Capítulo 2 — Segurança ofensiva autorizada e red team: seminário avançado
Mapa da aula
Aula 02 publicada. Mapa, exemplo, EX008.
flowchart TD
N0["2.1 Prática de seminário"]
N1["2.2 Vocabulário ATT&CK"]
N2["2.3 Achados sem payloads"]
N3["2.4 Guiado por ameaças versus checklist"]
N4["2.5 A arte do feedback"]
N5["2.5b Comparar frameworks num único slide"]
N6["2.5c Ler um framework de forma crítica"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX008"]
Desenho lógico
flowchart LR
N0["2.1 Prática de seminário"]
N1["2.2 Vocabulário ATT&CK"]
N2["2.3 Achados sem payloads"]
N3["2.4 Guiado por ameaças versus checklist"]
N4["2.5 A arte do feedback"]
N5["2.5b Comparar frameworks num único slide"]
N6["2.5c Ler um framework de forma crítica"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX008"]
[2.1 Prática de seminário]
|
v
[2.2 Vocabulário ATT&CK]
|
v
[2.3 Achados sem payloads]
|
v
[2.4 Guiado por ameaças versus checklist]
|
v
[2.5 A arte do feedback]
|
v
[2.5b Comparar frameworks num único slide]
|
v
[2.5c Ler um framework de forma crítica]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX008]
Objetivos de aprendizagem
Você vai (1) apresentar e criticar artigos e frameworks de metodologia; (2) usar o ATT&CK como vocabulário comum; (3) priorizar achados sintéticos sem detalhes de exploração; (4) debater testes guiados por ameaças versus testes por checklist; e (5) dar feedback estruturado aos pares.
2.1 Prática de seminário
A cada semana, um estudante apresenta um framework ou artigo: alegação, evidência e o que um estudo de mestrado poderia reaproveitar. Os pares entregam feedback por escrito: questão maior, questão menor, pergunta. O feedback por escrito mantém a discussão no trabalho, e não em quem apresenta. Quando Noah apresenta a marcação ATT&CK como intervenção de relato, a questão maior levantada pelos pares é que a qualidade das marcações pode variar. Esse comentário mais tarde se torna a auditoria de marcações dele. Guarde o feedback de cada semana no diário de pesquisa, com a ação que você tomou em resposta.
2.2 Vocabulário ATT&CK
Rotule as técnicas planejadas e as observadas. Cobertura é comunicação, não prova de segurança. Os IDs de técnica do ATT&CK dão a testadores e defensores nomes comuns para comportamentos, como T1046 Network Service Discovery ou T1078 Valid Accounts. No laboratório de cobertura, cinco de sete técnicas planejadas foram observadas, ou 71%. Esse número diz o que a avaliação exercitou, não qual risco permanece. As técnicas planejadas que não foram vistas entram no próximo plano autorizado, em vez de serem testadas por conta própria. Use uma única versão fixada do ATT&CK para todos os rótulos, para que as marcações continuem comparáveis ao longo do estudo.
2.3 Achados sem payloads
Pratique escrever achados como título, ativo afetado, referência de evidência, impacto, probabilidade e recomendação — nunca como receitas de exploração. O laboratório de achados pontua cada achado sintético como impacto vezes quatro, mais explorabilidade vezes dois, mais exposição. O SYN-001, uma senha padrão de administrador na interface web de staging, pontua 20 e é crítico; o SYN-002, cabeçalhos ausentes no site público, pontua 9 e é médio. Nenhuma das entradas diz como explorar coisa alguma. Quem remedia precisa do ativo, da referência de evidência e da correção, não do ataque. O SYN-005, uma conta de serviço do laboratório com direitos de administrador de domínio, pontua 17 e também é crítico.
2.4 Guiado por ameaças versus checklist
O TIBER-EU e o CBEST enfatizam cenários guiados por inteligência para serviços financeiros críticos. O PTES e o WSTG apoiam uma cobertura técnica estruturada. Uma dissertação deve dizer qual lógica usa. O estudo de Noah usa a lógica estruturada: achados sintéticos de avaliações de treinamento em segmentos da CBM, registrados em tickets. Ele não toma emprestada nenhuma fase de inteligência de ameaças, então seus resultados nada dizem sobre testes guiados por inteligência de serviços financeiros em produção. Declarar isso cedo impede que os leitores suponham que a comparação se aplica a engajamentos TIBER-EU ou CBEST, e molda o capítulo de limitações.
2.5 A arte do feedback
Questões maiores mudam conclusões; questões menores dão acabamento. Cite evidências quando discordar.
"""ATT&CK-style coverage matrix over synthetic authorized techniques (names only)."""
# Synthetic engagement log: technique_id -> observed (True/False)
PLAN = ["T1046", "T1595", "T1082", "T1083", "T1059", "T1078", "T1021"]
OBSERVED = {"T1046", "T1595", "T1082", "T1083", "T1078"}
LABELS = {
"T1046": "Network Service Discovery",
"T1595": "Active Scanning",
"T1082": "System Information Discovery",
"T1083": "File and Directory Discovery",
"T1059": "Command and Scripting Interpreter",
"T1078": "Valid Accounts",
"T1021": "Remote Services",
}
covered = 0
for tid in PLAN:
hit = tid in OBSERVED
covered += hit
print(f"{tid} {LABELS[tid]:34} {'COVERED' if hit else 'PLANNED-NOT-SEEN'}")
print(f"coverage={covered}/{len(PLAN)} ({100*covered/len(PLAN):.0f}%)")
Saída esperada:
T1046 Network Service Discovery COVERED
T1595 Active Scanning COVERED
T1082 System Information Discovery COVERED
T1083 File and Directory Discovery COVERED
T1059 Command and Scripting Interpreter PLANNED-NOT-SEEN
T1078 Valid Accounts COVERED
T1021 Remote Services PLANNED-NOT-SEEN
coverage=5/7 (71%)
"""Score synthetic findings for report priority (no exploit details)."""
# impact 0-3, exploitability 0-3, exposure 0-3 -> priority
findings = [
("SYN-001", "default admin password on staging web UI", 3, 3, 2),
("SYN-002", "missing security headers on public site", 1, 1, 3),
("SYN-003", "outdated TLS on internal admin port", 2, 2, 1),
("SYN-004", "verbose error messages disclose paths", 1, 2, 2),
("SYN-005", "service account with domain admin in lab AD", 3, 2, 1),
]
def priority(impact, exploitability, exposure):
score = impact*4 + exploitability*2 + exposure
if score >= 16: return "critical", score
if score >= 11: return "high", score
if score >= 7: return "medium", score
return "low", score
for fid, title, i, e, x in findings:
p, s = priority(i, e, x)
print(f"{fid} priority={p:8} score={s:2} impact={i} exploitability={e} exposure={x} :: {title}")
Saída esperada:
SYN-001 priority=critical score=20 impact=3 exploitability=3 exposure=2 :: default admin password on staging web UI
SYN-002 priority=medium score= 9 impact=1 exploitability=1 exposure=3 :: missing security headers on public site
SYN-003 priority=high score=13 impact=2 exploitability=2 exposure=1 :: outdated TLS on internal admin port
SYN-004 priority=medium score=10 impact=1 exploitability=2 exposure=2 :: verbose error messages disclose paths
SYN-005 priority=critical score=17 impact=3 exploitability=2 exposure=1 :: service account with domain admin in lab AD
Um comentário maior útil sobre a ideia de Noah é que a qualidade das marcações não é medida; um comentário menor útil é que a versão do ATT&CK deveria ser nomeada. Ambos são específicos e acionáveis. Um feedback que só elogia não dá a quem apresenta nada para corrigir. Quando discordar, aponte a fonte, os dados ou a saída de laboratório que sustentam a sua visão. Separe com clareza o maior do menor, para que quem apresenta saiba quais comentários precisam ser respondidos antes de o desenho ser fixado.
2.5b Comparar frameworks num único slide
Um slide de seminário útil tem três colunas: a pergunta que o framework responde, o artefato que ele espera (ROE, cenário, caso de teste) e um modo de falha (teatro do checklist, teatro da inteligência, teatro da cobertura). Os estudantes saem sabendo quando não forçar o encaixe de um framework. Por exemplo, o ATT&CK responde o que um adversário pode fazer, espera observações no nível de técnica e falha quando porcentagens de cobertura são lidas como segurança. Mantenha cada coluna em uma linha. Desenhe as mesmas três colunas para o PTES, o WSTG, o TIBER-EU e o CBEST. O slide de Noah mostra que o estudo dele se encaixa melhor na lógica do PTES e do WSTG, e diz com franqueza onde o ATT&CK não consegue nomear uma falha de processo.
2.5c Ler um framework de forma crítica
Cada framework embute um pressuposto que você deve testar antes de citá-lo numa dissertação. O PTES pressupõe um cliente capaz de declarar o impacto no negócio antes de o teste começar; na Cedar Bridge Mutual, a equipe de sinistros não conseguiu, então a reunião de escopo de Noah produziu uma lista de processos críticos (entrada de sinistros, aprovação de pagamentos) em vez de hosts. O ATT&CK pressupõe que o comportamento pode ser nomeado na granularidade de técnica; um achado sobre uma etapa de aprovação ausente nos pagamentos não tem técnica, e forçar uma (T1078, Valid Accounts) esconderia a falha de processo. O TIBER-EU pressupõe uma fase de inteligência de ameaças conduzida pelo regulador; uma seguradora de porte médio fora desse regime toma emprestada a estrutura, mas precisa dizer isso. Escreva cada pressuposto como uma frase no seu capítulo de métodos e declare se ele se confirmou no seu contexto.
2.6 Exemplo resolvido (caso sintético da CBM)
Noah apresenta a marcação ATT&CK como intervenção de relato. Os pares observam que a qualidade das marcações pode variar. O laboratório de cobertura mostra 71% de um conjunto planejado observado; o laboratório de achados classifica o SYN-001 como crítico sem descrever um caminho de exploração. O comentário dos pares sobre a qualidade das marcações muda o desenho: Noah planeja uma auditoria das marcações em relação às definições do ATT&CK. O número de cobertura de 71% é relatado como aquilo que a avaliação exercitou. O SYN-001 é classificado como crítico, com pontuação 20, e a entrada do relatório traz o ativo, a referência de evidência e a correção, sem caminho de exploração.
2.7 Erros e limites
Três erros são comuns: seminários que demonstram ataques; feedback que só elogia; e tratar a % de cobertura como risco residual. Cada erro prejudica o seminário. Demonstrações de ataque espalham detalhes de uso dual e rompem o limite do curso. Um feedback que só elogia deixa desenhos fracos sem contestação até que os examinadores encontrem os problemas. Ler a cobertura como risco residual transforma a descrição do que foi exercitado numa falsa alegação de segurança, o erro contra o qual o laboratório de cobertura alerta. Verifique os três pontos no seu plano de seminário e no seu feedback. Um revisor de fora do seminário consegue identificá-los depressa.
Exercícios
- EX008 — Apresentação — Esboce um seminário de 10 minutos sobre o PTES. Rubrica: 3 = alegação, fases, limites, reaproveitamento; 2 = três; 1 = um; 0 = nenhum.
- EX009 — Cobertura — Interprete com ética as linhas planejadas e não vistas. Rubrica: 3 = próximo trabalho autorizado, não ação por conta própria; 2 = parcial; 1 = atacar agora; 0 = nenhuma.
- EX010 — Achado — Reescreva o SYN-005 como entrada de relatório (sem passos de exploração). Rubrica: 3 = ativo, impacto, referência de evidência, recomendação; 2 = três; 1 = passos; 0 = nenhuma.
- EX011 — Guiado por ameaças — Quando um teste no estilo CBEST é mais apropriado que um teste web por checklist? Rubrica: 3 = serviços críticos, guiado por inteligência, supervisão; 2 = dois; 1 = um; 0 = nenhum.
- EX012 — Feedback — Escreva um comentário maior e um menor sobre a ideia de Noah. Rubrica: 3 = ambos específicos; 2 = um; 1 = vago; 0 = nenhum.
- EX013 — WSTG — O que o WSTG acrescenta que o ATT&CK não oferece? Rubrica: 3 = casos e procedimentos de teste web para aplicações web autorizadas; 2 = parcial; 1 = vaga; 0 = errada.
- EX014 — Uso dual — Por que proibir demonstrações de exploração no seminário? Rubrica: 3 = uso dual, ética, limite do curso; 2 = dois; 1 = um; 0 = nenhum.
Síntese
Os hábitos de seminário e de literatura transformam a prática de red team em perguntas pesquisáveis com limites éticos.
Continue estudando — capítulo 02 de 08
← Capítulo 01 (rascunho) · Índice de capítulos do curso · Capítulo 03 (rascunho) →