Prevenir es mejor que curar cuando se asegura …



El «bucle OODA» nos muestra cómo proteger las implementaciones nativas de la nube y prevenir las infracciones antes de que ocurran.

El renombrado estratega militar John Boyd concibió el «bucle OODA» para ayudar a los comandantes a tomar decisiones claras durante la Guerra de Corea. Veremos cómo se podría aplicar el bucle OODA OODA, que significa observar, orientar, decidir y actuar, específicamente para proteger las implementaciones nativas de la nube y prevenir las infracciones antes de que ocurran.

El ciclo OODA comienza observando cómo se desarrolla una batalla, determinando todas las opciones disponibles, tomando una decisión y actuando sobre esa decisión. La naturaleza caótica de la batalla requiere que el líder se reconcilie y repita constantemente ese proceso.

Podemos ver la misma lógica en un entorno nativo de la nube, donde describe cómo funciona la reconciliación de Kubernetes. Un controlador de Kubernetes:

  • Observa y orienta: supervisa el estado true y lo compara con las expectativas (es decir, el estado que el usuario ha definido para este recurso, quizás a través de un archivo YAML).
  • Determine: determina si es necesario agregar o eliminar recursos.
  • Actúa: toma medidas para adaptar constantemente el estado actual a las expectativas.

Por ejemplo, si tiene una implementación, el controlador verifica cuántos pods hay y si ese número coincide con el recuento de réplicas para esa implementación. Cada pod es una colección de contenedores que actúa como una «unidad desplegable» de código de aplicación, y el recuento de réplicas determine cuántos pods deben ejecutarse en este momento. Si el número actual de pods no coincide con este recuento, el controlador crea o destruye algunas cápsulas para alinear los números.

Puede aplicar el mismo modelo de bucle OODA para los comportamientos de seguridad. Puede detectar el comportamiento, compararlo con lo que espera ver, decidir si es algo que desea permitir y tomar medidas correctivas si ve algo inesperado. La pregunta es, ¿cómo se puede detectar si se ha producido un comportamiento inesperado?

Los contenedores son realmente útiles para simplificar el problema de detectar anomalías, especialmente si diseña sus aplicaciones utilizando un modelo de microservicios. Cada contenedor generalmente realiza solo una pequeña función y eso significa que el rango de comportamientos normales esperados es pequeño. Por ejemplo, a menudo es cierto que solo espera ver un ejecutable específico ejecutándose dentro de un contenedor determinado. Si puede observar los ejecutables que se ejecutan en cada contenedor, puede ver si cumplen con sus expectativas.

Durante mi presentación en la Cloud Indigenous Computing Foundation&#39s Foro de Kubernetes Sídney 2019, Acompañé a los asistentes a través de una demostración en vivo que ilustra esto. Puede encontrar un video clip de esta demostración, junto con todas las demás presentaciones del evento, aquí.

Como parte de esta demostración, mostré un script usando una herramienta llamada Tracee para alertarme sobre nuevos ejecutables que comienzan en contenedores. Mi script es una herramienta de seguridad nativa que aplica el modelo de bucle OODA al monitorear los nuevos ejecutables, mira sus nombres, determine si uno es malo y, de ser así, mata el pod básicamente, tira de un cable de emergencia. Sin embargo, si transcurre suficiente tiempo entre el momento en que se descubre el ejecutable incorrecto y el momento en que se toma una acción de corrección, el atacante puede tener éxito en la filtración de datos o en la eliminación de algún tipo de carga útil maliciosa que toma medidas más adelante. ¡No tan seguro después de todo!

Aquí hay otro problema con confiar en las herramientas de seguridad que reaccionan al mal comportamiento después de que sucede: el ciclo de reconciliación de Kubernetes se activa y recrea todos esos pods que mi script destruyó están haciendo lo malo otra vez, por lo que son destruidos de nuevo, y así sucesivamente. Mi herramienta de seguridad nativa está en desacuerdo con el ciclo de reconciliación de Kubernetes.

Lo que sería mejor es obtener la capacidad de evitar que se implementen esos pods defectuosos en primer lugar. Si puede determinar que la intención es ejecutar algo malo, no tiene que intentar detenerlo después de que se ejecute. Entonces, es mejor que el bucle OODA mire la intención, la examine con la expectativa y luego decida si permite o no ese comportamiento.

La clave es buscar antes en la canalización de implementación lugares donde pueda insertar medidas preventivas. Si puede evitar que se implemente software program incorrecto, no puede causar ningún daño. Por lo tanto, cualquier cosa que podamos hacer antes del tiempo de ejecución es preventivo y más eficaz.

Escanear imágenes es la forma en que podemos buscar dentro de las imágenes vulnerabilidades conocidas. Dependiendo de su escáner, es posible que también pueda detectar malware y evitar que esas imágenes se implementen, quizás impidiendo que se inserten en su registro. Puede utilizar el management de acceso basado en reglas para evitar que usuarios no autorizados implementen program como otro método para evitar la propagación de códigos maliciosos. Y puede usar el regulate de admisión como Open Policy Agent (OPA) para verificar el YAML mientras se implementa y evitar que se ejecute si no cumple con sus criterios. Algunas herramientas de seguridad pueden incluso proporcionar medidas preventivas dentro de un contenedor en ejecución, al evitar que se ejecuten programas no autorizados (en lugar de eliminarlos después de que ya hayan comenzado). (Nota del editor: la empresa del autor es una de las que ofrecen dicha herramienta).

Si está pensando en proteger su hogar u oficina, ¿qué haría primero: poner un candado en la puerta o invertir en cámaras y sistemas de videovigilancia? Por supuesto, primero instale la cerradura de la puerta es lo más fácil y efectivo de hacer. Eso es handle de acceso y el ejemplo perfecto de una medida preventiva eficaz.

Es bueno tener varias capas de defensa, por lo que es posible que desee agregar videovigilancia en todas las puertas. Pero siempre debe priorizar el command de acceso sobre las herramientas de observación. Lo mismo se aplica a la protección de sus entornos de Kubernetes.

Liz Rice es vicepresidenta de ingeniería de código abierto con los especialistas en seguridad nativa de la nube Aqua Stability, y se ocupa de proyectos que incluyen Starboard, Trivy, Tracee, kube-hunter y kube-bench. Es presidenta del Comité de Supervisión Técnica de la CNCF y fue copresidenta de KubeCon + … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia initial