Capítulo 21 — Infraestrutura crítica e segurança setorial: integração do serviço
Mapa da aula
Aula 21 publicada. Mapa, exemplo, EX061.
flowchart TD
N0["21.1 As interfaces são acordos"]
N1["21.2 Matrizes de responsabilidade"]
N2["21.3 Integração dos fornecedores"]
N3["21.4 O tratamento de incidentes encontra a continuid"]
N4["21.6 Atividade prática: acordos de interface"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX061"]
Desenho lógico
flowchart LR
N0["21.1 As interfaces são acordos"]
N1["21.2 Matrizes de responsabilidade"]
N2["21.3 Integração dos fornecedores"]
N3["21.4 O tratamento de incidentes encontra a continuid"]
N4["21.6 Atividade prática: acordos de interface"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX061"]
[21.1 As interfaces são acordos]
|
v
[21.2 Matrizes de responsabilidade]
|
v
[21.3 Integração dos fornecedores]
|
v
[21.4 O tratamento de incidentes encontra a continuid]
|
v
[21.6 Atividade prática: acordos de interface]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX061]
Objetivos de aprendizagem e conexão
Depois deste capítulo, você deve ser capaz de:
- integrar um serviço técnico com as pessoas e as organizações ao seu redor: operadores, o centro de monitoramento de segurança, fornecedores e planejadores de emergência;
- definir interfaces — o que é entregue, em que forma, com que rapidez e a quem —, e não apenas formatos de dados;
- escrever uma matriz de responsabilidades para um serviço compartilhado e testá-la com um cenário;
- ligar o tratamento de incidentes do serviço aos planos de continuidade e de emergência do operador.
A esta altura, o LANTERN é um serviço técnico em funcionamento. Um serviço está integrado quando todos os que dependem dele, ou de quem ele depende, sabem o que esperar e o que fazer. A maioria das falhas nesta etapa não é técnica: um alerta que ninguém assume, um fornecedor que nunca foi avisado de uma mudança, um operador que não sabia que o painel podia estar desatualizado.
21.1 As interfaces são acordos
Para cada vizinho, escreva a interface como um acordo:
- Operação de Água — o que o LANTERN fornece (telemetria ao historiador em até 60 s, com a idade do valor exibida), o que a Água fornece (solicitações de comissionamento de estações, exportações de engenharia, aprovações relevantes para o processo), como os alertas que afetam o processo chegam à sala de controle e como a Água relata um suposto problema de telemetria.
- Monitoramento de segurança da FSTS (SOC) — quais logs e alertas o LANTERN envia, em que formato, com quais primeiras ações; como o SOC escala para o plantão do LANTERN; o que o SOC pode fazer sem perguntar (por exemplo, desabilitar uma conta de fornecedor) e o que não pode (por exemplo, bloquear os conduítes das estações).
- Fornecedores (Kell, Arlen, BayTel, Halden) — como são avisados das mudanças que os afetam, como relatam problemas e vulnerabilidades, como funciona o seu acesso (Capítulo 7), com que antecedência avisam das suas próprias mudanças.
- Planejamento de emergência — como uma interrupção ou um comprometimento do LANTERN se reflete nos planos de continuidade da Água e do hospital.
21.2 Matrizes de responsabilidade
Uma matriz RACI registra, para cada atividade, quem é Responsável (executa), quem Aprova/responde (é dono do resultado — exatamente um), quem é Consultado e quem é Informado. Teste-a com um cenário: percorra "relay comprometido às 02:00" e confira se cada passo tem exatamente um papel que responde pelo resultado, se ninguém que precise ser consultado está inalcançável às 02:00, e se as pessoas que precisam agir sobre o processo físico são informadas cedo.
Percorrer "relay comprometido às 02:00" no rascunho de Fallowmere expôs o problema que o exemplo resolvido descreve: ninguém respondia por dizer aos operadores da Água que desconfiassem da telemetria.
21.3 Integração dos fornecedores
Os fornecedores fazem parte do serviço. O seu acesso remoto é um caminho para dentro dele; as suas atualizações de software são mudanças nele; as suas interrupções são as suas interrupções. Integrar significa: o acesso deles pelo caminho declarado; os avisos de mudança deles no seu calendário de mudanças; os alertas de segurança deles na sua rotina de vulnerabilidades (Capítulo 16); e cláusulas contratuais que exijam a notificação de incidentes que afetem você. A iniciativa Secure by Design da CISA incentiva os fabricantes a assumir a responsabilidade pelos resultados de segurança dos clientes (CISA Secure by Design); como cliente, pergunte aos fornecedores como eles atendem a essas expectativas e registre as respostas.
21.4 O tratamento de incidentes encontra a continuidade
Um incidente no LANTERN é tratado pelo processo de incidentes da FSTS, mas as suas consequências são geridas pelos arranjos de continuidade e de emergência da Água e do hospital. O ponto de integração é uma lista curta de gatilhos: condições sob as quais a FSTS diz à Água "presuma que a telemetria não é confiável — passe a leituras manuais nas estações" ou diz ao hospital "presuma que o gateway clínico está indisponível — use o procedimento da biblioteca de medicamentos em papel". Os gatilhos precisam ser acordados previamente e exercitados (Capítulo 28), porque às 02:00 ninguém deveria estar negociando o que significa "não confiável".
21.5 Exemplo resolvido: uma RACI que falhou no teste (sintético)
O rascunho da RACI para "suspeita de comprometimento de um relay" lista: plantão da FSTS — R; líder de segurança da FSTS — A; operação de Água — I; SOC — C; Kell — I. Percorrer o cenário revela três problemas. Primeiro, a decisão de dizer aos operadores da Água que desconfiem da telemetria não tem papel que responda por ela: a segurança da FSTS não consegue julgar o impacto no processo, e a Água é apenas Informada. Correção: o gerente de turno da Água como A pela resposta operacional, o líder de segurança da FSTS como A pela resposta técnica, com um gatilho nomeado para a passagem. Segundo, a Kell é apenas Informada, mas, se o comprometimento veio pelo caminho do fornecedor, a conta da Kell precisa ser desabilitada de imediato e a Kell consultada sobre a sua própria exposição. Terceiro, o SOC é "Consultado", mas, na prática, detecta a maioria dos incidentes; ele deveria ser Responsável pelos primeiros passos de triagem.
21.6 Atividade prática: acordos de interface
Escreva um acordo de interface de uma página entre o LANTERN e a operação de Água, cobrindo: o que cada lado fornece, os níveis de serviço (atualidade, exibição da idade do valor), o encaminhamento de alertas, como um suposto problema de telemetria é relatado, os gatilhos para "telemetria não confiável" e a frequência de revisão.
Torne os gatilhos mensuráveis: por exemplo, "telemetria não confiável" é declarada quando as falhas de MAC do relay excedem uma taxa declarada em mais de uma estação, quando duas ou mais estações mostram deslocamentos de relógio como os 422 segundos da PS-09, ou quando a FSTS suspeita do comprometimento de um relay. Declare quem a declara (o gerente de turno da Água, com o aconselhamento da FSTS), como a sala de controle é avisada e que ela é exercitada anualmente.
21.7 Erros comuns e limites
- Tratar a integração apenas como formatos de dados e APIs.
- Matrizes RACI com vários papéis que respondem pelo resultado, ou nenhum.
- Fornecedores fora dos processos de mudanças e de vulnerabilidades.
- Planos de continuidade que presumem que o serviço de TI está ou totalmente no ar ou totalmente fora, sem um estado "no ar, mas não confiável".
- Gatilhos definidos, mas nunca exercitados.
O primeiro rascunho da RACI mostra o segundo erro: nenhum papel respondia pela resposta operacional.
A exclusão da Kell dos papéis consultados no rascunho da RACI mostra o terceiro: um fornecedor cuja conta pode ser o caminho de entrada seria apenas informado.
Exercícios — capítulo 21
EX061 — Conserte a RACI. Objetivo: corrigir uma matriz de responsabilidades. Entradas: o rascunho do Capítulo 21 ("Exemplo resolvido: uma RACI que falhou no teste"). Restrições: exatamente um A por atividade; divida atividades se necessário. Etapas: escreva a matriz consertada para as atividades: detectar e triar; conter no relay; desabilitar o acesso do fornecedor; decidir a resposta operacional; notificar os reguladores, se exigido; restaurar o serviço. Evidência esperada: matriz. Rubrica: 3 = um A por linha; SOC R pela triagem; segurança da FSTS A pela contenção técnica; gerente de turno da Água A pela resposta operacional; notificação regulatória com A no papel designado pelo operador, e não na FSTS; Kell C no acesso do fornecedor; 2 = uma linha errada; 1 = continuam vários A; 0 = nada.
EX062 — Defina um gatilho. Objetivo: tornar preciso o "telemetria não confiável". Entradas: os alertas do LANTERN do Capítulo 19 e os desfechos de validação do Capítulo 3. Restrições: condições mensuráveis; não pode disparar em falhas comuns de uma única estação. Etapas: (1) escreva as condições do gatilho; (2) diga quem o declara e quem o encerra; (3) diga o que a Água faz quando ele é declarado. Evidência esperada: meia página. Rubrica: 3 = condições como uma mudança não autorizada confirmada num relay, falhas de MAC em várias estações ou falha de integridade do relay; declarado pelo líder de segurança da FSTS com o gerente de turno da Água; a Água passa a leituras manuais e amostragem; a condição de encerramento exige um estado limpo verificado; 2 = condições vagas; 1 = "quando parecer errado"; 0 = nada.
EX063 — Perguntas ao fornecedor. Objetivo: integrar um fornecedor. Entradas: Kell Instruments. Restrições: seis perguntas; cada uma ligada a um processo do LANTERN. Etapas: escreva as perguntas e o processo que cada uma alimenta. Evidência esperada: lista. Rubrica: 3 = por exemplo, como a Kell notifica vulnerabilidades (Capítulo 16), como o acesso da sua equipe é controlado e revogado (Capítulo 7), o seu compromisso de notificação de incidentes (este capítulo), como o firmware é assinado (Capítulo 27), as datas de fim de suporte (Capítulo 11), a disponibilidade de SBOM (CISA SBOM); 2 = quatro ou cinco; 1 = genérico; 0 = nada.
Síntese do capítulo
Um serviço está integrado quando todo vizinho — operadores, o SOC, fornecedores, planejadores de emergência — tem uma interface acordada: o que é fornecido, com que rapidez, a quem e o que acontece quando falha. Teste as matrizes de responsabilidade com cenários até que cada atividade tenha um papel que responda por ela. Traga os fornecedores para os processos de mudanças, vulnerabilidades e incidentes. Acorde e exercite os gatilhos que ligam um incidente técnico aos planos de continuidade do operador, incluindo o estado "no ar, mas não confiável".
Continue estudando — capítulo 21 de 30
← Capítulo 20 · Índice de capítulos do curso · Capítulo 22 →
Siga para a próxima lição escrita.