Pular para o conteúdo principal

Esquemas de log de auditoria para monitoramento de segurança

important

Este artigo foi retirado e pode não ser atualizado. O monitoramento de segurança logs agora está documentado em Eventos adicionais de monitoramento de segurança.

Para Databricks compute recurso no plano clássico compute, como VMs para clustering e pro ou clássico SQL warehouse, os seguintes recursos habilitam agentes de monitoramento adicionais:

Para serverless compute recurso, os agentes de monitoramento executam se o perfil de segurança compliance estiver ativado e o padrão de reclamação for compatível com serverless compute recurso. Veja quais compute recurso obtêm padrões aprimorados de serverless compute segurança e conformidade com a disponibilidade.

O resultado das ferramentas de monitoramento para esses recursos está disponível em Databricks audit logs.

Para acessar logs:

  1. Como administrador, configure a entrega de auditoria log para seu próprio bucket Amazon S3 .
  2. Examine regularmente os logs em busca de novas linhas com base nas seções a seguir.

Esquema para monitoramento da integridade do arquivo

Para obter o esquema geral dos logs de auditoria, consulte Exemplo de esquema de log de auditoria.

Campos do log de auditoria que são importantes para o monitoramento da integridade do arquivo:

  • serviceName: Sempre capsule8-alerts-dataplane.

  • timestamp: Hora em que a ferramenta criou esse evento.

  • workspaceId: O endereço workspace associado a esse evento.

  • requestId: O UUID exclusivo do evento original.

  • requestParams: Esse objeto request parameters JSON sempre tem apenas um campo instanceId, que é o instance-id (a ID do host) que emitiu essa entrada audit log.

  • response: Um objeto JSON.

    • Isso sempre tem uma propriedade statusCode definida como 200.

    • Um campo result que contém o valor JSON original do evento. O JSON pode variar de acordo com a detecção que o aciona. Para obter a referência completa do esquema, consulte os seguintes artigos de documentação de terceiros sobre o esquema de alerta JSON. O valor JSON é codificado como um único objeto de cadeia de caracteres em vez de um valor JSON aninhado, portanto, espere sinais de aspas com escape como os seguintes:

      JSON
      "response": {
      "statusCode": 200,
      "result": "{\"actionName\": \"Wget Program Blacklist\"}"
      }
  • accountId: O Databricks account ID para este workspace.

  • auditLevel: Sempre WORKSPACE_LEVEL.

  • actionName: Nome da ação. Um dos seguintes valores:

    • Heartbeat: Um evento regular para confirmar que o monitor está ligado. Atualmente, a execução é feita a cada 10 minutos, mas isso pode mudar no futuro.
    • Memory Marked Executable: A memória geralmente é marcada como executável para permitir que códigos maliciosos sejam executados quando um aplicativo está sendo explorado. alerta quando um programa define as permissões de memória do heap ou da pilha como executáveis. Isso pode causar falsos positivos em determinados servidores de aplicativos.
    • File Integrity Monitor: monitora a integridade de arquivos importantes do sistema. alerta sobre quaisquer alterações não autorizadas nesses arquivos. A Databricks define conjuntos específicos de caminhos de sistema na imagem, e esse conjunto de caminhos pode mudar com o tempo.
    • Systemd Unit File Modified: As alterações nas unidades do systemd podem resultar em relaxamento ou desativação dos controles de segurança ou na instalação de um serviço malicioso. alerta sempre que um arquivo de unidade systemd for modificado por um programa que não seja o systemctl.
    • Repeated Program Crashes: falhas repetidas no programa podem indicar que um invasor está tentando explorar uma vulnerabilidade de corrupção de memória ou que há um problema de estabilidade no aplicativo afetado. alerta quando mais de 5 instâncias de um programa individual travam por falha de segmentação.
    • Userfaultfd Usage: Certas funcionalidades do Linux são usadas quase exclusivamente ao explorar vulnerabilidades do kernel, geralmente com o objetivo de aumentar os privilégios. alerta quando um binário executa a chamada de sistema userfaultfd.
    • New File Executed in Container: Como os contêineres são, em geral, cargas de trabalho estáticas, esse alerta pode indicar que um invasor comprometeu o contêiner e está tentando instalar e executar um backdoor. alerta quando um arquivo que foi criado ou modificado em 30 minutos é executado em um contêiner.
    • Suspicious Interactive Shell: O shell interativo é uma ocorrência rara na infraestrutura de produção moderna. alerta quando um shell interativo é iniciado com argumentos comumente usados para o shell reverso.
    • User Command Logging Evasion: Evitar o registro de comando é uma prática comum dos invasores, mas também pode indicar que um usuário legítimo está realizando ações não autorizadas ou tentando burlar a política. alerta quando é detectada uma alteração no registro de histórico de comando do usuário, indicando que um usuário está tentando evitar o registro de comando.
    • BPF Program Executed: detecta alguns tipos de backdoors do kernel. O carregamento de um novo programa Berkeley Packet Filter (BPF) pode indicar que um invasor está carregando um rootkit baseado em BPF para ganhar persistência e evitar a detecção. alerta quando um processo carrega um novo programa BPF privilegiado, se o processo já fizer parte de um incidente em andamento.
    • Kernel Module Loaded: Os invasores geralmente carregam módulos de kernel maliciosos (rootkits) para evitar a detecção e manter a persistência em um nó comprometido. alerta quando um módulo do kernel é carregado, se o programa já fizer parte de um incidente em andamento.
    • Suspicious Program Name Executed-Space After File: Os atacantes podem criar ou renomear binários maliciosos para incluir um espaço no final do nome, em um esforço para se passar por um programa ou serviço legítimo do sistema. alerta quando um programa é executado com um espaço após o nome do programa.
    • Illegal Elevation Of Privileges: os exploits de escalonamento de privilégios do kernel geralmente permitem que um usuário sem privilégios obtenha privilégios de root sem passar pelas portas padrão para alterações de privilégios. alerta quando um programa tenta elevar os privilégios por meios incomuns. Isso pode emitir alertas falsos positivos em nós com cargas de trabalho significativas.
    • Kernel Exploit: as funções internas do kernel não são acessíveis aos programas regulares e, se chamadas, são um forte indicador de que uma exploração do kernel foi executada e de que o invasor tem controle total do nó. alerta quando uma função do kernel retorna inesperadamente ao espaço do usuário.
    • Processor-Level Protections Disabled: SMEP e SMAP são proteções no nível do processador que aumentam a dificuldade de sucesso das explorações do kernel, e desabilitar essas restrições é uma passo inicial comum nas explorações do kernel. alerta quando um programa adultera a configuração SMEP/SMAP do kernel.
    • Container Escape via Kernel ExploitationAlerta quando um programa usa funções do kernel comumente usadas em explorações de escape de contêineres, indicando que um invasor está aumentando os privilégios do acesso ao contêiner para o acesso ao nó.
    • Privileged Container Launched: Os contêineres privilegiados têm acesso direto aos recursos do host, o que causa um impacto maior quando comprometidos. alerta quando um contêiner privilegiado é iniciado, se o contêiner não for uma imagem privilegiada conhecida, como o kube-proxy. Isso pode emitir alertas indesejados para contêineres privilegiados legítimos.
    • Userland Container Escape: muitos escapes de contêiner forçam o host a executar um binário no contêiner, fazendo com que o invasor obtenha o controle total do nó afetado. alerta quando um arquivo criado em um contêiner é executado de fora do contêiner.
    • AppArmor Disabled In Kernel: A modificação de certos atributos do AppArmor só pode ocorrer no kernel, indicando que o AppArmor foi desativado por uma exploração do kernel ou rootkit. alerta quando o estado do AppArmor é alterado em relação à configuração do AppArmor detectada quando o sensor começa.
    • AppArmor Profile Modified: Os invasores podem tentar desativar a aplicação de perfis do AppArmor como parte da evasão da detecção. alerta quando um comando para modificar um perfil do AppArmor é executado, se não tiver sido executado por um usuário em uma sessão SSH.
    • Boot Files Modified: Se não for realizada por uma fonte confiável (como um gerenciador de pacotes ou uma ferramenta de gerenciamento de configuração), a modificação dos arquivos de inicialização pode indicar que um invasor está modificando o kernel ou suas opções para obter acesso persistente a um host. alerta quando são feitas alterações nos arquivos em /boot, indicando a instalação de um novo kernel ou configuração de inicialização.
    • Log Files DeletedA exclusão de registros não realizada por uma ferramenta de gerenciamento log pode indicar que um invasor está tentando remover indicadores de comprometimento. alerta sobre a exclusão de arquivos do sistema log.
    • New File Executed: Arquivos recém-criados de fontes que não sejam programas de atualização do sistema podem ser backdoors, explorações do kernel ou parte de uma cadeia de exploração. alerta quando um arquivo que foi criado ou modificado dentro de 30 minutos é executado, excluindo arquivos criados por programas de atualização do sistema.
    • Root Certificate Store Modified: A modificação do repositório de certificados raiz pode indicar a instalação de uma autoridade de certificação não autorizada, permitindo a interceptação do tráfego de rede ou o desvio da verificação da assinatura de código. alerta quando um armazenamento de certificados da CA do sistema é alterado.
    • Setuid/Setgid Bit Set On File: A configuração setuid/setgid bits pode ser usada para fornecer um método persistente para escalonamento de privilégios em um nó. alerta quando o bit setuid ou setgid é definido em um arquivo com a família chmod de chamadas de sistema.
    • Hidden File Created: Os invasores geralmente criam arquivos ocultos como forma de ocultar ferramentas e cargas úteis em um host comprometido. alerta quando um arquivo oculto é criado por um processo associado a um incidente em andamento.
    • Modification Of Common System Utilities: Os invasores podem modificar os utilitários do sistema para executar cargas maliciosas sempre que esses utilitários forem executados. alerta quando um utilitário comum do sistema é modificado por um processo não autorizado.
    • Network Service Scanner Executed: um invasor ou usuário desonesto pode usar ou instalar esses programas para pesquisar redes conectadas em busca de nós adicionais que possam ser comprometidos. alerta quando ferramentas comuns de programas de varredura de rede são executadas.
    • Network Service Created: Os atacantes podem começar um novo serviço de rede para fornecer acesso fácil a um host após o comprometimento. alerta quando um programa começa um novo serviço de rede, se o programa já fizer parte de um incidente em andamento.
    • Network Sniffing Program Executed: Um invasor ou usuário desonesto pode executar comandos de sniffing de rede para capturar credenciais, informações de identificação pessoal (PII) ou outras informações confidenciais. alerta quando é executado um programa que permite a captura de rede.
    • Remote File Copy Detected: o uso de ferramentas de transferência de arquivos pode indicar que um invasor está tentando mover conjuntos de ferramentas para outros hosts ou exfiltrar dados para um sistema remoto. alerta quando um programa associado à cópia remota de arquivos é executado, se o programa já fizer parte de um incidente em andamento.
    • Unusual Outbound Connection DetectedOs mineradores de criptomoedas e o canal Comando e Controle geralmente criam novas conexões de rede de saída em portas incomuns. alerta quando um programa inicia uma nova conexão em uma porta incomum, se o programa já fizer parte de um incidente em andamento.
    • Data Archived Via Program: depois de obter acesso a um sistema, um invasor pode criar um arquivo compactado de arquivos para reduzir o tamanho dos dados para serem exfiltrados. alerta quando um programa de compactação de dados é executado, se o programa já fizer parte de um incidente em andamento.
    • Process Injection: O uso de técnicas de injeção de processos geralmente indica que um usuário está depurando um programa, mas também pode indicar que um invasor está lendo segredos ou injetando código em outros processos. alerta quando um programa usa mecanismos de ptrace (depuração) para interagir com outro processo.
    • Account Enumeration Via Program: Os invasores geralmente usam programas de enumeração account para determinar seu nível de acesso e verificar se outros usuários estão conectados ao nó no momento. alerta quando um programa associado à enumeração account é executado, se o programa já fizer parte de um incidente em andamento.
    • File and Directory Discovery Via Program: explorar sistemas de arquivos é um comportamento comum após a exploração de um invasor em busca de credenciais e dados de interesse. alerta quando um programa associado à enumeração de arquivos e diretórios é executado, se o programa já fizer parte de um incidente em andamento.
    • Network Configuration Enumeration Via Program: Os atacantes podem interrogar a rede local e as informações de rota para identificar hosts e redes adjacentes antes do movimento lateral. alerta quando um programa associado à enumeração da configuração de rede é executado, se o programa já fizer parte de um incidente em andamento.
    • Process Enumeration Via Program: Os invasores geralmente listam os programas em execução para identificar a finalidade de um nó e se há alguma ferramenta de segurança ou monitoramento instalada. alerta quando um programa associado à enumeração de processos é executado, se o programa já fizer parte de um incidente em andamento.
    • System Information Enumeration Via Program: Os invasores geralmente executam o comando de enumeração do sistema para determinar as versões e o recurso do kernel e da distribuição do Linux, muitas vezes para identificar se o nó é afetado por vulnerabilidades específicas. alerta quando um programa associado à enumeração de informações do sistema é executado, se o programa já fizer parte de um incidente em andamento.
    • Scheduled Tasks Modified Via Program: Modificar a tarefa agendada é um método comum para estabelecer a persistência em um nó comprometido. O senhor deve ficar alerta quando os comandos crontab, at ou batch forem usados para modificar as configurações de tarefas agendadas.
    • Systemctl Usage Detected: As alterações nas unidades do systemd podem resultar em relaxamento ou desativação dos controles de segurança ou na instalação de um serviço malicioso. alerta quando o comando systemctl é usado para modificar as unidades do systemd.
    • User Execution Of su Command: o escalonamento explícito para o usuário raiz diminui a capacidade de correlacionar atividades privilegiadas a um usuário específico. alerta quando o su comando for executado.
    • User Execution Of sudo Command: alerta quando o comando sudo for executado.
    • User Command History Cleared: A exclusão do arquivo de histórico é incomum, geralmente realizada por invasores que ocultam atividades ou por usuários legítimos que pretendem evitar controles de auditoria. alerta quando os arquivos do comando line história são excluídos.
    • New System User Added: um invasor pode adicionar um novo usuário a um host para fornecer um método confiável de acesso. alerta se uma nova entidade de usuário for adicionada ao arquivo de gerenciamento local account /etc/passwd, se a entidade não for adicionada por um programa de atualização do sistema.
    • Password Database Modification: os invasores podem modificar diretamente os arquivos relacionados à identidade para adicionar um novo usuário ao sistema. alerta quando um arquivo relacionado a senhas de usuários é modificado por um programa não relacionado à atualização de informações de usuários existentes.
    • SSH Authorized Keys Modification: A adição de um novo SSH público key é um método comum para obter acesso persistente a um host comprometido. alerta quando é observada uma tentativa de gravação no arquivo SSH authorized_keys de um usuário, se o programa já fizer parte de um incidente em andamento.
    • User Account Created Via CLI: adicionar um novo usuário é uma passo comum para invasores ao estabelecer persistência em um nó comprometido. alerta quando um programa de gerenciamento de identidade é executado por um programa diferente de um gerenciador de pacotes.
    • User Configuration Changes: O perfil do usuário e os arquivos de configuração são frequentemente modificados como um método de persistência para executar um programa sempre que um usuário faz login. alerta quando o .bash_profile e o bashrc (bem como os arquivos relacionados) são modificados por um programa que não seja uma ferramenta de atualização do sistema.

A seguir, um exemplo de entrada de auditoria de monitoramento de integridade de arquivo log:

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"
}

Esquema para monitoramento de antivírus

Para obter o esquema geral dos logs de auditoria, consulte Exemplo de esquema de log de auditoria.

Auditoria log campos que são importantes para o monitoramento do antivírus:

  • serviceName: Sempre clamAVScanService-dataplane.
  • actionName: Sempre clamAVScanAction.
  • timestamp: A hora em que a ferramenta gera essa linha log.
  • workspaceId: O ID workspace associado a este log.
  • requestId: O UUID exclusivo para o evento de digitalização original.
  • requestParams: Esse objeto request parameters JSON sempre tem apenas um campo instanceId, que é o instance-id (a ID do host) que emitiu essa entrada audit log.
  • response: Esse objeto JSON de resposta sempre tem um statusCode de 200 e um campo result que inclui uma linha do resultado original da varredura. Cada resultado de varredura é representado normalmente por vários registros de log de auditoria, um para cada linha da saída original da varredura. Para obter detalhes sobre o que pode aparecer nesse arquivo, consulte a seguinte documentação de terceiros.
  • accountId: O Databricks account ID associado a este log.
  • auditLevel: Sempre WORKSPACE_LEVEL.

A seguir, um exemplo de entrada de auditoria de antivírus log que mostra o início de uma verificação no campo 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"
}

Um exemplo de arquivo de antivírus log:

----------- 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

Esquema para os logs do sistema

Para obter o esquema geral dos logs de auditoria, consulte Exemplo de esquema de log de auditoria.

Auditoria log campos que são importantes para o sistema log:

  • serviceName: Sempre syslog.

  • actionName: Sempre processEvent.

  • timestamp: A hora em que o log do sistema gera essa linha de log.

  • workspaceId: O ID workspace associado a este log.

  • requestId: O UUID exclusivo do evento original do sistema log.

  • requestParams: Esse objeto JSON de parâmetros de solicitação tem a seguinte chave:

    • instanceId: O instance-id (a ID do host) que emitiu essa entrada de auditoria log.
    • processName: Nome do processo interno que gerou esse evento. Esse campo é destinado a diagnósticos avançados e seu conteúdo está sujeito a alterações.
  • response: Um objeto JSON com um statusCode de 200 e um campo result que inclui o conteúdo original do sistema log.

  • accountId: O Databricks account ID associado a este log.

  • auditLevel: Sempre WORKSPACE_LEVEL.

Um exemplo de evento para o sistema log:

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"
}

Esquema para o monitor de processos

Para obter o esquema geral dos logs de auditoria, consulte Exemplo de esquema de log de auditoria.

Auditoria log campos que são importantes para o monitor de processo log:

  • serviceName: Sempre monit.

  • actionName: Uma das seguintes opções: processNotRunning (o monitor está em execução), processRestarting (o monitor está reiniciando), processStarted (o monitor está começando) ou processRunning (o monitor está em execução).

  • timestamp: A hora em que o log do monitor gera essa linha de log.

  • workspaceId: O ID workspace associado a este log.

  • requestId: O UUID exclusivo do evento original do sistema log.

  • requestParams: Esse objeto JSON de parâmetros de solicitação tem a seguinte chave:

    • instanceId: O instance-id (a ID do host) que emitiu essa entrada de auditoria log.
    • processName: Nome do processo interno que está sendo monitorado. Esse campo é destinado a diagnósticos avançados e seu conteúdo está sujeito a alterações.
  • response: Um objeto JSON com um statusCode de 200.

  • accountId: O Databricks account ID associado a este log.

  • auditLevel: Sempre WORKSPACE_LEVEL.

Um exemplo de evento para o monitor de processo log:

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"
}