theNet by CLOUDFLARE

Roadmap to zero trust

5 simple projects to advance zero trust adoption

Zero trust adoption is complex, but getting started doesn’t have to be

Adopting zero trust security is widely recognized as a difficult journey. In many ways, this reputation is well deserved. Zero trust requires work that Security and IT are justifiably cautious about: rethinking default-allow policies and perimeter-based network architecture, enabling collaboration between functionally different teams, and putting faith in new security services. Organizations may postpone this transformation for a variety of reasons, including:

  • Limitaciones de capacidad debido a otros proyectos simultáneos

  • Variation in zero trust vendor offerings

  • La incertidumbre sobre dónde se encuentran los distintos recursos y aplicaciones en la red

  • Interrupciones de la productividad de los empleados

The zero trust framework is quite complex on the whole — the complete roadmap to zero trust architecture consists of 28 comprehensive projects. However, some projects require comparatively little effort, even for small teams with limited time.



Piecemeal zero trust adoption

In a networking context, zero trust security requires that every request moving into, out of, or within a corporate network is inspected, authenticated, encrypted, and logged. It’s based on the idea that no request should be implicitly trusted, no matter where it comes from or where it’s going.

Making early progress toward zero trust means establishing these capabilities where they are not currently present. For organizations starting from scratch, this often means extending capabilities beyond a single ‘network perimeter.’

Here are five of the simplest zero trust adoption projects: focusing on securing users, applications, networks, and Internet traffic. They won’t achieve comprehensive zero trust alone, but they do offer immediate benefits and can create early momentum for broader transformation.


PROYECTO 1

Aplicar la autenticación multifactor para las aplicaciones críticas

In a zero trust approach, the network must be extremely confident that requests come from trusted entities. Organizations need to establish safeguards against user credentials being stolen via phishing or data leaks. Multi-factor authentication (MFA) is the best protection against such credential theft. While a complete MFA rollout may take significant time, focusing on the most critical applications is a simpler — but still impactful — win.

Las organizaciones que ya disponen de un proveedor de identidad pueden configurar la autenticación multifactor directamente en ese proveedor, por ejemplo, mediante códigos de un solo uso o aplicaciones de notificaciones push enviadas a los dispositivos móviles de los empleados. Para las aplicaciones no integradas directamente con tu proveedor de identidad (IdP), considera la posibilidad de utilizar un proxy inverso para aplicaciones delante de la aplicación que exija la autenticación multifactor.

Las organizaciones que no cuentan con un proveedor de identidad pueden adoptar un enfoque diferente de la autenticación multifactor. El uso de plataformas sociales como Google, LinkedIn y Facebook, o contraseñas de un solo uso (OTP) puede ayudar a verificar las identidades de los usuarios. Estas son formas comunes de acceso por cuenta propia para proveedores externos, sin la necesidad de agregarlos a un proveedor de identidad corporativa, y estas estrategias también se pueden aplicar dentro de la propia empresa.


PROYECTO 2

Zero trust policy enforcement for critical applications

Enforcing zero trust means more than simply verifying user identities. Applications must also be protected with policies that always verify requests, consider a variety of behavior and contextual factors before authenticating, and continuously monitor activity. As in Project 1, implementing these policies becomes simpler when applied to an initial list of critical applications.

Este proceso varía según el tipo de aplicación:

  • Aplicaciones privadas con alojamiento propio (accesibles solo a través de la red corporativa)

  • Aplicaciones públicas con alojamiento propio (accesibles a través de Internet)

  • Aplicaciones SaaS


PROYECTO 3

Monitorear las aplicaciones de correo electrónico y filtrar los intentos de phishing

Email is the number one way most organizations communicate, the most-used SaaS application, and the most common entry point for attackers. Organizations should apply zero trust principles to email to complement their standard threat filters and inspections.

Además, los equipos de seguridad deberían considerar el uso de un navegador aislado para poner en cuarentena los enlaces que no sean lo suficientemente sospechosos como para bloquearlos por completo.


PROYECTO 4

Cerrar todos los puertos de entrada que estén abiertos a Internet para la entrega de aplicaciones

Open inbound network ports are a common attack vector and should be given zero trust protection, only accepting traffic from known, trusted, verified sources.

These ports can be found using scanning technology. Then, a zero trust reverse proxy can securely expose a web application to the public Internet without opening any inbound ports. The application’s only publicly visible record is its DNS record — which can be protected with zero trust authentication and logging capabilities.

As an added layer of security, internal/private DNS can be leveraged using a zero trust Network Access solution.


PROYECTO 5

Bloquear solicitudes de DNS ante amenazas conocidas o destinos riesgosos

DNS filtering is the practice of preventing users from accessing websites and other Internet resources that are known or highly suspected to be malicious. It is not always included in the zero trust conversation because it does not involve traffic inspection or logging. However, it can ultimately control where users (or groups of users) can transfer and upload data — which aligns well with the broader zero trust philosophy.

El filtrado de DNS se puede aplicar a través de la configuración del enrutador o directamente en la máquina de un usuario.


Understanding the broader zero trust picture

Implementing these five projects can be a relatively straightforward foray into zero trust. And any organization that completes these projects will have made significant progress toward better, more modern security.

Broader zero trust adoption remains complicated. To help, we’ve built a vendor-neutral roadmap for the entire zero trust journey, covering these five projects and others like them. Some will take far longer than a few days, but the roadmap can provide greater clarity into what zero trust adoption means.

All of these services are built into the Cloudflare connectivity cloud: a unified platform of cloud-native services designed to help organizations regain control of their IT environment. Cloudflare is the leading connectivity cloud company. It empowers organizations to make their employees, applications, and networks faster and more secure everywhere, while reducing complexity and cost. Powered by one of the world’s largest and most interconnected networks, Cloudflare blocks billions of threats online for its customers every day.

Este artículo forma parte de una serie de publicaciones sobre las últimas tendencias y temas que afectan a los encargados de la toma de decisiones sobre tecnología en la actualidad.




CONCLUSIONES CLAVE

Después de leer este artículo podrás entender:

  • Los 28 proyectos de la hoja de ruta de Zero Trust

  • Los 5 proyectos de adopción del modelo Zero Trust que apenas requieren esfuerzo

  • Los tipos de servicios que permiten la implementación

  • Cómo iniciar una guía de implementación para tu organización


Recursos relacionados


Más información sobre este tema

Descubre más información sobre la arquitectura Zero Trust y empieza a planificar una hoja de ruta para tu organización con la Guía de implementación de la arquitectura Zero Trust.

¿Quieres recibir un resumen mensual de la información más solicitada de Internet?