Detectar alterações de Security posture

Estas regras de exemplo emitem alertas sobre alterações no Security posture da sua organização, usando as atividades que o Activity Feed da Compliance API registra. Elas pressupõem que seu sistema de gerenciamento de informações e eventos de segurança (SIEM) armazena essas atividades, conforme descrito em Enviar eventos para o seu SIEM.

Antes de escrever uma regra

Cada regra é uma descrição simples e uma consulta sem nenhuma linguagem de consulta específica.

• As consultas usam os nomes de campo do Activity Feed, além de stored_at, o nome que esta página usa para o momento em que você armazenou uma atividade. Qualquer outro nome é uma lista ou um alias seu.
• Antes que uma regra conte atividades, remova as duplicatas por id.
• A menos que uma regra indique o contrário, execute-a sobre o período desde a sua última execução concluída, com base em stored_at, não em created_at, porque uma atividade pode chegar atrasada; as consultas omitem esse intervalo.
• Escreva regras que disparem em uma atividade que você armazenou, nunca em uma que você não armazenou: ela pode estar atrasada ou ser uma alteração que o feed não registra. Para comparar atividades armazenadas com os resultados atuais, consulte Verificar eventos em relação aos resultados.

Regras de atestação

Estas cinco regras leem atividades org_security_control_attestation_updated.

Um risco foi aceito

Emita um alerta quando alguém aceitar o risco (accepted_risk) de não atender a um controle de segurança, para que uma segunda pessoa possa revisar a decisão.

type == "org_security_control_attestation_updated"
AND status == "accepted_risk"
AND actor.type != "system_actor"

A regra deixa de fora um system_actor, porque uma alteração automática, como uma atestação que deixou de estar em vigor (lapsed), mantém o status, mas não é uma aceitação.

Um controle foi atestado como Reprovado

Emita um alerta quando alguém atestar um controle como Reprovado (control_failed), para que alguém dê seguimento ao controle.

type == "org_security_control_attestation_updated"
AND status == "control_failed"
AND actor.type != "system_actor"

A regra deixa de fora um system_actor pelo mesmo motivo de Um risco foi aceito.

Alguém fora de uma lista de permissões alterou uma atestação

Emita um alerta quando uma atestação for registrada, alterada, salva novamente ou removida por alguém que não está na sua lista de pessoas que gerenciam atestações. Mantenha os valores de user_id dessas pessoas (allowed_user_ids) no seu SIEM.

type == "org_security_control_attestation_updated"
AND actor.type != "system_actor"
AND NOT (actor.type == "user_actor" AND actor.user_id IN allowed_user_ids)

• Qualquer ator que não seja um user_actor listado ou um system_actor dispara a regra.
• Mantenha a lista identificada por actor.user_id: actor.email_address é o endereço que a pessoa tinha quando a atividade foi registrada (Correlacione com seu SIEM).

Uma pessoa fez muitas alterações de atestação

Emita um alerta quando uma pessoa fizer mais alterações de atestação em um curto período do que é comum na sua organização. O limite de 10 e a janela de 1 hora são exemplos; escolha ambos com base na sua própria atividade.

type == "org_security_control_attestation_updated"
AND actor.type == "user_actor"
| group by organization_uuid, actor.user_id over a sliding 1 hour of created_at
| where count(distinct id) >= 10

• Alerte apenas para um grupo que contenha uma atividade armazenada desde a última execução da regra, e conte sobre todas as atividades que você armazenou, para que uma atividade atrasada se junte a um pico cujas outras atividades você armazenou antes.
• Contar por created_at mede o ritmo da pessoa, não o da sua ingestão.

Uma atestação deixou de estar em vigor automaticamente

Trate uma atividade lapsed como um sinal para revisar o controle que ela indica.

type == "org_security_control_attestation_updated"
AND action == "lapsed"

Uma atividade lapsed significa que o resultado da verificação do controle ou o seu valor atual difere daquele com base no qual a atestação foi salva, e não que uma data de término (review_date) passou. Ela pode chegar atrasada.

Mantenha as regras funcionando à medida que os valores mudam

Novos valores podem aparecer em qualquer um desses campos.

• Identifique alterações automáticas por actor.type, não pelo valor de actor.service.
• Não descarte atividades cujo valor de control, action ou status uma regra não lista; um novo valor de action pode registrar uma aceitação. Consulte a referência de eventos.

Testar uma regra

Para ver a regra da lista de permissões disparar, escolha alguém que possa atestar e que não esteja na sua lista. Peça a essa pessoa que ateste um controle que não tem nenhuma atestação e cujo resultado ninguém utiliza, e depois remova a atestação. Até que ela seja removida, a atestação pode alterar o resultado desse controle. Ambas as atividades podem levar algum tempo para chegar ao Activity Feed.

Se você armazena essas atividades como eventos Open Cybersecurity Schema Framework (OCSF), Mapear eventos de Security posture para OCSF mapeia os campos delas.