OpenCyber Academy
Engenharia · Capítulo 25 · Português
Código do curso: OCA-130Capítulo 25: OCA-130-C025

Capítulo 25 — Ateliê de projeto I

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 25 publicada. Mapa, exemplo, EX073.

flowchart TD
  N0["25.1 O problema do ateliê"]
  N1["25.2 Gerando alternativas"]
  N2["25.3 Critérios"]
  N3["25.4 Crítica no ateliê"]
  N4["25.5 Iteração"]
  N5["25.6 Documentação"]
  N6["25.7 Trabalho em equipe"]
  N7["Privacidade no projeto"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX073"]

Desenho lógico

flowchart LR
  N0["25.1 O problema do ateliê"]
  N1["25.2 Gerando alternativas"]
  N2["25.3 Critérios"]
  N3["25.4 Crítica no ateliê"]
  N4["25.5 Iteração"]
  N5["25.6 Documentação"]
  N6["25.7 Trabalho em equipe"]
  N7["Privacidade no projeto"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX073"]

[25.1 O problema do ateliê]
    |
    v
[25.2 Gerando alternativas]
    |
    v
[25.3 Critérios]
    |
    v
[25.4 Crítica no ateliê]
    |
    v
[25.5 Iteração]
    |
    v
[25.6 Documentação]
    |
    v
[25.7 Trabalho em equipe]
    |
    v
[Privacidade no projeto]
    |
    v
[Exemplo resolvido] --> [Exercício EX073]

Objetivos de aprendizagem

Você vai (1) trabalhar em equipe num problema aberto de projeto de SOC; (2) gerar e comparar projetos alternativos; (3) apresentar um projeto com sua justificativa; (4) responder à crítica num ambiente de ateliê.

25.1 O problema do ateliê

As equipes projetam o monitoramento das redes dos depósitos da Lindqvist, onde os leitores portáteis e as estações de trabalho antigas não conseguem rodar agentes. O projeto precisa detectar conexões incomuns dos depósitos para os sistemas de negócio. Conexões incomuns podem incluir um leitor conversando com um servidor do financeiro, ou uma estação de trabalho de depósito alcançando sistemas que nunca usou antes. Sem agentes, o projeto precisa se apoiar na observação da rede. As equipes também precisam considerar que os depósitos diferem em tamanho e conectividade, de modo que um único projeto precisa funcionar num pequeno depósito rural e num grande centro de distribuição.

25.2 Gerando alternativas

A equipe de Amara lista três opções: monitoramento de fluxos na fronteira entre depósitos e negócio; um sensor de detecção de rede com análise de protocolos; e o aperto das regras de firewall, com registro das conexões negadas. Listar várias opções antes de avaliar qualquer uma impede que a primeira ideia vire a única. As três diferem em natureza: uma observa fluxos, uma inspeciona conteúdo, uma restringe o tráfego e registra as recusas. Cada uma tem custos e pontos cegos diferentes, que a comparação por critérios vai evidenciar, e uma solução híbrida pode surgir quando as peças forem compreendidas.

25.3 Critérios

Eles comparam as opções em visibilidade, custo, carga operacional, privacidade e modos de falha, usando uma tabela ponderada. A visibilidade pergunta o que cada opção consegue ver; o custo inclui hardware, licenças e tempo da equipe; a carga operacional pergunta quem a mantém; a privacidade considera se o conteúdo do tráfego dos funcionários é coletado; os modos de falha perguntam o que acontece quando ela quebra. Os pesos são acordados antes da pontuação, e cada nota cita uma evidência, como uma folha de dados do fornecedor ou uma medição. A privacidade tem peso alto porque os funcionários dos depósitos usam a mesma rede para mensagens pessoais nos intervalos, e a política de monitoramento da empresa limita a coleta de conteúdo.

25.4 Crítica no ateliê

Cada equipe apresenta por dez minutos; colegas e professores contestam as suposições. O ateliê valoriza o raciocínio claro mais do que slides bem acabados. A crítica mira o projeto, não as pessoas. Contestações típicas são "o que acontece se o sensor falhar?" ou "como vocês vão saber que as regras funcionam?". Slides com diagramas impressionantes, mas sem raciocínio, recebem notas baixas. Os professores anotam fraquezas recorrentes entre as equipes e as tratam na aula seguinte. O retorno é escrito em cartões e entregue a cada equipe depois de sua vez, para que os comentários não se percam e os alunos mais calados também possam contribuir.

25.5 Iteração

Depois da crítica, as equipes revisam. A equipe de Amara descobre que o firewall da fronteira já registra os fluxos permitidos e negados; combinar os logs do firewall com um pequeno número de regras de permissão sai mais barato do que um novo sensor. A descoberta veio de perguntar à equipe de TI dos depósitos durante a crítica, o que mostra o valor de envolver quem conhece os sistemas existentes. Usar os logs que o firewall já produz custa quase nada em hardware. Regras de permissão estritas reduzem o tráfego normal a uma lista curta, de modo que qualquer fluxo negado ou inesperado se destaca com clareza nos logs.

25.6 Documentação

O projeto final inclui um diagrama, os fluxos de dados, os requisitos atendidos, os riscos e um plano de testes. O diagrama mostra de onde vêm os logs e para onde vão; os fluxos de dados dão formatos e volumes; os requisitos atendidos remetem ao enunciado; os riscos dizem o que pode dar errado; o plano de testes mostra como o projeto será comprovado. Um revisor que não assistiu à apresentação deve entender o projeto só pelo documento. A equipe de Amara limita o documento a seis páginas. Os apêndices guardam os detalhes.

25.7 Trabalho em equipe

Os papéis se revezam: apresentador, relator, crítico. Todos explicam todas as partes. Revezar os papéis impede que um membro confiante apresente tudo enquanto os outros ficam calados. O relator registra decisões e críticas; o crítico procura fraquezas antes que pessoas de fora o façam. Exigir que todos expliquem todas as partes significa que os professores podem questionar qualquer membro, o que revela se o entendimento é compartilhado ou está nas mãos de uma única pessoa. No fim, cada membro escreve uma nota curta sobre o que contribuiu e o que aprendeu com outro membro, que os professores leem junto com o projeto da equipe.

Privacidade no projeto

Os dispositivos dos depósitos são usados por motoristas e funcionários do armazém. O projeto registra apenas metadados das conexões, não o conteúdo, e os guarda por 30 dias, o que o responsável pela privacidade revisa e aprova. As equipes incluem essas revisões no plano, em vez de acrescentá-las no fim.

Exemplo resolvido

O projeto final da equipe: restringir o tráfego entre depósitos e negócio a cinco serviços necessários, registrar todas as tentativas negadas, alertar quando um dispositivo de depósito tentar um destino novo mais de três vezes numa hora e revisar semanalmente. Custo estimado: apenas tempo de configuração. Risco principal: falha da alimentação de logs do firewall, coberta por monitoramento de heartbeat.

Caso sintético. O ateliê e os projetos são inventados.

Erros e limites

Os projetos do ateliê não foram testados; o laboratório do capítulo 30 os verifica.

Exercícios

Síntese

Os ateliês ensinam projeto por meio de alternativas, critérios e crítica; o bom projeto mais barato muitas vezes reaproveita o que já existe.

Continue estudando — capítulo 25 de 50

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

Respostas comentadas

EX073. Monitoramento de fluxos na fronteira, um sensor de detecção de rede e regras de firewall mais estritas com registro das conexões negadas.

EX074. Descobriram que o firewall da fronteira já registrava os fluxos, então os logs do firewall com regras de permissão superaram a compra de um sensor.

EX075. Permitir cinco serviços, registrar as negações, alertar quando um dispositivo de depósito tentar um destino novo mais de três vezes numa hora, revisar semanalmente; o risco principal é a falha da alimentação de logs.