Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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 costes de ingesta, obtener detecciones ilimitadas en tiempo real y beneficiarse de una integración perfecta con los datos, las funciones y las acciones de corrección de Defender XDR, con asignación automática de entidades. Para obtener más información, consulte Las detecciones personalizadas son ahora la experiencia unificada para crear detecciones en Microsoft Defender XDR.
Microsoft Sentinel reglas de análisis le notifican cuando se produce algo sospechoso en la red. Ninguna regla analítica es perfecta, y es inevitable que se produzcan algunos falsos positivos que hay que gestionar. 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 de los 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 ciertos usuarios, normalmente los principales de servicio (identidades automatizadas usadas por aplicaciones y servicios), muestran un patrón que resulta 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 |
|
| Modificaciones de reglas de análisis |
|
Agregar excepciones con reglas de automatización (solo Azure Portal)
El siguiente procedimiento describe cómo añadir una regla de automatización cuando detectas un incidente de 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:
En Microsoft Sentinel, en Incidentes, seleccione el incidente para el que desea crear una excepción.
En el panel de detalles del incidente del lado, seleccione Acciones > Crear regla de automatización.
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.
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.
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 modifique las condiciones sugeridas 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.
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 añadir un comentario al incidente cerrado automáticamente en el que se explique 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. Puede elegir el período de tiempo que desee para la expiración y esta reducirá la posibilidad de errores de falsos negativos. Si desea una excepción más larga, establezca La expiración de la regla en un momento posterior.
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.
Seleccione Aplicar para activar la excepción.
Añadir excepciones modificando las consultas de reglas de analítica
También puedes implementar excepciones modificando la consulta de reglas de analítica. 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 gestionar la lista de excepciones en la lista de seguimiento.
Modificación de la consulta
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 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 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, manteniendo solo los eventos cuya dirección IP no coincide con ninguna entrada de subred.
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)
...
Use listas de seguimiento para gestionar excepciones
Puede usar una lista de seguimiento para gestionar la lista de excepciones al margen 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 seguimiento puede aplicarse a varias reglas, lo que permite una gestión centralizada de las excepciones.
Usar una lista de seguimiento es similar a usar una excepción directa. Usa _GetWatchlist('<watchlist name>') para llamar a la lista de seguimiento:
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');
Para más información sobre los operadores y funciones de Kusto usados en los ejemplos de consultas de excepciones, consulte la documentación de Kusto:
- let (instrucción)
- where (operador)
- project (operador)
- datatable (operador)
- operador del complemento evaluate
- ago() (función)
- función isempty()
- ipv4_lookup complemento
Para obtener más información sobre KQL, consulte introducción a Lenguaje de consulta Kusto (KQL).
Otros recursos:
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:
- Etiquetas de llamada para los usuarios que desea excluir para evitar que activen alertas. Etiquete usuarios en la lista de seguimiento SAP_User_Config, usando asteriscos (*) como caracteres comodín para etiquetar a todos los usuarios que sigan una sintaxis de nomenclatura especificada.
- Enumere los roles o perfiles de SAP específicos que desea excluir de la activación de alertas.
Excluir los 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 la referencia de datos de la solución Microsoft Sentinel para aplicaciones SAP®.
Contenido relacionado
Para más información, vea: