Práticas recomendadas para conformidade com os requisitos de segurança de APIs do PCI DSS v4.0
A dificuldade de acompanhar a evolução das normas não é novidade para as equipes de segurança de TI. Pense em todas as organizações que determinaram uma abordagem para a conformidade com a Diretiva NIS (Network and Information Security) e se depararam com sua atualização: a NIS2. E ao pensar que mais de 130 jurisdições globais promulgaram leis de privacidade de dados com requisitos que podem mudar, não surpreende que apenas 9% dos executivos realmente acreditam que podem atender a todos os requisitos de divulgação.
Se você estiver se preparando para cumprir com os requisitos da versão 4.0 do Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS v4.0), é possível que também não esteja se sentindo tão confiante assim.
O PCI DSS, que foi criado pelo Payment Card Industry Security Standards Council (PCI SSC), tornou-se um padrão global de proteção de dados de pagamento. Se a sua empresa aceita os principais cartões de crédito e processa, armazena ou transmite dados de titulares de cartões eletronicamente, precisa cumpri-lo.
Os principais pontos do PCI DSS referentes à segurança
Os requisitos da versão original abrangem os principais pontos referentes à segurança que continuam sendo tão importantes quanto à época de sua publicação em 2006. Por exemplo:
Monitorar e controlar o acesso a todas as contas administrativas em qualquer sistema de TI que processe ou armazene dados de titulares de cartões
Atribuir o acesso a dados de sistemas e de titulares de cartões com base na necessidade absoluta e definir requisitos de acesso por função
As atualizações de hoje acompanham o ritmo dinâmico do cenário de ameaças
O problema é que o cenário de ameaças moderno é mais complexo do que o de 2006.
Sim, as organizações ainda devem lidar com a tendência dos invasores de visar áreas como contas privilegiadas e usuários com permissões excessivas. No entanto, as empresas modernas também precisam adaptar seus programas de conformidade para lidar com os invasores que frequentemente visam as milhares de APIs que fazem parte de tecnologias de pagamento. Esses invasores sabem que as APIs são fáceis de explorar e podem ser uma maneira eficiente de roubar dados de titulares de cartões.
Portanto, para cumprir com o PCI DSS v4.0, sua organização precisa entender as ameaças a APIs e se proteger contra elas. Nesta publicação do blog, compartilharemos insights sobre os riscos, os requisitos e as maneiras de estar em conformidade.
Os quatro objetivos principais do PCI DSS v4.0
No geral, o PCI DSS v4.0 concentra-se em quatro objetivos principais:
Continuar atendendo às necessidades de segurança do setor de pagamentos
Promover a segurança como um processo contínuo
Oferecer flexibilidade às empresas (por exemplo, novas ferramentas, novos controles) quanto às maneiras pelas quais elas atendem aos requisitos
Aprimorar os métodos e processos de validação
Por que a segurança de APIs é essencial para proteger os dados de titulares de cartões
O PCI DSS v4.0 estabelece, de maneira explícita, que as APIs são um aspecto central que requer visibilidade e proteção. Todos os quatro objetivos são relevantes. Mas o terceiro (a flexibilidade para usar novas ferramentas e controles), devido aos riscos específicos às APIs, é especialmente importante. Por exemplo:
as APIs estão no centro de seus produtos e serviços digitais voltados para os clientes. As empresas médias, dependendo do porte, têm entre 15 mil e 25 mil APIs, todas projetadas para facilitar uma troca ininterrupta de dados.
Esses dados incluem informações confidenciais de clientes. Para cada pagamento digital, há uma API nos bastidores, transmitindo dados entre aplicativos, sistemas, terceiros e muito mais.
Basta uma API comprometida para que milhões de registros sejam roubados, retidos para devolução mediante pagamento ou divulgados. E APIs expostas ou mal configuradas são predominantes, fáceis de sabotar e, muitas vezes, estão desprotegidas, sem supervisão e sem gerenciamento.
Por que as autoridades reguladoras se preocupam com as APIs de tecnologias de pagamento
As autoridades reguladores conhecem os riscos às APIs, e sua empresa deve mostrar que tem a visibilidade e os controles necessários para evitar que os dados sejam comprometidos.
Os dados de cartões de pagamento são comprometidos em mais de um terço (37%) das violações, de acordo com o Data Breach Investigations Report (Relatório de Investigação de Violações de Dados) de 2023 da Verizon. O PCI DSS v4.0 apresenta novos requisitos de autenticação multifator e tamanho de senhas para proteger o elemento humano da superfície de ataque do setor de pagamentos.
No entanto, é importante lembrar que as violações de dados nem sempre ocorrem por métodos de ataque bem divulgados e voltados às pessoas, como a prática de phishing de senhas de funcionários.
Por exemplo, 18% dos ataques a empresas de comércio eletrônico envolvem código mal-intencionado integrado a páginas da Web de processamento de cartões. Os invasores estão cada vez mais sofisticados, visando componentes não humanos e automatizados do ambiente de TI que geralmente não têm a proteção adequada, como as APIs.
Setenta e oito por cento das empresas sofreram um incidente de segurança relacionado a APIs, de acordo com nossa pesquisa. Com base na urgência das ameaças a APIs, o PCI DSS v4.0 inclui novas regras, diretrizes e práticas recomendadas de segurança de APIs. Vejamos o requisito 6.2.3 primeiro.
Conformidade com o requisito 6.2.3 do PCI DSS v4.0
O requisito 6.2.3 concentra-se na necessidade de as organizações avaliarem seu código personalizado de aplicativos (ou seja, aplicativos desenvolvidos por um fornecedor externo, mas não aplicativos comerciais padrão prontos para uso) para garantir que nenhuma vulnerabilidade esteja presente na produção.
Esse requisito serve como orientação para verificar se o software de uma organização usa os recursos (bibliotecas, estruturas, APIs etc.) de componentes externos com segurança. Isso diz respeito ao papel central que as APIs desempenham na cadeia de fornecimento de software mais ampla, assim como àquilo que é necessário para protegê-la.
As APIs se tornaram o método padrão de conectividade e troca de dados em ambientes modernos de aplicativos. Com isso em mente, proteger as APIs com uma abordagem de pré-produção (shift-left) e pós-produção (shield-right) é essencial para que sua empresa digital se torne resiliente a ataques.
Seis práticas recomendadas para segurança de APIs
Aqui estão seis práticas recomendadas para segurança de APIs para ajudar na conformidade com o requisito 6.2.3.
Verificar o uso de componentes baseados em APIs e sua postura de segurança (por exemplo, localizar quaisquer configurações incorretas que levem a vulnerabilidades, incluindo o uso de cifras de criptografia fracas, conforme descrito no padrão)
Validar o comportamento normal e esperado do uso de APIs e implementar controles para impedir que agentes suspeitos violem seus sistemas (por exemplo, verificar o comportamento do aplicativo para detectar vulnerabilidades lógicas)
Detectar estruturas de terceiros usadas para impulsionar suas APIs e determinar se alguma delas está desatualizada e vulnerável
Criar um inventário completo de todas as suas APIs, incluindo as versões diferentes das APIs que você está executando, o que trará informações sobre possíveis recursos e backdoors não documentados que você precisa gerenciar
Analisar a segurança do seu código de APIs e evitar reproduzir quaisquer vulnerabilidades relacionadas a APIs
Implementar práticas recomendadas de codificação segura de APIs, o que permitirá que você adote uma abordagem programática para entregar o código de forma segura e contínua
Requisitos adicionais de segurança de APIs no PCI DSS v4.0
O PCI SSC também adicionou ao PCI DSS v4.0 duas outras seções relacionadas à segurança de APIs. Este é um resumo dos dois requisitos adicionais que você precisará cumprir.
O requisito 6.3.2 diz respeito à manutenção de um inventário de softwares personalizados, e de componentes de softwares de terceiros incorporados aos softwares personalizados, para facilitar o gerenciamento de vulnerabilidades e correções.
O requisito 6.2.2 trata do treinamento de equipes de desenvolvimento de software que trabalham com software personalizado. Ele estabelece que os desenvolvedores precisam receber treinamento pelo menos uma vez a cada 12 meses quanto à segurança relevante para suas funções de trabalho, incluindo técnicas seguras de design e codificação de software. Esse treinamento inclui ferramentas de teste de segurança e como usá-las para detectar vulnerabilidades no software.
Como o Akamai API Security pode ajudar você a atender aos novos requisitos
Para cada requisito apresentado nesta publicação, o Akamai API Security (Noname Security) oferece a proteção de APIs de que as empresas precisam, não apenas para ajudar você a cumprir com o PCI DSS v4.0, mas também para proteger continuamente os dados que seus clientes confiaram a você.
