# 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 das metas podem ser encontradas na Tabela 3.
*Tabela 3: fases operacionais*
| Fase | Objetivo |
| --- | --- |
| Detecção | Identifique um possível evento de segurança. |
| Análise | Determinar se um evento de segurança constitui um incidente e avaliar 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 | Restaurar os sistemas para um estado seguro conhecido e monitorar 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.
# Detecção
Um alerta corresponde ao componente principal da fase de detecção. Ele gera uma notificação para iniciar o processo de resposta a incidente com base nas atividades de ameaças na conta da AWS em questão.
A precisão dos alertas é um desafio. Não é sempre que é possível determinar com total certeza se um incidente ocorreu, está em andamento ou se ocorrerá no futuro. A seguir, apresentamos alguns motivos:
+ Os mecanismos de detecção são baseados na variação em relação à linha de base, em padrões conhecidos e em notificações provenientes de entidades internas ou externas.
+ Em virtude da natureza imprevisível da tecnologia e das pessoas, que são respectivamente *os meios* e *os agentes* dos incidentes de segurança, as linhas de base se alteram com o tempo. Os padrões anômalos surgem por meio de *táticas*, *técnicas* e *procedimentos* (TTPs) novos ou modificados de agentes de ameaças.
+ As alterações relacionadas a pessoas, tecnologia e processos não são incorporadas imediatamente ao processo de resposta a incidentes. Algumas dessas alterações, inclusive, são descobertas durante o andamento de uma investigação.
# Fontes de alertas
Você deve considerar o uso das seguintes fontes para definir alertas:
+ **Descobertas**: os serviços da AWS, como o [Amazon GuardDuty](https://aws.amazon.com/guardduty/), o [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/), o [Amazon Macie](https://aws.amazon.com/macie/), o [Amazon Inspector](https://aws.amazon.com/inspector/), o [AWS Config](https://aws.amazon.com/config/), o [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) e o [Analisador de Acesso à Rede](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html), geram descobertas que podem ser usadas para criar alertas.
+ **Logs**: os logs de serviços da AWS, infraestrutura e aplicações armazenados em buckets do Amazon S3 e em grupos de logs do CloudWatch podem ser analisados e correlacionados para gerar alertas.
+ **Atividade relacionada ao faturamento**: uma mudança repentina na atividade relacionada ao faturamento pode indicar um evento de segurança. Siga a documentação [Criar um alarme de faturamento para monitorar suas cobranças estimadas da AWS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html) para realizar o monitoramento dessa atividade.
+ **Inteligência de ameaças cibernéticas**: caso você seja assinante de um feed de inteligência de ameaças cibernéticas de entidades externas, é possível realizar a correlação dessas informações com outras ferramentas de registro em log e de monitoramento para identificar possíveis indicadores de eventos.
+ **Ferramentas de parceiros**: os parceiros da AWS Partner Network (APN) oferecem produtos de alto nível que podem ajudar você a atingir seus objetivos de segurança. Para a resposta a incidentes, os produtos de parceiros com funcionalidades de detecção e de resposta em endpoints (EDR, na sigla em inglês) ou de SIEM podem contribuir para o cumprimento dos objetivos de resposta a incidentes. Para obter mais informações, consulte [Soluções de parceiros de competência em segurança](https://aws.amazon.com/security/partner-solutions/) e [Soluções de segurança no AWS Marketplace](https://aws.amazon.com/marketplace/solutions/security).
+ **Confiança e Segurança da AWS**: a equipe de Suporte pode entrar em contato com os clientes caso identifiquemos atividades abusivas ou maliciosas.
+ **Contato único**: como podem ser seus clientes, desenvolvedores ou outros membros da equipe que percebem algo incomum na sua organização, é importante dispor de um método bem divulgado e conhecido para contato com sua equipe de segurança. Entre as opções populares estão sistemas de emissão de tíquetes, endereços de e-mail de contato e formulários na web. Caso sua organização atue com o público em geral, pode ser necessário também dispor de um canal de contato com a segurança voltada ao público externo.
Para obter mais informações sobre as funcionalidades em nuvem que podem ser usadas durante suas investigações, consulte o [Apêndice A: definições das funcionalidades da nuvem](appendix-a-cloud-capability-definitions.md) neste documento.
# Detecção como parte da engenharia de controles de segurança
Os mecanismos de detecção constituem uma parte essencial do desenvolvimento de controles de segurança. À medida que controles *diretivos* e *preventivos* são definidos, controles *detectivos* e *responsivos* correspondentes devem ser elaborados. Para exemplificar, uma organização estabelece um controle diretivo relacionado ao usuário-raiz de uma conta da AWS, o qual deve ser usado somente para atividades específicas e muito bem definidas. Esse controle é associado a um controle preventivo, implementado por meio de uma política de controle de serviços (SCP, na sigla em inglês) da organização da AWS. Se ocorrer uma atividade do usuário-raiz que ultrapassa a linha de base esperada, um controle detectivo, implementado com uma regra do EventBridge e um tópico do SNS, alertará o Security Operations Center (SOC). O controle responsivo envolve o SOC ao selecionar o plano de ação mais apropriado, realizar a análise e trabalhar até que o incidente seja resolvido.
Os controles de segurança são melhor definidos por meio da modelagem de ameaças das workloads executadas na AWS. A criticidade dos controles detectivos será determinada pela análise de impacto nos negócios (BIA, na sigla em inglês) para a workload específica. Os alertas gerados pelos controles detectivos não são tratados à medida que chegam, mas sim com base em sua criticidade inicial, a qual pode ser ajustada durante a análise. A criticidade inicial estabelecida serve como um auxílio para a priorização, no entanto, apenas o contexto em que o alerta ocorreu determinará sua real criticidade. Para exemplificar, uma organização usa o Amazon GuardDuty como um componente do controle detectivo aplicado para as instâncias do EC2 que fazem parte de uma workload. A descoberta `Impact:EC2/SuspiciousDomainRequest.Reputation` é gerada, informando que a instância do Amazon EC2 listada dentro da sua workload está consultando um nome de domínio suspeito de ser malicioso. Esse alerta é configurado por padrão com severidade baixa e, à medida que a fase de análise avança, foi constatado que várias centenas de instâncias do EC2 do tipo `p4d.24xlarge` foram implantadas por um agente não autorizado, aumentando significativamente o custo operacional da organização. Nesse momento, a equipe de resposta a incidentes decide ajustar a criticidade desse alerta para *alta*, aumentando o senso de urgência e agilizando as ações subsequentes. Vale destacar que a severidade da descoberta do GuardDuty não pode ser alterada.
# Implementações de controles detectivos
É importante compreender como os controles detectivos são implementados, pois isso auxilia a determinar como o alerta será usado para o evento específico. Existem duas principais formas de implementação de controles detectivos técnicos:
+ A **detecção comportamental** se baseia em modelos matemáticos, comumente conhecidos como machine learning (ML) ou inteligência artificial (IA). A detecção é realizada por inferência. Portanto, o alerta pode não refletir necessariamente um evento real.
+ A **detecção baseada em regras** é determinística. Dessa forma, os clientes podem definir exatamente os parâmetros das atividades sobre as quais desejam receber alertas, garantindo certeza na detecção.
As implementações modernas de sistemas detectivos, como um sistema de detecção de intrusão (IDS, na sigla em inglês), geralmente incluem ambos os mecanismos. A seguir, apresentamos alguns exemplos de detecções baseadas em regras e comportamentais com o GuardDuty.
+ Quando a descoberta `Exfiltration:IAMUser/AnomalousBehavior` é gerada, ela informa que “uma solicitação de API anômala foi observada em sua conta”. Ao analisar a documentação mais detalhadamente, verifica-se que ela informa que “o modelo de ML avalia todas as solicitações de API na sua conta e identifica eventos anômalos associados a técnicas usadas por agentes adversários”, o que demonstra a natureza comportamental dessa descoberta.
+ Para a descoberta `Impact:S3/MaliciousIPCaller`, o GuardDuty analisa as chamadas de API do serviço Amazon S3 no CloudTrail, comparando o elemento de log `SourceIPAddress` com uma tabela de endereços IP públicos que inclui feeds de inteligência de ameaças. Assim que encontra uma correspondência direta com uma entrada, a descoberta é gerada pelo serviço.
Recomendamos a implementação de uma combinação de alertas comportamentais e baseados em regras, pois nem sempre é possível aplicar alertas baseados em regras para todas as atividades dentro do seu modelo de ameaças.
# Detecção baseada em pessoas
Até o momento, abordamos a detecção baseada em tecnologia. Outra fonte importante de detecção provém de pessoas internas ou externas à organização do cliente. As *pessoas internas* podem ser definidas como um colaborador ou prestador de serviços, e as *pessoas externas* são entidades como pesquisadores que se concentram em segurança, autoridades policiais, meios de comunicação e redes sociais.
Embora a detecção baseada em tecnologia possa ser configurada de forma sistemática, a detecção baseada em pessoas ocorre de diversas formas, como e-mails, tíquetes, correspondências, publicações nos meios de comunicação, telefonemas e interações presenciais. As notificações de detecção tecnológica são geralmente entregues em tempo quase real, enquanto para a detecção baseada em pessoas não há expectativas definidas de prazo. É imprescindível que a cultura de segurança incorpore, facilite e fortaleça os mecanismos de detecção baseados em pessoas, visando uma abordagem de defesa em profundidade para a segurança.
# Resumo
Na detecção, é importante contar com uma combinação de alertas baseados em regras e orientados por comportamento. Além disso, devem existir mecanismos para que pessoas, tanto internas quanto externas, possam registrar tickets sobre questões de segurança. Os seres humanos podem ser uma das fontes mais valiosas para eventos de segurança, por isso é importante ter processos implementados que permitam que as pessoas realizem o encaminhamento de preocupações. É possível usar modelos de ameaças do seu ambiente para começar a desenvolver as detecções. Esses modelos de ameaças ajudarão você a desenvolver alertas baseados nas ameaças mais relevantes para o seu ambiente. Por fim, você pode usar estruturas como o MITRE ATT&CK para compreender as táticas, técnicas e procedimentos (TTPs) dos agentes de ameaças. A estrutura MITRE ATT&CK pode ser útil para servir como uma linguagem comum entre seus diversos mecanismos de detecção.
# Análise
Os logs, as funcionalidades de consulta e a inteligência de ameaças são alguns dos componentes de apoio necessários para a fase de análise. Diversos logs que são usados na fase de detecção também são aproveitados na análise, sendo necessário incorporá-los e configurar as ferramentas de consulta correspondentes.
# Validação, definição de escopo e avaliação do impacto do alerta
Durante a fase de análise, realiza-se uma análise abrangente dos logs com o objetivo de validar os alertas, definir o escopo e avaliar o impacto do possível comprometimento.
+ A *validação* do alerta constitui o ponto de entrada da fase de análise. Os responsáveis pela resposta a incidentes buscarão entradas de log provenientes de diversas fontes e entrarão em contato diretamente com os proprietários da workload afetada.
+ A *definição do escopo* é a etapa seguinte, na qual todos os recursos envolvidos são inventariados e a criticidade do alerta é ajustada após o consenso entre as partes interessadas de que se trata, provavelmente, de um alerta verdadeiro.
+ Por fim, a *análise de impacto* descreve a interrupção real nos negócios.
Uma vez que os componentes da workload afetada forem identificados, os resultados do escopo podem ser correlacionados com o objetivo de ponto de recuperação (RPO) e com o objetivo de tempo de recuperação (RTO) da workload correspondente, ajustando a criticidade do alerta, o que dará início à alocação de recursos e às atividades subsequentes. Não são todos os incidentes que interromperão diretamente as operações de uma workload que fornece suporte a um processo de negócios. Incidentes como a divulgação de dados sensíveis, o roubo de propriedade intelectual ou o sequestro de recursos (como no caso de mineração de criptomoedas) podem não paralisar ou prejudicar imediatamente um processo de negócios, mas podem acarretar consequências em um momento posterior.
# Enriquecimento de logs e de descobertas de segurança
## Enriquecimento com inteligência de ameaças e contexto organizacional
Ao longo da análise, é necessário enriquecer os observáveis de interesse a fim de proporcionar uma contextualização aprimorada do alerta. Conforme exposto na seção Preparação, a integração e o aproveitamento da inteligência de ameaças cibernéticas podem ser benéficos para a obtenção de uma compreensão mais aprofundada da descoberta de segurança. Os serviços de inteligência de ameaças são usados para atribuir reputação e identificar a titularidade de endereços IP públicos, nomes de domínio e hashes de arquivos. Essas ferramentas estão disponíveis por meio de serviços gratuitos ou pagos.
Os clientes que adotam o Amazon Athena como uma ferramenta de consulta de log obtêm a vantagem de usar trabalhos do AWS Glue para carregar informações de inteligência de ameaças como tabelas. As tabelas de inteligência de ameaças podem ser usadas em consultas SQL para correlacionar elementos dos logs, como endereços IP e nomes de domínio, proporcionando uma visão enriquecida dos dados a serem analisados.
A AWS não fornece inteligência de ameaças diretamente aos clientes, mas serviços como o Amazon GuardDuty fazem o uso da inteligência de ameaças para enriquecimento e geração de descobertas. Além disso, é possível fazer o upload de listas personalizadas de ameaças no GuardDuty com base em sua própria inteligência de ameaças.
## Enriquecimento com automação
A automação constitui uma parte essencial da governança na Nuvem AWS. A automação pode ser usada em todas as diversas fases do ciclo de vida da resposta a incidentes.
Na fase de detecção, a automação baseada em regras realiza a combinação de padrões de interesse definidos no modelo de ameaças com os logs e executa ações apropriadas, como o envio de notificações. A fase de análise pode aproveitar esse mecanismo de detecção para encaminhar o conteúdo do alerta a um mecanismo capaz de consultar os logs e enriquecer os observáveis para a contextualização do evento.
O conteúdo do alerta, em sua forma básica, é composto por um *recurso* e por uma *identidade*. Para exemplificar, você poderia implementar uma automação para consultar o CloudTrail sobre a atividade da API da AWS realizada pela identidade ou pelo recurso apresentados no conteúdo do alerta próximo ao momento do alerta, fornecendo informações adicionais como `eventSource`, `eventName`, `SourceIPAddress` e `userAgent` da atividade de API identificada. Ao realizar essas consultas de modo automatizado, os responsáveis pela resposta a incidentes podem economizar tempo durante a triagem e obter contexto adicional para tomar decisões mais bem informadas.
Consulte a publicação do blog [How to enrich AWS Security Hub findings with account metadata](https://aws.amazon.com/blogs/security/how-to-enrich-aws-security-hub-findings-with-account-metadata/) para obter um exemplo de como usar automação no enriquecimento de descobertas de segurança e na simplificação da análise.
# Coleta e análise de evidências forenses
A análise forense, conforme mencionada na seção [Preparação](preparation.md) deste documento, consiste no processo de coleta e de análise de artefatos durante a resposta a incidentes. Na AWS, essa análise se aplica a recursos do domínio de infraestrutura, como capturas de pacotes de tráfego de rede e despejos de memória do sistema operacional, bem como a recursos do domínio de serviços, como os logs do AWS CloudTrail.
As principais características do processo forense são:
+ **Consistência**: adoção rigorosa das etapas documentadas, sem alterações.
+ **Repetibilidade**: capacidade de gerar exatamente os mesmos resultados ao aplicar novamente o processo ao mesmo artefato.
+ **Caráter habitual**: documentado publicamente e amplamente adotado.
É importante manter uma cadeia de custódia dos artefatos coletados durante a resposta a incidentes. O uso de automação e da geração automática de documentação desse processo de coleta podem ser úteis, além do armazenamento dos artefatos em repositórios com permissão somente de leitura. A análise deve ser realizada apenas em réplicas exatas dos artefatos coletados, a fim de preservar sua integridade.
# Coleta de artefatos relevantes
Considerando essas características e com base nos alertas relevantes e na avaliação do impacto e do escopo, será necessário coletar os dados que serão relevantes para as investigações e para as análises posteriores. Diversos tipos e fontes de dados podem ser relevantes para a investigação, incluindo logs do ambiente de gerenciamento e dos serviços (nomeadamente, CloudTrail, eventos de dados do Amazon S3 e fluxo de logs da VPC), dados (por exemplo, metadados e objetos do Amazon S3) e recursos (como bancos de dados e instâncias do Amazon EC2).
Os logs do ambiente de gerenciamento e do serviço podem ser coletados para análise local ou, idealmente, consultados diretamente por meio de serviços nativos da AWS (quando aplicável). Os dados, incluindo metadados, podem ser consultados diretamente para obter informações relevantes ou para adquirir os objetos de origem, por exemplo, usar a AWS CLI CLI para obter metadados do bucket e do objeto do Amazon S3, bem como acessar diretamente os objetos de origem. Os recursos precisam ser coletados de maneira consistente com seu tipo e com o método de análise pretendido. Por exemplo, os bancos de dados podem ser coletados por meio da criação de uma cópia ou de um snapshot do sistema que executa o banco de dados, da cópia ou do snapshot do próprio banco de dados, ou pela consulta e extração de determinados dados e logs relevantes à investigação.
Para instâncias do Amazon EC2, existe um conjunto específico de dados que deve ser coletado e uma ordem definida de coleta que deve ser seguida, a fim de adquirir e preservar a maior quantidade possível de dados para fins de análise e de investigação.
De forma específica, a sequência recomendada de ações para resposta a incidentes, com o objetivo de adquirir e preservar a maior quantidade possível de dados de uma instância do Amazon EC2, é a seguinte:
1. **Adquirir metadados da instância**: adquira os metadados da instância que sejam relevantes para a investigação e para consultas de dados (nomeadamente, ID da instância, tipo, endereço IP, ID da VPC ou da sub-rede, região, ID da imagem de máquina da Amazon [AMI], grupos de segurança associados e horário de inicialização).
1. **Habilitar proteções e etiquetas da instância**: habilite as proteções da instância, como a proteção contra rescisão, configure o comportamento de desligamento para a interrupção (caso esteja definido como encerrar), desabilite os atributos Excluir ao Encerrar dos volumes do EBS anexados e aplique etiquetas apropriadas tanto para identificação visual quanto para utilização em possíveis automações de resposta (por exemplo, ao aplicar uma etiqueta com o nome `Status` e o valor `Quarantine`, realizar a aquisição forense dos dados e isolar a instância).
1. **Adquirir disco (snapshots do EBS)**: adquira um snapshot do EBS dos volumes do EBS anexados. Cada snapshot armazena as informações necessárias para restaurar os dados, a partir do momento em que o snapshot foi criado, em um novo volume do EBS. Consulte a etapa para executar a resposta em tempo real e a coleta do artefato, caso esteja usando volumes do armazenamento de instância.
1. **Adquirir memória**: como os snapshots do EBS capturam somente os dados que foram gravados no volume do Amazon EBS, o que pode excluir dados armazenados ou em cache na memória pelas aplicações ou pelo sistema operacional, é imprescindível adquirir uma imagem da memória do sistema usando uma ferramenta apropriada de uma entidade externa, seja ela de código aberto ou comercial, a fim de obter os dados disponíveis no sistema.
1. **(Opcional) Realizar a coleta da resposta e dos artefatos em tempo real**: realize a coleta direcionada de dados (para disco, memória e logs) por meio da resposta em tempo real no sistema somente se não for possível adquirir o disco ou a memória por outros meios, ou se houver uma justificativa válida de natureza operacional ou comercial. Essa ação modificará dados e artefatos valiosos do sistema.
1. **Descomissionar a instância**: realize o desvinculamento da instância dos grupos do Auto Scaling, cancele o registro da instância nos balanceadores de carga e ajuste ou aplique um perfil de instância definido previamente com permissões reduzidas ou inexistentes.
1. **Isolar ou realizar a contenção da instância**: verifique se a instância está efetivamente isolada de outros sistemas e recursos no ambiente ao realizar o encerramento e evitar conexões atuais e futuras de e para a instância. Consulte a seção [Contenção](containment.md) deste documento para obter mais detalhes.
1. **Opção do responsável pela resposta a incidentes**: com base na situação e nas metas, selecione uma das seguintes opções:
+ Desativar e encerrar o sistema (recomendado).
Encerre o sistema assim que as evidências disponíveis forem adquiridas, a fim de verificar a mitigação mais eficaz contra um possível impacto futuro ao ambiente causado pela instância.
+ Manter a instância em operação em um ambiente isolado com instrumentação para monitoramento.
Embora não seja recomendado como uma abordagem padrão, se uma situação justificar a observação contínua da instância (como quando dados ou indicadores adicionais são necessários para realizar uma investigação e análise abrangentes da instância), você pode considerar encerrar a instância, criar uma AMI da instância e iniciá-la novamente em sua conta dedicada à análise forense, dentro de um ambiente de sandbox que já esteja instrumentado para ser completamente isolado e configurado com instrumentação para facilitar o monitoramento quase contínuo da instância (por exemplo, os logs de fluxo da VPC ou a VPC Traffic Mirroring).
**nota**
É essencial capturar a memória antes das atividades de resposta em tempo real ou do isolamento ou desligamento do sistema, a fim de coletar dados voláteis (e valiosos) disponíveis.
# Desenvolvimento de narrativas
Durante a análise e a investigação, documente as ações executadas, a análise realizada e as informações identificadas, para serem usadas pelas fases subsequentes e, em última instância, em um relatório final. Essas narrativas devem ser concisas e precisas, confirmando que as informações relevantes estão incluídas para verificar a compreensão eficaz do incidente e para manter uma linha do tempo precisa. As narrativas também são úteis quando você envolve pessoas externas à equipe principal de resposta a incidentes. Aqui está um exemplo:
****
*O departamento de marketing e de vendas recebeu uma nota de resgate em 15 de março de 2022, exigindo o pagamento em criptomoeda para evitar a divulgação pública de possíveis dados sensíveis. O SOC determinou que o banco de dados do Amazon RDS pertencente ao departamento de marketing e de vendas estava acessível ao público em 20 de fevereiro de 2022. *O SOC consultou os logs de acesso do RDS e determinou que o endereço IP 198.51.100.23 foi usado em 20 de fevereiro de 2022 com as credenciais `mm03434`, pertencentes à Major Mary*, uma das desenvolvedoras web. Ao analisar os logs de fluxo da VPC, o SOC verificou que aproximadamente 256 MB de dados foram transferidos para o mesmo endereço IP na mesma data (carimbo de horário 2022-02-20T15:50\$100Z). Por meio de inteligência de ameaças de código aberto, o SOC confirmou que as credenciais estão atualmente disponíveis em texto simples no repositório público `https[:]//example[.]com/majormary/rds-utils`.*
# Contenção
No âmbito da resposta a incidentes, uma definição possível para a contenção é o processo ou a implementação de uma estratégia durante o tratamento de um evento de segurança, que atua para minimizar o escopo do evento de segurança e conter os efeitos do uso não autorizado dentro do ambiente.
Uma estratégia de contenção depende de uma infinidade de fatores e pode variar de uma organização para outra quanto à aplicação das táticas de contenção, ao momento de sua execução e ao seu propósito. O guia [NIST SP 800-61 – Computer Security Incident Handling Guide](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) descreve diversos critérios para a determinação da estratégia de contenção apropriada, entre os quais se incluem:
+ Danos potenciais e roubo de recursos.
+ Necessidade da preservação de evidências.
+ Disponibilidade de serviços (como conectividade de rede e serviços prestados a partes externas).
+ Tempo e recursos necessários para implementar a estratégia.
+ Eficácia da estratégia (por exemplo, contenção parcial ou total).
+ Duração da solução (por exemplo, solução de emergência que será removida em quatro horas, solução temporária que será removida em duas semanas ou solução definitiva).
Em relação aos serviços na AWS, no entanto, as etapas essenciais de contenção podem ser resumidas em três categorias principais:
+ **Contenção da origem**: uso de mecanismos de filtragem e de roteamento para restringir o acesso de uma determinada origem.
+ **Contenção de técnica e de acesso**: remoção de acessos para evitar acessos não autorizados aos recursos afetados.
+ **Contenção do destino**: uso de mecanismos de filtragem e de roteamento para restringir o acesso a um recurso de destino.
# Contenção da origem
A contenção da origem consiste no uso e na aplicação de mecanismos de filtragem ou roteamento, dentro de um determinado ambiente, com o objetivo de restringir o acesso a recursos provenientes de um endereço IP de origem ou intervalo de rede específico. A seguir, apresentamos exemplos de contenção da origem com o uso de serviços da AWS:
+ **Grupos de segurança**: a criação e a aplicação de grupos de segurança de isolamento para instâncias do Amazon EC2, ou a remoção de regras de um grupo de segurança existente, pode ajudar na contenção do tráfego não autorizado direcionado a uma instância do Amazon EC2 ou a um recurso da AWS. Vale destacar que conexões existentes, que já estejam sendo rastreadas, não serão interrompidas pela alteração dos grupos de segurança. Apenas o tráfego futuro será efetivamente bloqueado pelo novo grupo de segurança (consulte o [Plano de ação de Resposta a Incidentes](https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Ransom_Response_EC2_Linux.md) e a seção [Rastreamento de conexão de grupo de segurança](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) para obter mais informações sobre as conexões que são rastreadas e as conexões que não rastreadas).
+ **Políticas**: é possível configurar políticas de buckets do Amazon S3 para permitir ou negar tráfego proveniente de um determinado endereço IP, intervalo de rede ou endpoint da VPC. As políticas permitem bloquear endereços suspeitos e restringir o acesso ao bucket do Amazon S3. Você pode encontrar informações adicionais sobre as políticas de bucket em [Adicionar uma política de bucket usando o console do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html).
+ **AWS WAF**: é possível configurar listas de controle de acesso à web (ACLs da web) no AWS WAF para fornecer controle granulado sobre as solicitações web recebidas pelos recursos. Você pode adicionar um endereço IP ou um intervalo de rede a um conjunto de IP configurado no AWS WAF e aplicar condições de correspondência, como bloqueio, ao conjunto de IP. Dessa forma, quaisquer solicitações web serão bloqueadas para um recurso se o endereço IP ou os intervalos de rede provenientes do tráfego de origem corresponderem às regras do conjunto de IP configurado.
Um exemplo de contenção da origem pode ser observado no diagrama apresentado a seguir, no qual um analista responsável pela resposta a incidentes modifica o grupo de segurança de uma instância do Amazon EC2 para restringir novas conexões somente a determinados endereços IP. É importante ressaltar, conforme indicado no tópico sobre grupos de segurança, que conexões existentes, que já estejam sendo rastreadas, não serão interrompidas em decorrência da modificação do grupo de segurança.
![\[Diagrama que mostra um exemplo de contenção de origem\]](http://docs.aws.amazon.com/pt_br/security-ir/latest/userguide/images/source-containment-example.png)
**nota**
Os grupos de segurança e as ACLs da rede não realizam a filtragem do tráfego direcionado ao Amazon Route 53. Dessa maneira, ao realizar a contenção de uma instância do EC2, é necessário garantir o bloqueio explícito das comunicações DNS, caso o objetivo seja restringir o contato com hosts externos.
# Contenção de técnica e de acesso
Restrinja o uso não autorizado de um recurso por meio da limitação das funções e das entidades principais do IAM com acesso ao recurso. Isso inclui restringir as permissões das entidades principais do IAM que têm acesso ao recurso, bem como revogar credenciais de segurança temporárias. A seguir, apresentamos exemplos da contenção de técnica e de acesso com o uso de serviços da AWS:
+ **Restrição de permissões**: as permissões atribuídas a uma entidade principal do IAM devem seguir o [princípio de privilégio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege). No entanto, durante um evento de segurança ativo, pode ser necessário restringir ainda mais o acesso de uma determinada entidade principal do IAM a um recurso específico. Nesse caso, é possível realizar a contenção do acesso ao recurso ao remover as permissões da entidade principal do IAM em questão. Essa ação é executada com o uso do serviço IAM e pode ser aplicada usando o Console de gerenciamento da AWS, a AWS CLI ou um AWS SDK.
+ **Revogação de chaves**: as chaves de acesso do IAM são usadas pelas entidades principais do IAM para fins de acesso ou de gerenciamento de recursos. Estas são credenciais estáticas de longo prazo usadas para assinar solicitações programáticas à AWS CLI ou à API da AWS, e começam com o prefixo *AKIA* (para obter informações adicionais, consulte a seção *Understanding unique ID prefixes* em [Identificadores do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html)). Com a finalidade de conter o acesso de uma entidade principal do IAM cuja chave de acesso tenha sido comprometida, é possível desativar ou excluir a chave de acesso. É importante considerar os seguintes pontos:
+ Uma chave de acesso pode ser reativada após ser desativada.
+ Uma chave de acesso não pode ser recuperada após ser excluída.
+ Uma entidade principal do IAM pode ter, no máximo, duas chaves de acesso ativas simultaneamente.
+ Os usuários ou as aplicações que dependem da chave de acesso perderão acesso imediatamente após sua desativação ou exclusão.
+ **Revogação de credenciais de segurança temporárias**: as credenciais de segurança temporárias podem ser empregadas por uma organização para controlar o acesso a recursos da AWS e começam com o prefixo *ASIA* (para obter informações adicionais, consulte a seção *Understanding unique ID prefixes* em [Identificadores do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html)). As credenciais temporárias são geralmente usadas por perfis do IAM e não necessitam de alteração ou revogação explícita, devido ao seu prazo de validade limitado. Em casos em que ocorra um evento de segurança envolvendo uma credencial de segurança temporária antes da expiração da referida credencial de segurança temporária, pode ser necessário alterar as permissões efetivas das credenciais de segurança temporárias existentes. Essa ação pode ser realizada [por meio do serviço IAM no Console de gerenciamento da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html). As credenciais de segurança temporárias também podem ser emitidas para usuários do IAM (em oposição a perfis do IAM). Entretanto, até o momento da redação desta seção, não existe uma opção para revogar as credenciais de segurança temporárias para um usuário do IAM no Console de gerenciamento da AWS. Para eventos de segurança em que a chave de acesso do IAM de um usuário é comprometida por um usuário não autorizado que criou credenciais de segurança temporárias, as credenciais de segurança temporárias podem ser revogadas usando dois métodos:
+ Realize a anexação de uma política em linha para o usuário do IAM que restrinja o acesso com base no tempo de emissão do token de segurança (consulte a seção *Denying access to temporary security credentials issued before a specific time* em [Desabilitar permissões de credenciais de segurança temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html) para obter mais detalhes).
+ Realize a exclusão do usuário do IAM proprietário das chaves de acesso comprometidas. É possível criar novamente o usuário, se necessário.
+ **AWS WAF**: determinadas técnicas empregadas por usuários não autorizados incluem padrões comuns de tráfego malicioso, como solicitações que contêm injeção de SQL e cross-site scripting (XSS). O AWS WAF pode ser configurado para corresponder e negar esse tipo de tráfego usando as instruções de regras incorporadas do AWS WAF.
Um exemplo de contenção de técnica e de acesso pode ser observado no diagrama apresentado a seguir, no qual um responsável pela resposta a incidentes altera as chaves de acesso ou remove uma política do IAM para impedir que um usuário do IAM acesse um bucket do Amazon S3.
![\[Diagrama que mostra um exemplo de contenção de técnica e de acesso\]](http://docs.aws.amazon.com/pt_br/security-ir/latest/userguide/images/technique-and-access-containment.png)
# Contenção de destino
A contenção de destino refere-se à aplicação de mecanismos de filtragem ou roteamento em um ambiente com o objetivo de restringir o acesso a um host ou recurso de destino. Em alguns casos, a contenção de destino também envolve uma forma de resiliência para verificar se os recursos legítimos estão replicados para garantir disponibilidade. Os recursos devem ser desvinculados dessas formas de resiliência para fins de isolamento e de contenção. Entre os exemplos de contenção de destino com o uso de serviços da AWS, destacam-se:
+ **ACLs da rede**: as listas de controle de acesso à rede (ACLs da rede) configuradas em sub-redes que contêm recursos da AWS podem ter regras de negação adicionadas. Essas regras de negação podem ser aplicadas para restringir o acesso a um recurso da AWS específico. No entanto, aplicar uma lista de controle de acesso à rede (ACL da rede) afetará todos os recursos na sub-rede, e não apenas os recursos que estão sendo acessados sem autorização. As regras listadas em uma ACL da rede são processadas na ordem em que aparecem, de cima para baixo. Por isso, a primeira regra em uma ACL da rede existente deve ser configurada para negar o tráfego não autorizado para o recurso e a sub-rede de destino. Como alternativa, uma nova ACL da rede pode ser criada com uma única regra de negação para tráfego de entrada e saída. Em seguida, essa nova ACL da rede pode ser associada à sub-rede que contém o recurso de destino, restringindo o acesso à sub-rede com o uso da nova ACL da rede.
+ **Encerramento**: o encerramento definitivo de um recurso pode ser eficaz para conter os efeitos do uso não autorizado. No entanto, o encerramento um recurso também impedirá o acesso legítimo para as necessidades do negócio e prejudicará a obtenção de dados forenses voláteis. Portanto, essa deve ser uma decisão intencional e deve ser avaliada em relação às políticas de segurança de uma organização.
+ **VPCs de isolamento**: as VPCs de isolamento podem ser usadas para a contenção de recursos de forma eficaz, enquanto ainda permitem o acesso de tráfego legítimo (por exemplo, soluções de antivírus [AV] ou endpoints de detecção e de resposta [EDR] que precisam de acesso à internet ou a um console de gerenciamento externo). As VPCs de isolamento podem ser configuradas previamente antes de um evento de segurança para permitir endereços IP e portas válidos. Durante um incidente de segurança ativo, os recursos de destino podem ser movidos imediatamente para essa VPC de isolamento, com a finalidade de realizar a contenção do recurso enquanto ainda permite que o tráfego legítimo seja enviado e recebido pelo recurso de destino durante as fases subsequentes da resposta ao incidente. Um aspecto importante relacionado ao uso de uma VPC de isolamento é que os recursos, como as instâncias do EC2, precisam ser encerrados e inicializados novamente na nova VPC de isolamento antes do uso. As instâncias do EC2 existentes não podem ser movidas para outra VPC ou outra zona de disponibilidade. Para executar essa ação, siga as etapas descritas em [Como mover minha instância do Amazon EC2 para outra sub-rede, zona de disponibilidade ou VPC?](https://aws.amazon.com/premiumsupport/knowledge-center/move-ec2-instance/).
+ **Grupos do Auto Scaling e balanceadores de carga**: os recursos do AWS anexados a grupos do Auto Scaling e balanceadores de carga devem ser desanexados e removidos do registro como parte dos procedimentos de contenção de destino. A desanexação e a remoção do registro de recursos da AWS podem ser realizadas usando o Console de gerenciamento da AWS, a AWS CLI e o AWS SDK.
Um exemplo de contenção de destino é demonstrado no diagrama apresentado a seguir, em que um analista responsável pela resposta a incidentes adiciona uma ACL da rede para uma sub-rede com a finalidade de bloquear uma solicitação de conexão de rede proveniente de um host não autorizado.
![\[Diagrama que mostra um exemplo de contenção de destino\]](http://docs.aws.amazon.com/pt_br/security-ir/latest/userguide/images/destination-containment.png)
# Resumo
A contenção consiste em uma etapa do processo de resposta a incidentes e pode ser manual ou automatizada. A estratégia geral de contenção deve estar alinhada com as políticas de segurança e as necessidades de negócios de uma organização, além de verificar se os efeitos negativos são mitigados o mais eficientemente possível antes da erradicação e da recuperação.
# Erradicação
A erradicação, no contexto da resposta a incidentes de segurança, corresponde à remoção de recursos suspeitos ou não autorizados em um esforço para retornar a conta a um estado seguro conhecido. A estratégia de erradicação depende de diversos fatores, que, por sua vez, dependem dos requisitos de negócios da sua organização.
O guia [NIST SP 800-61 Computer Security Incident Handling Guide](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) estabelece diversas etapas para a erradicação:
1. Identificar e mitigar todas as vulnerabilidades que foram exploradas.
1. Remover malwares, materiais impróprios e outros componentes.
1. Caso mais hosts afetados sejam descobertos (por exemplo, novas infecções por malware), repetir as etapas de detecção e de análise para identificar todos os outros hosts afetados, e, em seguida, realizar a contenção e a erradicação do incidente para esses hosts.
Para os recursos da AWS, essas etapas podem ser ainda mais aprimoradas por meio dos eventos detectados e analisados em logs disponíveis ou das ferramentas automatizadas, como o CloudWatch Logs e o Amazon GuardDuty. Esses eventos devem ser a base para determinar quais remediações devem ser realizadas para restaurar adequadamente o ambiente a um estado seguro conhecido.
A primeira etapa da erradicação consiste em determinar quais recursos foram afetados na sua conta da AWS. Isso é realizado por meio da análise das fontes de dados de log, dos recursos e das ferramentas automatizadas disponíveis.
+ Identifique ações não autorizadas executadas pelas identidades do IAM na sua conta.
+ Identifique acessos ou alterações não autorizadas na sua conta.
+ Identifique a criação de recursos ou de usuários do IAM não autorizadas.
+ Identifique sistemas ou recursos com alterações não autorizadas.
Após identificar a lista de recursos, você deve avaliar cada um dos recursos para determinar o impacto nos negócios caso o recurso seja excluído ou restaurado. Para exemplificar, se um servidor web está hospedando sua aplicação de negócios e a exclusão dele causaria tempo de inatividade, então você deve considerar recuperar o recurso de backups seguros verificados ou inicializar novamente o sistema usando uma AMI íntegra antes de excluir o servidor impactado.
Após concluir a análise de impacto nos negócios, usando os eventos da análise de logs, você deve acessar as contas e realizar as remediações apropriadas, tais como:
+ Alterar ou excluir as chaves, pois essa etapa remove a capacidade do agente de continuar realizando atividades dentro da conta.
+ Alterar as credenciais de usuários do IAM que possam estar não autorizadas.
+ Excluir recursos não reconhecidos ou não autorizados.
**Importante**
Se você tiver a necessidade de manter recursos para sua investigação, considere fazer um backup desses recursos. Por exemplo, se for necessário reter uma instância do Amazon EC2 por razões regulatórias, de conformidade ou legais, [crie um snapshot do Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html) antes de remover a instância.
+ No caso de infecções por malware, talvez seja necessário entrar em contato com um parceiro da AWS Partner ou com outro fornecedor. A AWS não disponibiliza ferramentas nativas para análise ou remoção de malware. No entanto, se você estiver usando o módulo Proteção contra Malware do GuardDuty para o Amazon EBS, recomendações podem estar disponíveis para as descobertas fornecidas.
Após erradicar os recursos afetados identificados, a AWS recomenda que você realize uma análise de segurança da sua conta. Isso pode ser feito usando regras do AWS Config ou soluções de código aberto, como Prowler e ScoutSuite, ou por meio de outros fornecedores. Você também deve considerar a realização de verificações de vulnerabilidade em seus recursos voltados para o público e expostos à internet para avaliar o risco residual.
A erradicação consiste em uma das etapas do processo de resposta a incidentes e pode ser manual ou automatizada, dependendo do incidente e dos recursos afetados. A estratégia geral deve estar alinhada com as políticas de segurança e com as necessidades de negócios de uma organização, e verificar se os efeitos negativos são mitigados à medida que recursos ou configurações inapropriados são removidos.
# Recuperação
A recuperação é o processo de restaurar sistemas a um estado seguro conhecido, validar que os backups estão seguros ou não foram afetados pelo incidente antes da restauração, realizar testes para verificar se os sistemas estão funcionando corretamente após a restauração e abordar as vulnerabilidades associadas ao evento de segurança.
A ordem de recuperação depende dos requisitos da sua organização. Como parte do processo de recuperação, você deve realizar uma análise de impacto nos negócios para determinar, no mínimo:
+ Prioridades de negócios ou de dependências
+ Plano de restauração
+ Autenticação e autorização
O guia NIST SP 800-61 Computer Security Incident Handling Guide estabelece diversas etapas para a recuperação de sistemas, incluindo:
+ Restauração de sistemas usando backups íntegros.
+ Verifique se os backups são avaliados antes da restauração para os sistemas, a fim de garantir que a infecção não esteja presente e evitar um ressurgimento do evento de segurança.
Os backups devem ser avaliados regularmente como parte dos testes de recuperação de desastres, para verificar se o mecanismo de backup está funcionando corretamente e se a integridade dos dados atende aos objetivos de ponto de recuperação.
+ Se possível, use backups anteriores ao primeiro carimbo de data e horário do evento identificado como parte da análise da causa-raiz.
+ Reconstrução de sistemas do zero, o que inclui a reimplantações a partir de uma fonte confiável usando automação, às vezes em uma nova conta da AWS.
+ Substituição de arquivos comprometidos por versões íntegras.
Você deve ter extremo cuidado ao executar essa ação. É necessário ter certeza absoluta de que o arquivo que está recuperando é reconhecidamente seguro e não foi afetado pelo incidente.
+ Instalação de patches.
+ Alteração de senhas.
+ Isso inclui senhas para entidades principais do IAM que podem ter sido usadas indevidamente.
+ Se possível, recomendamos usar perfis para entidades principais do IAM e para federação como parte de uma estratégia de privilégio mínimo.
+ Reforço da segurança do perímetro da rede (por exemplo, com conjuntos de regras de firewall e listas de controle de acesso de roteadores de borda).
Depois que os recursos forem recuperados, é importante registrar as lições aprendidas para atualizar as políticas, os procedimentos e os guias de resposta a incidentes.
Em resumo, é imprescindível implementar um processo de recuperação que facilite o retorno às operações seguras conhecidas. A recuperação pode demorar um longo tempo e requerer uma ligação estreita com as estratégias de contenção para equilibrar o impacto nos negócios com o risco de reinfecção. Os procedimentos de recuperação devem incluir etapas para a restauração de recursos, serviços e entidades principais do IAM, e a realização de uma análise de segurança da conta para avaliar o risco residual.
# Conclusão
Cada fase operacional apresenta metas, técnicas, metodologias e estratégias específicas. A Tabela 4 fornece um resumo dessas fases e de algumas das técnicas e das metodologias abordadas nesta seção.
*Tabela 4: fases operacionais: metas, técnicas e metodologias*
| Fase | Objetivo | Técnicas e metodologias |
| --- | --- | --- |
| Detecção | Identifique um possível evento de segurança. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/security-ir/latest/userguide/operations-conclusion.html) |
| Análise | Determinar se o evento de segurança constitui um incidente e avaliar o escopo do incidente. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/security-ir/latest/userguide/operations-conclusion.html) |
| Contenção | Minimizar e limitar o impacto do evento de segurança. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/security-ir/latest/userguide/operations-conclusion.html) |
| Erradicação | Remova recursos ou artefatos não autorizados relacionados ao evento de segurança. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/security-ir/latest/userguide/operations-conclusion.html) |
| Recuperação | Restaurar os sistemas para um estado conhecido como íntegro e monitorá-los para garantir que a ameaça não retorne. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/security-ir/latest/userguide/operations-conclusion.html) |