Ciberseguridad

Cinco cosas que los CISO necesitan saber sobre EDR

La detección y respuesta protege los dispositivos bloqueando automáticamente las amenazas, si se configura correctamente.

endpoint

La detección y respuesta de dispositivos (EDR, de sus siglas inglesas) es un enfoque de protección que monitoriza los terminales en una red y bloquea las amenazas a medida que se identifican. Como cualquier otro producto de ciberseguridad, solo puede proteger una red si se configura y prueba adecuadamente. Y hay cinco cosas que los CISO deben saber sobre estas plataformas:

 

La EDR se puede eludir

Lo primero, y posiblemente lo más importante, que hay que entender acerca de EDR es que no es una solución inmediata que resolverá todos los problemas de seguridad de sus terminales. A pesar de lo que los departamentos de marketing y las diversas empresas de investigación de mercado quieran hacerle creer, la EDR puede ser derrotada, y en ocasiones de forma bastante trivial. Hay innumerables formas diversas en las que se puede evadir un EDR, ya sea mediante una interrupción de los sensores, una implementación de una técnica que subvierte la lógica de detección del EDR, mezclándose con el comportamiento normal del sistema o rompiendo la cadena de comunicación entre el endpoint y el servidor de recopilación central.

EDR tiene un trabajo difícil. Esperamos que sea capaz de detectar todas las herramientas que un adversario puede usar contra nuestros puntos finales, tanto conocidas como desconocidas, y al mismo tiempo ser perfectamente correcto en no introducir demasiados falsos positivos, lo que genera fatiga de alerta en el centro de operaciones de seguridad (SOC). Eso sí, deben equilibrar todo eso además de ser fáciles de usar e implementar, eficaces, seguros y con un precio competitivo para que el proveedor pueda vender su producto. Si simplemente moderamos nuestras expectativas sobre EDR y entendemos que, si bien ahora es la mejor herramienta para monitorear la actividad de los endpoints, no puede captar todo de manera inmediata, podemos comenzar a mejorar nuestro uso y extraer más valor.

 

No es un antivirus

El mercado de protección de terminales y la forma en que se denominan los productos puede resultar confuso. A pesar de la lista cada vez mayor de nombres y acrónimos, en realidad solo existen dos familias de productos de detección: antivirus y EDR. El antivirus generalmente se centra en detectar artefactos (normalmente malware basado en archivos). EDR, por otro lado, se centra en detectar comportamientos. Si bien la mayoría de las soluciones EDR hoy en día implementan algún tipo de antivirus, su principal preocupación es detectar lo que sucede después de que se detona el malware, como la actividad posterior a la explotación.

El enfoque de EDR en el comportamiento es lo que lo hace tan poderoso. Muchas amenazas modernas han evolucionado para no requerir la introducción de artefactos en el sistema que serían detectados por el antivirus, como el malware sin archivos. En estas situaciones, debemos poder investigar comportamientos en el sistema en busca de patrones que indiquen la presencia de un actor malicioso. Este es el verdadero valor de EDR: poder consultar y correlacionar comportamientos entre sistemas, ya sea para buscar compromisos activos o crear detecciones proactivas. Tratar nuestro EDR únicamente como una herramienta para detectar malware colocado en el disco nos impide extraer gran parte de su valor.

 

La cobertura de la flota importa

No puedo comenzar a decirles cuántas veces, en mi época como operador del equipo rojo, comprometí una estación de trabajo e inmediatamente salté a un servidor únicamente porque EDR no estaba implementado allí. Al discutir el tema de la cobertura de flota limitada con esos clientes, encontré muchas razones de por qué es así. Sin embargo, independientemente de esas razones, la recomendación es la misma: necesita la cobertura más completa posible cuando se trata de su implementación de EDR. Ciertamente habrá excepciones, como sistemas operativos no compatibles, recursos del sistema limitados, funciones comerciales críticas, pero lo predeterminado debería ser instalar el agente EDR y las excepciones se deberían hacer sistema por sistema.

El razonamiento detrás de esto tiene sentido si volvemos a considerar cuál es el propósito de EDR, es decir, recopilar e informar eventos que ocurren en un terminal. Imagine que tiene tres sistemas: estación de trabajo, servidor y una base de datos que contiene las "joyas de la corona" de su organización. Ha implementado EDR en la estación de trabajo porque es casi seguro que ese sistema estará sujeto a intentos de acceso inicial. También implementó EDR en la base de datos porque es el sistema más importante de todo su entorno. Mientras tanto, EDR no se implementó en el servidor por una razón u otra.

Durante una infracción, el adversario compromete una estación de trabajo y opera por debajo del umbral de detección del EDR. Descubren que tienen privilegios suficientes para migrar al rango de servidores y saltan al sistema del servidor. En el servidor, son efectivamente libres de hacer lo que quieran desde una perspectiva de detección, por lo que esta se convierte en su nueva cabeza de playa. A través del reconocimiento, descubren que pueden conectarse a la base de datos para extraer información de alto valor y exfiltrarla. Se inicia la respuesta a incidentes (IR) y ven muy claramente el acceso inicial, las acciones posteriores a la explotación e incluso el salto de la estación de trabajo al servidor, pero luego descubren que no hay datos para el servidor porque no había EDR. instalado y el sendero se seca.

Ahora el proceso de determinar el alcance y el impacto de una infracción, así como de erradicar a los actores residentes, se vuelve sustancialmente más difícil. Si se instaló EDR en el servidor, el equipo de seguridad interna podría haber respondido proactivamente para reducir el impacto y/o IR podría haber armado la cadena de ataque del adversario de manera más rápida y precisa para mejorar la eficacia de la remediación.

 

Lo que debes sumar a tu EDR

Cada EDR viene con alguna lógica de detección incorporada. Algunos proveedores incluso llegan a tener un período de referencia en el que el EDR se normaliza para su entorno (por ejemplo, un proceso que accede a LSASS puede ser normal en su entorno pero nunca sucederá en otra empresa). Si bien este es un excelente punto de partida, podemos hacer más. La lógica de detección incluida por el proveedor sólo debe verse como un punto de partida. No comprende las complejidades de su entorno, la sensibilidad de ciertos hosts o grupos de sistemas, las piezas estratégicamente importantes de su red o las inquietudes específicas que pueda tener. Para ello, debemos recurrir a la ingeniería de detección.

Históricamente, las reglas de detección han sido un juego de golpear al topo debido a su naturaleza precisa. Por ejemplo, una detección de Mimikatz, una herramienta utilizada para extraer credenciales de sistemas Windows, consistiría en simplemente buscar procesos llamados "mimikatz.exe". Esta lógica es trivial de evitar, si un atacante cambia el nombre de "mimikatz.exe" a "mimidogz.exe", por ejemplo, y necesita ser complementado con algo más robusto. Debido a que EDR tiene conexiones tan profundas con el sistema operativo a través de sus innumerables sensores, tenemos todos los datos para encontrar un comportamiento similar a Mimikatz sin necesidad de buscar a Mimikatz específicamente.

Si nuestra lógica de detección busca la funcionalidad principal de una técnica determinada, como abrir un identificador suficientemente privilegiado para lsass.exe y leer su memoria, podemos capturar más de una variación de su implementación. Esto significa que una única regla de detección puede proporcionar cobertura a nivel de procedimiento para Mimikatz y herramientas similares, incluidas SafetyKatz o Invoke-Mimikatz. Esta extensibilidad es una funcionalidad central de cada EDR que vale la pena comprar hoy.

 

Pruebe su EDR

¿Cómo sabe que su EDR puede detectar las cosas que dice hacer? ¿Cómo sabe que eso es válido en todas las versiones del sistema operativo, el agente EDR y la configuración de políticas? ¿Se aplica esto a todos los hosts de su entorno? ¿Será eso cierto la próxima semana y la siguiente? Debemos poner a prueba nuestras suposiciones sobre nuestra EDR para tener plena conciencia de la situación y realizar aprobaciones significativas.

Hay muchas formas de probar las detecciones y algunas son más específicas que otras. El primero que te puede venir a la mente es Red Teaming, que es un servicio diseñado para probar tus detecciones y ejercitar tus procedimientos de respuesta a incidentes. Si bien esta es una forma completamente válida de probar sus defensas, no proporciona cobertura de prueba para todas sus detecciones y es solo una evaluación de un momento dado.

Otro estilo son las pruebas "atómicas". Esto implica el uso de pruebas diseñadas específicamente para emular algún comportamiento (más comúnmente asignado a MITRE ATT&CK ) para estimular las defensas de una manera calculada para que la EDR pueda evaluarse más directamente. La desventaja de este enfoque es que la calidad del corpus de prueba es difícil de medir y la mayoría de las soluciones no se diseñan de forma continua o a escala. Estos enfoques de prueba aportan un valor inmenso a su programa de seguridad al probar suposiciones y ejercer defensas. Independientemente del enfoque que priorice, lo más importante es evaluar la eficacia y solidez de sus detecciones y mejorar cualquier deficiencia encontrada utilizando el rico conjunto de datos proporcionado por su EDR.

 



TE PUEDE INTERESAR...

Accede a la cobertura de nuestros encuentros
 
Lee aquí nuestra revista digital de canal

DealerWorld Digital

 

Forma parte de nuestra comunidad
 
¿Interesado en nuestros foros? 

 

Whitepaper

Documento Pure Storage y Kyndryl INFRAESTRUCTURAS