Seguridad en la Ingeniería del Caos

# Security on Chaos Engineering

## ¿Qué es el Chaos Engineering?

Es una disciplina que mediante la aplicación de una serie de pruebas específicas pone a prueba características como la disponibilidad, seguridad y rendimiento de una infraestructura de sistemas.

Con los resultados obtenidos se busca la resolución de los problemas que surjan en estos sistemas distribuidos para así lograr alta confianza y capacidad de recuperación de todo el sistema. El objetivo es conseguir sistemas con soporte de condiciones extremas descubriendo sus debilidades sistemáticas.

La ingeniería del caos está constituida en base a los principios definidos en http://principlesofchaos.org/ por Netflix.

Sus principios son:

1. Definir lo que sería un estado «estable»

2. Realizar una hipótesis del siguiente estado que le seguirá

3. Introducir variables que reflejen eventos fieles a la realidad

4. Intentar romper la hipótesis

Esta disciplina es aplicable en los sistemas distribuidos debido a que los mismos disponen de múltiples partes complejas donde éstas pueden tener comunicación o dependencia entre si.

Uno de los términos asociados con esta disciplina es la resiliencia, que se define como la capacidad para adaptarse positivamente a situaciones adversas. Si nuestro objetivo es construir sistemas escalables que a la vez dispongan de resiliencia, se requiere introducir caos para el aprendizaje y fortalecimiento de la misma.

Es importante destacar la importancia de esta disciplina, ya está siendo usada en producción por empresas de relevancia como Netflix, Google, Dropbox, el banco nacional de Australia, Jet, etc donde se están obteniendo mejoras sustanciales en sus infraestructuras.

## ¿De dónde viene el Chaos Engineering? Antifragilidad

El motor que mueve la disciplina de la ingeniería del caos viene del concepto “antifrágil” definido Nassim Nicholas Taleb.

Si bien la antifragilidad contempla el concepto de resiliencia del que ya hemos hablado previamente, ésta va más allá, pues si tomamos por ejemplo el concepto de un sistema robusto, podemos decir que el mismo se caracteriza de que puede aguantar gran cantidad de estrés aplicado sobre él, pero hay que tener claro que un sistema robusto ni crece ni alimenta su evolución con los agentes estresantes que provoque la fragilidad del sistema, se mantiene igual, no evoluciona. Lo que nos aporta lo antifrágil es que si tendría esta evolución o mejora ante el estrés provocado.

Este concepto es aplicable incluso a nuestra propia existencia como seres humanos, como a sistemas complejos (sistemas vivos), puesto que vivimos en un entorno donde existen variables que no podemos controlar, como podrían ser el caos, el desorden, la aleatoriedad, la incertidumbre, el tiempo, etc.

“No podremos entender lo caótico dado que somos seres lógicos”, y es que pese que nos empeñemos a intentar planificar y controlar todo, la realidad es que esto no es posible.

Aunque si es cierto que se puede llegar a comprender parte de un sistema caótico, hasta incluso llegar a tener un conocimiento del propio sistema bastante alto como para tener la capacidad de previsión de gran parte de los problemas que surjan y evitarlos, esto solo generaría un porcentaje de fiabilidad y capacidad de recuperación alto como dato estadístico durante la recuperación, pero lo que plantea Nassim Nicholas va más allá de esto.

El enfoque que nos da Nassim Nicholas no solo se centra en la capacidad de recuperación de forma rápida intentando cubrir todas las variables que conozcamos, si no que aprovechando estos agentes estresores controlados por nosotros los usemos a nuestro favor, como herramientas propias para una mejora continua con lo que aprendamos de sus resultados.

Una analogía sería por ejemplo con los huesos del cuerpo humano, donde se vuelven más robustos cuando están sometidos a la gravedad, por ejemplo mediante el ejercicio, pero curiosamente si estamos un mes en cama sin aplicar este agente estresante, concretamente el agente estresante de la gravedad sobre los huesos, terminaremos teniendo una posible atrofia muscular o volviendo más débiles los huesos.

Netflix intenta llevar la filosofía comentada a su Chaos Engineering, proyectando la misma en una suite de software que han llamado Simian Army que está compuesta de una serie de software que es capaz de asumir cada uno de los roles de esos agentes estresantes para poner a prueba plataformas orientadas a cloud, como podría ser Amazon Web Service, Google Cloud Platform, etc.

Para poder llevar a cabo esta idea se debe apostar por elementos de nuestra arquitectura que sepan comunicarse entre si y que nos comuniquen hacia nosotros estos estados informativos mediante esos agentes estresores por medio de una fuerte monitorización (spinnaker, sysdig, datadog, grafana, pagerduty, etc).

Cuando tengamos la visibilidad suficiente generaremos capacidad de reacción ante problemas aleatorios, si los mismos los provocamos nosotros de forma controlada, aumentaremos nuestra antifragilidad.

## Opacidad causal

Debemos tener claro que cuando se realiza esta transferencia de información entre los componentes de un sistema vivo y complejo, si solo nos centrásemos en las variables que creemos que pueden ser el foco de inicio del problema, esto sería simplificar la complejidad y engañarnos a nosotros mismos. La realidad, la vida misma, no funciona así… es mucho más compleja y está llena de variables que ni hemos barajado ni podemos hacerlo.

Si nos fiamos en la relación entre causa y consecuencia como posible análisis de problemas en nuestros sistemas y para ello nos basamos en la lógica bivalente, debemos de entender que esto realmente no es viable debido a que esta misma lógica, por como está definida, excluye matices, por lo que la búsqueda de la inferencia no acotaría realmente la búsqueda real problema ante la gran diversidad de variables que no podemos controlar.

Esta poca visibilidad de estas variables responsables de la causa y posteriormente consecuencia, sería la opacidad causal.

La securización de los sistemas nunca es plena debido a todas esas variables que no controlamos, pues como ya se ha comentado, aunque creamos que las tenemos todas contempladas, la realidad es que no es así. Los problemas que se generan en estos sistemas son similares a un proceso vivo donde la inclusión de aleatoriedad y la medición de resultados nos ayuda a tener tiempo de reacción, por lo tanto cierta “proactividad”.

## Ser proactivo es bueno, tener una rápida capacidad de recuperación ante la aleatoriedad es genial

Comentan que los mejores caballos pierden cuando compiten con otros más lentos y que pueden llegar a ganar cuando se enfrentan con rivales de su altura. Esto puede ser debido a múltiples factores, aunque Nassim Nicholas lo justifica con que esto es debido a la ausencia de los agentes estresores y/o retos, perjudicando así a los mejores.

Trabajar esta proactividad que viene dada por estos agentes estresores controlados por nosotros, nos ayudaran a ser más eficientes a la hora de recuperarnos.

La antifragilidad es lo que se despierta con la aleatoriedad y reacciona en exceso para compensar el daño provocado por los estresores.

## Fragilidad como nodo, antifragilidad como sistema

Podemos afirmar que un organismo vivo tiene una vida finita y que el organismo vivo cuando fallece lo hace después de dejar descendencia con un código genético que difiere en algún aspecto del de su progenitor.

Si observamos desde otra perspectiva, podemos decir que la propia naturaleza no considera que los individuos sean muy útiles cuando han agotado su capacidad de reproducción, por lo que prefiere dejar que el juego continúe en el nivel informativo, el del código genético.

Se considera por lo tanto que los organismos deben morir para que la naturaleza como “sistema” sea antifrágil.

Esta base debemos extrapolarla y absorberla hacia los sistemas, pensando en ellos como un conjunto de nodos (individuos) con su propia complejidad dentro de un sistema interconectado, donde existan funciones de transmisión de información eficientes frente a variables aleatorias que no podremos controlar para así lograr esa antifragilidad como sistema, aunque mueran determinados individuos o nodos.

Debemos aprovecharnos de las herramientas actuales de administración de nuestros sistemas (monitorización, despliegues continuos, mecanismos de alta disponibilidad, disaster recovery, etc) e introducir los elementos estresores para nuestro beneficio y crecimiento, buscando como objetivo la antifragilidad.

## Asegurar la seguridad mediante la antifragilidad

Normalmente suelo ver que no se suele dar el peso adecuado a la seguridad de los sistemas, por lo que aún teniendo sistemas exitosos que puedan estar logrando su principal objetivo, por ejemplo generar beneficios, no se comprende que realmente el peso de la fragilidad debería ser más alto e importante, puesto que no se tiende a ver que la supervivencia es más prioritaria que el éxito.

Esto es muy justificado normalmente por las prioridades de negocio, pero también implica con estas decisiones nunca generar sistemas antifrágiles en el tiempo.

Mediante el Simian Army de Netflix podremos hacer uso del “Security Monkey”, una herramienta que nos dará una visibilidad del estado de la configuración de nuestra arquitectura de los sistemas orientados a la plataforma que la hayamos desplegado (AWS, GCP, …).

## Estrategias: Simian Army

Realizar un análisis y su consecuente toma de decisiones para corregir un problema por medio de la recogida de información de los agentes estresores, puede llegar a ser muy complejo, por lo que lo ideal es realizar estrategias heurísticas enfocadas en un concepto claro, que menos es más y en priorizar una buena toma de decisiones donde lo principal sea la sencillez de resolución.

Creo que la aplicación del Chaos Monkey de Netflix solo tiene sentido en producción cuando disponemos de sistemas con una madurez relativamente alta, ya que comenzar aplicando el mismo en una arquitectura poco madura podría llegar a ser peor que un tiro en los pies si no lo hacemos en entornos controlados, por ejemplo en entornos de test.

Los elementos estresores (monos caóticos) o estrategias del Simian Army serían los siguientes:

• SSH monkeys: Ejecuta cualquier script disponible en una instancia después de iniciar sesión a través de SSH. Esta estrategia también puede incluir la eliminación de archivos para garantizar los permisos de archivos adecuados (seguridad)
• Simius Mortus: Apaga la instancia usando la API EC2. La clásica estrategia del mono del caos
• Simius Quies: Esto elimina todos los grupos de seguridad de la instancia y lo mueve a un grupo de seguridad que no permite ningún acceso. Por lo tanto, la instancia se está ejecutando, pero no se puede llegar a ella a través de la red. Esto solo puede funcionar en instancias de VPC
• Simius Amputa: Aquí se quitan los volúmenes EBS asignados a la instancia, simulando un problema con el volumen EBS. Por lo tanto, la instancia se está ejecutando, pero la E/S del disco EBS fallará
• Simius Cogitarius: Ejecuta procesos intensivos de CPU. La instancia tendrá efectivamente una CPU mucho más lenta
• Simius Occupatus: Ejecuta procesos intensivos en disco. La instancia tendrá efectivamente un disco mucho más lento
• Simius Plenus: Escribe un archivo enorme en el dispositivo raíz, llenando el disco raíz EC2
• Simius Delirius: Esta estrategia consiste en matar cualquier proceso java o python que encuentre cada segundo, simulando aplicaciones defectuosas, una instalación dañada o una instancia defectuosa
• Simius Desertus: Esta estrategia enruta la red 10.0.0.0/8, que es utilizada por la red interna de EC2. Todo el tráfico de red EC2 <-> EC2 fallará
• Simius Nonomenius: Aquí se usa iptables para bloquear el puerto 53 para TCP y UDP; esos son los puertos de tráfico DNS. Esto simula una falla de sus servidores DNS
• Simius Noneccius: Este mono pone entradas de host ficticias en / etc / hosts, por lo que todas las comunicaciones de la API EC2 fallarán. Esto simula una falla del plano de control EC2. Por supuesto, si su aplicación no utiliza la API EC2 de la instancia, entonces no se verá afectada por completo
• Simius Amnesius: Aquí se crearán entradas de host ficticias (/etc/hosts), por lo que toda la comunicación S3 fallará. Esto simula una falla de S3.
• Simius Nodynamus: Realiza lo mismo que el Fail S3 API pero en el servicio DynamoDB
• Simius Politicus: Se usa para corromper una gran parte de los paquetes de red. Esto simula una degradación de la red
• Simius Tardus: Esta estrategia introduce latencia (por ejemplo, 1 segundo +/- 50%) a todos los paquetes de red para simular la degradación de la red
• Simius Perditus: Aquí se eliminan fragmentos de la transmisión de los paquetes de red. Esto simula la degradación de la red EC2

## Estrategia de seguridad: Security Monkey

En plataformas de computación en la nube implementar la estrategia de seguridad Security Monkey es relativamente sencillo. Si por ejemplo trabajamos sobre AWS, con Security Monkey podremos supervisar, alertar e informar sobre irregularidades a nivel de seguridad sobre la plataforma.

Implementar una estrategia así nos ayudará a trabajar la antifragilidad de nuestra plataforma, inclusive ayudarnos al cumplimiento los objetivos de control y requisitos de PCI-DSS en caso de auditorias.

Algunas de funcionalidades de supervisión de configuraciones en AWS serían:

>> Security Groups

• Generación de informes sobre malas configuraciones en los SG
• Disparadores con alertas por correo
• Alertas ante la agregación de entradas 0.0.0.0/0 en los SG
• Control de cambios en los SG (Historial)
• Control de SG creados y eliminados

>> S3

• Security Monkey actúa como control de origen para sus políticas de cubos S3, ACL y reglas de ciclo de vida
• Genera un informe de auditoría de todos los problemas actuales (por ejemplo, los segmentos de AWS S3 que son accesibles para todos los compartidos en cuentas AWS desconocidas y tienen sentencias condicionales)
• Crea una alerta por correo electrónico cuando se agrega o borra un cubo S3
• Las políticas de recursos de AWS S3 se utilizan para otorgar controles de acceso de granos finos para segmentos y objetos S3. Todas las ACL y políticas se almacenan en el mono de seguridad, que activa las alertas cuando se realizan los cambios. Es útil cuando tiene segmentos S3 sensibles y desea monitorear los cambios
• Rastrea contenedores S3 para el cifrado a nivel de cubo
• Controla el control de versiones de cubos
• Realiza un seguimiento del objeto del ciclo de vida de un segmento S3. Las reglas de ciclo de vida le permiten archivar/eliminar automáticamente objetos S3 basados ​​en conjuntos de reglas predefinidos
• Supervisa las políticas de S3 ACL y de cubo desde la última comprobación y alerta cuando los depósitos son de acceso público. Aquí hay una buena lectura sobre los segmentos AWS S3 de 100 abiertos a la vista que exponen datos privados

>> IAM

• Genera un informe de todos los usuarios activos de IAM con claves de acceso activas.
• Enumera todas las claves activas activas de IAM que no se han girado en los últimos 90 días.
• Enumera todas las claves de acceso inactivas que se pueden usar para limpiar.
• Enumera todas las claves activas que no se usaron en los últimos 90 días.
• Enumera el usuario de IAM que tiene acceso a la consola de AWS, pero sin MFA habilitado
• Alertas cuando un rol de IAM tiene privilegios de administrador completos
• Actúa como un control de origen para todas sus políticas de IAM asociadas a los usuarios/roles

>> ELB

• Alertas cuando un ELB está orientado a internet
• Alertas cuando el registro ELB no está habilitado
• Alertas cuando los cifrados en desuso están habilitados en un ELB
• Proporciona una lista de las cifras débiles si está habilitada en la política ELB

>> SES

• Supervisa las identidades de SES para asegurarse de que solo la dirección de correo electrónico de la empresa válida esté configurada como verificada
• Monitores para todos los objetos SES que no están verificados y que se pueden limpiar

>> SQS

• Alertas cuando una cola SQS tiene una política que otorga acceso a todos o está abierta al mundo
• Notifica cuando hay un cambio en la política de SQS

## Implementación de nuestra propia estrategia

La implementación de una estrategia propia relativa a seguridad es posible utilizando el Simian Army de Netflix, ya solo dependeríamos de buenos procesos de análisis y creatividad, donde podría ser interesante “caotizar” nuestra plataforma realizando acciones del siguiente tipo:

• Desactivar reglas de SG
• Modificación de archivos en instancias de forma aleatoria
• Escucha de puertos de forma aleatoria
• Inyección de tráfico malicioso en nuestros VPC
• Matar aleatoriamente procesos en nuestras instancias
• Instalar malware sobre las instancias
• Corromper ficheros, sistemas o redes completas
• Realizar procesos de exfiltración de datos
• Lanzar análisis de vulnerabilidades sobre las instancias y sus servicios
• Desconfigurar servicios
• …

Esto nos daría una visibilidad más profunda de las consecuencias y compresión de los métodos de ataque y la forma de defendernos.

## Conclusión

Por la experiencia que he tenido, puedo decir que esta disciplina hace de nuestros sistemas que la alta disponibilidad se perfeccione, trabajando a unos niveles de exigencia más agresivos y generando, en cierto modo, sistemas más confiables.

Como consecuencia se podría decir que nuestros sistemas llegarían a un grado de madurez alto, ya que disciplinas de este tipo nos fuerza a crecer y generar esa maduración.

Creo que este tipo de disciplina debería ser obligatoria en la implantación de sistemas, mejorando así la visibilidad, tiempo de reacción y reducción de desastre ante problemas graves de seguridad.