◇ OpenCyber Academy
Engenharia · Capítulo 5 · Português

Capítulo 5 — Comunicação em engenharia

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 5 — Comunicação em engenharia

Mapa da aula

Aula 05 publicada. Mapa, exemplo, EX013.

flowchart TD
  N0["5.1 Públicos"]
  N1["5.2 Chamados"]
  N2["5.3 Documentos de projeto"]
  N3["5.4 Gráficos honestos"]
  N4["5.5 Palavras para a incerteza"]
  N5["5.6 Caso"]
  N6["Revisão antes do envio"]
  N7["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX013"]

Desenho lógico

flowchart LR
  N0["5.1 Públicos"]
  N1["5.2 Chamados"]
  N2["5.3 Documentos de projeto"]
  N3["5.4 Gráficos honestos"]
  N4["5.5 Palavras para a incerteza"]
  N5["5.6 Caso"]
  N6["Revisão antes do envio"]
  N7["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX013"]

[5.1 Públicos]
    |
    v
[5.2 Chamados]
    |
    v
[5.3 Documentos de projeto]
    |
    v
[5.4 Gráficos honestos]
    |
    v
[5.5 Palavras para a incerteza]
    |
    v
[5.6 Caso]
    |
    v
[Revisão antes do envio]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX013]

Objetivos de aprendizagem

Você vai (1) escrever notas técnicas, chamados e documentos de projeto claros; (2) adaptar a comunicação a analistas, gestores e clientes; (3) apresentar dados com honestidade em tabelas e gráficos; (4) usar linguagem precisa para a incerteza.

5.1 Públicos

Analistas precisam de campos e horários exatos; gestores precisam de impacto e decisões; clientes precisam saber o que aconteceu e o que fazer. Um incidente produz vários documentos, cada um escrito para seu leitor. Escrever um único documento para os três falha com todos eles: os analistas perdem detalhes, os gestores se afogam neles, os clientes recebem jargão. Amara começa cada texto perguntando o que o leitor precisa fazer depois de lê-lo. Essa pergunta decide o que incluir, dos nomes de campo para o analista a uma única decisão recomendada para o gestor.

5.2 Chamados

Um bom chamado de SOC declara o que foi observado, quando (com fuso horário), em quais ativos, o que foi feito e o que ainda é desconhecido. Knerler, Parker e Zimmerman (2022) enfatizam a comunicação clara como uma estratégia de SOC por si só. Declarar o que é desconhecido é a parte mais pulada, mas é ela que diz ao próximo turno onde procurar. Um horário sem fuso obriga o leitor a adivinhar, e um palpite errado pode reordenar a história. Os ativos devem ser nomeados pelos identificadores usados no inventário de ativos, para que outras equipes os encontrem sem precisar perguntar.

5.3 Documentos de projeto

Mudanças de engenharia, como uma nova detecção, precisam de um documento de projeto curto: problema, proposta, alternativas, riscos, plano de testes e reversão. Escrever as alternativas obriga o autor a mostrar por que a proposta supera outras opções, e não apenas que ela funciona. Um plano de testes declara como se vai mostrar que a detecção dispara no comportamento-alvo e fica em silêncio na atividade normal. A reversão explica como remover a mudança depressa se ela inundar a fila depois da implantação. Paolo revisa cada documento antes de a regra entrar em produção.

5.4 Gráficos honestos

Os gráficos devem começar os eixos de contagens no zero, rotular unidades e fusos horários e evitar suavizar picos que importam. Um eixo de contagem que começa em 900 pode fazer uma alta de 950 para 1.000 parecer uma duplicação. Fusos horários sem rótulo podem deslocar um pico para o turno errado. Suavizar com uma média móvel longa deixa as linhas de tendência arrumadas, mas pode apagar justamente a rajada que um gráfico de incidente deveria mostrar, por isso as contagens brutas devem aparecer ao lado de qualquer linha suavizada. As legendas declaram a fonte dos dados.

5.5 Palavras para a incerteza

"Confirmado", "provável" e "possível" devem ser usados de forma consistente. A equipe de Amara os define num guia de estilo para que os leitores saibam quão seguro o autor está. Sem significados acordados, o "provável" de um autor é o "possível" de outro, e um gestor pode agir com base numa afirmação mais forte do que a evidência sustenta. O guia de estilo liga cada palavra à evidência esperada: "confirmado" exige evidência direta, como uma entrada de log; "provável" exige vários indicadores consistentes; e "possível" marca uma pista ainda não verificada. O guia cabe numa página.

5.6 Caso

Depois da rajada no portal, Amara escreve três peças: o chamado para os analistas, um resumo para o gestor e um rascunho de aviso ao cliente dono da conta u5, revisados por Paolo e pela equipe de comunicação. O chamado lista as contagens de falhas, a rede, o horário do login bem-sucedido de u5 e as ações da sessão, com os horários em UTC. O resumo para o gestor dá o impacto em duas frases e declara o que já foi feito e a mudança agora proposta. O aviso ao cliente explica em palavras simples que foi vista uma atividade de acesso incomum e o que o cliente deve fazer.

Revisão antes do envio

Tudo o que sai do SOC é revisado por uma segunda pessoa: uma confere os fatos contra o chamado, a outra confere o tom e a clareza. Nos avisos a clientes, a equipe de comunicação aprova a redação final, porque um aviso enganoso pode fazer mais mal do que o próprio incidente. Amara guarda as versões revisadas junto com o chamado.

Exemplo resolvido

O resumo de Amara para o gestor: "Na segunda-feira, das 10:05 às 10:06 UTC, cerca de 600 tentativas de login a partir de uma rede miraram contas do portal do cliente. Uma conta de cliente foi acessada com sucesso e foi bloqueada; o cliente foi contatado. Nenhum sistema de funcionários foi afetado. Propõe-se uma mudança no limite de taxa."

Caso sintético. O incidente e os textos são inventados.

Erros e limites

Escrita clara não conserta fatos errados; confira os números contra as fontes antes de enviar.

Exercícios

Síntese

Comunique para cada leitor, com incerteza precisa e gráficos honestos; a clareza faz parte da engenharia de SOC.

Continue estudando — capítulo 05 de 50

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