Los experimentos controlados destinados a romper la red pueden descubrir vulnerabilidades previamente desconocidas.

La sabiduría convencional dice que si algo no está roto no lo arregles. Sin embargo, la ‘ingeniería del caos’ argumenta que hay que intentar romperlo de cualquier forma, aunque solo sea para comprobar qué sucede. Así esta disciplina se define como el modo de experimentar en un sistema para generar confianza en su capacidad y soportar condiciones problemáticas durante su producción. Los profesionales de esta rama sencillamente realizan este experimento para comparar lo que podría suceder con lo que realmente pasa y mejorar la resiliencia.

Por qué la ‘ingeniería del caos’ tiene sentido

El analista de Forrester, David Mooter cree que esta ciencia es una respuesta lógica a un entorno en el que las redes están distribuidas en plataformas de múltiples nubes y bajo cada vez más ciberataques. “El problema es que estos sistemas son demasiado complejos como para que podamos comprenderlos por completo. Por ello, los esfuerzos en resiliencia deben basarse en la suposición de que no podemos comprender y predecir cómo se comportan”.

“La red no es siempre confiable”, añadió Nora Jones, fundadora y directora ejecutiva de Jeli. “El concepto de probar la red es el mismo que probar la CPU o cualquier otra cosa; simular eventos desfavorables y sacar a la luz las incógnitas”. La ‘ingeniería del caos’ respalda el concepto de verificación continua, la idea de que las cosas nunca son totalmente confiables y de que el error acecha siempre. “Es una batalla constante para mantenerse por delante de la vulnerabilidad, y requiere de un cambio de mentalidad en la forma en que se abordan las operaciones”.

Ejemplos de ‘ingeniería del caos’

Mooter trabajó con una empresa que hizo un experimento que pasaba por la configuración incorrecta de un puerto. “La hipótesis era que este sería detectado y bloqueado por el firewall con una alerta para el equipo de seguridad”. Pero, la mitad de las veces que se hizo, el firewall no pudo bloquearlo. Sin embargo, una herramienta de configuración de nube secundaria consiguió el éxito en todas las ocasiones.

“El problema fue que la herramienta secundaria no alertó al departamento de seguridad, por lo que estaba ciego ante este tipo de incidentes. Por lo tanto, la prueba mostró no solo un fallo en el firewall, sino también en la capacidad del equipo para detectar y responder ante un incidente”.

Probar metódicamente y no al azar

La ‘ingeniería del caos’ no sería útil si introdujera fallos al azar de los que los equipos de seguridad o red no fueran conscientes y detuviera la red o causara problemas de rendimiento. Es muy específica y se realiza en entornos que no son principalmente de producción. “No se rompen las cosas al azar, sino que se identifica inteligentemente el riesgo que no se puede asumir, se formula una hipótesis sobre el mismo y se ejecuta un experimento para confirmar la hipótesis”.

Como en una tesis científica, la hipótesis debe ser refutable. “Cada vez que ejecuto el experimento y tiene éxito, tengo más confianza en que voy en el camino correcto”, expresó. “Pero si falla, descubro nuevas informaciones de mis sistemas que pueden corregir mis falsas suposiciones.

Uno de los grandes beneficios de este enfoque es que encuentra problemas antes de que puedan tener un gran impacto en los negocios. “Supongamos que hay algún error que puede desconectar un servicio de pagos. Entonces, ¿es preferible descubrirlo en un entorno controlado, probablemente sin producción, o que suceda inesperadamente?”.

Mejores prácticas

Hay varias mejores prácticas que las organizaciones pueden aplicar al experimentar con la ingeniería del caos:

Incluya a los desarrolladores de aplicaciones. Mooter mencionó: “con arquitecturas distribuidas complejas, los desarrolladores no tienen una buena intuición para los límites de sus aplicaciones. Cuando la ingeniería del caos se convierte en parte de la entrega de software, los desarrolladores ven cada vez más ejemplos en los que sus suposiciones eran incorrectas. Esto crea el hábito de ser más proactivo al cuestionar sus suposiciones”.

Mejorar la comunicación. En Netflix, donde la empresa creó sus propias herramientas de ingeniería del caos y luego las abrió, la idea “era crear una función forzada para que los ingenieros construyeran sistemas resistentes”, aseveró Jones, quien trabaja en la compañía. “Todos sabían que los servidores se apagarían al azar y el sistema necesitaba poder manejarlo. Y no solo eso, la gente necesitaba saber cómo comunicarse con las partes correctas cuando esto sucedía”.

Elija los experimentos correctos. Los experimentos de caos de redes “posiblemente son las pruebas más populares para modelar interrupciones que causan tiempo de inactividad no planificado en los sistemas distribuidos complejos de hoy en día”, aseguró Uma Mukkara, jefe de ingeniería de caos en Harness, que proporciona herramientas de ingeniería de caos y servicios de soporte. Las empresas pueden aprovechar la ingeniería del caos para experimentos específicos, como la validación de la latencia de la red entre dos servicios, la verificación de los mecanismos de resiliencia en el código, la caída del tráfico en una llamada de servicio para comprender el impacto en las dependencias ascendentes o la introducción de corrupción de paquetes en un flujo de red para comprender la aplicación o resiliencia del servicio.

Equipos de seguridad integrados: La ‘ingeniería del caos’ se puede aplicar a cualquier sistema distribuido complejo, incluida la seguridad de la red, dijo Mooter. “Para la seguridad, la mentalidad es asumir que los controles de seguridad fallarán sin importar cuánto se esfuerce por ser perfecto”, expresó. Por ejemplo, un banco usó la ‘ingeniería del caos’ para cambiar los indicadores que estaba midiendo. En lugar de simplemente realizar un seguimiento del tiempo sin incidentes de seguridad, comenzó a medir qué salvaguardas de seguridad específicas se sabía que estaban funcionando, dijo Mooter.

Consejos para controlar el caos

Ponga límites a los proyectos de ingeniería del caos. “No creo que debas darle a cada ingeniero las claves para romper cosas”, indicó Jones. “Es una disciplina, y más específicamente es una disciplina de personas más que de herramientas, por lo que inculcar la cultura apropiada de seguridad psicológica y aprendizaje es un requisito previo antes de que la ingeniería del caos pueda ser efectiva”.

Aprenda de los sistemas de respuesta a incidentes existentes. Las organizaciones deben tomarse el tiempo para asegurarse de que están aprendiendo de los incidentes que ya están teniendo, expresó Jones. “Si está considerando la ingeniería del caos, le garantizo que hay una gran cantidad de información en los incidentes que ya ha tenido”, dijo. “Explore esos primeros y los patrones de superficie de ellos” que ayudarán a comprender los mejores tipos de experimentos para ejecutar.

Tener una manera de desconectar rápidamente. Es una buena idea tener una forma automatizada de cancelar inmediatamente una actividad de caos cuando sea necesario, mencionó Mooter. “Cada experimento de caos debe diseñarse para minimizar el radio de explosión en caso de que las cosas salgan mal”, dijo. “Esto puede ser en las capas de infraestructura, aplicación o negocio”. Por ejemplo, en la capa de infraestructura, aísle la falla a un conjunto limitado de conexiones.

Federar el programa de ‘ingeniería del caos’. “Los equipos de ingeniería del caos centralizados no escalan”, explicó Mooter. “Los equipos de entrega no aprenden ni desarrollan la intuición para la resiliencia si no están directamente involucrados, por lo que pierde el beneficio del cambio de cultura si está centralizado”. No tiene sentido crear una dinámica de “nosotros contra ellos” entre el equipo de caos central y los equipos de entrega, señaló Mooter.

“Por ejemplo, una empresa de software descubrió que en el pasado, un equipo de desarrollo señalaba con el dedo a la infraestructura por no proporcionar suficiente espacio en disco, mientras que el equipo de infraestructura señalaba y preguntaba por qué los desarrolladores escribieron un código que consumía tanto espacio”, dice.

Después de adoptar la mentalidad de la ingeniería del caos, ambas partes han dejado de discutir por qué el disco está lleno y han pasado a preguntarse cómo hacer que el sistema sea resistente frente a un disco lleno, dice Mooter.

Cambiar la cultura. Las organizaciones que utilizan la ingeniería del caos deberían crear una cultura de experimentación, dijo Mukkara. “Ningún sistema puede ser 100% confiable. Sin embargo, su cliente quiere que esté disponible cuando lo necesite. Necesita construir un sistema que pueda soportar fallas comunes y capacitar a su equipo para responder a fallas desconocidas. Esto comienza con la experimentación para aprender cómo se comporta y funciona su sistema y la iteración de las mejoras a lo largo del tiempo”.

Visibilidad y transparencia. Mukkara añadió: “Informar y compartir aprendizajes con múltiples partes interesadas sobre los problemas que está encontrando y las mejoras de confiabilidad que está realizando en su sistema, para involucrar a la empresa”, dijo. Por ejemplo, informe al liderazgo de gestión de productos contra qué modos de falla está protegido un sistema y cómo se han probado con éxito los mecanismos de resiliencia. “Esto les dará confianza para comprender el sistema y la disponibilidad que debe mantener. También puede informarles a qué modos de falla es susceptible su sistema, para que el problema pueda priorizarse o, como mínimo, reconocerse como un riesgo aceptable”.

-IDG.es