Reglas de detección personalizadas
Application Security Management (ASM) viene con un conjunto de reglas de detección predefinidas cuyo objetivo es detectar los intentos de ataque, las vulnerabilidades encontradas por el atacante y el abuso de la lógica de negocio que afectan a tus sistemas de producción.
Sin embargo, hay situaciones en las que puedes querer personalizar una regla según tu entorno o carga de trabajo. Por ejemplo, es posible que desees personalizar una regla de detección que detecte a los usuarios que realizan acciones confidenciales desde una geolocalización en la que no opera tu empresa.
También puedes personalizar una regla para que se excluya una herramienta de análisis de seguridad interna. ASM detectará su actividad como siempre, pero quizá no quieras recibir notificaciones de los análisis que realiza habitualmente.
En estos casos, se puede crear una regla de detección personalizada para excluir dichos eventos. En esta guía, te explicamos cómo crear una regla de detección personalizada en ASM.
Regla de detección de abuso de lógica de negocio
ASM ofrece reglas predefinidas para detectar el abuso de la lógica de negocio (por ejemplo, hacer un reestablecimiento forzado de una contraseña). Estas reglas requieren añadir información de lógica de negocio a trazas (traces).
Intento reciente de las bibliotecas de rastreo de Datadog de detectar y enviar el inicio de sesión de usuario y los eventos de registro automáticamente sin necesidad de modificar el código. En caso necesario, puedes desactivar el rastreo automático del evento de la actividad del usuario.
Puedes filtrar las reglas e identificar qué lógica de negocio empezar a rastrear. Además, puedes utilizar estas reglas como modelo para crear reglas personalizadas basadas en tu propia lógica de negocio.
Consulta la sección siguiente para ver cómo configurar tus reglas.
Configuración
Para personalizar una regla de detección predefinida, lo primero que tienes que hacer es clonar una regla ya existente. Ve a la sección Detection Rules (Reglas de detección) y selecciónala. Desplázate hasta el final de la regla y haz clic en el botón Clone Rule (Clonar regla). Así, podrás editar la regla.
Definir una consulta de ASM
Crea una consulta de ASM utilizando la misma sintaxis de consulta que en el ASM Trace Explorer. Por ejemplo, crea una consulta para monitorizar los inicio de sesión exitosos desde fuera de Estados Unidos: @appsec.security_activity:business_logic.users.login.success -@actor.ip_details.country.iso_code:US.
También puedes definir un count único y una agrupación de señales. Cuenta el número de valores únicos que se observan en relación con un atributo en una franja de tiempo determinada. El parámetro group-by definido genera una señal por cada valor group-by. Lo más habitual es que el parámetro group-by sea una entidad (un usuario, una IP o servicio). Este parámetro también se usa para unir consultas.
Utiliza la sección de vista previa para ver qué trazas de ASM coinciden con la consulta de búsqueda. También puedes añadir consultas adicionales con el botón Add Query (Añadir consulta).
Unir consultas
Unir consultas para abarcar una franja de tiempo puede aumentar la fiabilidad o la gravedad de la señal de seguridad. Por ejemplo, para detectar un ataque exitoso, se pueden correlacionar los desencadenantes de éxito y fracaso en un servicio.
Las consultas se correlacionan empleando el valor group by. El valor group by suele ser una entidad (por ejemplo, IP o Service), aunque también puede ser un atributo.
Por ejemplo, puedes crear consultas opuestas para buscar la misma actividad business_logic.users.login.success, pero añadirles consultas de ruta HTTP opuestas para detectar intentos exitosos y fallidos:
Consulta 1: @appsec.security_activity:business_logic.users.login.success @actor.ip_details.country.iso_code:US.
Consulta 2: @appsec.security_activity:business_logic.users.login.success -@actor.ip_details.country.iso_code:US.
En este caso, las consultas unidas técnicamente contienen el mismo valor de atributo: el valor debe ser el mismo para el caso que se quiere encontrar. Si no existe un valor group by, nunca se encontrará el caso. Se genera una señal de seguridad por cada valor group by único cuando se encuentra una coincidencia con un caso.
Excluir la actividad benigna con consultas de supresión
En el campo Only generate a signal if there is a match (Generar una señal solo si hay una coincidencia), tienes la opción de introducir una consulta para que solo se genere un desencadenante cuando se cumpla un valor.
En el campo Only generate a signal if there is a match (Esta regla no generará una señal si hay una coincidencia), tienes la opción de introducir consultas de supresión para que no se genere un desencadenante cuando se cumplan los valores. Por ejemplo, si un servicio está activando una señal, pero la acción es benigna y ya no deseas que se activen señales desde este servicio, crea una consulta que excluya service.
Configurar casos de reglas
Activación
Los casos de las reglas, como successful login > 0, se evalúan como sentencias “case”. Por ello, el primer caso para el que se encuentre una coincidencia generará la señal. Crea uno o varios casos para tus reglas y haz clic en la zona gris situada junto a ellos para arrastrarlos y reordenarlos.
Los casos de las reglas contienen operaciones lógicas (>, >=, &&, ||) para determinar si debe generarse una señal según el número de eventos de las consultas definidas previamente.
Nota: La etiqueta de la consulta debe situarse por delante del operador. Por ejemplo, a > 3 es válido y 3 < a no es válido.
Ponle nombre a cada caso de regla. Este nombre se añadirá al nombre de la regla cuando se genere una señal.
Gravedad y notificación
In the Set severity to dropdown menu, select the appropriate severity level (INFO, LOW, MEDIUM, HIGH, CRITICAL).
In the Notify section, optionally, configure notification targets for each rule case.
You can also create notification rules to avoid manual edits to notification preferences for individual detection rules.
Intervalos de tiempo
An evaluation window is specified to match when at least one of the cases matches true. This is a sliding window and evaluates cases in real time.
After a signal is generated, the signal remains “open” if a case is matched at least once within the keep alive window. Each time a new event matches any of the cases, the last updated timestamp is updated for the signal.
A signal closes once the time exceeds the maximum signal duration, regardless of the query being matched. This time is calculated from the first seen timestamp.
Haz clic en Add case (Añadir caso) para añadir casos adicionales.
Nota: El valor de evaluation window debe ser inferior o igual a keep alive y maximum signal duration.
Decir qué está ocurriendo
Add a Rule name to configure the rule name that appears in the detection rules list view and the title of the Security Signal.
In the Rule message section, use notification variables and Markdown to customize the notifications sent when a signal is generated. Specifically, use template variables in the notification to inject dynamic context from triggered logs directly into a security signal and its associated notifications. See the Notification Variables documentation for more information and examples.
Utilice el menú desplegable etiquetar señales resultantes para añadir etiquetas (tags) a sus señales. Por ejemplo, attack:sql-injection-attempt.
Nota: La etiqueta security es especial, ya que sirve para clasificar la señal de seguridad. Las opciones recomendadas son attack, threat-intel, compliance, anomaly y data-leak.
Referencias adicionales
Más enlaces, artículos y documentación útiles:
