Capítulo 33 — Inteligência de ameaças e OSINT: segurança operacional e resiliência
Mapa da aula
Aula 33 publicada. Mapa, exemplo, EX097.
flowchart TD
N0["33.1 Como a inteligência pode ferir a operação"]
N1["33.2 Intertravamentos"]
N2["33.3 Resiliência à perda de fontes"]
N3["33.4 Retorno à configuração anterior"]
N4["33.5 Coordenação com a operação"]
N5["Nota de prática — casos de segurança"]
N6["Depois de uma anulação"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX097"]
Desenho lógico
flowchart LR
N0["33.1 Como a inteligência pode ferir a operação"]
N1["33.2 Intertravamentos"]
N2["33.3 Resiliência à perda de fontes"]
N3["33.4 Retorno à configuração anterior"]
N4["33.5 Coordenação com a operação"]
N5["Nota de prática — casos de segurança"]
N6["Depois de uma anulação"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX097"]
[33.1 Como a inteligência pode ferir a operação]
|
v
[33.2 Intertravamentos]
|
v
[33.3 Resiliência à perda de fontes]
|
v
[33.4 Retorno à configuração anterior]
|
v
[33.5 Coordenação com a operação]
|
v
[Nota de prática — casos de segurança]
|
v
[Depois de uma anulação]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX097]
Objetivos de aprendizagem
Você vai (1) analisar como as saídas de CTI poderiam prejudicar a tecnologia operacional; (2) projetar intertravamentos de segurança para ações automatizadas; (3) planejar a resiliência contra a perda de feeds ou parceiros; (4) ensaiar um retorno seguro à configuração anterior.
33.1 Como a inteligência pode ferir a operação
Um bloqueio amplo demais em um firewall de OT poderia separar um mestre SCADA de suas unidades terminais remotas, eliminando a visibilidade da rede elétrica. Uma marcação "maliciosa" equivocada no servidor de atualizações de um fornecedor poderia bloquear um patch relevante para a segurança operacional. Em infraestrutura crítica, falsos positivos têm consequências físicas. As revisões de projeto de Kofi perguntam, para cada ação automatizada, que efeito físico uma decisão errada poderia ter. Na TI corporativa a resposta costuma ser um site bloqueado e um chamado. Na OT pode ser uma sala de controle perdendo de vista parte da rede durante uma tempestade, justamente quando os operadores mais precisam dela. Essa diferença justifica regras diferentes para os dois ambientes.
33.2 Intertravamentos
O Lantern aplica intertravamentos: nenhuma ação automática em segmentos de OT; uma lista de endereços operacionais protegidos que nenhum bloqueio pode incluir; um tamanho máximo de mudança por envio; e aprovação por duas pessoas para qualquer regra de OT. Eles espelham a ideia da engenharia de segurança de que uma única falha não deve causar dano. Kofi testa cada intertravamento com um envio sintético feito para dispará-lo: uma lista com um endereço protegido, uma lista muito maior que o limite, uma aprovação por uma só pessoa. Cada teste precisa ser recusado e registrado.
33.3 Resiliência à perda de fontes
Se um parceiro importante parar de compartilhar, a detecção deve degradar de forma controlada. Fontes diversas, analíticas sobre a telemetria interna e detecções comportamentais mapeadas no ATT&CK reduzem a dependência de qualquer feed isolado. Kofi testou isso reproduzindo um mês de tráfego sintético sem o maior parceiro. As detecções caíram, mas as regras comportamentais ainda pegaram a maioria das intrusões simuladas que os indicadores haviam pegado, embora muitas vezes mais tarde. O resultado mostrou à BEN quão exposta ela ficaria se esse parceiro parasse de compartilhar e apoiou o investimento em analíticas internas.
33.4 Retorno à configuração anterior
Cada envio registra o conjunto de regras anterior. Um retorno testado, com um único comando, o restaura em minutos. Exercícios de retorno são feitos a cada trimestre no ambiente de teste. O exercício de Kofi mede quanto tempo o retorno leva e confere se as regras restauradas correspondem exatamente à cópia armazenada. O primeiro exercício levou vinte minutos porque o comando precisava de uma credencial que ninguém tinha à mão; agora o roteiro indica onde ela fica guardada. Um retorno que nunca é praticado tende a falhar na primeira vez em que é realmente necessário.
33.5 Coordenação com a operação
Os engenheiros de OT são donos das decisões operacionais. O Lantern fornece recomendações e evidências; ele não passa por cima da operação. Na prática, isso significa que as saídas do Lantern para a OT são recomendações com evidências anexadas. Um engenheiro de OT pode recusar um bloqueio porque ele interromperia uma janela de manutenção planejada, e essa decisão prevalece. Kofi registra o motivo, para que os analistas vejam por que o bloqueio não aconteceu. Se a ameaça crescer, os analistas a levantam de novo com novas evidências, em vez de contornar a equipe de operação. As duas equipes revisam juntas, todo mês, as recomendações recusadas.
Nota de prática — casos de segurança
Um argumento de segurança curto declara o perigo, os intertravamentos que o previnem e a evidência de que cada intertravamento funciona. Os revisores podem então contestar um elo específico em vez do projeto inteiro.
Depois de uma anulação
Sempre que um engenheiro anula um intertravamento, o dia útil seguinte inclui uma revisão curta do porquê, de se o intertravamento estava errado e de se a regra deve mudar.
Exemplo resolvido
Um parceiro marca como malicioso o endereço do servidor de atualizações do fornecedor de relés da BEN depois de um comprometimento em outro lugar. O intertravamento de endereços protegidos bloqueia o envio automático; os engenheiros de OT revisam, confirmam que o servidor do fornecedor está limpo para a região da BEN e registram a decisão.
Caso sintético. O fornecedor e a marcação são inventados.
Erros e limites
Intertravamentos podem ser contornados sob pressão; audite cada anulação. A análise de segurança operacional precisa envolver engenheiros de OT.
Exercícios
- EX097 — Dano físico. Dê uma forma pela qual um bloqueio no estilo de TI poderia causar dano operacional em uma rede elétrica. Rubrica: 3 = mecanismo específico (cortar a visibilidade do SCADA, bloquear patch de segurança); 2 = vago; 1 = tentativa mínima; 0 = nenhuma.
- EX098 — Lista de intertravamentos. Cite três intertravamentos que o Lantern aplica às ações de OT. Rubrica: 3 = três entre nenhuma ação automática em OT/lista de endereços protegidos/tamanho máximo de mudança/aprovação por duas pessoas; 2 = dois; 1 = um; 0 = nenhuma.
- EX099 — Perda de fonte. Como a detecção comportamental mapeada no ATT&CK ajuda quando um feed desaparece? Rubrica: 3 = detecta técnicas independentemente dos indicadores do feed; 2 = parcial; 1 = não ajuda; 0 = nenhuma.
Síntese
Trate falsos positivos como riscos físicos, intertrave as ações automatizadas, diversifique as fontes e ensaie o retorno à configuração anterior.
Continue estudando — capítulo 33 de 50
← Capítulo 32 (rascunho) · Índice de capítulos do curso · Capítulo 34 (rascunho) →