PCI DSS는 2004년에 주요 신용카드 회사가 수립한 일련의 보안 표준입니다. 결제를 처리하는 애플리케이션은 해커와 악의적인 행위자에게 매우 매력적인 표적이기 때문입니다.
목차
PCI DSS의 사명은 은행과 지불 카드 산업의 손실을 억제할 뿐만 아니라 소비자의 신뢰와 안전을 높이기 위해 신용카드와 직불카드 거래를 보호하는 것입니다. 이는 카드 데이터의 기밀성, 무결성 및 정확성을 보호하는 일련의 보안 제어를 통해 이루어집니다. 이 규정 준수 표준은 신용카드 데이터를 저장, 처리 및 전송하는 모든 조직에 적용됩니다. 적극 권장되지만 준수해야 할 의무는 없는 프레임워크인 NIST와 달리 PCI DSS를 반드시 준수해야 합니다.
PCI DSS 요구 사항
PCI DSS는 신용카드 데이터를 처리, 저장 또는 전송하는 조직이 안전한 환경을 유지할 수 있도록 6개의 제어 목표로 그룹화된 12개의 요구 사항으로 구성됩니다. 규정 준수는 카드 소지자 정보를 보호하고 전반적인 보안 조치를 강화하는 데 도움이 됩니다.
목표 #1: 보안 네트워크 유지
규칙 #1: 방화벽 설치 및 유지 관리
규칙 #2: 공급업체 기본 암호 또는 구성을 사용하지 마십시오.
목표 #2: 카드 소지자 데이터 보호
규칙 #3: 저장된 카드 소지자 데이터 보호
규칙 #4: 전송된 카드소유자 데이터 암호화
목표 #3: 취약점 관리 프로그램 유지
규칙 #5: 멀웨어로부터 보호
규칙 #6: 보안 시스템 개발 및 유지
목표 #4: 액세스 제어 관리
규칙 #7: 카드 소지자 데이터에 대한 액세스 제한
규칙 #8: 카드 소지자 데이터에 액세스할 수 있는 모든 사람을 고유하게 식별
규칙 #9: 카드 소지자 데이터에 대한 물리적 액세스 제한
목표 #5: 네트워크 모니터링 및 테스트
규칙 #10: 카드 소지자 데이터에 대한 모든 액세스 추적 및 모니터링
규칙 #11: 시스템 보안 테스트
목표 #6: 정보 보안 정책 유지
규칙 #12: 조직 내에서 정보 보안 정책 생성 및 시행
또한 처리된 신용카드/직불카드 거래의 연간 횟수에 따라 4가지 규정 준수 수준이 있습니다. 분류는 조직이 규정을 준수하기 위해 해야 할 일을 결정합니다.
레벨 1: 연간 600만 건 이상의 거래- 요구 사항: 공인 PCI 감사자가 수행하는 연례 내부 감사. 또한 분기에 한 번 승인된 스캔 벤더(ASV)가 PCI 스캔을 완료해야 합니다.
레벨 2: 연간 100만~600만 건의 거래- 요구 사항: 자체 평가 설문지(SAQ)를 사용하여 연례 평가를 완료합니다. 분기별 PCI 스캔이 필요할 수 있습니다.
레벨 3: 연간 20,000-100만 건의 거래- 요건: 연례 자체 평가 및 잠재적으로 분기별 PCI 스캔.
레벨 4: 연간 20,000건 미만의 거래- 요구 사항: 연례 자체 평가 및 잠재적으로 분기별 PCI 스캔.
PCI DSS 규정 준수가 중요한 이유
조직의 모든 사람은 규정 준수를 유지하는 데 역할을 합니다. CISO에서 시작하여 SecOps 및 DevOps 팀으로 속입니다. 이상적인 DevSecOps 세계에서는 두 팀 사이에 보안 책임 계층이 없습니다. 이들은 서로 협력하여 일합니다. SecOps는 DevOps 팀이 무엇을 해야 하는지 이해할 수 있도록 지원해야 하며 개발자는 애플리케이션 수준에서 이를 실행해야 합니다.
12가지 PCI DSS 요구 사항에 따라 지속적인 규정 준수가 팀 노력인 방법의 몇 가지 예를 들어보겠습니다.
규칙 #6: 개발자는 보안을 염두에 두고 시스템을 구축해야 합니다.
규칙 #8: ID 및 액세스 관리는 모든 사용자에게 고유한 사용자 ID 요구 사항 8을 할당해야 합니다.
규칙 #9: 물리적 보안 부서는 건물 및 서버실에 대한 접근이 통제되도록 해야 합니다.
규칙 #10: 보안 운영은 카드 소지자 데이터에 대한 액세스를 기록하고 추적하기 위해 로그가 생성되도록 보장해야 합니다.
규칙 #11: 운영 및 개발 팀은 서버와 소프트웨어를 테스트하기 위해 협력해야 합니다.
규칙 #12: 경영진은 비즈니스에서 달성해야 하는 정보 보안 및 규정 준수 수준을 자세히 설명하는 정책 및 관련 문서를 개발해야 합니다.
이 모든 것은 모두가 규정을 준수하는 데 중요한 역할을 합니다. 조직의 더 큰 장점뿐만 아니라 효율적으로 구축하고 배포할 수 있으며 앱 실행 후 10,000개의 SOS Slack 알림을 받지 못할 것이라는 확신을 가질 수 있습니다.
말씀드렸듯이 여러분의 책임은 주로 애플리케이션 수준에 있습니다. 여기에는 안전한 소스 코드 사용, CI/CD 파이프라인에 대한 적절한 구성 보장 등이 포함됩니다. 다음과 같은 생각을 하고 있을 수 있습니다. 알겠습니다. 하지만 어떻게 해야 할까요? 좋은 소식은 밴드 에이드를 줄이기 위해 신경외과 의사가 될 필요가 없는 것처럼 보안 또는 규정 준수 위즈가 될 필요가 없다는 것입니다. 이는 적절한 자원을 알고 적용하는 것입니다(예: 상처 위에 냅킨을 테이프로 붙이는 대신 밴드 에이드).
잘못된 구성을 방지하기 위해 클라우드 서비스 제공업체(CSP)의 문서 사이트를 확인할 수 있습니다. 그러나 이 모든 정보를 읽는 데에는 너무 많은 시간이 소요될 수 있습니다. 이러한 경우 자동화가 포함된 보안 솔루션을 사용하는 것이 좋습니다(권장 사항 아님).
첫 번째 위반은 1억 600만 건의 신용카드 신청을 노출시키고 미국 규제 당국으로부터 8천만 달러의 벌금을 부과한 자본 1 해킹입니다. 몇 가지 다른 위반 사항과 PCI DSS 규칙 및 목표를 참조하여 이를 피할 수 있었던 방법을 살펴보겠습니다.
취미 로비
2021년 초,Hobby Lobby는 해킹을 당했습니다. Boogeyman이 파악한 핸들을 사용하는 독립 연구원. 그는 30만 명 이상의 Hobby Lobby 고객의 민감한 정보가 포함된 Amazon Web Services(AWS)의 공개적으로 액세스 가능한 데이터베이스를 발견했습니다. 데이터베이스의 크기는 138GB였으며 고객 이름, 주소, 전화번호 및 카드 정보 일부를 가지고 있었습니다. 동일한 데이터베이스에서 이상하게도 회사 앱의 소스 코드였는데, 이는 모두 또 다른 문제입니다.
침해는 공개적으로 액세스할 수 있는 잘못 구성된 클라우드 데이터베이스의 결과였습니다. 이는 PCI DSS 규칙 #3, #7 및 #9의 명백한 위반입니다. 지불 카드 데이터가 열린 서버에 저장되고 있기 때문입니다. 또한 Hobby Lobby는 카드 소지자 데이터 및 관련 네트워크 리소스에 대한 액세스를 추적하고 모니터링해야 한다고 규정하는 규칙 #10을 준수하지 못했습니다. 이것은 분명히 일어나지 않았습니다. 그렇지 않으면 잘못된 구성이 해결되었을 것이고 전체 거래는 궁극적으로 피할 수 있었습니다.
Macy’s
주요 소매업체는 2019년 10월에 내 계정 지갑 페이지에서 온라인 체크아웃 시스템을 사용한 고객의 지불 카드 번호, 보안 코드 및 만료일을 노출한 위반을 겪었습니다. Macy’s는 영향을 받은 고객 수를 공개하지 않았지만, 소매업체는 해당 연도 4월까지 5,570만 건의 월간 온라인 방문을 기록했습니다. 솔직히 말해서 한 고객의 정보를 훔치는 것만으로도 충분합니다.
이 침해는 체크아웃 및 지갑 페이지에 멀웨어를 주입한 표적 마지카트 공격으로 인해 발생했습니다. Macy’s는 PCI DSS 규칙을 위반한 것이 분명했으며, 더 우려되는 점은 Magecart가 잘 알려져 있다는 사실입니다. 실제로 Macy’s는 FILA, Ticketmaster, British Airways 등 올해 많은 피해자 중 하나였습니다. 다른 주요 소매업체에 대한 이전 공격은 Macy’s가 보안 감사를 실행하고 PCI DSS에서 요구하는 취약점을 해결하도록 동기를 부여했어야 합니다.
제품 관리 부사장인 Scott Sargeant는 사이버 보안 및 IT 환경에서 엔터프라이즈급 솔루션을 제공한 25년 이상의 경험을 가진 노련한 기술 리더입니다.