Capítulo 5 — Letramento em segurança

Mapa da aula

Aula 05 publicada. Mapa, exemplo, EX013.

flowchart TD
  N0["5.1 Termos centrais"]
  N1["5.2 Prioridades num serviço essencial"]
  N2["5.3 Prevenir, detectar, recuperar"]
  N3["5.4 Ler incidentes públicos"]
  N4["5.6 Atividade prática: um cartão de controle"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX013"]

Desenho lógico

flowchart LR
  N0["5.1 Termos centrais"]
  N1["5.2 Prioridades num serviço essencial"]
  N2["5.3 Prevenir, detectar, recuperar"]
  N3["5.4 Ler incidentes públicos"]
  N4["5.6 Atividade prática: um cartão de controle"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX013"]

[5.1 Termos centrais]
    |
    v
[5.2 Prioridades num serviço essencial]
    |
    v
[5.3 Prevenir, detectar, recuperar]
    |
    v
[5.4 Ler incidentes públicos]
    |
    v
[5.6 Atividade prática: um cartão de controle]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX013]

Objetivos de aprendizagem e conexão

Depois deste capítulo, você deve ser capaz de:

• usar o vocabulário central — ativo, ameaça, vulnerabilidade, exposição, controle, risco, incidente, evidência — com precisão e consistência;
• explicar como as prioridades de segurança num serviço essencial diferem das de um escritório comum: a disponibilidade e a safety do serviço físico costumam vir primeiro;
• descrever um controle pelo que ele previne, detecta ou ajuda a recuperar, e pela evidência de que ele funciona;
• ler um relatório público de incidente em busca das suas lições sem transformá-lo numa técnica.

Os Capítulos 1–4 trataram de computação. Este capítulo fornece a linguagem comum que você vai usar com operadores, gestores, auditores e fornecedores pelo resto do livro. Palavras imprecisas causam falhas reais: "o CLP é seguro" não significa nada; "o CLP aceita escritas apenas da sub-rede do relay, verificado por uma revisão de fluxos em 3 de outubro" significa alguma coisa.

5.1 Termos centrais

• Ativo: qualquer coisa de valor para o serviço — um controlador de bomba, um historiador, uma credencial, um conjunto de dados, o conhecimento de uma pessoa.
• Ameaça: uma causa potencial de dano — um grupo criminoso, uma mudança descuidada, uma enchente, um fornecedor em dificuldades.
• Vulnerabilidade: uma fraqueza que uma ameaça poderia explorar — uma falha sem patch, uma senha compartilhada, um caminho não documentado, um backup não testado.
• Exposição: se uma ameaça consegue de fato alcançar a vulnerabilidade. Uma falha sem patch num dispositivo isolado está menos exposta que a mesma falha alcançável a partir da internet.
• Controle: uma medida que reduz o risco — técnica (uma regra de firewall), procedimental (uma aprovação de mudança) ou física (um armário trancado).
• Risco: a combinação de quão provável é o dano e de quão grave ele seria, para as pessoas que dependem do serviço. O Capítulo 13 torna isso concreto.
• Incidente: um evento que de fato prejudica, ou ameaça prejudicar, a confidencialidade, a integridade ou a disponibilidade — ou, na infraestrutura crítica, a safety.
• Evidência: um registro que permite a outra pessoa, que não você, conferir uma afirmação.

O Cybersecurity Framework 2.0 do NIST organiza os resultados em Govern, Identify, Protect, Detect, Respond e Recover (NIST CSWP 29); ele é um mapa útil do território, e não uma lista de verificação para ticar.

5.2 Prioridades num serviço essencial

A segurança da TI de escritório costuma ser descrita em termos de confidencialidade, integridade e disponibilidade, com a confidencialidade em primeiro lugar. Numa rede de água, num hospital ou num sistema de transporte, a ordem muda. A primeira preocupação costuma ser que o serviço físico continue e que ninguém se machuque; a integridade dos dados de controle e de medição vem logo atrás (um operador agindo sobre uma leitura falsa pode causar dano); a confidencialidade importa — prontuários de pacientes, dados de clientes, diagramas de rede —, mas raramente vale uma interrupção. O guia de TO do NIST discute como essas prioridades diferem para a tecnologia operacional (SP 800-82 Rev. 3).

Isso tem consequências práticas para um implementador. Um controle que pode parar um processo (um bloqueio automático numa estação de operador, uma reinicialização forçada para aplicar um patch) precisa de uma aprovação e de um momento diferentes na TO em relação a um escritório. Um controle que falha "fechado" na TI pode precisar falhar "aberto" num sistema relevante para a safety — e essa escolha precisa ser feita de forma deliberada por pessoas que entendem o processo, e não por padrão na configuração de um fornecedor.

5.3 Prevenir, detectar, recuperar

Classificar os controles pela função ajuda a ver lacunas. Os controles preventivos impedem que algo aconteça (autenticação, segmentação, allowlists). Os controles detectivos notam que está acontecendo (alertas, verificações de integridade, revisões). Os controles corretivos ou de recuperação restauram o serviço (backups, equipamentos sobressalentes, procedimentos de operação manual). Um serviço protegido apenas por controles preventivos não tem como notar quando eles falham; um com apenas controles detectivos nota o dano sem conseguir pará-lo ou desfazê-lo. Todo risco importante deve ter pelo menos um controle de cada tipo, e todo controle deve ter uma evidência declarada que mostre que ele funciona — e não apenas que está configurado.

5.4 Ler incidentes públicos

Os relatórios públicos de incidentes são o melhor material didático que a área tem, se lidos corretamente. Leia-os em busca das premissas que falharam e das lições: no que o operador acreditava que não era verdade? O alerta da CISA sobre o evento de 2021 na estação de tratamento de água de Oldsmar, na Flórida, descreveu software de acesso remoto, senhas compartilhadas e um sistema conectado à internet como condições a corrigir (CISA AA21-042A); um ex-funcionário municipal disse depois que o evento provavelmente foi erro de um empregado, e não uma intrusão (WUSF, 13 de abril de 2023). Os dois relatos ensinam a mesma lição ao implementador: o acesso remoto a um sistema de controle com credenciais compartilhadas e logs fracos torna impossível saber depois o que aconteceu. Note também a lição sobre evidência — um primeiro relato pode ser revisto.

5.5 Exemplo resolvido: reescrever afirmações vagas (sintético)

Um relatório de situação da FSTS diz: "O LANTERN é seguro. Os firewalls estão instalados. Os backups são feitos. O monitoramento está ativo." Reescrito no vocabulário deste capítulo, com evidências:

Tabela da aula; deslize para ver todas as colunas →

5.6 Atividade prática: um cartão de controle

Escolha um controle do LANTERN dos Capítulos 2–4 (por exemplo, o validador de mensagens). Escreva um cartão de controle de uma página: nome; risco que ele trata; tipo (prevenir / detectar / recuperar); onde está implementado; responsável; como ele poderia falhar; evidência de que funciona; data da última evidência. Você vai estender esses cartões no Capítulo 18.

Para o validador de mensagens, um cartão completo fica assim: risco, mensagens de estação forjadas, reproduzidas ou malformadas chegando ao historiador; tipo, prevenir; implementado no caminho de entrada do relay; responsável, FSTS Platform; poderia falhar se o estado de reprodução se perder numa reinicialização ou se a allowlist ficar atrás de uma estação nova, como a PS-11; evidência, as três aceitações, seis rejeições e duas quarentenas do Laboratório 3, mais as contagens de rejeição do relay; última evidência, a data da execução mais recente.

5.7 Erros comuns e limites

• Usar "seguro" como um estado, em vez de descrever proteções específicas e as suas evidências.
• Tratar a confidencialidade como a prioridade máxima num sistema de controle e aceitar o risco de interrupção para protegê-la.
• Contar controles em vez de perguntar o que cada um previne, detecta ou recupera.
• Ler relatórios de incidentes como guias de como fazer, ou repetir um primeiro relato depois que ele foi revisto.
• Chamar todo evento de incidente, o que esgota os respondedores; ou não chamar nada de incidente, o que atrasa a resposta.

Três deles aparecem no relatório de situação deste capítulo antes de ser reescrito. "O LANTERN é seguro" é o primeiro erro. "Os firewalls estão instalados" conta um controle sem dizer que um caminho corporativo→PS-04 não declarado precisou ser fechado sob a CHG-121. "O monitoramento está ativo" escondia que a Regra B detectou apenas 7 de 10 testes.

Exercícios — capítulo 5

EX013 — Precisão dos termos. Objetivo: usar o vocabulário corretamente. Entradas: a frase "A conta do fornecedor é uma ameaça porque a RTU é um risco sem controle." Restrições: reescreva em no máximo três frases. Etapas: (1) identifique cada termo mal usado; (2) reescreva corretamente usando ativo, vulnerabilidade, exposição, ameaça e controle. Evidência esperada: texto reescrito com uma nota de uma linha por correção. Rubrica: 3 = conta do fornecedor identificada como vulnerabilidade ou caminho de exposição (não uma ameaça), RTU como ativo, risco descrito como probabilidade e consequência, um controle ausente concreto nomeado; 2 = quase tudo certo; 1 = mudanças cosméticas; 0 = nada.

EX014 — Prevenir, detectar, recuperar. Objetivo: ver lacunas de controle pela função. Entradas: risco: "uma mudança de configuração no relay faz com que dados das estações sejam descartados". Restrições: um controle por função, implementável pela FSTS. Etapas: (1) proponha um controle preventivo, um detectivo e um de recuperação; (2) dê, para cada um, uma evidência de que funciona. Evidência esperada: tabela de três linhas. Rubrica: 3 = por exemplo, aprovação de mudança com revisão por pares (prevenir), alerta de integridade de arquivos e alerta de silêncio de estação (detectar), configuração versionada com rollback testado (recuperar), cada um com evidência testável; 2 = um fraco; 1 = todos preventivos; 0 = nada.

EX015 — Leitura de relatório de incidente. Objetivo: extrair lições para o implementador de uma fonte pública. Entradas: CISA AA21-042A e o artigo da WUSF. Restrições: apenas lições; nenhuma técnica de ataque. Etapas: (1) liste três condições que o alerta recomendou corrigir; (2) diga o que o relato posterior muda e o que não muda; (3) escreva uma regra de projeto do LANTERN que cada lição apoia. Evidência esperada: nota de meia página citando as duas fontes. Rubrica: 3 = condições como software de acesso remoto, credenciais compartilhadas e exposição à internet tiradas corretamente do alerta; reconhece que a revisão muda a atribuição, e não o valor das lições de higiene; regras de projeto específicas; 2 = um elemento fraco; 1 = repete o primeiro relato como fato firmado; 0 = nada.

Síntese do capítulo

Um vocabulário preciso é um controle de segurança: ele torna as afirmações verificáveis. Nos serviços essenciais, a continuidade e a safety do serviço físico costumam vir primeiro, o que muda como os controles são escolhidos, programados e autorizados a falhar. Descreva todo controle pelo que ele previne, detecta ou recupera, e pela evidência de que funciona. Leia os incidentes públicos em busca das premissas que falharam, e acompanhe as revisões.