국내 PCI DSS 인증업체목록

현재까지 국내에서 PCI DSS 인증을 통과한것으로 여겨지는 업체 목록입니다.

PayGate (www.paygate.net)
KSNET (www.ksnet.co.kr)
FirstData (www.firstdatacorp.co.kr)
NICE (www.nicevan.co.kr)
Smartro (www.smartro.co.kr)
KISVAN (www.kisvan.co.kr)
KOVAN (www.kovan.co.kr)
KCP (www.kcp.co.kr)
StarVAN (www.starvankorea.com)
LGDacom (www.lgdacom.net)
KOCES (www.koces.com)
JTNET (www.jtnet.co.kr)
AllAt (www.allat.co.kr)
INICIS (www.inicis.co.kr)
CyberPass (www.cyberpass.com)
HyoSung (www.hyosung.com)

총 16개 업체인데
이중 일부는 실사를 받기는 하였지만 100% Full Compliant 달성하지 못한 업체도 있을것으로 예상됩니다.

대부분 VAN및 PG사들이고 대형쇼핑몰업체는 아직 목록에 없군요.

PCI DSS version 1.1과 1.2 차이 요약

1.1과 1.2 두 버전간의 차이점에 대한 요약입니다.

모든 변경사항에 대한 비교 정보는
https://www.pcisecuritystandards.org/pdfs/pci_dss_summary_of_changes_v1-2.pdf
에서 확인가능합니다.

1.1.5~7까지의 requirements가 1.1.5 하나로 통합되었습니다.
실제 준비해나가다 보면 firewall configuration을 protocol 종류별로 따로 구분 관리하지는 않으므로 자연스러운 개선입니다.

1.1.8에서는 firewall ruleset 정기점검을 과거 분기 한번할것을 6개월에 한번 하면 되는것으로 완화되었습니다.

2.1.1에서는 WEP 무선보안 방식의 사용을 이제는 사실상 금지하도록 강화되었습니다. (WEP 사용금지는 4.1.1에서 다시한번 언급됩니다. 이미 WEP을 사용하고 있더라도 2010년 6월 30일까지는 폐기하도록 강요하는군요)
그리고 SSID broadcast가 다시 허용되는군요.

4.2에서는 예전 E-Mail Security만 언급하던데서 확장하여 End-User Messaging technologies로 정의하면서 여기에 E-Mail, Instant messaging, chat등이 포함되는군요.

6.5에서 최신 OWASP 10대 보안취약점에 대한 사항이 대폭 반영되었습니다.
버전 1.1에서는 OWASP 2004년도 버전을 기반으로 하였다면 1.2에서는 OWASP 2007년 버전으로 개편되었군요.

9.5 백업 미디어 체크는 최소한 1년에 한번 하도록 명시되었습니다.

11.1에서는 Wireless IDS/IPS 구현에 대한 옵션이 추가되었군요. 조만간 이것도 의무화될것으로 예상됩니다.

11.4 IDS/IPS적용 범위를 모든 네트웍 트래픽에서 카드정보저장 환경에 대한 트래픽으로 범위가 줄었습니다. (비용절감)

12.3에서는 근로자의 정보기기 사용통제에 대한 범위가 좀더 명확해졌습니다. (원격접근, 무선기기, 휴대용미디어, 이메일사용, 인터넷 사용, 랩탑, PDA등)

12.3.*의 모뎀 관련된 규정은 "Remote Access Technologies"로 변경되었군요. 모뎀은 사용하지 않아서 그냥 pass했었는데 챙겨봐야할 규정이 늘었습니다.

기타 다른 변경사항들도 많지만 Impact가 느껴지는 조항들은 앞서 언급한것들이군요.

PCI DSS version 1.2

얼마전 새로 발표된 PCI DSS version 1.2 입니다.
2008년 10월 1일자로 기존 버전 1.1을 대치하게 되며
버전 1.1은 2008년 12월 31일까지만 유효하군요.

https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html

QSA관련

QSA(Qualified Security Assessor)는 개인을 지칭하는 용어이자 회사를 의미합니다.

PCI DSS인증과정에서는 꼭 현장 실사를 거치게 되는데
이때 직접 실사를 나오는 개인이 QSA자격을 가지고 있는 사람이어야합니다.

그런데 QSA는 개인이 자기혼자 딸 수 있는건 아니고 꼭 회사의 직원일 경우에만 QSA로 인정받을 수 있습니다.

회사가 하는 역할중 중요한 것은 직원인 QSA의 신뢰성에 대한 보장을 보험으로 제공해야하며
보험가액이 $1,000,000은 됩니다.
보험은 그외에도 다른 요구사항들을 커버합니다.

이렇게 회사와 직원이 아주 밀접하게 결합되어 하나의 QSA가 탄생됩니다.

직원인 QSA는 PCI 위원회에서 개최하는 교육가서 교육받고 시험치르고 통과해야합니다.
CISSP, CISA, CISM중 하나라도 자격증이 있으면 몇가지 혜택이 있군요.

전세계 모든 QSA 목록은 PCI SSC website에서 제공합니다.
https://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf

QSA별 비지니스 지역이 표시되어 있고 연락처도 있습니다.
국내에서는 A3 Security가 확인되는군요.

한가지 확인할것은 Supported Languages항목을 보면 Korean을 지원하는 QSA가 상당히 됩니다.

페이게이트 인증을 담당한 ControlCase Inc.(www.controlcase.com)도 그중 한 회사이지요.

PCI 위원회에서는 실사를 거친후 보고서를 요구하는데 이 보고서 언어는 무조건 영어여야한다고 못박고 있습니다.

QSA를 통한 인증과정은 대략 아래와 같습니다.
회사는 Requirements에 대한 확인 및 필요시 보완한이후
각각에 대한 증빙(Evidence)를 준비하여 QSA에게 review를 요청합니다.
QSA의 review이후 evidence를 확정하고
모든 evidence가 100% 준비된것 확인하고 실사하러 옵니다.
실사에서는 evidence가 사실인지 여부를 비교하고 remote로는 확인이 불가한 항목들에 대해서 확인을 진행합니다.
예를 들어 카드번호가 암호화되어 있다는 증빙을 screenshot떠서 보내면 나중에 와서 sample data에 대해서 직접 cardnumber search를 해보고 없음을 확인하는 식입니다.
이렇게 실사를 거치고 돌아가서 RoC (Report on Compliance)를 준비합니다.
RoC는 Evidences와 함께 또다른 QSA에 의한 Cross 검증을 진행한 후 확정합니다.
확정된 RoC는 피인증업체에 제공되고 PCI 위원회에도 보고됩니다.

Log Management

로그관리는 어렵고 재미있고 비지니스에도 도움이 됩니다.

로그 종류는 통상 3가지 정도 됩니다.
- Windows Event Log
- Syslog
- snmp trap message

로그를 남기는 object들은 아래 목록에 대부분 포함됩니다.
- OS
- Web Server와 같은 common application
- 각종 network devices (무선 장비 포함)
- 자체 application

[file integrity check]
로그내용이 중간에 제3자가 임의로 변경하지 못하도록 하기 위하여
권한설정도 철저해야하며
또한 로그내용의 변경여부를 감지할 수 있어야합니다.
로그파일의 특성상 항상 내용이 기록되고 있어 이에 대응되도록 file integrity checking software를 설정해야합니다.
tripwire가 대표적인 tool이긴 한데 windows용으로는 다루기 어렵고
상용은 비싸고 너무 무겁습니다.
ossec(www.ossec.net)을 권장합니다. unix나 windows모두 커버가능하며 가볍로 로그분석이나 Host based IDS역할을 함께 수행합니다.

[central log server]
로그를 중앙 집중 관리하는것이 PCI DSS의 요구사항중 하나입니다.

일반적인 syslog를 사용하면 각 개별서버에서 1차 집중 서버로 로그를 모으는것은 가능한데 여기서 다시 다른 통합 서버로 log forwarding이 잘 안됩니다.
rsyslog가 이러한 요구사항에 아주 잘 대응되는 무료 서버입니다.
각 서버들에서 네트웍 단위별 rsyslog 서버로 로그를 모으로 다시 여기서 중앙 log server로 forwarding하는등의 구성이 아주 간단합니다.

windows event log까지 통합 관리하기 위해서는
상용 tools이 필요하며
여기에는 Cisco MARS나 GFI EventsManager등을 이용할 수 있습니다.

중앙 로그 서버에 모인 로그는 3개월간의 데이터까지는 상시 검색 가능해야하며(PCI DSS 1.2에서 변경된 항목임)
백업본은 1년 보관해야합니다.

로그 flow를 살펴보면 다음 단계를 거치게 됩니다.

1. 개별 OS, Application에서 네트웍 단위 로그서버로 로그 집중
2. 소단위 로그서버에서 중앙 로그서버로 로그 집중
3. 중앙 로그서버에서는 3개월까지 로그검색 가능해야함
4. 중앙 로그서버의 로그는 백업된다면 1년 보관.

Patch Management

소프트웨어 업데이트 또는 패치 관리는 Windows계열, Unix 계열으로 구분하여 대응이 필요합니다.

Windows 계열 OS인 경우 WSUS등이 우선 검토 대상입니다.

patch management가 중요하면서도 어려운 이유중 하나는

LAN구간의 서버들은 외부 인터넷과의 직접 접근이 엄격히 제한되는데
자동 패치를 위하여 서버들이 인터넷에 통상 접근하여 업데이트하는 방식과 상충됩니다.

DMZ구간등 외부 인터넷과 접근이 가능한 네트웍에 자동 업데이트를 위한 서버를 별도 운영할 필요성이 있습니다.

다행히 WSUS등은 그러한 요건에 대응이 됩니다.

Linux의 경우 YUM등을 통한 update를 하게 되는데
local server를 update server로 지정하여 처리하는 자동화된 방식에 있는지는
시간상 자세히 찾아보지 못하였습니다.

PCI DSS에서의 Requirement는 30일 이내에 업데이트하라는 것이며 Manual로 정기점검시 처리할수도 있습니다.
Linux의 update server 구성에 대해서는 코멘트 남겨주시면 확인후 반영하겠습니다.

GFI LANguard같은 제품이 windows OS auto update기능을 제공하기는 하는데 이 역시 internet access가 필요하여 사용에 제한이 있습니다.

Directory Server

Directory Server는 참 많은 곳에서 사용됩니다.

Windows 계열 OS에 대해서는 Active Directory가 절대적인 역할을 하며
이것으로
requirements 1.3.9 personal firewlal, 8.1~5까지의 요구사항을 직접적으로 충족할 수 있습니다.
그외에 AntiVirus 자동설치나 각종 접근제어등 Active Directory는 아주 요긴하게 사용됩니다.

Unix 계열로는 OpenLDAP이나 Sun Directory Server가 중요한 역할을 합니다.

각 vendor별로 directory server를 제공하는데
안정성이나 replication 기능등을 감안하여 신중하게 선택해야합니다.

요즘 Windows Active Directory에서도 Unix에 대한 지원이 강화되고 있어서
AD만으로 통합 인증을 시도해봄직하지만
상당히 많은 시도에서도 실패하여

현재 Windows계열은 AD, Unix 계열은 Sun Directory로 범위를 정하여 각종 패스워드 정책이나 Account Lockout정책을 반영하고 있습니다.

최신 Linux OS는 Active Directory Join이 가능하도록 지원하고 있으니 그 부분은 중점적으로 살펴볼필요가 있다.

참고로 Sun Directory는 Multi-master replication을 지원하는 최초의 제품으로 과거부터 사용해왔고
최초 20만 entry까지 무료 제공되다가 solaris9 OS에 기본 포함되면서 현재는 사용에 제약이 없는 상태입니다