Essa combinação de serviços oferece uma maneira econômica de monitorar continuamente servidores locais em busca de malware sem impactar o desempenho. Também ajuda a determinar backups seguros de ponto de recuperação no tempo para restauração, identificando a linha do tempo de comprometimentos por meio de análises centralizadas de ameaças.

• AWS Elastic Disaster Recovery (AWS DRS) minimiza o tempo de inatividade e a perda de dados com recuperação rápida e confiável de aplicações locais e baseadas em nuvem, usando armazenamento acessível, computação mínima e recuperação pontual.
• Amazon GuardDuty é um serviço de detecção de ameaças que monitora continuamente suas contas e cargas de trabalho da AWS em busca de atividades maliciosas e fornece descobertas de segurança detalhadas para visibilidade e remediação.
• AWS Security Hub é um serviço de gerenciamento de postura de segurança em nuvem (CSPM) que realiza verificações de melhores práticas de segurança, agrega alertas e permite remediação automatizada.

Arquitetura

Descrição da solução

A solução de varredura de malware pressupõe que os servidores locais já estejam sendo replicados com AWS DRS, e que Amazon GuardDuty e AWS Security Hub estejam habilitados. A stack CDK neste repositório implantará apenas os componentes rotulados como DRS Malware Scan no diagrama de arquitetura.

1. AWS DRS está replicando servidores de origem do ambiente local para a AWS (ou de qualquer provedor de nuvem, na verdade). Para mais detalhes sobre a configuração do AWS DRS, siga o Guia de início rápido.
2. Amazon GuardDuty já está habilitado.
3. AWS Security Hub já está habilitado.
4. A solução de varredura de malware é acionada por uma Regra de Agendamento no Amazon EventBridge (com prefixo DrsMalwareScanStack-ScheduleScanRule). Você pode ajustar a frequência de varredura conforme necessário (por exemplo, uma vez por dia, por semana, etc.).
5. A Regra de Agendamento no Amazon EventBridge aciona a função lambda Submit Orders (com prefixo DrsMalwareScanStack-SubmitOrders) que coleta os servidores de origem para varredura da tabela DynamoDB Source Servers.
6. As ordens são colocadas na fila SQS FIFO chamada Scan Orders (com prefixo DrsMalwareScanStack-ScanOrdersfifo). A fila é usada para serializar solicitações de varredura mapeadas para a mesma instância DRS, evitando uma condição de corrida.
7. A lambda Process Order pega uma ordem de varredura de malware da fila e a enriquece, preparando a operação de varredura de malware iminente. Por exemplo, ela insere o ID da instância DRS de replicação associada ao servidor de origem DRS fornecido na ordem. A saída de Process Order são comandos de varredura de malware contendo todas as informações necessárias para invocar a varredura de malware do GuardDuty.
8. As operações de varredura de malware são rastreadas usando a DRSVolumeAnnotationsDDBTable no nível de volume, fornecendo capacidades de relatório.
9. Os comandos de varredura de malware são inseridos na fila SQS FIFO Scan Commands (com prefixo DrsMalwareScanStack-ScanCommandsfifo) para aumentar a resiliência.
10. A função Process Commands submete comandos de varredura enfileirados a uma taxa máxima de 1 comando por segundo para evitar limitação da API. Ela aciona a função de varredura de malware sob demanda fornecida pelo Amazon GuardDuty.
11. A execução do trabalho de varredura de malware sob demanda do Amazon GuardDuty pode ser monitorada a partir do serviço Amazon GuardDuty.
12. O resultado do trabalho de varredura de malware é roteado para o Amazon Cloudwath Logs.
13. A função lambda Subscription Filter recebe o resultado da varredura e rastreia o resultado usando o DynamoDB (etapa #14).
14. A Tabela DynamoDB DRS Instance Annotations rastreia o status do trabalho de varredura de malware no nível da instância.
15. A stack CDK chamada ScanReportStack implanta a função lambda Scan Report (com prefixo ScanReportStack-ScanReport) para popular o bucket Amazon S3 com prefixo scanreportstack-scanreportbucket.
16. O AWS Security Hub agrega e correlaciona descobertas do Amazon GuardDuty.
17. O evento de descoberta do Security Hub é capturado por uma Regra do EventBridge (com prefixo DrsMalwareScanStack-SecurityHubAnnotationsRule).
18. A função lambda Security Hub Annotations (com prefixo DrsMalwareScanStack-SecurityHubAnnotation) gera Notas (Anotações) adicionais à Descoberta com informações contextualizadas sobre o servidor de origem afetado. Essas informações adicionais podem ser vistas na seção Notes dentro da Descoberta do Security Hub.
19. As atividades de acompanhamento dependerão do processo de resposta a incidentes adotado. Por exemplo, com base na data da infecção, o AWS DRS pode ser usado para realizar uma recuperação pontual usando um snapshot anterior à data da infecção por malware.
20. Em um cenário de múltiplas contas, esta solução pode ser implantada diretamente na conta da AWS que hospeda a solução AWS DRS. As descobertas do Amazon GuardDuty serão automaticamente enviadas para a Conta de Segurança centralizada.

Uso

Pré-requisitos

• Uma conta AWS.

• Amazon Elastic Disaster Recovery (DRS) configurado, com pelo menos 1 servidor de origem em sincronia. Caso contrário, consulte esta documentação. A Configuração de Replicação deve considerar a criptografia EBS usando Chave Gerenciada Personalizada (CMK) do AWS Key Management Service (AWS KMS). O Amazon GuardDuty Malware Protection não suporta a chave gerenciada padrão da AWS para EBS.

• Privilégios IAM para implantar os componentes desta solução.

• Amazon GuardDuty habilitado. Caso contrário, consulte esta documentação.

• Amazon Security Hub habilitado. Caso contrário, consulte esta documentação.

  Aviso
  Atualmente, a varredura de malware do Amazon GuardDuty não oferece suporte a volumes EBS criptografados com chaves gerenciadas pela EBS. Se você deseja usar esta solução para escanear seus servidores locais (ou de outra nuvem) replicados com DRS, é necessário configurar a replicação DRS com sua própria chave de criptografia no KMS. Se você estiver usando atualmente chaves gerenciadas pela EBS em seus servidores replicados, pode alterar as configurações de criptografia para usar sua própria chave KMS no console do DRS.

Implantação

1. Crie um ambiente Cloud9 com imagem Ubuntu (pelo menos t3.small para melhor desempenho) em sua conta AWS. Abra seu ambiente Cloud9 e clone o código deste repositório. Nota: Amazon Linux 2 tem node v16 que não é mais suportado desde 2023-09-11

   root@kitploit:~

   git clone https://github.com/aws-samples/drs-malware-scan
   

   root@kitploit:~

   cd drs-malware-scan
   

   root@kitploit:~

   sh check_loggroup.sh
   

2. Implante a stack CDK executando o seguinte comando no terminal do Cloud9 e confirme a implantação

   root@kitploit:~

   npm install
   

   root@kitploit:~

   cdk bootstrap
   

   root@kitploit:~

   cdk deploy --all
   

   Nota
   A solução é composta por 2 stacks:

   • DrsMalwareScanStack: implanta todos os recursos necessários para a funcionalidade de varredura de malware. Esta stack é obrigatória. Se você quiser implantar apenas esta stack, execute cdk deploy DrsMalwareScanStack
   • ScanReportStack: implanta os recursos necessários para relatórios (Amazon Lambda e Amazon S3). Esta stack é opcional. Se você quiser implantar apenas esta stack, execute cdk deploy ScanReportStack

   Se você quiser implantar ambas as stacks, execute cdk deploy --all

Configuração

1. Certifique-se de que o(s) servidor(es) de origem DRS esteja(m) replicando continuamente e em um estado de replicação saudável. Isso é necessário devido a uma limitação na API do GuardDuty: no momento desta redação, não existe uma API pública da AWS para escanear snapshots DRS. A única maneira de realizar a varredura de malware nos dados do(s) servidor(es) de origem DRS é realizar uma varredura no(s) Servidor(es) de Replicação (instâncias Amazon EC2) gerenciados pelo AWS DRS. Se a replicação não estiver em um estado saudável, sua varredura de malware DRS pode não ser concluída com sucesso. Você deve confirmar ReadyforRecovery=Ready

2. Identifique os Servidores de Origem para escanear. De todos os servidores sendo replicados com AWS DRS, você precisa determinar a lista de servidores candidatos para escanear. No console do AWS DRS, copie os nomes dos servidores de origem que você gostaria que a solução escaneasse e cole em um editor de texto. Isso será usado na próxima etapa.

3. Atualize a tabela DynamoDB. A lista de servidores a serem escaneados é armazenada em uma tabela DynamoDB criada pela stack cdk (com prefixo DrsMalwareScanStack-SourceServersDDBTable). Você precisa criar itens DynamoDB para cada Servidor de Origem que está sendo replicado pelo AWS DRS. Para fazer isso, vá ao serviço Amazon DynamoDB e siga estas etapas:

4. Agende o trabalho de varredura de malware. Você pode ir ao serviço Amazon Eventbridge e modificar a regra existente criada pela stack. Edite a regra com prefixo DrsMalwareScanStack-ScheduleScanRule, defina a frequência de varredura da análise de malware. Além disso, esta regra está DESABILITADA por padrão, por favor HABILITE-A.

5. Verifique se o Amazon GuardDuty acionou uma operação de varredura de malware Para confirmar que a solução está funcionando conforme esperado, você pode verificar no console do Amazon GuardDuty -> Malware scans. Alguns segundos após o horário agendado, você deve ver um trabalho com ScanStatus = Running. Caso contrário, consulte a seção de Solução de Problemas abaixo.

6. Verifique o AWS SecurityHub em busca de possíveis descobertas de malware em servidores locais A integração do Amazon GuardDuty com o Security Hub permite enviar descobertas do GuardDuty para o Security Hub.
   • O Security Hub mostra apenas descobertas, portanto, os trabalhos de varredura de malware com ScanResult=Clean não serão exibidos no console do Security Hub (apenas aqueles com ScanResult=Infected).
   • No console do AWS Security Hub, você pode ir em Findings e aplicar um filtro por ProductName=GuardDuty (conforme mostrado na animação abaixo).
   • A solução adiciona anotações à seção Notes da descoberta, destacando o nome dos servidores locais infectados.
   • O Security Hub está integrado ao Amazon Eventbridge para automatizar facilmente as atividades de resposta e remediação, como enviar um e-mail para um SOC, relatar o incidente em um canal Slack, etc. Você pode consultar este link para mais detalhes.

7. Opcional: Verifique o arquivo de relatório de varredura de malware no S3. Caso você tenha implantado a stack ScanReportStack, pode agendar um relatório para ser executado com a frequência que atender às suas necessidades. O relatório extrairá o conteúdo da tabela DynamoDB DRSVolumeAnnotationsDDBTable e o escreverá no bucket Amazon S3 criado pela stack (com prefixo scanreportstack-scanreportbucket). Este relatório é sobrescrito (e cumulativo) toda vez que a regra é acionada.

   • Habilite a regra do Amazon Eventbridge e defina o agendamento para executar o relatório: Edite a regra com prefixo ScanReportStack-ScanReportRule para definir a frequência de varredura da análise de malware e a lista de servidores de origem DRS a serem analisados. Além disso, esta regra está desabilitada por padrão, habilite-a.

          

   • Para verificar o relatório, você pode consultar o arquivo csv no bucket Amazon S3 (com prefixo scanreportstack-scanreportbucket)

          

8. Opcional: Para configuração de múltiplas contas Caso você tenha uma conta de segurança designada para centralizar todas as descobertas de segurança como parte de uma estratégia de múltiplas contas, esta solução também funcionará. A equipe de segurança pode realizar a mesma análise na conta de segurança; as descobertas do Security Hub e GuardDuty relatadas nas contas vinculadas são copiadas automaticamente para a conta de segurança centralizada.

Solução de problemas

Todas as funções lambda roteiam logs para Amazon CloudWatch. Você pode verificar a execução de cada função inspecionando os grupos de logs do CloudWatch apropriados para cada função, procure pelo padrão /aws/lambda/DrsMalwareScanStack-*.

A duração da operação de varredura de malware dependerá do número de servidores/volumes a serem escaneados (e seu tamanho). Quando o Amazon GuardDuty encontra malware, ele gera uma descoberta no SecurityHub: a solução intercepta esse evento e executa a lambda $StackName-SecurityHubAnnotations para aumentar a descoberta do SecurityHub com uma nota contendo o(s) nome(s) do(s) servidor(es) de origem DRS com malware.

As filas SQS FIFO podem ser monitoradas usando as métricas Messages available e Message in flight do console AWS SQS

A tabela DynamoDB DRS Volume Annotations mantém o status de cada operação de varredura de malware.

O Amazon GuardDuty tem razões documentadas para pular operações de varredura. Para mais informações, consulte Motivos para pular recurso durante a varredura de malware.

Para analisar logs das operações de varredura de malware do Amazon GuardDuty, você pode verificar o LogGroup do Amazon Cloudwatch /aws/guardduty/malware-scan-events. O período de retenção de logs padrão para este grupo de logs é de 90 dias, após o qual os eventos de log são excluídos automaticamente.

Limpeza

1. Execute os seguintes comandos no seu terminal:

   root@kitploit:~

   cdk destroy --all
   

2. (Opcional) Exclua os grupos de logs do CloudWatch associados às funções Lambda.

Análise de Estimativa de Custos AWS

Para fins desta análise, assumimos um cenário fictício como exemplo. As seguintes estimativas de custo são baseadas em serviços localizados na região da Virgínia do Norte (us-east-1).

Cenário estimado:

• 2 Servidores de Origem para replicar (DR) (Armazenamento Total: 100GB - 4 discos)
• 3 TB de Varredura de Malware por Mês
• 30 dias de período de retenção de snapshots EBS
• Varreduras de malware diárias

Detalhamento dos Serviços:

Nota
Os valores apresentados aqui são estimativas baseadas nas premissas descritas acima, derivadas da Calculadora de Preços da AWS. Para mais detalhes, consulte esta calculadora de preços como referência. Você pode ajustar a configuração dos serviços na calculadora referenciada para fazer sua própria estimativa. Esta estimativa não inclui impostos potenciais ou encargos adicionais que possam ser aplicáveis. É crucial lembrar que as taxas reais podem variar com base no uso e em quaisquer serviços adicionais não cobertos nesta análise. Para ambientes críticos, é aconselhável incluir o Business Support Plan (não considerado na estimativa)

Segurança

Consulte CONTRIBUTING para mais informações.

Autores

• Rodrigo Monge
• Thierry Francois
• Diego Pérez Holguín
• Leandro Santi

Licença

Este código de exemplo está licenciado sob a Licença MIT-0. Consulte o arquivo LICENSE.