Como atender ao requisito 6.6 do PCI DSS — uma solução dois em um da Threat Stack

F5

O Threat Stack agora é o F5 Distributed Cloud App Infrastructure Protection (AIP). Comece a usar o Distributed Cloud AIP com sua equipe hoje.

A versão atual do PCI DSS é a 3.2.1, publicada em maio de 2018. O Requisito 6 determina que você deve “Desenvolver e manter sistemas e aplicações seguros”. Claro, sem problema. Isso é totalmente claro e simples — pelo menos para quem nunca tentou desenvolver e manter sistemas e aplicações seguros! Para o restante de nós, é uma tarefa e tanto.

Mas o documento prossegue listando uma série de requisitos bastante simples — aspectos que já fazem parte da maioria dos ciclos de vida de desenvolvimento seguro de software. É preciso estabelecer um processo para identificar vulnerabilidades de segurança, corrigir vulnerabilidades conhecidas, adotar as melhores práticas de programação, separar de forma segura os ambientes e as contas de desenvolvimento e teste dos de produção, realizar revisões de código, implementar um processo de controle de alterações, capacitar os desenvolvedores em técnicas de programação segura e assim por diante. Tudo bastante razoável.

Um pouco mais abaixo desse requisito de alto nível — no Requisito 6.5 — são listadas diversas vulnerabilidades específicas contra as quais as aplicações devem ser protegidas. Trata-se de uma espécie de coletânea dos “maiores sucessos” do OWASP TOP 10, SANS CWE Top 25, CERT Secure Coding etc., e são exatamente o que se esperaria — injeção de SQL, criptografia fraca, XSS, estouros de buffer e afins. Mais uma vez, bastante razoável. Os invasores costumam explorar esses tipos de vulnerabilidade como ponto inicial de ataque.

Então, no Requisito 6.6, vem o ponto principal: “Para aplicações web voltadas ao público, trate continuamente novas ameaças e vulnerabilidades e garanta que essas aplicações estejam protegidas contra ataques conhecidos.” Quais ataques? A resposta é: “no mínimo, todas as vulnerabilidades do Requisito 6.5.” Pense nisso por um momento. Esse único requisito — o 6.6 —, escondido na página 64 do documento, tem um grande impacto na forma como desenvolvemos 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 manuais ou automatizados de avaliação de vulnerabilidades de segurança”
• Por meio do uso de “uma solução técnica automatizada que detecta e impede ataques baseados na Web”

Portanto, isso afeta tanto o momento da compilação quanto o tempo de execução de aplicações web e, na verdade, envolve duas atividades completamente diferentes:

1. Analisar aplicações para identificar proativamente a presença de vulnerabilidades (e, em seguida, garantir que sejam corrigidas)

– E –

2. Detectar e bloquear ataques em tempo real

Não é um requisito ruim. Como afirma a orientação, “aplicações web voltadas ao público são os principais alvos dos invasores, e aplicações web mal programadas oferecem a eles um caminho fácil para obter acesso a dados e sistemas confidenciais”. Concordo plenamente. O desafio está na implementação prática do requisito.

Não há muitas orientações sobre como realizar a primeira parte — a análise dos aplicativos. Os aplicativos devem ser analisados “usando ferramentas ou métodos manuais ou automatizados de avaliação de vulnerabilidades de segurança”. Isso é bastante abrangente.

A segunda parte traz uma recomendação um pouco mais específica. Você deve instalar “uma solução técnica automatizada que detecte e impeça ataques pela web (por exemplo, um firewall de aplicações web) à frente das aplicações web acessíveis ao público, para verificar continuamente todo o tráfego”. Isso foi uma bênção para os fornecedores de WAF, que de repente viram seus produtos se tornar uma compra feita apenas para “marcar uma caixinha” por equipes que buscavam atender ao Requisito 6.6. Mas um WAF não ajuda na primeira parte do requisito. Um WAF não é uma ferramenta de avaliação de segurança: ele não faz ideia do que uma aplicação faz nem de como ela funciona. Ele só entende o que está sendo enviado para uma aplicação — não o que a aplicação pode (ou não) fazer com essas informações.

Tudo isso faz com que muitas equipes tenham dificuldade para atender ao requisito 6.6 em sua totalidade. Esse pequeno requisito reúne duas necessidades importantes e bastante distintas. A maioria tentará atender à segunda parte com um WAF e combinará várias outras técnicas para tratar da primeira (revisões manuais de código, análise automatizada de código-fonte etc.).

Mas há uma alternativa capaz de atender ao Requisito 6.6 com uma única solução. Observe que o padrão PCI inclui a expressão “por exemplo” ao mencionar o WAF. Isso é significativo (e não constava nas versões anteriores do padrão). Essa expressão reconhece a existência de outras tecnologias capazes de proteger aplicações, desde que sejam “configuradas para bloquear ataques via web ou gerar um alerta que seja investigado imediatamente”. O Application Security Monitoring — a solução unificada de segurança de aplicações que a Threat Stack adicionou à sua Cloud Security Platform® sem custo adicional — abrange tanto os aspectos do Requisito 6.6 durante a fase de desenvolvimento quanto em tempo de execução. Uma única solução para esses dois grandes desafios.

Durante a compilação, você adiciona o microagente da Threat Stack às suas aplicações como faria com qualquer outra biblioteca de código de terceiros. Para os desenvolvedores, o processo é muito semelhante à instrumentação de aplicações com uma solução de APM. Depois que o microagente é adicionado, a aplicação é avaliada sempre que é executada — 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 a aplicação deve ser revisada “pelo menos uma vez por ano e após qualquer alteração”. A Threat Stack vai muito além disso, identificando vulnerabilidades de segurança continuamente — tudo sem que o desenvolvedor precise realizar nenhum trabalho adicional. Não é necessário criar testes nem administrar servidores.

Depois que uma vulnerabilidade é identificada, o Requisito 6.6 também determina que ela seja corrigida. Você deve garantir “que todas as vulnerabilidades sejam corrigidas e que a aplicação seja reavaliada após as correções”. O Threat Stack AppSec Monitoring fornece aos desenvolvedores orientações práticas sobre todos os riscos detectados — explicando o risco, apresentando um exemplo de código para corrigi-lo e indicando o módulo, o nome do método, o local do arquivo e o número da linha exatos em que ele foi encontrado. Depois que o desenvolvedor corrige a vulnerabilidade, não é necessário fazer nada especial para “reavaliar” — a aplicação será avaliada automaticamente na próxima vez que for executada.

Em tempo de execução, o requisito é “verificar continuamente todo o tráfego” para proteger a aplicação contra ataques conhecidos. O mesmo microagente do Threat Stack também faz isso. À medida que a aplicação é implantada do ambiente de desenvolvimento para o de produção, o microagente a acompanha (ele é incorporado à aplicação como uma dependência). A partir daí, ele analisa todos os payloads da Web enviados à aplicação em busca de indícios de ataque. Se um payload for considerado malicioso, a solicitação poderá ser interrompida imediatamente. As equipes são notificadas sobre o ataque pelo portal do Threat Stack, pelo Slack ou por outros canais de ChatOps. Isso atende diretamente ao requisito do PCI de “bloquear ataques baseados na Web ou gerar um alerta que seja investigado imediatamente”.

O PCI 6.6 é abrangente. A exigência de “lidar continuamente com novas ameaças e vulnerabilidades e garantir que essas aplicações estejam protegidas contra ataques conhecidos” abrange duas fases distintas do ciclo de vida de desenvolvimento de software (desenvolvimento e produção) e envolve duas tarefas diferentes (avaliação proativa de vulnerabilidades e detecção e prevenção de ataques em tempo real). Ambas são complexas e geralmente envolvem equipes diferentes. Mas você não precisa de duas ferramentas distintas para realizá-las. O Application Security Monitoring da Threat Stack atende aos dois requisitos com uma única solução que não reduz a produtividade dos desenvolvedores. Experimente hoje mesmo!

Se você quiser saber mais ou experimentar o Application Security Monitoring, inscreva-se para uma demonstração da Threat Stack Cloud Security Platform. Nossos especialistas em conformidade e segurança terão prazer em conversar sobre suas necessidades específicas.

Referência

Requisito 6.6 do PCI DSS, dos Requisitos e Procedimentos de Avaliação de Segurança, versão 3.2.1, maio de 2018

6.6 Para aplicações web voltadas ao público, trate continuamente novas ameaças e vulnerabilidades e garanta que essas aplicações estejam protegidas contra ataques conhecidos por meio de um dos seguintes métodos:

• Analisar aplicações web voltadas ao público por meio de ferramentas ou métodos manuais ou automatizados de avaliação de segurança de vulnerabilidades de aplicações, pelo menos uma vez por ano e após quaisquer alterações
• Instalar uma solução técnica automatizada que detecte e impeça ataques pela Web (por exemplo, um firewall de aplicações Web) à frente das aplicações Web voltadas ao público, para verificar continuamente todo o tráfego.

O Threat Stack agora é o F5 Distributed Cloud App Infrastructure Protection (AIP). Comece a usar o Distributed Cloud AIP com sua equipe hoje.

Sobre o autor

F5

Mais publicações de F5