Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se à recomendação da lista de verificação do Azure Well-Architected Framework Security:
| SE:12 | Defina e teste procedimentos eficazes de resposta a incidentes que abrangem um espectro de incidentes, desde problemas localizados até recuperação de desastre. Defina claramente qual equipe 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 houver um comprometimento de segurança para um sistema, uma abordagem sistemática de resposta a incidentes ajuda a reduzir o tempo necessário para identificar, gerenciar e mitigar incidentes de segurança. Esses incidentes podem ameaçar a confidencialidade, a integridade e a disponibilidade de dados e sistemas de software.
A maioria das empresas tem uma equipe de operação de segurança central (também conhecida como SOC (Central de Operações de Segurança) ou SecOps). A responsabilidade da equipe de operação de segurança é detectar, priorizar e triagem rapidamente possíveis ataques. A equipe também monitora dados de telemetria relacionados à segurança e investiga violações de segurança.
No entanto, você também tem a responsabilidade de proteger sua carga de trabalho. É importante que qualquer atividade de comunicação, investigação e busca seja um esforço colaborativo entre a equipe de carga de trabalho e a equipe do SecOps.
Este guia fornece recomendações para você e sua equipe de carga de trabalho para ajudá-lo a detectar, triagem e investigar ataques rapidamente.
Definições
| Prazo | Definition |
|---|---|
| Alerta | Uma notificação que contém informações sobre um incidente. |
| Fidelidade de alerta | A precisão dos dados que determina um alerta. Alertas de alta fidelidade contêm o contexto de segurança necessário para executar ações imediatas. Alertas de baixa fidelidade não têm informações ou contêm ruído. |
| Falso positivo | Um alerta que indica um incidente que não aconteceu. |
| Incidente | Um evento que indica o acesso não autorizado a um sistema. |
| Resposta a incidentes | Um processo que detecta, responde e reduz os riscos associados a um incidente. |
| Triagem | Uma operação de resposta a incidentes que analisa problemas de segurança e prioriza sua mitigação. |
Você e sua equipe executam operações de resposta a incidentes quando há um sinal ou alerta para um possível comprometimento. Alertas de alta fidelidade contêm amplo contexto de segurança que facilita a tomada de decisões dos analistas. Alertas de alta fidelidade resultam em um número baixo de falsos positivos. Este guia pressupõe que um sistema de alertas filtra sinais de baixa fidelidade e se concentra em alertas de alta fidelidade que podem indicar um incidente real.
Designar contatos de notificação de incidentes
Os alertas de segurança precisam alcançar as pessoas apropriadas em sua equipe e em sua organização. Estabeleça um ponto de contato designado em sua equipe de carga de trabalho para receber notificações de incidentes. Essas notificações devem incluir o máximo de informações possível sobre o recurso comprometido e o sistema. O alerta deve incluir as próximas etapas para que sua equipe possa agilizar as ações.
Recomendamos que você faça logon e gerencie ações e notificações de incidentes usando ferramentas especializadas que mantêm uma trilha de auditoria. Usando ferramentas padrão, você pode preservar evidências que podem ser necessárias para possíveis investigações legais. Procure oportunidades para implementar a automação que pode enviar notificações com base nas responsabilidades das partes responsáveis. Mantenha uma cadeia clara de comunicação e relatórios durante um incidente.
Aproveite as soluções de SIEM (gerenciamento de eventos de informações de segurança) e as soluções soar (resposta automatizada) de orquestração de segurança que sua organização fornece. Como alternativa, você pode adquirir ferramentas de gerenciamento de incidentes e incentivar sua organização a padronizar para todas as equipes de carga de trabalho.
Investigar com uma equipe de triagem
O membro da equipe que recebe uma notificação de incidente é responsável por configurar um processo de triagem que envolve as pessoas apropriadas com base nos dados disponíveis. A equipe de triagem, muitas vezes chamada de equipe de ponte, deve concordar com o modo e o processo de comunicação. Esse incidente requer discussões assíncronas ou chamadas de ponte? Como a equipe deve acompanhar e comunicar o andamento das investigações? Onde a equipe pode acessar ativos de incidentes?
A resposta a incidentes é um motivo crucial para manter a documentação atualizada, como o layout arquitetônico do sistema, informações em um nível de componente, classificação de privacidade ou segurança, proprietários e pontos-chave de contato. Se as informações forem imprecisas ou desatualizadas, a equipe da ponte desperdiçará um tempo valioso tentando entender como o sistema funciona, quem é responsável por cada área e qual pode ser o efeito do evento.
Para investigações adicionais, envolva as pessoas apropriadas. Você pode incluir um gerente de incidentes, um oficial de segurança ou clientes potenciais centrados na carga de trabalho. Para manter a triagem focada, exclua as pessoas que estão fora do escopo do problema. Às vezes, equipes separadas investigam o incidente. Pode haver uma equipe que inicialmente investiga o problema e tenta atenuar o incidente, e outra equipe especializada que pode realizar perícia para uma investigação profunda para verificar problemas amplos. Você pode colocar em quarentena o ambiente de carga de trabalho para permitir que a equipe forense faça suas investigações. Em alguns casos, a mesma equipe pode lidar com toda a investigação.
Na fase inicial, a equipe de triagem é responsável por determinar o potencial vetor e seu efeito sobre a confidencialidade, integridade e disponibilidade (também chamada de CIA) do sistema.
Dentro das categorias da CIA, atribua um nível de severidade inicial que indica a profundidade do dano e a urgência da correção. Espera-se que esse nível mude ao longo do tempo à medida que mais informações forem descobertas nos níveis de triagem.
Na fase de descoberta, é importante determinar um curso imediato de planos de ação e comunicação. Há alguma alteração no estado em execução do sistema? Como o ataque pode ser contido para impedir a exploração adicional? A equipe precisa enviar comunicação interna ou externa, como uma divulgação responsável? Considere o tempo de detecção e resposta. Você pode ser legalmente obrigado a relatar alguns tipos de violações a uma autoridade regulatória dentro de um período específico, que geralmente é de horas ou dias.
Se você decidir desligar o sistema, as próximas etapas levarão ao processo de recuperação de desastre (DR) da carga de trabalho.
Se você não desligar o sistema, determine como corrigir o incidente sem afetar a funcionalidade do sistema.
Recuperar-se de um incidente
Trate um incidente de segurança como um desastre. Se a correção exigir recuperação completa, use os mecanismos de recuperação de desastre adequados de uma perspectiva de segurança. O processo de recuperação deve evitar chances de recorrência. Caso contrário, a recuperação de um backup corrompido reintroduzi o problema. Reimplantar um sistema com a mesma vulnerabilidade leva ao mesmo incidente. Valide as etapas e processos de failover e failback.
Se o sistema permanecer funcionando, avalie o efeito nas partes em execução do sistema. Continue monitorando o sistema para garantir que outras metas de confiabilidade e desempenho sejam atendidas ou reajustadas implementando 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 possível correção e fallback sejam identificados. Após o diagnóstico, a equipe trabalha na correção, que identifica e aplica a correção necessária dentro de um período aceitável.
As métricas de recuperação medem quanto tempo leva para corrigir um problema. No caso de um desligamento, pode haver uma urgência em relação aos tempos de correção. Para estabilizar o sistema, leva tempo para aplicar correções, patches e testes e implantar atualizações. Determine estratégias de contenção para evitar danos adicionais e a propagação do incidente. Desenvolva procedimentos de erradicação para remover completamente a ameaça do ambiente.
Compensação: há uma compensação entre os destinos de confiabilidade e os tempos de correção. Durante um incidente, é provável que você não atenda a outros requisitos não funcionais ou não funcionais. Por exemplo, talvez seja necessário desabilitar partes do sistema enquanto investiga o incidente ou talvez seja necessário colocar todo o sistema offline até determinar o escopo do incidente. Os tomadores de decisão empresariais precisam decidir explicitamente quais são os alvos aceitáveis durante o incidente. Especifique claramente a pessoa responsável por essa decisão.
Saiba mais sobre um incidente
Um incidente descobre lacunas ou pontos vulneráveis em um design ou implementação. É uma oportunidade de melhoria que é impulsionada por lições sobre aspectos de design técnico, automação, processos de desenvolvimento de produtos que incluem testes e a eficácia do processo de resposta a incidentes. Mantenha registros detalhados de incidentes, incluindo ações executadas, linhas do tempo e descobertas.
É altamente recomendável que você realize revisões estruturadas pós-incidente, como análise de causa raiz e retrospectivas. Acompanhe e priorize o resultado dessas revisões e considere usar o que você aprende em designs futuros de carga de trabalho.
Os planos de melhoria devem incluir atualizações para análises e testes de segurança, como análises de BCDR (continuidade dos negócios e recuperação de desastre). Use o comprometimento de segurança como um cenário para executar uma análise de BCDR. Os drills podem validar como os processos documentados funcionam. Não deve haver vários guias estratégicos de resposta a incidentes. Use uma única origem que você pode ajustar com base no tamanho do incidente e quão difundido ou localizado o efeito é. Os exercícios são baseados em situações hipotéticas. Realize drills em um ambiente de baixo risco e inclua a fase de aprendizado nos exercícios.
Realize revisões pós-incidente, ou pós-morte, para identificar pontos fracos no processo de resposta e áreas para melhoria. Com base nas lições que você aprende com o incidente, atualize o IRP (plano de resposta a incidentes) e os controles de segurança.
Definir um plano de comunicação
Implemente um plano de comunicação para notificar os usuários sobre uma interrupção e informar os stakeholders internos sobre a correção e as melhorias. Outras pessoas em sua organização precisam ser notificadas sobre quaisquer alterações na linha de base de segurança da carga de trabalho para evitar incidentes futuros.
Gere relatórios de incidentes para uso interno e, se necessário, para conformidade regulatória ou para fins legais. Além disso, adote um relatório de formato padrão (um modelo de documento com seções definidas) que a equipe do SOC usa para todos os incidentes. Verifique se cada incidente tem um relatório associado a ele antes de encerrar a investigação.
Facilitação do Azure
O Microsoft Sentinel é uma solução SIEM e SOAR. É uma solução única para detecção de alertas, visibilidade de ameaças, busca proativa e resposta a ameaças. Para obter mais informações, consulte o que é o Microsoft Sentinel?
Verifique se o portal de registro do Azure inclui informações de contato do administrador para que as operações de segurança possam ser notificadas diretamente por meio de um processo interno. Para obter mais informações, consulte As configurações de notificação de atualização.
Para saber mais sobre como estabelecer um ponto de contato designado que recebe notificações de incidentes do Azure do Microsoft Defender para Nuvem, consulte Configurar notificações por email para alertas de segurança.
Alinhamento organizacional
O Cloud Adoption Framework para Azure fornece diretrizes sobre planejamento de resposta a incidentes e operações de segurança. Para obter mais informações, consulte Operações de segurança.
Links relacionados
- Criar incidentes automaticamente com base em alertas de segurança da Microsoft
- Realizar a busca de ameaças de ponta a ponta usando o recurso de buscas
- Configurar notificações por email para alertas de segurança
- Visão geral da resposta a incidentes
- Preparação para incidentes do Microsoft Azure
- Navegar e investigar incidentes no Microsoft Sentinel
- Controle de segurança: resposta a incidentes
- Soluções SOAR no Microsoft Sentinel
- Treinamento: Introdução à preparação para incidentes do Azure
- Atualizar as configurações de notificação do portal do Azure
- O que é um SOC?
- O que é o Microsoft Sentinel?
Lista de verificação de segurança
Consulte o conjunto completo de recomendações.