Capítulo 1 — Fundamentos de segurança para profissionais

Mapa da aula

Aula 01 publicada. Mapa, exemplo, EX001.

flowchart TD
  N0["1.1 O que é um serviço essencial"]
  N1["1.2 Consequência primeiro"]
  N2["1.3 O trabalho do coordenador"]
  N3["1.4 O vocabulário do risco"]
  N4["1.5 Frameworks como mapas"]
  N5["1.7 Atividade prática"]
  N6["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX001"]

Desenho lógico

flowchart LR
  N0["1.1 O que é um serviço essencial"]
  N1["1.2 Consequência primeiro"]
  N2["1.3 O trabalho do coordenador"]
  N3["1.4 O vocabulário do risco"]
  N4["1.5 Frameworks como mapas"]
  N5["1.7 Atividade prática"]
  N6["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX001"]

[1.1 O que é um serviço essencial]
    |
    v
[1.2 Consequência primeiro]
    |
    v
[1.3 O trabalho do coordenador]
    |
    v
[1.4 O vocabulário do risco]
    |
    v
[1.5 Frameworks como mapas]
    |
    v
[1.7 Atividade prática]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX001]

Objetivos de aprendizagem e conexão

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

• explicar o que torna um serviço "essencial" e por que a sua segurança é julgada pela consequência para as pessoas, e não pelo dano aos computadores;
• descrever o trabalho do coordenador e distingui-lo do trabalho do engenheiro, do analista de segurança e do executivo;
• usar o vocabulário central do risco — ativo, ameaça, vulnerabilidade, probabilidade, consequência, dono do risco, apetite a risco — com precisão suficiente para que os colegas possam agir a partir das suas frases;
• situar o seu trabalho dentro de um framework reconhecido (as seis funções do NIST Cybersecurity Framework 2.0) sem confundir o framework com o trabalho.

Este capítulo pressupõe apenas noções básicas de segurança. Tudo o que vem depois no livro se apoia nas distinções feitas aqui.

1.1 O que é um serviço essencial

Um serviço essencial é aquele cuja interrupção prejudica pessoas, a economia ou a ordem pública rapidamente e em grande escala: água potável, eletricidade, saúde, transporte, pagamentos, comunicações de emergência. Os governos os listam de formas diferentes. Os Estados Unidos agrupam dezesseis setores de infraestrutura crítica (CISA, Critical Infrastructure Sectors) e descrevem as funções críticas nacionais subjacentes — por exemplo, "fornecer água" ou "prestar atendimento médico" — que atravessam os setores (CISA, National Critical Functions Set). A Diretiva NIS2 da União Europeia nomeia setores de "alta criticidade" e impõe obrigações a entidades essenciais e importantes, inclusive aos seus órgãos de gestão (Directive (EU) 2022/2555).

A ideia útil em todas essas listas é a mesma: o que se protege é uma função entregue a pessoas, não um prédio ou um servidor. A Kestrel Water não existe para operar computadores; existe para que 180.000 pessoas possam beber água segura, com pressão adequada, a cada hora de cada dia. Os seus computadores importam na medida em que a função depende deles.

1.2 Consequência primeiro

Num escritório, a tríade clássica da segurança costuma ser recitada como confidencialidade, integridade e disponibilidade, nessa ordem. Num serviço essencial, a ordem de preocupação geralmente muda. O guia do NIST para a segurança da tecnologia operacional observa que os sistemas de TO afetam diretamente o mundo físico e que as suas prioridades — segurança humana, disponibilidade e integridade do controle — diferem das prioridades típicas de TI (NIST SP 800-82 Rev. 3).

Para um coordenador, isso tem um significado prático. Ao classificar um problema, pergunte nesta ordem:

1. Isso pode ferir alguém? (dosagem química errada, perda de pressão para um hospital, um trabalhador exposto a uma bomba em movimento);
2. Isso pode parar o serviço, por quanto tempo e para quantas pessoas?
3. Isso pode tornar o serviço não confiável — operadores já sem certeza de que as telas mostram a verdade?
4. Isso pode expor informações — dados de clientes, projetos de rede, relatórios de vulnerabilidades?

Um vazamento de dados do sistema de faturamento é grave e pode acarretar obrigações legais, mas uma mudança silenciosa num setpoint de cloro é uma categoria diferente de problema. Um coordenador que não consegue explicar essa diferença numa frase a um conselho verá o dinheiro ir para o lugar errado.

1.3 O trabalho do coordenador

O diretor de operações da Kestrel Water, E. Varga, escreveu a descrição do novo cargo. O seu núcleo são três verbos: conectar, viabilizar decisões e evidenciar.

• Conectar. Operações, TI, engenharia, atendimento ao cliente, comunicação, fornecedores e a diretoria detêm, cada um, parte do quadro. O coordenador garante que as partes se encontrem: as pessoas certas ficam sabendo de um risco, de uma mudança ou de um incidente a tempo.
• Viabilizar decisões. O coordenador raramente toma as decisões importantes. O gerente de operações decide se uma estação será operada manualmente; o diretor-presidente decide o que dizer ao público. O coordenador garante que a decisão tenha um dono, as informações de que precisa, um prazo e um registro.
• Evidenciar. O coordenador consegue mostrar, a um conselho, auditor ou regulador, o que foi decidido, por quê e se foi feito.

O coordenador não é o engenheiro que reconfigura o firewall, o analista que lê os logs nem o executivo que aceita o risco. Confundir esses papéis é a falha mais comum dos novos coordenadores: ou tentam fazer eles mesmos o trabalho técnico (e perdem de vista o programa), ou tomam decisões que pertencem a alguém com autoridade sobre o serviço (e depois são desautorizados ou culpados).

1.4 O vocabulário do risco

Palavras precisas economizam horas de reunião. As definições a seguir seguem o uso comum da NIST SP 800-30 Rev. 1, simplificadas para a prática:

• Ativo — qualquer coisa de que o serviço depende: equipamentos, software, dados, pessoas, fornecedores, prédios.
• Ameaça — uma circunstância ou um agente com potencial de causar dano (um grupo criminoso, uma atualização descuidada, uma enchente).
• Vulnerabilidade — uma fraqueza que uma ameaça poderia explorar (uma conta de fornecedor sem autenticação multifator).
• Probabilidade — quão provável é que o dano aconteça num dado período, considerados os controles existentes.
• Consequência (ou impacto) — o que acontece com o serviço e com as pessoas se o dano acontecer.
• Risco — a combinação: uma declaração do que pode acontecer, como, com que probabilidade e com que gravidade.
• Dono do risco — a pessoa com autoridade e orçamento para decidir como o risco é tratado. Em geral, um gestor do serviço afetado, não o coordenador.
• Apetite a risco — quanto risco a liderança da organização está disposta a aceitar na busca dos seus objetivos, declarado de antemão.
• Tratamento — reduzir, evitar, transferir (por exemplo, por seguro ou contrato) ou aceitar o risco.

Uma declaração de risco bem formada tem uma causa, um evento e uma consequência: "Como a conta remota do fornecedor de bombas não tem segundo fator, um atacante com a senha do fornecedor poderia entrar nos controladores das estações e alterar os setpoints das bombas, causando perda de pressão para até 20.000 clientes, incluindo o hospital." Compare com "risco de acesso de fornecedor", que ninguém consegue assumir nem tratar.

1.5 Frameworks como mapas

O NIST Cybersecurity Framework 2.0 organiza resultados em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar (NIST CSWP 29, The NIST Cybersecurity Framework 2.0). A versão 2.0 acrescentou Governar, que abrange estratégia, papéis, política, gestão de riscos e risco da cadeia de suprimentos — a maior parte do assunto deste livro. O Cyber Assessment Framework do Reino Unido, escrito para operadores de serviços essenciais, organiza-se em torno de objetivos como gerenciar o risco de segurança e minimizar o impacto de incidentes (NCSC, Cyber Assessment Framework).

Um framework é um mapa de resultados. Ele diz o que um bom programa alcança, não como a sua empresa deve alcançá-lo, e certamente não que você o alcançou. O Capítulo 5 mostra como ler avaliações baseadas em frameworks sem se deixar enganar por elas.

1.6 Exemplo resolvido: a primeira semana (sintético)

No primeiro dia, a nova coordenadora recebe três pedidos:

1. O departamento de TI pede que ela "dê o aval" a um novo antivírus para os computadores da sala de controle até sexta-feira.
2. O presidente do comitê de auditoria do conselho, T. Lindqvist, pede "a nossa nota de risco cibernético" para a reunião do comitê do mês que vem.
3. O gerente de operações, A. Mensah, comenta que um fornecedor de bombas "às vezes entra de casa" para consertar a estação KW-07.

Uma resposta fraca os trata como três tarefas. A resposta de um coordenador os ordena por consequência e por quem é dono da decisão:

Tabela da aula; deslize para ver todas as colunas →

O terceiro item, levantado casualmente, é o de maior consequência. Coordenadores aprendem a ouvir o risco na conversa.

1.7 Atividade prática

Escolha um serviço essencial que você conheça (o seu próprio empregador, ou um serviço público descrito numa reportagem). Escreva, em no máximo uma página: a função que ele entrega às pessoas; três coisas de que ele depende; e uma declaração de risco bem formada, com causa, evento e consequência. Marque quais partes você sabe e quais você pressupõe.

Depois entregue a página a um colega e peça que ele nomeie o dono do risco apenas a partir da sua declaração. Se ele não conseguir, a consequência ou o serviço afetado provavelmente estão vagos demais. Compare a sua função com a frase da Kestrel Water sobre água segura, com pressão adequada, para 180.000 pessoas: ela nomeia quem é atendido e do que essas pessoas precisam.

1.8 Erros comuns e limites

• Tratar a "segurança" como propriedade do departamento de TI. Num serviço essencial, as operações são donas da consequência.
• Escrever riscos como substantivos ("ransomware", "insider") em vez de declarações que alguém possa assumir.
• Pedir uma nota de risco única. Notas escondem qual serviço, quais pessoas e qual decisão.
• Confundir um perfil de framework com evidência de que os controles funcionam.

• Este capítulo simplifica: métodos reais de risco (Capítulo 4) exigem calibração, dados e julgamento, e as leis diferem entre países.

• Dar o aval a uma mudança que pertence a outra pessoa, como a coordenadora evitou com o pedido do antivírus para os computadores da sala de controle.

• Tratar um comentário casual, como o de um fornecedor que às vezes entra de casa, como conversa à toa em vez de um risco candidato.

Exercícios — capítulo 1

EX001 — Reescreva riscos. Objetivo: produzir declarações de risco que possam ser assumidas. Insumos: as entradas de registro "ransomware", "PCs antigos" e "acesso de fornecedor". Passos: reescrever cada uma como uma declaração de causa-evento-consequência situada na Kestrel Water. Evidência esperada: três declarações. Rubrica: 3 = cada uma tem causa, evento e uma consequência para o serviço medida em pessoas ou tempo, e nomeia a função afetada; 2 = uma não tem consequência; 1 = ainda genéricas; 0 = nada.

EX002 — Ordem de preocupação. Objetivo: aplicar a classificação com a consequência primeiro. Insumos: quatro eventos: (a) banco de dados de faturamento copiado por um intruso; (b) telas dos operadores na KW-03 congelam por 40 minutos; (c) setpoint de cloro na KW-05 alterado sem aprovação; (d) diagrama da rede interna enviado por e-mail a um endereço errado. Passos: classificá-los e justificar. Evidência esperada: classificação com uma frase para cada um. Rubrica: 3 = (c) primeiro por razões de segurança, (b) em segundo pela perda de visão e possível perda de controle, depois (d) e (a), com raciocínio sobre quem é prejudicado e como; observa que obrigações legais ainda podem tornar (a) urgente; 2 = apenas os dois primeiros corretos; 1 = classifica (a) em primeiro sem raciocínio; 0 = nada.

EX003 — Limites de papel. Objetivo: separar coordenação de autoridade. Insumos: o pedido do antivírus na seção 1.6. Passos: escrever o e-mail que você enviaria à TI e a A. Mensah. Evidência esperada: duas mensagens curtas. Rubrica: 3 = recusa o aval exclusivo, nomeia o dono da decisão, pede a compatibilidade do fornecedor, um teste fora de produção e um plano de reversão, propõe uma data; 2 = dono correto sem pedido de teste; 1 = dá o aval; 0 = nada.

EX004 — Mapeie para o CSF 2.0. Objetivo: usar um framework como mapa. Insumos: os três pedidos da seção 1.6. Passos: atribuir cada um a uma ou mais funções do CSF 2.0 e explicar. Evidência esperada: três atribuições. Rubrica: 3 = antivírus → Proteger (e Governar, pelos direitos de decisão); nota de risco → Governar; acessos do fornecedor → Governar (cadeia de suprimentos) e Identificar/Proteger; observa que um rótulo de função não é evidência; 2 = rótulos sem razões; 1 = um rótulo; 0 = nada.

EX005 — Ouça o risco. Objetivo: identificar o risco na conversa. Insumos: o comentário "o turno da noite deixa a porta da estação escorada aberta porque o leitor de crachá é lento." Passos: escrever uma declaração de risco, nomear um provável dono e uma pergunta que você faria antes de propor qualquer correção. Evidência esperada: declaração, dono, pergunta. Rubrica: 3 = a declaração liga o acesso físico ao equipamento de controle e à consequência; o dono é o gerente da estação ou de operações; a pergunta respeita o motivo de a equipe agir assim (por exemplo, quão lento é, e a porta é necessária como saída de emergência?); 2 = sem pergunta; 1 = culpa a equipe; 0 = nada.

Síntese do capítulo

Um serviço essencial é uma função entregue a pessoas, e a sua segurança se mede pela consequência: segurança das pessoas, continuidade, confiabilidade e, depois, confidencialidade. O coordenador conecta as pessoas que detêm partes do quadro, garante que as decisões tenham donos e registros, e guarda as evidências. Declarações de risco precisas e um framework usado como mapa — e não como prova — são as primeiras ferramentas do trabalho.