개인정보 침해사고 방지 대책

2008. 4

	행정안전부

	목 차
Ⅰ. 피해상황 및 정보도용 절차 1 Ⅱ. 긴급 조치사항 3 Ⅲ. 기관별 조치사항 4 Ⅳ. 향후 계획 5 <붙임 1> 인터넷상 개인정보 침해 원인 및 조치사항 <붙임 2> 개인정보보호 가이드라인 <붙임 3> 공공기관 개인정보보호 기본지침

개인정보 침해사고 방지 대책

❍ 최근 인터넷 경매업체인「옥션」의 해킹사고로 인해 주민번호, ID, 패스워드 도용을 통한 ID판매, 회원 명의 도용 등 국민들의 피해가 확산

❍ 개인정보를 보관하고 있는 모든 기관 및 사업자에 대해 일제점검을 실시하고 개인정보 유출 우려가 있는 시스템 긴급 개선 추진

-  -

Ⅰ		피해상황 및 정보도용 절차

□ 피해상황

「옥션」의 해킹사고 전말

❍ '08. 2. 5 해킹 프로그램에 의해 옥션의 개인정보 유출사고 발생

❍ '08. 4   약 1,081만명의 ID가 유출된 것으로 조사

❍ 경찰청 피해상황 수사 중, 방통위 관련 대책회의 및 발표

유사사례

❍「세븐일레븐」입사지원자 이력서 1,281명 정보노출(‘07. 1)

❍ 약 1,940명의 한국인 주민번호 중국내 판매 광고(‘07.3)

❍ KT '링고‘ 서비스 가입자 190만명 개인정보 노출(’07. 3)

❍ KT, 하나로통신에서 730만명의 고객정보 무단제공(’07. 8)

□ 정보도용 절차

문제가 되는 주요정보

❍ 신상정보 : 주민번호, 성명, 휴대전화번호

❍ 회원 ID  : 회원가입 ID, 패스워드

❍ 인 증 서 : 인증서 ID, 인증서 비밀번호

❍ 은행정보 : 계좌번호, 계좌비밀번호

정보유출에서 도용까지 절차

❍ 외부인의 악의적 해킹을 통해 개인정보 DB유출 ❍ 개인정보취급자 관리부주의 및 실수로 인한 정보유출 ❍ 내부자에 고의 정보유출(정보 판매, 회사불만 등 사유)

❍ 보이스 피싱 사기단 ❍ 금융거래 사기단 ❍ ID 등 개인정보 판매자			⇒ 90% 이상이 외국

❍ 신상정보, 주민번호 등을 이용한 금융사기(불법 대출․인출) ❍ 주민번호∙ID 판매, 개인정보 등을 이용한 협박 등

Ⅱ		긴급 조치사항

□ 개인정보 보호실태 일제점검

❍ 개인 식별번호, ID, 패스워드 등이 유출 되었는지 일제 조사

❍ 해킹, 웜∙바이러스 등에 의한 정보유출 악성프로그램 감염여부 진단

❍ 주요정보(주민번호, ID, 패스워드) 암호화 조치 여부 확인

□ 개인정보 유출 차단 조치

❍ 정보유출 차단용 해킹∙웜바이러스 보안장비 설치 의무화

※ 방화벽 정책설정, 웜∙바이러스 차단, 키보드보안 프로그램 실행

❍ 내부자의 주요정보 접근통제 강화 및 로그기록 일일점검

※ 내부직원의 금전적 이득 목적, 회사불만 등으로 고의 유통∙판매 방지

❍ 개인정보 인터넷 노출 등 관리자 부주의로 인한 정보노출 차단

※ 국민은행 홍보메일 발송과정 실수로 고객정보 3만명 명단 유출(‘06. 3)

□ 주요 정보 유출시 긴급조치

❍ 자체 보안인력을 투입하여 외부접근 차단 및 피해상황 조사

※ 긴급상황 발생시 서비스 중단 실시 및 외부 정보통신망 차단

❍ 경찰청 사이버수사대에 정보유출 상황 긴급 신고

❍ 행안부, KISA 등 정부 정보보호 기관에 긴급 보호 요청

※ 개인정보침해신고센터 : 행안부 개인정보보호과(02-2100-1732), KISA (국번없이 1336)

Ⅲ		기관별 조치사항

□ 중앙행정기관

❍ 산하 개인정보 취급기관 및 소속 사업자 긴급회의 개최

- 총무∙인사∙정보화 부서 책임자급 회의 소집

-「개인정보 침해사고 방지 대책」중심으로 대책회의

※「인터넷상 개인정보 침해 원인 및 조치사항」,「개인정보보호 가이드라인」, 「공공기관 개인정보보호 지침」함께 전파

❍「개인정보 침해사고 방지 대책」을 토대로 자체 추진계획 수립

❍ 정보유출이 우려되는 기관에 대해 관계기관 합동점검 실시

- 미흡한 기관에 대해서는 취약점을 긴급히 개선토록 조치

□ 개인정보 취급기관 및 사업자

❍ 자체 전문가팀을 구성, 개인정보 유·노출 상황 자체 점검

❍ 점검 결과 발견된 취약점, 유출사고에 대해서는 긴급개선

❍ 개인정보보호 가이드라인 및 침해방지 대책 교육 실시

□ 한국정보보호진흥원

❍ 개인정보 유출이 있는 기관에 대해 긴급 지원하고, 관련 정보보호 지침을 마련하여 체계적으로 대응할 수 있도록 협조

❍ 국․내외 해킹 등 정보보호 동향을 수시로 파악하여 개인정보 취급기관 및 사업자 등에 실시간 전파

Ⅵ		향후계획

□ 인터넷상에서 주민등록번호 일몰제 도입 검토

❍ 인터넷상 주민번호를 대체하는 본인확인수단 적용 확대(‘08.8～) 및 인터넷상에서 주민등록번호 유통 최소화 추진

※ 주민번호 없이 G-PIN, I-PIN(인터넷상 식별번호)으로 회원가입 등

□ 개인 식별번호와 비밀번호 정보 암호화

❍ 주민번호ㆍ계좌번호 등 주요 개인정보를 저장ㆍ유통할 때 반드시 암호화하도록 하여 유출된 정보의 악용을 차단(‘08.7～)

※「정보통신망법」상 기술적ㆍ관리적 보호조치 기준 고시 개정(’08.6, 방통위)

□ 개인정보보호 제도 강화

❍「개인정보보호법」을 제정(‘08.12), OECD 등 국제기준에 맞는 개인정보처리원칙을 규정, 정보 수집ㆍ보유ㆍ유통 등을 엄격히 규율하여 정보유출 최소화

※ 법률 또는 동의에 근거한 개인정보 수집, 개인정보처리방침의 공개, 보유 및 수집 목적 외 개인정보 이용ㆍ제공 금지 등

❍ 모든 사업자까지 법 적용범위를 확대하여 사각지대 해소

□ 개인정보 취급 기관 및 서비스에 대한 인증제도 의무화 도입

❍ 해킹, 웜․바이러스, 내․외부자에 의한 정보유출 등에 대한 정보보호장치가 일정 수준에 도달하도록 기준을 제시하고 인증심사를 하여 보호수준을 제고하는 인증제 도입

별첨 1

인터넷상 개인정보 침해 원인 및 조치사항

- 최근 발생한 인터넷 개인정보 유출 사고 방통위 분석 사례 중심 -

2008. 4. 28

	행정안전부

	목 차
Ⅰ. 현황 및 문제점 1 1. 현황 1 2. 개인정보 유출로 인한 피해 3 3. 문제점 4 Ⅱ. 조치 사항 6 1. 개인정보 관리실태 점검 및 미비점 개선 6 2. 이용자 피해 최소화 6 3. 개인정보 해킹에 대한 기술적 대책 강화 7 4. 기관․사업자의 개인정보보호 책임 강화 9 5. 개인정보보호 인식 제고 9 <참고 1> 홈페이지 취약점 점검 방안

Ⅰ		현황 및 문제점

1		현 황

□ 최근 개인정보 침해는 내부직원 유출, 사업자의 무단이용에 더불어 관리 부주의, 해킹․웜바이러스 등 외부 공격에 의한 유출로 양상 변화

o (해킹) 해커의 자기 과시나 네트워크․시스템 마비 목적에서 해킹툴 등을 이용하여 개인정보 탈취 목적의 해킹 증가

- (공공) 4,286건/’06년 → 7,588건/’07년, (민간) 26,808건/’06년 → 21,732건/’07년

※ '07년 해킹신고 건수는 전년 대비 18.9% 감소했으나, 개인정보 탈취 등 '침입시도' 해킹(4,316건)은 오히려 16.3% 증가

o (웜바이러스) 스팸메일 발송, DDoS 공격 등 시스템 통제 목적에서 개인정보 탈취를 목적으로 하는 유형 증가

※ '07년 웜바이러스 피해신고는 총 3,639건 발생했으며, 이 중 ID․비밀번호 등 개인정보 유출 목적의 OnlinegameHack 등 증가(전년 대비 71.7%)

o (내부유출) ID 도용 등을 통해 금전적 이득을 목적으로 텔레마케팅, 채권추심업체 등에 유출하는 유형 증가

※ ’06. 4, KT 등 4개 통신회사 영업점에서 고객정보 771만건 유출

※ ‘08.4월 통신업체 600만 회원정보를 텔레마케팅 업체에 8500만건 유출 등 내부자에 의한 개인정보 유출 규모 증가 추세

o (관리자 부주의) 정보관리자가 개인정보를 홈페이지 등에 노출

※ KT 비즈링고, 웹사이트 관리 부주의로 고객정보 190만건 노출('07. 3)

<개인정보 침해신고 및 침해양상 유형>

□ 주요 개인정보 침해사고 사례

o (옥션) 해킹으로 개인정보가 유출된 사실을 인지하고 경찰청('08.2.4) 및 정통부('08.2.5)에 신고, 경찰 중간수사 발표(‘08.4.18)

- 중국측 공격자가 국내 某 기업 서버를 경유하여 옥션 고객지원시스템(eNomix)에 접근한 뒤, 해킹툴을 이식하여 개인정보 DB 다운로드 추정

- 유출 정보는 옥션 회원 1,081만명의 성명․ID․주민번호 등(일부 회원의 은행계좌번호 포함), 비밀번호․신용카드번호는 미유출

o (KT, 다음 등 9개 업체) 경찰청은 9개 통신․인터넷 사업자가 해킹을 당해 개인정보가 유출된 사실에 대해 수사결과 발표(‘08.3)

- 국내 해커가 각 업체의 전산시스템 관리자 계정 도용, 해킹툴 이식 등으로 개인정보를 유출한 것으로 추정

- 유출 개인정보 중 10만건은 인터넷상에서 불법 판매했으며, 이 외에도 개인정보를 이용한 게임 아이템 사기, 스팸메일 발송 등 2차 범행

o (하나로 텔레콤) 이용자 동의없이 회원정보를 상업적 용도로 무단 제공(‘08.4)

- ‘06년 1월부터 ’07년 말까지 600만건의 이용자 정보 약 8,500만건을 전국 1,000여개 텔레마케팅 업체에 제공

□ 개인정보 유출 피해자들은 이전의 소극적․산발적 대응에서 집단 손해배상 소송 등 적극적․집단적 대응으로 변모

※ 국민은행 유출피해자 1,026명 집단 손배소(1인당 20만원), LG전자 290명(1인당 70만원) 등

※ 옥션, LG텔레콤, 하나로텔레콤 개인정보 유출과 관련하여 피해자 집단소송 준비중('08.4)

□ 주요 침해사고 원인

o 침해원인은 제도미비, 책임성 부족, 보안인프라 취약 등 복합적

- 개인정보보호 제도가 느슨하고, 법령별 기준․처벌규정 등이 상이

- 공공․민간 보안인프라가 취약하여 기술적 대응력 부족

※ 정보화 예산대비 정보보호 예산이 공공 4.3%, 민간 1% 이내

2		개인정보 유출로 인한 피해

□ 유출된 개인정보는 다시 다양한 형태의 2차 피해로 연결될 가능성

o 금번 옥션 등의 유출정보는 명의도용, 스팸발송, 보이스피싱, 불법유통, 텔레마케팅 활용의 가능성 상존

<인터넷 개인정보 유출로 인한 예상 피해유형>

구분	이용가능 정보	피해 유형	발생가능성
①인터넷 회원가입 명의도용	성명, 주민번호	- 다수 사이트에서 성명, 주민번호만으로 회원가입 가능(다만 휴대폰․공인인증 적용시는 도용 곤란)	높음
②기존회원 자격도용	ID, 비밀번호, 성명, 주민번호 등	- 성명․주민번호 등으로 비밀번호 유추하여 회원자격도용 가능	중간
③오프라인 서비스 명의도용	성명, 주민번호, 주소	- 금융․통신서비스 가입시 대면확인, 신분증 요구 등으로 도용가능성 낮으나, 일부 대포폰․대포통장 가능	낮음
④불법 스팸	이메일, 유․무선 전화번호	- 불법스팸, TM 발송에 이용	높음
⑤보이스피싱	성명, 유․무선 전화번호	- 기관사칭 전화사기, 납치사칭 전화사기 등에 모두 이용가능	높음
⑥개인정보 DB 유통	전 개인정보	- 통신사 영업점, 스팸발송업자, TM업자 등에 판매되어 이용가능	높음
⑦인터넷 유포	전 개인정보 (주로 성명, 주민번호)	- 전 개인정보 유포는 가능성 낮으나, 성명․주민번호는 중국 웹사이트에 유포가능성 있음	중간
⑧신분증 위조	성명, 주민번호, 주소	- 전문적 위조기술 필요	낮음
⑨금융범죄	계좌번호 등	- 공인인증서, 보안카드 등 추가 인증을 거치므로 도용 곤란	낮음
⑩사생활 침해	전 개인정보	- 개인 블로그․미니홈피 비공개 내용 유출 등 피해 가능	중간

3		문제점

□ 정보 관리 기관․사업자의 개인정보보호 책임성 부족

o 주민등록번호 등 서비스 제공과 무관한 개인정보를 과다 수집하는 관행으로 개인정보침해의 중요 원인이 됨

※ 국내 사이트의 73% 이상이 주민번호 수집('06) 하는 반면, 야후, MSN, 아마존닷컴 등 외국 주요사이트는 성명, 이메일, 생년월일 등 기본정보만 수집

※ 공공기관의 경우, 주민등록등본 이외에 혼인관계증명서 등 업무상 필요한 정보 이외의 과다한 개인정보 관련 서류 제출 요구(‘08.4, 여성가족부)

o 개인정보를 마케팅, 업무편의 등을 위한 수단으로 이용하는 반면, 정보보호에 대한 투자 및 경영자의 관심은 부족

※ 기업 정보보호 수준조사 : 보안투자 전무 50.8%, 투자비용 1% 미만 27.5%('07)

(미국, EU 등 주요 선진국은 평균 7% 이상, KISA)

※ 공공기관 보유 개인정보가 구글 등 일반 포털의 검색 엔진에도 쉽게 노출되나, 자료 게재시 주민번호 차단 시스템 등 개인정보보호 시스템 도입 미흡(‘08.4, 한겨레신문)

※ 전자정부서비스의 경우 보안시스템 도입률 55.4%(‘08.4, 행정안전부)

o 기관․사업자 등의 자율적 개인정보보호 활동은 미흡한 반면, 정부 규제․단속에 대해서만 소극적으로 대응하는 수준

※ 웹사이트 자료 게재 절차, 개인정보 노출 모니터링, 담당자 교육 등 개인정보 관리를 위한 적극적 보호 조치 미흡

※ 개인정보 노출 사고 발생시, 개인정보 침해 피해자에 대한 통보 및 관계기관 신고 등 개인 권리구제 활동에 소극적

□ 해킹에 대한 기관․사업자․이용자 대응 부족

o 개인정보 탈취를 위한 해킹은 네트워크(전송구간), 사업자 서버, 이용자 PC에서 발생

- 정보보호 투자 및 전문가 부족으로 해킹 사실을 조기 인지하지 못하거나 신속한 초등 대응 미흡

※ 정보보호 제품 사용현황 : 침입차단시스템 45.9%, 침입탐지시스템 9.5%, 웹방화벽18.3%(‘08 국가정보보호백서)

- 개인 PC는 백신 프로그램을 사용하지 않아 악성코드에 쉽게 감염

o 그간 해킹 대응은 DDoS 공격 등 네트워크 침해 대응 및 장애발생 예방에 집중되어 개인정보 탈취 목적 등 복합적․지능적 해킹의 탐지․대응에 한계

※ 네트워크 방화벽, 침입방지시스템 등 네트워크 침입 탐지․차단 시스템은 해킹과 웜․바이러스가 결합된 복합 해킹 공격에 무방비

<네트워크 구간별 해킹 대응방안>

Ⅱ		조치 사항

◇ 최근 옥션 사고를 계기로 전 기관․사업자의 개인정보 관리실태 일제점검 및 보안조치

◇ 아울러 개인정보 유출로 인한 2차 피해 최소화

◇ 개인정보의 수집․저장․이용 각 단계에서의 사업자 책임강화 및  신속한 권리구제를 위한 제도적․기술적 대책 추진

◇ 개인정보가 수집․이용되는 네트워크, 사업자 서버, 이용자 PC 보안 수준 강화

1		개인정보 관리실태 점검 및 미비점 개선

o 개인 식별번호, ID, 패스워드 등이 유출 되었는지 일제 조사

⇒ 정보유출시 피해상황 신고(경찰청) 및 정보보호 조치(자체, KISA 지원 등)

o 해킹, 웜․바이러스 등에 의한 정보유출 악성프로그램 감염여부 진단

⇒ 해킹․악성바이러스 제거, 보안시스템 도입 및 개선

o 주요정보(주민번호, ID, 패스워드) 암호화 조치 여부 확인

⇒ 주요정보는 최단시일내 암호화하고, 네트워크 내에 암호장비 설치

2		이용자 피해 최소화

□ 회원자격 도용 방지를 위한 비밀번호 변경 캠페인

o 각 기관․사업자별로 웹사이트 회원 등에 대해 ID 및 비밀번호 변경캠페인 추진

※ 다수 웹사이트에 동일 ID․비밀번호 사용이 대부분으로, 유출된 정보를 이용 타사이트 접속

o 각 기관․사업자별 웹사이트 휴면 계정을 정리하도록 안내

※ 휴면 계정은 최소 6개월 이상 비접속 회원으로 기관․사업자 상황에 맞게 기준 정의 및 사이트 공지․이메일 발송 등을 통해 자발적 정리 또는 유예기간 후 삭제

□ 사이트 회원가입을 위한 명의도용 방지

o 이름과 주민번호를 통한 본인확인 외에 추가로 공인인증서, 행정전자서명인증서(GPKI), 휴대폰 등을 이용한 본인확인 절차를 도입

o 명의도용차단서비스 제공사를 통해 명의도용 사실을 본인이 즉각 인지할 수 있는 서비스 이용 안내․권고

※ 크레딧뱅크(http://www.creditbank.co.kr), 사이렌24(http://www.siren24.com),

마이크레딧(http://www.mycredit.co.kr), 에이사이트(http://asite.dreamwiz.com)

□ 개인정보 모니터링 강화

o 주요 기관․사업자의 자체적인 개인정보 노출여부 모니터링 강화

※ 자체 홈페이지, 게시판 등에 게시되는 개인정보를 즉각 탐지 및 대응

3		개인정보 해킹에 대한 기술적 대책 강화

□ 네트워크 보안 대책

o 네트워크상에서 전송되는 개인정보를 보호하기 위하여 개인정보를 암호화하여 송․수신하는 보안서버(또는 SSL 인증서) 적용

※ 보안서버는 개인정보를 암호화해 전송함으로써 유출시에도 오․남용을 방지하는 S/W

※ SSL 인증서는 Internet Explorer 등 웹브라우저와 웹서버 간의 전송 정보를 암호화해주는 SSL 프로토콜용 인증서로, 행정안전부 행정전자서명인증관리센터에서 무료 보급

o 각 기관에서 운영 중인 인터넷 주소변환 시스템(DNS 서버, Domain Name Server)에 “악성코드 은닉사이트 차단 기능 적용”

※ 악성코드 은닉사이트 차단 기능은 한국정보보호진흥원에서 운영 중인「악성코드 은닉사이트 탐지 시스템 」을 이용하여 탐지된 악성코드 유포 사이트 접속을 차단. ‘06~’07년 1,326건의 국내 악성코드 제거, 12,168건의 국외 악성코드 유포지 차단

(KISA에서 무료 배포 중, 문의 : KISA 해킹대응팀 최중섭 팀장, 02-405-5630)

□ 웹서버, DB 등 서버 보안대책

o 웹사이트 개인정보 노출방지 사전차단 필터링 프로그램 도입․설치

- 민원인이 게시판 등에 자료 게재시 개인정보 노출에 대한 경고 팝업창 게재 병행

o 개인정보 유출 사고 발생 기관 등 공공기관․사업자에 대한 개인정보 유출 상시 모니터링 강화

o 홈페이지 취약점 점검을 통한 웹해킹 예방 및 공격 탐지․차단 기능 적용 확대

- OWASP 10대 취약점 등 웹 프로그램 취약점 점검

※ 참고 1 : 홈페이지 취약점 점검 방안

- 웹 소스 코드에 개인정보 포함여부 등 개인정보 취약점 점검

o 관리부재로 인해 악성 코드 유포, 개인정보 노출 점검 곤란 등 관리가 취약한 휴면 홈페이지 삭제 조치

< 휴면 홈페이지 유형 >

① 정보화사업 추진과정에서 테스트용도로 개설 후, 사업 종결 후에도 방치된 임시 홈페이지

② 기관, 부서의 新홈페이지 구축 후 방치된 舊홈페이지

③ 타 유사홈페이지로 통합 후 방치된 홈페이지

④ 개편, 소멸, 청산된 조직․기업․협의회 등의 홈페이지

⑤ 종결된 업무 또는 연구개발사업 홈페이지

⑥ 폐회된 워크샵, 컨퍼런스 등 행사관련 홈페이지

⑦ 소유자의 전직, 퇴사 등으로 관리부재 상태인 개인 홈페이지

⑧ 다수 홈페이지가 운영되는 동일 서버에서 방치되고 있는 미활용 홈페이지

⑨ 기타 접속이 없거나 활용도가 적은 홈페이지 (최소 6개월)

□ 개인 PC 보안대책

o 기관 관리용 PC에 대한 자동보안업데이트 프로그램 도입으로 개인 PC의 보안성 향상

o 홈페이지 이용자 PC 개인정보보호를 위해 웜․바이러스 등 악성코드 탐지․차단 기능 적용 확대

4		기관․사업자의 개인정보보호 책임 강화

□ 개인정보 수집 최소화

o 홈페이지 가입시 주민번호 등 개인정보 수집 최소화

o 주민번호 제공 없이도 본인 확인을 받아 인터넷에 가입할 수 있도록 사업자의 대체수단(G-PIN 등) 이용서비스 제공

□ 개인정보 이용․저장 관리수준 향상

o 이용자가 웹사이트 회원 가입을 위한 비밀번호 생성 또는 비밀번호 변경 시, 안전성이 확보되도록 비밀번호 작성 기준 적용

※ 8자리 이상, 문자․숫자 혼용, 일정기간 경과시 비밀번호 변경 의무화 등

o 개인정보 보유 기관․사업자는 주민번호, 계좌번호 등 금융정보를 암호화하여 보관토록 조치

o 기관 등의 홍보․공지를 위해 웹사이트 자료 게재시, 자료 게재 담당자 지정 및 부서장 확인 절차 수립․이행

5		개인정보보호 인식 제고

o 홈페이지 회원 및 내부 직원 대상 개인정보보호 중요성에 대한  홍보 캠페인 실시

o 정보보호․개인정보보호 담당자를 대상으로 해킹 대응․개인정보보호 조치 전반에 대한 실무 전문 교육 강화

o ‘주민번호 클린캠페인’ 실시를 통해, 주민번호 유․노출의 위험성을 알리고, 웹사이트 상에서 주민번호 제거 조치

< 참고 1 >

홈페이지 취약점 점검 방안

1. 디렉토리 리스팅 취약점

개요		인터넷 이용자에게 웹 서버 내 모든 디렉토리 및 파일 목록을 보여주고, 파일의 열람 및 저장도 가능하게 하는 취약점
점검범위		점검 대상 홈페이지에 디렉토리 리스팅 취약점이 존재하는지 여부를 점검하고, 디렉토리 리스팅 취약점 페이지가 구글엔진에 저장되었지는 여부를 점검한다.
점검방법	구글을 통한 점검 방법	구글 사이트에 접속한다. 고급 검색으로 이동한다. 도메인 설정 란에는 해당 사이트 주소를 입력하고, 검색창에는 다음을 입력하여 디렉토리 목록이 저장된 페이지를 찾는다. intitle:index.of "parent directory" intitle:index.of name size 검색 결과를 바탕으로 해당 사이트의 디렉토리 노출을 확인한다.
	직접 점검 방법	해당 웹 사이트의 하위 디렉토리 정보를 사전에 모두 확인한다. 웹 루트의 모든 하위 디렉토리에 대해서 웹 브라우저에 해당 주소를 입력해서 디렉토리 노출 여부를 점검한다. 예) http://www.sample.go.kr/ 이란 웹 서버의 웹 루트 밑에 “file”이란 디렉토리가 있다면 웹 브라우저의 URL 주소 입력란에 http://www.sample.go.kr/file/ 이라고 입력한다. 이 때 “file” 디렉토리 하위 내용이 모두 화면에 출력된다면 디렉토리 리스팅 취약점이 존재하는 것이다.(반드시 맨 끝의 ‘/’ 까지 입력) 모든 디렉토리에 대해 디렉토리 리스팅 취약점 존재 여부를 확인한다.
조치방법	구글 캐쉬에 노출된 경우	개인정보 취약점 페이지가 구글에 노출된 경우에는 먼저 홈페이지에도 개인정보 취약점 노출이 있는지 여부를 확인하여 홈페이지의 개인정보 취약점을 제거 한 후, 구글 검색 사이트에 해당 캐쉬에 대해 삭제를 요청하는 이메일을 발송한다. 개인정보의 노출 정도가 심각하여 긴급하게 노출을 방지하고자 한다면, 구글의 자동 URL 삭제 시스템을 이용하여, URL이 검색되지 않도록 한다. ※구글 자동 URL 삭제 시스템: http://services.google.com:8882/urlconsole/controller?cmd=reload&lastcmd=login
	직접 점검 시 노출의 경우 (윈도우)	[제어판]→[관리도구]의 [인터넷 서비스 관리자](혹은 [인터넷 정보 서비스]) 메뉴에서 [기본 웹 사이트]의 마우스 오른쪽 클릭, ‘속성’ 부분을 보면 ‘기본 웹 사이트 등록 정보’가 나온다. ‘기본 웹 사이트 등록 정보’에서 ‘홈 디렉토리’ 부분을 클릭한 후 ‘디렉토리 검색(B)' 부분의 체크를 해지한다.
	직접 점검 시 노출의 경우 (리눅스 /유닉스)	서버에서 “httpd.conf” 라는 파일을 찾는다. 파일 내용 중 Options 항목 뒤에 Indexes 라는 단어를 지우고 파일을 저장한다. 이 때, Options 는 디렉토리 별로 설정할 수 있게 되어 있으므로 모든 디렉토리에 대해서 Options 항목을 제거한다. 설정을 적용하기 위해 웹 서버 데몬을 다시 띄워준다.

2. 파일 다운로드 취약점

개요	게시판 등에 저장된 자료에 대해 위치 지정에 대한 제한을 부여하지 않음으로써 웹 서버 내의 비공개 자료를 다운로드 받을 수 있도록 하는 취약점
점검 범위	점검 대상이 되는 홈페이지에 파일 다운로드 기능이 존재하는지 여부를 점검하고, 파일 다운로드 스크립트 이용 여부를 확인한 후, 다운로드 스크립트의 매개변수를 변경하면서 주요 파일 다운로드를 시도한다.
점검 방법	게시판이 존재하는지, 그리고 그 게시판에 파일 다운로드 기능이 있는지 점검한다. 파일 다운로드 기능이 존재하지 않으면 ‘파일 다운로드’ 취약점은 존재하지 않는다. 파일 다운로드 기능이 존재하는 경우, 파일 다운로드 시의 URL 주소를 확인하여 파일 다운로드 스크립트를 이용하는지 여부를 확인한다. 파일 다운로드 URL 주소 확인은 첨부파일 하이퍼링크 부분에 마우스를 가져가 아래 상태표시줄로부터 링크를 확인하거나 팝업 메뉴의 ‘바로가기 복사(T)'를 클릭하고 메모장 등에서 ’붙여넣기‘ 함으로써 확인할 수 있다. 파일 다운로드 스크립트를 이용하지 않으면 ‘파일 다운로드’ 취약점은 존재하지 않는다. <다운로드 스크립트를 사용하지 않는 경우의 예> http://servername.go.kr/test/download/공지사항1.hwp <다운로드 스크립트를 사용하는 경우의 예> http://servername.go.kr/test/filedown.down?file=공지사항3.hwp&path=download 파일 다운로드 스크립트를 이용하는 경우, 매개변수를 변경하면서 주요 파일 다운로드를 시도한다. 이 때, 매개변수의 개수 및 경로를 적는 형식이 조금씩 틀리므로 링크 주소에 따라 상대적으로 매개변수 변경을 시도해야 한다.
	① /etc/passwd 파일 다운로드 시도
	asp 게 시 판	<정상적인 링크> http://servername.go.kr/pr/download.asp?filename=test.hwp <다운로드 시도> http://servername.go.kr/pr/download.asp?filename=/etc/passwd http://servername.go.kr/pr/download.asp?filename=../../../etc/passwd 등의 형태로 시도하되, 링크 중 ../의 개수를 1개부터 10개까지 점차 증가시키면서 시도한다.
	PHP게 시 판	<정상적인 링크> http://servername.go.kr/includes/download.php?sub_path=upfiles&filename=test.hwp <다운로드 시도> http://servername.go.kr/includes/download.php?sub_path=../../../etc&filename=passwd http://servername.go.kr/includes/download.php?sub_path=upfiles&filename=../../../../../../etc/passwd 등의 형태로 시도하되, 위의 두 가지 링크 각각에 대해 ../의 개수를 1개부터 10개까지 점차 증가시키면서 시도한다.
	jsp 게 시 판	<정상적인 링크> http://servername.go.kr/include/down.jsp?upfile=test.hwp&dir=/data <다운로드 시도> http://servername.go.kr/include/down.jsp?upfile=passwd&dir=/etc http://servername.go.kr/include/down.jsp?upfile=passwd&dir=/data/../../../etc 등의 형태로 시도하되, 위의 두 번째 링크에 대해 ../의 개수를 1개부터 10개까지 점차 증가시키면서 시도한다.
	기타 게 시 판	<정상적인 링크> http://servername.go.kr/servlet/Down?path=/DATA/docu/2006/10/10&name=test.hwp <다운로드 시도> http://servername.go.kr/servlet/Down?path=../../../../etc&name=passwd http://servername.go.kr/servlet/Down?path=/DATA/../../../etc&name=passwd 등의 형태로 시도하되, 링크 중 ../의 개수를 1개부터 10개까지 점차 증가시키면서 시도한다.
	② download 파일 다운로드 시도
	ASP 게 시 판	<정상적인 링크> http://servername.go.kr/pr/download.asp?filename=test.hwp <다운로드 시도> http://servername.go.kr/pr/download.asp?filename=../pr/download.asp 등의 형태로 시도하되, 링크 중 ../의 개수를 1개부터 10개까지 점차 증가시키면서 시도한다.
	PHP 게 시 판	<정상적인 링크> http://servername.go.kr/includes/download.php?sub_path=upfiles&filename=test.hwp <다운로드 시도> http://servername.go.kr/includes/download.php?sub_path=includes&filename=download.php http://servername.go.kr/includes/download.php?sub_path=upfiles&filename=../../../../../../includes/download.php 등의 형태로 시도하되, 위의 두 번째 경우에 대해서는 ../의 개수를 1개부터 10개까지 점차 증가시키면서 시도한다.
	jsp 게 시 판	<정상적인 링크> http://servername.go.kr/include/down.jsp?upfile=test.hwp&dir=/data <다운로드 시도> http://servername.go.kr/include/down.jsp?upfile=down.jsp&dir=/include 등의 형태로 시도하되, 링크 중 ../의 개수를 1개부터 10개까지 점차 증가시키면서 시도한다.
	다운로드 시도가 성공하는 경우 직접 웹 브라우저 화면에 내용이 뜨거나 ‘파일 저장’을 통해 저장이 될 수 있다. 이 경우들은 모두 파일 다운로드 취약점을 가지고 있는 경우이다.
조치 방법	첨부파일이 저장되어 있는 특정 디렉토리에 있는 파일만을 다운 받을 수 있도록 하기 위해 첨부파일을 다운받기 위해 사용하는 다운로드 스크립트를 다음과 같은 방법으로 수정해야 한다. 다운받기 위한 파일 이름에 “..”, “/”, “\”와 같은 문자열이 존재하면 모두 필터링한다. 이 부분은 웹 서버 설정으로 해결할 수 있는 것이 아니로 스크립트의 내용을 수정해야 한다. 스크립트 수정이 된 후에 다시 한번 취약점 점검 때와 같이 파일 다운로드가 되는지 여부를 확인하는 시도를 통해 취약점이 여전히 존재하는지를 점검한다.

3. 파일 업로드 취약점

개요	게시판에서 첨부파일을 업로드 하는 경우, 악성 실행 프로그램을 업로드한 후에 홈페이지 접속 방식으로 웹서버를 원격 제어할 수 있게 하는 취약점
점검범위	점검 대상이 되는 홈페이지에 파일 업로드 기능이 존재하는지 여부를 점검하고, 특정 확장자를 가진 악성파일의 업로드를 시도한다.
점검방법	게시판이 존재하는지, 그리고 그 게시판에 파일 업로드 기능이 있는지 점검한다. 파일 업로드 기능이 존재하지 않으면 ‘파일 업로드’ 취약점은 존재하지 않는다. 파일 업로드 기능이 존재하는 모든 게시판에 대해서, php, php3, asp, jsp, cgi, inc, pl 등의 확장자를 가진 파일 업로드를 시도한다. 파일 업로드를 확인하였을 때, 실제 업로드가 되었다면 ‘파일 업로드’ 취약점이 존재한다.
조치방법	게시판의 첨부파일 업로드를 처리하는 웹 소스코드에서 첨부파일의 확장자를 필터링하도록 처리한다. 게시판 작성 후 업로드 버튼을 클릭할 때, 첨부파일을 확인하여 php, php3, asp, jsp, cgi, inc, pl 등의 확장자를 갖는 파일의 경우는 경고창을 띄워 업로드를 제한한다. 웹 소스 수정을 한 후에 다시 한 번 취약점 점검과 같은 시도를 통해 취약점이 여전히 존재하는지를 점검한다.

4. 크로스 사이트 스크립트(XSS)

개요	게시판에서 글쓰기를 하는 경우, 입력 내용 중 실행코드인 스크립트의 태그에 대한 필터링을 하지 않아서 악의적인 스크립트 등록을 통해 일반 이용자 PC로부터 개인정보인 쿠키 등을 유출할 수 있게 하는 취약점
점검범위	점검 대상이 되는 홈페이지 게시판에 글쓰기 기능이 존재하는지 여부를 점검하고, 간단한 스크립트 문장을 입력하여 게시를 시도한다.
점검방법	게시판, 의견쓰기, 게시마당, 민원신청, 여론마당 등에 대해 일반 사용자들이 글을 게시할 수 있는 기능이 있는지 점검한다. 글쓰기 기능이 전혀 없으면 ‘XSS 취약점’은 존재하지 않는다. 글쓰기 기능이 있는 게시판에 대해 본문에 다음과 같은 스크립트 문장을 입력하고 게시를 시도한다. <script>alert('XSS 취약점 존재‘);</script> 글을 게시하는 중에 스크립트 태그 사용에 대한 ‘에러’나 ‘경고’ 메시지가 뜨면서 등록이 안된다면 ‘XSS 취약점’이 존재하지 않는 것이다. 윈도우 경고창이 전혀 뜨지않고 글 본문에 스크립트 문장이 입력한 대로 나오면 XSS 취약점이 존재하지 않는 것이다. 윈도우 경고창을 통해 'XSS 취약점 존재‘ 나 “XSS&nbsp;취약점&nbsp;존재”와 같은 형태의 팝업창이 뜨면 ‘XSS 취약점’이 존재하는 것이다.
조치방법	XSS 취약점은 웹 서버 설정으로는 조치할 수 없다. 글쓰기가 가능한 게시판 페이지에서 이용자가 스크립트를 입력할 수 없도록 다음과 같이 조치한다. 스크립트 문장에 존재할 수 있는 <, >, (, ), #, & 등의 메타 문자를 다른 문자로 변환하거나 글 게재 시점에서 스크립트가 있는 경우에는 게재를 차단한다. 웹 소스코드 수정이 된 후에 다시 한 번 XSS 취약점이 있는 지 점검한다.

5. SQL Injection

개요	웹브라우저 주소창, 이용자 ID/패스워드 입력화면 등에서 데이터베이스 SQL문에 이용되는 문자기호 입력을 필터링하지 않은 경우, 이용자가 SQL 조작에 의한 입력을 통해 데이터베이스에 인증절차 없이 접근하여 자료를 무단 유출하거나 변조할 수 있는 취약점
점검범위	웹사이트의 기본적인 사용자 인증창 우회 SQL Injection 취약점 점검 방법을 이용하여 취약점 존재 가능성을 점검한다.
점검방법	홈페이지 관리자 로그인 페이지로 이동한다. 관리자 아이디와 패스워드에 아래 문자열을 입력하여 결과를 확인한다. ① ‘or 1=1;- - ② ‘ ’ or 1=1- - ③ "or 1=1 -- ④ or 1=1-- ⑤ 'or 'a'='a ⑥ " or "a"="a ⑦ ')or('a'='a ⑧ sql' or 1=1- - ⑨ sql" or 1=1-- ⑩ + or 1=1- - ⑪ ';- - 인증 실패 메시지가 나타날 경우, ‘SQL Injection 취약성’은 존재하지 않는다. 로그인 될 경우, SQL Injection 취약점이 존재한다. 홈페이지 오류 메시지가 나타날 경우, SQL Injection 가능성이 있으므로 세부적인 점검이 필요하다는 것을 의미한다.
조치방법	ID, Password 란에 특수문자를 입력하지 못하도록 소스코드를 수정한다. 웹 소스코드 수정이 된 후에 다시 한 번 취약점을 점검한다.

6. 쿠키 암호화

개요	쿠키를 변조하여 불법적인 인증을 거쳐 웹서버에 접근하는 취약점
점검범위	쿠키정보를 통해 개인정보 노출 발생 여부를 확인하기 위해 쿠키정보가 암호화되어 저장되었는지를 점검한다.
점검방법	로그인을 수행한다. 웹 브라우저 주소 창에 javascript:document.cookie; 를 입력하여 쿠키 내용이 암호화되었는지 여부를 확인한다.
조치방법	가장 효과적인 방법은 SSL과 같은 보안 서버 기능을 적용함으로써 로그인 트랜잭션 전체를 암호화하는 방법이다. 쿠키저장 시 타인이 임의로 쿠키를 읽을 수 없도록 도메인과 경로 지정에 유의해야 하며, 브라우저에 저장되는 쿠키방식보다는 서버 측에 일부 정보를 저장하여 상호 대조할 수 있는 세션 방식으로 대체하고 세션방식의 경우도 사용자의 IP 주소 등을 함께 저장하여 유효성 여부를 확인한다.

7. 접근통제 취약점

개요		권한이 없는 이용자가 특정 경로를 통해 관리자 페이지나 DB에 접근할 수 있게 하는 취약점
점검범위		접근 통제의 기본이 되는 ID/PW 정보의 노출 및 관리자 홈페이지의 노출 여부를 점검한다.
점검 방법	구글을 통한 점검 방법	구글 사이트에 접속한다. 고급 검색으로 이동한다. 도메인 설정에는 해당 홈페이지 주소를 입력하고 검색어 입력 박스에는 다음을 입력하여 ID/PW 노출 및 관리자 홈페이지 노출 페이지를 찾는다. login | logon password|passcode|비밀번호|“your password is"|"당신의 비밀번호는” admin | administrator
	직접 점검 방법	일반적으로 많이 사용하는 관리자 페이지 명을 입력하여 관리자 페이지가 존재하는지 점검한다. - http://admin.test.go.kr - http://www.test.go.kr/admin/ - http://www.test.go.kr/manager/ - http://www.test.go.kr/master/ - http://www.test.go.kr/system/ 이용자 인증을 통과하여 페이지에 접속한 후, 인증과정없이 중간 페이지에 접속하여 접속이 가능한지 점검한다.
조치 방법	구글 캐쉬에 노출된 경우	개인정보 취약점 페이지가 구글에 노출된 경우에는 먼저 홈페이지에도 개인정보 취약점 노출이 있는지 여부를 확인하여 홈페이지의 개인정보 취약점을 제거 한 후, 구글 검색 사이트에 해당 캐쉬에 대해 삭제를 요청하는 이메일을 발송한다. 검색엔진 배제표준을 이용하여 개인정보가 포함된 주소를 지정하는 robot.txt 파일을 만들어 서버 루트 디렉토리에 저장하거나 해당 페이지의 HTML 안에 메타태그를 입력한다. 개인정보의 노출 정도가 심각하여 긴급하게 노출을 방지하고자 한다면, 구글의 자동 URL 삭제 시스템을 이용하여, URL이 검색되지 않도록 한다. ※ 구글 자동 URL 삭제 시스템: http://services.google.com:8882/urlconsole/controller?cmd=reload&lastcmd=login
	직접 점검을 통해 노출된 경우	관리자 페이지에 임의의 사용자가 접근할 수 없도록 관리자 페이지에 접근할 수 있는 권한을 가진 단말기만 접근 가능하도록 접근권한을 설정한다. 웹 관리자 메뉴의 접근을 특정 네트워크 대역으로 제한하여, IP 주소까지도 인증 요소로 체크하도록 웹 관리자 사용자 인터페이스를 개발하고, 관리자 인증 후 접속할 수 있는 페이지의 경우 해당 페이지 주소를 직접 입력하여 접속하지 못하도록 관리자 페이지 각각에 대하여 관리자 인증을 위한 세션관리를 한다.