Capítulo 7 — Infraestrutura crítica e segurança setorial: integração organizacional

Capítulo 7 — Infraestrutura crítica e segurança setorial: integração organizacional

Mapa da aula

Aula 07 publicada. Mapa, exemplo, EX031.

flowchart TD
  N0["7.1 Modelos operacionais"]
  N1["7.2 Responsabilidades: RACI e segregação de funções"]
  N2["7.3 Fornecedores e concentração"]
  N3["7.4 Integrar com a gestão de emergências"]
  N4["7.5 Compartilhamento de informações"]
  N5["7.7 Atividade prática: verificações de concentração"]
  N6["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX031"]

Desenho lógico

flowchart LR
  N0["7.1 Modelos operacionais"]
  N1["7.2 Responsabilidades: RACI e segregação de funções"]
  N2["7.3 Fornecedores e concentração"]
  N3["7.4 Integrar com a gestão de emergências"]
  N4["7.5 Compartilhamento de informações"]
  N5["7.7 Atividade prática: verificações de concentração"]
  N6["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX031"]

[7.1 Modelos operacionais]
    |
    v
[7.2 Responsabilidades: RACI e segregação de funções]
    |
    v
[7.3 Fornecedores e concentração]
    |
    v
[7.4 Integrar com a gestão de emergências]
    |
    v
[7.5 Compartilhamento de informações]
    |
    v
[7.7 Atividade prática: verificações de concentração]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX031]

Objetivos de aprendizagem e conexão

Ao final deste capítulo, você deverá ser capaz de:

1. Comparar modelos operacionais para a segurança de TO e de TI numa organização de serviço essencial e escolher um, com razões.
2. Atribuir as responsabilidades de modo que toda atividade crítica de segurança tenha exatamente um papel aprovador e que os conflitos de funções fiquem visíveis.
3. Medir a concentração de fornecedores dentro de uma organização e numa região, e planejar para a falha de modo comum de fornecedores.
4. Integrar a resposta a incidentes cibernéticos à gestão de emergências, à continuidade de negócios e aos arranjos regionais de resiliência.
5. Desenhar um compartilhamento de informações entre operadores que seja útil, lícito e confiável.

Os Capítulos 1–6 equiparam o especialista para decidir, evidenciar e avaliar. Este capítulo coloca esse trabalho dentro de uma organização e de uma região, porque a maioria das falhas nos serviços essenciais é falha de integração — entre a TI e as operações, entre um operador e seus fornecedores, entre uma equipe de incidentes cibernéticos e as pessoas que conduzem a resposta a emergências. O Capítulo 8 testa a integração nos casos mais difíceis; o Capítulo 9 a lidera e a assegura.

7.1 Modelos operacionais

Três modelos comuns para a segurança numa organização que opera tanto TI quanto TO:

Não existe um modelo universalmente certo. A NIST SP 800-82 recomenda formar uma equipe multifuncional que inclua engenheiros de controle, operadores, segurança de TI e pessoal de segurança operacional (NIST, 2023); o NIST CSF 2.0 coloca os papéis, as responsabilidades e as autoridades sob a governança (NIST, 2024). A escolha do modelo integrado pela Merrow Water — um Especialista Principal de Segurança subordinado ao Diretor de Operações, com uma linha pontilhada para o CISO — decorre de seu porte e do peso que ela dá à confiança dos operadores. O modelo precisa então se tornar real por meio das responsabilidades, do orçamento e do processo de incidentes; um organograma sozinho não integra nada.

7.2 Responsabilidades: RACI e segregação de funções

Para cada atividade crítica, um papel é o Aprovador (Accountable: é dono do resultado e aprova), um ou mais são Responsáveis (Responsible: fazem o trabalho), e outros são Consultados ou Informados. Duas regras pegam a maioria das falhas de responsabilidade: toda atividade crítica tem exatamente um papel aprovador; e, quando um único papel tanto executa quanto aprova uma atividade com consequência de segurança — uma mudança emergencial de firewall, um pagamento, uma concessão de acesso a um fornecedor —, o conflito é eliminado ou coberto por um controle compensatório, como uma revisão posterior de cada ocorrência. A segregação de funções é um princípio de controle de longa data no catálogo do NIST (NIST SP 800-53 Rev. 5). Dois papéis aprovadores para "declarar um incidente cibernético" soa como segurança adicional; na prática, cria uma lacuna às 3 da manhã, quando cada um supõe que o outro já decidiu.

7.3 Fornecedores e concentração

Os serviços essenciais dependem de fornecedores para o suporte aos sistemas de controle, a detecção gerenciada, as telecomunicações e a hospedagem em nuvem. A concentração tem dois níveis:

• Dentro de um operador. Se um fornecedor provê toda uma função crítica, sua falha — técnica, comercial ou um comprometimento — é a falha do operador. Uma medida padrão de concentração é o índice de Herfindahl–Hirschman (HHI): a soma dos quadrados das participações percentuais, de perto de 0 (muitos fornecedores pequenos) a 10.000 (um único fornecedor) (U.S. Department of Justice, HHI). É um sinalizador grosseiro, mas útil.
• Numa região. Se um fornecedor é uma dependência majoritária de vários operadores, um único evento se torna um evento regional. A indisponibilidade global de julho de 2024, causada por uma atualização defeituosa de um software de segurança, que afetou cerca de 8,5 milhões de dispositivos Windows segundo a Microsoft (Microsoft, 2024), mostrou como um fornecedor confiável pode se tornar uma falha de modo comum entre setores. A regulação financeira foi a que mais avançou nisso: o DORA exige registros dos acordos com terceiros de TIC e cria a supervisão dos prestadores terceiros críticos de serviços de TIC (Regulamento (UE) 2022/2554).

A concentração não é automaticamente ruim — um fornecedor bem gerido pode ser mais seguro do que três mal geridos. A tarefa do especialista é torná-la visível, decidir quais concentrações são aceitáveis e preparar planos de saída e de continuidade: o que faríamos se este fornecedor ficasse indisponível por uma semana, ou fosse comprometido? Os contratos devem dar direito aos logs, à notificação de incidentes, a requisitos de segurança e a suporte durante os incidentes do próprio fornecedor. As práticas de cadeia de suprimentos de software — listas de materiais de software (CISA, SBOM), desenvolvimento seguro (NIST SP 800-218) e compromissos de segurança desde o projeto (CISA, Secure by Design) — ajudam no lado do produto.

7.4 Integrar com a gestão de emergências

Um grande incidente cibernético num serviço essencial é também uma emergência: avisos de fervura da água, desvios de hospitais, fechamento de portos. A equipe de incidentes cibernéticos precisa, portanto, encaixar-se no comando de emergência e de continuidade de negócios da organização, em vez de funcionar em paralelo. Pontos práticos de integração:

• Uma classificação de incidentes compartilhada, que mapeie a gravidade cibernética para o impacto no serviço, para que o gerente de plantão possa escalar sem um especialista de segurança presente.
• Representação cibernética na estrutura de comando de emergência, e representação da gestão de emergências nos exercícios cibernéticos.
• Planos de operação manual e de continuidade de propriedade das operações e testados com cenários de segurança (Capítulo 6).
• Arranjos regionais acordados de antemão: quem avisa os operadores vizinhos, os serviços de saúde e as autoridades locais; como funciona a ajuda mútua; como as mensagens ao público são coordenadas. A Diretiva CER da UE enquadra a resiliência das entidades críticas como abrangendo todos os perigos e todos os setores (Diretiva (UE) 2022/2557); a política dos EUA sobre segurança e resiliência da infraestrutura crítica enfatiza, de modo semelhante, a coordenação setorial (visão geral do NSM-22, CISA).

7.5 Compartilhamento de informações

Os operadores aprendem mais depressa juntos, mas o compartilhamento traz riscos jurídicos, comerciais e de segurança. Um compartilhamento útil é específico (indicadores, técnicas, versões de produtos afetadas, mitigações que funcionaram), oportuno, protegido (regras de manuseio acordadas, como os rótulos do protocolo de semáforo) e recíproco. Um acordo de compartilhamento para um fórum regional deve cobrir: o que é compartilhado e em que formato; as regras de manuseio e de repasse; os dados pessoais (minimizar; verificar a base legal, GDPR; no Brasil, as hipóteses do art. 7º da LGPD); o cuidado com o direito da concorrência quanto a informações comercialmente sensíveis; a responsabilidade; e como as informações compartilhadas podem chegar aos reguladores. A confiança se constrói sobretudo pelo comportamento: compartilhar primeiro, proteger o que os outros compartilham e dar o crédito.

7.6 Exemplo resolvido: as dependências de Merrow Bay e uma matriz RACI preliminar (sintético)

O fórum de resiliência perguntou a cada operador quais fornecedores atendem suas funções essenciais e que parcela eles proveem. Ao mesmo tempo, o especialista da Merrow Water redigiu uma matriz RACI para cinco atividades críticas de segurança, a ser acordada com as operações e com o CISO. O Laboratório 7 analisa as duas coisas.

As perguntas foram deliberadamente simples: qual fornecedor atende cada função essencial e, aproximadamente, com que parcela. Os operadores responderam com base nos contratos e nos registros de ativos, e não de memória, e o fórum acordou de antemão que as respostas seriam usadas apenas para a análise regional. O rascunho da RACI cobre aprovar e executar mudanças emergenciais no firewall de TO, conceder sessões remotas a fornecedores, declarar um incidente cibernético e restaurar a partir do backup offline, cada uma escolhida porque um erro de responsabilidade ali atrasaria a resposta ou enfraqueceria o controle.

7.7 Atividade prática: verificações de concentração e de responsabilidade

# Lab 7 - concentration and ownership checks for an integrated security function (offline, stdlib only)
# Synthetic: which suppliers Merrow Bay operators depend on for essential functions, and a draft RACI.
from collections import defaultdict
DEPENDS = [  # (operator, function, supplier, share of that operator's function served by the supplier)
    ("Merrow Water", "SCADA support", "Corvane Systems", 1.0),
    ("Merrow Water", "managed detection", "Lumen Watch", 1.0),
    ("Merrow Water", "telemetry links", "BayTel", 0.7), ("Merrow Water", "telemetry links", "radio (own)", 0.3),
    ("Merrow Health", "EPR hosting", "Halden Cloud", 1.0),
    ("Merrow Health", "managed detection", "Lumen Watch", 1.0),
    ("Merrow Health", "pathology LIMS", "Corvane Systems", 1.0),
    ("Merrow Energy", "SCADA support", "Corvane Systems", 0.6), ("Merrow Energy", "SCADA support", "in-house", 0.4),
    ("Merrow Energy", "telemetry links", "BayTel", 0.5), ("Merrow Energy", "telemetry links", "private fibre", 0.5),
    ("Port of Merrow", "terminal OS hosting", "Halden Cloud", 1.0),
    ("Port of Merrow", "managed detection", "Lumen Watch", 1.0),
]
by_op_fn = defaultdict(list)
for op, fn, sup, share in DEPENDS: by_op_fn[(op, fn)].append((sup, share))
print("Herfindahl-Hirschman index per operator function (10000 = single supplier):")
for (op, fn), lst in by_op_fn.items():
    hhi = sum((100 * s) ** 2 for _, s in lst)
    print(f"  {op:15s} {fn:20s} HHI {hhi:6.0f}")
reach = defaultdict(set)
for op, fn, sup, share in DEPENDS:
    if sup not in ("in-house", "radio (own)", "private fibre") and share >= 0.5: reach[sup].add(op)
print("Suppliers that are a majority dependency for 2+ operators (regional common mode):")
for sup, ops in sorted(reach.items(), key=lambda x: -len(x[1])):
    if len(ops) >= 2: print(f"  {sup:16s} {len(ops)} operators: {', '.join(sorted(ops))}")
RACI = {  # activity -> {role: letters}
    "approve OT firewall change":   {"OT engineer": "R", "OT manager": "A", "CISO": "C"},
    "emergency OT firewall change": {"OT engineer": "RA", "OT manager": "I"},
    "grant vendor remote session":  {"OT engineer": "R", "Service desk": "R"},
    "declare cyber incident":       {"CISO": "A", "Duty manager": "A", "OT manager": "C"},
    "restore from offline backup":  {"OT engineer": "R", "OT manager": "A", "IT ops": "R"},
}
print("RACI findings:")
for act, roles in RACI.items():
    a = [r for r, l in roles.items() if "A" in l]
    if len(a) != 1: print(f"  {act}: {len(a)} accountable roles {a}")
    for r, l in roles.items():
        if "R" in l and "A" in l: print(f"  {act}: {r} both does and approves (needs compensating control or record)")

Saída esperada:

Herfindahl-Hirschman index per operator function (10000 = single supplier):
  Merrow Water    SCADA support        HHI  10000
  Merrow Water    managed detection    HHI  10000
  Merrow Water    telemetry links      HHI   5800
  Merrow Health   EPR hosting          HHI  10000
  Merrow Health   managed detection    HHI  10000
  Merrow Health   pathology LIMS       HHI  10000
  Merrow Energy   SCADA support        HHI   5200
  Merrow Energy   telemetry links      HHI   5000
  Port of Merrow  terminal OS hosting  HHI  10000
  Port of Merrow  managed detection    HHI  10000
Suppliers that are a majority dependency for 2+ operators (regional common mode):
  Corvane Systems  3 operators: Merrow Energy, Merrow Health, Merrow Water
  Lumen Watch      3 operators: Merrow Health, Merrow Water, Port of Merrow
  BayTel           2 operators: Merrow Energy, Merrow Water
  Halden Cloud     2 operators: Merrow Health, Port of Merrow
RACI findings:
  emergency OT firewall change: OT engineer both does and approves (needs compensating control or record)
  grant vendor remote session: 0 accountable roles []
  declare cyber incident: 2 accountable roles ['CISO', 'Duty manager']

Interpretação. Dentro dos operadores, sete dos dez pares função–operador têm HHI 10.000 — um único fornecedor —, o que é comum e não alarmante por si só. A visão regional é mais importante: a Corvane Systems é uma dependência majoritária de três operadores (suporte ao SCADA na água e na energia, sistemas de patologia na saúde), a Lumen Watch fornece detecção gerenciada a três, e a BayTel e a Halden Cloud a dois cada. Um comprometimento da Lumen Watch cegaria a detecção de três operadores ao mesmo tempo; um comprometimento do suporte remoto da Corvane poderia alcançar os sistemas operacionais de três setores. São riscos no nível do fórum que nenhum registro de um operador isolado mostrará. A verificação da RACI encontra três problemas: na mudança emergencial de firewall, o engenheiro de TO executa e aprova, o que pode ser aceitável à noite se toda ocorrência for revisada no dia útil seguinte; a concessão de sessões remotas a fornecedores não tem papel aprovador — a constatação mais perigosa, dado o evento de Hollin do Capítulo 3; e a declaração de um incidente cibernético tem dois papéis aprovadores, que devem virar um só (o gerente de plantão, que está sempre disponível), com o CISO consultado.

7.8 Erros comuns e limites

• Escolher um modelo operacional copiando outra organização, e não pelo porte, pelo risco e pela cultura.
• Desenhar um organograma e chamá-lo de integração.
• Deixar atividades críticas sem nenhum dono aprovador, ou com dois.
• Avaliar o risco de fornecedores contrato por contrato, sem ver a concentração regional.
• Tratar a certificação de um fornecedor como evidência de resiliência durante o incidente do próprio fornecedor.
• Conduzir a resposta a incidentes cibernéticos em paralelo com o comando de emergência.
• Compartilhar informações sem regras de manuseio, ou nunca compartilhar porque as regras não estão claras.

O limite da análise estrutural é que a integração depende, em última instância, de relações e de prática. As tabelas RACI e os valores de HHI indicam onde olhar; os exercícios e os incidentes reais mostram se a integração funciona.

Exercícios — capítulo 7

EX031 — Repare a RACI. Objetivo: corrigir os defeitos de responsabilidade e verificar. Insumos: Laboratório 7. Restrições: toda atividade com exatamente um A; todo conflito R+A eliminado ou documentado com um controle compensatório. Passos: (1) editar a RACI; (2) reexecutar e mostrar que não restam constatações sem tratamento; (3) escrever o controle compensatório de qualquer conflito que você mantiver. Evidência esperada: tabela editada, saída, texto do controle. Rubrica: 3 = concessão de sessão a fornecedores com um único papel aprovador (gerente de TO), com a central de serviços e o engenheiro de TO como responsáveis, declaração de incidente com um único aprovador, conflito da mudança emergencial eliminado ou mantido com revisão de toda ocorrência no dia seguinte; 2 = saída limpa, mas sem o controle; 1 = não reexecutado; 0 = nada.

EX032 — Modo comum regional. Objetivo: planejar para um fornecedor concentrado. Insumos: a Lumen Watch atendendo três operadores. Restrições: o fórum não tem autoridade sobre os contratos; os operadores mantêm suas próprias escolhas. Passos: (1) descrever dois cenários de falha (indisponibilidade; comprometimento do provedor); (2) propor ações no nível do operador e no nível do fórum; (3) definir as cláusulas contratuais a pedir na renovação. Evidência esperada: plano. Rubrica: 3 = cenários distintos (cegueira versus o provedor como caminho de ataque), ações que incluem uma detecção mínima local ou registros mantidos por cada operador, exercício conjunto, cláusulas de notificação, acesso aos logs e plano de saída; 2 = um cenário; 1 = "trocar de fornecedor"; 0 = nada.

EX033 — Escolha um modelo operacional. Objetivo: justificar um modelo para outra organização. Insumos: o Port of Merrow: 600 funcionários, uma equipe de segurança de TI de duas pessoas, a TO dos terminais operada por um terceirizado, um centro de operações da capitania. Restrições: usar a §7.1. Passos: comparar os modelos; escolher; declarar as três condições que fariam a sua escolha fracassar. Evidência esperada: recomendação de uma página. Rubrica: 3 = escolha argumentada a partir do porte, da dependência do terceirizado e da cultura das operações, condições de fracasso específicas; 2 = prós e contras genéricos; 1 = nenhuma escolha; 0 = nada.

EX034 — O cibernético dentro do comando de emergência. Objetivo: integrar as estruturas de resposta. Insumos: o plano de emergência existente da Merrow Water (fervura da água, perda de fornecimento) e seu procedimento de incidentes cibernéticos, que hoje não fazem referência um ao outro. Restrições: uma única classificação compartilhada; nenhum comando duplicado. Passos: (1) redigir uma tabela de classificação combinada a partir do impacto no serviço; (2) definir o lugar do responsável cibernético no comando de emergência; (3) listar as notificações regionais e quem as faz. Evidência esperada: tabela e descrição de um diagrama. Rubrica: 3 = classificação pelo impacto no serviço utilizável por um gerente de plantão, responsável cibernético assessorando o comandante do incidente em vez de conduzir uma estrutura paralela, notificações regionais atribuídas; 2 = as estruturas paralelas permanecem; 1 = gravidade apenas cibernética; 0 = nada.

EX035 — Aritmética da concentração e julgamento. Objetivo: calcular e interpretar o HHI. Insumos: a telemetria e os serviços de rede da Merrow Health divididos em 40% / 40% / 20% entre três operadoras, duas das quais compartilham o mesmo duto ao longo da avenida do porto. Restrições: mostrar o cálculo. Passos: (1) calcular o HHI; (2) explicar por que o número subestima a concentração real; (3) propor como representar os caminhos físicos compartilhados. Evidência esperada: cálculo e parágrafo. Rubrica: 3 = HHI 3.600, reconhecimento de que 80% do serviço compartilha uma rota física, de modo que a concentração efetiva é muito maior, proposta de calcular a concentração sobre caminhos físicos ou domínios de falha; 2 = apenas o número; 1 = aritmética errada; 0 = nada.

Síntese do capítulo

A integração é onde a segurança dos serviços essenciais costuma falhar. Escolha um modelo operacional para o seu porte, risco e cultura, e torne-o real com responsabilidades: exatamente um papel aprovador por atividade crítica e tratamento visível dos conflitos de funções. Meça a concentração de fornecedores dentro da organização e na região, e prepare planos de saída e de continuidade para a falha de modo comum de fornecedores. Coloque a resposta cibernética dentro do comando de emergência e de continuidade, com uma classificação compartilhada baseada no serviço. Compartilhe informações de forma específica, sob regras de manuseio acordadas, e construa a confiança pelo comportamento.

Continue estudando — capítulo 07 de 12

← Capítulo 06 · Índice de capítulos do curso · Capítulo 08 →

Siga para a próxima lição escrita.