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가 느껴지는 조항들은 앞서 언급한것들이군요.
2008년 12월 17일 수요일
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
2008년 10월 1일자로 기존 버전 1.1을 대치하게 되며
버전 1.1은 2008년 12월 31일까지만 유효하군요.
https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html
2008년 12월 16일 화요일
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 위원회에도 보고됩니다.
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년 보관.
로그 종류는 통상 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가 필요하여 사용에 제한이 있습니다.
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에 기본 포함되면서 현재는 사용에 제약이 없는 상태입니다
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에 기본 포함되면서 현재는 사용에 제약이 없는 상태입니다
변화관리 Change Management
변화관리 Change management는
workflow보다는 광의의 개념으로 PCI DSS 요구사항 중촉을 위하여 광범위하게 필요로합니다.
주요하게 사용한 tool로는 MS sharepoint와 bugzilla를 들 수 있는데
이 둘은 상호 보완적인 관계를 가집니다.
sharepoint는 corporate portal의 일부로서도 동작할 수 있으며
정형화된 flow control에 적합합니다.
bugzilla는 시작은 Application bug tracking 용도로 탄생하였지만
bug의 개념이 단순한 프로그램의 실수를 넘어서 business process의 오류나
계약지연등 일반적인 business관련 행위도 포함할 수 있으며
실제로 일반적인 business행위에 대해서 상당히 적절한 통제를 할 수 있습니다.
회사에서는 2002년부터 사내 범용의 Business process management tool로서 bugzilla를 사용해왔으며 비슷한 사례로는 Yahoo를 들 수 있습니다.
Yahoo역시 사내의 대부분 process를 bugzilla를 응용한 change management system으로 제어하고 있다고 합니다.
그 사용형태는 PayGate와 크게 다르지 않을것으로 예상합니다.
PCIDSS requirements 1.1.1, 6.4등은 직접적인 관련이 있습니다.
[MailToApps]
Corporate Portal와 Bugzilla와의 유연한 연계나
내부 사용자의 쉬운 사용을 보장하기 위하여
일반 메일에서 bugzilla로의 데이터 auto import가 아주 중요합니다.
메일발생은 application에서 자동발생될 수도 있으며
외부에서의 지원요청도 메일로 전달될 수 있습니다.
이러한 메일에서 자동으로 bugzilla로 insert될 수 있는 안정적인 구조는
가능한 모든 business event를 change management system으로 통합하는
중요한 수단이 됩니다.
MailToApps 관련 문의는 dev@paygate.net으로 연락주시면 안내하겠습니다.
bugzilla website : http://www.bugzilla.org/
workflow보다는 광의의 개념으로 PCI DSS 요구사항 중촉을 위하여 광범위하게 필요로합니다.
주요하게 사용한 tool로는 MS sharepoint와 bugzilla를 들 수 있는데
이 둘은 상호 보완적인 관계를 가집니다.
sharepoint는 corporate portal의 일부로서도 동작할 수 있으며
정형화된 flow control에 적합합니다.
bugzilla는 시작은 Application bug tracking 용도로 탄생하였지만
bug의 개념이 단순한 프로그램의 실수를 넘어서 business process의 오류나
계약지연등 일반적인 business관련 행위도 포함할 수 있으며
실제로 일반적인 business행위에 대해서 상당히 적절한 통제를 할 수 있습니다.
회사에서는 2002년부터 사내 범용의 Business process management tool로서 bugzilla를 사용해왔으며 비슷한 사례로는 Yahoo를 들 수 있습니다.
Yahoo역시 사내의 대부분 process를 bugzilla를 응용한 change management system으로 제어하고 있다고 합니다.
그 사용형태는 PayGate와 크게 다르지 않을것으로 예상합니다.
PCIDSS requirements 1.1.1, 6.4등은 직접적인 관련이 있습니다.
[MailToApps]
Corporate Portal와 Bugzilla와의 유연한 연계나
내부 사용자의 쉬운 사용을 보장하기 위하여
일반 메일에서 bugzilla로의 데이터 auto import가 아주 중요합니다.
메일발생은 application에서 자동발생될 수도 있으며
외부에서의 지원요청도 메일로 전달될 수 있습니다.
이러한 메일에서 자동으로 bugzilla로 insert될 수 있는 안정적인 구조는
가능한 모든 business event를 change management system으로 통합하는
중요한 수단이 됩니다.
MailToApps 관련 문의는 dev@paygate.net으로 연락주시면 안내하겠습니다.
bugzilla website : http://www.bugzilla.org/
Management Portal
Management Portal은 PCI DSS 준비에 있어 광범위하게 필요합니다.
우선 필요한 중요기능을 열거해보면
1. Corporate Calendar : 회사전체적으로 공유하는 일정
2. Document Management : 각종 정책 문서 관리
3. Workflow : Change Management처럼 변화관리가 필요한 관리항목에 대한 Workflow flow control
4. Knowledge Management : 중요한 지식(Knowledge) 관리 포탈
5. User Authentication & Authorization : 유저 인증 및 승인
이미 Corporate Portal을 운영중이라면 위에서 언급된 대부분의 요건들은 충족할것입니다.
시중에는 다양한 형태의 portal및 제품이 존재합니다.
대표적으로
IBM notes, MS sharepoint, knowledgeTree, plone 등이 있습니다.
페이게이트는 MS Sharepoint Services를 Corporate portal으로 선택하였습니다.
그 이유는 아래와 같습니다.
- 무료
- Active Directory와의 유연한 결합
- 상업용 버전으로의 확장성 (Sharepoint Server)
- 다양한 환경에 대한 적용
Sharepoint Corporate Portal으로 아래 업무에 대하여 적용하고 있습니다.
- Policy 문서 관리
- Information management : 자산관리, 업무분장 등 일반적인 업무관련 정보 관리
- Corporate Schedule : 회사 공식 일정 관리
- Formal workflow engine : 정형화된 내용에 대한 Workflow flow control
workflow관련해서는 몇가지 검증을 진행중이지만
PCI DSS에서 요구하는 각종 process control의 요건은 모두 충족할 수 있습니다.
PCI DSS requirements별 직접적인 sharepoint 활용은 아래와 같습니다.
1.1.1 formal process control : information management및 workflow를 이용하여 프로세스 제어
1.1.8 quarterly review : corporate calendar를 이용하여 일정 관리
6.4 change management : 모든 시스템 변경사항에 대한 통합 변화 관리
12.1 information security policy : 정보보호 정책 관리
기타 자산관리, 문서관리등 범용적인 용도의 portal기능으로도 PCI DSS준비에 도움이 됩니다.
MS Sharepoint services : http://office.microsoft.com/ko-kr/sharepointtechnology/FX100503841042.aspx
우선 필요한 중요기능을 열거해보면
1. Corporate Calendar : 회사전체적으로 공유하는 일정
2. Document Management : 각종 정책 문서 관리
3. Workflow : Change Management처럼 변화관리가 필요한 관리항목에 대한 Workflow flow control
4. Knowledge Management : 중요한 지식(Knowledge) 관리 포탈
5. User Authentication & Authorization : 유저 인증 및 승인
이미 Corporate Portal을 운영중이라면 위에서 언급된 대부분의 요건들은 충족할것입니다.
시중에는 다양한 형태의 portal및 제품이 존재합니다.
대표적으로
IBM notes, MS sharepoint, knowledgeTree, plone 등이 있습니다.
페이게이트는 MS Sharepoint Services를 Corporate portal으로 선택하였습니다.
그 이유는 아래와 같습니다.
- 무료
- Active Directory와의 유연한 결합
- 상업용 버전으로의 확장성 (Sharepoint Server)
- 다양한 환경에 대한 적용
Sharepoint Corporate Portal으로 아래 업무에 대하여 적용하고 있습니다.
- Policy 문서 관리
- Information management : 자산관리, 업무분장 등 일반적인 업무관련 정보 관리
- Corporate Schedule : 회사 공식 일정 관리
- Formal workflow engine : 정형화된 내용에 대한 Workflow flow control
workflow관련해서는 몇가지 검증을 진행중이지만
PCI DSS에서 요구하는 각종 process control의 요건은 모두 충족할 수 있습니다.
PCI DSS requirements별 직접적인 sharepoint 활용은 아래와 같습니다.
1.1.1 formal process control : information management및 workflow를 이용하여 프로세스 제어
1.1.8 quarterly review : corporate calendar를 이용하여 일정 관리
6.4 change management : 모든 시스템 변경사항에 대한 통합 변화 관리
12.1 information security policy : 정보보호 정책 관리
기타 자산관리, 문서관리등 범용적인 용도의 portal기능으로도 PCI DSS준비에 도움이 됩니다.
MS Sharepoint services : http://office.microsoft.com/ko-kr/sharepointtechnology/FX100503841042.aspx
웹 방화벽
웹 방화벽은 PCI DSS requirements 6.6에서 언급되고 있습니다.
모든 Web-facing applications은
제3의 기관을 통한 code review를 받거나
웹방화벽을 설치
하도록 요구합니다.
코드리뷰를 제3기관에서 코드리뷰를 받는 이슈는 그 의미에 대한 해석이 분분하며
1회성으로 끝나기에
웹방화벽 설치로 요구사항 충족하는 방법을 택합니다.
웹방화벽은 상당히 고가의 제품입니다.
일부 제품은 초기 접근가격이 억단위를 넘어서는데
전세계를 통틀어 비용대비 효율성이 높은 제품을 몇개 선정하여 테스트를 진행하였었습니다.
dotDefender
breach
barracuda
profense
위 4개 제품이 대상이었고 모두 USD 20000 이하 가격대입니다.
우리회사에서는 profense를 선정하였고 그 이유는 아래와 같습니다.
- 최저비용 : 현지 판매가 EUR6000 입니다. 원화로도 1500만원 이하의 가장 비용효율적인 제품입니다.
- 고성능 : 제품은 ISO installable image형태로 제공됩니다. 최고 성능의 하드웨어에 웹 방화벽을 직접 설치하여 구성할 수 있습니다.
- 최대 64개의 사이트 지원 : 통상 웹방화벽의 가격기준이 커버하는 사이트수가 중요한 기준이 되는데 profense를 제외한 다른 제품에서 64개의 사이트에 대하여 웹방화벽을 적용하려면 엄청난 고비용이 발생됩니다.
- OWASP 10대 보안취약점 대응
profense website : www.armorlogic.com
모든 Web-facing applications은
제3의 기관을 통한 code review를 받거나
웹방화벽을 설치
하도록 요구합니다.
코드리뷰를 제3기관에서 코드리뷰를 받는 이슈는 그 의미에 대한 해석이 분분하며
1회성으로 끝나기에
웹방화벽 설치로 요구사항 충족하는 방법을 택합니다.
웹방화벽은 상당히 고가의 제품입니다.
일부 제품은 초기 접근가격이 억단위를 넘어서는데
전세계를 통틀어 비용대비 효율성이 높은 제품을 몇개 선정하여 테스트를 진행하였었습니다.
dotDefender
breach
barracuda
profense
위 4개 제품이 대상이었고 모두 USD 20000 이하 가격대입니다.
우리회사에서는 profense를 선정하였고 그 이유는 아래와 같습니다.
- 최저비용 : 현지 판매가 EUR6000 입니다. 원화로도 1500만원 이하의 가장 비용효율적인 제품입니다.
- 고성능 : 제품은 ISO installable image형태로 제공됩니다. 최고 성능의 하드웨어에 웹 방화벽을 직접 설치하여 구성할 수 있습니다.
- 최대 64개의 사이트 지원 : 통상 웹방화벽의 가격기준이 커버하는 사이트수가 중요한 기준이 되는데 profense를 제외한 다른 제품에서 64개의 사이트에 대하여 웹방화벽을 적용하려면 엄청난 고비용이 발생됩니다.
- OWASP 10대 보안취약점 대응
profense website : www.armorlogic.com
USB Token
Safenet iKey 1000은 단가가 약 5만원 정도 합니다.
산업표준 PKCS#11을 지원하며
Active Directory, MS Certifiate Authority Server, HSM장비와 더불어
완전한 two factors authentication의 구현이 가능합니다.
USB Token은 PCI DSS requirements 8.2의 요구사항을 충족합니다.
Active Directory는 User identification 정보를 제공하며
MS Certificate Authority Server는 Windows 2003 Server 또는 2008 Server에 기본 내장되어 있는 인증서 발행 관리 서버이며
HSM장비는 MS CA server의 private key를 보관하는 역할을 하게 됩니다.
개인별 private key는 USB token내에 안전하게 저장되며
CA Server를 통해 발급된 인증서는 PKCS#11 interface를 통하여 Token에 설치됩니다.
Safenet iKey 1000 : www.safenet-inc.com
산업표준 PKCS#11을 지원하며
Active Directory, MS Certifiate Authority Server, HSM장비와 더불어
완전한 two factors authentication의 구현이 가능합니다.
USB Token은 PCI DSS requirements 8.2의 요구사항을 충족합니다.
Active Directory는 User identification 정보를 제공하며
MS Certificate Authority Server는 Windows 2003 Server 또는 2008 Server에 기본 내장되어 있는 인증서 발행 관리 서버이며
HSM장비는 MS CA server의 private key를 보관하는 역할을 하게 됩니다.
개인별 private key는 USB token내에 안전하게 저장되며
CA Server를 통해 발급된 인증서는 PKCS#11 interface를 통하여 Token에 설치됩니다.
Safenet iKey 1000 : www.safenet-inc.com
DB 암호화
PCI DSS requirements 3.4~6의 범위에 걸친 요구사항 충족을 위하여
카드번호 암호화가 필요합니다.
다양한 암호화 제품이 존재하지만
나름대로 아래와 같이 구분해보았습니다.
1. DB암호화 전용제품
- 기존 DB에 적용이 쉽고 아주 신속하게 반영이 가능함.
- 기존 어플리케이션을 거의 손댈필요없이 적용가능
- 높은 가격
2. 범용 암호화 제품
- DB암호화에 바로 적용할 수 없음.
- Application 수정 필요
- 기타 management tool을 추가 제작 필요
- 상대적 저가
동작방식에 따라서는 아래와 같은 구분도 가능합니다.
A. DB Connection pool에 하나의 layer로 동작하는 방식
- DB Connection pool을 치환하여 암복호화를 처리하는 방식
- Application tool을 변경할 필요가 없음.
- 암복호화 연산을 DB서버가 아닌 Application Server에서 진행하여 연산부하 분산 효과
B. DB내에서 동작하는 application 방식
- DB서버내에서 trigger로 동작이 유발되며 암복화를 진행하는 방식.
- 전통적으로 많이 사용되는 방식이지만 암복호화 연산부하 가중 우려가 있음.
C. 별도 외부 전용 하드웨어에서 처리하는 방식
- 암복호화 연산은 전문 하드웨어에서 처리
[HSM 장비]
우리회사는 HSM 장비를 이용합니다.
Key관리 관련 부담을 줄여서 PCI DSS requirements 3.5, 3.6의 요건을 쉽게 충족할 수 있습니다.
별도의 application을 개발및 소스 수정의 부담이 있지만
상대적으로 저렴한 가격이나 높은 활용도는 충분한 장점입니다.
선정된 암호 알고리즘 및 보안비도 : AES 256bit symmetric algorithm, SHA-256 hash algorithm
[암호화 여부 검증방식]
Database의 모든 table list를 도출하고
각 table당 100~500개 정도의 record를 dump뜨고
dump뜬 내용을 대상으로 카드번호 존재유무를 정규표현식으로 검색하여 확인합니다.
카드번호 암호화가 필요합니다.
다양한 암호화 제품이 존재하지만
나름대로 아래와 같이 구분해보았습니다.
1. DB암호화 전용제품
- 기존 DB에 적용이 쉽고 아주 신속하게 반영이 가능함.
- 기존 어플리케이션을 거의 손댈필요없이 적용가능
- 높은 가격
2. 범용 암호화 제품
- DB암호화에 바로 적용할 수 없음.
- Application 수정 필요
- 기타 management tool을 추가 제작 필요
- 상대적 저가
동작방식에 따라서는 아래와 같은 구분도 가능합니다.
A. DB Connection pool에 하나의 layer로 동작하는 방식
- DB Connection pool을 치환하여 암복호화를 처리하는 방식
- Application tool을 변경할 필요가 없음.
- 암복호화 연산을 DB서버가 아닌 Application Server에서 진행하여 연산부하 분산 효과
B. DB내에서 동작하는 application 방식
- DB서버내에서 trigger로 동작이 유발되며 암복화를 진행하는 방식.
- 전통적으로 많이 사용되는 방식이지만 암복호화 연산부하 가중 우려가 있음.
C. 별도 외부 전용 하드웨어에서 처리하는 방식
- 암복호화 연산은 전문 하드웨어에서 처리
[HSM 장비]
우리회사는 HSM 장비를 이용합니다.
Key관리 관련 부담을 줄여서 PCI DSS requirements 3.5, 3.6의 요건을 쉽게 충족할 수 있습니다.
별도의 application을 개발및 소스 수정의 부담이 있지만
상대적으로 저렴한 가격이나 높은 활용도는 충분한 장점입니다.
선정된 암호 알고리즘 및 보안비도 : AES 256bit symmetric algorithm, SHA-256 hash algorithm
[암호화 여부 검증방식]
Database의 모든 table list를 도출하고
각 table당 100~500개 정도의 record를 dump뜨고
dump뜬 내용을 대상으로 카드번호 존재유무를 정규표현식으로 검색하여 확인합니다.
시스템 취약점 스캔
취약점 스캔 (Vulnerability Scan)은 내부 스캔과 외부 스캔으로 구분됩니다.
내부 스캔은 별도 프로그램으로 검사해볼 수 있으며
nessus.org가 저렴하게 또는 무료로 이용가능한 신뢰할 수 있는 내부 취약점 스캔 툴입니다.
내부 스캔은 PCI DSS requirements 11.1, 11.2에서 요구되고 있으며
스캔전에 로그인 정보를 사전 등록하여 서버 내부로 실제 로그인하여 취약점을 검출하게 되며 외부 원격 스캔보다는 자세한 내용이 검출됩니다.
원격 취약점 스캐닝 (Remote Vulnerability scanning)은 PCI DSS requirements 11.2, 11.3에서 요구되는 사항입니다.
PCI위원회(www.pcisecuritystandards.org)에서는 원격 취약점 스캐닝을 수행할 업체를 엄격한 심사를 거쳐 선정하는데
공인된 ASV(Approved Scanning Vendors)에서 원격 취약점 스캐닝을 진행합니다.
원격 스캐닝은 네트웍 레벨의 보안 취약점 스캐닝과 모의해킹으로 구분되며
통상 유료로 서비스 됩니다.
그러나 국내의 경우 VISA의 지원하에 ScanAlert에서 한시적으로 50개 IP까지 무료서비스를 제공하고 있으며
ScanAlert Service를 통하여 remote network security vulnerabilities scanning및 모의해킹까지 모두 수행가능합니다.
* 주요 ASV
www.scanalert.com
www.controlcase.com
* ASV 목록
https://www.pcisecuritystandards.org/pdfs/asv_report.html 에서 현재 등록된 모든 ASV를 확인가능
내부 스캔은 별도 프로그램으로 검사해볼 수 있으며
nessus.org가 저렴하게 또는 무료로 이용가능한 신뢰할 수 있는 내부 취약점 스캔 툴입니다.
내부 스캔은 PCI DSS requirements 11.1, 11.2에서 요구되고 있으며
스캔전에 로그인 정보를 사전 등록하여 서버 내부로 실제 로그인하여 취약점을 검출하게 되며 외부 원격 스캔보다는 자세한 내용이 검출됩니다.
원격 취약점 스캐닝 (Remote Vulnerability scanning)은 PCI DSS requirements 11.2, 11.3에서 요구되는 사항입니다.
PCI위원회(www.pcisecuritystandards.org)에서는 원격 취약점 스캐닝을 수행할 업체를 엄격한 심사를 거쳐 선정하는데
공인된 ASV(Approved Scanning Vendors)에서 원격 취약점 스캐닝을 진행합니다.
원격 스캐닝은 네트웍 레벨의 보안 취약점 스캐닝과 모의해킹으로 구분되며
통상 유료로 서비스 됩니다.
그러나 국내의 경우 VISA의 지원하에 ScanAlert에서 한시적으로 50개 IP까지 무료서비스를 제공하고 있으며
ScanAlert Service를 통하여 remote network security vulnerabilities scanning및 모의해킹까지 모두 수행가능합니다.
* 주요 ASV
www.scanalert.com
www.controlcase.com
* ASV 목록
https://www.pcisecuritystandards.org/pdfs/asv_report.html 에서 현재 등록된 모든 ASV를 확인가능
Physical Security
서버들에 대한 물리적 보호는 아주 중요한 이슈입니다.
국내의 경우 다른 나라에 비해서 서버의 물리적 보호를 위한 환경이 잘되어 있는 편입니다.
만일 Data Center에 서버가 위치한다면 PCI DSS requirements 9의 상당히 많은 요구사항들을 충족할 수 있습니다.
그러나 IDC에 서버가 위치하더라도 요구사항 하나하나의 항목을 확실하게 점검해야합니다.
1. DVR recording
Video camera monitoring이 중요한데
최소 3개월간의 recording기록이 있어야하며 서버에 어떤 사람이 접근하여 어떤 작업을 하는지 video record로 확인이 가능해야합니다.
우리 Rack을 비추는 카메라가 없다면 IDC에 특별히 요청하여 카메라를 추가하는등의 사전 작업이 중요.
* 3개월이상 recording 기록 유지가 가능한 동작감지 recording방식의 DVR
2. ethernet MAC - IP binding
사무실에서 사용하는 PC의 ethernet MAC address와 IP를 bind하여 허용된 MAC은 허용된 IP만을 사용하도록 제어가 필요합니다.
또한 각 PC들은 사내 자산관리 목록에서 관리되어야합니다.
* PC자산관리
* PC MAC - IP binding
국내의 경우 다른 나라에 비해서 서버의 물리적 보호를 위한 환경이 잘되어 있는 편입니다.
만일 Data Center에 서버가 위치한다면 PCI DSS requirements 9의 상당히 많은 요구사항들을 충족할 수 있습니다.
그러나 IDC에 서버가 위치하더라도 요구사항 하나하나의 항목을 확실하게 점검해야합니다.
1. DVR recording
Video camera monitoring이 중요한데
최소 3개월간의 recording기록이 있어야하며 서버에 어떤 사람이 접근하여 어떤 작업을 하는지 video record로 확인이 가능해야합니다.
우리 Rack을 비추는 카메라가 없다면 IDC에 특별히 요청하여 카메라를 추가하는등의 사전 작업이 중요.
* 3개월이상 recording 기록 유지가 가능한 동작감지 recording방식의 DVR
2. ethernet MAC - IP binding
사무실에서 사용하는 PC의 ethernet MAC address와 IP를 bind하여 허용된 MAC은 허용된 IP만을 사용하도록 제어가 필요합니다.
또한 각 PC들은 사내 자산관리 목록에서 관리되어야합니다.
* PC자산관리
* PC MAC - IP binding
Security Alert Service
PCI DSS requirements 6.2에서 요구되는 사항입니다.
원문은 "Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the internet). update standards to address new vulnerability issues"
인데 새로 발견된 취약점을 확인 및 적용하는 프로세스가 필요합니다.
새로운 취약점 정보는 MS Site나 KR CERT site등에서 확인이 가능하며
이것은 주로 수신자가 사람인 경우 적절합니다.
requirements 11에서 정기적인 취약점 스캐닝을 할때 그 근거로 사용되는 취약점 정보가 필요하며
서버에서 이용가능한 자동화된 업데이트가 필요한데
저렴하게 이용가능한 취약점 업데이터 기능을 제공하는 소프트웨어는 아래와 같습니다.
Nessus (www.nessus.org)
GFI LANguard (www.gfi.com)
원문은 "Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the internet). update standards to address new vulnerability issues"
인데 새로 발견된 취약점을 확인 및 적용하는 프로세스가 필요합니다.
새로운 취약점 정보는 MS Site나 KR CERT site등에서 확인이 가능하며
이것은 주로 수신자가 사람인 경우 적절합니다.
requirements 11에서 정기적인 취약점 스캐닝을 할때 그 근거로 사용되는 취약점 정보가 필요하며
서버에서 이용가능한 자동화된 업데이트가 필요한데
저렴하게 이용가능한 취약점 업데이터 기능을 제공하는 소프트웨어는 아래와 같습니다.
Nessus (www.nessus.org)
GFI LANguard (www.gfi.com)
Email Security
PCI DSS requirement 4.2에서는 e-mail을 통한 카드정보 전송을 금지하고 있습니다.
PCI DSS version 1.2에서는 e-mail뿐만 아니라 messenger등 각종 messaging system을 통한 카드고객정보 전송을 금지하는것으로 확대되어 있습니다.
메일 발송 형태는 개인이 발송하는것과 시스템에서 자동발송하는 것 2가지로 구분할 수 있으며
개인 발송의 경우 outbound mail content filtering이 필요할 수 있습니다.
다양한 Mail Server에서 outbound mail content filtering을 지원하며
카드번호나 주민번호등의 주요정보가 그대로 나가지 않도록 Regular expression rule을 추가하여 발송을 금지하는 설정이 필요합니다.
또한 application에서 자동발송하는 경우
메일 발송 서버의 relay 설정 발송권한의 제어가 필요하며
특히 application에서는 카드정보가 그대로 나가지 않도록 code를 review해야합니다.
Email Security를 위한 Solution으로는 아래 서비스나 소프트웨어들을 검토해볼 수 있습니다.
- MS Exchange Server
- Google Apps premium edition (premium edition에서 postini outbound mail filtering rule 설정이 가능합니다.)
PCI DSS version 1.2에서는 e-mail뿐만 아니라 messenger등 각종 messaging system을 통한 카드고객정보 전송을 금지하는것으로 확대되어 있습니다.
메일 발송 형태는 개인이 발송하는것과 시스템에서 자동발송하는 것 2가지로 구분할 수 있으며
개인 발송의 경우 outbound mail content filtering이 필요할 수 있습니다.
다양한 Mail Server에서 outbound mail content filtering을 지원하며
카드번호나 주민번호등의 주요정보가 그대로 나가지 않도록 Regular expression rule을 추가하여 발송을 금지하는 설정이 필요합니다.
또한 application에서 자동발송하는 경우
메일 발송 서버의 relay 설정 발송권한의 제어가 필요하며
특히 application에서는 카드정보가 그대로 나가지 않도록 code를 review해야합니다.
Email Security를 위한 Solution으로는 아래 서비스나 소프트웨어들을 검토해볼 수 있습니다.
- MS Exchange Server
- Google Apps premium edition (premium edition에서 postini outbound mail filtering rule 설정이 가능합니다.)
SSL Server 인증서
SSL Server Certificate는 PCI DSS requirements 4.1 요구사항 충족을 위해서 필요합니다.
ActiveX plugin방식의 End-to-End 방식을 검토하는 경우가 있을 수 있으나
이것은 OWASP 10대 보안취약점에 대한 대응 등 다른 문제를 야기할 수 있으므로
결코 권고하지 않으며 말도 안되는 현상이지만 국내에서는 버젓이 하나의 상품으로 자리잡고 있는 현실이 안타깝습니다.
오로지 산업 표준 세션 보안 방식인 SSL을 사용할것을 권장합니다.
웹서버에서 SSL Server를 설정할 때는 가용한 프로토콜중 SSLv3, TLSv1만을 이용하고
보안상 취약점이 알려진 SSLv2는 disable해야합니다.
비용등을 감안한다면 wildcard ssl server certificate (*.paygate.net 과 같은 형태)도 고려해봄직합니다.
SSL Server Certificate를 발급하는 업체 목록은
아래 링크에서 찾아볼 수 있습니다.
http://www.google.co.kr/Top/Computers/Security/Public_Key_Infrastructure/PKIX/Tools_and_Services/Third_Party_Certificate_Authorities/
ActiveX plugin방식의 End-to-End 방식을 검토하는 경우가 있을 수 있으나
이것은 OWASP 10대 보안취약점에 대한 대응 등 다른 문제를 야기할 수 있으므로
결코 권고하지 않으며 말도 안되는 현상이지만 국내에서는 버젓이 하나의 상품으로 자리잡고 있는 현실이 안타깝습니다.
오로지 산업 표준 세션 보안 방식인 SSL을 사용할것을 권장합니다.
웹서버에서 SSL Server를 설정할 때는 가용한 프로토콜중 SSLv3, TLSv1만을 이용하고
보안상 취약점이 알려진 SSLv2는 disable해야합니다.
비용등을 감안한다면 wildcard ssl server certificate (*.paygate.net 과 같은 형태)도 고려해봄직합니다.
SSL Server Certificate를 발급하는 업체 목록은
아래 링크에서 찾아볼 수 있습니다.
http://www.google.co.kr/Top/Computers/Security/Public_Key_Infrastructure/PKIX/Tools_and_Services/Third_Party_Certificate_Authorities/
PCI DSS Version 1.1 requirements 분석
PCI DSS requirements에 대한 리스트는 어디서나(?)구할 수 있지만
실제 각 항목에 대한 분석자료는 많지 않았고 해석이 어려운 경우도 많았습니다.
그래서
http://spreadsheets.google.com/pub?key=ph4gmGGGZFpQfP0-7gSPoGA
에다가 분석한 내용을 몽땅 올렸습니다.
간단한 내용들은 패스하고
중요하거나 코멘트 달고싶은 곳에 내용을 추가하였습니다.
실제 각 항목에 대한 분석자료는 많지 않았고 해석이 어려운 경우도 많았습니다.
그래서
http://spreadsheets.google.com/pub?key=ph4gmGGGZFpQfP0-7gSPoGA
에다가 분석한 내용을 몽땅 올렸습니다.
간단한 내용들은 패스하고
중요하거나 코멘트 달고싶은 곳에 내용을 추가하였습니다.
2008년 12월 15일 월요일
PCI DSS Guide를 준비하며
회사에서 2008년 11월 26일에 PCI DSS 인증을 획득.
requirements를 100% 준수하는 Full compliance인데
근 1년 준비하여 아주 어렵게 획득하였다.
PCI DSS version 1.1이 올해까지이고 내년부터는 1.2가 시행되는데
어떻게 보면 1.1보다 좀 약해졌다고 해야하나 (그런 느낌임)
이유는 무선랜 보안에서 SSID broadcasting이 다시 허용되는거나
보안관련 명확하지 않은 규정들이 좀더 유연해진것등이 그렇고
PCI DSS 인증은 2009년부터 본격 시행되는데
그동안의 준비과정의 경험과 정보들을 정리하여 게시예정.
특히 비용관련하여 최대한 저렴하게 구성할수 있는 충분한 아이디어를 제공하고자합니다.
많은 기대 바랍니다.
피드 구독하기:
글 (Atom)