As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Exemplos de triagem e remediação de descobertas de segurança
Esta seção fornece exemplos do processo de triagem para as equipes de segurança, nuvem e aplicações. Ela analisa os tipos de descobertas que cada equipe geralmente resolve e fornece um exemplo de como responder. Orientações de remediação de alto nível também estão incluídas.
**Topics**
+ [Exemplo de equipe de segurança: criação de uma regra de automação CSPM do Security Hub](security-team-example.md)
+ [Exemplo de equipe da nuvem: alteração das configurações da VPC](cloud-team-example.md)
+ [Exemplo de equipe de aplicativos: criação de uma AWS Config regra](application-team-example.md)
# Exemplo de equipe de segurança: criação de uma regra de automação CSPM do Security Hub
A equipe de segurança recebe descobertas relacionadas à detecção de ameaças, incluindo GuardDuty descobertas da Amazon. Para obter uma lista completa dos tipos de GuardDuty descoberta que são categorizados por tipo de AWS recurso, consulte [Tipos de busca](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) na GuardDuty documentação. As equipes de segurança devem estar familiarizadas com todos esses tipos de descobertas.
Neste exemplo, a equipe de segurança está aceitando o nível de risco associado às descobertas de segurança em um Conta da AWS documento que é usado estritamente para fins de aprendizado e não inclui dados importantes ou confidenciais. O nome dessa conta é `sandbox`, e o ID da conta é `123456789012`. A equipe de segurança pode criar uma regra de AWS Security Hub CSPM automação que suprime todas as GuardDuty descobertas dessa conta. Eles podem criar uma regra com base em um modelo, que abrange muitos casos de uso comuns, ou criar uma regra personalizada. No Security Hub CSPM, recomendamos visualizar os resultados dos critérios para confirmar se a regra retorna as descobertas pretendidas.
**nota**
Este exemplo destaca a funcionalidade das regras de automação. Não recomendamos a supressão de todas as GuardDuty descobertas de uma conta. O contexto é importante, e cada organização deve escolher quais descobertas suprimir com base no tipo de dados, na classificação e nos controles de mitigação.
Confira abaixo os parâmetros usados para criar essa regra de automação:
+ **Regra:**
+ O **nome da regra** é `Suppress findings from Sandbox account`
+ A **descrição da regra** é `Date: 06/25/23 Authored by: John Doe Reason: Suppress GuardDuty findings from the sandbox account`
+ **Critérios:**
+ `AwsAccountId` = `123456789012`
+ `ProductName` = `GuardDuty`
+ `WorkflowStatus` = `NEW`
+ `RecordState` = `ACTIVE`
+ **Ação automatizada:**
+ `Workflow.status` é `SUPPRESSED`
Para obter mais informações, consulte [Regras de automação na documentação](https://docs.aws.amazon.com/securityhub/latest/userguide/automation-rules.html) do CSPM do Security Hub. As equipes de segurança têm muitas opções para investigar e remediar as descobertas das ameaças detectadas. Para obter orientações abrangentes, consulte o [Guia de Resposta a Incidentes de Segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html). Recomendamos revisar este guia para confirmar que você estabeleceu processos robustos de resposta a incidentes.
# Exemplo de equipe da nuvem: alteração das configurações da VPC
A equipe de nuvem é responsável por fazer a triagem e corrigir as descobertas de segurança que têm tendências comuns, como alterações nas configurações AWS padrão que podem não se adequar ao seu caso de uso. Essas descobertas tendem a afetar muitos Contas da AWS recursos, como configurações de VPC, ou incluem uma restrição que deve ser colocada em todo o ambiente. Na maioria das vezes, a equipe da nuvem faz alterações manuais e únicas, como adicionar ou atualizar uma política.
Depois que sua organização tiver usado um AWS ambiente por algum tempo, você poderá encontrar um conjunto de antipadrões em desenvolvimento. Um *antipadrão* é uma solução frequentemente usada para um problema recorrente em que a solução é contraproducente, ineficaz ou menos eficaz do que uma alternativa. Como alternativa a esses antipadrões, sua organização pode usar restrições ambientais que sejam mais eficazes, como políticas de controle de AWS Organizations serviço (SCPs) ou conjuntos de permissões do IAM Identity Center. SCPs e os conjuntos de permissões podem fornecer restrições adicionais para tipos de recursos, como impedir que os usuários configurem um bucket público do Amazon Simple Storage Service (Amazon S3). Embora possa ser tentador restringir todas as configurações de segurança possíveis, há limites de tamanho de política SCPs e conjuntos de permissões. Recomendamos uma abordagem equilibrada para os controles preventivos e de detecção.
A seguir estão alguns controles do padrão AWS Security Hub CSPM [Foundational Security Best Practices (FSBP)](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) pelos quais a equipe de nuvem pode ser responsável:
+ [[EC2.2] O grupo de segurança padrão da VPC não deve permitir tráfego de entrada e saída](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2)
+ [[EC2.6] O registro de fluxo de VPC deve ser ativado em todos VPCs](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-6)
+ [[EC2.23] Os Transit Gateways do Amazon EC2 não devem aceitar automaticamente solicitações de anexos da VPC](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-23)
+ [[CloudTrail.1] CloudTrail deve ser habilitado e configurado com pelo menos uma trilha multirregional que inclua eventos de gerenciamento de leitura e gravação](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudtrail-controls.html#cloudtrail-1)
+ [[Config.1] AWS Config deve estar habilitado](https://docs.aws.amazon.com/securityhub/latest/userguide/config-controls.html#config-1)
Neste exemplo, a equipe da nuvem está tratando uma descoberta sobre o controle FSBP EC2.2. A [documentação](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2) desse controle recomenda não usar o grupo de segurança padrão porque ele permite amplo acesso por meio das regras padrão de entrada e saída. Como o grupo de segurança padrão não pode ser excluído, recomendamos alterar as configurações das regras para restringir o tráfego de entrada e saída. Para resolver esse problema com eficiência, a equipe de nuvem deve usar mecanismos estabelecidos para modificar as regras do grupo de segurança para todos, VPCs pois cada VPC tem esse grupo de segurança padrão. Na maioria dos casos, as equipes da nuvem gerenciam as configurações da VPC usando personalizações do [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) ou uma ferramenta de infraestrutura como código (IaC), como [https://www.terraform.io/](https://www.terraform.io/) ou [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html).
# Exemplo de equipe de aplicativos: criação de uma AWS Config regra
A seguir estão alguns controles do padrão de segurança CSPM [Foundational Security Best Practices (FSBP)](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) do Security Hub pelos quais o aplicativo ou a equipe de desenvolvimento podem ser responsáveis:
+ [[CloudFront.1] CloudFront as distribuições devem ter um objeto raiz padrão configurado](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudfront-controls.html#cloudfront-1)
+ [[EC2.19] Grupos de segurança não devem permitir acesso irrestrito a portas com alto risco](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19)
+ [[CodeBuild.1] CodeBuild GitHub ou o repositório de origem do Bitbucket deve usar URLs OAuth](https://docs.aws.amazon.com/securityhub/latest/userguide/codebuild-controls.html#codebuild-1)
+ [[ECS.4] Os contêineres do ECS devem ser executados sem privilégios](https://docs.aws.amazon.com/securityhub/latest/userguide/ecs-controls.html#ecs-4)
+ [[ELB.1] O Application Load Balancer deve ser configurado para redirecionar todas as solicitações HTTP para HTTPS](https://docs.aws.amazon.com/securityhub/latest/userguide/elb-controls.html#elb-1)
Neste exemplo, a equipe de aplicação está abordando uma descoberta do controle FSBP EC2.19. Esse controle verifica se o tráfego de entrada irrestrito dos grupos de segurança é acessível para as portas especificadas que o maior risco. Esse controle falhará se alguma das regras em um grupo de segurança permitir tráfego de entrada de `0.0.0.0/0` ou `::/0` para essas portas. A [documentação](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19) desse controle recomenda excluir as regras que permitem esse tráfego.
Além de abordar a regra do grupo de segurança individual, esse é um ótimo exemplo de uma descoberta que deve resultar em uma nova AWS Config [regra](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html). Ao usar o [modo de avaliação proativa](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config-rules.html#aws-config-rules-evaluation-modes), você pode ajudar a evitar a implantação de regras arriscadas de grupos de segurança no futuro. O modo proativo avalia os recursos antes de serem implantados para que você possa evitar recursos mal configurados e suas descobertas de segurança associadas. Ao implementar um novo serviço ou uma nova funcionalidade, as equipes de aplicações podem executar regras no modo proativo como parte do pipeline de integração e entrega contínua (CI/CD) para identificar recursos não compatíveis. A imagem a seguir mostra como você pode usar uma AWS Config regra proativa para confirmar se a infraestrutura definida em um AWS CloudFormation modelo está em conformidade.
![\[Uma AWS Config regra proativa que verifica a conformidade AWS CloudFormation de um modelo\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/vulnerability-management/images/cloudformation-config-proactive-workflow.png)
Outra eficiência importante pode ser obtida neste exemplo. Quando uma equipe de aplicativos cria uma AWS Config regra proativa, ela pode compartilhá-la em um repositório de código comum para que outras equipes de aplicativos possam usá-la.
Cada descoberta associada a um controle CSPM do Security Hub contém detalhes sobre a descoberta e um link para as instruções para remediar o problema. Embora as equipes da nuvem possam encontrar descobertas que exijam uma remediação manual e única, quando apropriado, recomendamos criar verificações proativas que identifiquem os problemas o mais cedo possível no processo de desenvolvimento.