GoogleGroups 생성

PCI DSS관련 토의를 좀더 활발하게 하기 위하여 GoogleGroups를 생성하였습니다.

E-Mail 주소 : pcidssguide@googlegroups.com
Web 주소 : http://groups.google.com/group/pcidssguide

Blog에 포스팅하는 내용이나 댓글이 Groups에 자동 등록되도록 설정되었습니다.

PCI DSS 요구사항 요약정리

Requirements를 단위 갯수로 계산해보면 120개가 넘습니다.
그리고 각 조항의 세부항목을 모두다 읽어가다보면 숲(Wide View)을 보지 못하는 오류가 생기기 쉽습니다.

간단하게 requirements를 분류해두는 경우 각 항목별 이해도를 높이는데 도움이 됩니다.

[안전한 네트웍 구성을 위한 요구사항들]
Requirement 1 : 주로 방화벽 구성 관련 요구사항들
Requirement 2 : System Configuration 관리에 대하여 기술하고 있습니다.
각 시스템의 구성이나 설정방법으로 미리 기술하고 관리하자는 취지입니다.

[고객 카드정보 보호]
Requirement 3 : 카드정보 암호화 및 키관리 관련
Requirement 4 : 전송중인 데이터 보호 관련

[취약점 관리]
Requirement 5 : 바이러스 방지
Requirement 6 : 안전한 시스템 및 어플리케이션 개발

[접근통제]
Requirement 7 : 필요한 경우만 접근한다는 원칙
Requirement 8 : ID 관리
Requirement 9 : 물리적 접근통제

[모니터링 및 테스트]
Requirement 10 : 침입대응 모니터링
Requirement 11 : 취약점 테스트

[정책관리]
Requirement 12 : 보안 정책 관리

보완통제(Compensating Controls)

모든 PCI DSS requirements는 예외사항이 존재할 수 있습니다.
예를 들어 서버중 하나가 아주 오래된 Legacy system이고 허용하는 패스워드 최대자리수가 6자리라면 7자리까지 요구하는 PCI DSS의 규정을 달성할 수 없습니다.
그렇다고 튼튼하게 잘 돌아가는 legacy system을 패스워드 자릿수때문에 교체해야할까요?
그렇지 않습니다.

PCI DSS requirements Appendix B에서 보완통제에 대해서 자세히 기술하고 있는데
주요 내용은 모든 requirements 조항들에 대해서 다른 대안등이 고려될 수 있다는 것입니다.

requirements가 기술된 근본 이유를 파악하여 그에 상응하는 다른 대안을 준비하는 경우 QSA의 충분한 리뷰이후에 그 대안으로 요구사항들을 충족하는것으로 확인될 수 있습니다.

이부분은 PCI DSS 대응에 대한 상당한 유연성을 제공하는 규정입니다.

LAN Network에서의 outbound access

LAN Network에서 outbound access를 금지하는 규정이 PCI DSS requirements에 명시되어 있습니다.

그러나 현실은 LAN Network에서의 direct outbound access가 필요한 경우가 상당히 많습니다.

예를 들어
Linux OS Auto Update는 여전히 outbound access가 필요하며
또한 Partner 회사와 인터넷 VPN으로 통신하는 경우에는 outbound access가 필요합니다.

OS auto update가 DMZ에 존재하는 proxy나 os update repository를 통해서도 진행가능하지만
현실적으로 추가적인 하나의 Machine이 필요하거나 Vendor에서 정식으로 제공하지 않아서 구현하기 어려운 경우들이 상당수 존재합니다.

requirements 1.3.*에서 요구하는 outbound access 제한의 근본 취지는
어떤 해커가 시스템에 침입하여 주요 정보를 빼내가는 것을 방지하기 위해서 존재하는 규정이고
이것을 충족할 수 있다면 제한된 범위에서 outbound access가 허용될 수 있다는 QSA(mike)의 의견입니다.

즉 LAN Area에서 무조건적으로 DMZ내의 IP가 아닌 internet으로의 outbound access를 막는것은 아니고
outbound access를 통제하면서 제한적으로 허용될 수 있습니다.

partner사와의 VPN 통신시 outbount access target IP를 partner사로만 한정하는 경우 requirement구성의 근본 취지를 충족하면서 충분히 안전하게 처리가능합니다.

또한 OS Update시의 target server를 충분히 통제한다면 역시 LAN area에서의 outbound access가 허용될 수 있습니다.

이렇게 허용할 수 있는 근거는
requirements appendix B. Compensating Controls(보완 통제)에서 자세하게 다루고 있습니다.

가상화 기술 이용

비자 교육과정에서 처음 문의한것이 가상화 기술의 사용 부분이었다.

현재 시중의 주요 가상화제품군은 2종류(*)로 구분해보면
[Hypervisor 계열 제품들]
VMWare ESX
Sun LDOM
MS Hyper-V

[특정 OS위에서 운영되는 가상화 제품들]
VMWare Workstation
Sun Solaris Container
MS Windows 2008 Server Hyper-V

으로 분류해볼 수 있고

VM Host의 Physical Ethernet Cable을 DMZ과 LAN Area에 연결해두고
VM Guest들이 이들 네트웍 구간에 위치시키는 경우

해당 네트웍에 존재하는 서버들로 인정하여 PCI Audit에는 문제없다는 의견을 받음 (from Mike)

구상해볼 수 있는 네트웍 구성은

5개의 네트웍 구간을 준비하고
- Production DMZ
- Production LAN
- Staging DMZ
- Staging LAN
- Office Network

VMHost를 Office Network에 위치시킴.
Office Network은 Production이나 Staging 어디에도 속하지 않는 독립된 네트웍이고
VMHost에 4개의 추가 Ethernet Port를 확보하고 각각을 Production이나 Staging의 DMZ/LAN에 캐이블을 연결
이 Ethernet Port들은 VMGuest에서 사용되도록함.

VMGuest를 생성할때 Virtual Ethernet Device를 어느 네트웍에 속하는 것을 선택하는지에 따라 생성된 Virtual Machine이 DMZ이나 LAN Area에 위치시킬 수 있음.

가상화 기술의 장점이 물리적인 Resource를 Share할 수 있는 것이고
8core 32GB machine정도면 약 10개 정도의 VMGuest들을 만들어낼 수 있음.

Sun LDOM은 더 많이 만들어낼 수 있다고 하는데 한번 봐야하고

이걸로 최소한 PCI DSS준비하면서 Server가 부족한 상황은 해소가능하겠다.

[비용은]
x86계열은 VMWare ESX (무료)
Sparc Solaris는 LDOM (무료)

다른 플랫폼은 얼마인지 모름

비자인터네셔날 PCI DSS 교육

4월 9일, 10일 양일간 비자인터네셔널 주최로 소공동 롯데호텔에서
PCI DSS 관련 교육이 있었습니다.
PG사들, 대형 쇼핑몰, 그리고 카드사에서 참석하였고
약 30분이 열심히 교육을 받았습니다.

강사님은 Michael Dahn씨인데 마이크라고 부르더군요.

교육내용은 보안침해사례 검토, 적용범위, 보완통제 그리고 요구사항 분석등의 절차로 진행하였고
교육과정에서 확인한 중요사항을 추가로 정리해서 올리겠습니다.