Validação da sua configuração AWS Security Incident Response
Após concluir a integração, você poderá verificar se a inscrição, as fontes de detecção, as permissões do AWS Identity and Access Management (IAM), a contenção e as notificações estão configuradas corretamente antes que ocorra um evento de segurança real. Esta seção apresenta procedimentos de verificação passo a passo, utilizando tanto o AWS Management Console quanto a AWS CLI.
Tópicos
Antes da validação
Pré-requisitos para validar sua configuração de Resposta a Incidentes de Segurança
Para concluir essas etapas de validação, certifique-se de que você tenha o seguinte:
Acesso via console ou AWS Command Line Interface (AWS CLI) à sua conta de administrador delegado (designada durante o onboarding)
A Região da AWS em que ativou sua assinatura
Sua ID de membro (se estiver validando com a AWS CLI)
Confirmar a prontidão de logs
O AWS Security Incident Response não habilita fontes de log em seu nome. Durante uma investigação, os engenheiros dependem de logs já presentes no seu ambiente. Antes de validar a configuração, confirme se os logs a seguir estão habilitados em todas as contas e Regiões da AWS cobertas. Sem esses logs, os engenheiros de Resposta a Incidentes de Segurança têm visibilidade limitada durante as investigações. Habilite-os antes de continuar.
AWS CloudTrail: trilha de eventos de gerenciamento (necessária)
Logs de fluxo da Amazon VPC (recomendados)
Registro em log de acesso ao servidor do Amazon S3 para buckets sensíveis (recomendado)
Registro em log de consultas ao DNS do Amazon Route 53 Resolver (recomendado)
Verificar se o GuardDuty está habilitado
Use o comando a seguir para verificar se o Amazon GuardDuty está ativo nas suas contas:
aws guardduty list-detectors
Uma resposta não vazia confirma que o GuardDuty está habilitado na Região da AWS atual. Repita essa etapa para cada região ativa ou verifique em toda a sua organização por meio da conta de administrador delegado do GuardDuty.
nota
Os custos do AWS Security Incident Response não incluem os custos de uso do GuardDuty. Consulte a página de preços do GuardDuty
Etapa 1: verificar o cadastro e a associação
Usar o console de AWS Security Incident Response
Faça login na conta do administrador delegado.
Confirme se seu status de associação mostra Ativo. O status Pendente indica que o onboarding está incompleto.
Em Escopo da conta, verifique se as UOs que você pretendia abranger estão listadas. A cobertura é selecionada no nível da unidade organizacional (UO), não no nível da conta individual. Todas as contas dentro de uma UO selecionada (incluindo as UOs subordinadas) estão incluídas.
Confirme se a Região listada corresponde ao local em que suas workloads são executadas. A seleção da região é bloqueada na ocasião do registro e não pode ser alterada após a configuração.
Como usar o AWS CLI
Execute o seguinte comando a partir da sua conta de administrador delegado:
aws security-ir list-memberships
O comando anterior retorna seu ID de associado e seu status.
Para obter todos os detalhes da assinatura, incluindo a configuração da sua equipe de resposta a incidentes, execute o seguinte comando:
aws security-ir get-membership --membership-idmembership-id
Use a saída do comando para verificar as seguintes informações.
O status da associação é
ActiveOs membros da equipe de resposta a incidentes listados correspondem às partes interessadas que você pretende incluir
Estão configurados pelo menos dois membros da equipe de resposta a incidentes (necessário)
Verificar o administrador delegado
Para confirmar se a conta correta está registrada como administrador delegado para Resposta a Incidentes de Segurança, execute o seguinte comando:
aws organizations list-delegated-administrators \ --service-principal security-ir.amazonaws.com
nota
Prática recomendada: use a mesma conta de administrador delegado definida para outros serviços de segurança da AWS (como o AWS Security Hub CSPM e o GuardDuty). A Arquitetura de Referência de Segurança da AWS recomenda o uso da conta do Security Tooling.
Etapa 2: verificar as fontes de detecção e realizar a triagem
O AWS Security Incident Response monitora as descobertas de segurança do GuardDuty e de ferramentas de terceiros por meio do Security Hub CSPM. O serviço utiliza um Perfil vinculado ao serviço para coletar descobertas por meio de regras do Amazon EventBridge realizadas na implantação em suas contas durante o processo de integração.
Verifique o Perfil vinculado ao serviço Triage
O Perfil vinculado ao serviço AWSServiceRoleForSecurityIncidentResponse_Triage deve existir na sua conta gerencial e em todas as contas de membros com escopo.
Para verificar, execute o seguinte comando nas contas gerenciais e nas contas de membros incluídas no escopo:
aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse_Triage
Uma resposta com êxito confirma que o perfil existe. Se você receber uma mensagem de erro NoSuchEntity, execute uma das seguintes ações:
Se você realizou a integração usando o console: o perfil deveria ter sido criado automaticamente. Entrar em contato com o AWS Support.
Se você se cadastrou usando a API ou AWS CLI: Consulte Habilite a Resposta a Incidentes de Segurança usando a API/CLI para obter instruções sobre como criar manualmente o perfil.
Verificar o perfil vinculado ao serviço
O perfil AWSServiceRoleForSecurityIncidentResponse também deve existir na sua conta de administrador delegado. Para verificar se o perfil existe, execute o seguinte comando:
aws iam get-role --role-name AWSServiceRoleForSecurityIncidentResponse
Verificar a resposta proativa e as regras do EventBridge
No console do AWS Security Incident Response, confirme se Resposta proativa aparece como habilitada. Quando habilitado, o serviço faz o seguinte:
Incorpora as descobertas do GuardDuty e do Security Hub CSPM por meio de regras do EventBridge
Classifica automaticamente as descobertas com base no contexto específico do cliente (IPs conhecidos, entidades do IAM esperadas)
Cria casos de investigação proativa quando são identificadas falhas de segurança confirmadas
As descobertas do GuardDuty arquivadas foram consideradas benignas (podem ser visualizadas no console do GuardDuty, na seção Descobertas arquivadas)
Verificar a implantação das regras do EventBridge em contas de membros
Para verificar a implantação de regras do EventBridge em contas de membros, siga as próximas etapas.
Abra o console do Amazon EventBridge em uma conta de membro coberta.
Escolha Regras.
Confirme se as regras com
SecurityIncidentResponseno nome estão presentes e habilitadas.
Se as regras estiverem ausentes, execute novamente a configuração de resposta proativa no console do Serviço de Resposta a Incidentes de Segurança ou entre em contato com o AWS Support.
Verifique as integrações de terceiros (se aplicável)
Se você utilizar ferramentas de detecção de terceiros (como o CrowdStrike Falcon, o Trend Micro Cloud One ou o Fortinet Lacework FortiCNAPP), verifique se as descobertas dessas ferramentas estão sendo transmitidas ao Security Hub CSPM:
Abra o console do AWS Security Hub CSPM
. Acesse Integrações.
Confirme se a integração com o fornecedor terceirizado aparece como Aceitando descobertas.
nota
Você não precisa habilitar os padrões ou controles do Security Hub CSPM. Apenas as integrações com fornecedores são necessárias para que o Sistema de Resposta a Incidentes de Segurança possa incorporar as descobertas de terceiros.
Etapa 3: verificar o pipeline automatizado de descobertas
Esta etapa confirma que o pipeline do EventBridge está ativo e que as descobertas estão chegando à triagem automatizada.
Sobre amostras de descobertas do GuardDuty
O recurso incorporado Gerar amostras de descobertas do GuardDuty produz descobertas marcadas como amostras. A triagem automatizada filtra amostras de descobertas para evitar ruído; essas descobertas não passam por todo o pipelin de triagem e não podem ser usadas para validar sua configuração de Resposta a Incidentes de Segurança. Não as use para esta etapa.
Validar com o domínio de teste do GuardDuty
A documentação do GuardDuty fornece um domínio de teste (guarddutyc2activityb.com) que gera uma descoberta real sem a necessidade de eventos de segurança reais. A consulta a esse domínio a partir de uma instância do Amazon EC2 em uma conta coberta gera uma descoberta que o Serviço de Resposta a Incidentes de Segurança coleta e processa.
Para gerar uma descoberta de teste:
Conecte-se a uma instância do Amazon EC2 em uma conta coberta usando o Systems Manager Session Manager ou o SSH.
-
Execute o seguinte comando:
dig guarddutyc2activityb.com Abra o console do GuardDuty e escolha Descobertas. A descoberta aparece em cerca de 5 minutos.
O que esperar:
A triagem automatizada analisa a descoberta e determina que ela não é indício de um evento de segurança real.
A descoberta é arquivada no GuardDuty. Para visualizá-la, selecione Arquivadas no filtro Status.
Se você usa o Security Hub CSPM, o status do fluxo de trabalho da descoberta muda para
SUPPRESSED.Nenhum caso proativo é criado: este é o comportamento correto. Um caso somente é aberto quando a triagem automatizada identifica uma atividade que justifique uma investigação por parte de um profissional.
nota
Se a descoberta do teste não aparecer na lista arquivada do GuardDuty em até 15 minutos, consulte Solução de problemas. Se não houver nenhuma instância do Amazon EC2 disponível, passe para a Etapa 4 e retome este teste quando seu ambiente estiver pronto.
Etapa 4: verificar as notificações e a equipe de resposta a incidentes
Verificar sua equipe de resposta a incidentes
No console do Serviço de Resposta a Incidentes de Segurança, verifique os membros da equipe de resposta a incidentes que você configurou. Cada membro recebe notificações imediatas por e-mail quando um caso é criado.
Ou execute o comando a seguir para verificar usando a AWS CLI:
aws security-ir get-membership --membership-idmembership-id
Confirme que:
Todas as partes interessadas previstas estão listadas
Os endereços de e-mail estão corretos
As preferências de comunicação de cada membro estão configuradas corretamente (todas as opções de comunicação estão habilitadas por padrão — se um membro não estiver recebendo notificações, verifique se suas preferências não foram desativadas)
Entendendo observadores de casos
Observadores de casos são partes interessadas às quais é concedido acesso para visualizar um caso específico. Detalhes principais:
Os observadores são por caso, e não por conta. Adicionar um observador a um caso não concede a esse observador acesso a nenhum outro caso. É necessário adicionar explicitamente os observadores a cada caso em que se deseja que eles tenham visibilidade.
Observadores têm acesso somente para visualização. Eles podem visualizar os detalhes dos casos e receber notificações sobre atualizações dos mesmos, mas não podem realizar ações de contenção ou correção nos recursos.
Até 30 partes interessadas podem ser adicionadas por caso individual.
Cada caso inclui uma política de IAM com escopo pré-definido que concede acesso apenas a esse caso específico, mantendo o princípio do privilégio mínimo.
Essa definição do escopo caso a caso é particularmente importante ao conceder acesso a terceiros, como parceiros de detecção e resposta gerenciadas (MDR) ou equipes de investigação independentes, que devem ter acesso apenas ao caso específico no qual estão envolvidos.
Verificar o envio de notificações por meio de um caso de teste
A maneira mais eficaz de validar o fluxo de notificação de ponta a ponta é criar um caso de teste reativo (autogerenciado):
No console do Serviço de Resposta a Incidentes de Segurança, crie um novo caso autogerenciado.
No título e na descrição do caso, indique claramente: "Este é um teste de validação de configuração; não há um evento de segurança real."
Verifique se todos os membros da equipe de resposta a incidentes configurados recebem a notificação por e-mail.
Encerre o caso após confirmar que as notificações foram recebidas.
Importante
A criação de um caso de teste pode ser um gatilho para uma resposta dos engenheiros do Serviço de Resposta a Incidentes de Segurança caso você solicite um engajamento com suporte pela AWS. Indique claramente que se trata de um teste para evitar escalonamentos desnecessários. Siga esta etapa uma vez para confirmar se o canal está funcionando e, em seguida, encerre o caso imediatamente.
O que esperar das notificações de casos
Quando um caso é criado (seja de forma proativa pelo serviço ou reativa pela sua equipe), todos os membros configurados da equipe de resposta a incidentes recebem uma notificação por e-mail contendo os detalhes do caso.
Verificar a integração com o EventBridge (se estiver configurada)
Se você configurou o EventBridge para encaminhar eventos de casos para plataformas de terceiros (como ServiceNow, Jira, Slack ou PagerDuty), verifique se o seu caso de teste gera o gatilho da notificação esperada nesses sistemas.
Etapa 5: verificar a prontidão de contenção (opcional)
nota
A contenção é opcional e não está habilitada por padrão. A infraestrutura de contenção descrita nesta seção só é necessária caso você opte por habilitar a contenção; ela não é necessária para que o Serviço de Resposta a Incidentes de Segurança monitore seu ambiente, investigue as descobertas ou abra casos.
Se você não tiver habilitado a contenção
Nada para validar aqui. O Serviço de Resposta a Incidentes de Segurança oferece orientação e investigação durante eventos de segurança, mas não realiza ações automatizadas de contenção, a menos que você as autorize explicitamente.
Se você tiver habilitado a contenção
Verifique o status da contenção no console. Verifique se as ações de contenção aparecem como Autorizadas. As ações de contenção oferecidas incluem runbooks para:
Buckets do Amazon S3 afetados
Instâncias do Amazon EC2 afetadas
Entidades principais do IAM afetadas
Verifique se o StackSet do CloudFormation está implantado. A contenção requer perfis do IAM (AWSSecurityIncidentResponseContainment e AWSSecurityIncidentResponseContainmentExecution) em suas contas cobertas:
Abra o AWS CloudFormation na sua conta gerencial.
Escolha StackSets.
Confirme se o StackSet de contenção do Serviço de Resposta a Incidentes de Segurança mostra
SUCCEEDEDem todas as contas de destino.
Se o StackSet não estiver implantado, a autorização de contenção no console não resultará na execução de ações efetivas de contenção.
Confirme sua preferência de contenção. O Serviço de Resposta a Incidentes de Segurança oferece três níveis de contenção:
Aprovação necessária (padrão): nenhuma ação de contenção será realizada sem sua autorização explícita, caso a caso.
Conter confirmados: contenção proativa dos recursos confirmados como afetados.
Conter suspeitos: contenção proativa dos recursos com alta probabilidade de serem afetados.
Para enviar ou atualizar sua preferência, crie um caso do AWS Support do tipo Técnico: Serviço de Resposta a Incidentes de Segurança / Outros.
Se quiser usar o EC2 Triage: implante o modelo Contenção com o EC2 Triage do CloudFormation. Isso permite que os engenheiros do Serviço de Resposta a Incidentes de Segurança coletem dados de investigação de instâncias do Amazon EC2 usando o AWS Systems Manager.
Etapa 6: confirmar a operação contínua
Após concluir a validação inicial, utilize esses indicadores para confirmar se o Serviço de Resposta a Incidentes de Segurança está operando continuamente conforme o esperado.
A ausência de casos é normal
O Serviço de Resposta a Incidentes de Segurança cria um caso proativo somente quando a triagem automatizada identifica uma atividade que justifique uma investigação humana. Quando a triagem determina que uma descoberta é benigna, ela a arquiva sem criar um caso nem entrar em contato com sua equipe. Uma implantação sem casos em aberto e com um fluxo consistente de descobertas arquivadas do GuardDuty está operando conforme o esperado.
Se você não encontrar nenhum caso nem descobertas arquivadas após seu ambiente estar ativo há vários dias, é possível que o pipeline não esteja conectado; verifique as etapas 2 e 3.
nota
Os casos proativos que não receberem resposta do cliente por 5 dias são encerrados automaticamente.
Descobertas arquivadas e regras de supressão como indicadores de integridade
À medida que o Serviço de Resposta a Incidentes de Segurança analisa as descobertas ao longo do tempo, ela gera dois artefatos observáveis:
Descobertas arquivadas: descobertas que a triagem automatizada classificou como benignas. Esses itens se acumulam ao longo do tempo e podem ser visualizados no console do GuardDuty, na seção Descobertas; em seguida, selecione Arquivadas.
Regras de supressão do GuardDuty: para tipos de descobertas confirmados como atividade esperada no seu ambiente, o Serviço de Resposta a Incidentes de Segurança implanta regras de supressão nomeadas (prefixadas com
SIRTriage-). Esses são os sinais mais evidentes de que a triagem automatizada está funcionando efetivamente. Visualize-as no console do GuardDuty em Regras de supressão.
Sua equipe de resposta a incidentes é notificada quando uma regra de supressão é criada. Se uma regra tiver sido criada por engano, entre em contato com o AWS Support para solicitar a reversão. As descobertas arquivadas são mantidas no GuardDuty por 90 dias.
Relatório mensal de atividades
O Serviço de Resposta a Incidentes de Segurança envia um relatório mensal de atividades à sua equipe de resposta a incidentes, resumindo as descobertas processadas, os resultados da triagem e quaisquer casos que tenham sido abertos. Se sua equipe não tiver recebido um relatório após o primeiro mês completo de operação, verifique se os membros da equipe de resposta a incidentes tiveram as opções de comunicação habilitadas. Para quaisquer outras questões relacionadas ao relatório mensal, entre em contato com sua equipe de contas ou abra um caso de suporte do tipo: Técnico: Serviço de Resposta a Incidentes de Segurança / Outros e inclua as seguintes informações:
Nome da sua organização
O mês/ano de referência que você esperava (por exemplo, “maio de 2026”)
Seu ID de associação ao Serviço de Resposta a Incidentes de Segurança, se conhecido
Os IDs de conta abrangidos pela sua associação ao Serviço de Resposta a Incidentes de Segurança
O que esperar dos engenheiros do Security Incident Response
Quando você cria um caso compatível com a AWS ou quando o próprio serviço cria um de forma proativa, os engenheiros do Serviço de Resposta a Incidentes de Segurança confirmam o recebimento dos novos casos em até 15 minutos. Este SLO de reconhecimento de 15 minutos se aplica a todos os tipos de casos com suporte pela AWS, tanto eventos de segurança ativos quanto investigações. A confirmação inicial indica que seu caso está sendo analisado; o prazo total para a avaliação pode variar de acordo com a gravidade e a complexidade do caso.
No caso de casos proativos (criados automaticamente quando o serviço de triagem identifica um problema de segurança confirmado), o serviço cria o caso após a triagem automatizada confirmar o problema, e sua equipe de resposta a incidentes é notificada quando o caso é aberto.
Lista de verificação de validação
Use esta lista de verificação para confirmar se sua configuração está completa:
Fontes de log habilitadas: eventos de gerenciamento do CloudTrail (necessários), Logs de fluxo da Amazon VPC, registro em log de acesso ao Amazon S3, registro em log de consultas ao DNS (recomendado)
O GuardDuty está habilitado em todas as contas e regiões ativas
O status de associação é Ativo no console do Serviço de Resposta a Incidentes de Segurança
A região está correta (bloqueada na ocasião do registro)
A conta do administrador delegado está correta (recomenda-se a conta do Security Tooling)
O escopo da conta abrange as UOs pretendidas
AWSServiceRoleForSecurityIncidentResponse_Triageexiste na conta gerencialAWSServiceRoleForSecurityIncidentResponse_Triageexiste em contas de membros dentro do escopoAWSServiceRoleForSecurityIncidentResponseexiste na conta de administrador delegadoAs integrações de terceiros (se aplicáveis) aparecem como aceitando descobertas no Security Hub CSPM
Regras do EventBridge com
SecurityIncidentResponseno nome estão presentes e habilitadas nas contas de membrosOs membros da equipe de resposta a incidentes estão configurados com as informações de contato corretas e com os meios de comunicação habilitados
Caso de teste criado e notificações por e-mail recebidas por todos os membros da equipe
Descoberta de domínios de teste (
guarddutyc2activityb.com) arquivado em até 15 minutosO StackSet de contenção foi implantado com êxito (se a contenção estiver habilitada)
Preferência de contenção enviada (se a contenção estiver habilitada)
As integrações do EventBridge (se configuradas) estão enviando eventos para plataformas de terceiros
Descobertas arquivadas visíveis no GuardDuty após a primeira semana de operação
Verificação de faturamento
Clientes do Enterprise Support e das Operações Unificadas: O Serviço de Resposta a Incidentes de Segurança está incluído, sem custo adicional, como parte do seu plano de suporte. Você não vê as cobranças relacionadas ao Serviço de Resposta a Incidentes de Segurança no Explorador de Custos do AWS nem no Relatório de Custos e Uso da AWS.
Todos os demais clientes: o preço é baseado no número de descobertas de segurança detectadas. As primeiras 10.000 descobertas por mês são gratuitas. Para obter detalhes, consulte Definição de preço do AWS Security Incident Response
Solução de problemas
| Sintomas | Causa provável | Resolução |
|---|---|---|
| O status da associação é “Pendente” | Onboarding não concluído | Conclua todas as etapas de configuração. Consulte Introdução ao . |
list-memberships retorna vazio |
A região da CLI não corresponde à região da assinatura | Especifique a região onde você ativou: --region |
| SLR de triagem não encontrado na conta gerencial | Incorporado via API/CLI sem criá-lo | Criar manualmente: aws iam create-service-linked-role --aws-service-name "triage.security-ir.amazonaws.com" |
| Contas de membros que não constam na cobertura | SLR não implantado na conta do membro | Execute novamente a configuração da resposta proativa a partir do console do Serviço de Resposta a Incidentes de Segurança |
| As regras do EventBridge não estão presentes em uma conta | Configuração de resposta proativa incompleta | Execute novamente a configuração ou verifique se há falhas do StackSet no CloudFormation |
| Amostras de descobertas do GuardDuty não processadas | Os resultados da amostra são filtrados por triagem automatizada (esperado) | Verificar descobertas arquivadas no GuardDuty |
| A descoberta do domínio de teste não foi arquivada após 15 minutos | Regras do EventBridge ausentes ou desabilitadas; GuardDuty não habilitado | Verifique as etapas 2 e 3 |
| Nenhum caso após um longo período | Todas as descobertas arquivadas por triagem (esperado) ou pipeline não conectado | Verifique as descobertas arquivadas no GuardDuty. Se não houver nenhuma, verifique as regras e a resposta proativa do EventBridge. |
| Nenhuma descoberta do GuardDuty está sendo triada | O GuardDuty não está ativado ou não está gerando descobertas | Verifique se o GuardDuty está habilitado: aws guardduty list-detectors |
| O serviço não está processando descobertas | A triagem automatizada determinou que a atividade detectada é esperada | Analise as descobertas Arquivadas do GuardDuty e as descobertas SUPPRESSED do Security Hub CSPM |
| Membros da equipe que não estão recebendo notificações | E-mail incorreto, comunicações desabilitadas ou e-mail em spam | Verifique os endereços de e-mail e as preferências de comunicação; verifique as pastas de spam |
| Ações de contenção não estão sendo executadas | StackSet não implantado ou preferência não enviada | Verifique o status do StackSet no CloudFormation e confirme a preferência enviada via AWS Support |
Recursos relacionados
