2.2.2.1.-Qué es un SIEM
2.2.2. ¿Qué es un SIEM?¶
En este documento se describe, de forma progresiva, qué es un SIEM y cómo encaja en el trabajo diario de un SOC: desde la recogida de logs hasta la generación de alertas y la conexión con la gestión de incidentes.
Fuente y alcance
El contenido está basado en varias lecciones de LetsDefend (SIEM 101). Se mantiene la información e imágenes originales del documento de partida y se reorganiza para que el temario sea más fácil de seguir.
Fuente
https://app.letsdefend.io/training/lesson_detail/siem-introduction
1. Introducción a SIEM¶
La gestión de eventos e información de seguridad (SIEM) es una solución de seguridad que recopila e interpreta datos dentro de la organización y luego detecta amenazas potenciales. Gracias a SIEM, las amenazas de seguridad se pueden monitorear en tiempo real. En esta capacitación, explicaremos cómo funciona un SIEM en general. Sin profundizar demasiado, le proporcionaremos suficiente información para que el analista de SOC comprenda lo que sucede detrás de escena. Al final de la capacitación, tendrá una comprensión general de los siguientes temas:
- ¿Cómo funciona SIEM?
- ¿Cómo recopila SIEM los registros?
-
Almacenamiento de registros
-
Creación de alertas
1.1. Productos SIEM¶
Hay muchas soluciones SIEM en el mercado. Según el informe de Gartner 2021, las soluciones SIEM comerciales más exitosas son las que se muestran en la imagen a continuación.
1.2. Analista SIEM y SOC¶
Los analistas de SOC revisan las posibles amenazas detectadas con SIEM. Por ejemplo, puede pensar en las alertas de la página Monitoreo de LetsDefend como alertas creadas por SIEM.
Fuente
https://app.letsdefend.io/training/lesson_detail/log-collection
2. Recopilación de registros¶
En primer lugar, necesitamos datos para que la solución SIEM detecte amenazas. Es por eso que el proceso de recopilación de registros es una de las partes más importantes de la arquitectura SIEM, porque sin el registro, SIEM sería inútil.
2.1. Conceptos: log y logging¶
En informática, un archivo de Log es un archivo que registra eventos que ocurren en un sistema operativo u otras ejecuciones de software, o mensajes entre diferentes usuarios de un software de comunicación. Logging es el acto de mantener un log (registro). En el caso más simple, los mensajes se escriben en un solo archivo de log. definición: wikipedia.org
Contiene un registro básico, hora, sistema fuente y un mensaje. Por ejemplo, cuando observamos el contenido del archivo "/var/log/auth.log" en un servidor Ubuntu, podemos ver la fuente, la hora y la información del mensaje.
Nuestro objetivo en este punto es transferir registros desde varios lugares (hosts, firewall, registro del servidor, proxy, etc.) a SIEM. Así, podemos procesar todos los datos y detectar amenazas en un punto central.
2.2. Métodos de recopilación¶
Los registros generalmente se recopilan de las siguientes 2 maneras:
- Agentes de registro
- Sin agente
2.2.1. Agentes de registro¶
Para implementar este método, se requiere un software de agente de registro. Los agentes suelen tener funciones de análisis, rotación de registros, almacenamiento en búfer, integridad de registros, cifrado y conversión. En otras palabras, este software de agente puede actuar sobre los registros que recopila antes de reenviarlos al destino. Por ejemplo, con el software del agente, podemos dividir un registro con "nombre de usuario: User1; cuenta: Administrador" en 2 partes y reenviarlo como:
- mensaje1 = "nombre de usuario: User1"
- mensaje2 = "cuenta: Administrador"
2.2.1.1. Ventajas del método¶
- Es una aplicación probada y funcional por parte de los desarrolladores.
- Tiene muchas características adicionales como análisis automático, encriptación, integridad de registro, etc.
2.2.1.2. Contras del método¶
- A medida que se activan las funciones adicionales, aumenta el consumo de recursos. Eso requiere que se aumenten los recursos del sistema, como la CPU y la RAM, por lo que el costo aumenta.
2.2.2. Syslog¶
Es un protocolo de red muy popular para transferencias de registros. Puede funcionar tanto con UDP como con TCP y, opcionalmente, puede cifrarse con TLS. Algunos dispositivos que admiten syslog: conmutadores, enrutadores, IDS, cortafuegos, Linux, Mac, dispositivos Windows pueden volverse compatibles con syslog con software adicional.
Puede hacer que sus agentes de registro transfieran registros con Syslog. Para esto, primero debe analizar sus registros en formato syslog.
2.2.2.1. Formato de registro del sistema¶
Marca de tiempo - Dispositivo de origen - Instalación - Gravedad - Número de mensaje - Texto del mensaje
Además, el tamaño máximo de paquete que se puede enviar con Syslog UDP es de 1024 bytes. Para TCP es de 4096 bytes.
2.2.4. Agentes de terceros¶
La mayoría de los productos SIEM tienen su propio software de agente. Los agentes de terceros tienen más capacidades que syslog debido a las funciones que admiten. Algunos agentes:
- Splunk: promotor universal
- ArcSight: Conectores de ArcSight
Estos agentes son fáciles de integrar en SIEM y tienen funciones de análisis.
2.2.4.1. Agentes de código abierto populares¶
- Latidos https://www.elastic.co/beats/
- NXLog https://nxlog.co/
2.2.5. Sin agente (agentless)¶
A veces se prefiere el proceso de envío de registros sin agentes, ya que no hay costos de instalación y actualización. Por lo general, los registros se envían conectándose al destino con SSH o WMI. Para este método, se requieren el nombre de usuario y la contraseña del servidor de registro, por lo que existe el riesgo de que la contraseña sea robada. Más fácil de preparar y administrar que el método del agente. Sin embargo, tiene capacidades limitadas y las credenciales están envueltas en la red.
2.2.5.1. Recolección manual¶
A veces, hay registros que no puede recopilar con el software de agente existente. Por ejemplo, si no puede leer los registros de una aplicación basada en la nube con el agente, es posible que deba escribir su propio script.
En definitiva, hay varias formas de recopilar registros. Estos son, con agentes y sin agente. En los casos en que los agentes del mercado no sean suficientes, debe escribir sus propios guiones.
Fuente
https://app.letsdefend.io/training/lesson_detail/log-aggregation-and-parsing
3. Agregación y análisis de registros¶
El primer lugar donde se envían los registros generados es el agregador de registros. Podemos editar los registros que vienen aquí antes de enviarlos al destino. Por ejemplo, si queremos obtener solo códigos de estado de los registros de un servidor web, podemos filtrar entre los registros entrantes y enviar solo las partes deseadas al destino.
3.1. Agregador y EPS¶
3.1.1. ¿Qué es EPS?¶
EPS es un evento por segundos. La fórmula es Eventos/Período de tiempo de segundos. Por ejemplo, si el sistema recibe 1000 registros en 5 segundos, EPS sería 1000/5 = 200. A medida que aumenta el valor de EPS, también aumenta el agregador y el área de almacenamiento que se debe utilizar.
3.1.2. Escalado del agregador¶
Se puede agregar más de un agregador para que los registros entrantes no carguen el mismo agregador cada vez. Y se puede proporcionar una selección secuencial o aleatoria.
3.1.3. Proceso del agregador de registros¶
El registro que llega al Agregador se procesa y luego se dirige al destino. Este proceso puede ser análisis, filtrado y enriquecimiento.
3.1.4. Modificación de registros¶
En algunos casos, debe editar el registro entrante. Por ejemplo, mientras que la información de fecha de la mayoría de los registros que recopila tiene el formato dd-mm-aaaa, si proviene de una sola fuente como mm-dd-aaaa, querrá convertir ese registro. Otro ejemplo, es posible que necesite convertir la información de hora entrante UTC + 2 a UTC + 1.
3.1.5. Enriquecimiento de registros¶
El enriquecimiento se puede realizar para aumentar la eficiencia de los registros recopilados y ahorrar tiempo. Ejemplos de enriquecimientos:
Por ejemplo agregar o eliminar información a registros de geolocalización y DNS
3.1.5.1. Geolocalización¶
La geolocalización de la dirección IP especificada se puede encontrar y agregar al registro. Por lo tanto, la persona que ve el registro ahorra tiempo. También le permite analizar el comportamiento basado en la ubicación.
3.1.5.2. DNS¶
Con las consultas de DNS, se puede encontrar la dirección IP del dominio o se puede encontrar la dirección IP haciendo DNS inverso.
Fuente
https://app.letsdefend.io/training/lesson_detail/log-storage
4. Almacenamiento de registros¶
Una vez que hemos enriquecido los registros, como vimos en el punto anterior, el siguiente paso es almacenar los registros entrantes.
Uno de los errores comunes que se cometen en las estructuras SIEM es centrarse en el tamaño del almacenamiento. El almacenamiento de gran tamaño es importante, así como la velocidad de acceso a estos datos. Por ejemplo, digamos que recopilamos todos los registros como WAF, Firewall, Proxy, etc. e imaginemos que se tarda 15 minutos en realizar una búsqueda en estos registros. En una situación en la que es tan difícil acceder a los datos, los estudios no serán muy productivos. Por este motivo, la velocidad de acceso a los datos también debe tenerse en cuenta en el almacenamiento.
Cuando observamos las tecnologías de almacenamiento populares en el mercado (Ejemplo: mysql), vemos que se enfoca en agregar, editar y eliminar datos. Pero nuestro enfoque está en indexar los datos, no tenemos la intención de editar el registro almacenado más adelante. Nuestro propósito es acceder a los datos lo más rápido posible. Para esto, las tecnologías basadas en WORM (escribir una vez leer muchas) son más adecuadas para ser utilizadas en SIEM.
Más información sobre el gusano, escriba una vez, lea muchas: https://en.wikipedia.org/wiki/Write_once_read_many
Puede comprender la diferencia presionando el botón "Buscar" en las 2 áreas de almacenamiento diferentes a continuación.
Fuente
https://app.letsdefend.io/training/lesson_detail/alerting
5. Creación de alertas (alerting)¶
Hemos recopilado, procesado y almacenado registros hasta este momento. Ahora, necesitamos detectar comportamientos anormales utilizando los datos que tenemos y generar alertas.
La ocurrencia oportuna de alertas varía según nuestra velocidad de búsqueda. Para un registro creado hoy, queremos crear una advertencia inmediatamente en lugar de generar una alerta después de 2 días. Por lo tanto, como mencionamos en nuestro artículo anterior, se debe crear un entorno de almacenamiento adecuado. Las alarmas que crearemos para SIEM generalmente serán sospechosas y deben investigarse. Esto significa que la alerta debe optimizarse y no dispararse en grandes cantidades (excepto en casos excepcionales). Estas son algunas formas de crear una alerta:
- Mediante la búsqueda de datos almacenados
- Crear alarmas mientras se toman registros
Ejemplos de alertas que se pueden crear:
- Nuevo usuario agregado al administrador global
- 15 Error de inicio de sesión en 3 minutos con la misma dirección IP
Para crear una alerta de calidad, debe comprender los datos que tiene. Algunas de las técnicas para realizar mejores búsquedas de registros son las listas negras, las listas blancas y el análisis de registros de cola larga.
5.1. Lista negra¶
Se puede utilizar para detectar situaciones no deseadas. Por ejemplo, podemos recopilar los nombres de procesos prohibidos (Ejemplo: mimikatz.exe) y escribirlos en una lista. Luego, si un proceso de esta lista aparece en los registros, podemos crear una alerta. Del mismo modo, se puede generar una alerta cuando hay un dispositivo que crea y accede a una lista de IP prohibidas. Es fácil de administrar e implementar, pero muy fácil de eludir. Por ejemplo, si se usa el nombre mimikatz2.exe en lugar de mimikatz.exe, no se producirá ninguna alerta.
5.2. Lista blanca¶
A diferencia de la lista negra, se usa para situaciones deseadas. Por ejemplo, se puede mantener una lista de direcciones IP con comunicación normal. Si la comunicación se realiza con una dirección diferente a esta lista, podemos generar una alerta. Este método es altamente efectivo pero difícil de manejar. La lista debe actualizarse constantemente.
5.3. Análisis de registro de cola larga¶
Este método asume que los comportamientos que ocurren constantemente son normales. En otras palabras, si un registro de "Evento ID 4624 Se inició sesión correctamente en una cuenta" se produce constantemente en un dispositivo, con este método debemos tomarlo como normal y abordar los registros menos frecuentes con sospecha.
imagen: https://respond-software.com/
Buena publicación sobre el análisis de registros de cola larga: https://threatpost.com/long-tail-analysis-hope-cybercrime-battle/155992/ Puede detectar situaciones sospechosas y crear alertas utilizando estos 3 métodos.
Fuente
https://app.letsdefend.io/training/lesson_detail/introduction-to-incident-management
6. Introducción a la gestión de incidentes¶
El Centro Nacional de Seguridad Cibernética (NCSC) define un incidente cibernético como una violación de la política de seguridad de un sistema para afectar su integridad o disponibilidad y/o el acceso no autorizado o intento de acceso a un sistema o sistemas; de acuerdo con la Ley de Uso Indebido de Computadoras.
En nuestra capacitación anterior sobre SIEM 101, hablamos sobre cómo se recopilan los datos y se convierten en alertas dentro del SOC. Si aún no ha completado esa capacitación, le recomendamos que la complete haciendo clic en el enlace y luego continúe desde aquí. Una de las plataformas donde se recopilan e investigan las alertas en SIEM es el “Sistema de Gestión de Incidencias”.
En la continuación de esta capacitación, explicaremos cómo funciona un Sistema de gestión de incidentes y por qué y cómo utilizar estos sistemas como analistas de SOC.
Fuente
https://app.letsdefend.io/training/lesson_detail/basic-definitions-about-incident-management
6.1. Definiciones básicas sobre la gestión de incidentes¶
En este apartado te explicaremos los conceptos básicos que necesitas saber sobre la gestión de incidencias. Dado que encontrará estos conceptos con frecuencia durante su educación y su rutina laboral diaria, le recomendamos que los comprenda a fondo:
- Alerta
- Evento
- Incidente
-
Verdadero Positivo
-
Falso positivo
6.1.1. Alerta¶
Hablamos sobre cómo se crea una alerta en el módulo de capacitación SIEM. Puede hacer clic en el enlace (https://app.letsdefend.io/training/lessons/siem-101) para acceder a la formación. Para recordar brevemente, se genera una alerta como resultado de la recopilación y el procesamiento de datos (análisis, enriquecimiento, etc.) en SIEM, como se ve en la imagen a continuación. Luego, iniciamos el proceso de análisis enviando las alarmas generadas al Sistema de Gestión de Incidencias.
6.1.2. Evento¶
Un evento es cualquier ocurrencia observable en un sistema o red. Simplemente, los eventos son actividades como un usuario que se conecta a un archivo compartido, un servidor que recibe una solicitud de una página web, un usuario que envía correo electrónico (e-mail), un firewall que bloquea un intento de conexión, etc.
6.1.3. Incidente¶
La definición de un incidente de seguridad informática ha evolucionado con el tiempo. En el pasado, un incidente de seguridad informática se consideraba un evento adverso relacionado con la seguridad en el que se producía una pérdida de la confidencialidad de los datos, una interrupción de la integridad de los datos o del sistema, o una interrupción o denegación de disponibilidad.
Desde entonces, han surgido muchos tipos nuevos de incidentes de seguridad informática, y esto requería una definición más amplia de "incidente". Generalmente, un incidente es una violación o amenaza inminente de violación de las políticas de seguridad informática, las políticas de uso aceptable o las prácticas de seguridad estándar. Definiciones: Publicación especial NIST 800-61
6.1.4. Alerta de verdadero positivo¶
Si la situación que se va a detectar y la situación detectada (alerta desencadenada) son las mismas, se trata de una alerta de verdadero positivo. Por ejemplo, supongamos que se hizo una prueba de PCR para saber si es positivo para Covid19 y el resultado de la prueba fue positivo. Es Verdadero Positivo porque la condición que desea detectar (si tiene la enfermedad de Covid19) y la condición detectada (ser un paciente de Covid19) son las mismas. Esta es una verdadera alerta positiva.
Supongamos que hay una regla para detectar ataques de inyección SQL y esta regla se ha activado debido a una solicitud que se realizó a la siguiente URL. La alerta es de hecho un "Verdadero positivo" ya que hubo un ataque de inyección SQL real.
6.1.5. Alerta de falso positivo¶
En resumen, es una falsa alarma. Por ejemplo, hay una cámara de seguridad en tu casa y si la cámara te alerta por los movimientos de tu gato, es una alerta de falso positivo.
Si observamos el ejemplo de URL a continuación, vemos la palabra clave "Unión" del parámetro SQL dentro de esta URL. Si se produce una alerta de inyección SQL para esta URL, será una alerta de falso positivo porque la palabra clave "Unión" se usa para mencionar un equipo deportivo aquí y no para un ataque de inyección SQL.
Para comprender mejor las definiciones, puede comparar los términos y definiciones en una sola tabla de la siguiente manera:
img fuente:hacia la ciencia de los datos.com
Fuente
https://app.letsdefend.io/training/lesson_detail/incident-management-systems-ims
6.2. Sistemas de gestión de incidentes (IMS)¶
Los sistemas de gestión de incidentes es donde los equipos SOC llevan a cabo el proceso de investigación y registran las acciones tomadas cuando ocurre un incidente. Por esta razón, los analistas de SOC pasan una parte importante de su tiempo en la interfaz de estos sistemas.
Un ejemplo de IMS es el proyecto de código abierto TheHive.
De manera similar, la "Gestión de casos" en LetsDefend se puede dar como un ejemplo para los Sistemas de gestión de incidentes.
6.2.1. ¿Cómo funciona un IMS?¶
Para abrir un registro en la plataforma de Gestión de Incidencias, primero se debe proporcionar una entrada de datos aquí. Estos datos pueden provenir directamente del SIEM o de otros productos de seguridad. Una vez que se establece el flujo de datos, se crea un ticket/caso en el Sistema de gestión de incidentes.
Si se establecen integraciones con "Threat Intelligence", "SOAR" y plataformas similares, los datos dentro del caso se enriquecen y esto ayuda a responder rápidamente. Por ejemplo, supongamos que hay un dominio sospechoso "letsdefend.io" en el incidente. Si existe una integración entre IMS y la plataforma de inteligencia de amenazas, la reputación de la dirección de dominio "letsdefend.io" se consulta automáticamente y se proporciona al analista de SOC. Si no hay una integración de la plataforma de inteligencia de amenazas, se requiere una consulta manual de las plataformas de código abierto como Virustotal.
Además, los productos SOAR también ofrecen integración con otros productos de seguridad. Muchos productos SOAR pueden integrarse con productos como Firewall, IPS, WAF, Proxy, Email Gateway, Email Security. Si estamos seguros de que el dominio "letsdefend.io" es dañino y queremos evitar el acceso a esta dirección desde dentro de la organización, podemos bloquear rápidamente este dominio a través de un proxy con la ayuda de SOAR.
Considere el "Canal de Investigación" en la página de Monitoreo de LetsDefend. Se crea un nuevo "Caso" en "Administración de casos" cuando hacemos clic en el botón "Crear caso" aquí. En otras palabras, se crea un nuevo registro en el IMS.
Por último, puede consultar el panel de SIEM como analista de SOC:
Comience el recorrido interactivo
Generalmente, como vemos en la imagen a continuación, los detalles de alerta de SIEM se transmiten al Sistema de gestión de incidentes y el Sistema de gestión de incidentes funciona en coordinación con las plataformas Threat Intelligence y SOAR para procesar todos los datos y se crea un nuevo caso/ticket. Gracias a las integraciones de Threat Intelligence y SOAR en IMS, se proporciona enriquecimiento de datos y varias acciones. Finalmente, la alerta se cierra cuando se completan las operaciones.
Nota
Como mencionamos anteriormente, Incident Management System (IMS) es una de las plataformas en las que pasará la mayor parte de su tiempo como analista de SOC. Puede acortar significativamente su tiempo de investigación y deshacerse de sus tareas repetitivas si usa las plataformas IMS de manera efectiva. Por lo tanto, siempre debe llevar sus conocimientos y habilidades en las plataformas IMS al siguiente nivel.
Fuente
https://app.letsdefend.io/training/lesson_detail/case-alert-naming
6.3. Nombre del caso/alerta¶
Es importante que el ticket/caso/registros creados en el sistema de gestión de incidentes tengan un título significativo, ya que tener convenciones de nomenclatura unificadas ayudará en las consultas retrospectivas para encontrar rápidamente el registro relevante o extraer estadísticas fácilmente cuando se realiza una investigación. Por estas y otras razones, es necesario tener una idea del ticket/caso con solo mirar el título. Existen varios métodos para nombrar los tickets. El método de nomenclatura en LetsDefend "Gestión de casos" es el siguiente.
EventID: {Número de ID de alerta} - [{Nombre de alerta}]
Gracias a esta convención de nomenclatura, los analistas pueden acceder rápidamente a los detalles de la alarma a los que desean llegar, por ID o nombre de la alarma, mientras examinan los registros anteriores.
Cuando observamos ejemplos del mundo real, vemos que el formato de nomenclatura que describimos anteriormente es una práctica común en la industria. Además, en ocasiones pueden incluirse en el título los siguientes campos:
- Categoría de alerta
- Origen del evento
- Descripción
Fuente
https://app.letsdefend.io/training/lesson_detail/playbooks
6.4. Playbooks (libros de jugadas)¶
Hay muchos tipos diferentes de alertas (ataques web, ransomware, malware, phishing, etc.) en el entorno SOC. Los métodos y enfoques para investigar estas alertas son diferentes entre sí. Los flujos de trabajo preparados para un análisis eficaz y coherente de las alertas creadas en SIEM o en una herramienta de seguridad diferente se denominan playbooks.
Por ejemplo, cuando hace clic en el botón "Crear caso" para una alerta en la página de monitoreo de LetsDefend, se abre un ticket en "Administración de casos" y el sistema le asigna automáticamente un libro de jugadas. Para que pueda investigar la alerta con los pasos correctos siguiendo las instrucciones allí.
6.4.1. ¿Por qué son importantes los playbooks?¶
Como analistas de SOC, es posible que no siempre sepamos exactamente qué hacer cuando manejamos alertas. Podemos llevar a cabo el proceso de investigación paso a paso, gracias a las instrucciones del Playbook. Los Playbooks brindarán orientación, especialmente a los analistas que acaban de comenzar sus carreras en el campo SOC.
Mencionamos que los libros de jugadas guían a los analistas. Aparte de eso, permite que el equipo realice análisis con ciertos estándares. Por ejemplo, verificar si hay acceso a sitios C2/direcciones IP es vital después de analizar el malware. Sin embargo, es posible que algunos analistas no verifiquen el acceso a C2 todo el tiempo, mientras que otros sí lo hacen. Esto conduce a la inconsistencia en los estándares de trabajo del equipo. Es importante que todos los analistas creen y sigan manuales de estrategias para garantizar el mismo nivel de estándares de análisis dentro del equipo.
En el siguiente ejemplo, puede ver el flujo del libro de jugadas de phishing que Microsoft ha publicado.
Fuente
https://app.letsdefend.io/training/lesson_detail/what-does-the-soc-analyst-do-when-an-alert-occurs
6.5. Qué hace el analista SOC cuando ocurre una alerta¶
PD: Trabajas en LetsDefend individualmente, no como miembro de un equipo.
Después de tomar posesión de la alerta, verá que la alerta se ha reenviado al "Canal de investigación". Este canal tiene alertas en las que se está trabajando activamente. Haga clic en la alerta para obtener más detalles. Nuestro objetivo es determinar si esta alerta realmente contiene una situación dañina. En otras palabras, necesitamos determinar si es un falso positivo o un verdadero positivo. Para esto, podemos crear un registro en "Gestión de casos/Gestión de incidentes" haciendo clic en el botón "Crear caso" y luego siguiendo los pasos del libro de jugadas.
En las secciones anteriores, hablamos sobre cómo se produce una alerta. Como analista de SOC, su principal tarea es detectar amenazas para su organización. Por lo general, realiza esta tarea analizando las alertas creadas en SIEM o en un entorno diferente.
Las alertas que se producen no siempre indican un incidente real. A veces encontrará alertas de falsos positivos. De hecho, pasará la mayor parte de su tiempo lidiando con los falsos positivos, por lo que debe estar en comunicación constante con el equipo que crea las reglas SIEM y brindarles comentarios todo el tiempo. Como analista de SOC, debe profundizar en los detalles para comprender si una alerta es un falso positivo. No existe un método de análisis estándar, ya que puede haber diferentes tipos de alertas (web, malware, endpoint, etc.), y cada tipo tiene sus propios detalles específicos. Por lo tanto, es importante seguir los libros de jugadas en los sistemas de gestión de incidentes.
Demos un ejemplo sobre LetsDefend para una mejor comprensión. Como se ve en la imagen a continuación, hay muchas alertas en la página "Monitoreo". Como analistas debemos decidirnos y empezar por elegir una alerta.
Playbook te ofrece los pasos a seguir. Después de cerrar la alerta, le ayuda a verificar los resultados de su análisis a través de algunas preguntas.
Después de completar los pasos del libro de jugadas, será redirigido nuevamente a la página de Monitoreo. Ahora que ha terminado con el análisis, ahora necesita tomar una decisión final. ¿Esta alerta es un falso positivo o un verdadero positivo?
Después de realizar las selecciones y explicaciones necesarias, puede cerrar la alerta y ver los resultados de su análisis.
PD: en la vida real, es posible que no pueda verificar los resultados de su análisis todo el tiempo. A veces, puede trabajar con un analista senior y obtener ayuda al explicar los pasos que ha realizado, pero este no es un método sostenible. Por lo tanto, es una oportunidad para examinar los resultados del análisis de las alertas que ha cerrado en LetsDefend y aprender nuevos métodos.
Una vez cerrada la alerta, se dirigirá al canal "Alertas cerradas" y podrá consultar sus respuestas aquí.
Puede acceder al recorrido oficial en el área "Nota del editor", o puede acceder a los métodos de solución creados por la comunidad en el área "Recorrido de la comunidad".
Aunque no importa qué alerta inicie dentro del entorno de simulación, en la vida real debe priorizar las alertas con valores de gravedad altos.
Puede comenzar a trabajar en la alerta que ha elegido haciendo clic en el botón "Tomar posesión". La lógica del estándar de trabajo es que hay 10 alertas activas y usted está trabajando en la alerta con el número de EventID 63. Dado que otros miembros del equipo saben que está trabajando en esta alerta, elegirán una de las 9 alertas restantes y seguirán trabajando. Así, se asegura el trabajo en equipo para evitar la duplicación de trabajo.
Referencias y bibliografía¶
- LetsDefend SIEM introduction: https://app.letsdefend.io/training/lesson_detail/siem-introduction
- LetsDefend Log collection: https://app.letsdefend.io/training/lesson_detail/log-collection
- LetsDefend Alerting: https://app.letsdefend.io/training/lesson_detail/alerting
- LetsDefend Incident management (intro): https://app.letsdefend.io/training/lesson_detail/introduction-to-incident-management
- LetsDefend Basic definitions (IM): https://app.letsdefend.io/training/lesson_detail/basic-definitions-about-incident-management
- LetsDefend Incident management systems (IMS): https://app.letsdefend.io/training/lesson_detail/incident-management-systems-ims