CyberOps Associate: Módulo 26 – Evaluación de alertas

Última actualización: abril 1, 2022

26.0. Introducción

26.0.1. ¿Por qué deberíamos tomar este módulo?

Una habilidad crítica para un analista de ciberseguridad es la capacidad de evaluar alertas y decidir qué hacer con ellas. En este módulo, aprenderá de dónde provienen las alertas, los flujos de trabajo comunes asociados a las alertas y los métodos estándar para evaluar y clasificar las alertas.

26.0.2. ¿Qué aprenderemos en este módulo?

Título del módulo:: Evaluando Alertas

Objetivos del módulo: Explicar el proceso de evaluar alertas

26.1. Fuentes de las alertas

26.1.1. Security Onion

Security Onion es una suite de código abierto de herramientas de Monitoreo de la seguridad de la red (Network Security Monitoring, NSM) que se ejecuta en una distribución Ubuntu de Linux. Las herramientas de Security Onion ofrecen tres funciones principales para el análisis de ciberseguridad como la captura completa de paquetes y tipos de datos, sistemas de detección de intrusión basados en el host y basados en la red, y herramientas de análisis de alerta. Security Onion puede instalarse como una plataforma independiente o como una plataforma de sensor y servidor. Algunos de los componentes de Security Onion son propiedad de corporaciones que los mantienen, como Cisco y Riverbend Technologies, pero está disponible como una plataforma de código abierto.

Para obtener más información, y para obtener Security Onion, busque en Internet el sitio web de Security Onion.

Nota: En algunos recursos, es posible que vea Security Onion abreviado como SO En este curso, usaremos Security Onion.

26.1.2. Herramientas de detección para recopilar datos de alertas

Security Onion contiene muchos componentes. Es un entorno integrado diseñado para simplificar la implementación de una solución integral de NSM. En la figura, se ejemplifica una vista simplificada de la manera en que algunos de los componentes de Security Onion funcionan juntos.

Una arquitectura Security Onion

26.1.3. Herramientas de análisis

Security Onion integra estos diferentes tipos de datos y registros del sistema de detección de intrusiones (IDS) en una única plataforma mediante las siguientes herramientas:

• Sguil – Proporciona una consola de alto nivel para que los investigadores de ciberseguridad puedan investigar las alertas de seguridad a partir de una amplia variedad de fuentes. Sguil sirve como punto de partida para la investigación de alertas de seguridad. Hay disponible una amplia variedad de fuentes de datos para el analista de ciberseguridad si se utiliza Sguil directamente con otras herramientas.
• Kibana – Kibana es una interfaz interactiva para datos de Elasticsearch. Permite la consulta de datos de NSM y proporciona visualizaciones flexibles de esos datos. Proporciona funciones de exploración de datos y análisis de datos de aprendizaje automático. Es posible pivotar desde Sguil directamente a Kibana para ver pantallas contextualizadas basadas en las direcciones IP de origen y destino asociadas a una alerta. Busque en Internet y visite el sitio web elastic.co para obtener más información sobre las muchas características de Kibana.
• Wireshark – Es una aplicación de captura de paquetes que está integrada en el conjunto de productos de Security Onion. Puede abrirse directamente con otras herramientas y permite ver capturas de paquetes completos relevantes para un análisis.
• Zeek – Este es un analizador de tráfico de red que sirve como monitor de seguridad. Zeek inspecciona todo el tráfico en un segmento de red y permite un análisis detallado de esos datos. El giro de Sguil a Zeek proporciona acceso a registros de transacciones muy precisos, contenido de archivos y salida personalizada.

Nota: Las herramientas de Security Onion que no se ven en la figura están fuera del alcance de este curso. Una descripción completa de Security Onion y sus componentes puede ser encontrada en la página web de Security Onion.

26.1.4. Generación de alertas

Las alertas de seguridad son los mensajes de notificación que generan las herramientas, los sistemas y los dispositivos de seguridad de NSM. Las alertas pueden adoptar muchas formas según la fuente. Por ejemplo, syslog admite clasificaciones de gravedad que se pueden utilizar para alertar a los analistas de ciberseguridad sobre eventos que requieran atención.

En Security Onion, Sguil proporciona una consola que integra alertas de varias fuentes en una cola con marca de hora. Un analista de ciberseguridad puede navegar por la cola de seguridad investigando, clasificando, derivando o retirando alertas. En lugar de un sistema de administración del flujo de trabajo dedicado como Request Tracker for Incident Response (RTIR), un analista de ciberseguridad utilizaría el resultado de una aplicación como Sguil para organizar una investigación NSM.

Las alertas suelen incluir información de cinco tuplas cuando esté disponible, así como marcas de hora y la información necesaria para identificar qué dispositivo o sistema generó la alerta. Es importante recordar que las cinco tuplas incluyen la siguiente información para el seguimiento de una conversación entre una aplicación de origen y una de destino:

• SrcIP – La dirección IP de origen para el evento.
• SPort – El puerto de la capa 4 de origen (local) para el evento.
• DstIP – La dirección IP de destino para el evento.
• DPort – El puerto de la capa 4 de destino para el evento.
• Pr – El número de protocolo IP para el evento.

La información adicional podría incluir la aplicación de una decisión de permitir o negar el tráfico, datos capturados de la carga útil del paquete, o un valor hash para un archivo descargado, o una variedad de datos diferentes.

En la figura, se ve la ventana de la aplicación Sguil con la cola de alertas que esperan ser investigadas en la parte superior de la interfaz.

Ventana de Sguil

Los campos disponibles para los eventos en tiempo real son los siguientes:

• ST – This is the status of the event. RT means real time. The event is color-coded by priority. The priorities are based on the category of the alert. There are four priority levels: muy bajo, bajo, medio y alto. Los colores van del amarillo claro al rojo a medida que la prioridad aumenta.
• CNT – El recuento de la cantidad de veces que se detectó este evento para la misma dirección IP de origen y de destino. El sistema determina que este conjunto de eventos está correlacionado. En lugar de informar cada evento de una serie posiblemente larga de eventos correlacionados en esta ventana, el evento aparece una vez en esta columna con la cantidad de ocasiones en que se lo detectó. Un número elevado puede representar un problema de seguridad o la necesidad de modificar las firmas del evento para limitar la cantidad de eventos potencialmente irrelevantes que se está informando.
• Sensor – Es el agente que reporta el evento. Los sensores disponibles y sus números de identificación pueden encontrarse en la ficha de estado del agente del panel que aparece debajo de la ventana de eventos a la izquierda. Estos números también se utilizan en la columna de identificación de la alerta. Desde el panel de estado del agente, podemos ver que los sensores de OSSEC, pcap y Snort envían informes a Sguil. Además, podemos ver los nombres de host predeterminados de estos sensores, lo que incluye la interfaz de monitoreo. Es necesario tener en cuenta que cada interfaz de monitoreo tiene datos pcap y Snort asociados con ella.
• ID de alerta -Este número de dos partes representa el sensor que informa el problema y el número de evento para ese sensor. En la figura, podemos ver que la mayor cantidad de eventos visualizados provienen del sensor de OSSEC (1). El sensor de OSSEC ha informado ocho conjuntos de eventos correlacionados. De estos eventos, 232 se informaron con la identificación de evento 1.24.
• Fecha/Hora – Esta es la marca de tiempo del evento. En el caso de eventos correlacionados, es la marca de tiempo del primer evento.
• Mensaje de evento – El texto que identifica el evento. Se configura en la regla que desencadenó la alerta. La regla asociada puede verse en el panel derecho, justo encima del paquete de datos. Para mostrar la regla, la casilla de verificación Mostrar regla debe estar activada.

Según la tecnología de seguridad, es posible generar alertas con base en reglas, firmas, anomalías o comportamientos. Sin importar cómo se generan, las condiciones que desencadenan una alerta deben definirse previamente de algún modo.

26.1.5. Reglas y alertas

Las alertas pueden provenir de una serie de fuentes:

• NIDS – Snort, Zeek, y Suricata
• HIDS – OSSEC, Wazuh
• Administración y monitoreo de activos – Sistema de detección de activos pasivos (PADS)
• Transacciones HTTP, DNS y TCP– Registradas por Zeek y pcaps
• Mensajes de syslog* – Múltiples fuentes

La información encontrada en las alertas que estan en Sguil diferirá en cuanto al formato del mensaje, ya que provienen de fuentes diferentes.

La alerta de Sguil en la figura se activó por una regla configurada en Snort. Es importante que el analista de ciberseguridad pueda interpretar lo que desencadenó la alerta para poder investigarla. Por esta razón, el analista de ciberseguridad debe entender los componentes de las reglas de Snort, que son una importante fuente de alertas en Security Onion.

Alerta y regla asociada de Sguil

26.1.6. Estructura de la regla de Snort

Las reglas de Snort constan de dos secciones, como se ve en la Figura: el encabezado de la regla y las opciones de la regla. El encabezado de la regla contiene la acción, el protocolo, las direcciones IP y máscaras de red de origen y destino, y la información del puerto de origen y de destino. La sección de opciones de la regla contiene mensajes de alerta e información sobre qué partes del paquete deben ser inspeccionadas para determinar si debe adoptarse la acción de la regla. A veces, Sguil añade la ubicación de la regla. La ubicación de la regla es la ruta al archivo que contiene la regla y el número de línea en la que la regla aparece para que sea posible encontrarla y modificarla o eliminarla si hace falta.

Estructura de la regla de Snort e información suministrada por Sguil

El encabezado de las reglas

El encabezado de la regla contiene la acción, el protocolo, las direcciones y el puerto, como se muestra en la figura. Además, se indica la dirección del flujo que desencadenó la alerta. La estructura de la parte del encabezado es la misma entre las reglas de alerta de Snort.

Snort puede configurarse para utilizar variables a fin de representar direcciones IP internas y externas. Estas variables, $HOME_NET y $EXTERNAL_NET, aparecen en las reglas de Snort. Permiten simplificar la creación de reglas eliminando la necesidad de detallar direcciones y máscaras específicas para cada regla. Los valores de estas variables se configuran en el archivo snort.conf. Snort también permite especificar en las reglas direcciones IP individuales, bloques de direcciones o listas de cualquiera de estos. Es posible especificar los rangos de puertos separando los valores superiores e inferiores del rango con dos puntos. También hay disponibles otros operadores.

Estructura de encabezado de la regla de Snort

Las opciones de las reglas

La estructura de la sección de opciones de la regla es variable. Es la parte de la regla que está entre paréntesis, como se ve en la Figura. Contiene el mensaje de texto que identifica la alerta. También contiene metadatos sobre la alerta, como una dirección URL que proporciona información de referencia para la alerta. Es posible incluir otra información, como el tipo de regla y un identificador numérico único para la regla y su revisión. Además, es posible especificar características de la carga útil del paquete en las opciones. El manual de usuario de Snort, que se puede encontrar en Internet, proporciona detalles sobre las reglas y cómo crearlas.

Los mensajes de reglas de Snort pueden incluir la fuente de la regla. Tres fuentes comunes de reglas de Snort son las siguientes:

• GPL – reglas de Snort anteriores que fueron creadas por Sourcefire y distribuidas mediante GPLv2. El conjunto de reglas GPL no cuenta con certificación de Cisco Talos. Incluye las SID de Snort 3464 e inferiores. El conjunto de reglas de la GPL se puede descargar desde el sitio web de Snort, y se incluye en Security Onion.
• ET – reglas de Snort para amenazas emergentes. Las amenazas nuevas son un punto de recopilación para las reglas de Snort desde múltiples fuentes. Las reglas de ET son de código abierto y se distribuyen bajo licencia de BSD. El conjunto de reglas de ET contiene reglas de múltiples categorías. Un conjunto de reglas de ET se incluye con Security Onion. Las amenazas emergentes es una división de Proofpoint, Inc.
• VRT – Estas reglas están inmediatamente disponibles para los suscriptores y se publican para los usuarios registrados 30 días después de que se crean, con algunas limitaciones. Ahora las crea y mantiene Cisco Talos.

Las reglas pueden descargarse automáticamente de Snort.org con la utilidad de administración de reglas PulledPork que se incluye con Security Onion.

Las alertas que no generan las reglas de Snort se identifican con etiquetas de OSSEC o PADS, entre otras. Además, es posible crear reglas locales personalizadas.

Estructura de opciones de la regla de Snort

26.1.7. Práctica de laboratorio: Reglas de Snort y de firewalls

Distintos tipos de software y dispositivos de seguridad realizan funciones diferentes y registran diversos eventos. Como consecuencia, también varían las alertas generadas por diferentes dispositivos y software.

En esta práctica de laboratorio se familiarizarán con las reglas de firewall y las firmas de IDS; para ello, harán lo siguiente:

• Monitorear IDS y eventos en vivo.
• Configurarán su propia regla de firewall personalizada para impedir que los hosts se comuniquen con un servidor que aloja malware.
• Crearán un paquete malicioso y lo lanzarán con un objetivo interno.
• Crearán una regla de IDS personalizada para detectar el ataque personalizado y emitir una alerta.

26.2. Descripción general de la evaluación de alertas

26.2.1. La necesidad de evaluar las alertas

El panorama de amenazas cambia constantemente con la detección de nuevas vulnerabilidades y la evolución de nuevas amenazas. A medida que las necesidades de usuarios y organizaciones cambian, también lo hace la superficie de ataque. Los agentes de amenaza han aprendido a cambiar rápidamente las características de sus ataques para evadir la detección.

Es imposible diseñar medidas para evitar todos los ataques. Inevitablemente, los ataques terminan evadiendo las medidas de protección, sin importar lo sofisticadas que puedan ser. A veces, lo mejor que se puede hacer es detectar los ataques mientras ocurren o posteriormente. Las reglas de detección deben ser excesivamente conservadoras. En otras palabras, es mejor que se generen alertas ocasionales por tráfico inocente que tener reglas que no detecten tráfico malicioso. Por este motivo, es necesario tener analistas de ciberseguridad calificados que investiguen las alertas para determinar si realmente se produjo un ataque.

Analistas de ciberseguridad de categoría 1, analizarán colas de alertas en una herramienta como Sguil, alternando a herramientas como Zeek, Wireshark y Kibana para verificar que una sea realmente un ataque.

Principales herramientas para el analista de ciberseguridad de nivel 1

26.2.2. Evaluación de alertas

Los incidentes de seguridad se clasifican con un esquema adoptado del ámbito de los diagnósticos médicos. Este esquema de clasificación se utiliza para guiar acciones y evaluar los procedimientos de diagnóstico. Por ejemplo, cuando un paciente visita a un médico para un examen de rutina, una de las tareas del médico es determinar si el paciente está enfermo. Uno de los resultados puede ser determinar correctamente que la enfermedad está presente y que el paciente está enfermo. Otro resultado puede ser determinar que no hay ninguna enfermedad y el que paciente está sano.

Entonces, la inquietud radica en que el diagnóstico sea exacto (verdadero) o inexacto (falso). Por ejemplo, el médico podría pasar por alto síntomas de la enfermedad y tomar la determinación incorrecta de que el paciente está bien cuando, en realidad, está enfermo. Otro error posible es determinar que un paciente está enfermo cuando en realidad no lo está. Los diagnósticos falsos son costosos o peligrosos.

Durante el análisis de seguridad de la red, el analista de ciberseguridad recibe una alerta. Esto se asemeja a un paciente que va al médico y dice “estoy enfermo”. El analista de ciberseguridad, como el médico, debe determinar si este diagnóstico es cierto. El analista de ciberseguridad piensa: “El sistema dice que se ha producido un ataque. ¿Es cierto?”

Las alertas pueden clasificarse de la siguiente manera:

• Positivo verdadero: Se ha comprobado que la alerta es un incidente real de seguridad.
• Positivo falso: La alerta no indica que el incidente de seguridad haya sido real. La actividad benigna que resulta en un falso positivo a veces se conoce como un desencadenante benigno.

Otra situación puede ser que no se haya generado una alerta. La ausencia de una alerta puede clasificarse del siguiente modo:

• Negativo verdadero: No se han producido incidentes de seguridad. La actividad es benigna.
• Falso negativo: Se ha producido un incidente no detectado.

Los positivos verdaderos son el tipo de alerta deseado. Si ocurren, significa que las reglas que generan alertas funcionan correctamente. Los falsos positivos no son deseables. Aunque no indican que se ha producido un ataque no detectado, son costosos porque los analistas de ciberseguridad deben investigar las falsas alarmas; por lo tanto, le quitan tiempo a la investigación de alertas que indican la presencia de ataques reales. Los negativos verdaderos también son deseables. Indican que el tráfico benigno normal se ignora correctamente y que no se emiten alertas erróneas. Los falsos negativos son peligrosos. Indican que los sistemas de seguridad implementados no detectan ataques. Estos incidentes podrían pasar inadvertidos durante mucho tiempo y causar daños y pérdidas de datos constantes.

Los eventos benignos son aquellos que no deben desencadenar alertas. Los eventos benignos excesivos indican que es necesario mejorar o eliminar algunas reglas u otros detectores.

Cuando se sospecha que hay positivos verdaderos, un analista de ciberseguridad es requerido para escalar la alerta a un nivel mayor de investigación. El investigador avanzará con la investigación para confirmar el incidente e identificar cualquier daño que podría haber ocurrido. Esta información será utilizada por personal de seguridad de mayor categoría que trabajará para aislar el daño, solucionar las vulnerabilidades, mitigar la amenaza y cumplir los requisitos de creación de informes.

Es posible que un analista de ciberseguridad también sea deba informar al personal de seguridad que se producen falsos positivos si estos le están quitando demasiado tiempo. Esta situación indica que los sistemas de seguridad deben ajustarse para ser más eficientes. Los cambios legítimos en la configuración de la red o la descarga de reglas de detección recientes podrían ocasionar un aumento repentino de falsos positivos.

Los falsos negativos pueden detectarse mucho después de que se produzca un ataque. Esto se puede lograr mediante el análisis retrospectivo de seguridad (RSA, Retrospective Security Analysis). El RSA puede tener lugar cuando se aplican reglas recién obtenidas u otra inteligencia de amenazas a datos de seguridad de la red archivados. Por este motivo, es importante monitorear la inteligencia de amenazas para conocer vulnerabilidades y ataques nuevos y para evaluar la probabilidad de que la red fuera vulnerable. Además, es necesario evaluar el ataque en relación con el posible daño que podría sufrir la empresa. Se puede determinar que añadir nuevas técnicas de mitigación es suficiente o que debería efectuarse un análisis más detallado.

26.2.3. Análisis determinista y análisis probabilístico

Se pueden utilizar técnicas estadísticas para evaluar el riesgo de que los ataques tengan éxito en una red dada. Este tipo de análisis puede ayudar a los encargados de la toma de decisiones a evaluar mejor el costo de mitigar una amenaza respecto del daño que podría causar un ataque.

Hay dos enfoques generales para esto el análisis determinista y el análisis probabilístico. El análisis determinista evalúa el riesgo según lo que se conoce acerca de una vulnerabilidad. Supone que, para que un ataque tenga éxito, todos los pasos anteriores del ataque también deben tener éxito. Este tipo de análisis de riesgo solamente puede describir el peor de los casos. Sin embargo, muchos agentes de amenaza, aunque son conscientes del proceso para llevar a cabo un ataque, pueden carecer del conocimiento o la experiencia para completar correctamente cada paso en el camino a un ataque exitoso. Esto puede darle al analista de ciberseguridad una oportunidad para detectar el ataque y detenerlo antes de que avance más.

El análisis probabilístico evalúa el éxito potencial de un ataque calculando la probabilidad de que, si un paso de un ataque concluye con éxito, el siguiente paso también lo hará. El análisis probabilístico es especialmente útil en los análisis de seguridad de la red en tiempo real, en los que numerosas variables están en juego y un agente de amenaza puede tomar decisiones desconocidas a medida que se persigue un ataque.

El análisis probabilístico usa técnicas estadísticas que sirven para calcular la probabilidad que ocurra un evento de acuerdo con la probabilidad de que ocurran eventos anteriores. Con este tipo de análisis, es posible calcular las trayectorias más probables de un ataque y el personal de seguridad puede concentrar su atención en prevenir o detectar el ataque más probable.

En un análisis determinista, se da por sabida toda la información para llevar a cabo un ataque. Las características del ataque, como el uso de números de puerto específicos, se conocen por otras instancias del ataque o porque se usan puertos estandarizados. En el análisis probabilístico, se da por sentado que los números de puerto que se utilizarán solamente pueden predecirse con un cierto grado de seguridad. En esta situación, por ejemplo, no es posible aplicar un análisis determinista a un ataque que utiliza números de puerto dinámicos. Tales ataques se han optimizado para evitar que los firewalls que utilizan reglas estáticas los detecten.

Los dos enfoques se resumen a continuación.

• Análisis determinístico – para que un ataque tenga éxito, todos los pasos anteriores del ataque también deben tener éxito. El analista especializado en ciberseguridad conoce los pasos de un ataque exitoso.
• Análisis probabilístico– Hay técnicas estadísticas que predicen la probabilidad de que se concrete un ataque a partir de las posibilidades de que cada paso del ataque tenga éxito.

26.3. Resumen de evaluación de alertas

26.3.1. ¿Qué aprenderé en este módulo?

Fuentes de las alertas

Security Onion es una suite de código abierto de herramientas de Monitoreo de la seguridad de la red (Network Security Monitoring, NSM) que se ejecuta en una distribución Ubuntu de Linux. Las herramientas de Security Onion ofrecen tres funciones principales para el análisis de ciberseguridad como la captura completa de paquetes y tipos de datos, sistemas de detección de intrusión basados en el host y basados en la red, y herramientas de análisis de alerta. Algunos de los componentes de Security Onion son propiedad de corporaciones que los mantienen, como Cisco y Riverbend Technologies, pero está disponible como una plataforma de código abierto.

Security Onion contiene muchos componentes. Es un entorno integrado diseñado para simplificar la implementación de una solución integral de NSM. Security Onion integra estos diferentes tipos de datos y registros del sistema de detección de intrusiones (IDS) en una única plataforma mediante las siguientes herramientas: Sguil – Sirve para punto de inicio de investigación de alertas de seguridad Kibana – Kibana es una interfaz interactiva para datos de Elasticsearch. Permite la consulta de datos de NSM y proporciona visualizaciones flexibles de esos datos. La aplicación capturadora de paquetes Wireshark está integrada en el conjunto de Security Onion. Zeek es un analizador de tráfico de red que sirve como monitor de seguridad. Zeek inspecciona todo el tráfico en un segmento de red y permite un análisis detallado de esos datos.

Las alertas de seguridad son los mensajes de notificación que generan las herramientas, los sistemas y los dispositivos de seguridad de NSM. En Security Onion, Sguil proporciona una consola que integra alertas de varias fuentes en una cola con marca de hora. Un analista de ciberseguridad puede navegar por la cola de seguridad investigando, clasificando, derivando o retirando alertas.

Las alertas suelen incluir información de cinco tuplas cuando esté disponible, así como marcas de hora y la información necesaria para identificar qué dispositivo o sistema generó la alerta. Según la tecnología de seguridad, es posible generar alertas con base en reglas, firmas, anomalías o comportamientos. Las alertas pueden provenir de varios orígenes, como NIDS, administración y supervisión de activos, transacciones HTTP, DNS y TCP, y mensajes Syslog.

Snort es un sistema de detección de intrusiones en la red (NIDS, Network Intrusion Detection System). Es una fuente importante de los datos de alerta que se indexan en la herramienta de análisis Sguil. Utiliza reglas para identificar el tráfico potencialmente malicioso. Las reglas de Snort consisten de dos secciones: el encabezado de la regla y las opciones de la regla. El encabezado de la regla contiene la acción, el protocolo, las direcciones IP y máscaras de red de origen y destino, y la información del puerto de origen y de destino. La sección de opciones de la regla contiene mensajes de alerta e información sobre qué partes del paquete deben ser inspeccionadas para determinar si debe adoptarse la acción de la regla. La estructura de la sección de opciones de la regla es variable.

Descripción general de la evaluación de alertas

El panorama de amenazas cambia constantemente con la detección de nuevas vulnerabilidades y la evolución de nuevas amenazas. A medida que las necesidades de usuarios y organizaciones cambian, también lo hace la superficie de ataque. Los agentes de amenaza han aprendido a cambiar rápidamente las características de sus ataques para evadir la detección. Las reglas de detección deben ser excesivamente conservadoras. Es mejor que se generen alertas ocasionales por tráfico inocente que tener reglas que no detecten tráfico malicioso. Por este motivo, es necesario tener analistas de ciberseguridad calificados que investiguen las alertas para determinar si realmente se produjo un ataque.

Los incidentes de seguridad se clasifican con un esquema adoptado del ámbito de los diagnósticos médicos. Este esquema de clasificación se utiliza para guiar acciones y evaluar los procedimientos de diagnóstico. La inquietud radica en que el diagnóstico sea exacto (verdadero) o inexacto (falso). Las alertas se pueden clasificar como Verdadero Positivo (se ha verificado que la alerta es un incidente de seguridad real) o Falso Positivo (La alerta no indica un incidente de seguridad real). Otra situación puede ser que no se haya generado una alerta. La ausencia de una alerta se puede clasificar como: Verdadero negativo (no se ha producido ningún incidente de seguridad. La actividad es benigna.) y falso negativo (Un incidente no detectado que ha ocurrido) Los verdaderos positivos y los verdaderos negativos son deseables. Los falsos positivos no son deseables, pero inevitables, y los falsos negativos son peligrosos.

Se pueden utilizar técnicas estadísticas para evaluar el riesgo de que los ataques tengan éxito en una red dada. Este tipo de análisis puede ayudar a los encargados de la toma de decisiones a evaluar mejor el costo de mitigar una amenaza respecto del daño que podría causar un ataque. Hay dos enfoques generales para esto el análisis determinista y el análisis probabilístico. El análisis determinista evalúa el riesgo según lo que se conoce acerca de una vulnerabilidad. Supone que, para que un ataque tenga éxito, todos los pasos anteriores del ataque también deben tener éxito. Este tipo de análisis de riesgo solamente puede describir el peor de los casos. El análisis probabilístico evalúa el éxito potencial de un ataque calculando la probabilidad de que, si un paso de un ataque concluye con éxito, el siguiente paso también lo hará. El análisis probabilístico es especialmente útil en los análisis de seguridad de la red en tiempo real, en los que numerosas variables están en juego y un agente de amenaza puede tomar decisiones desconocidas a medida que se persigue un ataque.