Como abordar o requisito 6.6 do PCI DSS — Uma solução dois por um da Threat Stack

A versão atual do PCI DSS é 3.2.1, publicada em maio de 2018. O requisito 6 afirma que você deve “Desenvolver e manter sistemas e aplicativos seguros”.  Claro, sem problemas. Isso é totalmente claro e direto — pelo menos para quem nunca tentou desenvolver e manter sistemas e aplicativos seguros! Para o resto de nós, isso é uma tarefa difícil. 

Mas o documento continua listando uma série de requisitos bastante simples — coisas que já são componentes da maioria dos ciclos de vida de desenvolvimento de software seguro. Você deve estabelecer um processo para identificar vulnerabilidades de segurança, abordar vulnerabilidades conhecidas, empregar as melhores práticas em codificação, separar com segurança os ambientes e contas de desenvolvimento e teste da produção, fazer revisões de código, ter um processo de controle de alterações, treinar desenvolvedores em técnicas de codificação segura e assim por diante. Tudo bastante razoável. 

Um pouco mais abaixo desse requisito de nível superior — no Requisito 6.5 — são listadas algumas vulnerabilidades específicas contra as quais os aplicativos devem ser protegidos. Esses são uma espécie de "maiores sucessos" do OWASP TOP 10, SANS CWE Top 25, CERT Secure Coding, etc., e são o que você esperaria — injeção de SQL, criptografia fraca, XSS, estouros de buffer e coisas do tipo. Mais uma vez, razoável. Os invasores têm como alvo confiável esses tipos de vulnerabilidades como um ponto inicial de ataque. 

Então, no Requisito 6.6, o mais importante: “Para aplicativos da web voltados ao público, aborde novas ameaças e vulnerabilidades continuamente e garanta que esses aplicativos estejam protegidos contra ataques conhecidos.” Quais ataques? Ele responde, “no mínimo, todas as vulnerabilidades no Requisito 6.5”. Pense nisso por um momento. Este único requisito — 6.6 — enterrado profundamente no documento na página 64 tem um grande impacto em como construímos e operamos software! Como eles propõem atender a esse requisito? A resposta tem duas partes:

• Revisando os aplicativos anualmente e após quaisquer alterações — usando “ferramentas ou métodos de avaliação de segurança de vulnerabilidades manuais ou automatizados”
• Ao utilizar “uma solução técnica automatizada que detecta e previne ataques baseados na web” 

Portanto, isso afeta tanto o tempo de construção quanto o tempo de execução de aplicativos da web e envolve duas atividades completamente diferentes:

1. Revisar aplicativos para encontrar proativamente a presença de vulnerabilidades (e, em seguida, garantir que sejam corrigidas)

- E - 

2. Detectando e bloqueando ataques em tempo real

Não é um requisito ruim. Conforme afirma a orientação, “aplicativos da web voltados ao público são alvos principais para invasores, e aplicativos da web mal codificados fornecem um caminho fácil para invasores obterem acesso a dados e sistemas confidenciais”. Não poderia concordar mais. O desafio está na implementação prática do requisito. 

Não há muita orientação sobre como realizar a primeira parte — revisar aplicativos. Os aplicativos devem ser revisados “usando ferramentas ou métodos de avaliação de segurança de vulnerabilidade manuais ou automatizados”. Isso é bem amplo. 

A segunda parte tem uma recomendação um pouco mais específica. Você deve instalar “uma solução técnica automatizada que detecte e previna ataques baseados na web (por exemplo, um firewall de aplicativo da web) na frente de aplicativos da web públicos, para verificar continuamente todo o tráfego”. Isso foi uma bênção para os fornecedores de WAF que de repente se viram como uma compra "de caixa de seleção" para equipes que buscavam satisfazer o Requisito 6.6. Mas um WAF não ajuda com a primeira parte do requisito. Um WAF não é uma ferramenta de avaliação de segurança: Ele não tem ideia do que um aplicativo faz ou como. Ele só entende o que está sendo enviado para um aplicativo — não o que o aplicativo pode (ou não) fazer com essas informações.

Tudo isso deixa muitas equipes com dificuldades para lidar com a totalidade do 6.6. Neste pequeno requisito há duas necessidades significativas e bem diferentes. A maioria tentará satisfazer a segunda parte com um WAF e reunirá uma série de outras técnicas para abordar a primeira (revisões manuais de código, análise automatizada de código-fonte, etc.). 

Mas há uma alternativa que pode satisfazer o Requisito 6.6 com uma única solução. Você notará que o padrão PCI inclui a frase “por exemplo” ao mencionar WAF. Isso é significativo (e não foi incluído em versões anteriores do padrão). Ele reconhece que existem outras tecnologias que podem proteger aplicativos, desde que sejam “configuradas para bloquear ataques baseados na web ou gerar um alerta que seja imediatamente investigado”.  O Application Security Monitoring — a solução unificada de segurança de aplicativos que o Threat Stack adicionou à sua Cloud Security Platform® sem custo extra — aborda os aspectos de tempo de construção e tempo de execução do Requisito 6.6. Uma solução para esses dois grandes desafios. 

No momento da compilação, você adiciona o microagente Threat Stack aos seus aplicativos, assim como qualquer outra biblioteca de código de terceiros. Os desenvolvedores acham isso muito semelhante a instrumentar seus aplicativos com uma solução APM. Depois que o microagente é adicionado, o aplicativo é avaliado toda vez que é executado — seja por meio de testes manuais locais, testes automatizados em uma compilação noturna, testes de aceitação do usuário e assim por diante. O PCI especifica que o aplicativo deve ser revisado “pelo menos anualmente e após quaisquer alterações”. O Threat Stack vai muito além disso para identificar vulnerabilidades de segurança continuamente — tudo isso sem que o desenvolvedor precise fazer nenhum trabalho extra. Não há testes para escrever nem servidores para administrar.

Depois que uma vulnerabilidade é identificada, o Requisito 6.6 também determina que ela deve ser abordada. Você deve garantir “que todas as vulnerabilidades sejam corrigidas e que o aplicativo seja reavaliado após as correções”. O Threat Stack AppSec Monitoring fornece aos desenvolvedores orientações práticas sobre quaisquer riscos detectados — explicando o risco, apresentando código de exemplo sobre como corrigi-lo e direcionando o desenvolvedor ao nome exato do módulo e método, ao local do arquivo e ao número da linha onde ele foi encontrado. Depois que o desenvolvedor corrige a vulnerabilidade, não há necessidade de fazer nada especial para “reavaliar” — o aplicativo será avaliado automaticamente na próxima vez que for executado. 

Em tempo de execução, o requisito é “verificar continuamente todo o tráfego” para proteger o aplicativo contra ataques conhecidos. O mesmo microagente Threat Stack também faz isso. À medida que o aplicativo é implantado do desenvolvimento para a produção, o microagente vai junto (ele é incorporado ao aplicativo como uma dependência). A partir daí, ele analisa todas as cargas úteis da web que são enviadas ao aplicativo para observar sinais de ataque. Se uma carga for determinada como maliciosa, a solicitação pode ser interrompida imediatamente. As equipes são notificadas sobre o ataque por meio do portal Threat Stack ou no Slack ou outros canais do ChatOps. Isso aborda diretamente o requisito do PCI de “bloquear ataques baseados na web ou gerar um alerta que seja imediatamente investigado”.

PCI 6.6 é importante. O mandato para “abordar novas ameaças e vulnerabilidades de forma contínua e garantir que esses aplicativos estejam protegidos contra ataques conhecidos” abrange duas fases separadas do ciclo de vida de desenvolvimento de software (desenvolvimento e produção) e envolve duas tarefas separadas (avaliação proativa de vulnerabilidades e detecção e prevenção de ataques em tempo real). Ambos são complexos e normalmente envolvem equipes diferentes. Mas você não precisa de duas ferramentas separadas para lidar com eles. O Application Security Monitoring da Threat Stack aborda ambos os requisitos com uma única solução que não deixará os desenvolvedores lentos. Experimente hoje mesmo!   

Se você estiver interessado em aprender mais ou quiser fazer um teste do Application Security Monitoring, inscreva-se para uma demonstração da Threat Stack Cloud Security Platform. Nossos especialistas em conformidade e segurança ficarão felizes em discutir suas necessidades específicas.