로그 관리 방법 정리

로그는 크게 3가지 정도 분류된다.
Windows Events Log, Syslog messages, SNMP trap messages

각각을 하나로 모으는 과정은 아래 몇가지 방법을 이용한다.

1. Syslog를 이용하여 유닉스 및 network device들의 log 집중 관리
- syslog는 그자체로 훌륭한 중앙 로그집중 관리툴이다.
- syslog는 산업 표준 logging system으로 대부분의 유닉스(리눅스 포함)및 네트웍 장비들이 지원한다.

2. rsyslog를 이용하여 syslog forwarding
- rsyslog는 syslog message를 수신하면서 동시에 다른 syslog server로 log를 forwarding한다.
- 네트웍 구간별로 syslog server가 존재한다면 각 구간별 syslog server에는 rsyslog를 설치하여 log를 중앙으로 forwarding해준다.

3. Log management tool을 이용한 로그 수집
- Log management tool을 로그의 수신, 분석 및 저장 역할을 담당한다.
- syslog및 windows events를 모아서 분석하고 리포팅하며 또한 Database에 저장한다.
- 페이게이트는 GFI EventsManager를 이용중
- DB에 저장된 로그는 검색이 가능하며 PCI DSS의 로그보관정책에 따라 Tape에 백업해둘수도 있다.

------------------
전체 구조를 flow로 구성해보면
(Unix & Network device log)
-> rsyslog server(네트웍 구간별로 존배)
-> central rsyslog server
-> Log management tool
-> Database
-> Backup Tapes

의 로그흐름이 생성된다.

모의해킹 방법

PCI DSS Requirements 11 에서 모의해킹(Penetration test)을 요구한다.
아래 간단한 모의해킹 방법을 정리해보았다.

1. download metasploit tool
http://www.metaspolit.com

2. open port scan with zenmap(nmap tool gui version)
target IP들에 대해서 open port가 있는 IP들을 scan한다.
IP대역 지정은 CIDR 포맷이나 range로 지정가능하다.
CIDR 예: 211.53.212.0/24
IP range : 21.53.212.1-254

3. port가 열려있는 IP들에 대해서 nessus vulnerability scan을 수행
만일 high vulnerabilities가 발견된다면

4. metasploit tool을 이용하여 exploit test 수행
- 발견된 취약점 형태에 따른 적절한 metasploit module을 선택하여 모의해킹 수행

-----------
위 절차는 사무실내에서(internal penetration test)와
사무실 외에서(external penetration test)에서 수행해야한다.

실제 모의해킹은 network에 대해서와 application에 대해서 시도해봐야하는데
위 절차는 network에 대한 절차이고 application에 대해서는 OWASP Top10 vulnerability guide에 의해 자체적으로 별도 수행해야한다.

-----------

참고로 일부 ASV scan 업체의 경우 ASV scan과 함께 penetration test 동시에 수행하고 결과를 제공하기도 한다.

PCI DSS 주기적으로 해야할 체크리스트

PCI DSS 감사를 매년 진행하면서 이미 진행했어야 하는 사항을 빠트리기 쉽고 과거진행했어야 할 사항은
감사시점에서 증빙을 제시하기 어려운것이 많으므로 미리미리 준비해야한다.

1. 매일 체크해야할 사항
- Log Reviews for Servers and network devices

2. 매주 체크해야할 사항
- File Integrity monitoring Review
- Anti-virus scan reports

3. 매월 체크해야할 사항
- 보안패치 반영사항

4. 분기별 확인사항
- 카드번호 검색 (데스크탑, 파일서버 및 데이터베이스)
- 내부 취약점 Scanning
- 모든 공개 IP에 대한 ASV scanning
- 유저 Account Privilege Review and removal of users not logged in last 90 days
- 무선망 취약점 분석

5. 반기별 확인사항
- 방화벽 및 라우터 룰셋 점검

6. 연간 확인사항
- 매년 암호화 키 로테이션
- Physical Security Review of Off-site Tape Backup location
- Media Inventories of medias stored onsite and offsite locations
- Internal Penetration Testing (Network and Application)
- Risk Assessment for the environment in scope
- External Penetration Testing (Network and Application)
- Policies & Procedures Review
- Incident Response Testing
- Information Security Awareness Training
- Sign-off from employees that they have read and understood the information security policies and procedures

SSH Port Forwarding

LAN to WAN direct outbound 금지에 대해서 고민하던중
SSH Port forwarding을 적용하기로 하였다.
일단 TCP protocol에 대해서만 적용가능하므로
Application Server에서 outbound access가 필요한 경우
HTTP Forward Proxy를 사용하거나 SSH Port Forwarding을 사용하면
대부분의 외부 접근 문제를 해결할 수 있다.

단 현재까지 아직 검증되지 않은 사항은
장애발생시 Failover나 얼마나 안정적으로 동작할것인지
그리고 어느정도의 추가 부하가 생길것인지 가늠하기가 어렵다.

OpenSSH가 무난하고
Client와의 연계를 위해서는 VanDyke software의 SecureCRT를 함께 검토중이다.

Anti DDoS 장비가 IDS의 일종인가?

Anti DDoS장비를 IDS로 볼 수 있는지에 대한 의견이 분분합니다.
일단 저는 Anti DDoS장비를 IDS/IPS의 일종으로 보고 있습니다.
IDS/IPS 설치는 PCI DSS Requirements중 하나이고 전자금융거래법 시행세칙에서도 요구되고 있습니다.
정확한 사항은 QSA의 답변을 받아봐야할것 같습니다.

OSI Layer 1에서부터 7까지중 어디까지 Detect하느냐가 기존의 IDS와 Anti DDoS장비의 중요한 차이점이고
PCI DSS Requirements에 OSI 7 Layer 수준까지 명시하고 있지는 않아서
QSA의 판단에 따라서 보완통제를 적용하든 적용없이 인정할 수 있겠다는 생각입니다.

Forward Proxy

Forward Proxy가 LAN area의 서버에서 Direct outbound access 금지 규정에 대한 훌륭한 솔루션임을 확인하였습니다.

HTTP/HTTPS outbound access가 필요한 다양한 Application에서 forward proxy를 이용할 수 있도록 기본 지원합니다.

검토한 Application등은 아래와 같습니다.
* yum update 시 proxy server 지정가능
* windwos update시 IE 연결 설정에서 proxy server 지정가능
* apache commons httpclient library에서 proxy server 지정가능
* wget과 같은 command line tool에서 proxy server 지정가능.

Proxy server 이용시 다양한 추가 정책을 설정하여 보안을 강화할 수 있습니다. (유저인증, Source IP제한, Target IP 제한 등)

ActiveDirectory 정책으로 이용하는 모든 PC에서 Default Proxy Server를 강제 설정할 수 있도록 지원하는것도 확인하였습니다.

cache기능을 함께 이용하면 OS Update에 대한 traffic 감소 효과도 있을것으로 예상합니다.

List of Compliant Service Providers

전세계 PCI DSS 인증받은 Service Provider 목록이 있습니다.

Asia Pacific 지역은 www.visa-asia.com/spregistry 에서 확인가능하며
전세계 모든 지역에 대한 목록은 www.visa.com/splisting 에서 확인가능합니다.

spregistry에 등록하는것은 연간 5천불의 비용이 드는데 한국의 경우 Visa에 한정된 범위내에서 무료 등록 지원을 해주고 있습니다.

visa-asia.com site는 update가 좀 늦는군요.

알고 있는 회사가 존재하는지 찾아보세요

Master Card 목록은 여기에 있군요.
http://www.mastercard.com/us/sdp/assets/pdf/Compliant%20Service%20Providers%20-%20November%2016%202009.pdf

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씨인데 마이크라고 부르더군요.

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

국내 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사들이고 대형쇼핑몰업체는 아직 목록에 없군요.