Detectar vulnerabilidades de um cluster regulamentado do AKS para PCI-DSS 3.2.1 (Parte 5 de 9)

Este artigo descreve as considerações para um cluster do AKS (Serviço de Kubernetes do Azure) configurado de acordo com o Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI-DSS 3.2.1).

Este artigo faz parte de uma série. Leia a introdução.

Como qualquer solução de nuvem, uma carga de trabalho PCI está sujeita a ameaças de rede, identidade e dados. Exemplos comuns de fontes que aproveitam as vulnerabilidades da carga de trabalho e do sistema são vírus ou atualizações de software que produzem resultados indesejáveis. Detecte ameaças antecipadamente e responda com mitigação em tempo hábil. Crie alertas críticos para atividades de carga de trabalho e estenda esses alertas para os principais processos do sistema. As ferramentas FIM (monitoramento de integridade de arquivo) ou antivírus devem estar sempre em execução. Tenha um plano de resposta responsável e uma equipe que investigue os alertas e tome ação.

Manter um programa de gerenciamento de vulnerabilidades

Requisito 5: proteger todos os sistemas contra malware e atualizar regularmente softwares ou programas antivírus

Suporte ao recurso do AKS

O AKS não se comporta como um host de aplicativo tradicional. As VMs de nó em um cluster do AKS têm exposição limitada e foram projetadas para não serem acessadas diretamente. Como as VMs de nó não são equivalentes a VMs tradicionais, você não pode usar ferramentas comuns de VM. Portanto, as recomendações nesta seção são aplicadas por meio de constructos nativos do Kubernetes. Aplicar esses requisitos diretamente no nível da VM pode fazer com que o cluster fique sem suporte.

Você precisará implantar o software antimalware de sua escolha no DaemonSets que será executado em um pod em cada nó.

Suas responsabilidades

Verifique se o software é especializado em Kubernetes e contêineres. Há várias opções de software de terceiros. As opções mais conhecidas incluem Prisma Cloud e Aquasec. Há também opções de código aberto, como o Falco. É sua responsabilidade garantir que haja processos em vigor para garantir que o software de terceiros esteja atualizado. Além disso, monitorar e alertar sobre as soluções é sua responsabilidade.

Requisito 6: desenvolver e manter os aplicativos e sistemas protegidos

Suporte ao recurso do AKS

Assim como outros serviços do Azure, o AKS segue os processos do Microsoft SDL (Ciclo de Vida de Desenvolvimento de Segurança) para segurança durante as fases do processo de desenvolvimento. Vários componentes são verificados nos estágios iniciais de desenvolvimento e as lacunas de segurança são abordadas o mais cedo possível.

As imagens do AKS seguem uma abordagem de SLA do FedRAMP, que exige que as vulnerabilidades nas imagens sejam corrigidas dentro de 30 dias. Para fazer cumprir este requisito, todas as imagens são corrigidas por meio de um pipeline de DevSecOps.

Semanalmente, o AKS fornece novas imagens para os pools de nós. É sua responsabilidade aplicá-las para garantir o patch e a atualização de nós de trabalho de conjuntos de dimensionamento de máquinas virtuais. Para obter mais informações, confira Atualização de uma imagem de nó do AKS (Serviço de Kubernetes do Azure).

Para o plano de controle do AKS, o AKS instala ou atualiza os patches de segurança. Eles são atualizados a cada 24 horas.

O plano de controle do AKS e os nós de trabalho são protegidos usando os parâmetros de comparação do CIS (Center for Internet Security), especificamente o CIS do AKS, o CIS do Ubuntu e o CIS do Windows.

O AKS se integra com o Registro de Contêiner do Azure. Use o Azure Container Registry com recursos de verificação contínua no Microsoft Defender para Nuvem para identificar imagens e aplicativos vulneráveis em vários níveis de risco. Para obter informações sobre verificação de imagem e controle de risco, confira o Microsoft Defender para Contêineres.

Suas responsabilidades

Requisito 5.1

Implantar o software antivírus em todos os sistemas geralmente afetados por software mal-intencionado (particularmente computadores pessoais e servidores).

Suas responsabilidades

É sua responsabilidade proteger a carga de trabalho, a infraestrutura e os pipelines de implantação escolhendo um software antimalware apropriado.

Como o acesso às VMs do nó AKS é restrito, proteja o sistema em cada camada onde malware pode ser injetado nas VMs do nó. Inclui detecção e prevenção em nós de cluster, imagens de contêiner e interações de runtime com o servidor de API do Kubernetes. Além do cluster, proteja esses componentes que interagem com o cluster e podem ter o software antivírus instalado de maneira tradicional:

• Jump boxes
• Agente de compilação

Alinhe suas atividades de verificação com o SDL (Ciclo de Vida de Desenvolvimento de Segurança). Seguir o SDL garante que a verificação de vários componentes da arquitetura comece nos estágios iniciais das lacunas de desenvolvimento e segurança o mais cedo possível.

Requisito 5.1.1

Certificar-se de que os programas antivírus sejam capazes de detectar, remover e proteger contra todos os tipos conhecidos de software mal-intencionado.

Suas responsabilidades

Saiba mais sobre o conjunto de recursos de cada oferta de software e a profundidade de verificação que ele pode fazer. O software deve bloquear ameaças comuns e monitorar novas ameaças. Verifique se o software está atualizado, foi testado e é substituído regularmente se ele considerado inadequado. Considere o software desenvolvido por fornecedores respeitáveis.

• Ferramentas de monitoramento que detectam vulnerabilidades de cluster.

  No AKS, você não pode executar soluções de VM tradicionais baseadas em agente diretamente em VMs de nó. Você precisará implantar o software antimalware no DaemonSets que será executado em um pod em cada nó.

  Escolha um software especializado para Kubernetes e cargas de trabalho em contêineres. Há várias opções de software de terceiros. As opções mais conhecidas incluem Prisma Cloud e Aquasec. Há também opções de código aberto, como o Falco.

  Quando implantados, eles são executados como agentes no cluster que verifica todos os pools de nós do usuário e do sistema. Embora o AKS use pools de nós do sistema para seus binários do sistema de runtime, a computação subjacente ainda é sua responsabilidade.

  A finalidade de executar o agente é detectar atividades incomuns de cluster. Por exemplo, um aplicativo está tentando chamar o servidor de API? Algumas soluções geram um log de chamadas à API entre pods, geram relatórios e geram alertas. Certifique-se de examinar esses logs e executar as ações necessárias.

  Instale agentes de segurança imediatamente após a inicialização do cluster para minimizar as lacunas não monitoradas entre o cluster e a implantação de recursos AKS.

  Os agentes de segurança são executados com altos privilégios e verificam tudo o que é executado no cluster e não apenas a carga de trabalho. Eles não devem se tornar uma fonte de exfiltração dos dados. Além disso, ataques da cadeia de fornecedores são comuns para contêineres. Use estratégias de defesa detalhadas e verifique se o software e todas as dependências são confiáveis.

  Execute também software antivírus em ativos externos que participam de operações de cluster. Alguns exemplos incluem jump boxes, agentes de build e imagens de contêiner que interagem com o cluster.

  Ao verificar, o agente não deve bloquear nem interferir nas operações críticas do cluster, como bloquear arquivos. A configuração incorreta pode causar problemas de estabilidade e deixar seu cluster sem suporte.

  Importante

  A implementação de referência fornece uma implantação DaemonSet de espaço reservado para executar um agente antimalware. O agente será executado em cada VM de nó no cluster. Coloque sua escolha de software antimalware nesta implantação.

• Manter a segurança do contêiner. Execute ferramentas de verificação de contêiner no pipeline para detectar ameaças que podem vir por meio de imagens de contêiner, como a verificação de vulnerabilidades de CI/CD no Microsoft Defender para Contêineres. As opções de terceiros incluem Trivy e Clair. Quando você estiver criando imagens, sempre tente obter imagens sem intervalo. Essas imagens contêm apenas os binários essenciais na imagem base do Linux e reduzem a área da superfície para ataques. Use uma solução de verificação contínua como a avaliação de vulnerabilidade no Microsoft Defender para Contêineres para verificação contínua de imagens já em repouso em seus repositórios.

Requisito 5.1.2

Para sistemas que normalmente não são alvo ou afetados por software malicioso, realize avaliações periódicas para identificar e avaliar ameaças de malware em evolução para confirmar se continuam a não precisar de software antivírus.

Suas responsabilidades

Vulnerabilidades comuns podem afetar componentes fora do cluster. Acompanhe as vulnerabilidades de segurança observando CVEs e outros alertas de segurança da plataforma do Azure. Verifique se há atualizações do Azure para novos recursos que podem detectar vulnerabilidades e executar soluções antivírus em serviços hospedados no Azure.

Por exemplo, o armazenamento de blobs deve ter uma triagem de reputação de malware para detectar uploads suspeitos. O Microsoft Defender for Storage inclui verificação de reputação de malware. Além disso, considere se uma solução antivírus é necessária para esse serviço.

Requisito 5.2

Certificar-se de que todos os mecanismos antivírus sejam mantidos do seguinte modo:

• Estejam sempre atualizados.
• Executem verificações periódicas
• Gerem logs de auditoria que são mantidos segundo o Requisito PCI DSS 10.7.

Suas responsabilidades

• Verifique se o cluster está protegido contra novos ataques usando a versão mais recente do software antivírus. Há dois tipos de atualizações que devem ser considerados:
  • O software antivírus deve acompanhar as atualizações de recursos mais recentes. Um modo é agendar atualizações como parte das atualizações da plataforma.
  • As atualizações de inteligência de segurança devem ser aplicadas assim que estiverem disponíveis para detectar e identificar as ameaças mais recentes. Optar por atualizações automáticas.
• Valide se as verificações de vulnerabilidade estão em execução, conforme agendado.
• Retenha logs gerados como resultado da verificação que indica componentes íntegros e não íntegros. O período de retenção recomendado é dado no Requisito 10.7, que é um ano.
• Tenha um processo em vigor que faça a triagem e corrija os problemas detectados.

Para obter informações sobre como as atualizações do antivírus Microsoft Defender for Endpoint são aplicadas, consulte Informações de segurança e atualizações de produtos do Microsoft Defender Antivirus.

Requisito 5.3

Os recursos antivírus devem estar em execução ativa e não podem ser desativados ou alterados pelos usuários. Exceto quando autorizado pela administração caso a caso por um período de tempo limitado.

Suas responsabilidades

Você é responsável por configurar o monitoramento e o alerta do agente de segurança. Crie alertas críticos não apenas para a carga de trabalho, mas também para os principais processos do sistema. O agente deve sempre estar em execução.. Responda aos alertas gerados pelo software antimalware.

• Mantenha um rastro de log das atividades de verificação. Certifique-se de que o processo de verificação não registra nenhum dado de titular do cartão eliminado do disco ou da memória.
• Defina alertas para atividades que podem causar um lapso inesperado de conformidade. Os alertas não devem ser desativados inadvertidamente.
• Restrinja as permissões para modificar a implantação do agente (e outras ferramentas de segurança críticas). Mantenha essas permissões separadas das permissões de implantação de carga de trabalho.
• Não implante cargas de trabalho se os agentes de segurança não estiverem em execução conforme o esperado.

Requisito 5.4

Verifique se políticas de segurança e procedimentos operacionais para proteção dos sistemas contra malware estão documentados, em uso e são comunicados a todas as partes afetadas.

Suas responsabilidades

É fundamental que você mantenha uma documentação completa sobre o processo e as políticas, especialmente detalhes sobre a solução antivírus usada para proteger o sistema. Inclua informações como onde, no ciclo do produto, as atualizações de inteligência de segurança são mantidas, a frequência das verificações e informações sobre os recursos de verificação em tempo real.

Tenha políticas de retenção para armazenar logs. Talvez você queira ter armazenamento de longo prazo para fins de conformidade.

Mantenha a documentação sobre procedimentos operacionais padrão para avaliar e remediar problemas. As pessoas que operam ambientes regulamentados devem ser instruídas, informadas e incentivadas para dar suporte às garantias de segurança. Isso é importante para as pessoas que fazem parte do processo de aprovação do ponto de vista da política.

Requisito 6.1

Estabelecer um processo para identificar vulnerabilidades de segurança, usando fontes confiáveis externas para obter informações de vulnerabilidade de segurança e atribuir uma classificação de risco (por exemplo, alto, médio ou baixo) às vulnerabilidades de segurança recém-descobertas.

Suas responsabilidades

Tenha processos que verificam as vulnerabilidades detectadas e sejam classificados adequadamente. O Microsoft Defender para Nuvem mostra recomendações e alertas, tipo de recurso baseado e sua gravidade, ambiente. A maioria dos alertas tem táticas MITRE ATT&CK® que podem ajudar você a entender a intenção de encerramento de cadeia. Verifique se você tem um plano de correção para investigar e atenuar o problema.

No AKS, você pode usar o Registro de Contêiner do Azure em combinação com a verificação contínua para identificar imagens e aplicativos vulneráveis em vários níveis de risco. É possível exibir resultados no Microsoft Defender para Nuvem.

Para obter mais informações, consulte Proteção de contêiner no Defender para Nuvem.

Requisito 6.2

Verificar se todos os componentes de sistema e software estão protegidos contra vulnerabilidades conhecidas instalando os patches de segurança aplicáveis distribuídos pelo fornecedor. Instale os patches de segurança essenciais no prazo de um mês a contar do lançamento.

Suas responsabilidades

• Para evitar ataques da cadeia de fornecedores de terceiros, verifique se todas as dependências são confiáveis. É importante que você escolha fornecedores que sejam confiáveis e respeitáveis.

• Semanalmente, o AKS fornece novas imagens para os pools de nós. Essas imagens não são aplicadas automaticamente. Aplique-as assim que estiverem disponíveis. Você pode atualizar manual ou automaticamente por meio da Atualização de Imagem do Nó. Para obter mais informações, confira Atualização de uma imagem de nó do AKS (Serviço de Kubernetes do Azure)

  Para o plano de controle do AKS, o AKS instala ou atualiza os patches de segurança.

• A cada 24 horas, os nós do AKS baixam e instalam automaticamente patches de segurança e do sistema operacional, individualmente. Seu firewall não deverá bloquear esse tráfego se você quiser receber essas atualizações.

  Considere habilitar recursos de relatório no agente de segurança para obter informações sobre as atualizações aplicadas. Algumas atualizações de segurança exigem reinicialização. Examine os alertas e tome medidas para garantir o tempo mínimo ou zero de inatividade do aplicativo com essas reinicializações. Uma opção de código aberto para executar reinicializações de maneira controlada é o Kured (daemon de reinicialização do Kubernetes).

• Estenda o processo de aplicação de patch para recursos fora do cluster que você provisiona, como jump boxes e agentes de build.

• Mantenha-se atualizado com as versões do AKS com suporte. Se o design usar uma versão que tenha atingido o fim da vida útil, atualize para uma versão atual. Para mais informações, confira Versões do AKS com suporte.

Requisito 6.3

Desenvolver aplicativos de software internos e externos (incluindo acesso administrativo baseado na Web aos aplicativos) com segurança, da seguinte maneira:

• De acordo com o PCI DSS (por exemplo, autenticação de segurança e registro em log)
• Com base em padrões e/ou melhores práticas do setor.
• Incorporar segurança da informação em todo o ciclo de vida de desenvolvimento de software. Isso se aplica a todos os softwares desenvolvidos internamente, incluindo software sob medida ou personalizado desenvolvido por terceiros.

Suas responsabilidades

Integre e priorize as opções de segurança como parte do ciclo de vida da carga de trabalho e das operações.

Várias estruturas do setor são mapeadas para o ciclo de vida, como a estrutura NIST. As funções NIST (Identificar, Proteger, Detectar, Responder e Recuperar) fornecem estratégias para controles preventivos em cada fase.

O SDL (Ciclo de Vida de Desenvolvimento de Segurança) da Microsoft fornece as melhores práticas, ferramentas e processos de segurança em todas as fases do processo de desenvolvimento. As práticas de SDL da Microsoft são seguidas para todos os serviços do Azure, incluindo o AKS. Também seguimos a estrutura do OSA (Garantia de Segurança Operacional) para serviços de nuvem operacionais. Verifique se você tem um processo semelhante. Essas práticas são publicadas para ajudar você a proteger seus aplicativos.

• SDL da Microsoft
• OSA da Microsoft

Requisito 6.3.1

Remover o desenvolvimento, o teste e/ou as contas de aplicativo personalizado, as IDs de usuário e as senhas antes que os aplicativos fiquem ativos ou sejam disponibilizados para os clientes.

Suas responsabilidades

Como parte da criação do cluster, vários usuários locais do Kubernetes são criados por padrão. Esses usuários não podem ser auditados porque não representam uma identidade exclusiva. Alguns deles têm privilégios altos. Desabilite esses usuários usando o recurso Desabilitar contas locais do AKS.

Para outras considerações, consulte as diretrizes no padrão oficial PCI-DSS 3.2.1.

Requisito 6.3.2

Examinar o código personalizado antes do lançamento na produção ou para os clientes a fim de identificar possíveis vulnerabilidades de codificação (usando processos manuais ou automatizados) para incluir o seguinte:

• As alterações de código são examinadas por indivíduos que não sejam o autor do código original e por indivíduos que tenham conhecimento sobre técnicas de revisão de código e práticas de codificação seguras.
• As revisões de código fazem com que o código seja desenvolvido de acordo com diretrizes de codificação seguras
• As correções apropriadas são implementadas antes do lançamento.
• Os resultados da revisão de código são analisados e aprovados pela gerência antes do lançamento.

Suas responsabilidades

Todos os softwares instalados no cluster são provenientes do Registro de contêiner. Semelhante ao código do aplicativo, ter processos e pessoas examinando o Azure e imagens de terceiros (DockerFile e OCI). Também:

• Inicie a verificação de imagens de contêiner dos estágios iniciais quando o cluster for criado. Torne o processo de verificação uma parte dos pipelines de integração contínua/implantação contínua.

  Verifique se os pipelines de implantação estão fechados de modo que as imagens de inicialização de cluster e sua carga de trabalho tenham passado por uma revisão e/ou portão de quarentena. Mantenha o histórico sobre como e quais processos foram usados antes de terem pull efetuado para o cluster.

• Reduza o tamanho da imagem. Normalmente, as imagens contêm mais binários do que o necessário. Reduzir o tamanho da imagem não só tem benefícios de desempenho, mas também limita a superfície de ataque. Por exemplo, o uso de imagens sem distribuição minimizará a superfície de ataque das imagens base do Linux.

• Use ferramentas de análise estática que verificam a integridade do Dockerfile e dos manifestos. As opções de terceiros incluem Dockle e Trivy.

• Use apenas imagens assinadas.

• Entenda (e aceite) a imagem base fornecida pelo Azure e como ela está em conformidade com os parâmetros de comparação do CIS. Para obter mais informações, confira Parâmetros de comparação do CIS (Center for Internet Security).

O Registro de Contêiner do Azure com a verificação contínua no Microsoft Defender para Nuvem ajudará a identificar imagens vulneráveis e vários riscos que isso pode representar para a carga de trabalho. Para obter mais informações sobre verificação de imagem e controle de risco, confira Segurança do contêiner.

Requisito 6.4

Seguir processos e procedimentos de controle de alterações para todas as alterações de componentes do sistema.

Suas responsabilidades

Certifique-se de documentar os processos de controle de alterações do documento e projetar os pipelines de implantação de acordo com esses processos. Incui outros processos para detectar situações em que os processos e os pipelines reais não se alinham.

Requisito 6.4.1, 6.4.2

• Separar ambientes de desenvolvimento/teste dos ambientes de produção e impor a separação com controles de acesso.
• Separação de funções entre ambientes de desenvolvimento/teste e produção.

Suas responsabilidades

Mantenha ambientes e funções de produção e pré-produção separados que operam nesses ambientes.

• Não use seu cluster de produção para fins de desenvolvimento/teste. Por exemplo, não instale o Bridge to Kubernetes em seus clusters de produção. Use clusters dedicados para cargas de trabalho que não são de produção.

• Verifique se os ambientes de produção não permitem acesso à rede a ambientes de pré-produção e vice-versa.

• Não reutilize identidades do sistema em ambientes de pré-produção e produção.

  Use grupos do Microsoft Entra para grupos como administradores de cluster ou entidades de pipeline. Não use grupos generalizados ou comuns como controles de acesso. Não reutilize esses grupos entre clusters de pré-produção e produção. Um modo é usar o nome do cluster (ou outro identificador opaco) no nome do grupo, para ser explícito em associações.

  Use as funções de RBAC (controle de acesso baseado em função) do Azure adequadamente entre ambientes. Normalmente, mais funções e direitos são atribuídos a ambientes de pré-produção.

  As identidades somente na pré-produção (concedidas a pipelines ou equipes de engenharia de software) não devem ter acesso na produção. Por outro lado, as identidades somente produção (como pipelines) não devem ter acesso a clusters de pré-produção.

  Não use a mesma identidade gerenciada pelo usuário para qualquer recurso em pré-produção e em produção. Essa recomendação se aplica a todos os recursos que dão suporte à identidade gerenciada pelo usuário, não apenas ao recurso implantado em seu cluster. Como regra, os recursos do Azure que exigem identidades devem ter sua própria identidade distinta em vez de compartilhá-la com outros recursos.

• Use o acesso JIT (just-in-time) para acesso de alto privilégio, inclusive em clusters de pré-produção, se possível. Use políticas de acesso condicional em clusters de pré-produção e produção.

Requisito 6.4.3

Os dados de produção (PANs dinâmicas) não são usados para teste ou desenvolvimento.

Suas responsabilidades

Verifique se os dados CHD não fluem para o ambiente de desenvolvimento/teste. Tenha uma documentação clara que forneça o procedimento para mover dados da produção para o desenvolvimento/teste. A remoção de dados reais deve ser incluída nesse procedimento e ser aprovada por partes responsáveis.

Requisito 6.4.4

Remoção de dados de teste e contas de componentes do sistema antes que o sistema se torne ativo ou entre em produção.

Suas responsabilidades

Remova dados de configuração padrão, dados de exemplo e dados de teste conhecidos no sistema antes de implantar em produção. Não use dados de titular do cartão para fins de teste.

Requisito 6.4.5

Os procedimentos de controle de alterações para a implementação de patches de segurança e modificações de software devem incluir o seguinte:

• 6.4.5.1 Documentação do impacto.
• 6.4.5.2 Aprovação da alteração documentada por pessoas autorizadas.
• 6.4.5.3 Testar a funcionalidade para verificar que a alteração não afeta negativamente a segurança do sistema.
• 6.4.5.4 Procedimentos de recuo.

Suas responsabilidades

Esses pontos das diretrizes são mapeados para os requisitos vistos acima:

• Documente as alterações de infraestrutura esperadas como resultado dos patches de segurança e modificações de software. Esse processo é mais fácil com a abordagem de IaC (infraestrutura como código). Por exemplo, com um arquivo Bicep ou um modelo do Azure Resource Manager (modelo ARM), você pode visualizar as alterações da implantação usando a operação de teste de hipóteses. Para obter mais informações, confira a Operação de teste de hipóteses de implantação do Bicep para suas alterações de infraestrutura.

• Implemente portões em seus pipelines de implantação que validem a aprovação de alterações para implantações regulares. Documente a justificativa para implantações de emergência em que os portões podem ter sido ignorados.

  Defina os níveis e a profundidade das alterações. Verifique se a equipe concorda com a definição de alterações significativas, em vez de pequenas alterações. Se for prático, automatize a descoberta de algumas dessas alterações. Os revisores da carga de trabalho, infraestrutura e pipeline devem ter uma compreensão clara dos níveis e validar esses critérios.

• Teste as funcionalidades de segurança. Verifique se as transações sintéticas estão testando as preocupações de segurança (permissão e negação). Verifique também se esses testes sintéticos estão em execução em ambientes de pré-produção.

• Tenha um processo de recuo caso uma correção de segurança tenha resultados inesperados. Uma estratégia comum é implantar mantendo o estado anterior usando implantações azul-verde. Para cargas de trabalho, incluindo bancos de dados, tenha uma estratégia que funcione para sua topologia específica e tenha o escopo de suas unidades de implantação.

Requisito 6.5

Lidar com vulnerabilidades de codificação comuns nos processos de desenvolvimento de software da seguinte maneira:

• Treinar os desenvolvedores pelo menos anualmente em técnicas de codificação seguras atualizadas, incluindo como evitar vulnerabilidades de codificação comuns.
• Desenvolver aplicativos com base em diretrizes de codificação seguras.

Suas responsabilidades

É fundamental que as equipes de aplicativos e as equipes de operações sejam instruídas, informadas e incentivadas para dar suporte às atividades de verificação da carga de trabalho e da infraestrutura. Aqui estão alguns recursos:

• Diretrizes de codificação segura
• DevOps seguro
• Recursos do Ciclo de Vida de Desenvolvimento Seguro

Requisito 6.6

Para aplicativos Web voltados para o público, enfrente novas ameaças e vulnerabilidades continuamente. Verifique se esses aplicativos estão protegidos contra ataques conhecidos por um dos seguintes métodos:

• Revise aplicativos Web voltados para o público usando ferramentas ou métodos manuais ou automatizados de avaliação de segurança de vulnerabilidade de aplicativos. Realize uma avaliação de vulnerabilidade pelo menos anualmente e após quaisquer alterações.

  Observação

  Essa avaliação não é a mesma coisa que as verificações de vulnerabilidade executadas como parte do Requisito 11.2.

• Instale uma solução automatizada que detecta e previne ataques baseados na Web. Por exemplo, um firewall de aplicativo web. Implante na frente de aplicativos Web voltados para o público e avalie ativamente todo o tráfego.

Suas responsabilidades

Faça verificações para detectar o tráfego proveniente da Internet pública usando um WAF (Firewall de Aplicativo Web). Nesta arquitetura, o Gateway de Aplicativo do Azure verifica todo o tráfego de entrada usando seu WAF integrado. O WAF é baseado em CRS (conjuntos de regras principais) do OWASP (Open Web Application Security Project). Se os controles técnicos não estiverem em vigor, tenha controles compensatórios. Um modo é por meio da inspeção manual de código.

Verifique se você está usando as versões mais recentes do conjunto de regras e aplique regras relevantes à sua carga de trabalho. As regras devem ser executadas no modo Prevenção. Você pode impor esse requisito adicionando uma instância do Azure Policy que verifica se o WAF está habilitado e está operando nesse modo.

Mantenha os logs gerados pelo WAF do Gateway de Aplicativo para obter detalhes sobre as ameaças detectadas. Ajuste as regras conforme necessário.

Realize testes de penetração focados no código do aplicativo. Dessa forma, os profissionais que não fazem parte da equipe de aplicativos encontrarão lacunas de segurança (como injeção de SQL e passagem de diretório) coletando informações, analisando vulnerabilidades e relatando. Neste exercício, os praticantes podem precisar de acesso a dados confidenciais. Para garantir que a intenção não seja mal utilizada, siga as diretrizes fornecidas nas Regras de Teste de Penetração da Participação.

Requisito 6.7

Garantir que políticas de segurança e procedimentos operacionais para desenvolver e manter sistemas e aplicativos de segurança estejam documentados, em uso e sejam do conhecimento de todas as partes afetadas.

Suas responsabilidades

É fundamental que você mantenha uma documentação completa sobre os processos e as políticas. Suas equipes devem ser treinadas para priorizar as opções de segurança como parte do ciclo de vida da carga de trabalho e das operações.

O SDL da Microsoft fornece as melhores práticas, ferramentas e processos de segurança em todas as fases do processo de desenvolvimento. As práticas de SDL da Microsoft são seguidas estritamente quando criamos software na Microsoft. Também seguimos a estrutura do OSA (Garantia de Segurança Operacional) para serviços de nuvem operacionais. Essas práticas são publicadas para ajudar você a proteger seus aplicativos.

• SDL da Microsoft
• OSA da Microsoft

Mantenha uma documentação completa para testes de penetração que descrevem o escopo do teste, os processos de triagem e a estratégia de correção para os problemas detectados. Se ocorrer um incidente, incorpore a avaliação do Requisito 6 como parte da análise de causa-raiz. Se forem detectadas lacunas (por exemplo, uma violação de regra OWASP será detectada), feche essas lacunas.

Na documentação, tenha diretrizes claras sobre o status de proteção de WAF esperado.

As pessoas que operam ambientes regulamentados devem ser instruídas, informadas e incentivadas para dar suporte às garantias de segurança. Isso é importante para as pessoas que fazem parte do processo de aprovação do ponto de vista da política.

Próximas etapas

Restringir o acesso aos dados do titular do cartão segundo a necessidade de conhecimento da empresa. Identificar e autenticar o acesso aos componentes do sistema. Restringir o acesso físico aos dados do titular do cartão.