Compartilhar via

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

  • Artigo

Aplica-se à recomendação da lista de verificação de segurança bem arquitetada: Power Platform

SE:11 Defina e teste procedimentos de resposta a incidentes eficazes que abranjam um espectro de incidentes, desde problemas localizados até recuperação de desastres. Defina claramente qual equipe ou indivíduo executa um procedimento.

Este guia descreve as recomendações para implementação de uma resposta a incidentes de segurança para uma carga de trabalho. Se houver um comprometimento da segurança de um sistema, uma abordagem sistemática de resposta a incidentes vai ajudar 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 sistemas de software e dados.

A maioria das empresas tem uma equipe de operação de segurança central (também conhecida como Centro de operações de segurança [SOC] ou SecOps). A responsabilidade da equipe de operação de segurança é rapidamente detectar, priorizar e fazer a triagem de ataques em potencial. A equipe também monitora dados telemétricos relacionados à segurança e investiga violações de segurança.

Arte conceitual que mostra uma abordagem colaborativa para mitigar um risco em potencial e realizado.

No entanto, você também tem responsabilidade de proteger a carga de trabalho. É importante que toda atividade de comunicação, investigação e busca seja um esforço colaborativo entre a equipe da carga de trabalho e a equipe de SecOps.

Este guia faz recomendações para você e a equipe da carga de trabalho para ajudar rapidamente a detectar, fazer a triagem e investigar ataques.

Definições

Termo Definição
Alerta Uma notificação contendo 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 tomar medidas imediatas. Os 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 acesso não autorizado a um sistema.
Resposta a incidente Um processo que detecta, responde a e mitiga riscos associados a um incidente.
Triagem Uma operação de resposta a incidente que analisa problemas de segurança e prioriza a mitigação.

Estratégias-chave de design

Você e a equipe realizam operações de resposta a incidente quando um sinal ou um alerta indica um incidente de segurança em potencial. Os alertas de alta fidelidade contêm um contexto de segurança amplo que facilita a tomada de decisões por analistas. Alertas de alta fidelidade resultam em um número baixo de falsos positivos. Este guia pressupõe que um sistema de alerta filtre sinais de baixa fidelidade e se concentra em alertas de alta fidelidade capazes de indicar um incidente real.

Atribuir notificação de acidente

Os alertas de segurança precisam alcançar as pessoas indicadas na equipe e na organização. Estabeleça um ponto de contato designado na equipe da carga de trabalho para receber notificações de incidente. Essas notificações devem incluir o máximo de informações possíveis sobre o recurso comprometido e o sistema. O alerta deve incluir as próximas etapas, de maneira que a equipe possa agilizar as ações.

É recomendável registrar e gerenciar notificações e ações de incidente usando ferramentas especializadas que mantenham uma trilha de auditoria. Usando ferramentas padrão, você pode preservar uma evidência que talvez seja necessária para investigações legais em potencial. Procure oportunidades de implementar uma automação capaz de enviar notificações com base nas responsabilidades das partes responsáveis. Mantenha uma cadeia de comunicação clara e relatórios durante um incidente.

Usufrua as soluções de gerenciamento de evento de informações de segurança (SIEM) e as soluções de resposta automatizada da orquestração de segurança (SOAR) oferecidas pela organização. Como alternativa, você pode comprar ferramentas de gerenciamento de incidentes e incentivar a organização a padronizá-las para todas as equipes da 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 indicadas com base nos dados disponíveis. A equipe de triagem, normalmente chamada de equipe ponte, deve concordar com o modo e o processo de comunicação. Esse incidente requer discussões assíncronas ou chamadas ponte? Como a equipe deve rastrear e comunicar o progresso das investigações? Onde a equipe pode acessar ativos de incidente?

A resposta a incidente é um motivo crucial para manter a documentação atualizada, como o layout arquitetônico do sistema, informações em nível de componente, classificação de privacidade ou segurança, proprietários e pontos-chave de contato. Se as informações estiverem imprecisas ou desatualizadas, a equipe ponte perderá um tempo valioso tentando compreender como o sistema funciona, quem é responsável pela área e qual efeito o evento pode ter.

Para investigações adicionais, envolva as pessoas indicadas. Convém incluir um gerente de incidente, um responsável pela segurança ou clientes potenciais centrados na carga de trabalho. Para manter a triagem concentrada, exclua pessoas que estejam fora do escopo do problema. Às vezes, equipes à parte investigam o incidente. É possível que haja uma equipe inicialmente investigando o problema e tentando mitigar o incidente, e outra equipe especializada realizando a perícia de uma investigação aprofundada para determinar problemas amplos. Você pode colocar o ambiente da carga de trabalho em quarentena para permitir que a equipe pericial faça as investigações. Em alguns casos, a mesma equipe pode cuidar de toda a investigação.

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

Dentro das categorias de CIA, atribua um nível de gravidade inicial que indique a profundidade do dano e a urgência da correção. Espera-se que esse nível mude com o passar do tempo, à medida que mais informações forem descobertas nos níveis de triagem.

Na fase de descoberta, é importante determinar uma medida imediata e planos de comunicação. Há alguma alteração no estado de execução do sistema? Como o ataque pode ser contido para impedir novas explorações? A equipe precisa enviar um comunicado interno ou externo, como uma divulgação responsável? Leve em consideração a detecção e o tempo de resposta. É possível que haja a obrigação legal de relatar alguns tipos de violações a uma autoridade reguladora dentro de um período específico, normalmente de horas ou dias.

Se você optar por desligar o sistema, as próximas etapas acarretarão o 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 DR indicados de uma perspectiva de segurança. O processo de recuperação deve evitar probabilidades de recorrência. Do contrário, a recuperação de um backup corrompido reintroduz o problema. A reimplantação de um sistema com a mesma vulnerabilidade acarreta o mesmo incidente. Valide etapas e processos de failover e failback.

Se o sistema continuar funcionando, avalie o efeito sobre as partes em execução do sistema. Continue monitorando o sistema para garantir que outras metas de confiabilidade e desempenho sejam atingidas ou reajustadas por meio da implementação dos processos de degradação indicados. Não comprometa a privacidade por causa da mitigação.

O diagnóstico será um processo interativo até o vetor, e uma possível correção e fallback, ser identificado. 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 demora para corrigir um problema. Em caso de desligamento, é possível que haja uma urgência referente aos tempos de correção. Para estabilizar o sistema, é preciso tempo para aplicar correções, patches e testes, além de implantar atualizações. Determine estratégias de contenção para evitar ainda mais danos e o espalhamento do incidente. Desenvolva procedimentos de erradicação para remover por completo a ameaça do ambiente.

Tradeoff: There é um tradeoff entre metas de confiabilidade e tempos de correção. Durante um incidente, é provável que você não atenda a outros requisitos não funcionais ou funcionais. Por exemplo, talvez seja necessário desabilitar partes do sistema enquanto você investiga o incidente ou até mesmo deixar todo o sistema offline até determinar o escopo do incidente. Os tomadores de decisão de negócios precisam decidir explicitamente quais são as metas aceitáveis durante o incidente. Especifique claramente a pessoa responsável por essa decisão.

Aprender com um incidente

Um incidente revela lacunas ou pontos vulneráveis em um design ou em uma implementação. Trata-se de uma oportunidade de melhoria impulsionada por lições em aspectos técnicos de design, automação, processos de desenvolvimento de produtos dentre os quais estão testes e a eficácia do processo de resposta a incidentes. Mantenha registros de incidente detalhados, inclusive ações tomadas, linhas do tempo e descobertas.

É altamente recomendável realizar revisões pós-incidente estruturadas, como análise de causa raiz e retrospectivas. Acompanhe e priorize o resultado dessas revisões e leve em consideração o uso do que você aprendeu em designs de carga de trabalho futuros.

Os planos de melhoria devem incluir atualizações feitas em análises de segurança e testes, como os análises de continuidade dos negócios e recuperação de desastres (BCDR). Use o comprometimento da segurança como um cenário para realizar uma análise de BCDR. As análises podem validar como os processos documentados funcionam. Não deve haver vários guias estratégicos de resposta a incidentes. Use uma única fonte que você possa ajustar com base no tamanho do incidente e na amplitude ou na localização do efeito. As análises se baseiam em situações hipotéticas. Realize análises em um ambiente de baixo risco e inclua a fase de aprendizado nas análises.

Realize análises pós-incidente, ou post-mortems, para identificar pontos fracos no processo de resposta e áreas de melhoria. Com base nas lições aprendidas com o incidente, atualize o plano de resposta a incidentes (IRP) e os controles de segurança.

Enviar a comunicação necessária

Implemente um plano de comunicação para notificar usuários de uma interrupção e informar stakeholders internos sobre a correção e as melhorias. Outras pessoas na organização precisam ser notificadas de eventuais alterações feitas na linha de base de segurança da carga de trabalho para evitar incidentes futuros.

Gere relatórios de incidente para uso interno e, se necessário, para fins legais ou de conformidade regulatória. Além disso, adote um relatório de formato padrão (um modelo de documento com seções definidas) usado pela equipe SOC em todos os incidentes. Verifique se todo incidente tem um relatório associado antes de encerrar a investigação.

Facilitação do Power Platform

As seções a seguir descrevem os mecanismos que você pode empregar como parte dos procedimentos de resposta a incidentes de segurança.

Microsoft Sentinela

Microsoft A solução Sentinel permite que os clientes detectem diversas atividades suspeitas, incluindo: Microsoft Power Platform

  • Execução do Power Apps em geografias não autorizadas
  • Destruição de dados suspeitos por Power Apps
  • Exclusão em massa do Power Apps
  • Ataques de phishing feitos por meio do Power Apps
  • Atividade de fluxos do Power Automate por funcionários de saída
  • Conectores do Microsoft Power Platform adicionados a um ambiente
  • Atualização ou remoção das políticas de prevenção contra perdas de dados do Microsoft Power Platform

Para obter mais informações, consulte Microsoft Visão geral da solução Sentinel Microsoft Power Platform .

Microsoft Registro de atividades do Purview

Power Apps, Power Automate, Conectores, Dados prevenção contra perdas e Power Platform registro de atividades administrativas são rastreados e visualizados no Microsoft portal de conformidade do Purview.

Para obter mais informações, consulte:

Sistema de Proteção de Dados do Cliente

A maioria das operações, suporte e solução de problemas realizados por pessoal (incluindo subprocessadores) não exigem acesso aos dados do cliente. Microsoft Com o Power Platform Customer Lockbox, Microsoft fornece uma interface para os clientes revisarem e aprovarem (ou rejeitarem) solicitações de acesso a dados nas raras ocasiões em que o acesso aos dados do cliente é necessário. Ele é usado em casos em que um Microsoft engenheiro precisa acessar dados do cliente, seja em resposta para um tíquete de suporte iniciado pelo cliente ou um problema identificado por Microsoft. Para obter mais informações, consulte Acessar com segurança os dados do cliente usando o Sistema de Proteção de Dados do Cliente no Power Platform e no Dynamics 365.

Atualizações de segurança

As equipes do Service realizam regularmente o seguinte para garantir a segurança do sistema:

  • Verificações do serviço para identificar possíveis vulnerabilidades de segurança.
  • Avaliações do serviço para garantir que os controles-chave de segurança estejam funcionando efetivamente.
  • Avaliações do serviço para determinar a exposição a quaisquer vulnerabilidades identificadas pelo Security resposta Center (MSRC), que monitora regularmente sites externos de conscientização sobre vulnerabilidades. Microsoft

Essas equipes também identificam e rastreiam todos os problemas identificados, além de agir rapidamente para atenuar riscos quando necessário.

Como posso saber sobre atualizações de segurança?

Como as equipes do Service se esforçam para aplicar mitigações de risco de maneira que não exija tempo de inatividade do serviço, os administradores normalmente não veem notificações do Centro de Mensagens para atualizações de segurança. Se a atualização de segurança afetar o serviço, ela será considerada uma manutenção planejada e será publicada com a duração do impacto estimado e a janela quando o trabalho vai ocorrer.

Para obter mais informações sobre segurança, consulte Microsoft Central de Confiabilidade.

Gerenciar sua janela de manutenção

Microsoft realiza atualizações regularmente e manutenção para garantir segurança, desempenho, disponibilidade e fornecer novos recursos e funcionalidades. Esse processo de atualização oferece semanalmente melhorias secundárias em segurança e serviço, com cada atualização implementada região por região de acordo com uma agenda de implantação segura, organizado em Estações. Para obter informações sobre sua janela de manutenção padrão para ambientes, consulte Políticas e Comunicações para incidentes de serviço. Consulte também Gerenciar a janela de manutenção.

Verifique se o portal de inscrição do Azure inclui informações de contato do administrador, de maneira que as operações de segurança possam ser notificadas diretamente por meio de um processo interno. Para obter mais informações, consulte Atualizar configurações de notificação.

Alinhamento organizacional

O Cloud Adoption Framework para Azure dá diretrizes sobre planejamento de resposta a incidentes e operações de segurança. Para obter mais informações, consulte Operações de segurança.

Lista de verificação de segurança

Consulte o conjunto completo de recomendações.

Lista de verificação de segurança