OpenCyber Academy
Pós-graduação · Capítulo 6 · Português
Código do curso: OCA-157Capítulo 06: OCA-157-C006

Capítulo 6 — Avaliação controlada

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 06 publicada. Mapa, exemplo, EX026.

flowchart TD
  N0["6.1 Alvos da avaliação"]
  N1["6.2 Laboratório de pontuação"]
  N2["6.3 Pré-registro"]
  N3["6.4 Linguagem de GAP"]
  N4["6.5 Independência"]
  N5["6.6 Ética"]
  N6["6.7 Narrativa"]
  N7["6.8 Notas de viabilidade"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX026"]

Desenho lógico

flowchart LR
  N0["6.1 Alvos da avaliação"]
  N1["6.2 Laboratório de pontuação"]
  N2["6.3 Pré-registro"]
  N3["6.4 Linguagem de GAP"]
  N4["6.5 Independência"]
  N5["6.6 Ética"]
  N6["6.7 Narrativa"]
  N7["6.8 Notas de viabilidade"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX026"]

[6.1 Alvos da avaliação]
    |
    v
[6.2 Laboratório de pontuação]
    |
    v
[6.3 Pré-registro]
    |
    v
[6.4 Linguagem de GAP]
    |
    v
[6.5 Independência]
    |
    v
[6.6 Ética]
    |
    v
[6.7 Narrativa]
    |
    v
[6.8 Notas de viabilidade]
    |
    v
[Exemplo resolvido] --> [Exercício EX026]

Objetivos de aprendizagem

Você vai (1) desenhar avaliações de cenários e controles; (2) usar uma pontuação que equilibre aprendizado e risco; (3) fazer pré-registro; (4) relatar lacunas sem catastrofismo.

6.1 Alvos da avaliação

A escolha de cenários, a cobertura de controles, as regras de detecção e os resultados do programa precisam, cada um, de um desenho de avaliação diferente. Amira recusa uma nota única que finja medir tudo isso junto. A classificação de cenários do laboratório serve para escolher cenários; as regras de detecção precisam de medidas de purple team; os resultados do programa precisam de registros de decisão como a DEC-14. Misturar classificações de cenários, medidas de purple team e resultados da DEC-14 em uma só métrica daria ao conselho um número que não mede nenhum deles, e é assim que os materiais do conselho perdem o sentido. Por isso, cada alvo de avaliação mantém, no material dela, seu próprio desenho e sua própria medida.

6.2 Laboratório de pontuação

O lab_scenario classifica cenários sintéticos com score = 2×aprendizado − risco, para que surjam as opções de alto aprendizado e risco administrável.

"""Lab 6: score synthetic TIBER-style scenario options by detection learning vs ops risk (1-3)."""
opts = [("A","Stolen VPN + SWIFT-adjacent pivot",3,3),("B","Public web defacement only",1,1),
        ("C","Supply-chain library in batch app",3,2),("D","Branch Wi-Fi rogue AP",2,2)]
for i,t,learn,risk in sorted(opts, key=lambda x:(-(x[2]*2-x[3]), x[0])):
    print(f"{i} score={learn*2-risk:+d} learn={learn} risk={risk} {t}")

Execute com python3 lab_scenario.py. Saída verificada:

C score=+4 learn=3 risk=2 Supply-chain library in batch app
A score=+3 learn=3 risk=3 Stolen VPN + SWIFT-adjacent pivot
D score=+2 learn=2 risk=2 Branch Wi-Fi rogue AP
B score=+1 learn=1 risk=1 Public web defacement only

A biblioteca da cadeia de suprimentos no aplicativo de lote (C) tem a maior nota, +4; a VPN roubada com pivô adjacente ao SWIFT (A) tem +3, mas carrega risco 3; o ponto de acesso falso no Wi-Fi da agência (D) tem +2; e a desfiguração do site público (B) tem só +1. A classificação é uma entrada, e não uma decisão de financiamento. Amira rebaixa uma nota alta do laboratório quando falta viabilidade do white team, e a viabilidade continua decidindo o financiamento depois da classificação do laboratório.

6.3 Pré-registro

Métricas e limiares recebem uma tag no git antes dos resultados, para que Amira não possa mudar as regras do jogo depois de ver as notas. O pré-registro declara a medida principal, o limiar e as exclusões, e é curto de propósito: um colega deve conseguir encontrar a tag e lê-la sem perguntar a ela. Mudar um limiar depois de ver as notas exige uma tag emendada e uma nota no log de decisões que diga o porquê. O pré-registro é como a Meridian Clearing House mantém a avaliação honesta quando os cenários favoritos têm desempenho fraco e a tentação de redefinir o sucesso é maior.

6.4 Linguagem de GAP

"T1190 0/2 GAP" agenda trabalho de engenharia; não alega cegueira permanente. T1190 0/2 significa que nenhuma das duas tentativas de exploração de aplicação exposta ao público foi detectada, uma amostra pequena demais para estimar uma taxa. Um chamado de engenharia com data é o companheiro honesto de um rótulo GAP. Dizer "estamos cegos para sempre" não é verdadeiro nem útil quando um chamado com data pode fechar a lacuna, e a linguagem catastrofista ensina os diretores a ignorar lacunas que a engenharia poderia fechar. Por isso, a linguagem de Amira nos achados e nos materiais do conselho fica na faixa em que um GAP agenda trabalho de engenharia.

6.5 Independência

O white team ou um colega aplica a pontuação às mesmas entradas. Na oficina de cenários, o colega recebe as quatro opções com suas notas de aprendizado e de risco, mas não a classificação de Amira. A independência não é cortesia opcional: é como a pontuação otimista dos cenários favoritos é apanhada antes que as decisões de financiamento se fixem. As divergências não são resolvidas por média; cada uma mantém as duas notas e uma justificativa de uma linha de cada avaliador, e vira uma nota de desenho com a tag FEASIBILITY para a oficina seguinte. Amira prefere perder um cenário preferido a manter uma nota que só ela consegue defender.

6.6 Ética

Cenários que precisam de impacto real sobre participantes são rejeitados na fase de desenho. Dano real aos participantes não é um preço aceitável por um exercício mais realista na Meridian Clearing House, e modelos sintéticos de compensação e ambientes isolados bastam para o aprendizado. Por isso, o pivô adjacente ao SWIFT do cenário A só é jogado contra um ambiente isolado, nunca contra sistemas que carregam tráfego real de compensação. A folha de rosto de ética diz "somente sintético" na primeira página de cada projeto, o que transforma o impacto real sobre participantes em rejeição na fase de desenho, e não em negociação no meio de um exercício.

6.7 Narrativa

A viabilidade faz parte da nota, e não é um detalhe posterior. A viabilidade do cenário C para o white team inclui um responsável pelo inventário de bibliotecas que possa interromper as implantações do aplicativo de lote dentro da janela do exercício, e não apenas aprovar um chamado depois. Sem esse responsável, Amira rebaixa C apesar da nota +4 no laboratório. A pontuação independente significa que ela sai da sala enquanto um colega aplica o lab_scenario às mesmas entradas. Quando a visão do white team se sobrepõe a uma nota do laboratório, como no cenário C, ela registra o motivo como nota de desenho arquivada ao lado da saída do laboratório, em vez de mudar a nota em silêncio.

6.8 Notas de viabilidade

As notas de desenho que surgem de divergências de pontuação recebem a tag FEASIBILITY, para aparecerem automaticamente na oficina de cenários seguinte, transformando uma disputa de pontuação em insumo para desenhar o próximo cenário. Cada nota registra a letra do cenário, as duas notas, o elemento de viabilidade que falta e quem precisa fornecê-lo antes da oficina. A falta do responsável pela biblioteca no cenário C foi arquivada assim e virou o primeiro item da oficina seguinte. Amira lê as notas com tag em voz alta, para que o colega que discordou veja seu argumento ser acolhido e os juniores aprendam que perder uma opção favorita é normal quando faltam responsáveis pela parada.

6.9 Slide para o conselho

Amira comunicou ao conselho o rebaixamento do cenário C por viabilidade como força, e não como indecisão. O título do slide dela foi "Recusamos um cenário de nota alta que não conseguiríamos parar", e ele punha a nota +4 de C no laboratório ao lado do responsável ausente pelo congelamento de implantações, de modo que o motivo cabia em uma linha. O conselho aplaudiu. A recusa foi registrada no log de decisões ao lado da nota do laboratório, para que o motivo sobreviva à reunião. Notas de laboratório sem responsáveis pela parada agora são rotuladas como provisórias em todo pacote que sai da mesa dela.

6.10 Rótulos provisórios

Os rótulos de "provisório" nas notas são laranja vivo na exportação em PDF, para que uma classificação provisória não possa ser citada como definitiva depois que o PDF sai da equipe. Só as notas com viabilidade confirmada pelo white team podem perder a marca laranja, e confirmação significa que o líder do white team assinou a linha de viabilidade, incluindo um responsável nomeado pela parada daquele cenário. Diretores já agradeceram a Amira pela cor laranja quando um fornecedor tentou citar uma classificação provisória como compromisso. O rótulo não custa nada para ser aplicado e impede que uma classificação seja tratada como aprovação.

Exemplo resolvido (MCH sintética)

O lab_scenario classifica o cenário da biblioteca da cadeia de suprimentos como o mais alto dos quatro; ainda assim, Amira o submete à verificação de viabilidade pelo white team antes de financiá-lo.

Caso sintético — Meridian Clearing House (MCH). A organização de compensação, Amira Hassan e todos os números foram inventados para fins didáticos.

Erros e limites

Testes guiados por ameaças e de sistemas de compensação exigem autorização jurídica especializada. Este livro só usa casos sintéticos e não traz código de exploração nem roteiro de ataque ao mercado.

Exercícios

Síntese

A avaliação controlada pesa o aprendizado contra o risco e recusa a linguagem catastrofista para amostras pequenas.

Continue estudando — capítulo 06 de 12

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

Respostas comentadas

EX026. C — Biblioteca da cadeia de suprimentos no aplicativo de lote.

EX027. score = 2×aprendizado − risco.

EX028. A classificação informa; a viabilidade do white team e critérios mais amplos continuam decidindo o financiamento.

EX029. Como uma lacuna que agenda trabalho de engenharia, e não como cegueira permanente.

EX030. Em uma tag datada no git ou em um registro equivalente feito antes dos resultados.