Schémas de Log d'audit pour le monitoring de sécurité

important

Cet article a été retiré et pourrait ne pas être mis à jour. Les logs de monitoring de sécurité sont désormais documentés dans Événements de monitoring de sécurité supplémentaires.

Pour les ressources de compute Databricks dans le plan de compute classique, telles que les machines virtuelles pour les clusters et les SQL warehouses professionnels ou classiques, les fonctionnalités suivantes activent des agents de monitoring supplémentaires :

• monitoring de sécurité renforcée
• Profil de sécurité de la conformité.

Pour les ressources compute serverless, les agents de monitoring s'exécutent si le profil de sécurité de la conformité est activé et que la norme de conformité prend en charge les ressources compute serverless. Consultez le profil de sécurité de la conformité et les normes de conformité avec la disponibilité du compute serverless et standard.

La sortie des outils de monitoring pour ces fonctionnalités est disponible dans les audit Logs Databricks.

Pour accéder aux Logs :

1. En tant qu'administrateur, configurez la livraison des logs d'audit vers votre propre compartiment Amazon S3.
2. Veuillez consulter régulièrement les logs pour les nouvelles lignes en fonction des sections suivantes.

Schéma pour le monitoring de l'intégrité des fichiers

Pour le schéma global des Logs d'audit, consultez Exemple de schéma de Log d'audit.

Champs des Audit Logs importants pour le monitoring de l'intégrité des fichiers :

• serviceName: Toujours capsule8-alerts-dataplane.

• timestamp: heure à laquelle l'outil a créé cet événement.

• workspaceId: Le Workspace associé à cet événement.

• requestId: L'UUID unique de l'événement original.

• requestParams: Cet objet JSON de paramètres de requête n'a toujours qu'un seul champ instanceId, qui est le instance-id (l'ID de l'hôte) qui a émis cette entrée de log d'audit.

• response: Un objet JSON.

  • Ceci a toujours une propriété statusCode définie à 200.

  • Un champ result qui contient la valeur JSON originale de l'événement. Le JSON peut varier en fonction de la détection qui le Trigger. La valeur JSON est encodée comme un objet chaîne unique au lieu d'une valeur JSON imbriquée ; attendez-vous donc à des signes de guillemets échappés comme suit :

    JSON

    "response": {
      "statusCode": 200,
      "result": "{\"actionName\": \"Wget Program Blacklist\"}"
    }

• accountId: l'ID de compte Databricks pour ce Workspace.

• auditLevel: Toujours WORKSPACE_LEVEL.

• actionName: Nom de l'action. L'une des valeurs suivantes :

  • Heartbeat: Un événement régulier pour confirmer que le moniteur est activé. Actuellement exécuté toutes les 10 minutes, mais cela pourrait changer à l'avenir.
  • Memory Marked Executable: La mémoire est souvent marquée comme exécutable afin de permettre au code malveillant de s'exécuter lorsqu'une application est exploitée. Alertes lorsqu'un programme définit des permissions de mémoire de tas ou de pile comme exécutables. Cela peut provoquer des faux positifs pour certains serveurs d'applications.
  • File Integrity Monitor: Supervise l'intégrité des fichiers système importants. Alerte en cas de modifications non autorisées de ces fichiers. Databricks définit des ensembles spécifiques de chemins système sur l'image, et cet ensemble de chemins peut changer au fil du temps.
  • Systemd Unit File Modified: Des modifications apportées aux unités systemd pourraient entraîner un relâchement ou une désactivation des contrôles de sécurité, ou l'installation d'un service malveillant. Alertes chaque fois qu'un fichier d'unité systemd est modifié par un programme autre que systemctl.
  • Repeated Program Crashes: Les pannes répétées du programme pourraient indiquer qu'un attaquant tente d'exploiter une vulnérabilité de corruption de mémoire, ou qu'il existe un problème de stabilité dans l'application concernée. Alertes lorsque plus de 5 instances d’un programme individuel se bloquent en raison d’une erreur de segmentation.
  • Userfaultfd Usage: Certaines fonctionnalités Linux sont presque exclusivement utilisées lors de l'exploitation de vulnérabilités du noyau, généralement dans le but d'une élévation de privilèges. Alertes lorsqu'un binaire exécute l'appel système userfaultfd.
  • New File Executed in Container: les conteneurs étant généralement des charges de travail statiques, cette alerte pourrait indiquer qu'un attaquant a compromis le conteneur et tente d'installer et d'exécuter une porte dérobée. Alertes lorsqu'un fichier créé ou modifié dans les 30 minutes est ensuite exécuté dans un conteneur.
  • Suspicious Interactive Shell: les shells interactifs sont rares sur les infrastructures de production modernes. Alertes lorsqu'un shell interactif est start avec des arguments couramment utilisés pour les shells inversés.
  • User Command Logging Evasion: éviter la journalisation des commandes est une pratique courante chez les attaquants, mais peut également indiquer qu’un utilisateur légitime effectue des actions non autorisées ou tente de contourner la politique. Alerte lorsqu’une modification de la journalisation de l’historique des commandes utilisateur est détectée, indiquant qu’un utilisateur tente de contourner la journalisation des commandes.
  • BPF Program Executed: détecte certains types de portes dérobées de noyau. Le chargement d'un nouveau programme Berkeley Packet Filter (BPF) pourrait indiquer qu'un attaquant charge un rootkit basé sur BPF pour obtenir une persistance et éviter la détection. Des alertes sont générées lorsqu'un processus charge un nouveau programme BPF privilégié, si le processus fait déjà partie d'un incident en cours.
  • Kernel Module Loaded: Les attaquants chargent couramment des modules de noyau malveillants (rootkits) pour échapper à la détection et maintenir la persistance sur un nœud compromis. Alertes lorsqu'un module de noyau est chargé, si le programme fait déjà partie d'un incident en cours.
  • Suspicious Program Name Executed-Space After File: les pirates peuvent créer ou renommer des binaires malveillants en incluant un espace à la fin du nom afin d'usurper l'identité d'un programme ou service système légitime. Alertes lorsqu'un programme est exécuté avec un espace après le nom du programme.
  • Illegal Elevation Of Privileges: les exploits d'escalade de privilèges de noyau permettent couramment à un utilisateur non privilégié d'obtenir des privilèges root sans passer par les portes standard pour les changements de privilèges. Alerte lorsqu’un programme tente d’élever les privilèges par des moyens inhabituels. Cela peut générer des alertes de faux positifs sur les nœuds avec des charges de travail significatives.
  • Kernel Exploit: Les fonctions internes du noyau ne sont pas accessibles aux programmes standards et, si elles sont appelées, sont un indicateur fort qu'un exploit du noyau a été exécuté et que l'attaquant a le contrôle total du nœud. Alertes lorsqu'une fonction de noyau retourne inopinément à l'espace utilisateur.
  • Processor-Level Protections Disabled: SMEP et SMAP sont des protections au niveau du processeur qui augmentent la difficulté de réussite des exploits de noyau, et la désactivation de ces restrictions est une première étape courante dans les exploits de noyau. Alertes lorsqu'un programme altère la configuration SMEP/SMAP du noyau.
  • Container Escape via Kernel Exploitation: Alerte lorsqu'un programme utilise des fonctions du noyau couramment utilisées dans les exploits d'évasion de conteneur, indiquant qu'un attaquant escalade les privilèges de l'accès au conteneur à l'accès au nœud.
  • Privileged Container Launched: Les conteneurs privilégiés ont un accès direct aux ressources hôtes, ce qui entraîne un impact plus important en cas de compromission. Alertes lorsqu'un conteneur privilégié est lancé, si le conteneur n'est pas une image privilégiée connue telle que kube-proxy. Ceci peut émettre des alertes indésirables pour les conteneurs privilégiés légitimes.
  • Userland Container Escape: De nombreuses évasions de conteneurs forcent l'hôte à exécuter un binaire en conteneur, ce qui permet à l'attaquant de prendre le contrôle total du nœud affecté. Alerte lorsqu'un fichier créé par un conteneur est exécuté depuis l'extérieur d'un conteneur.
  • AppArmor Disabled In Kernel: La modification de certains attributs AppArmor ne peut se produire qu'au sein du noyau, ce qui indique qu'AppArmor a été désactivé par un exploit du noyau ou un rootkit. Alertes lorsque l'état AppArmor est modifié par rapport à la configuration AppArmor détectée au start du capteur.
  • AppArmor Profile Modified: Les attaquants peuvent tenter de désactiver l'application des profils AppArmor dans le cadre de l'évasion de la détection. Alertes lorsqu'une commande de modification d'un profil AppArmor est exécutée, si elle n'a pas été exécutée par un utilisateur dans une session SSH.
  • Boot Files Modified: Si elle n’est pas effectuée par une source fiable (telle qu’un gestionnaire de packages ou un outil de gestion de configuration), la modification des fichiers de démarrage pourrait indiquer qu’un attaquant modifie le noyau ou ses options afin d’obtenir un accès persistant à un hôte. Alertes lorsque des modifications sont apportées aux fichiers dans /boot, indiquant l'installation d'un nouveau noyau ou d'une configuration de démarrage.
  • Log Files Deleted: la suppression de logs non effectuée par un outil de gestion de logs pourrait indiquer qu'un attaquant tente de supprimer des indicateurs de compromission. Alertes en cas de suppression de fichiers de logs système.
  • New File Executed: Les fichiers nouvellement créés à partir de sources autres que les programmes de mise à jour système peuvent être des portes dérobées, des exploits du noyau ou faire partie d'une chaîne d'exploitation. Alertes lorsqu’un fichier créé ou modifié dans les 30 minutes est ensuite exécuté, à l’exclusion des fichiers créés par les programmes de mise à jour du système.
  • Root Certificate Store Modified: La modification du magasin de certificats racine pourrait indiquer l'installation d'une autorité de certification malveillante, permettant l'interception du trafic réseau ou le contournement de la vérification de la signature du code. Alerte lorsqu'un magasin de certificats CA système est modifié.
  • Setuid/Setgid Bit Set On File: le réglage des bits setuid/setgid peut être utilisé pour fournir une méthode persistante d'escalade de privilèges sur un nœud. Alerte lorsque le bit setuid ou setgid est défini sur un fichier avec la famille d'appels système chmod.
  • Hidden File Created: Les attaquants créent souvent des fichiers masqués pour masquer des outils et des charges utiles sur un hôte compromis. Alertes lorsqu'un fichier masqué est créé par un processus associé à un incident en cours.
  • Modification Of Common System Utilities: Les attaquants peuvent modifier les utilitaires système afin d'exécuter des charges utiles malveillantes chaque fois que ces utilitaires sont exécutés. Alertes lorsqu'une infrastructure publique système courante est modifiée par un processus non autorisé.
  • Network Service Scanner Executed: Un attaquant ou un utilisateur malveillant peut utiliser ou installer ces programmes pour sonder les réseaux connectés à la recherche de nœuds supplémentaires à compromettre. Alertes lorsque des outils courants de programme de balayage réseau sont exécutés.
  • Network Service Created: Les attaquants peuvent start un nouveau service réseau pour faciliter l'accès à un hôte après compromission. Alertes lorsqu'un programme start un nouveau service réseau, si le programme fait déjà partie d'un incident en cours.
  • Network Sniffing Program Executed: un attaquant ou un utilisateur malveillant peut exécuter des commandes de reniflage réseau pour capturer des justificatifs d’identité, des informations personnellement identifiables (PII) ou d’autres informations sensibles. Alerte lorsqu’un programme est exécuté qui permet la capture réseau.
  • Remote File Copy Detected: L'utilisation d'outils de transfert de fichiers pourrait indiquer qu'un attaquant tente de déplacer des ensembles d'outils vers des hôtes supplémentaires ou d'exfiltrer des données vers un système distant. Alertes lorsqu'un programme associé à une copie de fichier à distance est exécuté, si le programme fait déjà partie d'un incident en cours.
  • Unusual Outbound Connection Detected: Les canaux de commande et de contrôle et les mineurs de cryptomonnaies créent souvent de nouvelles connexions réseau sortantes sur des ports inhabituels. Alerte lorsqu'un programme initie une nouvelle connexion sur un port inhabituel, si le programme fait déjà partie d'un incident en cours.
  • Data Archived Via Program: Après avoir obtenu l'accès à un système, un attaquant peut créer une archive compressée de fichiers afin de réduire la taille des données pour l'exfiltration. Alertes lorsqu'un programme de compression de données est exécuté, si le programme fait déjà partie d'un incident en cours.
  • Process Injection: L'utilisation de techniques d'injection de processus indique généralement qu'un utilisateur est en train de debugging un programme, mais cela peut également indiquer qu'un attaquant lit des secrets ou injecte du code dans d'autres processus. Alertes lorsqu'un programme utilise des mécanismes ptrace (debugging) pour interagir avec un autre processus.
  • Account Enumeration Via Program: les attaquants utilisent souvent des programmes d'énumération de comptes pour déterminer leur niveau d'accès et voir si d'autres utilisateurs sont actuellement connectés au nœud. Alertes lorsqu'un programme associé à l'énumération de comptes est exécuté, si le programme fait déjà partie d'un incident en cours.
  • File and Directory Discovery Via Program: L’exploration des systèmes de fichiers est un comportement courant après exploitation pour un attaquant recherchant des informations d’identification et des données d’intérêt. Alerte lorsqu'un programme associé à l'énumération de fichiers et de répertoires est exécuté, si le programme fait déjà partie d'un incident en cours.
  • Network Configuration Enumeration Via Program: Les attaquants peuvent interroger les informations de réseau local et de routage pour identifier les hôtes et les réseaux adjacents avant un mouvement latéral. Alertes lorsqu'un programme associé à l'énumération de la configuration réseau est exécuté, si le programme fait déjà partie d'un incident en cours.
  • Process Enumeration Via Program: Les attaquants répertorient souvent les programmes en cours d'exécution afin d'identifier l'objectif d'un nœud et de vérifier si des outils de sécurité ou de monitoring sont en place. Alertes lorsqu’un programme associé à l’énumération de processus est exécuté, si le programme fait déjà partie d’un incident en cours.
  • System Information Enumeration Via Program: Les attaquants exécutent couramment des commandes d'énumération système pour déterminer les versions et les fonctionnalités du noyau et de la distribution Linux, souvent pour identifier si le nœud est affecté par des vulnérabilités spécifiques. Alertes lorsqu'un programme associé à l'énumération des informations système est exécuté, si le programme fait déjà partie d'un incident en cours.
  • Scheduled Tasks Modified Via Program: La modification des tâches planifiées est une méthode courante pour établir une persistance sur un nœud compromis. Alertes lorsque les commandes crontab, at ou batch sont utilisées pour modifier les configurations des tâches planifiées.
  • Systemctl Usage Detected: Des modifications apportées aux unités systemd pourraient entraîner un relâchement ou une désactivation des contrôles de sécurité, ou l'installation d'un service malveillant. Alertes lorsque la commande systemctl est utilisée pour modifier les unités systemd.
  • User Execution Of su Command: l'escalade explicite vers l'utilisateur root diminue la capacité de corréler l'activité privilégiée à un utilisateur spécifique. Alertes lorsque la commande su est exécutée.
  • User Execution Of sudo Command: alertes lorsque la commande sudo est exécutée.
  • User Command History Cleared : La suppression du fichier d'historique est inhabituelle, généralement effectuée par des attaquants qui dissimulent leur activité, ou par des utilisateurs légitimes qui cherchent à échapper aux contrôles d'audit. Alertes lorsque les fichiers d'historique de ligne de commande sont supprimés.
  • New System User Added: Un attaquant peut ajouter un nouvel utilisateur à un hôte pour fournir une méthode d'accès fiable. Envoie des alertes si une nouvelle entité d'utilisateur est ajoutée au fichier de gestion de compte local /etc/passwd, si l'entité n'est pas ajoutée par un programme de mise à jour du système.
  • Password Database ModificationLes attaquants peuvent modifier directement les fichiers liés à l'identité pour ajouter un nouvel utilisateur au système. Alerte lorsqu'un fichier lié aux mots de passe des utilisateurs est modifié par un programme non lié à la mise à jour des informations utilisateur existantes.
  • SSH Authorized Keys ModificationL'ajout d'une nouvelle clé publique SSH est une méthode courante pour obtenir un accès persistant à un hôte compromis. Alertes lorsqu'une tentative d'écriture dans le fichier SSH authorized_keys d'un utilisateur est observée, si le programme fait déjà partie d'un incident en cours.
  • User Account Created Via CLI: L'ajout d'un nouvel utilisateur est une étape courante pour les attaquants lorsqu'ils établissent une persistance sur un nœud compromis. Alertes lorsqu'un programme de gestion des identités est exécuté par un programme autre qu'un gestionnaire de package.
  • User Configuration Changes: Les fichiers de profil utilisateur et de configuration sont souvent modifiés comme méthode de persistance afin d’exécuter un programme chaque fois qu’un utilisateur se connecte. Alertes lorsque .bash_profile et bashrc (ainsi que les fichiers associés) sont modifiés par un programme autre qu’un outil de mise à jour du système.

Voici un exemple d'entrée de journal d'audit de monitoring de l'intégrité des fichiers :

JSON

{
  "version": "2.0",
  "timestamp": 1625959170109,
  "workspaceId": "2417130538620110",
  "serviceName": "capsule8-alerts-dataplane",
  "actionName": "Wget Program Blacklist",
  "requestId": "318a87db-4cfe-4532-9110-09edc262275e",
  "requestParams": {
    "instanceId": "i-0a3c9d63bb295eb4f"
  },
  "response": {
    "statusCode": 200,
    "result": "<original-alert-json>"
  },
  "accountId": "82d65820-b5e4-4ab0-96e6-0cba825a5687",
  "auditLevel": "WORKSPACE_LEVEL"
}

Schéma pour le monitoring antivirus

Pour le schéma global des Logs d'audit, consultez Exemple de schéma de Log d'audit.

Champs des Logs d'audit importants pour le monitoring antivirus :

• serviceName: Toujours clamAVScanService-dataplane.
• actionName: Toujours clamAVScanAction.
• timestamp: L'heure à laquelle l'outil génère cette ligne de journal.
• workspaceId: L'ID du Workspace associé à ce Log.
• requestId: L'UUID unique de l'événement d'analyse original.
• requestParams: Cet objet JSON de paramètres de requête n'a toujours qu'un seul champ instanceId, qui est le instance-id (l'ID de l'hôte) qui a émis cette entrée de log d'audit.
• response: Cet objet JSON de réponse a toujours un statusCode de 200 et un champ result qui inclut une ligne du résultat de l'analyse originale. Chaque résultat de scan est généralement représenté par plusieurs enregistrements de logs d'audit, un pour chaque ligne de la sortie de scan originale. Pour plus de détails sur ce qui pourrait apparaître dans ce fichier, consultez la documentation tierce suivante.
• accountId: L'ID de compte Databricks associé à ce log.
• auditLevel: Toujours WORKSPACE_LEVEL.

Voici un exemple d'entrée de log d'audit antivirus qui montre le début d'une analyse dans le champ response.result :

JSON

{
  "version": "2.0",
  "timestamp": 1625959170109,
  "workspaceId": "2417130538620110",
  "serviceName": "clamAVScanService-dataplane",
  "actionName": "clamAVScanAction",
  "requestId": "318a87db-4cfe-4532-9110-09edc262275e",
  "requestParams": {
    "instanceId": "i-0a3c9d63bb295eb4f"
  },
  "response": {
    "statusCode": 200,
    "result": "begin daily clamav scan : Mon Oct 25 06:25:01 UTC 2021\\n"
  },
  "accountId": "82d65820-b5e4-4ab0-96e6-0cba825a5687",
  "auditLevel": "WORKSPACE_LEVEL"
}

Un exemple de fichier de log antivirus :

----------- SCAN SUMMARY -----------
Known viruses: 8556227
Engine version: 0.103.2
Scanned directories: 6
Scanned files: 446
Infected files: 0
Data scanned: 74.50 MB
Data read: 164.43 MB (ratio 0.45:1)
Time: 37.874 sec (0 m 37 s)
Start Date: 2021:07:27 21:47:36
End Date:   2021:07:27 21:48:14

Schéma pour les logs système

Pour le schéma global des Logs d'audit, consultez Exemple de schéma de Log d'audit.

Champs du audit log importants pour le système log :

• serviceName: Toujours syslog.

• actionName: Toujours processEvent.

• timestampHeure à laquelle le log système génère cette ligne de log.

• workspaceId: L'ID du Workspace associé à ce Log.

• requestId: L'UUID unique pour l'événement de log système d'origine.

• requestParams: L'objet JSON de ces paramètres de requête possède les clés suivantes :

  • instanceId: Le instance-id (l'ID de l'hôte) qui a émis cette entrée de log d'audit.
  • processName: Nom du processus interne qui a généré cet événement. Ce champ est destiné aux diagnostics avancés et son contenu est susceptible d'être modifié.

• responseObjet JSON avec un statusCode de 200 et un champ result qui inclut le contenu original du journal système.

• accountId: L'ID de compte Databricks associé à ce log.

• auditLevel: Toujours WORKSPACE_LEVEL.

Un exemple d'événement pour le système Logs :

JSON

{
  "version": "2.0",
  "timestamp": 1633220481000,
  "workspaceId": "2417130538620110",
  "sessionId": "2710",
  "serviceName": "syslog",
  "actionName": "processEvent",
  "requestId": "1054f4c8-741d-3d80-b168-ca2cb891aa7a",
  "requestParams": {
    "instanceId": "i-00edf5b73b4c68221",
    "processName": "<process-name>"
  },
  "response": {
    "statusCode": 200,
    "result": "<syslog content>"
  },
  "accountId": "82d65820-b5e4-4ab0-96e6-0cba825a5687",
  "auditLevel": "WORKSPACE_LEVEL"
}

Schéma pour le moniteur de processus

Pour le schéma global des Logs d'audit, consultez Exemple de schéma de Log d'audit.

Champs des Logs d'audit importants pour le journal du moniteur de processus :

• serviceName: Toujours monit.

• actionName: Voici l'un des états suivants : processNotRunning (le moniteur est en cours d'exécution), processRestarting (le moniteur est en redémarrage), processStarted (le moniteur a start), ou processRunning (le moniteur est en cours d'exécution).

• timestamp: Le moment où le moniteur log génère cette log row.

• workspaceId: L'ID du Workspace associé à ce Log.

• requestId: L'UUID unique pour l'événement de log système d'origine.

• requestParams: L'objet JSON de ces paramètres de requête possède les clés suivantes :

  • instanceId: Le instance-id (l'ID de l'hôte) qui a émis cette entrée de log d'audit.
  • processName: Nom du processus interne qui est surveillé. Ce champ est destiné aux diagnostics avancés et son contenu est susceptible d'être modifié.

• response: Un objet JSON avec un statusCode de 200.

• accountId: L'ID de compte Databricks associé à ce log.

• auditLevel: Toujours WORKSPACE_LEVEL.

Un exemple d'événement pour le log du moniteur de processus :

JSON

{
  "version": "2.0",
  "timestamp": 1626857554000,
  "workspaceId": "2417130538620110",
  "serviceName": "monit",
  "actionName": "processRestarting",
  "requestId": "48bb4060-7685-3a19-9dbb-f83d2afaf346",
  "requestParams": {
    "instanceId": "i-0c48619b79d4056f2",
    "processName": "<process-name>"
  },
  "response": {
    "statusCode": 200
  },
  "accountId": "82d65820-b5e4-4ab0-96e6-0cba825a5687",
  "auditLevel": "WORKSPACE_LEVEL"
}