정보보안에서 가장 중요한 데이터, '로그'를 파헤치다
명일 이직을 원하는 IT 보안 로그 분석 전문 회사의 면접을 앞두고,
본인은 정보통신 보안 업계에 속해있다. 여기서 취급하는 디지털 세계에서 가장 중요하다고 생각하는 물적 증거는 '로그(log)'다.
1. 로그란?
이를테면 배달의 민족이나 쇼핑몰 모바일 앱의 시스템 정기점검 시간을 제외하곤 항상 해당 서비스를 사용할 수 있는 까닭은 그 앱의 시스템을 수시로 점검하고 있는 서버 엔지니어의 노고가 있기 때문이기도 하다. 이런 앱을 개발하고 배포하는 개발자들이야 처음에 시연하고 지속적인 테스트를 몇 번 거친 후 유지보수 및 기능상 업데이트를 몇 번 하기는 하더라도, 무중단 서비스가 가능케 하는 책임은 앞서 말한 시스템 엔지니어들에게 떠넘겨진다.
그리고 그 시스템 엔지니어들이 '개인정보 보호법'의 몇 가지 조항에 따라 월 1회 이상 정기적으로 점검하고 검토해서 이상 징후 여부 등 그 결과를 관련 책임자에게 보고해야 하는 것은 해당 법규와 ISMS(Information Security Management System)라는 인증 기준 항목들에 해당하기 때문이기도 하다.
정보보안 사고가 간간히 터질 때, 이 준칙들을 잘 이행하고 있다는 것을 보이기 위해 보안사고 발생 시에 내세울 수 있는 것이 '감사증적(로그)'이다. 그 보안사고의 주범인 비인가(Unauthorized, 해당 사용자에게 접근이 허락되지 않은) 접근자(내부 직원일 수도 있고, 해커일 수도 있다.)의 시스템 접속 기록을 법정에서 제시할 수 없다면 검찰이나 판사가 부르는 금액대로 피해자들에게 배상해야 한다.
2. 로그의 분석 이유는?
경영자의 입장에서는 앞서 말했듯이 사고가 터졌을 때 해당 개인정보의 당사자들에게 합산된 피해 배상금을 물지 않기 위해서이며, KISA(한국 인터넷 진흥원)으로부터의 ISMS 인증을 받아서 만약 이것을 감사받지 않았을 경우의 과징금을 물지 않기 위해서이기도 한다. 그리고 현업의 엔지니어 입장에서는 로그에는: 1) 성능 2) 오류 3) 경고 4) 운영정보가 기록되어 있으므로 이것을 정기적으로 분석하여 침입여부를 파악하고 침입 시도 의심사례를 분석할 뿐만 아니라, 이를 형식 상 문서로 남겨서 보고해야 하기 때문이다. 하루 평균 수백만 명이 사용하는 배달의 민족이나 여타 쇼핑몰 앱의 방문자들의 로그온(logon) 성공, 실패 등의 기록을 모두 분석하기에는 특정 다수의 엔지니어들에게는 무리이므로 서버의 보안 관리자는 해당 접속 기록 중 특이한 패턴을 보이는 이력(History)들만 따로 수집해서 '어떤 의미 있는 정보－즉 데이터'를 추출하는 작업을 한다.
3. 로그를 왜 수집해야 하나(얻을 수 있는 정보란)?
1) 외부로부터의 침입 감지와 추적
2) 시스템 성능 관리와 시스템의 장애 원인 분석
3) 시스템 취약점 분석
4) 침해 사고 시 '근거 자료'로 활용
5) 각종 법규나 지침에서 관리 의무화(개인정보보호법의 안전성 확보 조치 기준)
① 개인정보보호법 조항
ㅇ 개인정보처리 시스템에서 접속한 기록은 '6개월 이상' 보관 관리
ㅇ 개인정보처리 시스템에서 접속 기록 등을 반기별(전/후반기별)로 1회 이상 점검(연 2회 이상 실시)
ㅇ 접속기록 위/변조 및 도난 및 분실되지 않도록 안전하게 보관(백업)
② ISMS 인증 기준
ㅇ 8.1.3 보안로그 기능
- 보안사고 발생 시 책임 추적(Accountability)을 위하여 감사증적(로그)을 확보하고, 보안로그의 비인가된 변조 및 삭제를 방지하여야 한다.
ㅇ 11.2.9 백업 관리
- 각종 로그(정보시스템 보안감사 로그, 이벤트 로그, 정보보호 시스템 이벤트 로그 등)에 대해 백업 관리를 수행하여야 한다.
ㅇ 11.6.2 로그기록 및 보존
- 로그기록 및 보존이 필요한 주요 정보시스템을 지정하고 기록하여야 할 로그 유형 및 보존기간을 정하여야 한다. (최소 6개월 이상 권고)
- 비인가자에 의한 로그기록 위변조 및 삭제 등을 방지하여야 한다.
ㅇ 11.6.3 접근 및 사용 모니터링
- 중요정보 및 정보시스템 사용자 접속기록을 주기적으로 검토(월 1회 이상 권고)하고, 이상 징후 여부 등 그 결과를 관련 책임자에게 보고하여야 한다.
4. Case-by-case(사례별)
어떤 사용자가 시스템에 로그온을 시도했는 데 계속 실패했다면, 이것은 1) 보안 공격의 징후(비인가 사용자의 접속－기밀성 침해)가 된다; 또한 로그온에 성공한 어떤 사용자가 권한이 허락되지 않는 자료에 접근하고자 계속 시도하였다면, 그래서 권한 오류가 발생했다면 이것은 2) 자료 유출의 징후(기밀성 침해)가 될 수 있다;
또한 정상적인 권한을 가진 사용자라 하더라도 새벽 시간에 중요 자료에 접근했다면 이것은 3) 불순한 의도(기밀성 침해)가 있다고 판단 가능하며 마지막으로 중요자료를 함부로 수정했다든지 혹은 삭제(내부 데이터 손상－무결성 침해)하였다면－이러한 이벤트에 대해서는 자세히 조사해볼 필요가 있다.
5. 시스템 운영체제별 로그 관리 프로세스
1) Windows
로그는 아래 화면과 같이 이벤트 뷰어(Event Viewer)의 윈도 로그 트리의 '보안' 항목에서 확인 가능하며, 해당 로그의 키워드가 '감사 실패'에 해당하는 이벤트 아이디(ID number), '4673'임을 알 수 있다.
'eventvwr'라고 치면 이벤트 뷰어가 실행한다.
키워드가 감사 실패인 로그 중 이벤트 아이디 '4625'를 필터링하여 해당 이벤트를 오른쪽 마우스 버튼으로 클릭하면 자세히 보기를 할 수 있다. 자세히 탭을 선택하고 '간단히 보기' 라디오 버튼을 클릭하면 아래와 같이 여러 필드(항목)들이 보이는데 이 중, IpAddress(IP 주소)가 만약 외부의 IP라면 추후 외부로부터 침입감지나 추적 또는 침해 사고 시 근거자료로 활용이 가능하다. 그러므로 이 데이터가 기록되는 로그를 윈도 운영체제일 경우에는 dumpel.exe이라는 마이크로소프트에서 제공하는 파일을 통해 정기적으로 백업을 하도록 해야 한다.
Event ID 4625(logon failed) 속성 자세기 보기윈도의 로컬 보안 정책을 설정할 수 있는 프로그램은 커맨드 라인에서 'secpol'이라는 명령어를 치면 아래 화면과 같이 실행된다.
'secpol'이라고 치면 로컬 보안 정책이 실행한다.
보안 설정 트리에서 로컬 정책 하위의 '감사정책'에서 로그관리와 관련된 보안 설정을 할 수 있다. 여기서 로그온 화면에서 해커가 무작위로 암호를 대입하여 사용자 인증을 시도하는 Brute Force(무차별 대입) 공격과 관련된 정책은 서로 이름이 비슷한 '계정 로그온 이벤트 감사'와 '로그온 이벤트 감사'이다. 이 두 정책의 차이는 전자와 같은 경우는 도메인(특정 네트워크 영역) 계정에 대한 로그온 시도의 로그인 반면, 후자는 로컬 계정에 대한 로그온 시도에 대한 로그라는 점이다(2014, 이상진).
위의 화면에서 보안 설정을 '성공' 또는 '실패'로 설정해놓을 경우에만 해당 이벤트가 발생 시에 로그로 남긴다는 뜻이다. '감사 안 함'은 위 설정의 예처럼 디렉터리 서비스 액세스 감사나 시스템 이벤트 감사 그리고 프로세스 추적 감사는 이벤트의 발생이 성공이든 실패든 로그로 남기지 않겠다는 뜻이다.
윈도는 리눅스와 달리 로그 데이터를 별도의 파일로 저장해놓지 않기 때문에 수동으로 로그를 백업해야 하는 데, 매일같이 일일이 하면 빠져먹을 수 있으므로 자동화해놓기 위해 배치 파일을 만들어서 돌려야 한다. 그래서 앞서 말한 Dumpel.exe라는 파일을 이용해서 이벤트 로그를 탭으로 구분(parsing)한 텍스트 파일로 덤프 뜰 수 있다. 이를 이용하거나 보통 공공기관이나 기업에서는 그 외의 로그 수집 및 분석 프로그램을 이용하여 여러 서버의 이벤트 로그를 통합하여 분석할 수 있다(2014, 이상진).
하지만 프로세스 관점에서 로그 관리와 관련하여 주의할 점은 서버 관리자는 정기적으로 로그를 분석해야 한다. 왜냐하면, 첫 번째는 공격의 징후를 판단하여 사전에 해당 도메인으로 접속하는 장비에 대한 접근을 차단하기 위해서이며 두 번째는 아무리 로그를 남겨도 이를 분석하여 체계적으로 관리하지 않으면 이러한 로그 데이터가 무의미하기 때문이다(2014, 이상진).
2) Unix(Linux)는 다음 섹션에서 다루겠다.
| 참조
이상진. (2014). 정보보안 가이드북. (초판, pp. 62-76). 서울: 프리렉.
