Por que planos de resposta a incidentes falham?
Problema de segurança como vazamentos, invasões, e outros quetais sempre irão assombrar empresas – especialmente porque o mundo do cibercrime virtual está cada vez mais rentável e evoluído tecnicamente. Depois de acontecer algum incidente de segurança em infraestruturas críticas, o tempo começa a correr rapidamente e qualquer ação pode ser fatal.
Organizações, nesses casos, costumam ter um plano de resposta à incidentes que, em um primeiro momento, parece estar bem-estruturado, mas que pode se transformar em pesadelo em poucos instantes se não for bem-implantado.
Em vez de identificar, analisar e erradicar a ameaça, as empresas podem facilmente se complicar em processos que as impedem de reagir em tempo hábil, o que as põe em perigo, comenta Susan Peterson, líder de produtos de segurança da GE Oil & Gas, em uma coluna ao TechCrunch.
“Embora muitas organizações industriais tenham plano ativos, pouquíssimas os rodam por meio de exercícios de simulação de rotina”, afirma a especialista. “Exercícios simulados apontam diversas suposições incorretas feitas ao longo do processo e identificam buracos onde há falta de contatos ou protocolos críticos para um programa bem-sucedido”, completa. Susan aponta três motivos pelos quais um programa de resposta a incidentes falha.
1. Linha de comunicação
Quando o incidente ocorre, as principais partes interessadas devem estar cientes do que está acontecendo e como a situação está sendo tratada. Gerenciar expectativas em torno da linha de comunicação é parte importante de um plano de resposta a incidentes. Para isso deve haver algum encarregado que pode alertar rapidamente as partes que necessitam ser alertadas e informar os próximos passos – movimento crucial quando um incidente impacta a TI, equipes de campo, múltiplas unidades de negócios, regiões globais e fornecedores. Para Susan, “exercícios simulados garantem que o plano de comunicação está claro, preciso e que as informações de contato necessários estão prontas para conscientizar todos os interessados”, afirma.
2. Fornecedores
Quando o assunto é gerenciamento de fornecedores em um plano de resposta a incidentes, há uma série de questões ou hipóteses que devem ser verificadas durante um exercício simulado. Qual o papel que os fornecedores exercem em caso de ataque? Eles possuem acordo contratual que descreve o que eles devem fazer? Eles realizaram a instalaçam de software terceiro? Eles sabem qual software a empresa tem em operação? Será que eles rodam simulações de atualizações de softwares ou de máquinas antes de realmente implementá-las?
“Essa última questão, em especial, é crítica para ambientes de tecnologia operacionais que não reiniciam regularmente para atualizações de software”, afirma Susan, completando que, em estudos recentes, apenas um terço das empresas está confiante de que sabe o número exato de fornecedores que acessam seus sistemas. “Um plano de resposta a incidentes deve incorporar todas as informações necessárias sobre quem tem acesso às redes e quais fornecedores irão desempenhar algum papel em resposta a ataques cibernéticos, incluindo a forma como deve ser comunicado e como podem ajudar a mitigar o risco”, completa.
3. Flexibilidade operacional
Se a interface de máquina humana de um sistema de controle cai como resultado de um ataque cibernético em uma operação, o que poderia manter os sistemas funcionando apesar da deficiência? Quando sistemas de controle distribuído (DCS) estão fora do ar, a organização pode operar a maquinaria por meio do painel de controle.
De acordo com Susan, porém, essa não é uma solução simples e líderes devem considerar se há um operador em cada turno qualificado para operar o controle por meio do painel e não pelo DCS.
Ataques são parte integrante de um ambiente conectado e planos de resposta a incidentes não são tanto sobre o ataque em si, mas sobre resiliência. Práticas de segurança corporativa devem ser um movimento colaborativo e aberto, não apenas dentro das organizações, mas em todos os setores.
