# Processar
O desenvolvimento de processos de resposta a incidentes bem estruturados e devidamente definidos é essencial para garantir o êxito e a escalabilidade de um programa de resposta a incidentes. No caso da ocorrência de um evento de segurança, a existência de etapas e fluxos de trabalho claros permitirá uma resposta em tempo hábil. É possível que você já tenha processos existentes de resposta a incidentes. Independentemente do seu estado atual, é importante atualizar, repetir e testar seus processos de resposta a incidentes regularmente.
# Desenvolvimento e teste de um plano de resposta a incidentes
O primeiro documento a ser desenvolvido para a 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. Um plano de resposta a incidentes consiste em um documento de alto nível que, normalmente, inclui as seguintes seções:
+ **Visão geral da equipe de resposta a incidentes**: apresenta as metas e as funções da equipe de resposta a incidentes.
+ **Perfis e responsabilidades**: lista as partes interessadas na resposta a incidentes e detalha os perfis em caso de ocorrência de um incidente.
+ **Plano de comunicação**: detalha as informações de contato e a maneira como será realizada a comunicação durante um incidente.
É uma prática recomendada dispor de um canal de comunicação externo à banda principal como um backup para comunicação em incidentes. Um exemplo de uma aplicação que fornece um canal de comunicação seguro e externo à banda é o [AWS Wickr](https://aws.amazon.com/wickr/).
+ **Fases da resposta a incidentes e ações a serem executadas**: enumera as fases da resposta a incidentes, por exemplo, detecção, análise, erradicação, contenção e recuperação, incluindo as ações de alto nível a serem executadas em cada fase.
+ **Definições relativas à severidade e priorização de incidentes**: explicita os critérios para a classificação da severidade de um incidente, a maneira de realizar a priorização dos incidentes e, em seguida, a influência dessas definições de severidade nos procedimentos de encaminhamento.
Embora essas seções sejam comuns em empresas de diferentes tamanhos e setores, o plano de resposta a incidentes de cada organização é único. Será necessário elaborar um plano de resposta a incidentes que seja mais adequado para a sua organização.
# Documentação e centralização dos diagramas de arquitetura
Para responder de forma rápida e precisa a um evento de segurança, é necessário compreender como seus sistemas e suas redes estão arquitetados. A compreensão desses padrões internos é essencial não apenas para a resposta a incidentes, mas também para verificar a consistência das aplicações que foram desenvolvidas seguindo esses padrões, de acordo com as práticas recomendadas. Você também deve verificar se essa documentação está atualizada e é regularmente atualizada de acordo com os novos padrões de arquitetura. Recomenda-se desenvolver documentação e repositórios internos que detalhem itens como:
+ **Estrutura da conta da AWS**: informações necessárias:
+ Qual é a quantidade de contas da AWS que você tem?
+ De que maneira essas contas da AWS estão organizadas?
+ Quem são os responsáveis comerciais por cada conta da AWS?
+ Você faz o uso de políticas de controle de serviços (SCPs)? Em caso afirmativo, quais barreiras de proteção organizacionais são implementadas ao usar as SCPs?
+ Você limita as regiões e os serviços que podem ser usados?
+ Quais são as diferenças entre as unidades de negócios e os ambientes (dev/teste/produção)?
+ **Padrões de serviços da AWS**
+ Quais serviços da AWS são usados por você?
+ Quais são os serviços da AWS que apresentam maior adoção?
+ **Padrões de arquitetura**
+ Quais arquiteturas de nuvem são usadas por você?
+ **Padrões de autenticação da AWS**
+ De que maneira seus desenvolvedores geralmente realizam a autenticação na AWS?
+ Você usa usuários ou perfis do IAM, ou uma combinação de ambos? Sua autenticação na AWS está conectada a um provedor de identidades (IdP)?
+ De que maneira é realizado o mapeamento de um usuário por perfil do IAM para um colaborador ou para um sistema?
+ De que maneira ocorre a revogação de acesso quando um indivíduo perde a autorização?
+ **Padrões de autorização da AWS**
+ Quais políticas do IAM são usadas por seus desenvolvedores?
+ Você faz o uso de políticas baseadas em recursos?
+ **Registro em log e monitoramento**
+ Quais fontes de registros em log são usadas e em quais locais essas fontes são armazenadas?
+ Você realiza a agregação de logs do AWS CloudTrail? Em caso afirmativo, em quais locais esses logs são armazenados?
+ De que maneira você realiza a consulta em logs do CloudTrail?
+ O Amazon GuardDuty está habilitado?
+ De que maneira é possível acessar as descobertas do GuardDuty (por exemplo, o console, o sistema de emissão de tíquetes e o SIEM)?
+ As descobertas ou os eventos são agregados em um SIEM?
+ Os tíquetes são criados automaticamente?
+ Quais ferramentas estão em vigor para realizar a análise de logs para uma investigação?
+ **Topologia de rede**
+ De que maneira os dispositivos, os endpoints e as conexões presentes em sua rede estão organizados física ou logicamente?
+ De que maneira sua rede se conecta com a AWS?
+ De que maneira é realizado a filtragem do tráfego de rede entre os diferentes ambientes?
+ **Infraestrutura externa**
+ De que maneira as aplicações voltadas para o público externo são implantadas?
+ Quais recursos da AWS estão disponíveis publicamente?
+ Quais contas da AWS hospedam infraestrutura voltada para o público externo?
+ Que mecanismos de proteção contra ataques de DDoS ou filtragem externa estão implementados?
A documentação de diagramas técnicos e processos internos facilita o trabalho do analista responsável pela resposta a incidentes, permitindo o acesso rápido ao conhecimento técnico institucional necessário para responder a um evento de segurança. A documentação completa dos processos técnicos internos não apenas simplifica as investigações de segurança, como também contribui para a racionalização e para a avaliação desses processos.
# Desenvolvimento de planos de ação de resposta a incidentes
Uma parte fundamental da preparação de seus processos de resposta a incidentes é desenvolver playbooks. Os playbooks de resposta a incidentes fornecem uma série de 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.
# Identificação de situações que requerem a criação de planos de ação
Os playbooks devem ser criados para cenários de incidentes, como:
+ **Incidentes esperados:** é recomendável criar planos de ação para os tipos de incidentes que podem ser antecipados. Isso inclui ameaças como negação de serviço (DoS), ransomware e comprometimento de credenciais.
+ **Descobertas ou alertas de segurança conhecidos:** é recomendável elaborar planos de ação específicos para descobertas e alertas de segurança conhecidos, como as descobertas geradas pelo GuardDuty. Você pode receber uma descoberta do GuardDuty e pensar: “E agora?” Para evitar o tratamento inadequado de uma descoberta do GuardDuty ou a negligência diante dessa descoberta, crie um plano de ação correspondente para cada tipo de descoberta possível do GuardDuty. Alguns detalhes e orientações sobre a correção podem ser encontrados na [documentação do GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html). É importante notar que o GuardDuty não está habilitado por padrão e seu uso gera custos. Mais detalhes sobre o GuardDuty podem ser encontrados no Apêndice A: definições das funcionalidades da nuvem: [Visibilidade e geração de alertas](visibility-and-alerting.md).
# O que deve ser incluso nos planos de ação
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.
Os itens a serem incluídos em um playbook incluem:
+ **Visão geral do plano de ação**: quais cenários de riscos ou de incidentes este plano de ação aborda? Qual é o objetivo do playbook?
+ **Requisitos prévios**: quais logs e mecanismos de detecção são necessários para este cenário de incidente? Qual é a notificação esperada?
+ **Informações das partes interessadas**: quem são as pessoas envolvidas e quais são suas informações de contato? Quais são as responsabilidades de cada parte interessada?
+ **Etapas de resposta**: ao longo das fases da resposta a incidentes, quais etapas táticas devem ser adotadas? Que consultas um analista deve executar? Que código deve ser executado para alcançar o resultado desejado?
+ **Detecção**: qual será o método de detecção do incidente?
+ **Análise**: qual será o método de determinação do escopo do impacto?
+ **Contenção**: qual será o método de isolamento do incidente para limitar o escopo?
+ **Erradicação**: qual será o método de remoção da ameaça do ambiente?
+ **Recuperação**: qual será o método de reintegração do sistema ou do serviço afetado para o ambiente de produção?
+ **Resultados esperados**: quais são os resultados esperados após a execução das consultas e do código definido neste plano de ação?
Com a finalidade de verificar a consistência das informações em cada plano de ação, pode ser útil criar um modelo de plano de ação a ser usado nos demais planos de ação de segurança. Alguns dos itens mencionados anteriormente, por exemplo, as informações das partes interessadas, podem ser comuns a vários planos de ação. Se esse for o caso, é possível criar uma documentação centralizada para essas informações e apenas referenciá-la no plano de ação, enumerando as diferenças específicas diretamente no próprio plano de ação. Dessa forma, você evita a necessidade de atualizar repetidamente as mesmas informações em cada plano de ação de forma individual. Ao criar um modelo e ao identificar informações comuns ou compartilhadas entre os planos de ação, é possível simplificar e agilizar o desenvolvimento dos planos de ação. Por fim, considerando que os planos de ação tendem a evoluir ao longo do tempo, a padronização das etapas permite definir os requisitos necessários para sua automação.
# Planos de ação de amostra
Diversos planos de ação de amostra podem ser encontrados no Apêndice B, na seção [Recursos relacionados ao plano de ação](appendix-b-incident-response-resources.md#playbook-resources). Os exemplos apresentados podem servir como referência para a criação dos seus próprios planos de ação e para a definição dos elementos que devem ser incluídos nesses planos de ação. No entanto, é fundamental que você elabore planos de ação que incorporem os riscos mais relevantes ao seu negócio. É necessário verificar se as etapas e os fluxos de trabalho definidos nos seus planos de ação estão alinhados às tecnologias e aos processos usados em sua organização.
# Execução de simulações de forma periódica
Com o tempo, as organizações se desenvolvem e transformam, assim como o panorama de ameaças. Por isso, é importante analisar continuamente suas funcionalidades de resposta a incidentes. As simulações são um dos métodos que podem ser usados 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.
As simulações fornecem uma variedade de benefícios, incluindo:
+ 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.
# Tipos de simulações
Existem três tipos principais de simulações:
+ **Exercícios de simulação**: abordagem de exercícios de simulação consiste estritamente em uma sessão baseada em debates, envolvendo as diversas partes interessadas responsáveis pela resposta a incidentes para praticar as atividades atribuídas ao cargo e as responsabilidades, além de usar as ferramentas de comunicação e os planos de ação estabelecidos. Normalmente, a facilitação do exercício pode ser realizada em um dia inteiro, seja em um ambiente virtual, em um ambiente físico ou em uma combinação de ambos. Devido à sua natureza baseada em debates, o exercício de simulação se concentra em processos, pessoas e colaboração. A tecnologia constitui uma parte essencial da discussão. No entanto, o uso real de ferramentas ou de scripts de resposta a incidentes geralmente não faz parte do exercício de simulação.
+ **Exercícios de Purple Team**: os exercícios de Purple Team aumentam o nível de colaboração entre os responsáveis pela resposta a incidentes (*Blue Team*) e os agentes de ameaças simulados (*Red Team*). Geralmente, o Blue Team é composto por membros do Security Operations Center (SOC), mas também pode incluir outras partes interessadas que estariam envolvidas durante um evento cibernético real. O Red Team, por sua vez, é geralmente formado por uma equipe de testes de penetração ou por partes interessadas principais que foram treinadas em segurança ofensiva. O Red Team trabalha de forma colaborativa com os facilitadores do exercício durante a elaboração do cenário, garantindo que este seja preciso e viável. Durante os exercícios de Purple Team, o foco principal está nos mecanismos de detecção, nas ferramentas e nos procedimentos operacionais padrão (SOPs, na sigla em inglês) que fornecem suporte às iniciativas de resposta a incidentes.
+ **Exercícios de Red Team**: durante um exercício de Red Team, a equipe ofensiva (*Red Team*) conduz uma simulação para atingir um objetivo ou conjunto de objetivos determinado dentro de um escopo determinado previamente. A equipe defensora (*Blue Team*) nem sempre conhecem o escopo e a duração do exercício, o que proporciona uma avaliação mais realista de como as pessoas reagiriam a um incidente real. Como os exercícios de Red Team podem ser testes invasivos, é recomendável agir com cautela e implementar controles para garantir que o exercício não cause danos reais ao seu ambiente.
**nota**
A AWS requer que os clientes analisem a política de testes de penetração disponível no [site de teste de penetração](https://aws.amazon.com/security/penetration-testing/) antes de realizarem exercícios de Purple Team ou de Red Team.
A Tabela 1 apresenta um resumo das principais diferenças entre esses tipos de simulações. É importante destacar que as definições são geralmente consideradas flexíveis e podem ser personalizadas para atender às necessidades da sua organização.
*Tabela 1: tipos de simulações*
| | Exercício de simulação | Exercício de Purple Team | Exercício de Red Team |
| --- | --- | --- | --- |
| Resumo | Exercícios baseados em documentos que se concentram em um cenário específico de incidente de segurança. Os exercícios podem ser de nível estratégico ou técnico, e são conduzidos por uma série de informações documentadas. | Uma abordagem mais realista em comparação aos exercícios de simulação. Durante os exercícios de Purple Team, os facilitadores trabalham de forma colaborativa com os participantes para aumentar o engajamento no exercício e oferecer treinamento quando necessário. | Trata-se, em geral, de uma simulação mais complexa. Normalmente há um alto nível de sigilo, de modo que os participantes podem não conhecer todos os detalhes do exercício. |
| Recursos necessários | Recursos técnicos limitados necessários | Diversas partes interessadas necessárias e alto nível de recursos técnicos necessários | Diversas partes interessadas necessárias e alto nível de recursos técnicos necessários |
| Complexidade | Baixo | Médio | Alto |
Considere facilitar as simulações cibernéticas em intervalos regulares. Cada tipo de exercício pode fornecer benefícios únicos aos participantes e à organização como um todo, por isso pode ser interessante começar com simulações menos complexas (como os exercícios de simulação) e evoluir gradualmente para simulações mais complexas (como os exercícios de Red Team). Você deve selecionar um tipo de simulação com base em sua maturidade de segurança, recursos e resultados desejados. Alguns clientes podem optar por não realizar exercícios de Red Team devido à sua complexidade e ao custo envolvido.
# Ciclo de vida do exercício
Independentemente do tipo de simulação que você escolher, as simulações geralmente seguem estas etapas:
1. **Definição dos elementos principais do exercício**: defina o cenário da simulação e os objetivos da simulação. Ambos devem ter aceitação da equipe de liderança.
1. **Identificação das partes interessadas principais**: no mínimo, um exercício requer 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. **Desenvolvimento e teste do cenário**: o cenário pode precisar ser redefinido durante sua elaboração, caso determinados elementos não sejam viáveis. Espera-se um cenário finalizado como resultado dessa etapa.
1. **Facilitação da simulação**: o tipo de simulação determina o método de facilitação adotado (por exemplo, um cenário baseado em documentos comparado a um cenário altamente técnico e simulado). 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. **Elaboração do relatório posterior à ação (AAR, na sigla em inglês)**: identifique os pontos que funcionaram bem, aqueles que podem ser aprimorados 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.