Capítulo 37 — Arquitetura e engenharia de segurança: operações
Mapa da aula
Aula 37 publicada. Mapa, exemplo, EX109.
flowchart TD
N0["37.1 Operações desde o projeto"]
N1["37.2 Detecção a partir das ameaças"]
N2["37.3 Patches e mudanças"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3
N3 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX109"]
Desenho lógico
flowchart LR
N0["37.1 Operações desde o projeto"]
N1["37.2 Detecção a partir das ameaças"]
N2["37.3 Patches e mudanças"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3 --> Q["EX109"]
[37.1 Operações desde o projeto]
|
v
[37.2 Detecção a partir das ameaças]
|
v
[37.3 Patches e mudanças]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX109]
Objetivos de aprendizagem
Você vai (1) projetar as operações de segurança para a nova arquitetura; (2) definir casos de uso de detecção a partir do modelo de ameaças; (3) planejar a aplicação de patches e a gestão de mudanças preservando as propriedades de segurança.
37.1 Operações desde o projeto
Uma arquitetura só é tão boa quanto sua operação. Sofia trabalha com o centro de operações da Corvia para planejar como o novo back-office será operado com segurança: quem monitora quais alertas, quem pode mudar configurações, como os incidentes são escalados e como os acessos são revisados. Ela usa o NIST CSF 2.0, cujas funções são governar, identificar, proteger, detectar, responder e recuperar (govern, identify, protect, detect, respond, recover), para verificar se cada função tem responsáveis e procedimentos para o novo sistema. Planejar as operações durante o projeto evita construir sistemas que ninguém consegue monitorar ou manter adequadamente depois que a equipe do projeto sai.
37.2 Detecção a partir das ameaças
Sofia transforma as ameaças do capítulo 23 em casos de uso de detecção. Para registros de validação repetidos: alertar quando as rejeições por replay de um validador excederem um limiar. Para tabelas de tarifas maliciosas: alertar sobre qualquer versão não publicada. Para a exportação de dados de viagem por insiders: alertar quando as exportações excederem o volume normal ou ocorrerem fora do horário de trabalho. Cada caso de uso lista a fonte de dados, a lógica, os falsos positivos esperados e o playbook de resposta. Derivar a detecção do modelo de ameaças garante que o monitoramento se concentre no que importa para este sistema, e não em alertas genéricos copiados de modelos de fornecedores.
37.3 Patches e mudanças
As mudanças podem quebrar propriedades de segurança. Sofia define um processo de mudanças em que qualquer mudança que toque autenticação, criptografia, regras de rede ou logging precisa de revisão de segurança e de uma nova execução dos testes de verificação relevantes dos capítulos 30 e 40. Os patches de rotina seguem um calendário, com caminhos de emergência para vulnerabilidades críticas. Ela também exige que o modelo de arquitetura seja atualizado quando uma mudança alterar fluxos ou componentes. Daniel observa que a maioria das organizações não tem dificuldade em projetar sistemas seguros, e sim em mantê-los seguros ao longo de anos de pequenas mudanças bem-intencionadas.
Exemplo resolvido
Sofia relaciona o back-office às funções do CSF 2.0, deriva três casos de uso de detecção do modelo de ameaças e define um processo de mudanças com nova verificação de segurança.
Caso sintético. Os casos de uso e os processos são sintéticos; o NIST CSF 2.0 é real.
Erros e limites
Os limiares de detecção precisam de ajuste depois do lançamento. Os processos de mudança podem virar gargalos se toda mudança exigir revisão completa.
Exercícios
-
EX109 — Funções do CSF. Liste as seis funções do CSF 2.0. Rubrica: 3 = governar, identificar, proteger, detectar, responder, recuperar (govern, identify, protect, detect, respond, recover);; 2 = cinco;; 1 = três;; 0 = nenhuma.
-
EX110 — Detecção de exportação por insider. Como a exportação de dados de viagem por um insider é detectada? Rubrica: 3 = alerta sobre volume de exportação incomum ou exportações fora do horário;; 2 = volume ou horário;; 1 = vago;; 0 = nenhuma.
-
EX111 — Gatilho de revisão. Que mudanças precisam de revisão de segurança e nova verificação? Rubrica: 3 = as que tocam autenticação, criptografia, regras de rede ou logging;; 2 = três;; 1 = todas as triviais;; 0 = nenhuma.
Síntese
A segurança operacional é projetada junto com a arquitetura, com detecção derivada das ameaças e um controle de mudanças que protege as propriedades de segurança.
Continue estudando — aula 37 (capítulo 37 de 50)
← Capítulo 36 · Índice das aulas · Capítulo 38 →
Continue para a próxima aula já escrita.