O estabelecimento de um plano de respostas a incidentes de segurança é essencial não apenas para grandes empresas, mas também para pequenas empresas.
As leis de segurança cibernética ou o GDPR/LGPD exigem não apenas um processo de incidente de segurança, mas também exigem que uma notificação de incidente de segurança seja enviada à autoridade supervisora e às principais partes interessadas.
Um plano completo de incidente de segurança envolve a equipe de tratamento de incidentes de segurança, recursos humanos, departamento jurídico e também grupos de supervisão externos.
Atividades de Segurança
Plano de respostas a incidentes
Embora existam muitas tecnologias e ferramentas de segurança que podem ajudar a identificar, proteger, detectar, responder e recuperar de ameaças, as relações públicas e a comunicação pública desempenham papéis críticos em partes não técnicas. Vamos nos concentrar principalmente nas atividades de segurança durante os estágios de preparação, detecção, contenção e manuseio pós-incidente, com base no NIST SP 800-62.
Se você desejar, aqui estão algumas das referências recomendadas do setor relacionadas à resposta a incidentes de segurança:
- NIST SP 800-62 Computer Security Incident Handling Guide (https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/ final)
- SANS Incident Handler Handbook (https://www.sans.org/reading-room/whitepapers/incident/incident-handlers-handbook-33901)
- ENISA Cloud Computing Benefits, risks, and recommendations for information security (https://resilience.enisa.europa.eu/cloud-security-and-resilience/publications/cloud-computing-benefits-risks-and-recommendations-for-information-security)
- MITRE Ten Strategies of a World-Class Cyber Security Operations Center (https://www.mitre.org/sites/default/files/publications/pr-13-1028-mitre-10-strategies-cyber-ops-center.pdf)
- FIRST (https: //www.first .org / education / FIRST_PSIRT_Service_Framework_v1.0)
Ciclo de vida de um plano de respostas a incidentes
Bom, voltando ao plano de resposta a incidentes, O NIST SP 800-62 define o ciclo de vida de resposta a incidentes como composto por quatro fases:
A preparação é a parte mais crítica do plano de respostas a incidentes.
Não podemos prever ou evitar completamente nenhum incidente de segurança, mas podemos planejar uma preparação completa para um incidente de segurança.
A preparação abrange tudo que é necessário para prevenir e lidar com um incidente de segurança: todos os processos, ferramentas de análise, tecnologias de segurança e recursos de equipe. A preparação não apenas ajuda a prevenir incidentes de segurança, mas também a minimizar os danos causados durante um incidente de segurança.
Práticas de segurança sugeridas no plano de respostas a incidentes
Plano de resposta a incidentes
Algumas práticas de segurança sugeridas a serem executadas na fase de preparação da resposta a incidentes:
- Plano de comunicação do operador de incidentes
- Ferramentas de hardware e software de análise de incidentes
- Diagrama de rede e linhas de base existentes
- Controles de prevenção, como riscos avaliações, segurança do host, segurança de rede, proteção contra malware, conscientização do usuário e treinamento
- O exercício de segurança da equipe azul e vermelha
- Programa de recompensa para hackers da Whitehat ou pesquisadores de segurança enviar problemas de segurança
Sugerimos que você execute simulações de ataques internos regularmente para testar a eficácia e a fraqueza das soluções de segurança de endpoint e detecção de rede existentes, como software antivírus, IPS, IDS e firewalls. A equipe de segurança também pode analisar os recursos existentes de registro e alerta e o tempo de resposta. Esses tipos de ataques simulados dão à equipe de segurança a chance de revisar e otimizar a estrutura de segurança existente.
Detecção e análise
A identificação dos sinais de um incidente de segurança requer a implantação de várias soluções de segurança e sensores de log. As fontes de infecções incluem: IDS / IPS, SIEM, antivírus, monitoramento de integridade de arquivos, logs de sistema operacional / rede e vulnerabilidades públicas e conhecidas.
A implantação de todos os controles de segurança da empresa pode se referir aos controles críticos de segurança do CIS para uma defesa cibernética eficaz (você pode encontrar as informações em https://www.cisecurity.org/controls/). Eles consistem em 20 controles de segurança, definidos em 3 níveis de atuação conforme resumido exibido a seguir.
Quando um caso de incidente de segurança é recebido, a equipe de segurança deve executar uma priorização do incidente de segurança com base no impacto que ele causa.
O Guia de tratamento de incidentes de segurança do NIST SP800-61 sugere quantificar o nível de impacto pelo impacto funcional, o impacto das informações de PII e o esforço de recuperação:
- O impacto funcional significa o impacto nas funções de negócios
- O impacto das informações de PII é a confidencialidade, integridade e disponibilidade (CIA) das informações confidenciais
- O esforço de recuperação refere-se à quantidade de tempo e recursos necessários para recuperar-se do incidente.
Contenção e recuperação
Plano de resposta a incidentes
Algumas práticas de segurança sugeridas a serem executadas na fase de preparação da resposta a incidentes:
- Plano de comunicação do operador de incidentes
- Ferramentas de hardware e software de análise de incidentes
- Diagrama de rede e linhas de base existentes
- Controles de prevenção, como riscos avaliações, segurança do host, segurança de rede, proteção contra malware, conscientização do usuário e treinamento
- O exercício de segurança da equipe azul e vermelha
- Programa de recompensa para hackers da Whitehat ou pesquisadores de segurança enviar problemas de segurança
As atividades de recuperação não incluem apenas a restauração do sistema, mas também a remoção de arquivos comprometidos, a aplicação dos patches mais recentes, a proteção das portas de comunicação, o aumento da complexidade das senhas e a melhoria dos controles de segurança, como configurações de permissões, HIDS/SIDS, SELinux e firewalls.
Em termos de recuperação, o objetivo é restaurar os aplicativos ou hosts infectados de volta à operação normal.
Atividade pós incidente
A efetivação de uma reunião de lições aprendidas ou de um relatório de análise post-mortem pode ajudar a equipe a aprender com o incidente. O objetivo principal da reunião de lições aprendidas é procurar o aprimoramento de cada fase durante o plano de respostas a incidentes de segurança. Esse tipo de reunião geralmente é negligenciado quando o problema de segurança é resolvido. Sugerimos que pelo menos documente o processo do incidente de segurança e o incorpore à base de conhecimento.
Para uma reunião de lições aprendidas, a reunião deve se concentrar em como a equipe pode melhorar juntos e evitar um problema semelhante no futuro, em vez de culpar alguém pelo erro. As entradas da reunião post-mortem geralmente incluem as alterações de controle de segurança propostas, as informações de tratamento de caso e o relatório de análise de causa raiz. Espera-se que a equipe pense em quais ações específicas podem ser feitas para evitar problemas semelhantes. Por exemplo, o treinamento específico sobre conscientização de phishing (fraude) por email pode ser aumentado.
Esses são os resultados potenciais da reunião com o consenso entre as partes interessadas, como as equipes de segurança, TI, desenvolvimento, negócios e jurídico. O relatório de saída post-mortem esperado normalmente inclui certas seções principais, como: o que aconteceu, o impacto, a análise da causa raiz, as atenuações de curto e longo prazo, as atividades que ocorreram durante o cronograma do incidente, o que deve ser aprimorado e o que deve ser mantido.
Aqui está um exemplo de um relatório de saída da reunião post-mortem:
Visão geral do problema
Um dos serviços foi identificado como tendo uma disponibilidade anormal. O processo WebLogic teve um uso de CPU de 100% e o log mostrou uma conexão IP de saída anormal e suspeita.
O que aconteceu e o impacto
Impacto Funcional dos Negócios:
- Alguns dos serviços ficaram mais lentos e não puderam responder às solicitações.
- O processo em execução ocupou 100% dos recursos da CPU.
- Não foram identificados riscos de vazamento de dados.
Análise de causa raiz
- A TI identificou que era o processo WebLogic que frequentemente tinha um uso de CPU acima de 80%.
- Depois que a equipe de segurança verificou os logs de conexão do Linux, foi confirmado que o processo WebLogic tinha uma conexão de saída com hosts externos relacionados ao cryptojacking (cryptojacking refere-se ao uso de hosts comprometidos na mineração de criptomoedas).
- Após pesquisar o banco de dados do CVE pela equipe de segurança, o problema provavelmente estava relacionado ao CVE 2017-3248.
Mitigação e soluções
Curto prazo antes que o patch de segurança esteja pronto: aplique regras de firewall para bloquear o tráfego de comunicação de saída nos servidores de quebra de criptografia e conexões de entrada com o host da vítima.
Longo prazo
- Aplique o patch de segurança WebLogic.
- Atualize os padrões de segurança antivírus.
- Otimize as regras de detecção de intrusão baseadas em host para processos de uso de alta CPU e comportamentos anormais de conexões de saída.
Sua equipe de segurança já está pronta para algum incidente? Comente, mande suas dúvidas nos comentários e conheça nosso treinamento devsecops advanced se desejar levar segurança a todas as suas aplicações!
Newsletter HNZ
Fique por dentro de nossos conteúdos se cadastrando na nossa newsletter semanal! Clique aqui!
