Capítulo 27 — Segurança ofensiva autorizada e red team: desenho de controles | Engenharia Segurança ofensiva autorizada e equipe vermelha

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 Três tipos"]
  N1["27.2 Competência do operador"]
  N2["27.3 Compensação"]
  N3["27.2b Dono do controle"]
  N4["27.3b Testando controles"]
  N5["27.1b Detectando o contorno de controles"]
  N6["Nota de prática"]
  N7["Síntese"]
  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 Três tipos"]
  N1["27.2 Competência do operador"]
  N2["27.3 Compensação"]
  N3["27.2b Dono do controle"]
  N4["27.3b Testando controles"]
  N5["27.1b Detectando o contorno de controles"]
  N6["Nota de prática"]
  N7["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX079"]

[27.1 Três tipos]
    |
    v
[27.2 Competência do operador]
    |
    v
[27.3 Compensação]
    |
    v
[27.2b Dono do controle]
    |
    v
[27.3b Testando controles]
    |
    v
[27.1b Detectando o contorno de controles]
    |
    v
[Nota de prática]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX079]

Objetivos de aprendizagem

Você vai (1) desenhar controles preventivos, detectivos e corretivos para a plataforma; (2) amarrar os controles aos requisitos; (3) evitar controles que exijam habilidades de exploração para serem operados.

27.1 Três tipos

Preventivo: o predicado de escopo antes da ação. Detectivo: alerta num acerto da lista de exclusão. Corretivo: desativação automática da conta de avaliação no fim da janela. Cada um corresponde a um id de requisito. Associar cada tipo a um id de requisito torna as lacunas visíveis. Preventivo sem detectivo deixa falhas silenciosas; detectivo sem corretivo deixa contas abertas depois da janela. A tabela de controles de Sam tem três colunas e recusa células vazias nas linhas Must. A desativação de contas no fim da janela é testada deixando uma conta canário ativa em staging e observando o controle corretivo disparar. Os canários de staging têm nomes claros, para que ninguém os confunda com contas de avaliação de produção.

27.2 Competência do operador

Os controles precisam ser operáveis por engenheiros que seguem runbooks — não só por especialistas em exploração. Um controle que precisa de um shellcode personalizado para ser verificado é o controle errado para este programa. Controles operáveis por runbook sobrevivem aos plantões noturnos e às novas contratações. Uma verificação que só funciona com exploração exclui os engenheiros que este programa forma. Sam reescreve qualquer controle cujo passo de verificação precise de ferramentas ofensivas personalizadas. Os passos de verificação são reescritos até que um recém-contratado consiga executá-los pelo runbook em menos de quinze minutos. Cronometrar a execução do recém-contratado faz parte da aceitação do controle e é registrado ao lado do campo de dono.

27.3 Compensação

Se o controle preventivo é fraco (um sistema legado não consegue impor o escopo de portas), acrescente monitoramento detectivo e uma aprovação humana mais rígida. Documente a compensação na ROE.

"""Evaluate proposed actions against synthetic rules of engagement."""
ROE = {
    "hours": ("09:00", "17:00"),
    "deny_actions": {"denial-of-service", "phishing-staff", "exfiltrate-real-data"},
    "require_approval": {"password-spray-lab", "privilege-escalation-lab"},
    "max_concurrency": 5,
}
proposals = [
    ("service-enum", "10:30", 3, False),
    ("denial-of-service", "10:30", 1, False),
    ("password-spray-lab", "10:30", 2, False),
    ("password-spray-lab", "10:30", 2, True),
    ("service-enum", "18:00", 2, False),
    ("service-enum", "11:00", 20, False),
]

def ok_time(t):
    return ROE["hours"][0] <= t <= ROE["hours"][1]

for action, when, conc, approved in proposals:
    reasons=[]
    if action in ROE["deny_actions"]: reasons.append("deny-action")
    if action in ROE["require_approval"] and not approved: reasons.append("needs-approval")
    if not ok_time(when): reasons.append("outside-hours")
    if conc > ROE["max_concurrency"]: reasons.append("concurrency")
    print(f"action={action:20} when={when} conc={conc:2} approved={approved} -> {'ALLOW' if not reasons else 'DENY'} {','.join(reasons) or '-'}")

Saída esperada:

action=service-enum         when=10:30 conc= 3 approved=False -> ALLOW -
action=denial-of-service    when=10:30 conc= 1 approved=False -> DENY deny-action
action=password-spray-lab   when=10:30 conc= 2 approved=False -> DENY needs-approval
action=password-spray-lab   when=10:30 conc= 2 approved=True -> ALLOW -
action=service-enum         when=18:00 conc= 2 approved=False -> DENY outside-hours
action=service-enum         when=11:00 conc=20 approved=False -> DENY concurrency

Caso sintético — Riverstone Transit. O password-spray-lab é negado a menos que aprovado — uma etapa preventiva, com um evento detectivo quando alguém tenta sem aprovação.

Lacunas legadas são honestas quando nomeadas na ROE, com monitoramento e aprovação anexados. Lacunas escondidas viram incidentes. Sam lista as compensações na apresentação do kickoff para que o cliente as aceite explicitamente. Slides de kickoff que omitam uma compensação listada são corrigidos antes das assinaturas, não depois da primeira tempestade de negações.

27.4 Erros e limites

Pilhas de controles compensatórios sem dono viram alertas ignorados. Pilhas de alertas sem dono ensinam as pessoas a ignorar os acionamentos. Todo controle compensatório precisa de um nome e de uma data de revisão. Sam apaga ou realoca os órfãos todo mês, e um alerta que disparou sem dono por uma semana é levado ao pacote da liderança como defeito de controle. Os pacotes da liderança incluem uma linha com a contagem de alertas órfãos, para que o silêncio não seja confundido com saúde. Uma contagem de órfãos em alta é discutida antes da velocidade de funcionalidades, na mesma reunião da liderança.

27.2b Dono do controle

Todo controle tem um dono, que recebe seus alertas, e uma data de revisão. Controles detectivos órfãos viram ruído; controles preventivos órfãos viram folclore que ninguém ousa mudar. Coloque o dono e a data de revisão no mesmo repositório que o código do controle. Dono mais data de revisão no repositório vencem um wiki que ninguém atualiza. O CODEOWNERS de Sam mapeia os caminhos dos controles para as pessoas que recebem os acionamentos. Remapear donos é uma mudança de configuração revisada, com uma semana de acionamentos acompanhados antes de o dono antigo sair.

27.3b Testando controles

Cada controle precisa de um teste negativo: remova-o ou quebre-o num laboratório e mostre que o mau resultado é pego por um controle superior ou pelos padrões de falha fechada. Controles não testados são desejos. Testes negativos provam que a camada superior pega um controle preventivo quebrado. Controles não testados são desejos com painéis. Sam agenda o laboratório de quebra a cada trimestre e registra as lacunas como P1. Os P1 abertos do laboratório aparecem no painel de prontidão do engajamento, ao lado da ROE e das versões fixadas. Os painéis de prontidão ficam vermelhos com P1 abertos e continuam vermelhos até que a correção entre e o laboratório seja executado de novo.

27.1b Detectando o contorno de controles

Registre quando um operador usa o acesso de emergência (break-glass) para pular a aprovação dupla. Break-glass sem detecção é só um controle individual escondido. A revisão semanal dos eventos de break-glass faz parte do desenho do controle. A revisão semanal mantém os caminhos de emergência excepcionais. Sam plota a contagem de break-glass ao lado do volume de engajamentos. As revisões de design dos caminhos de controle duplo convidam um representante do cliente quando as contagens sobem por duas semanas seguidas. Duas semanas é tempo suficiente para ver um padrão e curto o bastante para agir antes da próxima janela. Cada registro de break-glass anota quem o usou, qual aprovação foi pulada e por quê.

Nota de prática

Os controles se degradam. Agende um dia trimestral de saúde dos controles: quebre cada controle preventivo num laboratório sintético e confirme que os controles detectivos disparam. Registre a data ao lado do dono do controle. Um controle que nunca foi quebrado de propósito é um controle que você só espera que funcione, e esperança não é um controle de engenharia numa plataforma de avaliação autorizada.

Exercícios

EX079 — Mapa. Dê um controle preventivo e um detectivo contra a adulteração de evidências. Rubrica: 3 = os dois (por exemplo, repositório lacrado + alerta de divergência de hash); 2 = um; 1 = vago; 0 = nada.
EX080 — Operável. Por que "verificar explorando de novo" é um controle ruim? Rubrica: 3 = uso dual + instável + competência errada; 2 = um motivo; 1 = vago; 0 = defende.
EX081 — Laboratório. Qual regra da ROE bloqueia a concorrência 20? Rubrica: 3 = limite de concorrência; 2 = negação vaga; 1 = errado; 0 = nada.

Síntese

Os controles são preventivos/detectivos/corretivos, têm dono e são operáveis sem exploits.

Continue estudando — capítulo 27 de 50

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