Capítulo 4 — Escrita acadêmica
Mapa da aula
Aula 04 publicada. Mapa, exemplo, EX010.
flowchart TD
N0["4.1 Achados sem culpa"]
N1["4.2 Fato vs afirmação"]
N2["4.3 Citações"]
N3["4.4 Camadas de público"]
N4["4.5 Estrutura"]
N5["4.6 Revisão"]
N6["4.7 Nota aplicada"]
N7["4.8 Passagem pelo público"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX010"]
Desenho lógico
flowchart LR
N0["4.1 Achados sem culpa"]
N1["4.2 Fato vs afirmação"]
N2["4.3 Citações"]
N3["4.4 Camadas de público"]
N4["4.5 Estrutura"]
N5["4.6 Revisão"]
N6["4.7 Nota aplicada"]
N7["4.8 Passagem pelo público"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX010"]
[4.1 Achados sem culpa]
|
v
[4.2 Fato vs afirmação]
|
v
[4.3 Citações]
|
v
[4.4 Camadas de público]
|
v
[4.5 Estrutura]
|
v
[4.6 Revisão]
|
v
[4.7 Nota aplicada]
|
v
[4.8 Passagem pelo público]
|
v
[Exemplo resolvido] --> [Exercício EX010]
Objetivos de aprendizagem
Você vai (1) escrever achados sem culpabilização; (2) separar fatos de afirmações; (3) citar frameworks corretamente.
4.1 Achados sem culpa
"Conta de administrador compartilhada no sistema de empréstimos" é melhor que "administradores preguiçosos". Conselhos financiam correções; insultos criam inimigos. Um achado que nomeia uma fraqueza, sua localização e sua consequência dá ao dono algo para corrigir. Um achado que nomeia um grupo de pessoas dá a elas algo para defender. Sam escreve o achado da conta de administrador compartilhada com o sistema, a conta, o que os logs conseguem e não conseguem atribuir e uma mudança recomendada, e deixa os julgamentos de caráter totalmente de fora, porque o mesmo relatório será lido pelas pessoas que precisam fazer o trabalho.
4.2 Fato vs afirmação
Fato: a camada web abriu uma sessão TCP com o ledger-db. Afirmação: "atacantes podem movimentar dinheiro" precisa de mais evidência ou é rotulada como especulativa. A conexão em si é observada e registrada em log; a afirmação sobre movimentar dinheiro depende do que o ledger-db aceitaria dessa sessão, o que o teste não explorou. Sam escreve o fato no achado e, ou rotula a afirmação maior como especulativa, ou lista a evidência que seria necessária para sustentá-la. Os leitores podem então pesar cada frase pela sua evidência, e não pelo seu tom.
4.3 Citações
NIST SP 800-115, PTES, ATT&CK, OWASP WSTG, TIBER-EU e CBEST são citados com os títulos corretos. Nunca invente DOIs. Cada citação é conferida na página do editor antes que o relatório saia, e a edição ou versão importa: o SP 800-115 é citado como o guia técnico do NIST para testes e avaliações, não como uma regulação. Se Sam não consegue encontrar o identificador oficial de uma fonte, ele cita o título e a URL e não diz mais nada. Um DOI inventado minaria toda frase verdadeira perto dele.
4.4 Camadas de público
Executivos precisam de decisões; engenheiros precisam de reprodução; ambos precisam de honestidade sobre a incerteza. Para o achado da conta de administrador compartilhada, o CISO precisa da decisão (financiar contas nominais para o sistema de empréstimos), o engenheiro precisa do nome do sistema, da conta e da lacuna de logs, e ambos precisam do mesmo enunciado sobre o que não foi testado. Sam escreve o sumário executivo e o apêndice técnico a partir do mesmo registro de achado, para que eles não possam se distanciar. A incerteza, como os hosts não testados, entra nas duas partes com as mesmas palavras.
4.5 Estrutura
Sumário, escopo/métodos, achados, pontos positivos, limitações, apêndices. A ordem é deliberada. Um leitor que para depois do sumário ainda sabe qual decisão foi pedida; escopo e métodos dizem a todos o que foi e o que não foi testado antes que qualquer achado seja lido; os pontos positivos registram o que se manteve, como o SWIFT continuar inalcançável; as limitações impedem que o relatório seja lido como uma garantia. Os apêndices trazem os hashes, os IDs de tickets e os cartões de método que permitem a um engenheiro reproduzir cada etapa. Sam usa essa estrutura em todo relatório do TRB.
4.6 Revisão
A revisão por pares pega jargão e afirmações exageradas antes que o CISO veja o rascunho. O revisor de Sam lê procurando duas coisas: palavras que um não especialista não entenderia e frases que afirmam mais do que a evidência mostra, como "atacantes podem movimentar dinheiro" no lugar da conexão observada com o ledger-db. Cada comentário é respondido no histórico do rascunho, de modo que o relatório final mostra o que mudou e por quê antes que o CISO o receba. Comentários não resolvidos bloqueiam a liberação; os resolvidos continuam visíveis. O CISO recebe apenas a versão revisada, então rascunhos exagerados como "atacantes podem movimentar dinheiro" nunca chegam ao CISO.
4.7 Nota aplicada
Os exercícios de citação exigem abrir a página viva do NIST ou do PTES, não o resumo de um blog. Sam reprovou um rascunho inicial por citar uma paráfrase de segunda mão do SP 800-115 que inventava uma cláusula. Só fontes primárias — a mesma regra de nunca inventar DOIs. A página do NIST também mostra o status e a data do documento. Sam agora registra, ao lado de cada citação no rascunho, a data em que abriu a página primária e a seção em que se apoiou. Os revisores podem então conferir uma afirmação contra a mesma página, em vez de confiar na memória dele.
4.8 Passagem pelo público
Antes de enviar, Sam lê o sumário executivo em voz alta para alguém de fora da segurança. Se a pessoa não consegue reformular a decisão pedida, ele reescreve. Jargão que sobrevive a essa passagem é um defeito. A reformulação do ouvinte é anotada no histórico do rascunho para comparação posterior. No relatório da conta de administrador compartilhada, um ouvinte de finanças reformulou o pedido como "pagar por contas nominais no sistema de empréstimos", o que bateu. Um rascunho anterior tinha produzido "alguma coisa sobre senhas", o que o mandou de volta para reescrita. O ouvinte de finanças foi escolhido de propósito.
4.9 Auditoria da voz passiva
Achados que escondem os agentes na voz passiva são reescritos. "Senhas foram reutilizadas" vira "A conta de administrador de empréstimos usava a mesma senha da VPN", quando isso é conhecido. Nomear o sistema torna o achado acionável e testável. Quando o agente não é conhecido, a frase diz isso claramente, por exemplo "os logs não mostram qual administrador mudou a configuração". Isso mantém o achado honesto sem inventar um culpado e aponta direto para a lacuna de logs como uma segunda questão a corrigir. Corrigir o rascunho "os desenvolvedores ignoraram a segurança" exigiu apenas uma frase reescrita que nomeava o sistema e o log ausente.
4.10 Reescrevendo um achado acusatório
Um rascunho de achado certa vez dizia "os desenvolvedores ignoraram a segurança". O jurídico pediu reescrita antes do material do conselho. Sam produziu: "O serviço de empréstimos aceitava uma senha privilegiada compartilhada; os logs não conseguem atribuir mudanças a uma pessoa." Os mesmos fatos, num tom financiável. Ele guarda as duas versões nas notas de ensino para mostrar a diferença. A reescrita remove a acusação, mas mantém todos os fatos: uma senha privilegiada compartilhada e nenhuma atribuição nos logs. É por isso que ela sobreviveu à revisão jurídica e ainda disse aos donos do serviço de empréstimos exatamente o que mudar.
Os troféus de tom são adesivos bobos em achados impressos que os desenvolvedores elogiaram como claros. Sam prefere adesivos a métricas que ninguém lê. Cada adesivo registra qual achado foi elogiado e por quê, para que o próximo relatório possa copiar a clareza, e não apenas o adesivo. Clareza que os desenvolvedores notam é clareza que gera correções. Sam guarda os achados elogiados numa pasta como exemplos para estagiários. A contagem de achados fica em segundo plano nos relatórios de Sam, porque um achado claro que é corrigido importa mais que uma lista longa.
Exemplo resolvido (TRB sintético)
Sam reescreve "a equipe web é incompetente" como "a camada web alcança o ledger-db por um fluxo não aprovado; controle: impor a matriz aprovada".
Caso sintético — Riverstone Transit Bank (TRB). O banco, Sam Ito, TrackScope/FindingsDesk/PulseMap e todos os números são inventados para fins didáticos.
Erros e limites
Este livro não concede nenhuma autoridade para testar bancos ou sistemas de pagamento reais. Os laboratórios usam apenas endereços de faixas de documentação e dados sintéticos; código de exploit nunca é fornecido.
Exercícios
- EX010 — Reescrita. Transforme "reutilização estúpida de senhas" em linguagem profissional de achado. Rubrica: 3 = condição do sistema + impacto + nenhum insulto; 2 = parcial; 1 = mantém o insulto; 0 = nada.
- EX011 — Afirmação especulativa. Como Sam deve rotular "atacantes já roubaram fundos"? Rubrica: 3 = especulativa/não confirmada; separada dos fatos; 2 = parcial; 1 = como fato; 0 = nada.
- EX012 — Regra de citação. O que Sam nunca pode inventar ao citar? Rubrica: 3 = DOIs / referências falsas; 2 = parcial; 1 = vago; 0 = nada.
Síntese
Uma escrita clara, citada e atenta ao público faz parte do ofício dos testes autorizados.
Continue estudando — capítulo 04 de 40
← Capítulo 03 (rascunho) · Índice de capítulos do curso · Capítulo 05 (rascunho) →