PCI DSS é um conjunto de padrões de segurança estabelecido em 2004 por grandes empresas de cartão de crédito porque, sem surpresa, aplicações que processam pagamentos são alvos altamente atraentes para hackers e agentes maliciosos.
Índice
A missão do PCI DSS é proteger transações com cartões de crédito e débito não apenas para reduzir perdas para bancos e a indústria de pagamento, mas para aumentar a confiança e a segurança do consumidor. Isso é alcançado por meio de um conjunto de controles de segurança que protegem a confidencialidade, integridade e precisão dos dados do cartão. Este padrão de conformidade se aplica a toda organização que armazena, processa e transmite dados de cartão de crédito. Ao contrário do NIST, que é um framework que você é fortemente encorajado, mas não obrigado a seguir, você absolutamente deve cumprir o PCI DSS.
Requisitos PCI DSS
PCI DSS consiste em 12 requisitos agrupados em seis objetivos de controle, garantindo que organizações que processem, armazenem ou transmitam dados de cartão de crédito mantenham um ambiente seguro. A conformidade ajuda a proteger informações de titulares de cartão e reforçar as medidas gerais de segurança.
Objetivo nº 1: Construir e manter uma rede segura
Regra nº 1: Instalar e manter um firewall
Regra nº 2: Não usar senhas ou configurações padrão de fornecedores
Objetivo nº 2: Proteger dados do titular do cartão
Regra nº 3: Proteger dados armazenados do titular do cartão
Regra nº 4: Criptografar dados transmitidos do titular do cartão
Objetivo nº 3: Manter um programa de gerenciamento de vulnerabilidades
Regra nº 5: Proteger contra malware
Regra nº 6: Desenvolver e manter sistemas seguros
Objetivo nº 4: Gerenciar controle de acesso
Regra nº 7: Restringir acesso a dados do titular do cartão
Regra nº 8: Identificar exclusivamente todos que têm acesso a dados do titular do cartão
Regra nº 9: Restringir acesso físico a dados do titular do cartão
Objetivo nº 5: Monitorar e testar redes
Regra nº 10: Rastrear e monitorar todo acesso a dados do titular do cartão
Regra nº 11: Testar a segurança do sistema
Objetivo nº 6: Manter uma política de segurança da informação
Regra nº 12: Criar e aplicar uma política de segurança da informação dentro da organização
Também existem quatro níveis de conformidade, dependendo do número anual de transações de cartão de crédito/débito processadas. A classificação determina o que a organização precisa fazer para permanecer em conformidade:
Nível 1: Acima de 6 milhões de transações/ano – Requisito: Auditoria interna anual conduzida por um auditor PCI autorizado. Além disso, devem completar um scan PCI por um Approved Scanning Vendor (ASV) uma vez por trimestre.
Nível 2: 1–6 milhões de transações/ano – Requisito: Completar uma autoavaliação usando um Self-Assessment Questionnaire (SAQ). Um scan PCI trimestral pode ser necessário.
Nível 3: 20.000–1 milhão de transações/ano – Requisito: Autoavaliação anual e potencialmente um scan PCI trimestral.
Nível 4: Menos de 20.000 transações/ano – Requisito: Autoavaliação anual e potencialmente um scan PCI trimestral.
Por que a Conformidade PCI DSS é Importante
Todos na organização desempenham um papel na manutenção da conformidade. Isso começa no topo com os CISOs e depois se estende para as equipes de SecOps e DevOps. Em um mundo DevSecOps ideal, não há hierarquia na responsabilidade de segurança entre as equipes — elas trabalham em conjunto. SecOps deve ajudar as equipes de DevOps a entender o que precisam fazer, e os desenvolvedores devem executar isso no nível de aplicação.
Seguindo os 12 requisitos PCI DSS, aqui estão alguns exemplos de como a conformidade contínua é um esforço em equipe:
Regra nº 6: Os desenvolvedores devem criar sistemas com segurança em mente
Regra nº 8: O gerenciamento de identidade e acesso deve atribuir a cada usuário um id exclusivo – requisito oito
Regra nº 9: O departamento de segurança física deve garantir que o acesso ao prédio e às salas de servidores seja controlado
Regra nº 10: As operações de segurança devem garantir que logs sejam criados para registrar e rastrear acesso a dados do titular do cartão
Regra nº 11: As equipes de operações e desenvolvimento devem trabalhar juntas para testar servidores e software
Regra nº 12: A gestão deve desenvolver políticas e documentos associados para detalhar o nível de segurança da informação e conformidade que deve ser alcançado em seu negócio
Tudo isso para dizer — todos desempenham um papel em manter a conformidade. Não apenas pelo bem maior da organização, mas para que você possa criar e implantar com eficiência e com confiança de que não vai receber 10.000 alertas SOS do Slack depois que seu aplicativo for lançado.
Como dissemos, sua responsabilidade está principalmente no nível da aplicação. Isso inclui usar código-fonte seguro, garantir configurações adequadas para seu pipeline CI/CD e muito mais. Você pode estar pensando: Ok, mas como devo fazer isso? A boa notícia é que você não precisa ser um especialista em segurança ou conformidade, assim como você não precisa ser neurocirurgião para colocar um curativo em um corte. Tudo se resume a conhecer e aplicar os recursos adequados (como um Band-Aid em vez de colar um guardanapo no ferimento).
Para evitar configurações incorretas, você pode consultar o site de documentação do seu provedor de serviços em nuvem (CSP). No entanto, ler todas essas informações pode ser muito demorado. Se esse for o caso, sugerimos (ou melhor, recomendamos fortemente) usar uma solução de segurança com automação.
A primeira violação que me vem à mente é o ataque da Capital One que expôs 106 milhões de solicitações de cartão de crédito e levou a uma multa de U$80 milhões de reguladores dos EUA. Vamos analisar algumas outras violações e como elas poderiam ter sido evitadas seguindo as regras e objetivos do PCI DSS.
Hobby Lobby
No início de 2021, a Hobby Lobby foi hackeada. Um pesquisador independente que usa o codinome Boogeyman identificou a violação. Ele descobriu um banco de dados publicamente acessível na Amazon Web Services (AWS) que continha informações sensíveis de mais de 300.000 clientes da Hobby Lobby. O banco de dados tinha 138GB e continha nomes de clientes, endereços, números de telefone e detalhes parciais do cartão. Curiosamente, no mesmo banco de dados estava o código-fonte do aplicativo da empresa, o que já é outro problema.
A violação foi resultado de um banco de dados em nuvem mal configurado que estava publicamente acessível. Esta é uma violação clara das regras nº 3, nº 7 e nº 9 do PCI DSS, porque os dados de pagamento estavam sendo armazenados em um servidor aberto. A Hobby Lobby também falhou em cumprir a regra nº 10, que afirma que o acesso a dados do titular do cartão e a recursos relevantes da rede deve ser rastreado e monitorado. Isso claramente não estava acontecendo; caso contrário, a má configuração teria sido corrigida e toda a violação teria sido evitada.
Macy’s
O grande varejista sofreu uma violação em outubro de 2019, que expôs números de cartões de pagamento, códigos de segurança e datas de expiração de clientes que usaram o sistema de checkout on-line com a página de carteira My Account. Embora a Macy’s não tenha revelado o número de clientes afetados, o varejista registrou 55,7 milhões de visitas mensais on-line até abril daquele ano. E, para ser sincero, roubar a informação de apenas um cliente já é motivo de preocupação.
A violação ocorreu devido a um ataque Magecart direcionado que injetou malware nas páginas de checkout e carteira. A Macy’s estava evidentemente em violação de várias regras PCI DSS, e o mais preocupante é o fato de que Magecart é bem conhecido. De fato, a Macy’s foi apenas uma das muitas vítimas naquele ano, incluindo FILA, Ticketmaster, British Airways e outras. Ataques anteriores contra outros grandes varejistas deveriam ter motivado a Macy’s a realizar auditorias de segurança e corrigir quaisquer vulnerabilidades conforme exigido pelo PCI DSS.
Scott Sargeant, Vice-Presidente de Gerenciamento de Produto, é um experiente líder em tecnologia com mais de 25 anos de experiência em fornecer soluções corporativas em todo o cenário de Cibersegurança e TI.