Règles de détection personnalisées
Ce produit n'est pas pris en charge par le
site Datadog que vous avez sélectionné. (
).
Présentation
App and API Protection (AAP) est fourni avec un ensemble de règles de détection prêtes à l’emploi qui visent à détecter les tentatives d’attaque, les vulnérabilités découvertes par les attaquants et les abus de logique métier qui impactent vos systèmes de production.
Cependant, il existe des situations où vous pourriez vouloir personnaliser une règle en fonction de votre environnement ou de votre charge de travail. Par exemple, vous pourriez vouloir personnaliser une règle de détection qui identifie les utilisateurs effectuant des actions sensibles depuis une géolocalisation où votre entreprise n’opère pas.
Un autre exemple est la personnalisation d’une règle pour exclure un scanner de sécurité interne. AAP détecte son activité comme prévu. Cependant, vous ne souhaitez peut-être pas être notifié de son scan régulier.
Dans ces situations, une règle de détection personnalisée peut être créée pour exclure de tels événements. Ce guide vous montre comment créer une règle de détection personnalisée pour AAP.
Règle de détection d’abus de logique métier
AAP propose des règles prêtes à l’emploi pour détecter les abus de logique métier (par exemple, la réinitialisation d’un mot de passe par force brute). Ces règles nécessitent d’ajouter des informations de logique métier aux traces.
Les SDK Datadog récents tentent de détecter et d’envoyer automatiquement les événements de connexion et d’inscription des utilisateurs sans avoir besoin de modifier le code. Si nécessaire, vous pouvez désactiver le suivi automatique des événements d’activité utilisateur.
Vous pouvez filtrer les règles et identifier la logique métier dont vous souhaitez commencer le suivi. De plus, vous pouvez utiliser ces règles comme modèle pour créer des règles personnalisées basées sur votre propre logique métier.
Consultez la section ci-dessous pour savoir comment configurer vos règles.
Configuration
Pour personnaliser une règle de détection prête à l’emploi, vous devez d’abord cloner une règle existante. Accédez à vos Règles de détection et sélectionnez une règle. Faites défiler jusqu’en bas de la règle et cliquez sur le bouton Clone Rule. Cela vous permet désormais de modifier la règle existante.
Définir une requête AAP
Construisez une requête AAP en utilisant la même syntaxe de requête que dans l’AAP Trace Explorer. Par exemple, créez une requête pour surveiller les connexions réussies depuis l’extérieur des États-Unis : @appsec.security_activity:business_logic.users.login.success -@actor.ip_details.country.iso_code:US.
Optionnellement, définissez un compte unique et un regroupement de signaux. Comptez le nombre de valeurs uniques observées pour un attribut dans un laps de temps donné. Le regroupement défini génère un signal pour chaque valeur de regroupement. Généralement, le regroupement est une entité (comme un utilisateur, une adresse IP ou un service). Le regroupement est également utilisé pour joindre les requêtes entre elles.
Utilisez la section de prévisualisation pour voir quelles traces AAP correspondent à la requête de recherche. Vous pouvez également ajouter des requêtes supplémentaires avec le bouton Add Query.
Joindre des requêtes
Joindre des requêtes pour couvrir une période peut augmenter la confiance ou la gravité du signal de sécurité. Par exemple, pour détecter une attaque réussie, les déclencheurs réussis et infructueux peuvent être corrélés pour un service.
Les requêtes sont corrélées entre elles en utilisant une valeur group by. La valeur group by est généralement une entité (par exemple, IP ou Service), mais peut être n’importe quel attribut.
Par exemple, créez des requêtes opposées qui recherchent la même activité business_logic.users.login.success, mais ajoutez des requêtes de chemin HTTP opposées pour les tentatives réussies et infructueuses :
Requête 1 : @appsec.security_activity:business_logic.users.login.success @actor.ip_details.country.iso_code:US.
Requête 2 : @appsec.security_activity:business_logic.users.login.success -@actor.ip_details.country.iso_code:US.
Dans ce cas, les requêtes jointes détiennent techniquement la même valeur d’attribut : la valeur doit être la même pour que le cas soit satisfait. Si une valeur group by n’existe pas, le cas ne sera jamais satisfait. Un signal de sécurité est généré pour chaque valeur group by unique lorsqu’un cas correspond.
Exclure l’activité bénigne avec des requêtes de suppression
Dans le champ Only generate a signal if there is a match, vous avez la possibilité de saisir une requête afin qu’un déclencheur ne soit généré que lorsqu’une valeur est atteinte.
Dans le champ This rule will not generate a signal if there is a match, vous avez la possibilité de saisir des requêtes de suppression afin qu’un déclencheur ne soit pas généré lorsque les valeurs sont atteintes. Par exemple, si un service déclenche un signal, mais que l’action est bénigne et que vous ne souhaitez plus que des signaux soient déclenchés par ce service, créez une requête qui exclut service.
Définir un cas de règle
Déclencheur
Les cas de règle, tels que successful login > 0, sont évalués comme des instructions de cas. Ainsi, le premier cas correspondant génère le signal. Créez un ou plusieurs cas de règle, puis cliquez sur la zone grise à côté d’eux pour les faire glisser et réorganiser leur ordre.
Un cas de règle contient des opérations logiques (>, >=, &&, ||) pour déterminer si un signal doit être généré en fonction des nombres d’événements dans les requêtes précédemment définies.
Remarque : L’étiquette de la requête doit précéder l’opérateur. Par exemple, a > 3 est autorisé ; 3 < a n’est pas autorisé.
Donnez un nom à chaque cas de règle. Ce nom est ajouté au nom de la règle lorsqu’un signal est généré.
Gravité et notification
In the Set severity to dropdown menu, select the appropriate severity level (INFO, LOW, MEDIUM, HIGH, CRITICAL).
In the Add notify section, click Add Recipient to optionally configure notification targets.
You can also create notification rules to avoid manual edits to notification preferences for individual detection rules.
Fenêtres temporelles
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.
Cliquez sur Add Case pour ajouter des cas supplémentaires.
Remarque : Le evaluation window doit être inférieur ou égal au keep alive et au maximum signal duration.
Indiquez ce qui se passe
- Enter a Rule name. The name 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.
- Use the Tag resulting signals dropdown menu to add tags to your signals. For example,
security:attack or technique:T1110-brute-force.- Note: the tag
security is special. This tag is used to classify the security signal. The recommended options are: attack, threat-intel, compliance, anomaly, and data-leak.
Utilisez le menu déroulant Tag resulting signals pour ajouter des tags à vos signaux. Par exemple, attack:sql-injection-attempt.
Remarque : Le tag security est spécial. Ce tag est utilisé pour classer le signal de sécurité. Les options recommandées sont : attack, threat-intel, compliance, anomaly et data-leak.
Pour aller plus loin
Documentation, liens et articles supplémentaires utiles:
