Recomendações para resposta a incidentes de segurança

  • Artigo

Aplica-se à recomendação da lista de verificação do Azure Well-Architected Framework Security:

SE:12 Defina e teste procedimentos de resposta a incidentes eficazes que abrangem um espetro de incidentes, desde problemas localizados até recuperação após desastre. Defina claramente que equipa ou indivíduo executa um procedimento.

Este guia descreve as recomendações para implementar uma resposta a incidentes de segurança para uma carga de trabalho. Se existir um compromisso de segurança para um sistema, uma abordagem sistemática de resposta a incidentes ajuda a reduzir o tempo necessário para identificar, gerir e mitigar incidentes de segurança. Estes incidentes podem ameaçar a confidencialidade, integridade e disponibilidade de sistemas e dados de software.

A maioria das empresas tem uma equipa de operação de segurança central (também conhecida como Centro de Operações de Segurança (SOC) ou SecOps). A responsabilidade da equipa de operação de segurança é detetar, priorizar e fazer a triagem rápida de potenciais ataques. A equipa também monitoriza dados telemétricos relacionados com segurança e investiga falhas de segurança.

Arte conceptual que mostra uma abordagem colaborativa para mitigar o potencial e o risco realizado.

No entanto, também tem a responsabilidade de proteger a carga de trabalho. É importante que qualquer comunicação, investigação e atividades de investigação seja um esforço de colaboração entre a equipa de carga de trabalho e a equipa secOps.

Este guia fornece recomendações para si e para a sua equipa de carga de trabalho para o ajudar a detetar, fazer a triagem e investigar ataques rapidamente.

Definições

Termo Definição
Alerta Uma notificação que contém informações sobre um incidente.
Fidelidade do alerta A precisão dos dados que determinam um alerta. Os alertas de alta fidelidade contêm o contexto de segurança necessário para efetuar ações imediatas. Os alertas de baixa fidelidade não têm informações ou contêm dados irrelevantes.
Falso positivo Um alerta que indica um incidente que não aconteceu.
Incidente Um evento que indica acesso não autorizado a um sistema.
Resposta a incidentes Um processo que deteta, responde e mitiga riscos associados a um incidente.
Triagem Uma operação de resposta a incidentes que analisa problemas de segurança e prioriza a mitigação.

Principais estratégias de conceção

O utilizador e a sua equipa realizam operações de resposta a incidentes quando existe um sinal ou alerta para um potencial compromisso. Os alertas de alta fidelidade contêm um amplo contexto de segurança que facilita a tomada de decisões por parte dos analistas. Os alertas de alta fidelidade resultam num número baixo de falsos positivos. Este guia pressupõe que um sistema de alerta filtra sinais de baixa fidelidade e foca-se em alertas de alta fidelidade que podem indicar um incidente real.

Atribuir notificação de incidente

Os alertas de segurança têm de contactar as pessoas adequadas na sua equipa e na sua organização. Estabeleça um ponto de contacto designado na sua equipa de carga de trabalho para receber notificações de incidentes. Estas notificações devem incluir o máximo de informações possível sobre o recurso que está comprometido e o sistema. O alerta tem de incluir os passos seguintes, para que a sua equipa possa agilizar as ações.

Recomendamos que registe e faça a gestão de notificações e ações de incidentes através de ferramentas especializadas que mantêm um registo de auditoria. Ao utilizar ferramentas padrão, pode preservar provas que possam ser necessárias para potenciais investigações legais. Procure oportunidades para implementar a automatização que possa enviar notificações com base nas responsabilidades das partes responsáveis. Mantenha uma cadeia clara de comunicação e relatórios durante um incidente.

Tire partido das soluções de gestão de eventos de informações de segurança (SIEM) e das soluções soar (Security Orchestration Automated Response) fornecidas pela sua organização. Em alternativa, pode obter ferramentas de gestão de incidentes e incentivar a sua organização a uniformizá-las para todas as equipas de cargas de trabalho.

Investigar com uma equipa de triagem

O membro da equipa que recebe uma notificação de incidente é responsável por configurar um processo de triagem que envolve as pessoas adequadas com base nos dados disponíveis. A equipa de triagem, muitas vezes denominada equipa de bridge, tem de concordar com o modo e o processo de comunicação. Este incidente requer discussões assíncronas ou chamadas de ponte? Como deve a equipa controlar e comunicar o progresso das investigações? Onde é que a equipa pode aceder a recursos de incidentes?

A resposta a incidentes é um motivo crucial para manter a documentação atualizada, como o esquema de arquitetura do sistema, informações ao nível do componente, classificação de privacidade ou segurança, proprietários e pontos chave de contacto. Se as informações forem imprecisas ou desatualizadas, a equipa da ponte perde tempo valioso para tentar compreender como funciona o sistema, quem é responsável por cada área e qual poderá ser o efeito do evento.

Para mais investigações, envolva as pessoas apropriadas. Pode incluir um gestor de incidentes, um agente de segurança ou oportunidades potenciais centradas em cargas de trabalho. Para manter a triagem focada, exclua as pessoas que estão fora do âmbito do problema. Por vezes, as equipas separadas investigam o incidente. Pode haver uma equipa que inicialmente investiga o problema e tenta mitigar o incidente, e outra equipa especializada que pode realizar análises forenses para uma investigação aprofundada para apurar problemas amplos. Pode colocar em quarentena o ambiente de carga de trabalho para permitir que a equipa forense faça as investigações. Em alguns casos, a mesma equipa pode processar toda a investigação.

Na fase inicial, a equipa de triagem é responsável por determinar o vetor potencial e o seu efeito na confidencialidade, integridade e disponibilidade (também denominada CIA) do sistema.

Nas categorias da CIA, atribua um nível de gravidade inicial que indique a profundidade dos danos e a urgência da remediação. Espera-se que este nível mude ao longo do tempo à medida que são detetadas mais informações nos níveis de triagem.

Na fase de deteção, é importante determinar um curso imediato de planos de ação e comunicação. Existem alterações ao estado de execução do sistema? Como pode o ataque ser contido para parar a exploração? A equipa precisa de enviar comunicações internas ou externas, como uma divulgação responsável? Considere a deteção e o tempo de resposta. Poderá ser legalmente obrigado a comunicar alguns tipos de violações a uma autoridade reguladora num período de tempo específico, que é frequentemente de horas ou dias.

Se decidir encerrar o sistema, os passos seguintes levam ao processo de recuperação após desastre (DR) da carga de trabalho.

Se não encerrar o sistema, determine como remediar o incidente sem afetar a funcionalidade do sistema.

Recuperar de um incidente

Tratar um incidente de segurança como um desastre. Se a remediação exigir uma recuperação completa, utilize os mecanismos de DR adequados numa perspetiva de segurança. O processo de recuperação tem de impedir possibilidades de periodicidade. Caso contrário, a recuperação de uma cópia de segurança danificada reintroduzi o problema. Reimplementar um sistema com a mesma vulnerabilidade leva ao mesmo incidente. Valide os passos e processos de ativação pós-falha e reativação pós-falha.

Se o sistema continuar a funcionar, avalie o efeito nas partes em execução do sistema. Continue a monitorizar o sistema para garantir que outros destinos de fiabilidade e desempenho são cumpridos ou reajustados através da implementação de processos de degradação adequados. Não comprometa a privacidade devido à mitigação.

O diagnóstico é um processo interativo até que o vetor, e uma correção potencial e contingência, seja identificado. Após o diagnóstico, a equipa trabalha na remediação, que identifica e aplica a correção necessária num período aceitável.

As métricas de recuperação medem o tempo que demora a corrigir um problema. Em caso de encerramento, pode haver uma urgência em relação aos tempos de remediação. Para estabilizar o sistema, demora algum tempo a aplicar correções, patches e testes e a implementar atualizações. Determine estratégias de contenção para evitar mais danos e a propagação do incidente. Desenvolva procedimentos de erradicação para remover completamente a ameaça do ambiente.

Compromisso: existe uma desvantagem entre os destinos de fiabilidade e os tempos de remediação. Durante um incidente, é provável que não cumpra outros requisitos funcionais ou não funcionais. Por exemplo, poderá ter de desativar partes do seu sistema enquanto investiga o incidente ou poderá ter de colocar todo o sistema offline até determinar o âmbito do incidente. Os decisores empresariais têm de decidir explicitamente quais são os destinos aceitáveis durante o incidente. Especifique claramente a pessoa responsável por essa decisão.

Aprender com um incidente

Um incidente deteta lacunas ou pontos vulneráveis numa conceção ou implementação. É uma oportunidade de melhoria que é impulsionada por lições sobre aspetos de design técnico, automatização, processos de desenvolvimento de produtos que incluem testes e a eficácia do processo de resposta a incidentes. Mantenha registos de incidentes detalhados, incluindo ações tomadas, linhas cronológicas e conclusões.

Recomendamos vivamente que realize revisões estruturadas pós-incidente, tais como análises da causa raiz e retrospetivas. Controle e dê prioridade ao resultado dessas revisões e considere utilizar o que aprende em futuras estruturas de cargas de trabalho.

Os planos de melhoria devem incluir atualizações para testes e testes de segurança, como testes de continuidade de negócio e recuperação após desastre (BCDR). Utilize o comprometimento de segurança como cenário para realizar um teste BCDR. Os testes podem validar o funcionamento dos processos documentados. Não devem existir vários manuais de procedimentos de resposta a incidentes. Utilize uma única origem que possa ajustar com base no tamanho do incidente e no quão difundido ou localizado é o efeito. Os exercícios baseiam-se em situações hipotéticas. Realize exercícios num ambiente de baixo risco e inclua a fase de aprendizagem nos exercícios.

Realize revisões pós-incidente, ou postmortems, para identificar fraquezas no processo de resposta e áreas para melhorar. Com base nas lições que aprendeu com o incidente, atualize o plano de resposta a incidentes (IRP) e os controlos de segurança.

Enviar a comunicação necessária

Implemente um plano de comunicação para notificar os utilizadores de uma interrupção e informar os intervenientes internos sobre a remediação e melhorias. As outras pessoas na sua organização têm de ser notificadas de quaisquer alterações à linha de base de segurança da carga de trabalho para evitar futuros incidentes.

Gere relatórios de incidentes para utilização interna e, se necessário, para fins legais ou de conformidade regulamentar. Além disso, adote um relatório de formato padrão (um modelo de documento com secções definidas) que a equipa do SOC utiliza para todos os incidentes. Certifique-se de que todos os incidentes têm um relatório associado antes de fechar a investigação.

Facilitação do Azure

O Microsoft Sentinel é uma solução SIEM e SOAR. É uma solução única para deteção de alertas, visibilidade de ameaças, investigação proativa e resposta a ameaças. Para obter mais informações, consulte O que é o Microsoft Sentinel?

Confirme que o portal de inscrição do Azure inclui informações de contacto do administrador para que as operações de segurança possam ser notificadas diretamente através de um processo interno. Para obter mais informações, veja Atualizar definições de notificação.

Para saber mais sobre como estabelecer um ponto de contacto designado que recebe notificações de incidentes do Azure do Microsoft Defender para a Cloud, veja Configurar notificações por e-mail para alertas de segurança.

Alinhamento organizacional

Cloud Adoption Framework para o Azure fornece orientações sobre o planeamento de resposta a incidentes e operações de segurança. Para obter mais informações, veja Operações de segurança.

Lista de verificação de segurança

Veja o conjunto completo de recomendações.

Lista de verificação de segurança