# Detecção 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 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 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 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 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 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.