Capítulo 16 — Infraestrutura crítica e segurança setorial: métodos II
Mapa da aula
Aula 16 publicada. Mapa, exemplo, EX046.
flowchart TD
N0["16.1 Recebimento de vulnerabilidades e aplicabilidad"]
N1["16.2 Priorização"]
N2["16.3 Tratamento quando não dá para aplicar o patch r"]
N3["16.4 Verificação"]
N4["16.5 Backups e testes de restauração"]
N5["16.7 Atividade prática: registro de vulnerabilidade"]
N6["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX046"]
Desenho lógico
flowchart LR
N0["16.1 Recebimento de vulnerabilidades e aplicabilidad"]
N1["16.2 Priorização"]
N2["16.3 Tratamento quando não dá para aplicar o patch r"]
N3["16.4 Verificação"]
N4["16.5 Backups e testes de restauração"]
N5["16.7 Atividade prática: registro de vulnerabilidade"]
N6["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX046"]
[16.1 Recebimento de vulnerabilidades e aplicabilidad]
|
v
[16.2 Priorização]
|
v
[16.3 Tratamento quando não dá para aplicar o patch r]
|
v
[16.4 Verificação]
|
v
[16.5 Backups e testes de restauração]
|
v
[16.7 Atividade prática: registro de vulnerabilidade]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX046]
Objetivos de aprendizagem e conexão
Depois deste capítulo, você deve ser capaz de:
- conduzir uma rotina de tratamento de vulnerabilidades: recebimento, aplicabilidade, priorização, tratamento e verificação;
- priorizar correções usando evidências de exploração, exposição e consequência para o ativo, e não apenas a nota de severidade;
- planejar a aplicação de patches quando o dispositivo não pode ser corrigido rapidamente, usando controles compensatórios com data de término;
- projetar, executar e registrar backups e testes de restauração que provem a recuperação dentro de um tempo-alvo.
Métodos I (Capítulo 14) controlou as mudanças. Métodos II cobre as duas rotinas que mais costumam decidir quão ruim um dia ruim fica: lidar com as vulnerabilidades antes que sejam exploradas, e recuperar quando algo se perde de qualquer forma.
16.1 Recebimento de vulnerabilidades e aplicabilidade
Os alertas chegam de fornecedores, de agências nacionais e de listas de discussão de segurança. A primeira pergunta é a aplicabilidade: rodamos o produto e a versão afetados, numa configuração em que a falha importa? Isso depende de o inventário (Capítulo 11) estar correto quanto às versões. Registre a decisão — "aplicável", "não aplicável (motivo)", "desconhecido (ação para descobrir)" — para todo alerta que toque um produto do inventário. "Desconhecido" é comum na TO e precisa ter um responsável.
Para o alerta do Arlen 300, o inventário tinha as duas versões: PS04-PLC na 4.2 e PS07-PLC na 3.9.
16.2 Priorização
Uma nota de severidade descreve a falha em geral; a sua prioridade depende da sua situação. Três perguntas a tornam mais precisa. Ela está sendo explorada? O catálogo Known Exploited Vulnerabilities da CISA lista falhas com evidência de exploração ativa (CISA KEV); essas entradas passam para a frente. Ela está exposta? Uma falha alcançável a partir da internet ou da zona corporativa é mais urgente do que uma alcançável apenas de dentro de um conduíte bem controlado. Qual é a consequência? Uma falha num ativo de criticidade 1 na zona das estações importa mais do que uma num quiosque da garagem. A orientação sobre gestão de patches trata isso como um agendamento baseado em risco, com planos de manutenção definidos para diferentes grupos de ativos (NIST SP 800-40 Rev. 4).
16.3 Tratamento quando não dá para aplicar o patch rapidamente
Os controladores das estações podem precisar de firmware certificado pelo fornecedor, de uma visita ao local, de uma janela de interrupção e de novos testes do processo. O tratamento tem então duas partes: controles compensatórios agora (restringir mais o conduíte, desabilitar a função vulnerável se não for usada, acrescentar monitoramento de tentativas de exploração, aumentar a revisão da configuração do dispositivo) e um plano com data para a correção. Registre ambos, e o dono do risco residual (Capítulo 13). Lembre-se do Capítulo 9: esses itens em aberto há muito tempo precisam aparecer nas suas medidas de patches.
PS04-PLC e PS07-PLC são o caso de Fallowmere: desabilitar a interface web não usada, fechar o caminho corporativo→PS-04, alertar sobre a porta web, e depois o firmware 4.3 nas próximas visitas ao local.
16.4 Verificação
Uma correção está completa quando é verificada no dispositivo: a versão é confirmada (a partir do dispositivo ou da sua exportação de engenharia, e não do ticket), o serviço funciona (as verificações do Capítulo 27) e os controles compensatórios que não são mais necessários são removidos sob controle de mudanças — do contrário, as regras temporárias se acumulam.
Para o PS07-PLC, a versão foi lida no dispositivo durante a visita ao local: 3.9, como registrado, então a correção continua em aberto. Quando a 4.3 for instalada, a evidência será a exportação do engenheiro mostrando 4.3, e o alerta sobre a porta web do CLP será mantido ou removido pelo seu próprio registro de mudança.
16.5 Backups e testes de restauração
Um backup que nunca foi restaurado é uma esperança. O guia do NIST de planejamento de contingência cobre o planejamento e o teste de backup e recuperação (NIST SP 800-34 Rev. 1), e o guia do NIST sobre recuperação de eventos cibernéticos enfatiza preparar e exercitar a recuperação com antecedência (NIST SP 800-184). Para o LANTERN:
- O que tem backup: a configuração e a allowlist do relay (já sob controle de versões), as chaves (no próprio backup do seu armazenamento protegido), o banco de dados do historiador, os programas e as configurações dos controladores (pelos engenheiros da Água) e a documentação necessária para reconstruir.
- Onde: pelo menos uma cópia offline ou imutável, para que um ransomware ou um erro de administrador não consiga apagar todas as cópias.
- Metas: um objetivo de tempo de recuperação (RTO — com que rapidez o serviço precisa voltar) e um objetivo de ponto de recuperação (RPO — quanta perda de dados é tolerável). Para o HIST-01 em Fallowmere: RTO de 4 horas, RPO de 24 horas.
- Testes de restauração: agendados, cronometrados, registrados, com o resultado comparado às metas; o Capítulo 9 mostra como relatá-los com honestidade.
16.6 Exemplo resolvido: um alerta para o Arlen 300 (sintético)
Um alerta relata uma falha na interface web de gerenciamento do CLP Arlen 300, firmware abaixo da 4.3, agora listada como explorada em outros lugares (sintético). Aplicabilidade: o PS04-PLC roda a 4.2 e o PS07-PLC roda a 3.9 — ambos aplicáveis. Exposição: a interface web deveria ser alcançável apenas pelo caminho de salto de engenharia; mas a revisão de fluxos do Capítulo 2 encontrou uma estação de trabalho corporativa conversando diretamente com a PS-04. Prioridade: alta nas três perguntas. Tratamento: hoje, confirmar com o engenheiro da Água se a interface web é usada e, se não for, desabilitá-la; fechar o caminho corporativo→PS-04 (já levantado); acrescentar um alerta para qualquer conexão à porta web dos CLPs. Correção: firmware 4.3 nas próximas visitas ao local, com os testes de processo da Água. Verificação: versão lida na exportação de engenharia; alerta e conduíte testados.
16.7 Atividade prática: registro de vulnerabilidade
Escreva o registro completo para o alerta do Capítulo 16 ("Exemplo resolvido: um alerta para o Arlen 300"): aplicabilidade por ativo, prioridade com os motivos para cada uma das três perguntas, controles compensatórios com evidências, plano de correção com datas e responsáveis, etapas de verificação e o dono do risco residual.
A prioridade do PS04-PLC se apoia em três respostas: aplicável (a 4.2 está abaixo da 4.3), explorada em outros lugares e exposta, porque a revisão de fluxos viu uma estação de trabalho corporativa conversando com a PS-04. O PS07-PLC é aplicável e explorado, mas nenhum caminho não declarado foi visto, então o seu motivo de exposição é mais fraco. Nomeie a operação de Água como dona do risco residual até que a 4.3 seja verificada nos dois.
16.8 Erros comuns e limites
- Priorizar apenas pela nota de severidade.
- Marcar "não aplicável" sem conferir as versões.
- Deixar "desconhecido" sem responsável.
- Controles compensatórios sem data de término, que assim se tornam permanentes.
- Fechar o ticket quando o patch é agendado, e não quando é verificado.
- Backups guardados onde a mesma conta de administrador consegue apagar todas as cópias.
- Medir o sucesso do backup pela conclusão da tarefa, em vez de por testes de restauração.
Os dois CLPs mostram o risco do quinto erro: o ticket fecharia em "firmware 4.3 agendado", enquanto a 3.9 continua rodando na PS-07.
A 4.2 do PS04-PLC teria sido marcada como não aplicável por quem lesse apenas a nota do alerta.
Exercícios — capítulo 16
EX046 — Priorize três alertas. Objetivo: aplicar exploração, exposição e consequência. Entradas: (a) falha de severidade crítica no navegador do quiosque da garagem, sem exploração conhecida, quiosque na rede da garagem com acesso à internet; (b) falha de severidade média no servidor SSH do relay, listada no KEV, SSH alcançável apenas a partir do host de salto; (c) falha de severidade alta no banco de dados do HIST-01, sem exploração conhecida, alcançável a partir da zona corporativa. Restrições: ordene e justifique com uma frase cada. Etapas: ordene, depois dê uma data-alvo para cada uma. Evidência esperada: tabela. Rubrica: 3 = (b) em primeiro lugar por causa da exploração ativa e da criticidade, apesar da nota média e da exposição restrita; depois uma ordenação defensável de (c) e (a), com motivos (consequência do historiador contra a exposição à internet do quiosque); datas proporcionais; 2 = ordenação defensável, motivos rasos; 1 = só pela severidade; 0 = nada.
EX047 — Plano de controles compensatórios. Objetivo: tratar uma vulnerabilidade que não pode ser corrigida rapidamente. Entradas: Capítulo 16 ("Exemplo resolvido: um alerta para o Arlen 300"); o firmware 4.3 só pode ser instalado na PS-07 daqui a 10 semanas. Restrições: pelo menos três controles, cada um com evidência e data de término. Etapas: escreva o plano. Evidência esperada: tabela. Rubrica: 3 = desabilitar a interface web se não for usada (evidência: exportação de engenharia), restrição do conduíte verificada por revisão de fluxos, alerta sobre conexões à porta web testado, comparação de configuração mais frequente; todos terminando quando a 4.3 for verificada; 2 = sem datas de término; 1 = "monitorar"; 0 = nada.
EX048 — Projeto de teste de restauração. Objetivo: projetar um teste de restauração que prove o RTO. Entradas: HIST-01, RTO de 4 h, RPO de 24 h. Restrições: não pode perturbar a produção; precisa ser repetível. Etapas: (1) descreva o ambiente de teste; (2) as etapas e os pontos de cronometragem; (3) os critérios de aprovação; (4) o que é registrado. Evidência esperada: uma página. Rubrica: 3 = destino de restauração isolado, parte da cópia offline/imutável, cronometra da "decisão de restaurar" até "os operadores conseguem consultar os dados", confere a atualidade dos dados contra o RPO, registra tempos, lacunas e lições, e é agendado com regularidade; 2 = falta a cronometragem ou a verificação do RPO; 1 = "conferir se a tarefa de backup teve sucesso"; 0 = nada.
Síntese do capítulo
Trate as vulnerabilidades como uma rotina: decida a aplicabilidade a partir do inventário, priorize por exploração, exposição e consequência, aplique controles compensatórios com datas de término onde a aplicação de patches é lenta e verifique as correções no dispositivo. Faça backup do que você precisa para reconstruir, mantenha uma cópia que não possa ser apagada pelas mesmas pessoas que operam a produção, defina o RTO e o RPO e prove-os com testes de restauração cronometrados.
Continue estudando — capítulo 16 de 30
← Capítulo 15 · Índice de capítulos do curso · Capítulo 17 →
Siga para a próxima lição escrita.