다음을 위해 설계된 보안 코딩 교육
PCI DSS 4.0.1 요구사항 6.2.2

감사인이 실제로 증거로 요청하는 것

6.2.2를 살펴보는 QSA는 세 가지 문서적 흐름을 원합니다. 첫 번째는 할당입니다 — 누가 범위에 포함되고, 그들에게 무엇이 할당되었으며, 역할-커리큘럼 매핑이 어떻게 결정되었는지입니다. 두 번째는 이수입니다 — 타임스탬프, 점수 또는 통과 상태, 이수된 콘텐츠의 버전을 포함한 개발자별 기록입니다. 세 번째는 콘텐츠 통화입니다 — 커리큘럼이 현재의 취약점 유형을 반영하고 있으며 이전 평가 이후 자료 업데이트가 반영되었다는 증거입니다.

팀 수준에서 단일 연간 이수 보고서를 생성하는 프로그램은 어려움을 겪을 것입니다. 버전 스탬프가 찍힌 콘텐츠 참조와 함께 학습자별 기록을 내보내는 프로그램은 그렇지 않을 것입니다. 기준은 얼마나 많은 교육을 제공했는지가 아닙니다. 이름이 명시된 개발자가 롤링 12개월 기간 내에 이름이 명시된 콘텐츠를 이수했음을 얼마나 깔끔하게 입증할 수 있는지입니다.

SecureCodingHub가 12.6.1 대 6.2.2에 매핑되는 방식

이 두 요구사항은 일상적으로 혼동됩니다. 그래서는 안 됩니다. 요구사항 12.6.1은 모든 인력 — 피싱, 비밀번호 위생, 물리적 보안, 사고 보고 — 을 위한 일반 보안 인식 교육입니다. 대상은 역할에 관계없이 카드 소지자 데이터 또는 이를 다루는 시스템에 접근할 수 있는 모든 사람입니다. 요구사항 6.2.2는 특히 소프트웨어 개발 인력을 위한 보안 코딩 교육으로, 요구사항 자체에 언어별, 역할 관련성, 실습 특성이 명시되어 있습니다.

SecureCodingHub는 6.2.2를 다룹니다. 단독으로 12.6.1을 충족시키지는 않으며, 저희는 이를 일반 인식 플랫폼으로 마케팅하지 않습니다. 광범위한 인원에 대해 12.6.1 인식 벤더를 사용하고 개발자 인원에 대해 SecureCodingHub를 사용하는 프로그램은 한 도구가 설계되지 않은 작업을 하도록 강요하지 않고도 두 요구사항을 모두 다룹니다.

일반적인 범위 설정 실수

가장 빈번한 범위 설정 오류는 운영 환경을 향한 서비스를 소유한 엔지니어만 교육하고 인접 팀을 제외하는 것입니다. 내부 도구, 배치 작업, 통합 코드, 또는 카드 소지자 데이터 환경으로 흘러 들어가는 공유 라이브러리를 작성하는 개발자도 그들의 코드가 해당 환경에 영향을 미칠 수 있다면 여전히 6.2.2 범위에 포함됩니다. 범위는 엔지니어가 조직도에서 어디에 위치하느냐가 아니라, 그 코드가 다루는 시스템에 따라 결정됩니다.

두 번째 실수는 계약직 및 임시 엔지니어링 인력을 제외하는 것입니다. 계약직 직원이 CDE에서 실행되는 코드를 커밋한다면 그들은 범위에 포함됩니다. 계약 관계는 요구사항을 변경하지 않습니다. 깔끔한 프로그램은 직원과 계약직 모두에 동일한 커리큘럼 할당 로직을 적용하는 단일 명부를 갖습니다.

세 번째는 교육을 연간 행사로 취급하는 것입니다. 롤링 12개월 통화 기간은 가차없습니다. 평가 13개월 전에 커리큘럼을 이수한 개발자는 작년에 완전히 교육받았더라도 해당 평가 주기에 대해 비준수입니다. 교육을 연 1회 캠페인으로 일정 잡는 프로그램은 신입사원과 역할 변경에 대해 통화에서 벗어나는 경향이 있습니다. 12개월 경계에서 자동 재교육이 이루어지는 지속적인 할당이 개입 없이 두 번째 주기까지 살아남는 유일한 패턴입니다.