Controlar los falsos positivos en Microsoft Sentinel

Importante

Las detecciones personalizadas ahora son la mejor manera de crear nuevas reglas en Microsoft Sentinel Microsoft Defender XDR SIEM. Con las detecciones personalizadas, puede reducir los costos de ingesta, obtener detecciones ilimitadas en tiempo real y beneficiarse de una integración sin problemas con Defender XDR datos, funciones y acciones de corrección con la asignación automática de entidades. Para obtener más información, lea este blog.

Microsoft Sentinel reglas de análisis le notifican cuando se produce algo sospechoso en la red. Ninguna regla de análisis es perfecta y está obligado a obtener algunos falsos positivos que necesitan control. En este artículo se describe cómo controlar los falsos positivos, ya sea mediante la automatización o mediante la modificación de reglas de análisis programadas.

Causas y prevención falsos positivos

Incluso en una regla de análisis compilada correctamente, los falsos positivos a menudo proceden de entidades específicas, como usuarios o direcciones IP que deben excluirse de la regla.

Entre los escenarios comunes se incluyen:

• Las actividades normales de determinados usuarios, normalmente entidades de servicio, muestran un patrón que parece sospechoso.
• La actividad de examen de seguridad intencionada procedente de direcciones IP conocidas se detecta como malintencionada.
• Una regla que excluye las direcciones IP privadas también debe excluir algunas direcciones IP internas que no son privadas.

En este artículo se describen dos métodos para evitar falsos positivos:

• Las reglas de automatización crean excepciones sin modificar las reglas de análisis.
• Las modificaciones de reglas de análisis programado permiten excepciones más detalladas y permanentes.

En la tabla siguiente se describen las características de cada método:

Método	Característica
Reglas de automatización	Se puede aplicar a varias reglas de análisis. Mantenga un registro de auditoría. Las excepciones cierran inmediata y automáticamente los incidentes creados, registrando el motivo del cierre y los comentarios. A menudo los generan los analistas. Permitir la aplicación de excepciones durante un tiempo limitado. Por ejemplo, el trabajo de mantenimiento podría desencadenar falsos positivos que fuera del período de tiempo de mantenimiento serían verdaderos incidentes.
Modificaciones de reglas de análisis	Permitir expresiones booleanas avanzadas y excepciones basadas en subred. Permite usar listas de reproducción para centralizar la administración de excepciones. Normalmente, los ingenieros de Security Operations Center (SOC) requieren la implementación. Son la solución de falsos positivos más flexible y completa, pero son más complejas.

Agregar excepciones con reglas de automatización (solo Azure Portal)

En este procedimiento se describe cómo agregar una regla de automatización cuando se ve un incidente falso positivo. Este procedimiento solo se admite en el Azure Portal.

Si Microsoft Sentinel se incorpora al portal de Defender, cree reglas de automatización desde cero en función de los detalles del incidente. Para obtener más información, consulte Automatización de la respuesta a amenazas en Microsoft Sentinel con reglas de automatización.

Para agregar una regla de automatización para controlar un falso positivo:

1. En Microsoft Sentinel, en Incidentes, seleccione el incidente para el que desea crear una excepción.

2. En el panel de detalles del incidente del lado, seleccione Acciones > Crear regla de automatización.

3. En la barra lateral Crear nueva regla de automatización , modifique opcionalmente el nuevo nombre de regla para identificar la excepción, en lugar de solo el nombre de la regla de alerta.

4. En Condiciones, opcionalmente agregue más nombres de regla de Analyticsa los que aplicar la excepción. Seleccione el cuadro desplegable que contiene el nombre de la regla de análisis y seleccione más reglas de análisis en la lista.

5. La barra lateral presenta las entidades específicas del incidente actual que podrían haber causado el falso positivo. Mantenga las sugerencias automáticas o modifíquelas para ajustar la excepción. Por ejemplo, podría cambiar una condición en una dirección IP para que se aplique a una subred completa.

   

6. Una vez que esté satisfecho con las condiciones, desplácese hacia abajo en el panel lateral para seguir definiendo lo que hace la regla:

   

   • La regla ya está configurada para cerrar un incidente que cumple los criterios de excepción.
   • Puede mantener el motivo de cierre especificado tal cual o puede cambiarlo si otra razón es más adecuada.
   • Puede agregar un comentario al incidente cerrado automáticamente que explica la excepción. Por ejemplo, podría especificar que el incidente se originó en una actividad administrativa conocida.
   • De forma predeterminada, la regla se establece para que expire automáticamente después de 24 horas. Esta expiración puede ser lo que quiere y reduce la posibilidad de errores negativos falsos. Si desea una excepción más larga, establezca La expiración de la regla en un momento posterior.

7. Puede agregar más acciones si lo desea. Por ejemplo, puede agregar una etiqueta al incidente, o puede ejecutar un cuaderno de estrategias para enviar un correo electrónico o una notificación o sincronizar con un sistema externo.

8. Seleccione Aplicar para activar la excepción.

Adición de excepciones mediante la modificación de reglas de análisis

Otra opción para implementar excepciones es modificar la consulta de regla de análisis. Puede incluir excepciones directamente en la regla o, preferiblemente, cuando sea posible, usar una referencia a una lista de reproducción. A continuación, puede administrar la lista de excepciones en la lista de reproducción.

Modificación de la consulta

Para editar las reglas de análisis existentes, seleccione Automatización en el menú de navegación izquierdo Microsoft Sentinel. Seleccione la regla que desea editar y, a continuación, seleccione Editar en la esquina inferior derecha para abrir el Asistente para reglas de análisis.

Para obtener instrucciones detalladas sobre el uso del Asistente para reglas de análisis para crear y editar reglas de análisis, consulte Creación de reglas de análisis personalizadas para detectar amenazas.

Para implementar una excepción en un preámbulo de regla típico, puede agregar una condición como where IPAddress !in ('<ip addresses>') cerca del principio de la consulta de regla. Esta línea excluye direcciones IP específicas de la regla.

let timeFrame = 1d;
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| where IPAddress !in ('10.0.0.8', '192.168.12.1')
...

Este tipo de excepción no se limita a las direcciones IP. Puede excluir usuarios específicos mediante el UserPrincipalName campo o excluir aplicaciones específicas mediante AppDisplayName.

También puede excluir varios atributos. Por ejemplo, para excluir alertas de la dirección 10.0.0.8 IP o del usuario user@microsoft.com, use:

| where IPAddress !in ('10.0.0.8')
| where UserPrincipalName != 'user@microsoft.com'

Para implementar una excepción más específica cuando corresponda y reducir la posibilidad de falsos negativos, puede combinar atributos. La siguiente excepción solo se aplica si ambos valores aparecen en la misma alerta:

| where IPAddress != '10.0.0.8' and UserPrincipalName != 'user@microsoft.com'

Excluir subredes

La exclusión de los intervalos IP utilizados por una organización requiere la exclusión de subredes. En el ejemplo siguiente se muestra cómo excluir subredes.

El ipv4_lookup operador es un operador de enriquecimiento, no un operador de filtrado. La where isempty(network) línea realiza realmente el filtrado, inspeccionando los eventos que no muestran una coincidencia.

let subnets = datatable(network:string) [ "111.68.128.0/17", "5.8.0.0/19", ...];
let timeFrame = 1d;
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| evaluate ipv4_lookup(subnets, IPAddress, network, return_unmatched = true)
| where isempty(network)
...

Uso de listas de reproducción para administrar excepciones

Puede usar una lista de reproducción para administrar la lista de excepciones fuera de la propia regla. Cuando corresponda, esta solución tiene las siguientes ventajas:

• Un analista puede agregar excepciones sin editar la regla, lo que mejor sigue los procedimientos recomendados de SOC.
• La misma lista de reproducción se puede aplicar a varias reglas, lo que permite la administración central de excepciones.

El uso de una lista de reproducción es similar al uso de una excepción directa. Use _GetWatchlist('<watchlist name>') para llamar a la lista de reproducción:

let timeFrame = 1d;
let logonDiff = 10m;
let allowlist = (_GetWatchlist('ipallowlist') | project IPAddress);
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| where IPAddress !in (allowlist)
...

También puede realizar el filtrado de subredes mediante una lista de seguimiento. Por ejemplo, en el código de exclusión de subredes anteriores, podría reemplazar la definición de subredes datatable por una lista de seguimiento:

let subnets = _GetWatchlist('subnetallowlist');

Vea más información sobre los siguientes elementos usados en los ejemplos anteriores, en la documentación de Kusto:

• let (instrucción)
• where (operador)
• operador project
• operador datatable
• operador de complemento evaluate
• ago() (función)
• función isempty()
• complemento ipv4_lookup

Para obtener más información sobre KQL, consulte introducción a Lenguaje de consulta Kusto (KQL).

Otros recursos:

• Referencia rápida de KQL
• Lenguaje de consulta Kusto recursos de aprendizaje

Ejemplo: Administración de excepciones para la solución de Microsoft Sentinel para aplicaciones SAP®

La solución Microsoft Sentinel para aplicaciones SAP® proporciona funciones que puede usar para excluir a los usuarios o sistemas de la activación de alertas.

• Excluir usuarios. Use la función SAPUsersGetVIP para:

  • Llame a etiquetas para los usuarios que desea excluir de la activación de alertas. Etiquete a los usuarios en la lista de reproducción de SAP_User_Config usando asteriscos (*) como caracteres comodín para etiquetar a todos los usuarios con una sintaxis de nomenclatura especificada.
  • Enumere los roles o perfiles de SAP específicos que desea excluir de la activación de alertas.

• Excluir sistemas. Use funciones que admitan el parámetro SelectedSystemRoles para determinar que solo tipos específicos de sistemas desencadenan alertas, incluidos solo sistemas de producción , solo sistemas UAT o ambos.

Para obtener más información, consulte Microsoft Sentinel referencia de datos de la solución para aplicaciones SAP®.

Contenido relacionado

Para más información, vea:

• Uso de datos de UEBA para analizar falsos positivos
• Automatización del control de incidentes en Microsoft Sentinel con reglas de automatización
• Creación de reglas de análisis personalizadas para detectar amenazas
• Uso de listas de reproducción de Microsoft Sentinel