Si alguna vez —en alguna realidad alternativa o en un futuro de fantasía— tuviera la oportunidad de diseñar los sistemas informáticos de la Flota Estelar, me aseguraría sin duda de que los sistemas de armamento no estuvieran conectados a las subrutinas de soporte vital. O, si fuera el comandante de una fuerza de invasión alienígena encargada de conquistar la Tierra —un planeta habitado por una especie completamente distinta, no lo olvidemos—, exigiría autenticación biométrica en lugar de un código de acceso o un token. Y, por último, si alguno de mis oficiales o naves espaciales lograra «escapar» milagrosamente de sus captores contra todo pronóstico, lo primero que haría sería comprobar que no llevara consigo ningún caballo de Troya.
Entonces, ¿qué tiene que ver esto con la confianza cero? Como probablemente ya habrás adivinado, a Hollywood le encantan las tramas que muestran las consecuencias épicas de renunciar a una pequeña dosis inicial de sana paranoia. Y, desde mi perspectiva como profesional de la ciberseguridad, esa misma mentalidad —mantener una sana paranoia— constituye la esencia de lo que realmente significa la confianza cero.
Entonces, ¿por qué he decidido centrarme específicamente en la confianza cero? Mi motivación se debe a una tendencia en el uso actual del término «confianza cero». Volviendo a otra anécdota sobre la producción cinematográfica, esta vez de finales de los años 80, por aquel entonces Hollywood estaba pasando de las antiguas tecnologías analógicas a los estándares digitales de audio, vídeo y edición de posproducción. En aquel momento y entorno, muchos de los miembros menos técnicos de la comunidad cinematográfica no entendían qué significaba realmente «digital», ni tampoco les interesaba demasiado; para ellos, el término «digital» era, en la práctica, sinónimo de «la mejor opción de su categoría». Como consecuencia —y para gran disgusto de mis amigos expertos en tecnología que trabajaban con ellos—, los productores y directores empezaron a preguntar si la iluminación o la construcción de los decorados eran «digitales», cuando lo que realmente querían decir era: «¿Es este el mejor diseño de iluminación o la mejor construcción de decorados?». Volviendo al presente, con demasiada frecuencia oigo utilizar «confianza cero» en la comunidad de responsables de seguridad de una forma muy similar a como los productores cinematográficos utilizaban «digital» en 1990.
Por otro lado, hace poco conocí el marco «Empieza con el porqué» de Simon Sinek. Este marco, combinado con los recuerdos de cómo concebía Hollywood los inicios de lo «digital» y de cómo las películas creaban historias basadas en buenas (o malas) prácticas de seguridad, me ayudó a concretar varias ideas que tenía sobre la confianza cero. En el núcleo de la confianza cero se encuentra la moraleja de las tramas de Hollywood con las que comencé: renunciar a una pequeña dosis de ciberprevención bien meditada al diseñar y gestionar la seguridad de un sistema crítico acabará provocando un grado mucho mayor de vulneración y sufrimiento. De forma análoga, en el nivel central del «porqué» del marco, la confianza cero puede expresarse mediante el siguiente conjunto de convicciones:
A. Verifique siempre de forma explícita «quién»: es decir, el actor que intenta interactuar con su sistema.
B. Aplicar de forma predeterminada el mínimo privilegio necesario: Una vez establecida la identidad, conceda a ese actor únicamente los privilegios necesarios para interactuar con el sistema en la transacción comercial específica que se esté realizando, de acuerdo con los privilegios requeridos que se hayan definido en el diseño.
C. Supervisar y (re)evaluar continuamente: La verificación de la identidad y los derechos de acceso no deben ser algo estático que se realiza una sola vez; por el contrario, estas decisiones deben evaluarse y reevaluarse continuamente.
D. Y, aun así, dé por hecho que su sistema se ha visto comprometido: Por último, pese a haber aplicado las tres medidas anteriores, dé por sentado que un adversario sofisticado ha logrado sortear las defensas. Por tanto, el sistema también debe contemplar cómo identificar y aislar cualquier elemento o identidad que se haya visto comprometido, así como una estrategia para contener o mitigar su impacto en el sistema.
En pocas palabras: No confíes de forma implícita; verifica siempre. Y concede solo la confianza necesaria. Evalúa continuamente. Y no des por sentado que los detectarás a todos. Ese es el «porqué» de la confianza cero.
Por supuesto, el «porqué» es solo una parte de la historia. El «cómo» —es decir, las técnicas y herramientas utilizadas para materializar la mentalidad que genera ese «porqué»— constituye otra perspectiva relevante para el profesional y surge como consecuencia de las convicciones antes mencionadas. Una vez más, seré concreto y lo plantearé en el contexto del conjunto actual de herramientas de las que disponen hoy los profesionales de la ciberseguridad:
- Autenticación: Cualquier actor que interactúe con el sistema protegido debe acreditar que posee una identidad o, en algunos casos, un conjunto de identidades, como una identidad para la persona o el sistema automatizado, junto con una identidad para el dispositivo o la plataforma que utiliza dicha persona o sistema, y quizá incluso una identidad para el navegador o la herramienta empleados para facilitar el acceso. El enfoque de confianza cero implica que toda acreditación de este tipo debe verificarse o «autenticarse» mediante uno o varios métodos: un secreto compartido, un token o certificado y, en los sistemas más modernos, también mediante la observación y verificación del patrón de comportamiento de dicho actor.
- Control de acceso: Una vez establecida la identidad, se le debe asignar un nivel de confianza, materializado en los derechos de control de acceso que se le concedan. La política de control de acceso debe seguir el principio de mínimo privilegio, según el cual solo se conceden los derechos mínimos necesarios para que el actor desempeñe su función dentro del sistema. Las implementaciones ideales de control de acceso deben permitir especificar de forma detallada los derechos concedidos, por ejemplo: El rol <X> permite acceder a las API <1>, <3> y <4>, y otorga privilegios de lectura sobre objetos de las clases <Y> y <Z>. Una práctica recomendada que conviene tener en cuenta es que los escenarios complejos de control de acceso dirigidos a recursos de aplicaciones deben abstraerse mediante API, en lugar de conceder acceso directo a objetos, archivos y recursos de red.
- Visibilidad: Pasando a la parte de «supervisión» de este enfoque —un requisito previo para la «reevaluación continua»—, el sistema debe ofrecer una visibilidad continua y en tiempo real del comportamiento de cada actor dentro del sistema. En este contexto, la afirmación «si no lo viste, no ocurrió» es axiomática. Además, la «telemetría» recopilada no solo debe ser visible, sino también utilizable; es decir, debe integrarse en un marco que permita compartir y contextualizar la información notificada. Esto permite combinar y correlacionar de forma significativa datos procedentes de múltiples fuentes, lo que posibilita una evaluación de riesgos más sólida y eficaz.
- Análisis contextual asistido por aprendizaje automático: La finalidad de la visibilidad mencionada anteriormente es poder aplicar el principio de «reevaluación continua». En la práctica, este precepto requiere no solo visibilidad, sino también análisis —normalmente de múltiples fuentes de datos (lo que exige el marco propicio para el intercambio mencionado anteriormente)— casi en tiempo real. Para ello, la evaluación continua suele requerir la ayuda de sistemas de aprendizaje automático basados en IA que detecten a los actores con comportamientos anómalos, a fin de identificar cualquier posible vulneración del sistema. Por último, un motor de análisis sólido debería ser capaz de ofrecer una respuesta más matizada que un simple sí o no; idealmente, una evaluación del riesgo junto con la correspondiente puntuación de confianza.
- Remediación automatizada basada en el riesgo: Por último, dado que parte de este enfoque parte de la premisa de que algunos adversarios sofisticados lograrán infiltrarse en el sistema, este debe ser capaz de actuar para llevar a cabo una supervisión más exhaustiva y, cuando sea necesario, contener o bloquear dichas acciones o actores. La respuesta del sistema —que puede ir desde el mero registro hasta una inspección más profunda, el bloqueo de la acción intentada o incluso el engaño del presunto actor malicioso— debe evaluarse en el contexto empresarial general. Entre los factores que deben tenerse en cuenta se encuentran la probabilidad y el impacto de los falsos positivos o negativos, así como el riesgo empresarial asociado a la acción. Por ejemplo, bloquear la consulta de un catálogo de productos solo sería apropiado si existiera un grado de certeza muy alto de que el actor es un extractor malicioso de datos de sitios web; en cambio, exigir una autenticación adicional podría ser adecuado para una transacción bancaria con un grado de certeza menor. Por último, debido a la sofisticación y la velocidad de los ciberataques modernos, la medida operativa de remediación debe poder automatizarse, y la política definida por las personas debe expresarse en términos de objetivos basados en la intención.
El último aspecto del marco «por qué, cómo y qué» es el «qué»; es decir, los objetivos pueden alcanzarse y los distintos tipos de ataques pueden prevenirse o mitigarse mediante las herramientas y técnicas anteriores. Una taxonomía completa de todos los ciberataques será objeto de un futuro artículo; no obstante, como anticipo, el «por qué» y el «cómo» aquí descritos sí abarcan todo el espectro de sofisticadas «amenazas avanzadas». Por ejemplo, el enfoque de confianza cero permite hacer frente a las amenazas de ransomware, incluso cuando las inician componentes de software «de confianza» (lo que se conoce como «ataques a la cadena de suministro»). En concreto, la aplicación del principio de mínimo privilegio, plasmado en la política de control de acceso, debe utilizarse para limitar los permisos de lectura y escritura de archivos exclusivamente a los actores que realmente necesiten ese privilegio, evitando así el cifrado de los recursos de archivos. Además, si algún actor —por ejemplo, un componente de software existente con permisos de escritura de archivos— se viera comprometido (mediante el vector de ataque a la cadena de suministro antes mencionado) e intentara cifrar rápidamente una gran cantidad de archivos, la reevaluación y el análisis continuos deberían detectar en poco tiempo ese comportamiento anómalo, al observar la cantidad de archivos a los que se accede y la frecuencia con la que se hace. La detección, combinada con una mitigación automatizada, puede utilizarse para bloquear rápidamente este tipo de actividad.
Así pues, volviendo a los mundos alternativos con los que empecé... Si todos los subsistemas informáticos de la Flota Estelar funcionaran según el principio de mínimo privilegio, el subsistema de control de gravedad no debería poder invocar la API que lanza los torpedos de fotones. Y los controles de la nave nodriza alienígena no solo aplicarían una autenticación multifactor basada en datos biométricos, sino que sus controles de seguridad también asumirían que se producirán brechas y, por tanto, supervisarían y reevaluarían continuamente la situación, detectarían la anomalía de un dron de combate que atraviesa la nave y mitigarían la amenaza si ese dron anómalo se dirigiera hacia el núcleo del motor. Esas pocas y cruciales medidas preventivas evitarían una gran cantidad de situaciones dramáticas posteriores: algo malo para Hollywood, pero bueno para los profesionales de la ciberseguridad.
Para obtener más información sobre el marco que engloba los conceptos generales en torno a la confianza cero, en relación con el contexto empresarial actual, y sobre la mentalidad de seguridad que deberían adoptar los responsables de las aplicaciones empresariales, lea nuestro informe técnico «Seguridad de confianza cero: por qué es importante la confianza cero (y no solo para el acceso)».
Sobre el autor
Artículos relacionados del blog
Proteger los endpoints de las API dificulta la seguridad de las API
Descubre las complejidades de la seguridad de las API, los retos a los que se enfrentan las organizaciones, la evolución de los ataques contra endpoints de API y la necesidad de políticas de seguridad adaptadas.
¿Qué es el sesgo de la IA y por qué es importante para TI?
Descubre los fundamentos del aprendizaje de la IA. Aprende cómo pueden surgir sesgos en la IA y qué riesgos plantean para las TI y la transformación digital.
Redefiniendo la ciberseguridad en el extremo de la nube distribuida con IA y telemetría en tiempo real
La transformación digital y la adopción de tecnologías en la nube están provocando cambios en las arquitecturas de las aplicaciones. Estos cambios introducen nuevas superficies de ataque, que son el objetivo de métodos de ataque avanzados, altamente organizados y con motivaciones económicas. Mediante el uso del framework Morpheus de NVIDIA, F5 está investigando técnicas para detectar estas amenazas avanzadas con telemetría en tiempo real y análisis basados en IA.
El papel de la nube en las aplicaciones nativas del edge
No debería sorprender que, al igual que la aparición de la nube dio lugar a las aplicaciones nativas de la nube, el edge esté impulsando un conjunto de aplicaciones nativas del edge. Sin embargo, estas aplicaciones no residirán únicamente en el edge. Al mismo tiempo, están surgiendo nuevos patrones arquitectónicos que aprovechan las aplicaciones alojadas en la nube y en el centro de datos.
La creciente diversidad de ubicaciones y usuarios está impulsando a las empresas hacia el edge
En el contexto del ámbito de las aplicaciones, el término «usuario» siempre se ha referido a la entidad que interactúa con una aplicación. Del mismo modo que los cambios en las arquitecturas de las aplicaciones impulsan cambios en las tecnologías que permiten ofrecerlas y protegerlas, los cambios en la definición de usuario han provocado cambios en los lugares donde se despliegan las aplicaciones.
El edge está impulsando un renacimiento de las infraestructuras
A medida que las organizaciones aumentan la generación de datos y tratan de extraer valor empresarial de ellos, sin duda recurrirán a la analítica y la automatización basadas en la IA y el aprendizaje automático. Precisamente este tipo de cargas de trabajo son las que más se beneficiarían de una infraestructura optimizada y, sin embargo, hoy en día son las que menos probabilidades tienen de poder aprovecharla.