# Resposta a incidentes
Mesmo com controles preventivos e de detecção consolidados, sua organização deve implementar mecanismos para responder e atenuar o impacto potencial de incidentes de segurança. Sua preparação afeta muito a capacidade das equipes operarem efetivamente durante um incidente, isolarem, conterem e analisarem problemas e restaurarem as operações para um estado adequado conhecido. Implementar as ferramentas e o acesso antes de um incidente de segurança e praticar rotineiramente game days para validar a resposta a incidentes ajudam a garantir que você possa se recuperar enquanto minimiza interrupções empresariais.
**Topics**
+ [Aspectos da resposta a incidentes da AWS](aspects-of-aws-incident-response.md)
+ [Elaborar metas da resposta da nuvem](design-goals-of-cloud-response.md)
+ [Preparação](preparation.md)
+ [Operações](operations.md)
+ [Atividade pós-incidente](post-incident-activity.md)
# Aspectos da resposta a incidentes da AWS
Todos os usuários da AWS de uma organização devem ter uma compreensão básica dos processos de resposta a incidentes de segurança, e a equipe de segurança deve entender como responder aos problemas de segurança. Educação, treinamento e experiência são essenciais para um programa bem-sucedido de resposta a incidentes na nuvem e são preferencialmente implementados bem antes de precisar lidar com um possível incidente de segurança. A base de um programa bem-sucedido de resposta a incidentes na nuvem consiste em *Preparação*, *Operações* e *Atividade pós-incidente*.
Para entender cada um desses aspectos, considere as seguintes descrições:
+ **Preparação**: prepare sua equipe de resposta a incidentes para detectar e responder aos incidentes na AWS ativando controles de detecção e verificando o acesso adequado às ferramentas e aos serviços de nuvem necessários. Além disso, prepare os playbooks necessários, tanto os automatizados quanto os manuais, para garantir respostas confiáveis e consistentes.
+ **Operações**: opere em eventos de segurança e possíveis incidentes seguindo as fases de resposta a incidentes do NIST: detectar, analisar, conter, erradicar e recuperar.
+ **Atividade pós-incidente**: itere o resultado de seus eventos e simulações de segurança para melhorar a eficácia da resposta, aumentar o valor derivado da resposta e da investigação e reduzir ainda mais os riscos. Você precisa aprender com os incidentes e ter uma propriedade consistente das atividades de melhoria.
O diagrama a seguir mostra o fluxo desses aspectos, alinhando-se ao ciclo de vida de resposta a incidentes do NIST mencionado anteriormente, mas com operações que abrangem detecção e análise com contenção, erradicação e recuperação.
![\[Diagrama que exibe o ciclo das operações de resposta a incidentes da AWS.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/security-pillar/images/aws-incident-response.png)
# Elaborar metas da resposta da nuvem
Embora os processos e os mecanismos gerais de resposta a incidentes, como os definidos no [NIST SP 800-61 Guia de tratamento de incidentes de computadores](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final), permaneçam válidos, recomendamos que você avalie os objetivos específicos desse projeto que são relevantes para responder a incidentes de segurança em um ambiente de nuvem:
+ **Estabeleça objetivos de resposta:** trabalhe com as partes interessadas, a assessoria jurídica e a liderança organizacional para determinar a meta da resposta a um incidente. Algumas metas comuns são: conter e atenuar o problema, recuperar os recursos afetados, preservar dados para análise forense, retornar às operações seguras conhecidas e, finalmente, aprender com os incidentes.
+ **Responda usando a nuvem:** implemente padrões de resposta na nuvem, onde o evento e os dados ocorrem.
+ **Saiba o que você tem e o que precisa:** preserve logs, recursos, instantâneos e outras evidências copiando e armazenando-os em uma conta centralizada na nuvem dedicada à resposta. Use tags, metadados e mecanismos que impõem políticas de retenção. Você precisará entender quais serviços são usados e identificar os requisitos para investigar esses serviços. Para ajudar você a entender seu ambiente, você também pode usar marcação com tags.
+ **Use mecanismos de reimplantação:** se um problema de segurança puder ser atribuído a uma configuração incorreta, a correção poderá ser tão simples quanto a remoção da variação com a reimplantação dos recursos com a configuração apropriada. Se um possível comprometimento for identificado, verifique se sua redistribuição inclui a atenuação bem-sucedida e verificada das causas principais.
+ **Automatize sempre que possível:** à medida que problemas surgem ou incidentes se repetem, crie mecanismos para fazer a triagem programática e responder a eventos comuns. Use respostas humanas para incidentes exclusivos, complexos ou confidenciais em que as automações são insuficientes.
+ **Escolha soluções escaláveis:** esforce-se para combinar a escalabilidade da abordagem de sua organização com a computação em nuvem. Implemente mecanismos de detecção e resposta que se expandam em seus ambientes para reduzir efetivamente o tempo entre a detecção e a resposta.
+ **Aprenda e aprimore seu processo:** seja proativo na identificação de lacunas em seus processos, ferramentas ou pessoas e implemente um plano para corrigi-las. Simulações são métodos seguros para encontrar lacunas e melhorar processos.
Essas metas de design são um lembrete para analisar a implementação de sua arquitetura quanto à capacidade de conduzir tanto a resposta a incidentes quanto a detecção de ameaças. Ao planejar suas implementações de nuvem, pense em responder a um incidente, de preferência, com uma metodologia de resposta sólida em termos forenses. Em alguns casos, isso significa que você pode ter várias organizações, contas e ferramentas configuradas especificamente para essas tarefas de resposta. Essas ferramentas e funções devem ser disponibilizadas para a equipe de atendimento a incidentes por meio do pipeline de implantação. Elas não devem ser estáticas, pois podem causar um risco maior.
# Preparação
A preparação para um incidente é fundamental para uma resposta oportuna e eficaz a incidentes. A preparação é feita em três domínios:
+ **Pessoas**: preparar seu pessoal para um incidente de segurança envolve identificar as partes interessadas relevantes para a resposta a incidentes e treiná-las em resposta a incidentes e tecnologias de nuvem.
+ **Processos**: preparar seus processos para um incidente de segurança envolve documentar arquiteturas, desenvolver planos completos de resposta a incidentes e criar playbooks para uma resposta consistente a eventos de segurança.
+ **Tecnologia**: preparar sua tecnologia para um incidente de segurança envolve configurar o acesso, agregar e monitorar os logs necessários, implementar mecanismos de alerta eficazes e desenvolver recursos de resposta e investigação.
Cada um desses domínios é igualmente importante para uma resposta eficaz a incidentes. Nenhum programa de resposta a incidentes é completo ou eficaz sem os três. Você precisará preparar pessoas, processos e tecnologias com uma forte integração para se preparar para um incidente.
**Topics**
+ [SEC10-BP01 Identificar equipes e recursos externos fundamentais](sec_incident_response_identify_personnel.md)
+ [SEC10-BP02 Desenvolver planos de gerenciamento de incidentes](sec_incident_response_develop_management_plans.md)
+ [SEC10-BP03 Preparar recursos forenses](sec_incident_response_prepare_forensic.md)
+ [SEC10-BP04 Desenvolver e testar playbooks de resposta a incidentes de segurança](sec_incident_response_playbooks.md)
+ [SEC10-BP05 Provisionar acesso previamente](sec_incident_response_pre_provision_access.md)
+ [SEC10-BP06 Implantar ferramentas previamente](sec_incident_response_pre_deploy_tools.md)
+ [SEC10-BP07 Executar simulações](sec_incident_response_run_game_days.md)
# SEC10-BP01 Identificar equipes e recursos externos fundamentais
Identifique as equipes, as obrigações legais e os recursos internos e externos que ajudam sua organização a responder a um incidente.
**Resultado desejado:** você tem uma lista dos principais funcionários, suas informações de contato e as funções que eles desempenham ao responder a um evento de segurança. Você revisa essas informações regularmente e as atualiza para refletir mudanças de equipes do ponto de vista das ferramentas internas e externas. Você considera todos os provedores de serviços e fornecedores terceirizados ao documentar essas informações, incluindo parceiros de segurança, provedores de nuvem e aplicações de software como serviço (SaaS). Durante um evento de segurança, as equipes estão preparadas com o nível apropriado de responsabilidade, contexto e acesso para resposta e recuperação.
**Práticas comuns que devem ser evitadas:**
+ Não manter uma lista atualizada das principais equipes com informações de contato, funções e responsabilidades para responder a eventos de segurança.
+ Supor que todos saibam quais são as pessoas, as dependências, a infraestrutura e as soluções necessárias para resposta a um evento e recuperação.
+ Não ter um documento ou repositório de conhecimentos que represente a infraestrutura principal ou o design da aplicação.
+ Não ter processos de integração adequados para que novos funcionários contribuam eficazmente para uma resposta a eventos de segurança, como a realização de simulações de eventos.
+ Não ter um caminho de encaminhamento estabelecido quando as equipes principais estão temporariamente indisponíveis ou não respondem durante eventos de segurança.
**Benefícios de implementar esta prática recomendada:** essa prática reduz a triagem e o tempo de resposta gastos na identificação do pessoal certo e de seus perfis durante um evento. Minimize o tempo perdido durante um evento mantendo uma lista atualizada das principais equipes e de suas funções para que você possa convocar as pessoas certas para a triagem e se recuperar de um evento.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
**Identifique o pessoal-chave em sua organização:** mantenha uma lista de contatos do pessoal de sua organização que você precisa envolver. Revise e atualize regularmente essas informações em caso de movimentação de equipes, como mudanças organizacionais, promoções e mudanças de equipe. Isso é especialmente importante para funções importantes, como gerentes de incidentes, respondedores a incidentes e líderes de comunicação.
+ **Gerente de incidentes:** os gerentes de incidentes têm autoridade geral durante a resposta ao evento.
+ **Respondedores a incidentes:** os respondedores a incidentes são responsáveis pelas atividades de investigação e correção. Essas pessoas podem diferir com base no tipo de evento, mas normalmente são desenvolvedores e equipes operacionais responsáveis pela aplicação afetada.
+ **Líder de comunicação:** o líder de comunicação é responsável pelas comunicações internas e externas, especialmente com órgãos públicos e reguladores e clientes.
+ **Processo de integração:** treine e integre regularmente novos funcionários para equipá-los com as habilidades e conhecimentos necessários para contribuir de forma eficaz com os esforços de resposta a incidentes. Incorpore simulações e exercícios práticos como parte do processo de integração para facilitar sua preparação
+ **Especialistas no assunto (SME):** no caso de equipes distribuídas e autônomas, recomendamos que você identifique um SME para workloads de missão crítica. Eles oferecem insights sobre a operação e a classificação de dados das workloads críticas envolvidas no evento.
Formato de tabela de exemplo:
```
| Role | Name | Contact Information | Responsibilities |
1 | ——– | ——- | ——- | ——- |
2 | Incident Manager | Jane Doe| jane.doe@example.com | Overall authority during response |
3 | Incident Responder | John Smith | john.smith@example.com | Investigation and remediation |
4 | Communications Lead | Emily Johnson | emily.johnson@example.com | Internal and external communications |
5 | Communications Lead | Michael Brown | michael.brown@example.com | Insights on critical workloads |
```
Considere usar o recurso [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) para capturar os principais contatos, definir um plano de resposta, automatizar cronogramas de plantão e criar planos de escalação. Automatize e faça a rotação de toda a equipe por meio de um cronograma de plantão para que a responsabilidade pela workload seja compartilhada entre os respectivos responsáveis. Isso favorece boas práticas, como emitir métricas e logs relevantes e definir limites de alarme importantes para a workload.
**Identifique parceiros externos:** as empresas usam ferramentas criadas por provedores de software independentes (ISVs), parceiros e subcontratados para criar soluções diferenciadas para seus clientes. Envolva as principais equipes dessas partes que possam ajudar na resposta e recuperação de um incidente. Recomendamos se inscrever no nível apropriado do Suporte para obter acesso imediato a especialistas da AWS por meio de um caso de suporte. Considere acordos semelhantes com todos os provedores de soluções essenciais para as workloads. Alguns eventos de segurança exigem que as empresas de capital aberto notifiquem os órgãos públicos e reguladores relevantes sobre o evento e os impactos. Mantenha e atualize as informações de contato dos departamentos relevantes e das pessoas responsáveis.
## Etapas de implementação
1. Configure uma solução de gerenciamento de incidentes.
1. Considere implantar o Incident Manager em sua conta de ferramentas de segurança.
1. Defina contatos em sua solução de gerenciamento de incidentes.
1. Defina pelo menos dois tipos de canal de contato para cada contato (como SMS, telefone ou e-mail) para garantir a acessibilidade durante um incidente.
1. Defina um plano de resposta.
1. Identifique os contatos mais adequados a serem mobilizados durante um incidente. Defina planos de encaminhamento alinhados às funções das equipes a serem mobilizadas, em vez de contatos individuais. Considere incluir contatos que possam ter a responsabilidade de informar entidades externas, mesmo que eles não sejam diretamente mobilizados para resolver o incidente.
## Recursos
**Práticas recomendadas relacionadas:**
+ [OPS02-BP03 Atividades de operações com proprietários identificados responsáveis pela performance](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_ops_model_def_activity_owners.html)
**Documentos relacionados:**
+ [AWS Guia de resposta a incidentes de segurança da](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
**Exemplos relacionados:**
+ [AWS Framework do playbook do cliente da](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [Como se preparar e responder a incidentes de segurança no ambiente da AWS](https://youtu.be/8uiO0Z5meCs)
**Ferramentas relacionadas:**
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
**Vídeos relacionados:**
+ [A abordagem da Amazon à segurança durante o desenvolvimento](https:/www.youtube.com/watch?v=NeR7FhHqDGQ)
# SEC10-BP02 Desenvolver planos de gerenciamento de incidentes
O primeiro documento a ser desenvolvido para resposta a incidentes é o plano de resposta a incidentes. O plano de resposta a incidentes foi projetado para ser a base de seu programa e estratégia de resposta a incidentes.
**Benefícios de implementar esta prática recomendada:** o desenvolvimento de processos de resposta a incidentes completos e claramente definidos é fundamental para um programa de resposta a incidentes bem-sucedido e escalável. Quando um evento de segurança ocorre, etapas e fluxos de trabalho claros poderão ajudar você a responder em tempo hábil. Talvez você já tenha processos de resposta a incidentes existentes. Independentemente do seu estado atual, é importante atualizar, repetir e testar seus processos de resposta a incidentes regularmente.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Um plano de gerenciamento de incidentes é fundamental para responder, mitigar e se recuperar de possíveis impactos de incidentes de segurança. Um plano de gerenciamento de incidentes é um processo estruturado de identificação, correção e resposta em tempo hábil a incidentes de segurança.
A nuvem tem muitos dos mesmos requisitos e perfis operacionais encontrados em um ambiente on-premises. Ao criar um plano de gerenciamento de incidentes, é importante definir estratégias de resposta e recuperação que se alinhem melhor aos seus resultados empresariais e requisitos de conformidade. Por exemplo, se você opera workloads na AWS em conformidade com o FedRAMP dos Estados Unidos, siga as recomendações em [NIST SP 800-61 Computer Security Handling Guide](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf). Da mesma forma, ao operar workloads que armazenam informações de identificação pessoal (PII), considere como se proteger e responder a incidentes relacionados ao uso e à residência de dados.
Ao criar um plano de gerenciamento de incidentes para suas workloads na AWS, comece com o [Modelo de responsabilidade compartilhada da AWS](https://aws.amazon.com/compliance/shared-responsibility-model/) para criar uma abordagem de defesa aprofundada para a resposta a incidentes. Nesse modelo, a AWS gerencia a segurança da nuvem, e você é responsável pela segurança na nuvem. Isso significa que você mantém o controle e é responsável pelos controles de segurança que escolhe implementar. O [Guia de resposta a incidentes de segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) detalha os conceitos e as orientações básicas para criar um plano de gerenciamento de incidentes centrado na nuvem.
Um plano de gerenciamento de incidentes eficaz deve ser continuamente trabalhado e permanecer atualizado com relação às suas metas de operações na nuvem. Considere o uso dos planos de implementação detalhados abaixo à medida que cria e evolui seu plano de gerenciamento de incidentes.
### Etapas de implementação
1. Defina funções e responsabilidades em sua organização para lidar com eventos de segurança. Isso deve envolver representantes de vários departamentos, incluindo:
+ Recursos humanos (RH)
+ Equipe executiva
+ Departamento jurídico
+ Proprietários e desenvolvedores de aplicações (especialistas no assunto, ou SMEs)
1. Descreva claramente quem é responsável, consultado e informado (RACI) durante um incidente. Crie um gráfico RACI para facilitar a comunicação rápida e direta e descreva claramente a liderança em diferentes estágios de um evento.
1. Envolva proprietários e desenvolvedores de aplicações (SMEs) durante um incidente, pois eles podem fornecer informações e contexto valiosos para ajudar a medir o impacto. Desenvolva relacionamentos com esses SMEs e pratique cenários de resposta a incidentes com eles antes que um incidente real ocorra.
1. Envolva parceiros confiáveis ou especialistas externos no processo de investigação ou resposta, pois eles podem oferecer experiência e perspectiva adicionais.
1. Alinhe seus planos e funções de gerenciamento de incidentes com quaisquer regulamentações locais ou requisitos de conformidade que regem sua organização.
1. Pratique e teste seus planos de resposta a incidentes regularmente e envolva todas as funções e responsabilidades definidas. Isso ajuda a agilizar o processo e a verificar se você tem uma resposta coordenada e eficiente aos incidentes de segurança.
1. Revise e atualize as funções, responsabilidades e o gráfico RACI periodicamente ou à medida que sua estrutura organizacional ou requisitos mudarem.
**Compreensão das equipes de resposta da AWS e do suporte fornecido**
+ **AWS Support**
+ [Suporte](https://aws.amazon.com/premiumsupport/) O AWS oferece uma variedade de planos que permitem conceder acesso a ferramentas e conhecimentos que oferecem suporte ao sucesso e à integridade operacional das soluções da . Se precisar de suporte técnico e mais recursos para ajudar a planejar, implantar e otimizar seu ambiente da AWS, selecione um plano de suporte mais adequado ao seu caso de uso da AWS.
+ Considere o [Support Center](https://console.aws.amazon.com/support) no Console de gerenciamento da AWS (é necessário iniciar sessão) como ponto central de contato para obter suporte para problemas que afetam seus recursos da AWS. O acesso ao Suporte é controlado pelo AWS Identity and Access Management. Para mais informações sobre como obter acesso aos recursos da Suporte, consulte [Conceitos básicos do Suporte](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support).
+ **AWS Equipe de Resposta a Incidentes de Clientes (CIRT) da)**
+ A Equipe de Resposta a Incidentes de Clientes (CIRT) da AWS é uma equipe global da AWS especializada que está disponível 24 horas por dia, 7 dias por semana, para prestar assistência aos clientes durante eventos de segurança ativos no lado do cliente do [Modelo de responsabilidade compartilhada da AWS](https://aws.amazon.com/compliance/shared-responsibility-model/).
+ Ao apoiar você, a CIRT da AWS presta assistência na triagem e na recuperação de um evento de segurança ativo na AWS. A equipe pode ajudar na análise da causa-raiz por meio do uso de logs de serviço da AWS e fornecer recomendações para recuperação. Ela também podem fornecer recomendações de segurança e práticas recomendadas para ajudar você a evitar eventos de segurança no futuro.
+ Os clientes da AWS podem solicita a ajuda da CIRT da AWS por meio de um [caso do Suporte](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)
+ [https://aws.amazon.com/security-incident-response/](https://aws.amazon.com/security-incident-response/)
+ Anunciado no re:Invent 2024, o AWS Security Incident Response é um serviço gerenciado de resposta a incidentes de segurança que usa tecnologia moderna de triagem e human-in-the-loop. O serviço ingere todas as descobertas do GuardDuty e descobertas de terceiros enviadas ao AWS Security Hub CSPM para triagem a fim de alertar o cliente somente sobre descobertas que exijam investigação. O serviço também oferece um portal para o cliente enviar casos reativos se perceber a ocorrência de um evento de segurança e receber suporte da equipe avançada de resposta a incidentes da AWS.
+ **Suporte de resposta a DDoS**
+ A AWS oferece o [AWS Shield](https://aws.amazon.com/shield/), que fornece um serviço gerenciado de proteção contra negação de serviço distribuída (DDoS) para proteger aplicações Web executadas na AWS. O Shield fornece detecção permanente e mitigações automáticas em linha que podem minimizar o tempo de inatividade e a latência das aplicações para que não seja necessário envolver o Suporte para usufruir da proteção contra DDoS. O Shield possui dois níveis: AWS Shield Standard e AWS Shield Advanced. Para saber mais sobre as diferenças entre esses dois níveis, consulte a [Documentação de recursos do Shield](https://aws.amazon.com/shield/features/).
+ **AWS Managed Services (AMS)**
+ O [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) oferece gerenciamento contínuo de sua infraestrutura da AWS para que você possa se concentrar em suas aplicações. Ao implementar práticas recomendadas para manter sua infraestrutura, o AMS ajuda a reduzir a sobrecarga e os riscos operacionais. O AMS automatiza atividades comuns, como solicitações de alteração, monitoramento, gerenciamento de patches, segurança e serviços de backup, além de disponibilizar serviços de ciclo de vida total para provisionar, executar e apoiar a sua infraestrutura.
+ O AMS assume a responsabilidade de implantar um pacote de controles de detecção de segurança e fornece uma primeira linha de resposta aos alertas 24 horas por dia, 7 dias por semana. Quando um alerta é iniciado, o AMS segue um conjunto padrão de guias e playbooks automatizados para verificar uma resposta consistente. Esses playbooks são compartilhados com os clientes do AMS durante a integração para que eles possam desenvolver e coordenar uma resposta com o AMS.
**Desenvolva o plano de resposta a incidentes**
O plano de resposta a incidentes foi projetado para ser a base de seu programa e estratégia de resposta a incidentes. O plano de resposta a incidentes deve estar em um documento formal. Um plano de resposta a incidentes geralmente inclui as seguintes seções:
+ **Visão geral da equipe de resposta a incidentes:** descreve as metas e funções da equipe de resposta a incidentes.
+ **Papéis e responsabilidades:** lista as partes interessadas na resposta a incidentes e detalha seus papéis quando um incidente ocorre.
+ **Plano de comunicação:** detalha as informações de contato e como você se comunica durante um incidente.
+ **Métodos de comunicação de backup:** é prática recomendada ter comunicação fora de banda como backup para a comunicação de incidentes. Um exemplo de aplicação que fornece um canal seguro de comunicação fora de banda é AWS Wickr.
+ **Fases da resposta a incidentes e ações necessárias:** enumera as fases da resposta a incidentes (por exemplo, detectar, analisar, erradicar, conter e recuperar), incluindo ações de alto nível a serem realizadas nessas fases.
+ **Definições de severidade e priorização de incidentes:** detalha como classificar a severidade de um incidente, como priorizar o incidente e, depois, como as definições de severidade afetam os procedimentos de escalação.
Embora essas seções sejam comuns em empresas de diferentes tamanhos e setores, o plano de resposta a incidentes de cada organização é único. Você precisa criar um plano de resposta a incidentes que funcione melhor para a organização.
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC04 Detecção](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**Documentos relacionados:**
+ [Guia de resposta a incidentes de segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [ NIST: Guia de tratamento de incidentes de segurança de computadores ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)
# SEC10-BP03 Preparar recursos forenses
Antes de um incidente de segurança, considere o desenvolvimento de recursos forenses para contribuir com as investigações de eventos de segurança.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
Os conceitos da análise forense on-premises tradicional se aplicam à AWS. Para obter informações importantes para começar a desenvolver recursos forenses na Nuvem AWS, consulte [Estratégias do ambiente de investigação forense na Nuvem AWS](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/).
Depois de configurar o ambiente e a estrutura da Conta da AWS para análise forense, defina as tecnologias necessárias para executar com eficácia metodologias forenses sólidas nas quatro fases:
+ **Coleta:** colete logs relevantes da AWS, como do AWS CloudTrail, do AWS Config, logs de fluxo de VPC e logs em nível de host. Colete snapshots, backups e despejos de memória dos recursos afetados da AWS, quando disponíveis.
+ **Exame:** examine os dados coletados extraindo e avaliando as informações relevantes.
+ **Análise:** analise os dados coletados para entender o incidente e tirar conclusões do ocorrido.
+ **Relatório:** apresente as informações resultantes da fase de análise.
## Etapas de implementação
**Prepare o ambiente forense**
O [AWS Organizations](https://aws.amazon.com/organizations/) ajuda a gerenciar e reger centralmente um ambiente da AWS à medida que você expande e escala os recursos da AWS. Uma organização da AWS consolida suas Contas da AWS para que você possa administrá-las como uma única unidade. Você pode usar unidades organizacionais (UOs) para agrupar contas e administrá-las como uma unidade única.
Para resposta a incidentes, é útil ter uma estrutura da Conta da AWS compatível com as funções de resposta a incidentes, que inclui uma *UO de segurança* e uma *UO forense*. Dentro da OU de segurança, é necessário ter contas para:
+ **Arquivamento de logs:** agregue logs em uma Conta da AWS de arquivamento de logs com permissões limitadas.
+ **Ferramentas de segurança:** centralize os serviços de segurança em uma Conta da AWS de ferramentas de segurança. Essa conta opera como administrador delegado dos serviços de segurança.
Dentro da UO forense, você tem a opção de implementar uma única conta ou contas forenses para cada região em que opera, dependendo da que funciona melhor para sua empresa e modelo operacional. Se você criar uma conta forense por região, poderá bloquear a criação de recursos da AWS fora dessa região e reduzir o risco de os recursos serem copiados para uma região não pretendida. Por exemplo, se você operasse apenas na região Leste dos EUA (Norte da Virgínia) (`us-east-1`) e Oeste dos EUA (Oregon) (`us-west-2`), você teria duas contas na UO forense: uma para `us-east-1` e outra para `us-west-2`.
É possível criar uma Conta da AWS de análise forense para várias regiões. Você deve ter cuidado ao copiar recursos da AWS para essa conta para verificar se está de acordo com seus requisitos de soberania de dados. Como é preciso tempo para provisionar novas contas, é imperativo criar e instrumentar as contas forenses bem antes de um incidente, para que os respondentes possam estar preparados para usá-las de forma eficaz em suas respostas.
O diagrama a seguir exibe um exemplo de estrutura de contas, incluindo uma UO forense com contas forenses por região:
![\[Diagrama de fluxo mostrando uma estrutura de contas por região para resposta a incidentes, bifurcada em uma UO forense e de segurança.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/security-pillar/images/region-account-structure.png)
**Capture backups e snapshots**
Configurar backups dos principais sistemas e bancos de dados é essencial para a recuperação de um incidente de segurança e para fins forenses. Com os backups em vigor, você pode restaurar seus sistemas ao estado seguro anterior. Na AWS, é possível criar snapshots de vários recursos. Os snapshots fornecem backups pontuais desses recursos. Há muitos serviços da AWS que podem ajudar em backup e recuperação. Para obter detalhes sobre esses serviços e abordagens para backup e recuperação, consulte [Orientação prescritiva de backup e recuperação](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html) e [Usar backups para se recuperar de incidentes de segurança](https://aws.amazon.com/blogs/security/use-backups-to-recover-from-security-incidents/).
Especialmente quando se trata de situações como ransomware, é fundamental que os backups estejam bem protegidos. Para obter orientações sobre como proteger backups, consulte [As dez principais práticas recomendas de segurança para proteger backups na AWS](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/). Além de proteger os backups, você deve testar regularmente seus processos de backup e restauração para verificar se a tecnologia e os processos implementados funcionam conforme o esperado.
**Automatize a análise forense**
Durante um evento de segurança, sua equipe de resposta a incidentes deve ser capaz de coletar e analisar evidências rapidamente, mantendo a precisão durante o período em torno do evento (como capturar registros relacionados a um evento ou recurso específico ou coletar o despejo de memória de uma instância do Amazon EC2). É desafiador e demorado para a equipe de resposta a incidentes coletar manualmente as evidências relevantes, especialmente em um grande número de instâncias e contas. Além disso, a coleta manual pode estar sujeita a erros humanos. Por esses motivos, você deve desenvolver e implementar a automação para perícia forense o máximo possível.
A AWS oferece vários recursos de automação para análise forense, os quais são listados na seção de recursos a seguir. Esses recursos são exemplos de padrões forenses que desenvolvemos e que os clientes implementaram. Embora possam ser uma arquitetura de referência útil para começar, considere modificá-las ou criar padrões de automação forense com base em seu ambiente, requisitos, ferramentas e processos forenses.
## Recursos
**Documentos relacionados:**
+ [Guia de resposta a incidentes de segurança da AWS: Desenvolver recursos forenses ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/develop-forensics-capabilities.html)
+ [Guia de resposta a incidentes de segurança da AWS: Recursos forenses ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-b-incident-response-resources.html#forensic-resources)
+ [Estratégias do ambiente de investigação forense na Nuvem AWS](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/)
+ [Como automatizar a coleta forense de discos na AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/)
+ [Recomendações da AWS: Automatizar a resposta a incidentes e a análise forense ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automate-incident-response-and-forensics.html)
**Vídeos relacionados:**
+ [ Automatizar a resposta a incidentes e a análise forense ](https://www.youtube.com/watch?v=f_EcwmmXkXk)
**Exemplos relacionados:**
+ [Framework de resposta a incidentes e análise forense automatizadas ](https://github.com/awslabs/aws-automated-incident-response-and-forensics)
+ [Orquestrador forense automatizado para Amazon EC2 ](https://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/welcome.html)
# SEC10-BP04 Desenvolver e testar playbooks de resposta a incidentes de segurança
Uma parte fundamental da preparação de seus processos de resposta a incidentes é desenvolver playbooks. Os playbooks de resposta a incidentes fornecem recomendações e etapas a serem seguidas quando um evento de segurança ocorre. Ter uma estrutura e etapas claras simplifica a resposta e reduz a probabilidade de erro humano.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Os playbooks devem ser criados para cenários de incidentes, como:
+ **Incidentes esperados:** os playbooks devem ser criados para os incidentes previstos. Isso inclui ameaças como negação de serviço (DoS), ransomware e comprometimento de credenciais.
+ **Descobertas ou alertas de segurança conhecidos**: devem ser criados playbooks para abordar descobertas e alertas de segurança conhecidos, como os do Amazon GuardDuty. Quando você recebe uma descoberta do GuardDuty, o manual deve fornecer etapas claras para evitar o manuseio incorreto ou a ignorância do alerta. Para obter mais detalhes e orientações sobre remediação, consulte [Correção de problemas de segurança descobertos pelo GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html).
Os playbooks devem conter etapas técnicas a serem concluídas por um analista de segurança para investigar e responder adequadamente a um possível incidente de segurança.
A Equipe de Resposta a Incidentes de Clientes (CIRT) da AWS publicou um [repositório no GitHub que contém manuais de resposta a incidentes](https://github.com/aws-samples/aws-customer-playbook-framework/tree/main/docs) organizados por cenário, tipo e recurso de ameaça. Esses manuais podem ser adaptados para se alinharem aos procedimentos existentes de resposta a incidentes ou servir como base para o desenvolvimento de novos.
### Etapas de implementação
Os itens a serem incluídos em um playbook incluem:
+ **Visão geral do playbook**: qual cenário de risco ou incidente esse playbook aborda? Qual é o objetivo do playbook?
+ **Pré-requisitos**: quais logs, mecanismos de detecção e ferramentas automatizadas são necessários para esse cenário de incidente? Qual é a notificação esperada?
+ **Informações de comunicação e escalação**: quem está envolvido e quais são suas informações de contato? Quais são as responsabilidades de cada parte interessada?
+ **Etapas da resposta:** em todas as fases da resposta a incidentes, quais etapas táticas devem ser seguidas? Que consultas um analista deve executar? Que código deve ser executado para alcançar o resultado desejado?
+ **Detectar**: como o incidente será detectado?
+ **Analisar**: como o escopo do impacto será determinado?
+ **Conter**: como o incidente será isolado para limitar o escopo?
+ **Erradicar**: como a ameaça será removida do ambiente?
+ **Recuperar**: como o sistema ou o recurso afetado voltará à produção?
+ **Resultados esperados**: depois que as consultas e o código forem executados, qual é o resultado esperado do playbook?
## Recursos
**Práticas recomendadas do Well-Architected relacionadas:**
+ [SEC10-BP02 Desenvolver planos de gerenciamento de incidentes](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html)
**Documentos relacionados:**
+ [Framework para playbooks de resposta a incidentes](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [Como desenvolver seus próprios playbooks de resposta a incidentes](https://github.com/aws-samples/aws-incident-response-playbooks-workshop)
+ [Exemplos de playbook de resposta a incidentes](https://github.com/aws-samples/aws-incident-response-playbooks)
+ [Criar um runbook de resposta a incidentes da AWS using playbooks do Jupyter e o CloudTrail Lake](https://catalog.workshops.aws/incident-response-jupyter/en-US)
# SEC10-BP05 Provisionar acesso previamente
Verifique se os respondedores a incidentes têm o acesso correto pré-provisionado na AWS para reduzir o tempo de investigação necessário até a recuperação.
**Práticas comuns que devem ser evitadas:**
+ Uso da conta raiz para a resposta a incidentes.
+ Alterar contas de usuário existentes.
+ Manipular permissões do IAM diretamente ao fornecer elevação de privilégios just-in-time.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
A AWS recomenda reduzir ou eliminar a dependência de credenciais de longa duração sempre que possível, dando preferência a credenciais temporárias e a mecanismos de escalação de privilégios *just-in-time*. As credenciais de longa duração são propensas a riscos de segurança e aumentam a sobrecarga operacional. Para a maioria das tarefas de gerenciamento, bem como para as tarefas de resposta a incidentes, recomendamos implementar a [federação de identidades](https://aws.amazon.com/identity/federation/) junto com a [escalação temporária para acesso administrativo](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/). Nesse modelo, um usuário solicita elevação para um nível de privilégio superior (como um perfil de resposta a incidentes) e, considerando que ele seja elegível para a elevação, a solicitação é enviada a um aprovador. Se a solicitação for aprovada, o usuário receberá um conjunto de [credenciais da AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) temporárias que podem ser usadas para concluir suas tarefas. Quando essas credenciais expirarem, o usuário deverá enviar uma nova solicitação de elevação.
Recomendamos usar a escalação de privilégio temporária para a maioria dos cenários de resposta a incidentes. A maneira correta de fazer isso é usar o [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) e [políticas de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) para definir o escopo do acesso.
Há cenários em que as identidades federadas não estão disponíveis, como:
+ Interrupção relacionada a um provedor de identidades (IdP) comprometido.
+ Erro de configuração ou erro humano causando uma falha no sistema de gerenciamento de acesso federado.
+ Atividade mal-intencionada, como um evento de negação de serviço distribuído (DDoS) ou que causa a indisponibilidade do sistema.
Nos casos anteriores, deve haver um acesso emergencial de *"vidro quebrado"* configurado para permitir a investigação e a correção rápida de incidentes. Recomendamos usar um [usuário, grupo ou perfil com as permissões apropriadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) para realizar tarefas e acessar recursos da AWS. Use as credenciais de usuário-raiz somente para realizar [tarefas que exijam as credenciais de usuário-raiz](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Para verificar se os respondedores de um incidente têm o nível de acesso correto à AWS e a outros sistemas relevantes, recomendamos provisionar previamente contas dedicadas. As contas exigem acesso privilegiado e devem ser estritamente controladas e monitoradas. As contas devem ser criadas com os privilégios mínimos exigidos para realizar as tarefas necessárias e o nível de acesso deve ser baseado nos playbooks criados como parte do plano de gerenciamento de incidentes.
Como prática recomendada, utilize perfis e usuários dedicados e com propósito específico. Escalar temporariamente o acesso de usuários ou perfis por meio da adição de políticas do IAM não deixa claro qual é o acesso que os usuários tinham durante o incidente, e há um risco de que os privilégios escalados não sejam revogados.
É importante remover o máximo de dependências possível para verificar se o acesso pode ser obtido com o maior número possível de cenários de falha. Como forma de auxiliar esse processo, crie um playbook para verificar se os usuários de resposta a incidentes são criados como usuários em uma conta de segurança dedicada e não são gerenciados por nenhuma solução de autenticação única (SSO) ou federação existente. Cada respondedor individual deve ter sua própria conta nomeada. A configuração da conta deve aplicar uma [política de senha forte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) e autenticação multifator (MFA). Se os playbooks de resposta a incidentes só exigem acesso ao Console de gerenciamento da AWS, o usuário não deve ter chaves de acesso configuradas e deve ser proibido explicitamente de criar chaves de acesso. Isso pode ser configurado com políticas do IAM ou políticas de controle de serviços (SCPs), conforme mencionado nas Práticas recomendadas de segurança da AWS para [SCPs do AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) Os usuários não devem ter privilégios além da capacidade de assumir perfis de resposta a incidentes em outras contas.
Durante um incidente, talvez seja necessário conceder acesso a outros indivíduos internos ou externos para apoiar a investigação, a correção ou as atividades de recuperação. Nesse caso, use o mecanismo do playbook mencionado anteriormente, e deve haver um processo para verificar se qualquer acesso adicional foi revogado imediatamente após a conclusão do incidente.
Para verificar se o uso de perfis de resposta a incidentes pode ser monitorado e auditado corretamente, é essencial que as contas de usuário do IAM criadas para esse fim não sejam compartilhadas entre indivíduos e que o Usuário raiz da conta da AWS não seja utilizado, a menos que isso seja [necessário para uma tarefa específica](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Se o usuário-raiz for necessário (por exemplo, quando o acesso do IAM a uma conta específica estiver indisponível), use um processo separado com um playbook disponível para verificar a disponibilidade das credenciais de início de sessão e do token de MFA do usuário-raiz.
Para configurar as políticas do IAM para os perfis de resposta a incidentes, considere usar o [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) para gerar políticas com base em logs do AWS CloudTrail. Para fazer isso, conceda acesso de administrador ao perfil de resposta a incidentes em uma conta de não produção e execute as etapas descritas nos playbooks. Concluído o processo, uma política que permita somente as ações realizadas pode ser criada. Essa política pode ser então aplicada a todos os perfis de resposta a incidentes em todas as contas. Você pode criar uma política do IAM separada para cada playbook a fim de facilitar o gerenciamento e a auditoria. Exemplos de playbook podem incluir planos de resposta para ransomware, violações de dados, perda de acesso à produção, entre outros cenários.
Use as contas de resposta a incidentes para assumir [perfis do IAM de resposta a incidentes dedicados em outras Contas da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) Esses perfis também devem ser configurados para poder ser assumidos somente por usuários na conta de segurança, e o relacionamento de confiança deve exigir que a entidade principal que está fazendo a chamada seja autenticada com MFA. Os perfis devem usar políticas do IAM com escopo estritamente definido para controlar o acesso. Certifique-se de que todas as solicitações de `AssumeRole` para esses perfis sejam registradas em log no CloudTrail e acionem alertas, e que quaisquer ações realizadas usando esses perfis sejam registradas em log.
É altamente recomendável que as contas do IAM e os perfis do IAM sejam claramente nomeados para permitir que sejam encontrados com facilidade nos logs do CloudTrail. Um exemplo disso seria nomear as contas do IAM como `-BREAK-GLASS` e os perfis do IAM como `BREAK-GLASS-ROLE`.
O [CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) é usado para registrar a atividade da API em suas contas da AWS e deve ser usado para [configurar alertas sobre o uso dos perfis de resposta a incidentes](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/). Consulte a publicação do blog sobre como configurar alertas quando as chaves-raiz são usadas. As instruções podem ser modificadas para configurar o filtro métrico do [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) para filtrar eventos `AssumeRole` relacionados ao perfil do IAM de resposta a incidentes:
```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```
Como é provável que os perfis de resposta a incidentes tenham um alto nível de acesso, é importante que esses alertas sejam transmitidos a um grupo amplo e que as atitudes necessárias sejam tomadas rapidamente.
Durante um incidente, é possível que um respondedor possa exigir acesso a sistemas que não são protegidos diretamente pelo IAM. Isso pode incluir instâncias do Amazon Elastic Compute Cloud, bancos de dados do Amazon Relational Database Service ou plataformas de software como serviço (SaaS). É altamente recomendável que, em vez de usar protocolos nativos, como SSH ou RDP, o [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) seja usado para todo o acesso administrativo às instâncias do Amazon EC2. Esse acesso pode ser controlado usando o IAM, que é seguro e auditado. Talvez também seja possível automatizar partes de seus playbook usando [documentos de execução de comandos do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html), o que pode reduzir os erros do usuário e melhorar o tempo de recuperação. Para acesso aos bancos de dados e a ferramentas de terceiros, recomendamos armazenar as credenciais de acesso no AWS Secrets Manager e conceder acesso aos perfis de respondedores a incidentes.
Por fim, o gerenciamento das contas do IAM de resposta a incidentes deve ser adicionado aos seus [processos de Joiners, Movers e Leavers](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) e revisado e testado periodicamente para verificar se somente o acesso pretendido é permitido.
## Recursos
**Documentos relacionados:**
+ [Gerenciar o acesso elevado temporário ao seu ambiente da AWS](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)
+ [Guia de resposta a incidentes de segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
+ [Definir uma política de senhas de contas para usuários do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)
+ [Usar a autenticação multifator (MFA) na AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)
+ [Configurar o acesso entre contas com MFA](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [Usar o IAM Access Analyzer para gerar políticas do IAM](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/)
+ [Práticas recomendadas para Políticas de controle de serviços do AWS Organizations em um ambiente com várias contas](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [Como receber notificações quando as chaves de acesso raiz da sua conta da AWS são usadas](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [Criar permissões de sessão refinadas usando políticas gerenciadas pelo IAM](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)
+ [Acesso de emergência](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**Vídeos relacionados:**
+ [Automatizar a resposta a incidentes e a análise forense na AWS](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+ [Guia de faça você mesmo para runbooks, relatórios de incidentes e resposta a incidentes](https://youtu.be/E1NaYN_fJUo)
+ [Como se preparar e responder a incidentes de segurança no ambiente da AWS](https://www.youtube.com/watch?v=8uiO0Z5meCs)
# SEC10-BP06 Implantar ferramentas previamente
Verifique se o pessoal de segurança tem as ferramentas certas pré-implantadas para reduzir o tempo de investigação até a recuperação.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Para automatizar as funções de resposta e operações de segurança, é possível usar um conjunto abrangente de APIs e ferramentas da AWS. Você pode automatizar totalmente os recursos de gerenciamento de identidade, segurança de rede, proteção de dados e monitoramento e disponibilizá-los com métodos populares de desenvolvimento de software já em vigor. Quando você cria a automação da segurança, seu sistema pode monitorar, analisar e iniciar uma resposta, em vez de fazer com que as pessoas monitorem a sua posição de segurança e reajam manualmente a eventos.
Se as equipes de resposta a incidentes continuarem a responder aos alertas da mesma forma, haverá o risco de se acostumarem aos alertas. Com o passar do tempo, a equipe pode se tornar dessensibilizada para alertas e cometer erros ao lidar com situações comuns ou perder alertas incomuns. A automação ajuda a evitar a exaustão de alertas usando funções que processam alertas repetitivos e comuns, permitindo que as pessoas lidem com incidentes confidenciais e exclusivos. A integração de sistemas de detecção de anomalias, como Amazon GuardDuty, AWS CloudTrail Insights e Amazon CloudWatch Anomaly Detection, pode reduzir a carga de alertas baseados em limites comuns.
Você pode melhorar os processos manuais com a automatização programática das etapas do processo. Depois de definir o padrão de correção para um evento, você poderá decompor esse padrão em lógica acionável e desenvolver o código para executar essa lógica. Os respondedores podem executar esse código para corrigir o problema. Com o passar do tempo, você pode automatizar mais e mais etapas e, por fim, lidar automaticamente com classes inteiras de incidentes comuns.
Durante uma investigação de segurança, você precisa ser capaz de revisar os logs relevantes para registrar e compreender o escopo completo e o cronograma do incidente. Os logs também são necessários para geração de alertas indicando que determinadas ações de interesse ocorreram. É essencial selecionar, ativar, armazenar e configurar mecanismos de consulta e recuperação, bem como definir alertas. Além disso, uma forma eficaz de fornecer ferramentas para pesquisar dados de log é o [Amazon Detective](https://aws.amazon.com/detective/).
A AWS oferece mais de 200 serviços em nuvem e milhares de recursos. Recomendamos que você analise os serviços que podem apoiar e simplificar sua estratégia de resposta a incidentes.
Além do registro, você deve desenvolver e implementar uma [estratégia de marcação](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html). A marcação pode ajudar a fornecer contexto sobre a finalidade de um recurso da AWS. A marcação também pode ser usada para automação.
### Etapas de implementação
**Selecione e configure logs para análise e alertas**
Consulte a documentação a seguir sobre como configurar logs para resposta a incidentes:
+ [Estratégias de log para resposta a incidentes de segurança](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [SEC04-BP01 Configurar o registro em log de serviços e aplicações](sec_detect_investigate_events_app_service_logging.md)
**Habilite serviços de segurança para oferecer suporte a detecção e resposta**
A AWS fornece recursos de detecção, prevenção e resposta, e outros serviços podem ser usados para projetar soluções de segurança personalizadas. Para ver uma lista dos serviços mais relevantes para resposta a incidentes de segurança, consulte [Definições das funcionalidades da nuvem](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html) e a [página inicial do serviço Resposta a Incidentes de Segurança](https://aws.amazon.com/security-incident-response/).
**Desenvolva e implemente uma estratégia de marcação**
Obter informações contextuais sobre o caso de uso empresarial e as partes interessadas internas relevantes em torno de um recurso da AWS pode ser difícil. Uma forma de fazer isso é na forma de tags, que atribuem metadados aos recursos da AWS e consistem em uma chave e um valor definidos pelo usuário. Você pode criar tags para categorizar os recursos por finalidade, proprietário, ambiente, tipo de dados processados e outros critérios de sua escolha.
Ter uma estratégia de marcação consistente pode acelerar os tempos de resposta e minimizar o tempo gasto no contexto organizacional, permitindo identificar e discernir rapidamente as informações contextuais sobre um recurso da AWS. As tags também podem servir como um mecanismo para iniciar automações de resposta. Para obter mais detalhes sobre o que marcar, consulte [Como marcar seus recursos da AWS](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html). Primeiro, você deve definir as tags que deseja implementar em toda a sua organização. Depois disso, você implementará e aplicará essa estratégia de marcação. Para obter mais detalhes sobre implementação e fiscalização, consulte [Implementar a estratégia de marcação de recursos da AWS usando políticas de tags e políticas de controle de serviços (SCPs) da AWS](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/).
## Recursos
**Práticas recomendadas do Well-Architected relacionadas:**
+ [SEC04-BP01 Configurar o registro em log de serviços e aplicações](sec_detect_investigate_events_app_service_logging.md)
+ [SEC04-BP02 Capturar logs, descobertas e métricas em locais padronizados](sec_detect_investigate_events_logs.md)
**Documentos relacionados:**
+ [ Estratégias de log para resposta a incidentes de segurança ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [ Definições de recursos de nuvem para resposta a incidentes ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html)
**Exemplos relacionados:**
+ [ Detecção e resposta a ameaças com o Amazon GuardDuty e o Amazon Detective ](https://catalog.workshops.aws/guardduty/en-US)
+ [ Workshop do Security Hub ](https://catalog.workshops.aws/security)
+ [ Gerenciamento de vulnerabilidades com o Amazon Inspector ](https://catalog.workshops.aws/inspector/en-US)
# SEC10-BP07 Executar simulações
À medida que as organizações crescem e evoluem com o tempo, o mesmo acontece com o cenário de ameaças, o que torna importante analisar continuamente seus recursos de resposta a incidentes. Executar simulações (também conhecidas como "game days") é um método que pode ser usado para realizar essa avaliação. As simulações usam cenários de eventos de segurança do mundo real projetados para imitar as táticas, as técnicas e os procedimentos (TTPs) de um agente de ameaças e permitir que uma organização exercite e avalie seus recursos de resposta a incidentes respondendo a esses eventos cibernéticos simulados da mesma forma que em uma situação real.
**Benefícios de implantar esta prática recomendada:** as simulações trazem vários benefícios:
+ Validar a prontidão cibernética e desenvolver a confiança de seus socorristas.
+ Testar a precisão e a eficiência de ferramentas e fluxos de trabalho.
+ Refinar os métodos de comunicação e escalação alinhados ao seu plano de resposta a incidentes.
+ Proporcionar uma oportunidade de responder a vetores menos comuns.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Existem três tipos principais de simulações:
+ **Simulações teóricas:** a abordagem de simulações teóricas é uma sessão baseada em discussões que envolvem as várias partes interessadas na resposta a incidentes para exercer funções e responsabilidades e usar ferramentas de comunicação e playbooks estabelecidos. A facilitação das simulações normalmente pode ser realizada em um dia inteiro em um local virtual, local físico ou uma combinação de ambos. Por ser baseada em discussões, a simulação teórica se concentra em processos, pessoas e colaboração. A tecnologia é parte integrante da discussão, mas o uso real de ferramentas ou scripts de resposta a incidentes geralmente não faz parte da simulação teórica.
+ **Simulações da equipe roxa:** As simulações da equipe roxa aumentam o nível de colaboração entre os respondedores ao incidente (equipe azul) e os agentes de ameaças simuladas (equipe vermelha). A equipe azul é composta por membros do centro de operações de segurança (SOC), mas também pode incluir outras partes interessadas que estariam envolvidas durante um evento cibernético real. A equipe vermelha é composta por uma equipe de testes de penetração ou pelas principais partes interessadas treinadas em segurança ofensiva. A equipe vermelha trabalha em colaboração com os facilitadores da simulação ao projetar um cenário que seja preciso e viável. Durante as simulações da equipe roxa, o foco principal está nos mecanismos de detecção, nas ferramentas e nos procedimentos operacionais padrão (SOPs) que apoiam os esforços de resposta a incidentes.
+ **Simulações da equipe vermelha:** durante uma simulação da equipe vermelha, o infrator (equipe vermelha) realiza uma simulação para atingir um determinado objetivo ou conjunto de objetivos a partir de um escopo predeterminado. Os defensores (equipe azul) não necessariamente terão conhecimento do escopo e da duração da simulação, o que oferece uma avaliação mais realista de como eles responderiam a um incidente real. Como as simulações da equipe vermelha podem ser testes invasivos, tenha cuidado e implemente controles para verificar se a simulação não causa danos reais ao ambiente.
Considere facilitar as simulações cibernéticas em intervalos regulares. Cada tipo de simulação pode oferecer benefícios exclusivos aos participantes e à organização como um todo. Portanto, você pode optar por começar com tipos de simulação menos complexos (como simulações teóricas) e avançar para tipos de simulação mais complexos (simulações da equipe vermelha). Você deve selecionar um tipo de simulação com base em sua maturidade de segurança, recursos e resultados desejados. Alguns clientes podem não optar por realizar simulações da equipe vermelha devido à complexidade e ao custo.
## Etapas de implementação
Independentemente do tipo de simulação que você escolher, as simulações geralmente seguem estas etapas de implementação:
1. **Defina os elementos fundamentais da simulação:** defina o cenário e os objetivos da simulação. Ambos devem ter aceitação da equipe de liderança.
1. **Identifique as principais partes interessadas:** no mínimo, a simulação precisa de facilitadores e participantes. Dependendo do cenário, outras partes interessadas, como departamento jurídico, de comunicação ou liderança executiva, podem estar envolvidos.
1. **Crie e teste o cenário:** talvez o cenário precise ser redefinido durante a criação se elementos específicos não forem viáveis. Espera-se um cenário finalizado como resultado dessa etapa.
1. **Facilite a simulação:** o tipo de simulação determina a facilitação usada (um cenário impresso em comparação a um cenário simulado altamente técnico). Os facilitadores devem alinhar suas táticas de facilitação aos objetos da simulação e envolver todos os participantes sempre que possível para proporcionar o máximo benefício.
1. **Desenvolva o relatório pós-ação (AAR):** identifique as áreas de sucesso, aquelas que podem ser melhoradas e possíveis lacunas. O AAR deve medir a eficácia da simulação, bem como a resposta da equipe ao evento simulado, para que o progresso possa ser monitorado ao longo do tempo com simulações futuras.
## Recursos
**Documentos relacionados:**
+ [Guia de resposta a incidentes da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
**Vídeos relacionados:**
+ [AWS GameDay: edição de segurança](https://www.youtube.com/watch?v=XnfDWID_OQs)
+ [Running effective security incident response simulations](https://www.youtube.com/watch?v=63EdzHT25_A)
# Operações
As operações são a base da resposta a incidentes. É aqui que ocorrem as ações de resposta e atenuação de incidentes de segurança. As operações incluem as seguintes cinco fases: *detecção*, *análise*, *contenção*, *erradicação* e *recuperação*. As descrições dessas fases e dos objetivos podem ser encontradas na tabela a seguir.
| **Phase (Fase)** | **Objetivo** |
| --- | --- |
| Detecção | Identifique um possível evento de segurança. |
| Análise | Determine se o evento de segurança é um incidente e avalie o escopo do incidente. |
| Contenção | Minimize e limite o escopo do evento de segurança. |
| Erradicação | Remova recursos ou artefatos não autorizados relacionados ao evento de segurança. Implemente atenuações para as causas do incidente de segurança. |
| Recuperação | Restaure os sistemas ao estado seguro conhecido e monitore esses sistemas para verificar se não há retorno da ameaça. |
As fases devem servir como orientação quando você responde e atua em incidentes de segurança, a fim de responder de forma eficaz e robusta. As ações reais realizadas variam de acordo com o incidente. Um incidente envolvendo ransomware, por exemplo, terá um conjunto de etapas de resposta a serem seguidas diferente do que o de um incidente que envolva um bucket público do Amazon S3. Além disso, essas fases não acontecem necessariamente de modo sequencial. Após a contenção e a erradicação, talvez seja necessário retornar à análise para entender se suas ações foram eficazes.
A preparação completa de seu pessoal, processos e tecnologia é fundamental para ser eficaz nas operações. Portanto, siga as práticas recomendadas da seção [Preparação](preparation.md) para poder responder com eficácia a um evento de segurança ativo.
Para saber mais, consulte a seção [Operações](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/operations.html) do Guia de resposta a incidentes de segurança da AWS.
# Atividade pós-incidente
O cenário de ameaças está mudando constantemente, e é importante ser igualmente dinâmico na capacidade de sua organização de proteger seus ambientes com eficácia. A chave para a melhoria contínua é iterar os resultados de seus incidentes e simulações a fim de melhorar seus recursos para detectar, responder e investigar com eficácia possíveis incidentes de segurança, reduzindo suas possíveis vulnerabilidades, o tempo de resposta e o retorno às operações seguras. Os mecanismos a seguir podem ajudar você a verificar se sua organização continua preparada com os recursos e os conhecimentos mais recentes para responder com eficácia, independentemente da situação.
**Topics**
+ [SEC10-BP08 Estabelecer um framework para aprender com os incidentes](sec_incident_response_establish_incident_framework.md)
# SEC10-BP08 Estabelecer um framework para aprender com os incidentes
Implementar um framework de *lições aprendidas* e o recurso de análise da causa-raiz não só ajudará a melhorar os recursos de resposta a incidentes, mas também a evitar que o incidente se repita. Ao aprender com cada incidente, você pode ajudar a evitar a repetição dos mesmos erros, exposições ou configurações incorretas, não apenas melhorando seu procedimento de segurança, mas também minimizando o tempo perdido em situações evitáveis.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
É importante implementar um framework de *lições aprendidas* que estabeleça e atinja, em alto nível, os seguintes pontos:
+ Quando um processo de lições aprendidas é realizado?
+ O que está envolvido no processo de lições aprendidas?
+ Como um processo de lições aprendidas é realizado?
+ Quem está envolvido no processo e como?
+ Como as áreas de melhoria serão identificadas?
+ Como você garantirá que as melhorias sejam monitoradas e implementadas de forma eficaz?
O framework não deve se concentrar em culpar os indivíduos, mas sim na melhoria de ferramentas e processos.
### Etapas de implementação
Além dos resultados de alto nível listados acima, é importante garantir que você faça as perguntas certas para obter o máximo valor (informações que levem a melhorias práticas) do processo. Considere estas perguntas para ajudar você a começar a promover discussões sobre lições aprendidas:
+ Como foi o incidente?
+ Quando o incidente foi identificado pela primeira vez?
+ Como ele foi identificado?
+ Que sistemas alertaram sobre a atividade?
+ Que sistemas, serviços e dados estiveram envolvidos?
+ O que ocorreu especificamente?
+ O que funcionou bem?
+ O que não funcionou bem?
+ Que processos ou procedimentos falharam ou não tiveram a escala ajustada para responder ao incidente?
+ O que pode ser melhorado nas seguintes áreas:
+ **Pessoas**
+ As pessoas que precisavam ser contatadas estavam realmente disponíveis e a lista de contatos estava atualizada?
+ As pessoas estavam perdendo treinamentos ou não tinham os recursos necessários para responder e investigar o incidente de forma eficaz?
+ Os recursos apropriados estavam prontos e disponíveis?
+ **Processo**
+ Os processos e procedimentos foram seguidos?
+ Os processos e procedimentos foram documentados e estavam disponíveis para esse (tipo de) incidente?
+ Havia processos e procedimentos necessários faltando?
+ Os respondedores conseguiram obter acesso oportuno às informações necessárias para responder ao problema?
+ **Tecnologia**
+ Os sistemas de alerta existentes identificaram e alertaram efetivamente sobre a atividade?
+ Como poderíamos ter reduzido o tempo de detecção em 50%?
+ Os alertas existentes precisam ser aprimorados ou novos alertas precisam ser criados para esse (tipo de) incidente?
+ As ferramentas existentes permitiram uma investigação (pesquisa/análise) eficaz do incidente?
+ O que pode ser feito para ajudar a identificar esse (tipo de) incidente mais cedo?
+ O que pode ser feito para ajudar a evitar que esse (tipo de) incidente ocorra novamente?
+ Quem é o proprietário do plano de melhoria e como você testará se ele foi implementado?
+ Qual é o cronograma para que os controles e processos adicionais de monitoramento ou prevenção sejam implementados e testados?
Essa lista não inclui tudo, mas serve como ponto de partida para identificar quais são as necessidades da organização e da empresa e como você pode analisá-las para aprender com os incidentes de forma mais eficaz e melhorar constantemente seu procedimento de segurança. O mais importante é começar incorporando as lições aprendidas como parte padrão do processo de resposta a incidentes, da documentação e das expectativas das partes interessadas.
## Recursos
**Documentos relacionados:**
+ [Guia de resposta a incidentes da AWS: estabelecer um framework para aprender com os incidentes](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/establish-framework-for-learning.html)
+ [Orientações do NCSC CAF: lições aprendidas](https://www.ncsc.gov.uk/collection/caf/caf-principles-and-guidance/d-2-lessons-learned)