Capítulo 27 — Operações de segurança e blue team: projeto de controles | Engenharia Operações de segurança e equipe azul

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 27 publicada. Mapa, exemplo, EX079.

flowchart TD
  N0["27.1 Controles de detecção e de resposta"]
  N1["27.2 Playbooks"]
  N2["27.3 Ações automatizadas"]
  N3["27.4 Salvaguardas"]
  N4["27.5 Mapeamento ao D3FEND"]
  N5["27.6 Testando os controles"]
  N6["27.7 Caso"]
  N7["Experiência do cliente"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX079"]

Desenho lógico

flowchart LR
  N0["27.1 Controles de detecção e de resposta"]
  N1["27.2 Playbooks"]
  N2["27.3 Ações automatizadas"]
  N3["27.4 Salvaguardas"]
  N4["27.5 Mapeamento ao D3FEND"]
  N5["27.6 Testando os controles"]
  N6["27.7 Caso"]
  N7["Experiência do cliente"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX079"]

[27.1 Controles de detecção e de resposta]
    |
    v
[27.2 Playbooks]
    |
    v
[27.3 Ações automatizadas]
    |
    v
[27.4 Salvaguardas]
    |
    v
[27.5 Mapeamento ao D3FEND]
    |
    v
[27.6 Testando os controles]
    |
    v
[27.7 Caso]
    |
    v
[Experiência do cliente]
    |
    v
[Exemplo resolvido] --> [Exercício EX079]

Objetivos de aprendizagem

Você vai (1) projetar controles de detecção e de resposta com gatilhos e ações definidos; (2) especificar playbooks para alertas comuns; (3) projetar salvaguardas contra ações automatizadas nocivas; (4) mapear os controles às técnicas do D3FEND.

27.1 Controles de detecção e de resposta

Um controle de detecção encontra a atividade; um controle de resposta age sobre ela. Para a tomada de conta no portal, a detecção é a regra de possível tomada de conta; a resposta é bloquear a conta, invalidar as sessões e contatar o cliente. Cada um precisa do outro. Uma detecção sem resposta planejada deixa os analistas inseguros sobre o que fazer às 3 da manhã, enquanto uma resposta sem detecção confiável ou nunca é acionada ou é acionada nas contas erradas. Projetá-los juntos permite a Amara casar a força da evidência com a força da ação: uma tomada de conta provável justifica invalidar as sessões, enquanto uma mera tentativa não justifica deixar o cliente sem acesso.

27.2 Playbooks

Um playbook lista os passos que um analista segue para um tipo de alerta: verificar, delimitar, conter, notificar, registrar. Ele nomeia os dados a conferir e os pontos de decisão. O NIST SP 800-61r3 situa essas atividades de resposta no ciclo mais amplo de gestão de riscos. Os pontos de decisão são onde o playbook pede ao analista que julgue, em vez de seguir: o sucesso veio do dispositivo habitual do cliente? O endereço já foi alterado? Nomear os dados a conferir em cada ponto impede os analistas de pularem evidências sob pressão. O playbook também diz quando parar e escalonar, para que os analistas conheçam os limites de sua própria autoridade durante um incidente.

27.3 Ações automatizadas

Alguns passos podem ser automatizados: invalidar uma sessão é rápido e de baixo risco. Outros, como bloquear uma faixa de rede, podem prejudicar usuários legítimos e exigem uma decisão humana. Invalidar uma sessão força um novo login; se o cliente for legítimo, ele simplesmente entra de novo, então uma decisão errada custa pouco. Bloquear uma faixa de rede poderia cortar uma operadora móvel que atende milhares de clientes, então uma decisão errada custa muito. Amara classifica cada ação candidata pelo custo de errar e automatiza apenas aquelas em que um erro é barato e fácil de reverter.

27.4 Salvaguardas

A automação precisa de limites: número máximo de ações por hora, exclusões para contas críticas e alertas automáticos se os limites forem atingidos. Uma automação descontrolada pode deixar milhares de clientes sem acesso. Um defeito numa regra ou uma enxurrada de eventos de teste sintéticos poderia acionar a automação milhares de vezes em minutos. Um teto de ações por hora transforma um possível desastre num problema contido. Contas críticas, como as usadas pelos sistemas dos depósitos, ficam excluídas porque bloqueá-las pararia as entregas. Atingir um limite pausa a automação e aciona um engenheiro, que decide se ela continua.

27.5 Mapeamento ao D3FEND

O D3FEND nomeia técnicas defensivas como a limiarização de eventos de autenticação e o bloqueio de contas. Mapear os controles a ele esclarece o que cada controle de fato faz e ajuda a encontrar lacunas. Os nomes de produtos e os termos de marketing variam, o que dificulta saber se duas ferramentas se sobrepõem ou deixam lacunas. O D3FEND oferece um vocabulário comum que descreve o que um controle faz com a atividade do adversário. Mapear os controles do portal da Lindqvist mostra que a limiarização e o bloqueio de contas estão presentes, enquanto nada ainda analisa o comportamento da sessão depois do login, o que sugere onde investir em seguida.

27.6 Testando os controles

Cada controle é testado com eventos sintéticos seguros, e os playbooks de resposta são ensaiados em exercícios. Os eventos sintéticos verificam se a detecção dispara e se a automação age dentro de seus limites. Os exercícios verificam as partes humanas: o analista encontra o playbook, o atendimento ao cliente sabe o que dizer a um cliente bloqueado, o contato de escalonamento atende? Os exercícios muitas vezes revelam pequenos problemas, como um número de telefone desatualizado, que nenhum teste técnico pegaria. As constatações de cada exercício são registradas com um responsável e uma data para a correção.

27.7 Caso

Amara projeta o playbook de possível tomada de conta com Paolo e com a gerente de atendimento ao cliente. Envolver o atendimento ao cliente cedo importa porque é ele que vai falar com os clientes cujas contas foram bloqueadas. A gerente pede um roteiro curto explicando por que o acesso foi redefinido e como recuperá-lo, e um campo no alerta mostrando se o cliente já foi contatado. Os dois pedidos entram no playbook antes de ele ser testado. O playbook pronto é ensaiado uma vez com um alerta sintético antes da entrada em produção, com a gerente de atendimento fazendo o papel do cliente.

Experiência do cliente

Os controles de resposta tocam os clientes. A mensagem de suspensão no portal explica que a conta está pausada por segurança e dá o número do suporte, para que os clientes legítimos não fiquem confusos.

Exemplo resolvido

O playbook automatiza a invalidação de sessões e uma suspensão temporária da conta, com teto de 20 contas por hora; acima disso, a automação pausa e aciona o engenheiro de plantão. Um analista confirma em até 30 minutos, contata o cliente pelo telefone cadastrado e registra o resultado.

Caso sintético. O playbook é inventado.

Erros e limites

Os playbooks envelhecem à medida que os sistemas mudam; revise-os após cada uso.

Exercícios

EX079 — Detecção versus resposta. Dê um controle de detecção e um de resposta para a tomada de conta no portal.
Mostrar critérios de avaliação
Rubrica: 3 = regra de possível tomada de conta; bloquear a conta/invalidar sessões; 2 = um; 1 = confuso; 0 = nada.
EX080 — Salvaguarda da automação. Que salvaguarda limita a suspensão automatizada?
Mostrar critérios de avaliação
Rubrica: 3 = teto de 20 contas/hora; pausar e acionar acima dele; 2 = parcial; 1 = vago; 0 = nada.
EX081 — Decisão humana. Por que o bloqueio de faixas de rede deve exigir uma pessoa?
Mostrar critérios de avaliação
Rubrica: 3 = pode prejudicar usuários legítimos; exige julgamento; 2 = parcial; 1 = velocidade; 0 = nada.

Síntese

Projete os controles como detecção mais resposta, automatize os passos de baixo risco com limites e mapeie os controles a técnicas defensivas nomeadas.

Continue estudando — capítulo 27 de 50

← Capítulo 26 (rascunho) · Índice de capítulos do curso · Capítulo 28 (rascunho) →