Capítulo 15 — Fundamentos de segurança

Capítulo 15 — Fundamentos de segurança

Mapa da aula

Aula 15 publicada. Mapa, exemplo, EX029.

flowchart TD
  N0["15.1 As propriedades"]
  N1["15.2 Ameaça, vulnerabilidade, risco"]
  N2["15.3 Controles e princípios"]
  N3["15.4 Frameworks"]
  N4["15.6 Atividade prática"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX029"]

Desenho lógico

flowchart LR
  N0["15.1 As propriedades"]
  N1["15.2 Ameaça, vulnerabilidade, risco"]
  N2["15.3 Controles e princípios"]
  N3["15.4 Frameworks"]
  N4["15.6 Atividade prática"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX029"]

[15.1 As propriedades]
    |
    v
[15.2 Ameaça, vulnerabilidade, risco]
    |
    v
[15.3 Controles e princípios]
    |
    v
[15.4 Frameworks]
    |
    v
[15.6 Atividade prática]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX029]

Objetivos de aprendizagem e conexão

Ao fim deste capítulo você será capaz de (1) definir confidencialidade, integridade e disponibilidade e explicar por que sua prioridade é diferente em infraestrutura; (2) descrever ameaças, vulnerabilidades, risco e controles e relacioná-los numa avaliação de riscos; (3) aplicar princípios de projeto da literatura de segurança; e (4) mapear os controles de um sistema a um framework reconhecido. Ele integra os capítulos 1–14 e prepara os capítulos de arquitetura de segurança e de identidade (18–19) e os capítulos setoriais (do 20 em diante).

15.1 As propriedades

A confidencialidade limita quem pode ler a informação; a integridade garante que a informação e os sistemas não sejam alterados sem autorização; a disponibilidade garante acesso oportuno e confiável. Na TI corporativa, a confidencialidade costuma vir na frente. Em infraestrutura, o processo físico vem em primeiro lugar: integridade e disponibilidade do controle, depois a segurança operacional, depois a confidencialidade — embora a confidencialidade dos projetos de rede e das credenciais proteja as demais. Avizienis et al. (2004) colocam a segurança ao lado da confiabilidade, da segurança operacional e da manutenibilidade como atributos da dependabilidade; sua taxonomia de faltas, erros e falhas é usada ao longo de todo este livro.

15.2 Ameaça, vulnerabilidade, risco

Uma ameaça é uma causa potencial de dano (um ator com capacidade e intenção, ou um perigo natural); uma vulnerabilidade é uma fraqueza que uma ameaça pode explorar; o risco combina probabilidade e consequência. O NIST SP 800-30 Rev. 1 descreve a avaliação de riscos como a identificação de fontes e eventos de ameaça, vulnerabilidades, probabilidade e impacto. Em infraestrutura, comece pela consequência: quais são as piores coisas que poderiam acontecer ao serviço e às pessoas? O método Consequence-driven Cyber-informed Engineering (CCE), do Idaho National Laboratory, começa assim, perguntando qual perda ou uso indevido de funções seria inaceitável e trabalhando de trás para a frente até o que um adversário precisaria.

15.3 Controles e princípios

Os controles são preventivos, detectivos, corretivos ou compensatórios, e técnicos, procedimentais ou físicos. Princípios de projeto de Saltzer and Schroeder (1975): economia de mecanismo, padrões à prova de falhas, mediação completa, projeto aberto, separação de privilégios, privilégio mínimo, mínimo mecanismo comum e aceitabilidade psicológica. Acrescente a defesa em profundidade (camadas cujas falhas são independentes) e a presunção de violação (assume breach: projetar de modo que o comprometimento de uma camada seja detectado e contido). No projeto do TMRP, o modo manual local com uma chave seletora física é um exemplo de separação de privilégios, e o analisador de cloro independente é uma camada de detecção fora dos sistemas que ele observa.

15.4 Frameworks

Os frameworks dão estrutura e um vocabulário comum. O NIST Cybersecurity Framework 2.0 organiza os resultados em Govern, Identify, Protect, Detect, Respond e Recover. O catálogo NIST SP 800-53 Rev. 5 lista controles; a ISA/IEC 62443 especifica requisitos para sistemas e componentes de automação industrial, com níveis de segurança; o NCSC Cyber Assessment Framework, do Reino Unido, é baseado em resultados para serviços essenciais. Um framework é uma lista de verificação de resultados, não uma evidência de que um projeto os alcança.

15.5 Exemplo resolvido: a primeira tabela de riscos do TMRP (sintético)

Cada linha nomeia primeiro uma consequência em termos de serviço. A tabela é uma hipótese a ser refinada nos capítulos 23 e 27.

15.6 Atividade prática

Mapeie cada controle proposto na §15.5 a uma função do CSF 2.0 e a uma família de controles do SP 800-53, citando os documentos. Para cada linha da tabela de riscos do TMRP, escolha a função do CSF que melhor descreve o propósito principal do controle proposto e anote onde um controle serve a duas. A telemetria autenticada é principalmente protetiva, o alarme do analisador independente é principalmente detectivo, e os backups off-line testados apoiam a recuperação. Cite os documentos dos frameworks com suas versões. Depois escreva uma frase para cada linha explicando o que o mapeamento não lhe diz, porque um mapeamento correto ainda não é evidência de que o controle funciona na LRWA.

15.7 Erros comuns e limites

• Copiar as prioridades corporativas para a TO.
• Registros de riscos que listam vulnerabilidades sem consequências.
• Camadas de "defesa em profundidade" que compartilham um único ponto de falha.
• Tratar o mapeamento a um framework como prova de segurança.
• Notas de probabilidade sem base declarada.

A primeira tabela de riscos do TMRP evita esses erros ao nomear primeiro cada consequência em termos de serviço, de modo que toda vulnerabilidade fique ligada a um dano, e ao tratar suas probabilidades como hipóteses a refinar nos capítulos seguintes. Suas camadas são conferidas quanto a dependências compartilhadas antes de serem chamadas de independentes.

Exercícios — capítulo 15

EX029 — Auditoria de princípios. Objetivo: aplicar princípios de projeto. Entradas: o Laboratório 8 e a máquina de estados da bomba da §9.5. Passos: para cada um, identifique dois princípios de Saltzer–Schroeder aplicados e um violado ou não tratado, e proponha uma correção. Evidência esperada: tabela. Rubrica: 3 = princípios atribuídos corretamente, com uma lacuna crível (por exemplo, a chave fixada no código do Laboratório 8 viola a separação/o privilégio mínimo; o projeto aberto é respeitado pelo HMAC); 2 = uma atribuição errada; 1 = apenas nomes; 0 = nada.

EX030 — Cenário a partir da consequência. Objetivo: começar pela consequência. Entradas: o serviço da LRWA. Passos: identifique duas consequências inaceitáveis e, para cada uma, as funções que um adversário precisaria usar indevidamente e o controle de engenharia mais barato que tornaria a consequência fisicamente impossível ou limitada. Evidência esperada: meia página. Rubrica: 3 = consequências em termos de serviço, funções específicas, pelo menos um limite físico projetado (por exemplo, alívio mecânico de sobrepressão, limite por fiação dedicada na bomba de cloro); 2 = todos os controles digitais; 1 = genérico; 0 = nada.

Síntese do capítulo

A segurança de infraestrutura protege um serviço físico: a integridade e a disponibilidade do controle e a segurança operacional vêm na frente. Comece pela consequência, depois as ameaças e as vulnerabilidades, depois os controles. Aplique princípios de projeto duradouros, empilhe defesas cujas falhas sejam independentes, presuma a violação e use os frameworks como listas de verificação estruturadas — não como evidência.

Continue estudando — capítulo 15 de 50

← Capítulo 14 · Índice de capítulos do curso · Capítulo 16 →

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