Capítulo 6 — Infraestrutura crítica e segurança setorial: fluxo operacional

Mapa da aula

Aula 06 publicada. Mapa, exemplo, EX026.

flowchart TD
  N0["6.1 Papéis"]
  N1["6.2 RACI"]
  N2["6.3 Governança de mudanças entre TI e TO"]
  N3["6.4 Escalonamento"]
  N4["6.6 Atividade prática"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX026"]

Desenho lógico

flowchart LR
  N0["6.1 Papéis"]
  N1["6.2 RACI"]
  N2["6.3 Governança de mudanças entre TI e TO"]
  N3["6.4 Escalonamento"]
  N4["6.6 Atividade prática"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX026"]

[6.1 Papéis]
    |
    v
[6.2 RACI]
    |
    v
[6.3 Governança de mudanças entre TI e TO]
    |
    v
[6.4 Escalonamento]
    |
    v
[6.6 Atividade prática]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX026]

Objetivos de aprendizagem e conexão

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

• definir os papéis de que um programa de segurança de infraestrutura crítica precisa e como eles se relacionam com as operações;
• construir e verificar uma matriz RACI para que toda atividade-chave tenha exatamente uma pessoa que responde por ela e um líder claro;
• conduzir a governança de mudanças entre TI e TO sem bloquear as operações nem contornar a segurança;
• desenhar um caminho de escalonamento, do operador de turno até a diretoria, que funcione às 03:00 de um domingo.

O Capítulo 5 deu a você réguas. Este capítulo faz o programa funcionar no dia a dia.

6.1 Papéis

No porte da Kestrel Water, os papéis abaixo podem ser divididos entre um punhado de pessoas. O que importa é que cada um seja atribuído:

• Patrocinador executivo (diretor de operações) — é dono do programa, aceita riscos altos, resolve conflitos entre departamentos.
• Donos de serviço (gerente de operações para o tratamento e as estações; gerente de atendimento ao cliente para o faturamento) — são donos dos riscos e das decisões dos seus serviços.
• Coordenador — conduz o ciclo: registro, registros de decisão, exercícios, relatórios, revisões de fornecedores.
• Líder de segurança — assessoria técnica de segurança e interlocução de monitoramento com o KVROC.
• Engenheiro de sistemas de controle — configuração e mudanças nos sistemas operacionais.
• Líder de comunicação — mensagens ao público e à imprensa.
• Líder de incidente (em rodízio, de plantão) — comanda a resposta quando um incidente é declarado.
• Fornecedores — trabalham sob autorização; nunca são donos de decisões sobre o seu serviço.

As orientações do NIST para resposta a incidentes enfatizam a definição de papéis e responsabilidades, incluindo os de fora da equipe de segurança, antes dos incidentes (NIST SP 800-61 Rev. 3).

6.2 RACI

Uma matriz RACI lista atividades contra pessoas, com uma letra para cada: Responsável (executa o trabalho), Aprovador (responde pelo resultado e dá a aprovação final — exatamente um por atividade), Consultado (contribuição de mão dupla antes da decisão), Informado (avisado depois). Duas regras pegam a maioria dos defeitos:

1. Exatamente um A por atividade. Zero significa que ninguém responde; dois significa que cada um pressupõe que o outro vai responder.
2. Pelo menos um R e, quando houver vários, um líder nomeado.

Acrescente duas verificações do coordenador: ninguém deve ser o aprovador do próprio acesso ou do próprio trabalho; e ninguém deve acumular tantas entradas R e A num incidente que se torne um gargalo.

6.3 Governança de mudanças entre TI e TO

Mudanças nos sistemas operacionais podem afetar o processo físico. Um processo de mudanças viável para uma empresa pequena tem três classes:

• Padrão — pré-aprovada, de baixo risco, repetível (substituir o teclado defeituoso de um operador): registre-a.
• Normal — avaliada e aprovada pelo dono do serviço, com um plano de teste ou de reversão e uma janela acordada com as operações.
• Emergencial — necessária agora para proteger pessoas ou o serviço; aprovada verbalmente pelo líder de incidente ou pelo dono do serviço, registrada em até 24 horas e revista depois.

O interesse do coordenador é que mudanças relevantes para a segurança (novo acesso remoto, mudanças em regras de firewall, novos fornecedores, software nos computadores da sala de controle) não possam escorregar para a classe "padrão", e que as mudanças emergenciais feitas durante incidentes sejam revistas em vez de se tornarem permanentes.

6.4 Escalonamento

Um caminho de escalonamento responde, para cada nível de gravidade: quem é chamado, por quem, como, em quanto tempo e o que acontece se a pessoa não atender. Escreva-o como uma tabela com substitutos, teste-o (Capítulo 11) e coloque-o onde os operadores do turno da noite possam encontrá-lo sem um computador — um cartão impresso na sala de controle —, porque o incidente pode ter levado os computadores.

O cartão da Kestrel Water lista o líder de incidente, o gerente de operações e o líder de segurança, com um substituto nomeado para cada um, além de números de celular que não dependem da rede corporativa.

6.5 Exemplo resolvido: verificando a RACI de incidentes (sintético)

A coordenadora redige a RACI de incidentes da Kestrel Water e executa o Laboratório 6, que aplica as regras da seção 6.2.

Laboratório 6 (salve como lab06.py e execute com python3 lab06.py):

# Lab 6 - RACI matrix check for incident coordination (offline, standard library only; synthetic)
PEOPLE = ["Coordinator", "Ops manager", "Security lead", "Comms", "Vendor", "CEO"]
# activity -> one letter per person (R responsible, A accountable, C consulted, I informed, - none)
RACI = {
    "Declare cyber incident":            "R A C I - I",
    "Decide to isolate stations":        "C A R I C I",
    "Switch stations to manual operation":"I A - - - I",
    "Notify regulator":                  "R - C C - A",
    "Brief hospital (critical customer)":"R C I R - A",
    "Approve vendor remote session":     "C A A - R -",
    "Public statement":                  "C C C R - -",
}
issues = []
load = {p: 0 for p in PEOPLE}
for act, codes in RACI.items():
    c = codes.split()
    assert len(c) == len(PEOPLE), act
    a = [p for p, x in zip(PEOPLE, c) if x == "A"]
    r = [p for p, x in zip(PEOPLE, c) if x == "R"]
    for p, x in zip(PEOPLE, c):
        if x in "RA": load[p] += 1
    if len(a) != 1: issues.append(f"{act}: {len(a)} accountable ({', '.join(a) or 'none'})")
    if not r: issues.append(f"{act}: nobody responsible")
    if len(r) > 1: issues.append(f"{act}: {len(r)} responsible ({', '.join(r)}) - name a lead")
    if act.startswith("Approve") and c[PEOPLE.index("Vendor")] in "RA":
        issues.append(f"{act}: vendor is responsible for approving its own access")
for i in issues: print("ISSUE", i)
print("R/A load:", ", ".join(f"{p}={n}" for p, n in load.items()))
print(f"{len(issues)} issues in {len(RACI)} activities")

Saída esperada (Python 3.13.5):

ISSUE Switch stations to manual operation: nobody responsible
ISSUE Brief hospital (critical customer): 2 responsible (Coordinator, Comms) - name a lead
ISSUE Approve vendor remote session: 2 accountable (Ops manager, Security lead)
ISSUE Approve vendor remote session: vendor is responsible for approving its own access
ISSUE Public statement: 0 accountable (none)
R/A load: Coordinator=3, Ops manager=4, Security lead=2, Comms=2, Vendor=1, CEO=2
5 issues in 7 activities

Cinco defeitos em sete atividades:

• Switch stations to manual operation (passar as estações para operação manual) tem um aprovador (o gerente de operações), mas nenhum responsável — na prática, quem faz isso são os operadores de turno e os técnicos de plantão, e eles não estão na matriz. A correção é acrescentar o supervisor de turno como R.
• Brief hospital (informar o hospital) tem dois responsáveis. A coordenadora e a comunicação podem achar, cada uma, que a outra ligou. Nomeie a coordenadora como líder (é uma interlocução operacional), com a comunicação consultada sobre a redação.
• Approve vendor remote session (aprovar a sessão remota do fornecedor) tem dois aprovadores e lista o fornecedor como responsável. O gerente de operações deve ser o único A (é dono das estações); o líder de segurança é C; o fornecedor solicita o acesso e é I quanto à decisão — uma parte nunca deve aprovar o próprio acesso.
• Public statement (declaração pública) não tem aprovador. O diretor-presidente deve ser A, e a comunicação, R.

A linha de carga mostra o gerente de operações com quatro entradas R/A — durante um incidente, a mesma pessoa está operando a planta. A coordenadora propõe um substituto para as entradas ligadas ao incidente. O laboratório verifica apenas a estrutura; se as pessoas certas foram escolhidas é um julgamento do patrocinador executivo.

6.6 Atividade prática

Escreva uma RACI para "integrar um novo fornecedor com acesso remoto" usando pelo menos cinco papéis e verifique-a contra as quatro regras, à mão ou editando o Laboratório 6.

Inclua o fornecedor como papel e garanta que ele nunca aprove o próprio acesso, o que o Laboratório 6 verifica explicitamente. Nomeie quem é o aprovador da criação da conta, quem verifica se o contrato tem as cláusulas de segurança e quem é informado quando a conta é habilitada. Depois conte as entradas R e A de cada pessoa: se um nome aparece em quase todas as linhas, a integração vai travar sempre que essa pessoa estiver de folga. Mostre o resultado ao gerente de operações e pergunte se falta alguém.

6.7 Erros comuns e limites

• Comitês como aprovadores ("o conselho de segurança").
• RACIs escritas só para dias normais, não para incidentes.
• Mudanças emergenciais nunca revistas.
• Listas de escalonamento sem substitutos, ou guardadas apenas na rede.

• Uma RACI é um contrato social: publique-a, repasse-a com cada pessoa e atualize-a depois de reorganizações.

• Deixar fora da matriz as pessoas que de fato fazem o trabalho, como o Laboratório 6 constatou com os operadores de turno na operação manual.

• Permitir que uma parte aprove o próprio acesso, como um fornecedor marcado como responsável por aprovar a sua sessão remota.
• Dar a uma pessoa tantas entradas R e A que o incidente passa a depender só dela.

Exercícios — capítulo 6

EX026 — Conserte a RACI. Objetivo: corrigir defeitos. Insumos: a matriz do Laboratório 6. Passos: propor linhas corrigidas para os cinco problemas e executar de novo a verificação (à mão ou com código). Evidência esperada: matriz corrigida e resultado limpo. Rubrica: 3 = zero problemas, o fornecedor nunca é A nem R na aprovação, um papel de turno acrescentado para a operação manual, um único líder para informar o hospital, o diretor-presidente como aprovador da declaração pública; 2 = resta um problema; 1 = parcial; 0 = nada.

EX027 — Classifique mudanças. Objetivo: aplicar as classes de mudança. Insumos: (a) nova regra de firewall permitindo uma VPN de fornecedor; (b) substituir a bateria defeituosa de um nobreak no armário de uma estação; (c) desabilitar uma conta comprometida durante um incidente; (d) instalar um agente de monitoramento no historiador. Passos: classificar e justificar. Evidência esperada: quatro classes. Rubrica: 3 = (a) normal (relevante para a segurança), (b) padrão, se existir um procedimento pré-aprovado, (c) emergencial com revisão posterior, (d) normal, com verificação de compatibilidade junto ao fornecedor; 2 = três certas; 1 = todas padrão; 0 = nada.

EX028 — Cartão de escalonamento. Objetivo: desenhar um caminho de escalonamento utilizável. Insumos: os papéis da seção 6.1. Passos: escrever o cartão impresso para os operadores do turno da noite para um suposto evento cibernético. Evidência esperada: conteúdo do cartão. Rubrica: 3 = gatilhos observáveis, primeira ligação e substituto com espaços para os números de telefone, limites de tempo, o que fazer enquanto isso (segurança primeiro, não desligar computadores sem instrução, anotar os horários), quando ligar diretamente para o líder de incidente; 2 = sem substitutos; 1 = "ligar para a TI"; 0 = nada.

EX029 — Análise de gargalo. Objetivo: usar a linha de carga. Insumos: a saída de carga do Laboratório 6. Passos: propor como reduzir a carga do gerente de operações durante incidentes sem enfraquecer a sua autoridade sobre a segurança. Evidência esperada: proposta. Rubrica: 3 = mantém as decisões de segurança com as operações, mas delega a interlocução e a aprovação de fornecedores a um substituto nomeado ou ao líder de incidente, com o gerente de operações consultado; 2 = delegação sem a ressalva de segurança; 1 = passa as decisões de segurança para a TI; 0 = nada.

EX030 — Revisão de mudanças emergenciais. Objetivo: encerrar mudanças emergenciais. Insumos: durante um incidente, um engenheiro acrescentou uma regra de firewall bloqueando todo acesso de fornecedores e criou uma conta temporária de administrador local. Passos: descrever a revisão pós-incidente. Evidência esperada: passos da revisão. Rubrica: 3 = listar as mudanças emergenciais a partir do registro, decidir manter/modificar/reverter cada uma, com dono, remover a conta temporária, restabelecer o acesso de fornecedores apenas pelo processo normal, atualizar a documentação; 2 = alguns passos; 1 = "deixar como está"; 0 = nada.

Síntese do capítulo

Um programa funciona com papéis atribuídos, uma RACI com um aprovador por atividade e um líder nomeado, uma governança de mudanças que mantém visíveis as mudanças relevantes para a segurança e um caminho de escalonamento que funciona offline, de noite. Verifique a estrutura da RACI, a titularidade das aprovações e a carga durante incidentes; revise toda mudança emergencial depois do evento.