Gerenciamento de vulnerabilidades
Desenvolva práticas eficazes de vulnerabilidade.
Visão geral
Este documento técnico aborda diferentes práticas de gerenciamento de vulnerabilidades, como varreduras de vulnerabilidades, testes de penetração e varreduras de vulnerabilidade de código. Este documento também explorará processos para restaurar a disponibilidade e o acesso após uma interrupção do serviço devido a um incidente.
Requisitos da Política de proteção de dados (DPP)
As part of Amazon’s Data Protection Policy (DPP) (DPP), developers have to implement vulnerability scans at minimum semi-annually, penetration tests yearly, code vulnerability scans prior to release of new code, features, or products, and to ensure they can restore availability and access to Personal Identifiable Information (PII) within hours. This is to avoid exposure of sensitive data, including PII. Every SP-API developer needs to ensure that vulnerable points such as public-facing websites, interfaces, servers, and new features have the expected level of security and protection even before release.
Gerenciamento de vulnerabilidades
Os desenvolvedores devem criar e manter um plano ou um manual para detectar e corrigir vulnerabilidades. Os desenvolvedores devem proteger o hardware físico que contém PII contra vulnerabilidades técnicas realizando verificações de vulnerabilidades e corrigindo adequadamente. Os desenvolvedores devem realizar a verificação de vulnerabilidades pelo menos a cada 180 dias, testar a penetração pelo menos a cada 365 dias e escanear o código em busca de vulnerabilidades antes de cada lançamento. Além disso, os desenvolvedores devem controlar as alterações no hardware de armazenamento testando, verificando alterações, aprovando alterações e restringindo o acesso a quem pode realizar essas ações. Os desenvolvedores devem ter procedimentos e planos apropriados para restaurar a disponibilidade e o acesso às PII em tempo hábil no caso de um incidente físico ou técnico.
Verificações de vulnerabilidade
Uma verificação de vulnerabilidade é o processo de identificar, descobrir, analisar e relatar o acesso ao host, os pontos fracos e as lacunas de rede das instâncias ou do software que o aplicativo está executando.
Em termos de segurança, é essencial verificar se os dispositivos/instâncias voltados para o público estão protegidos contra agentes mal-intencionados. Em um cenário ideal, as verificações podem ser executadas por ferramentas de varredura de vulnerabilidades para identificar/classificar fatores de risco e possíveis vetores de ataque na rede (incluindo ativos de software e hardware).
Here are the top ten vulnerabilities according to the Open Web Application Security Project (OWASP) for 2021 and associated Common Weakness Enumerations (CWE):
CWE | Ponto de vulnerabilidade | Breve descrição |
---|---|---|
A01 | Controle de acesso quebrado | O usuário executa uma ação que não deveria poder acessar. |
A02 | Falhas criptográficas | Práticas criptográficas inexistentes ou fracas. |
A03 | Injeção | Os hackers são capazes de inserir dados e manipulá-los em uma rede. |
A04 | Design inseguro | Falta de planejamento durante a fase de projeto da rede. |
A05 | Microconfigurações de segurança | Configurações do programa FBA - Logística da Amazon de segurança em bancos de dados, bibliotecas e/ou servidores não definidas que podem levar a uma vulnerabilidade. |
A06 | Componentes vulneráveis e desatualizados | Versões antigas ou não suportadas de um software ou sistema operacional. |
A07 | Falhas de identificação e autenticação | Falta de controles de acesso do usuário e gerenciamento de credenciais. |
A08 | Falhas de integridade de software e dados | Sem proteção contra violações de integridade. |
A09 | Falha segura de registro e monitoramento | Nenhum serviço de monitoramento dificulta a identificação de violações e ataques de saída. |
A10 | Falsificação de solicitação do lado do servidor (SSFR) | URL não verificada fornecida por um usuário que força um aplicativo a enviar solicitações que contornam a segurança da rede. |
Refer to OWASP – Vulnerability Scanning Tools for a list of free and paid scanning tools.
Depois que as verificações forem concluídas, os desenvolvedores precisam priorizar as vulnerabilidades de acordo com o nível de impacto na segurança e trabalhar para corrigi-las adequadamente.
-
Escaneamentos externos de vulnerabilidades: As verificações externas têm como objetivo verificar vulnerabilidades em pontos externos/públicos, como portas, sites, redes e aplicativos.
-
Verificações internas de vulnerabilidades: As varreduras internas dão visibilidade sobre possíveis falhas de segurança em uma rede privada.
-
Escaneamentos intrusivos e não intrusivos: os escaneamentos não intrusivos examinarão um alvo específico, como tráfego de rede ou a versão de um banco de dados, mas isso não afeta os níveis de serviço, pois só verifica as informações sem tirar proveito da vulnerabilidade. Uma verificação intrusiva tem como objetivo explorar a vulnerabilidade em seu nível mais alto e fornecer mais informações sobre as vulnerabilidades encontradas, mas também interrompe os níveis de serviço, portanto, use-a em um ambiente controlado.
Amazon Inspector
Amazon Inspector is a scalable vulnerability management tool which scans workloads and unintended network exposures to verify that there are no vulnerabilities in operating systems running EC2 instances.
O Amazon Inspector fornece relatórios de localização de vulnerabilidades quase em tempo real usando fatores atualizados de Vulnerabilidades e Exposição Comuns (CVE) e verificando diferentes linguagens de codificação, como Java, Python e Node.js. Os desenvolvedores que usam o Amazon Inspector podem usá-lo para validação de conformidade de programas como certificados PCI, ISO e CSA STAR.
Amazon Guard
Amazon’s Security team developed Amazon’s SP-API-Guard as an application that runs in AWS instances to check and asses security compliance with Amazon’s DPP. SP-API Guard also provides a recommendation report of any security gap it finds within a day to an S3 bucket. This reduces the effort for manual Data Security Assessments and remediation plan times while providing recommended solutions for vulnerabilities found.
Teste de penetração
O teste de penetração (pen testing) é uma forma de verificar em um ambiente simulado/controlado qualquer vulnerabilidade em diferentes pontos de aplicativos ou redes. Isso é feito para confirmar quais vulnerabilidades podem ser exploradas por agentes mal-intencionados.
O teste de caneta consiste nas seguintes etapas:
-
Etapa de planejamento: A equipe define metas e o escopo dos pen tests dos testadores. Todas as partes devem estar cientes dos próximos testes.
-
Estágio de digitalização/descoberta: Os testadores de caneta iniciam o processo de reconhecimento de rede e inspeção de código.
-
Estágio de penetração: O pen tester tenta obter acesso à rede/instâncias usando diferentes tipos de ataques, como injeção de SQL, scripts entre sites e backdoors, para explorar vulnerabilidades.
-
Etapa de análise/relatório: O pen tester cria um relatório com informações detalhadas sobre as ações tomadas para penetrar na segurança da rede e as vulnerabilidades encontradas. O testador de caneta deve incluir uma seção de ações recomendadas no relatório.
-
Estágio de remediação/limpeza: A equipe responsável assume a liderança e começa a trabalhar na correção das vulnerabilidades relatadas após a conclusão dos pen tests.
Como uma etapa extra de segurança para garantir que as vulnerabilidades sejam corrigidas ou corrigidas, os desenvolvedores executam um segundo teste após a fase de remediação para garantir que nenhum item tenha sido deixado para trás ou sem supervisão.
OWASP also offers a penetration test guide (OWASP ZAP) for developers who want to know more on how to apply pen tests at an application level and for their network components such as firewalls and ports.
Escaneamentos de vulnerabilidade de código
As varreduras de vulnerabilidade de código têm como objetivo reduzir os riscos quando um novo recurso/produto está sendo lançado. Os desenvolvedores podem garantir que não haja erros, problemas técnicos ou falhas de segurança quando o código for implantado com o uso das seguintes ferramentas de escaneamento de código:
-
Teste estático de segurança de aplicativos (SAST): Revisão do código sem precisar executá-lo. O SAST verifica como o código é escrito para apontar quaisquer problemas de segurança nele.
-
Teste dinâmico de segurança de aplicativos (DAST): Ao contrário do SAST, o DAST verifica o código em um aplicativo em execução simulando ataques com injeções maliciosas de carga útil. O DAST ajuda os desenvolvedores a identificar vulnerabilidades em um aplicativo em execução.
-
Teste de aplicativo interativo (IAST): O IAST verifica as funcionalidades do aplicativo em todos os ambientes de teste. Isso facilita a implementação e a escalabilidade, pois ajuda a reduzir possíveis períodos de inatividade ou interrupções no serviço ao lidar com as vulnerabilidades antes do lançamento.
Essas ferramentas devem seguir os padrões fornecidos pelo OWASP para verificar a segurança do aplicativo em relação aos dez principais riscos de segurança. Os desenvolvedores precisam continuar com a digitalização do código para identificar, classificar e priorizar quaisquer falhas de segurança que afetem ou interrompam o serviço após o lançamento do produto.
Plano de recuperação de desastres
To ensure that application users are not affected by incidents (technical or physical) developers must have a plan that covers actions on how to restore availability and access to PII data in a short time, taking in consideration Recovery Time Objective (RTO) and Recovery Point Objective (RPO). AWS offers guidance in Establishing RTO and RPO Targets for Cloud Applications.
-
PARA: o tempo que os desenvolvedores levam para restaurar os níveis normais de serviço para os usuários do aplicativo. Isso pode ser feito com redundância nas instâncias/serviços de rede que são essenciais para a funcionalidade do aplicativo.
-
PRO: O momento em que os desenvolvedores podem restaurar os dados, ou seja, quantos dados podem ser perdidos após um incidente. Um aspecto fundamental desse objetivo é ter um ou mais backups dos dados em locais diferentes e realizar esses backups duas vezes por semana, se possível.
Developers are expected to use recovery strategies and test them to meet objectives (RTO and RPO). AWS Resilience Hub is an AWS service that helps to establish RTO and RPO targets, and it analyzes applications against those targets.
Conclusão
O gerenciamento de vulnerabilidades é um padrão de segurança essencial. As verificações de vulnerabilidade e os testes de penetração ajudam a identificar e reduzir possíveis riscos em um ambiente de rede e instâncias de aplicativos. Os desenvolvedores precisam executar escaneamentos de vulnerabilidades e pen tests pelo menos uma vez por ano, de acordo com os requisitos do DPP. A prática de conduzir essas avaliações ajuda os desenvolvedores a aumentar sua maturidade de segurança e a cumprir os padrões que eles podem enfrentar, como as melhores práticas regulatórias ou do setor.
Os desenvolvedores devem executar uma varredura de código antes do lançamento de recursos ou produtos. Os testes devem ser feitos em um ambiente isolado e controlado para garantir que não haja falhas de segurança para novas versões e que nenhum dado seja exposto.
Ter backups, instantâneos ou imagens ajuda a reduzir o impacto da perda de dados de PII devido a um incidente. Garantir a resiliência de seus serviços de aplicativos reduz o tempo necessário para restaurar o acesso e a disponibilidade aos dados de PII.
Updated 23 days ago