Capítulo 32 — Segurança ofensiva autorizada e red team: confiabilidade

Mapa da aula

Aula 32 publicada. Mapa, exemplo, EX094.

flowchart TD
  N0["32.1 Metas"]
  N1["32.2 Novas tentativas"]
  N2["32.3 Degradação segura"]
  N3["32.2b Contrapressão"]
  N4["32.3b Caos só no ambiente sintético"]
  N5["32.1b Verificações de saúde das dependências"]
  N6["Nota de prática"]
  N7["32.4b Medir se as metas foram cumpridas"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX094"]

Desenho lógico

flowchart LR
  N0["32.1 Metas"]
  N1["32.2 Novas tentativas"]
  N2["32.3 Degradação segura"]
  N3["32.2b Contrapressão"]
  N4["32.3b Caos só no ambiente sintético"]
  N5["32.1b Verificações de saúde das dependências"]
  N6["Nota de prática"]
  N7["32.4b Medir se as metas foram cumpridas"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX094"]

[32.1 Metas]
    |
    v
[32.2 Novas tentativas]
    |
    v
[32.3 Degradação segura]
    |
    v
[32.2b Contrapressão]
    |
    v
[32.3b Caos só no ambiente sintético]
    |
    v
[32.1b Verificações de saúde das dependências]
    |
    v
[Nota de prática]
    |
    v
[32.4b Medir se as metas foram cumpridas]
    |
    v
[Exemplo resolvido] --> [Exercício EX094]

Objetivos de aprendizagem

Você vai (1) definir metas de disponibilidade para ferramentas de avaliação; (2) usar novas tentativas com orçamentos; (3) degradar com segurança quando uma dependência falha.

32.1 Metas

Caminho de negação do TrackScope: alta disponibilidade durante as janelas de engajamento. Painéis do PulseMap: melhor esforço. Declare a meta; não insinue cinco noves sem um orçamento. Declarar melhor esforço para os painéis acaba com o folclore dos cinco noves. A disponibilidade do caminho de negação durante as janelas é a promessa que protege o cliente. Sam publica a meta ao lado do valor medido todo mês. Valores mensais com mais de cinco semanas aparecem como desatualizados na página de status. O marcador de desatualizado aponta para o job de medição que produziu o último número de 99,6% contra a meta de 99,5% do caminho de negação, com o id do job já preenchido, para que os operadores rodem de novo a mesma consulta em vez de inventar outra.

32.2 Novas tentativas

Novas tentativas ajudam em uploads instáveis (Capítulo 6), mas precisam de prazo e jitter. Limite o total de tentativas para que o limite de taxa da ROE continue valendo.

"""Reliability of a synthetic evidence-upload step with retries (deterministic)."""
import random
random.seed(7)
P_FAIL = 0.2
def upload_attempts(max_tries):
    for t in range(1, max_tries + 1):
        if random.random() > P_FAIL:
            return True, t
    return False, max_tries
for tries in (1, 2, 3, 5):
    random.seed(7)
    ok = sum(upload_attempts(tries)[0] for _ in range(1000))
    print(f"max_tries={tries} success={ok}/1000 theory={1-P_FAIL**tries:.4f}")

Saída esperada:

max_tries=1 success=784/1000 theory=0.8000
max_tries=2 success=949/1000 theory=0.9600
max_tries=3 success=988/1000 theory=0.9920
max_tries=5 success=1000/1000 theory=0.9997

Prazos e jitter impedem que as novas tentativas virem estouros de manada. Os limites protegem o orçamento de taxa da ROE derivado antes. Sam configura as novas tentativas de upload a partir do mesmo arquivo de configuração do limite de volume da ROE, para que não possam se afastar, e um teste unitário falha se o produto dos limites pelo tamanho do lote ultrapassar o orçamento. Os comentários da configuração de upload precisam citar um id real de cláusula da ROE para o limite de volume — o mesmo id que Sam usou quando escreveu as tentativas esperadas na ROE antes do engajamento —, ou o lint reprova a construção.

32.3 Degradação segura

Se o FindingsDesk cair, continue negando/permitindo localmente e enfileire os rascunhos de achados em disco — nunca falhe aberto nas verificações de escopo. Negar/permitir localmente com filas de rascunhos em disco preserva a segurança quando o FindingsDesk morre. Falhar aberto no escopo nunca é um modo de degradação. Os catorze rascunhos enfileirados na história da queda mostram o padrão funcionando. Sam treina o caminho de reprodução da fila depois de cada release do FindingsDesk. O treino semeia catorze rascunhos sintéticos, como na história da queda, reproduz e depois os apaga; uma contagem restante diferente de zero reprova o treino antes que a release seja marcada como operável.

Caso sintético — Riverstone Transit. Durante uma queda do FindingsDesk, a fila no laptop de Sam guardou 14 rascunhos; o TrackScope continua negando o que está fora do escopo.

32.4 Erros e limites

Novas tentativas contra uma API com limite de taxa podem parecer abuso; coordene os orçamentos com a ROE. Rajadas de novas tentativas contra uma API limitada parecem abuso para os defensores que observam a mesma rede. Os orçamentos acordados na ROE precisam incluir as novas tentativas das ferramentas, não só as ações lógicas. Sam mostra a contagem esperada de tentativas no kickoff e reduz a concorrência dos scanners quando o canal de monitoramento do cliente relata alarmes de limite de taxa. Slides de kickoff que omitem as contagens de tentativas são corrigidos antes das assinaturas. A caixa de revisão da assessoria jurídica rejeita um pacote de assinatura sem a contagem esperada de tentativas, porque é esse número que torna auditável a cláusula de volume da ROE.

32.2b Contrapressão

Quando a fila de rascunhos passa de um limite, pare de iniciar novos métodos de descoberta e acione o líder. Continuar varrendo enquanto os achados não podem ser registrados cria risco não rastreado. A contrapressão é uma funcionalidade de segurança, não só de desempenho. Achados não rastreados enquanto a varredura continua são risco de escopo silencioso. Parar novos métodos de descoberta leva o líder a uma escolha consciente. O limite de Sam é baixo o bastante para que uma fila no disco do laptop não cresça durante a noite sem ser notada. Os alarmes de profundidade disparam quando a fila passa de cinquenta rascunhos — antes dos alarmes de idade —, porque um disco cheio durante uma queda do FindingsDesk descartaria novos rascunhos em silêncio.

32.3b Caos só no ambiente sintético

Experimentos de confiabilidade (matar pods, particionar redes) rodam no ambiente sintético. Nunca faça teste de caos durante uma janela assinada de um cliente. Registre os ids de experimento separados dos ids de engajamento, para que as métricas não se misturem. Janelas assinadas são para avaliação autorizada, não para experimentos. Os scripts de caos de Sam se recusam a rodar se houver um id de engajamento definido no ambiente. A CI define de propósito um id de engajamento falso e espera uma saída diferente de zero, provando que a proteção não pode ser pulada por um export esquecido num perfil de shell.

32.1b Verificações de saúde das dependências

O TrackScope deve verificar a saúde do armazenamento de políticas e do destino de eventos no início da janela. Começar um engajamento às cegas e descobrir um destino quebrado no meio da varredura é uma falha de operações que o capítulo de confiabilidade quer evitar. Inícios às cegas que descobrem um destino quebrado no meio da varredura gastam a paciência do cliente e criam evidência parcial. Verificações de saúde no início da janela custam menos que pedidos de desculpa. Sam bloqueia o botão de início até que o armazenamento de políticas e o destino de eventos respondam. Quando o destino falhou na verificação sintética de início do mês passado, a linha em texto puro event-sink: connection refused foi colada no chat de início, para que o contato do cliente visse por que a janela não tinha aberto.

Nota de prática

Defina orçamentos de erro para o caminho de negação separados dos orçamentos de melhor esforço da interface. Gastar o orçamento da interface num painel sofisticado é aceitável; gastar o orçamento de negação no mesmo trabalho, não. Publique os dois orçamentos, para que a pressão do produto tenha um número com que discutir, em vez de um apelo vago por mais confiabilidade.

32.4b Medir se as metas foram cumpridas

Uma meta de disponibilidade só tem sentido se for medida. O TrackScope registra cada decisão de negar ou permitir com um carimbo de tempo, para que a equipe possa calcular a fração dos minutos da janela de engajamento em que o serviço respondeu dentro do orçamento de latência. O relatório sintético do mês passado mostrou 99,6% contra uma meta de 99,5%. Carimbos de tempo em cada decisão tornam a disponibilidade calculável em vez de anedótica. Os 99,6% contra 99,5% do mês passado são o tipo de número feio que Sam prefere. Ele põe num gráfico os minutos dentro do orçamento ao lado dos minutos da janela, para que uma queda curta não se esconda nas médias, e o gráfico leva como legenda a mesma fórmula que a meta de confiabilidade usa.

Exercícios

• EX094 — Meta. Escreva uma frase de disponibilidade para o caminho de negação do TrackScope. Rubrica: 3 = meta por janela + medição; 2 = alta e vaga; 1 = piada dos cinco noves; 0 = nada.
• EX095 — Orçamento. Com p=0,8 e no máximo 3 tentativas, qual o número esperado de tentativas? Rubrica: 3 = 1,24 com o raciocínio; 2 = 1/p; 1 = 3; 0 = nada.
• EX096 — Degradar. O que nunca pode degradar para ALLOW? Rubrica: 3 = decisões de escopo/política; 2 = parcial; 1 = interface de achados; 0 = errado.

Síntese

Negações confiáveis, novas tentativas com orçamento, degradação fechada.

Continue estudando — capítulo 32 de 50

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