OpenCyber Academy
Técnico · Capítulo 18 · Português
Código do curso: OCA-065Capítulo 18: OCA-065-C018

Capítulo 18 — Projeto técnico supervisionado

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 18 publicada. Mapa, exemplo, EX069.

flowchart TD
  N0["18.1 Briefing do projeto"]
  N1["18.2 Apresentação"]
  N2["18.3 Passagem"]
  N3["18.5 Próximo curso"]
  N4["18.6 Folha de rosto de segurança"]
  N5["18.7 Higiene do repositório"]
  N6["18.8 Ciclo de retorno"]
  N7["18.9 Disciplina de campo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX069"]

Desenho lógico

flowchart LR
  N0["18.1 Briefing do projeto"]
  N1["18.2 Apresentação"]
  N2["18.3 Passagem"]
  N3["18.5 Próximo curso"]
  N4["18.6 Folha de rosto de segurança"]
  N5["18.7 Higiene do repositório"]
  N6["18.8 Ciclo de retorno"]
  N7["18.9 Disciplina de campo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX069"]

[18.1 Briefing do projeto]
    |
    v
[18.2 Apresentação]
    |
    v
[18.3 Passagem]
    |
    v
[18.5 Próximo curso]
    |
    v
[18.6 Folha de rosto de segurança]
    |
    v
[18.7 Higiene do repositório]
    |
    v
[18.8 Ciclo de retorno]
    |
    v
[18.9 Disciplina de campo]
    |
    v
[Exemplo resolvido] --> [Exercício EX069]

Objetivos de aprendizagem

Você vai (1) entregar um pequeno projeto de teste autorizado sobre dados sintéticos da NMT; (2) apresentá-lo a um supervisor; (3) passar adiante os runbooks; (4) declarar os limites que permanecem.

18.1 Briefing do projeto

Usando apenas exportações sintéticas, produza: a comparação atualizada de portas aprovadas, dois achados validados com hashes de evidência, um relato de reteste e uma melhoria de runbook. O briefing do projeto pede um pacote com escopo no estilo ENG para a NMT sintética — diagrama, lista de verificação das ROE, resultado do lab_ports, hashes, reteste com FIXED/STILL OPEN e registro do exercício de parada. Nada de sondagens de tarifa, nada de dados de produção. As duas listas descrevem o mesmo pacote por dois ângulos: as entregas acima são o que o supervisor avalia, e o briefing nomeia os artefatos que precisam sustentá-las. Cada item é construído a partir das exportações sintéticas, com a rede de tarifas intocada.

18.2 Apresentação

Quinze minutos para o supervisor e um observador do SOC. A apresentação de Sam abre com as exclusões e os itens ainda abertos, como o F2, e só então passa às evidências. Slides que elogiam ferramentas sem hashes por trás reprovam na etapa da apresentação; qualquer elogio a ferramentas vai para um apêndice. O observador do SOC confere se o caminho de parada mostrado nos slides corresponde ao que o SOC de fato recebeu durante a janela. As perguntas do supervisor sobre qualquer item aberto são respondidas a partir das evidências, e não da memória.

18.3 Passagem

Runbooks e scripts no repositório da equipe, com versões. A passagem também inclui o caminho do cofre, os itens abertos e os contatos de emergência. O e-mail sozinho é uma transferência incompleta, então uma demonstração no jump host é agendada, e a lista de transferência exige o convite de calendário como anexo para provar que a demonstração foi marcada, e não apenas prometida. A demonstração permite ao técnico que recebe ver as ferramentas funcionando e fazer perguntas antes de assumir o trabalho. Ela também confirma que quem recebe consegue abrir o caminho do cofre antes que Sam se afaste.

18.4 Limites

Sam ainda não faz desenvolvimento de exploits nem projeto de cenários guiados por ameaças — temas de cursos mais longos. A página de limites declara que a rede de tarifas está fora do escopo, que todo o trabalho usou dados sintéticos e que Sam não tem autorização para testar sistemas reais. Cada limite aponta para a linha das ROE que o define, para que os examinadores possam verificar que a página não exagera a autoridade. Um colega revisa a redação dos limites antes da entrega, e os examinadores são orientados a ler esse apêndice primeiro, porque limites escondidos inventam uma cobertura que nunca existiu.

18.5 Próximo curso

Segurança de IA (066) é o próximo no caminho curricular. Dentro da própria trilha de red team, o próximo livro é o do nível de tecnólogo, que acrescenta profundidade em projeto e integração. Este livro técnico termina na competência procedimental sob ROE, então o trabalho pesado de projeto espera por esse curso. Antes que os concluintes sigam adiante, Sam diz a eles quais hábitos se transferem diretamente, como a disciplina de parada e o cálculo de hashes das evidências, e qual autoridade não se transfere para nenhum engajamento novo. O livro de segurança de IA citado acima continua sendo o próximo título no caminho curricular mais amplo, fora desta trilha.

18.6 Folha de rosto de segurança

A capa do projeto declara que ele é apenas sintético e sem varredura real. A folha de rosto de segurança repete as regras centrais: homologação primeiro, rede de tarifas em preto, as condições de parada e o prazo de exclusão da retenção. Ela é a página um do repositório do projeto, antes de qualquer código. Um robô de revisão verifica que ela é o primeiro arquivo que os revisores veem na árvore, e os merges falham se a capa estiver aninhada em outro lugar, para que ninguém leia os scripts sem antes ler os limites que os regem. Os avaliadores conferem a capa antes de qualquer outro arquivo da entrega.

18.7 Higiene do repositório

Os scripts do projeto entram no repositório da equipe sem credenciais, com README e cabeçalhos de licença conforme a política da NMT. A higiene do repositório proíbe segredos e inventários reais; só inventários sintéticos podem ser enviados. Um segredo no git reprova o projeto, seja qual for a qualidade dos achados, e o mesmo vale para um clone que contenha dados reais de inventário. O README precisa mostrar logo de início as instruções de desativação e de parada, para que qualquer pessoa que execute os scripts depois saiba como pará-los antes de saber como iniciá-los.

18.8 Ciclo de retorno

O retorno do supervisor vira duas edições de runbook em até uma semana — projeto concluído significa processo melhorado. Os comentários do supervisor viram correções de runbook na mesma semana, e Sam nunca arquiva retorno sem ler. Os links dessas correções da mesma semana são colados na nota de passagem do projeto. Uma nota de passagem sem eles é devolvida como incompleta até que os links estejam presentes, o que garante que o retorno mudou visivelmente o processo, em vez de ser reconhecido e esquecido. O supervisor pode então ver cada comentário ligado à mudança que produziu.

18.9 Disciplina de campo

A folha de rosto do projeto supervisionado tem uma página: declaração de uso apenas sintético, ID do engajamento do pacote de dados da sala de aula, lista de entregas com hashes, assinatura do supervisor e a declaração de limites de Sam. Sem a folha de rosto, o projeto está incompleto, mesmo que o trabalho técnico seja excelente. A disciplina de campo para o projeto é briefing, limites, folha de rosto de segurança, repositório limpo e STILL OPEN honesto. Esses cinco são o critério de aprovação. Um projeto que cumpre os cinco é aprovado mesmo quando relata itens abertos, enquanto um projeto a que falte um deles reprova, por mais polidos que pareçam seus achados.

18.10 Nota de encerramento

Depois da aceitação, Sam marca uma sessão de orientação de trinta minutos sobre os temas de controle de acesso do OWASP WSTG que ele quer aprofundar — o aprendizado contínuo faz parte da nota do projeto na NMT. O projeto prova que Sam consegue manter os hábitos do ENG-512 sem um professor na sala, e o crédito de portfólio exige artefatos que comprovem esses hábitos solo; a intenção não basta. Os artefatos são a evidência de que esses hábitos são reais: um pacote que mostra o exercício de parada, os hashes e os status de reteste honestos ganha a nota, enquanto a promessa de trabalhar assim não ganha.

18.11 Extra

A pergunta do observador do SOC costuma ser sobre detecção: Sam prepara uma técnica do ATT&CK e uma fonte de logs que recomendaria para cada achado. Como extra, Sam anexa as saídas do lab_ports e do lab_hash literalmente num apêndice. Assim, os examinadores podem reproduzir por conta própria as linhas NOT APPROVED, MATCH e MISMATCH e compará-las com os achados, sem precisar de uma reunião para perguntar como um resultado foi produzido. A saída literal também impede que um resumo suavize em silêncio um resultado que as ferramentas relataram de forma mais dura.

Exemplo resolvido (NMT sintética)

O projeto de Sam é aceito com elogios por deixar o F2 aberto e pelo desempenho no exercício de parada do Laboratório II. Ele arquiva a folha de rosto e o plano para o próximo curso.

Caso sintético — Northline Municipal Transit (NMT). A operadora de transporte, Sam Park e todos os números foram inventados para fins didáticos.

Erros e limites

Sistemas de transporte reais e equipamentos de tarifa nunca são testados sem uma autorização separada e especializada. Este livro usa apenas dados sintéticos e não concede autorização para testar sistemas reais.

Exercícios

Síntese

O projeto técnico comprova um ofício de teste disciplinado sobre dados sintéticos e limites honestos.

Continue estudando — capítulo 18 de 18

← Capítulo 17 (rascunho) · Índice de capítulos do curso · Resoluções ↓ · Próximo curso pelo índice de capítulos →

Respostas comentadas

EX069. Comparação de portas, dois achados validados com hashes, um relato de reteste e uma melhoria de runbook.

EX070. Isso mostra uma verificação honesta, em vez de chamados encerrados sem evidências.

EX071. Desenvolvimento de exploits ou liderar um engajamento guiado por ameaças no estilo CBEST/TIBER.

EX072. Segurança de IA.