BLOG | OFICINA DEL CTO

Confianza cero: Tres componentes estratégicos clave de Assume Breach

Miniatura de Ken Arora
Ken Arora
Publicado el 13 de abril de 2023

La confianza cero es un tema popular en los círculos de ciberseguridad en estos días, pero todavía recibo miradas extrañadas cada vez que menciono el concepto de asumir una violación como parte clave de la mentalidad de confianza cero. Supongo que la razón de esta reacción surge de una de dos posibles preocupaciones. En primer lugar, algunos profesionales de seguridad pueden interpretar esto como una visión terriblemente pesimista del mundo; su internalización de “asumir una violación” sería algo así como: “Entonces, ¿estás diciendo que estamos todos condenados? "Bueno entonces, rindamos nuestras manos y dejemos incluso de intentarlo " . Otros, quizás los más orgullosos, pueden tener una actitud de: "Bueno, tus cosas pueden ser violadas, pero mi seguridad es sólida como una roca y no hay forma de que los malos puedan atravesar mis defensas ".

Mi intención no es ninguna de estas dos extremos, sino más bien hacer hincapié en internalizar la realidad de operar en un mundo digital, es decir, que se producirán violaciones y, por lo tanto, pueden y deben tenerse en cuenta en el diseño de cualquier sistema de seguridad. Este no es un concepto nuevo y deberíamos inspirarnos en la sabiduría adquirida por generaciones de artesanos y trabajadores comerciales que lo han adoptado.

Los fontaneros, electricistas y otros profesionales que operan en el mundo físico han internalizado desde hace mucho tiempo la verdadera esencia de “asumir el incumplimiento”. Dado que tienen la tarea de crear soluciones que deben ser robustas en entornos tangibles, aceptan e incorporan implícitamente el simple hecho de que las fallas ocurren dentro del alcance de su trabajo. También entienden que los fracasos no son una crítica a sus habilidades ni una razón para renunciar a sus servicios. Más bien, sólo los más hábiles, entendiendo que sus creaciones eventualmente fracasarán, incorporan los aprendizajes de los fracasos pasados y son capaces de anticipar probables fracasos futuros. 

Recientemente tuve que hacer frente a un problema similar: una tubería de alcantarillado de mi casa se obstruyó en medio del camino de drenaje. La casa tiene más de 30 años, por lo que un fallo, una violación, no debería ser una sorpresa. Después de todo, la probabilidad de que se produzca una vulneración en cualquier sistema durante un período prolongado de tiempo se acerca al 100%.  

Ése es el punto. Anticipar una falla a lo largo del tiempo es tan cierto para una solución de seguridad de aplicação como lo es para mi sistema de plomería. Además, suponer que “mi sistema de plomería nunca fallará” no es más apropiado como estrategia de mantenimiento del hogar que “mis defensas cibernéticas nunca serán vulneradas”. 

Por lo tanto, la mentalidad del plomero —y del profesional de la ciberseguridad— debe abarcar cómo lidiar con la falla, es decir, la violación, que eventualmente ocurrirá.

Tres componentes estratégicos clave de la estrategia Assume Breach

Una estrategia eficaz para afrontar fallas de los sistemas (físicos o cibernéticos) generalmente tiene tres componentes.

  1. Visibilidad. Asegúrese de tener suficiente visibilidad para poder detectar una falla lo antes posible. Una fuga de plomería en el desagüe del baño, si no se controla, provocará podredumbre y moho en el contrapiso, lo que puede tardar meses o años en notarse. O uno podría notar agua goteando desde el techo del espacio debajo de un baño del segundo piso después de que un depósito de agua debajo del piso se haya desbordado y el panel de yeso se haya saturado. En cualquiera de estos escenarios, la primera detección del problema ocurre algún tiempo después de la falla inicial y después de que se haya producido un daño secundario adicional .

    El primer principio para asumir una falla o una violación debe ser el de proporcionar indicadores claros de un posible compromiso lo antes posible después de la falla, idealmente incluso proporcionando una notificación activa de las fallas probables. Por ejemplo, los sótanos que dependen de bombas de sumidero para la extracción de agua generalmente tienen sensores que emiten una alarma cuando el nivel del agua excede un umbral preestablecido. En otras situaciones, donde la alerta proactiva no es posible para todos los modos de falla probables, se realizan controles de mantenimiento de rutina (por ejemplo, inspección de calentadores de agua semestralmente).

    En ciberseguridad, esto significa que la arquitectura de seguridad de las aplicação debe incluir una estrategia de telemetría considerada y probada que tenga en cuenta los modos de falla más importantes y brinde visibilidad oportuna de posibles infracciones. En la práctica, la telemetría debe transmitirse a herramientas de análisis y notificaciones mediante prácticas de AISecOps, y también debe persistir simultáneamente en los almacenes de datos para su uso posterior. Se deben utilizar herramientas de inteligencia artificial y de alerta para mejorar la eficacia y proporcionar contexto a los humanos y garantizar una respuesta oportuna. Los datos persistentes se deben utilizar para aprender y ayudar a brindar información para lograr mayor solidez en el futuro.

     

  2. Robustez. Las soluciones deben incluir los medios para evitar o reducir la duración de una falla. Los patrones comunes de robustez en este contexto son (a) degradación elegante o (b) redundancia, y la elección depende de la viabilidad de operar con un componente degradado. Algunos sistemas, como los calentadores de agua, pueden tener ambos. Por ejemplo, mi calentador de agua utiliza un sistema de recirculación alimentado por bomba para tener siempre agua caliente lista para su uso. Pero si la bomba falla, aún así tendré agua caliente, aunque tendré que esperar un poco más. Por otro lado, la falla de un sensor de bobina de calentamiento (donde el elemento de calentamiento no se apaga) puede provocar una falla catastrófica , por lo que se utiliza redundancia, en forma de una válvula de alivio de presión.

    La robustez debe considerarse en múltiples ámbitos del sistema. Por ejemplo, en el ámbito de la línea de drenaje, un plomero que trabaja en una solución de calidad comercial podría instalar un par de líneas de eliminación redundantes, de modo que la falla de cualquiera de las líneas no haga que el drenaje quede inutilizable. Por otro lado, un arquitecto que opere el nivel de abstracción del sistema podría diseñar redundancia a nivel del sistema, como agregar un segundo lavabo o inodoro cerca, lo que también tendría el beneficio de abordar más modos de falla que solo las líneas de drenaje obstruidas.

    Ciertamente, la redundancia es una práctica común en ciberseguridad, ya que muchos dispositivos de seguridad se implementan en modo activo/en espera (redundancia total) o activo/activo (degradación elegante). Sin embargo, el mundo de la ciberseguridad difiere un poco del mundo físico. En primer lugar, el hecho de que en el mundo de la ciberseguridad haya atacantes activos, con intención e inteligencia, significa que las fallas rara vez son resultado de causas naturales. Una segunda diferencia más significativa es la de escala. Debido a que el software es virtual, no físico, sigue el paradigma “escribir una vez, implementar muchas”. Si bien esta es una propiedad maravillosa para escalar, también implica que una vulnerabilidad de código en un componente de software central probablemente afectará a todas las instancias de ese código en el sistema. Como tal , la solución de ciberseguridad para la robustez se basa también en evitar puntos únicos (y clases únicas de elementos) de falla; una estrategia a veces denominada “defensa en profundidad”. La autenticación multifactor es un gran ejemplo de esta idea en la práctica. El modo de falla (los medios para comprometer) de cada factor es diferente, y el compromiso de cualquiera de los factores por sí solo no comprometerá el sistema en su conjunto.

     

  3. Contención. Es fundamental limitar el impacto (la zona de explosión) de una falla. Así como aceptamos que ocurrirán fallas o infracciones, también debemos aceptar que no podremos evitar por completo los puntos únicos de falla ni crear redundancia para cada requisito funcional. Por consiguiente, el arquitecto también debe considerar cómo minimizar el impacto de un fallo, utilizando tanto el esfuerzo como las consecuencias como dos métricas importantes de bondad. Por ejemplo, un plomero puede agregar puertos de limpieza ubicados estratégicamente a las líneas de drenaje para reducir el tiempo de remediación. En caso de fallas más catastróficas, un contratista podría elegir tuberías de drenaje de PVC en lugar de galvanizadas para facilitar la reparación de una fuga en la línea, reduciendo así el esfuerzo de remediación. Una práctica común de plomería doméstica es la inclusión de válvulas de cierre para limitar las consecuencias de una falla (detectada), evitando así daños secundarios a tocadores y pisos.

    En el mundo de la ciberseguridad, los conceptos análogos son aislamiento, mantenibilidad y modularidad . El aislamiento consiste en minimizar los daños colaterales o detener el sangrado; una buena práctica es contar con una infraestructura que pueda actuar como un disyuntor, utilizando tecnologías como la microsegmentación. Mantenibilidad significa que, cuando sea posible, habilitar un camino rápido y de bajo esfuerzo desde una situación comprometida hasta una no comprometida; por ejemplo, reiniciar una carga de trabajo comprometida por ataques de desbordamiento de memoria podría ser un método de mitigación efectivo (aunque incompleto). La modularidad es la práctica de construir sistemas que permitan intercambiar fácilmente componentes funcionales comparables, de modo que en los casos en que el mantenimiento no es posible o suficiente, se minimiza el esfuerzo necesario para su remediación.

Estas son algunas de las mejores prácticas que he aprendido sobre cómo lidiar con las infracciones, aunque ciertamente no afirmo que no existan otras. Lo que más importa es que los desarrolladores y profesionales de seguridad encargados de proteger las aplicações comprendan que se producirán fugas y que inevitablemente habrá violaciones. En ese sentido, la forma en que planificamos y abordamos esos fracasos es tan importante y merece tanta reflexión deliberada como lo que hacemos para minimizar la frecuencia de esos fracasos.  

En última instancia, seremos juzgados no sólo por la frecuencia con la que se produzcan las infracciones, sino también por lo bien que reaccionemos ante ellas cuando inevitablemente ocurran