La mejor manera de detectar amenazas en la nube
Muchas organizaciones, y la industria en general, todavía tienen desafíos para definir qué es lo bueno en la detección de amenazas en general. Aquí tenemos una necesidad más limitada de definir qué aspecto tiene la detección de amenazas en la nube . Por eso, queremos formular dimensiones aproximadas e imperfectas de una buena detección de amenazas para la computación en la nube pública.
Directrices aproximadas para una buena detección de amenazas en la nube
Ciertamente, una buena detección de amenazas en la nube debe apuntar a amenazas realistas que afecten los entornos de nube pública . Muchas organizaciones se enfrentan a grandes desafíos aquí, y los datos recientes indican que los entornos de nube se enfrentan a una combinación desconcertante de amenazas antiguas y nuevas (desde adivinar contraseñas al estilo de la década de 1980 hasta escapes de contenedores de la década de 2020). No es probable que la simple replicación de los controles de detección de amenazas del centro de datos que funcionaron bien en las instalaciones en la nube conduzca a la grandeza , o incluso a la bondad en la detección. Con la nube, vienen nuevas capas de exposición y control de seguridad (y enormes ventajas de seguridad ), por lo que incluirlas en la planificación de detección es crucial para el éxito.
Naturalmente, una buena detección de amenazas en la nube tiene en cuenta las propiedades de la computación en la nube , como el escalado, la naturaleza efímera, las API y se enfoca en la criticidad de la capa de identidad en la nube .
Si bien son organizaciones con huellas mínimas en la nube, se espera que los controles de detección de amenazas en la nube tengan que ofrecer una mayor eficacia con respecto a los «falsos positivos», dados los volúmenes de telemetría más altos y crecientes . Después de todo, el 1 % de falsos positivos por megabytes de datos puede haber sido aceptable. Los mismos porcentajes no funcionarían para los controles de detección automatizados en petabytes de datos, especialmente en nuestro mundo donde los humanos capacitados en detección son escasos .
Como mencionamos muchas veces, los tipos de datos de origen para la detección en la nube están cambiando o al menos se está reequilibrando su importancia . A largo plazo, los controles de detección centrados en la red que se basan en la captura de paquetes y los metadatos de tráfico probablemente perderán importancia debido al crecimiento del cifrado y el ancho de banda. Esto significa que, en última instancia, los registros, los datos de observabilidad y varias técnicas de detección que se basan en el acceso del proveedor de la nube al backplane serán más importantes.
De manera similar, el papel de la telemetría de punto final, como EDR , disminuirá a medida que las organizaciones adopten tecnologías nativas de la nube y los puntos finales comiencen a desaparecer. Hoy en día, muchas organizaciones implementan agentes en entornos de nube, al menos en máquinas virtuales y, a veces, en contenedores. Se espera que la popularidad de estos agentes disminuya a medida que más organizaciones cambien a microservicios e incluso más SaaS. Incluso donde los servidores permanecen, predecimos un crecimiento en los enfoques sin agentes dada su menor sobrecarga operativa tanto para las cargas de trabajo del servidor como para los equipos de seguridad.
Mientras estamos en el tema de realizar la detección desde el plano posterior del proveedor de la nube, surge la cuestión de la durabilidad de los controles de detección contra la interferencia del atacante . Los controles basados en agentes que se implementan en el entorno comprometido, como EDR, siempre tuvieron esto como un riesgo potencial. En la nube, tenemos la oportunidad de instrumentar controles de detección con una posibilidad mucho menor de interferencia de atacantes , como VMTD.
Naturalmente, también existe un grado de reequilibrio entre los controles de detección que se consideran auxiliares frente a los que se consideran primarios en comparación con los entornos locales. Por ejemplo, todos destacan el papel de la identidad en la nube; por lo tanto, las personas tratan los registros de actividad de identidad como una fuente principal para la detección de amenazas, mientras que, digamos, los datos de flujo se vuelven auxiliares para muchos.
Finalmente, aunque quiero que las detecciones sean siempre transparentes (y para ML, al menos explicables), otros no están de acuerdo . Encontremos el ángulo en el que todos parecían estar de acuerdo: es mejor que quien necesite usarlas confíe en las detecciones .
¿Qué ventaja tiene un proveedor de nube (CSP) en el desarrollo/operación de sistemas de detección y contenido?
- Proximidad de procesamiento: CSP no tiene costos de salida/retorno de red para datos sin procesar y señales en los sistemas de detección. Esto proporciona un beneficio económico y beneficios de latencia y durabilidad: menos saltos en un sistema significa una detección de extremo a extremo más rápida y menos señales caídas y costos inesperados.
- Mejor integración de sistemas: CSP tiene una oportunidad única de conectarse a la infraestructura relacionada y de soporte para detectar amenazas con señales que de otro modo no se externalizarían por razones de privacidad/seguridad/rendimiento.
- Alerta avanzada/detección temprana: CSP puede trabajar con equipos internos para desarrollar la detección de vulnerabilidades y problemas embargados; también puede confiar en la amplia conciencia de amenazas del proveedor de la nube.
- Acceso a equipos ascendentes en el proveedor de la nube: los equipos de detección de amenazas de CSP pueden trabajar con equipos internos para modificar sistemas a fin de producir señales adicionales necesarias para la detección, como agregar anotaciones a un registro o incorporar un LSM en una distribución de Linux.
- Mayor resiliencia frente a atacantese invisibilidad del control de detección; La instrumentación de CSP es invisible tanto para los desarrolladores de los clientes como para los adversarios.
¿Qué ventajas tiene un proveedor externo en el desarrollo/operación de sistemas de detección y contenido
- Aplicabilidad más amplia: un CSP que desarrolla para su nube tiene una pieza de software muy particular que se adapta a las peculiaridades de esa nube, pero requiere un cambio de mentalidad para trabajar en tecnologías de terceros. Un tercero tiene una visión de enfoque más amplia al desarrollar para todas las nubes.
- Mejor cobertura multinube: se acepta ampliamente que una visión más unificada de las actividades de detección y una mejor cobertura entre los CSP se logra mejor mediante un tercero, no uno de los CSP (sin embargo, estamos muy lejos de «una regla de detección para múltiples situación de las nubes de todos modos)
- Ventaja de confianza percibida a través de la separación de funciones: algunos usuarios de la nube prefieren separar el operador del entorno del operador de detección, ya que consideran que este enfoque es más confiable en principio.
- Agilidad superior: algunos creen que una startup más pequeña y enfocada desarrollará detecciones más rápido y abordará las necesidades verticales de los clientes con más agilidad.
- Menos presión de confiabilidad: se acepta, si no es aceptable, que las herramientas de terceros pueden presentar problemas de rendimiento. Es inaceptable que un CSP cause un problema de rendimiento en su propio jardín.
¿Qué ventajas tiene un cliente al desarrollar/operar sistemas de detección y contenido?
- Modelo de amenazas preciso: naturalmente, los clientes conocen mejor sus amenazas; en teoría, esto significa que pueden desarrollar las mejores detecciones (en la práctica, muchos carecen de las habilidades de ingeniería de detección necesarias)
- Conocimiento comercial/vertical: de manera similar, los clientes también poseen un conocimiento superior de sus negocios, activos y detalles específicos de la industria. Para algunas amenazas, donde el conocimiento del entorno es más importante que el conocimiento de la amenaza, las detecciones personalizadas o creadas por el cliente son el único camino a seguir.
Ahora, un lector cuidadoso de nuestra publicación tendrá la sensación de que estamos defendiendo la idea de que la mejor detección de amenazas en la nube tendrá que ser creada por el propio proveedor de la nube, esencialmente el propietario de una plataforma en la nube . Para algunos, esto sería similar a decir que el proveedor del sistema operativo creará la mejor detección para un sistema operativo en particular porque «es su sistema operativo» y «ellos lo conocen mejor». Naturalmente, todos sabemos que esto no es realmente cierto en la vida real. Entonces, ¿por qué sería cierto en la nube?
Esta vez es realmente diferente: cuando la gente construyó nuestro sistema operativo y pilas de hardware (el desarrollo de Unix comenzó en 1969, Windows NT en 1989, nuestro conjunto de instrucciones x86 data de los años 70) estábamos mucho menos preocupados por la seguridad de lo que estamos hoy. Como proveedor de la nube, diseñamos la seguridad en nuestros cimientos mucho antes, con el conocimiento de que teníamos un cambio generacional en los cimientos de la computación y motivados por décadas de fallas de seguridad y una oportunidad generacional limpia para cambiar los resultados de seguridad.
Por lo tanto, el argumento no se basa en la «propiedad de la plataforma», sino en el hecho de que el pensamiento de seguridad estuvo presente durante el día 1, tal vez incluso el día «-100», cuando los sistemas aún estaban siendo concebidos y diseñados. ¡Esto importa!
Entonces, nuestra conclusión: tenemos la hipótesis de que, en última instancia, la ruta CSP ganará naturalmente como el mejor lugar para obtener detecciones de nubes . Nuestra impresión es que estar cerca de una plataforma en la nube diseñada de forma segura y tener factores superiores de conocimiento de la plataforma (y las amenazas) superará a los demás. Pero, definitivamente curioso por ver cómo evoluciona esto…
Fuente: Security Boulevard