ISMS-P 결함사례 고찰 #2.9. 시스템 및 서비스 운영관리

2.9.1 변경관리

인증기준: 정보시스템 관련 자산의 모든 변경내역을 관리할 수 있도록 절차를 수립·이행하고, 변경 전 시스템의 성능 및 보안에 미치는 영향을 분석하여야 한다.

 

결함사례#1

최근 DMZ 구간 이중화에 따른 변경 작업을 수행하였으나, 변경 후 발생할 수 있는 보안위험성 및 성능 평가에 대한 수행·승인 증거자료가 확인되지 않은 경우가 있다. 언제나 변경 작업이 있을 때는 그에 따른 위험 평가를 하는 것이 보편적이다. 이미 여러 번 작업을 하였다고 하더라도, 새로운 취약점이 생길 수도 있기 때문이다. 그렇기에 이를 누락하지 말고, 변경 업무와 한 세트로 받아들이고 작업에 임해야 할 것이다.

 

결함사례#2

최근 네트워크 변경 작업을 수행하였으나 관련 검토 및 공지가 충분히 이루어지지 않아 네트워크 구성도 및 일부 접근통제시스템(침입차단시스템, 데이터베이스 접근제어시스템 등)의 접근통제 리스트(ACL)에 적절히 반영되어 있지 않은 경우가 있다. 이런 경우는 은근히 종종 있는 편인데, 개인적으로 이때에는 일종의 지침이나 프레임워크를 마련해서 업무를 진행하는 것이 좋다고 생각한다.

 

결함사례#3

변경관리시스템을 구축하여 정보시스템 입고 또는 변경 시 성능 및 보안에 미치는 영향을 분석· 협의하고 관련 이력을 관리하도록 하고 있으나, 해당 시스템을 통하지 않고도 시스템 변경이 가능하며, 관련 변경사항이 적절히 검토되지 않는 경우가 있다. 해당 시스템을 통하지 않고도 시스템 변경이 가능하다는 것은 결국 공격자가 얼마든지 우회하여 공격할 수 있다는 것을 의미한다. 항상 시스템을 구축할 떄는 정해진 경로 외에 들어갈 수 있는 방법에 대해 검토하고 조치를 취해야 한다.

2.9.2 성능 및 장애관리

인증기준: 정보시스템의 가용성 보장을 위하여 성능 및 용량 요구사항을 정의하고 현황을 지속적으로 모니터링하여야 하며, 장애 발생 시 효과적으로 대응하기 위한 탐지·기록·분석·복구·보고 등의 절차를 수립·관리하여야 한다.

 

결함사례#1

성능 및 용량 관리를 위한 대상별 요구사항(임계치 등)을 정의하고 있지 않거나 정기 점검보고서 등에 기록하고 있지 않아 현황을 파악할 수 없는 경우가 있다. 임계치를 정의하지 않게 되면 나중에 가용성에 문제가 생길 염려가 있다. 성능 및 용량을 관리하는 담당자를 따로 지정하여 이에 대한 누락이 생기지 않도록 해야 할 것이다.

 

결함사례#2

성능 또는 용량 기준을 초과하였으나 관련 검토 및 후속조치방안 수립·이행이 이루어지고 있지 않은 경우가 있다. 임계치를 초과하는 경우에는 즉시 대응절차를 수립하고 이행해야 한다. 위에서도 말했듯 임계치를 초과하면 가용성에 문제가 생길 수 있기 때문에 바로 작업을 들어가야 한다. 공격자를 떠나서 정보시스템 자체에 이미 장애가 걸릴 수 있다. 공격자의 공격도 아니고, 그저 시스템을 제대로 구축하지 않아서 문제가 생긴다는 것은 너무 우스운 일이 될 것이다.

 

결함사례#3

전산장비 장애대응절차를 수립하고 있으나 네트워크 구성 및 외주업체 변경 등의 내·외부 환경변화가 적절히 반영되어 있지 않은 경우가 있다. 보통 장애 대응 절차라던지, 공격 대응 절차라던지 이런 대응에 대한 절차를 만들었을 때는 그것을 실제로 연습해보는 경험도 중요하다. 그런데 내부, 외부 환경변화가 적절히 반영되어 있지 않다는 것은 그런 연습을 해본 적이 없다는 것을 의미할 것이다. 보안 담당자는 신이 아니기 때문에 여러 대응 방안에 대한 연습이 요구된다. 그렇게 되면 이와 같은 결함 사례는 자연스레 사라질 것이다.

 

결함사례#4

장애처리절차와 장애유형별 조치방법 간 일관성이 없거나 예상소요시간 산정에 대한 근거가 부족하여 신속·정확하고 체계적인 대응이 어려운 경우가 있다. 장애 발생 시 절차에는 물론 일관성과 세부적인 근거가 요구된다. 결국 이것도 #3과 이어지는 것인데, 직접 실전을 가장하여 연습을 해봐야 느낄 수 있다. 그래야 문제점을 파악하고, 체계적인 대응을 위한 더욱 실전에 맞는 조치방법을 구성할 수 있을 것이다.

 

2.9.3 백업 및 복구관리

인증기준: 정보시스템의 가용성과 데이터 무결성을 유지하기 위하여 백업 대상, 주기, 방법, 보관장소, 보관기간, 소산 등의 절차를 수립·이행하여야 한다. 아울러 사고 발생 시 적시에 복구할 수 있도록 관리하여야 한다.

 

결함사례#1

백업 대상, 주기, 방법, 절차 등이 포함된 백업 및 복구 절차가 수립되어 있지 않은 경우가 있다. 백업은 기본이다. 그것이 물리적 백업이건, 논리적 백업이건, 증분 백업이건, 무엇이 되었건 간에, 백업은 업무에 있어서 언제나 기본으로 여겨야 한다. 그리고 그 백업에 관해서도 당연히 절차가 수립되어 있어야 한다. 모든 담당자가 다 제각각으로 진행해서는 안 되니 말이다. 기본을 지키지 않고 공격을 당했을 때 피해가 커지면, 이미 상황은 너무 늦었다.

 

결함사례#2

백업정책을 수립하고 있으나 법적 요구사항에 따라 장기간(6개월, 3년, 5년 등) 보관이 필요한 백업 대상 정보가 백업 정책에 따라 보관되고 있지 않은 경우가 있다. 언제나 조직 내의 지침에만 따르지 말고, 상위 근거인 법에 대해서도 주의를 기울일 필요가 있다. 법의 내용을 보면 사실 너무 강한 요구사항이 있지는 않다. '이 정도는 해야 하지 않겠냐' 수준인 것이 보통이다. 그렇기에 법적 요구사항을 기준으로 하게 된다면, 최소한의 기준은 맞출 수 있게 된다는 의미가 되기도 한다. 그래서 법적 요구사항을 기본으로 깔고, 그 안에서 추가적으로 조직 내 지침에 따라 요구사항을 더하는 것이 좋지 않을까 싶다.

 

결함사례#3

상위 지침 또는 내부 지침에 따라 별도로 백업하여 관리하도록 명시된 일부 시스템(보안시스템 정책 및 로그 등)에 대한 백업이 이행되고 있지 않은 경우가 있다. 보안시스템 이벤트 로그, 감사 로그 같은 것들은 주요 백업 대상으로 고려되는 대표적인 예시들 중 하나이다. 주요 백업 대상에 대해서도 미리 대상을 판별하고 그에 따라 백업관리대장을 운영하는 것이 좋다고 생각한다.

 

결함사례#4

상위 지침 또는 내부 지침에는 주기적으로 백업매체에 대한 복구 테스트를 수행하도록 정하고 있으나 복구테스트를 장기간 실시하지 않은 경우가 있다. 복구테스트도 담당자를 배정하고, 주기나 시점, 방법 등에 대한 계획과 시나리오를 수립해야 한다. 그래서 복구테스트를 실시하고, 그에 대한 문제점을 발견하여 조치를 취해야 한다. 개발 업무에 아주 얕게라도 발을 담군 적이 있다면 공겜하겠지만, 보통 테스트라는 것을 실시하면 언제나 내 생각과는 다른 결과가 나오기 마련이다.. 스스로와 조직을 너무 맹신해서는 안 될 것이다..

 

2.9.4 로그 및 접속기록 관리

인증기준: 서버, 응용프로그램, 보안시스템, 네트워크시스템 등 정보시스템에 대한 사용자 접속기록, 시스템로그, 권한부여 내역 등의 로그유형, 보존기간, 보존방법 등을 정하고 위·변조, 도난, 분실되지 않도록 안전하게 보존·관리하여야 한다.

 

결함사례#1

로그 기록 대상, 방법, 보존기간, 검토 주기, 담당자 등에 대한 세부 기준 및 절차가 수립되어 있지 않은 경우가 있다. 로그 기록도 역시나 담당자를 배정하여 각 로그 기록이 위조, 변조, 도난, 분실되지 않도록 이에 대한 안전한 보관을 위해 절차를 수립해야 한다. 이떄 로그기록에 대한 접근권한을 최소화하는 것은 물론이고 말이다.

 

결함사례#2

보안 이벤트 로그, 응용프로그램 및 서비스 로그(윈도우 2008 서버 이상) 등 중요 로그에 대한 최대 크기를 충분하게 설정하지 않아 내부 기준에 정한 기간 동안 기록·보관되고 있지 않은 경우가 있다. 이것도 담당자가 결국에는 로그 기록을 검토하며 최대 크기를 충분하게 설정해야 했는데, 그것을 누락한 것으로 보인다. 디폴트에 비해 값이 큰 경우가 분명 존재하므로, 이에 대해서도 설정을 해야 할 것이다.

 

결함사례#3

중요 Linux/UNIX 계열 서버에 대한 로그 기록을 별도로 백업하거나 적절히 보호하지 않아 사용자의 명령 실행 기록 및 접속 이력 등을 임의로 삭제할 수 있는 경우가 있다. 이것을 임의로 삭제할 수 있다는 것은, 공격자가 공격을 할 때 자신의 흔적을 너무나도 쉽게 지울 수 있다는 것과 동일하다. 보통 공격자들은 흔적을 지우는 데에도 시간을 다소 쓰는데, 이렇게 되면 공격자에게 더욱 시간적인 여유를 안기는 환경을 만들어 주는 것이다. 임의로 삭제하는 경로는 반드시 막아야 한다.

 

결함사례#4

개인정보처리시스템에 접속한 기록을 확인한 결과 접속자의 계정, 접속 일시, 접속자 IP주소 정보는 남기고 있으나, 처리한 정보주체 정보 및 수행업무(조회, 변경, 삭제, 다운로드 등)와 관련된 정보를 남기고 있지 않은 경우가 있다. 어떤 정보주체의 업무를 처리했고, 어떤 내용의 업무를 수행했는지를 남기는 것은 필수적이다. 이것은 법과 각종 지침에도 '필수적'인 것으로 명시되어 있는 내용이다. 그렇기에 이에 대한 누락을 하는 것은 있어서는 안 되는 일이다. 타인의 개인정보를 다루는 것인 만큼, 이에 대한 업무는 의심을 남기는 행위를 해서는 안 될 것이다.

 

결함사례#5

로그 서버의 용량의 충분하지 않아서 개인정보처리시스템 접속기록이 2개월 밖에 남아 있지 않은 경우가 있다. 접속기록은 보통 2년 이상 보존해야 하는 경우가 많다. 그게 법으로 정해져 있으며, 그렇기에 2년 이상을 보존할 수 있도록 반드시 용량을 확보해야 할 것이다.

 

결함사례#6

개인정보처리자가 정보주체 10만 명의 개인정보를 처리하는 개인정보처리시스템의 개인정보취급자 접속기록을 1년간만 보관하고 있는 경우가 있다. #5와 이어지는 건이며, 법에 분명하게 명시가 되어 있음에도 불구하고, 법을 무시하는 경우로 보인다. 이때 용량 때문에 어쩔 수 없었다는 변명을 하더라도, 일부러 접속기록을 빨리 지우게 설계한 것이 아니냐는 의심을 받아야 할 것이다. 항상 조직의 지침보다는 법의 내용을 우선하는 것을 당연시 여겨야 한다.

 

2.9.5 로그 및 접속기록 점검

인증기준: 정보시스템의 정상적인 사용을 보장하고 사용자 오·남용(비인가접속, 과다조회 등)을 방지하기 위하여 접근 및 사용에 대한 로그 검토기준을 수립하여 주기적으로 점검하며, 문제 발생 시 사후조치를 적시에 수행하여야 한다.

 

결함사례#1

중요 정보를 처리하고 있는 정보시스템에 대한 이상접속(휴일 새벽 접속, 우회경로 접속 등) 또는 이상행위(대량 데이터 조회 또는 소량 데이터의 지속적·연속적 조회 등)에 대한 모니터링 및 경고·알림 정책(기준)이 수립되어 있지 않은 경우가 있다. 이상징후에 대해 정책을 마련하지 않았다는 것은, 실제로 그런 상황이 발생했을 때 대응이 정말 제대로 되지 않을 수밖에 없다는 것을 의미한다. 이것도 결국 마찬가지이다. 만일의 상황에 대해 실제적인 연습을 하지 않았기 때문에 이런 결함사례가 발생할 수 있는 것이다.

 

결함사례#2

내부 지침 또는 시스템 등에 접근 및 사용에 대한 주기적인 점검·모니터링 기준을 마련하고 있으나 실제 이상접속 및 이상행위에 대한 검토 내역이 확인되지 않은 경우가 있다. 이것도 #1과 마찬가지이다. 실제로 연습을 해봤다면, 기존 시스템이 그저 구축만 되어있을 뿐 평소에 검토를 하지 않는다는 것을 인지할 수 있을 텐데 말이다. 기껏 구축하고 사용하지 않는다면 그게 무슨 소용이 있을까 싶다.

 

결함사례#3

개인정보처리자가 개인정보처리시스템의 접속기록 점검 주기를 분기 1회로 정하고 있는 경우가 있다. 점검 주기는 법령에서 월 1회 이상으로 정하고 있다. 사실 보통 이런 '주기'에 대해서는 의외로 법에서 정하고 있는 경우가 많다. 따라서 이에 대해서는 조직의 지침을 따르기에 앞서 관련 법령을 먼저 살펴보는 것이 좋을 것이다.

 

결함사례#4

개인정보처리자의 내부 관리계획에는 1,000명 이상의 정보주체에 대한 개인정보를 다운로드한 경우에는 사유를 확인하도록 기준이 책정되어 있는 상태에서 1,000건 이상의 개인정보 다운로드가 발생하였으나 그 사유를 확인하지 않고 있는 경우가 있다. 개인정보를 다운로드할 때는 사유 확인 기준 및 결과가 존재해야 한다. 이것은 개인정보의 안전성 확보 조치에 속한 것으로 볼 수 있겠다. 아마 업무를 하다 보면 1,000명 이상의 정보주체에 대한 개인정보를 다운로드하는 경우가 은근 많은 조직들이 있을 것이다. 워낙 자주 발생하는 업무라도, 법에서 정해져 있다면 그것을 따라야 하는 것은 당연한 순리일 것이다.

 

2.9.6 시간 동기화

인증기준: 로그 및 접속기록의 정확성을 보장하고 신뢰성 있는 로그분석을 위하여 관련 정보시스템의 시각을 표준시각으로 동기화하고 주기적으로 관리하여야 한다.

 

결함사례#1

일부 중요 시스템(보안시스템, CCTV 등)의 시각이 표준시와 동기화되어 있지 않으며, 관련 동기화 여부에 대한 주기적 점검이 이행되고 있지 않은 경우가 있다. 보통은 NTP를 사용하여 시스템 간 시간을 동기화할 것이다. 그런데 이것이 있다고 해서 끝나는 게 아니라, 주기적으로 시간 동기화가 정상적으로 이뤄지고 있는지 점검해야 할 것이다. 모든 시스템이 언제나 딱딱 맞아 떨어지는 건 아니니 말이다.

 

결함사례#2

내부 NTP 서버와 시각을 동기화하도록 설정하고 있으나 일부 시스템의 시각이 동기화되지 않고 있고, 이에 대한 원인분석 및 대응이 이루어지고 있지 않은 경우가 있다. #1의 연장선으로 이어지는 내용인데, 동기화 오류가 발생하였다면 당연히 원인 분석을 해야 한다. OS에 문제가 있을 수도 있고, 다른 설정에 문제가 있을 수도 있고, 이유는 몇 가지 있을 것이다. 점검을 하는 이유가 단순히 시간이 맞는지만 확인하는 것이 아니기 때문에, 문제가 생길 경우 그에 대한 방안도 만들어야 할 것이다.

 

2.9.7 정보자산의 재사용 및 폐기

인증기준: 정보자산의 재사용과 폐기 과정에서 개인정보 및 중요정보가 복구·재생되지 않도록 안전한 재사용 및 폐기 절차를 수립·이행하여야 한다.

 

결함사례#1

개인정보취급자 PC를 재사용할 경우 데이터 삭제프로그램을 이용하여 완전삭제 하도록 정책 및 절차가 수립되어 있으나, 실제로는 완전삭제 조치 없이 재사용하거나 기본 포맷만 하고 재사용하고 있는 등 관련 절차가 이행되고 있지 않은 경우가 있다. 이런 경우는 정말이지 정말이지 너무 많다. 특히나 보안 부서가 제대로 없는 회사일 경우는 더욱 그러한 것이 실정이다. 휴지통을 비운다고 해서 삭제가 이뤄지지 않는다는 것은 어찌 보면 기본인데, 그것을 수행했으니 그만이라는 것과 다름 없는 상황이 많다는 것이다. 복원이 불가능한 방법에 대해서는 알려진 것이 몇 가지 있으니 이를 수행하여 완전삭제를 이뤄야 할 것이다.

 

결함사례#2

외부업체를 통하여 저장매체를 폐기하고 있으나, 계약 내용상 안전한 폐기 절차 및 보호대책에 대한 내용이 누락되어 있고 폐기 이행 증거자료 확인 및 실사 등의 관리·감독이 이루어지지 않은 경우가 있다. 폐기에 대해서도 당연히 담당자가 있어야 하고, 그 담당자는 폐기가 제대로 이행되었는지 증거자료와 사용된 방법을 확인하고 실제로도 결과를 파악해 볼 필요가 있다. 외부업체가 제대로 했는지, 대충 했는지 파악은 해야 하니 말이다.

 

결함사례#3

폐기된 HDD의 일련번호가 아닌 시스템명을 기록하거나 폐기 대장을 작성하지 않아 폐기 이력 및 추적할 수 있는 증거자료를 확인할 수 없는 경우가 있다. 폐기 이력이나 증거자료를 확인할 수 없다면 결국 그것이 완전히 폐기되었는지 확인할 수 없다는 것을 의미한다. 정보자산 및 저장매체에 대해서는 폐기 증거자료를 온전히 보관해야 하는 것을 원칙으로 삼아야 한다.

 

결함사례#4

회수한 폐기 대상 하드디스크가 완전삭제 되지 않은 상태로 잠금장치가 되지 않은 장소에 방치되고 있는 경우가 있다. 그러니까 이것은 결국 중요한 정보를 담은 자료가 누구나 접근 가능한 영역에 놓아져 있다는 말이다. 아직 폐기를 진행하지 않았더라면, 폐기 이전까지는 마치 암호문 처럼 보안 취급을 하여 보관해야 한다. 자기의 가족관계증명서, 등본, 부동산계약서를 누구나 접근할 수 있는 곳에 놔두어도 아무렇지 않은 사람이 있을까? 그렇게 생각하면 이것의 중요성을 더욱 이해할 수 있을 것이다.