'6.25 해킹 사태'와 함께 2013년을 떠들썩하게 했던 '3.20 해킹 사태' 이후 APT 공격 징후 및 피해 내역, 발생 경위 파악을 위한 필수 정보로 Windows 운영체제 구동 과정에서 발생하는 거의 모든 정보를 담고 있는 Event Log가 주목을 받기 시작했다.
 |
| 기껏 확보한 좀비PC를 죄다 날려버린 3.20 |
그러나 광범위한 분석 범위(다수 PC에서 발생하는 다량의 로그)의 어려움으로 인해 Event Log 역시 사전예방 보다는 주로 사고 발생 후, 즉 사후대응 측면의 접근에 머무르고 있는 게 현실이다. 이런 현실을 극복해보자.
일단 Event Log는 텍스트가 아닌 바이너리 형식으로 저장되기 때문에 시스템 내장 분석 도구인 '관리도구>이벤트 뷰어(evtvwr.msc)'를 통해서만 조회가 가능하다. 참고로 물리적인 로그 파일 저장 경로는 'C:\Windows\System32\winevt\Logs'.
 |
| 이벤트 로그 조회 |
이벤트 뷰어를 이용하면 로그 조회가 가능하나 단일 로그 단위의 분석만 가능한, 대량 로그 분석에는 적합하지 않은 환경임을 알 수 있다. 이런 환경에서 관리 대상 PC가 늘어난다면 대량 로그 분석의 가능성은 더 낮아질 수밖에 없다. 어쩐다?
LogParser가 있다
MS에서 배포하는 LogParser는 텍스트 및 바이너리 로그를 SQL을 이용한 데이터베이스 환경에서 분석할 수 있게 해주며 Event Log를 포함, 20여 개 이상의 다양한 로그 형식을 지원한다. LogParser를 이용해서 대량 로그 분석의 난제를 해결해보자.
사용 방법은 다음과 같다. '-i(input)' 옵션을 이용해서 분석 대상 로그의 타입을 지정하며, SQL을 작성해서 Event Log를 조회하는 방식.
그런데 CLI 환경 때문에 솔직히 이벤트 뷰어보다 더 편한지 잘 모르겠다. 한마디로 불편하다. 이런 불편함을 알았는지 MS는 LogParser의 CLI 환경을 GUI로 바꿔주는, 'LogParser Studio'라는 도구도 제공해준다.
LogParser Studio를 이용하면 매우 직관적인 데이터 조회가 가능해짐은 물론, SQL 쿼리문 생성·관리의 효율성과 함께 데이터 가공 측면의 편의·생산성까지 높일 수 있다.
LogParser와 LogParser Studio를 설치하면 Event Log를 분석할 준비는 끝난다. 본격적인 분석 작업에 들어가기 전에, SQL을 이용한 Event Log 분석을 위해 Event Log의 필드 구성부터 살펴보자.
사용 방법은 다음과 같다. '-i(input)' 옵션을 이용해서 분석 대상 로그의 타입을 지정하며, SQL을 작성해서 Event Log를 조회하는 방식.
그런데 CLI 환경 때문에 솔직히 이벤트 뷰어보다 더 편한지 잘 모르겠다. 한마디로 불편하다. 이런 불편함을 알았는지 MS는 LogParser의 CLI 환경을 GUI로 바꿔주는, 'LogParser Studio'라는 도구도 제공해준다.
LogParser Studio를 이용하면 매우 직관적인 데이터 조회가 가능해짐은 물론, SQL 쿼리문 생성·관리의 효율성과 함께 데이터 가공 측면의 편의·생산성까지 높일 수 있다.
LogParser와 LogParser Studio를 설치하면 Event Log를 분석할 준비는 끝난다. 본격적인 분석 작업에 들어가기 전에, SQL을 이용한 Event Log 분석을 위해 Event Log의 필드 구성부터 살펴보자.
Event Log는 총 13개의 필드로 이루어져 있으며, 로그 분류의 최소 단위는 EventID, 최대 단위는 EventType 필드임을 알 수 있다. 참고로 EventCategory나 Type 컬럼은 로그 분류의 명확한 기준이 되지 못한다. 로그 종류가 너무 다양해서 MS도 포기?
이제 지금까지 확인한 내용을 바탕으로 본격적인 분석을 해보자. LogParser Studio를 이용해서 2015년 11월에 발생한 security Event Log의 일별 발생 추이를 조회해봤다.
사용된 SQL 쿼리문은 다음과 같다.
① select to_string(timewritten, 'yyyy-MM-dd'), count(*)
-> to_string 함수를 이용, timewritten 필드의 '날짜+시간' 정보 중, '날짜' 정보만 추출
-> count 함수를 이용, 날짜별 로그 발생 개수 집계
② from security
③ where to_string(timewritten, 'yyyy-MM') = '2015-11'
④ group by to_string(timewritten, 'yyyy-MM-dd')
조회 결과를 통해 얼마든지 로그 발생 추이 확인이 가능하지만, 차트로 표현하면 더 많은 정보를 더 빠르게 확인할 수 있다. LogParser Studio가 제공하는 깜찍한 차트 생성 기능을 이용해보자.
다음은 단축키(F6)를 이용해서 데이터 조회 결과를 차트로 변환한 결과. 참고로 차트 생성 시 결과 필드는 '항목:값' 구성, 즉 '값'이 반드시 우측에 위치해야 하며, 차트로 표현해야 하는 값을 가진 필드가 둘 이상일 때는 차트 생성이 되지 않는다. 2차원의 단순 차트 생성만 가능하다는 뜻.
일별 발생 추이 확인 결과 특정 날짜에 대량 로그 발생, 즉 이상징후가 확인됐다. 해당 날짜에 발생한 로그를 더 세부적으로 확인해보자. 사용된 SQL 쿼리문은 다음과 같다.
① select to_string(timewritten, 'hh:mm:ss'), count(*)
-> to_string 함수를 이용, timewritten 필드의 '날짜+시간' 정보 중, '시간' 정보만 추출
-> count 함수를 이용, 시간대/eventid별 발생 개수 집계
② from security
③ where to_string(timewritten, 'yyyy-MM-dd') = '2015-11-14'
④ group by to_string(timewritten, 'hh:mm:ss')
다음은 해당 SQL 쿼리문을 실행한 결과.
조회 결과를 차트로 변환했더니 로그가 대량 발생한 특정 시간대가 한눈에 들어온다.
해당 시간대에 발생한 로그의 발생 분포를 확인해보자. 사용된 SQL 쿼리문은 다음과 같다.
① select eventid, count(*)
② from security
③ where to_string(timewritten, 'yyyy-MM-dd') = '2015-11-14'
and to_string(timewritten, 'hh:mm:ss') = '17:04:23'
④ group by eventid
확인 결과 해당 시간대에 발생한 eventid는 다음처럼 '4907' 하나뿐이다.
이제 eventid 4907의 세부 내역을 확인하면 된다.
① select message
② from security
③ where to_string(timewritten, 'yyyy-MM-dd') = '2015-11-14'
and to_string(timewritten, 'hh:mm:ss') = '17:04:23'
and eventid = 4907
해당 로그는 특정 개체의 감사 설정이 변경됐음을 알리는, (개발자에게나 의미 있어 보이는) 디버깅 수준의 로그로 보인다. 그런데 동일 EventID임에도 세부 내용은 다를 수 있기 때문에, 전체 내용을 확인하기 위해서는 70개의 로그를 하나씩 확인해야 하는, 일괄적인 분석이 어려운 상황임을 알 수 있다. 어떻게 하면 빠른 분석이 가능할까?
일괄 분석을 위해서는 결국 로그의 핵심 패턴을 추출해야 한다. 해당 로그의 핵심 패턴은 설정이 변경된 특정 개체, 특정 프로세스에 해당하는 문자열이다. 어떻게 하면 해당 문자열만을 추출할 수 있을까?
Message 필드는 다음처럼 '보안 ID: S-1-5-18' 형식, 즉 '제목: 값' 형식으로 정보를 표시하는데, Strings 필드는 동일 정보 중 '값'만을 '|' 기호로 구분해서 표시한다.
이럴 때 요긴하게 사용할 수 있는 'extract_token'이라는 LogParser 함수가 있다. '구분 기호'를 기준으로 명시한 순서에 해당하는 데이터를 추출하는 함수이며, 순서는 0부터 시작. (리눅스 'cut' 명령어와 유사)
- extract_token(컬럼명,순서 번호,'구분 기호')
'extract_token' 함수를 사용한 쿼리문은 다음과 같다.
① select extract_token(strings,11,'|'), count(*)
② from security
③ where to_string(timewritten, 'yyyy-MM-dd') = '2015-11-14'
and to_string(timewritten, 'hh:mm:ss') = '17:04:23'
and eventid = 4907
④ group by extract_token(strings,11,'|')
Event Log 이상 발생 추이 원인은 'poqexec.exe(기본 작업 큐 실행자?)' 파일에 대한 잦은 감사 설정 변경이었음이 확인됐다. 변경 원인 등 더 상세한 분석은 system 및 application 등 다른 Event Log와의 연관 분석이 필요해 보이지만, 보안 측면에서 주목할만한 징후는 아닌 듯하다.
사전예방 차원의 Event Log 이상징후 분석 사례를 살펴봤다. 단일 PC의 일부에 불과한 로그 분석 과정임에도 적지 않은 시간 투자가 필요했으며, 그럼에도 보안에 직접 도움이 될만한 정보는 얻지 못했다. 그렇다면 지금껏 했던 작업은 아까운 시간만 낭비한 것일까?
그렇지 않다
이런 분석 작업이 지속된다면 시간대/업무별 발생 추이 및 세부 발생 분포 등 조직의 로그 발생 특성이 파악될 것이고, 정상 상태에 대한 수치화가 가능해질 것이며, 결과적으로 비정상의 구분이 가능해질 것이다.
어제도 얘기했지만 현 정보보안 분야의 가장 심각한 문제는 분석해야 할 로그의 양이 너무 많다는 것이며, 그 결과 대부분의 로그는 사전에 분석되지 못하고, 보안사고가 발생한 후에야 겨우 분석이 이루어지고 있다.
이런 상황에 대한 해법은 결국 IDS 등 전통적 보안장비를 이용하는 알려진 공격 대응과 함께, 시스템 로그 정보의 각 요소들에 대한 발생 추이, 분포 등을 지속 분석해서 정상 상태를 정의하고, 그 상태를 벗어나는 비정상을 추적할 수 있는 이상징후 분석 체계를 세우는 것뿐.
알려진 공격 대응과 이상징후 분석 병행이 가능한 체계를 구축하지 않는다면 보안사고가 발생해야만, '피해자'라는 힌트를 얻어야만 대응이 가능해지는 상황에서 벗어날 수 없으며, '소 잃고 외양간 고치는' 상황의 무한 반복을 피할 수 없게 된다. 누구나 다 아는, 쌀로 밥 짓는 얘기.
당연한 얘긴데 왜 어려울까? 일한 티가 잘 안 난다. 세상은 생각보다 아름다워서 비정상보다는 정상이 더 많기 때문. 비정상을 못찾으면 일 안 하고 놀고 있다고 생각하는 사람들도 많고(..)
그냥 훈련, 비상 근무 등으로 바쁜 모습 보여주는 게 훨씬 쉽고 일한 티도 잘 난다. 사고 적당히 터져주면 더 좋고.
사족
기다리면 사람만큼 똑똑한 컴퓨터 나오겠지? 그때가 되면 지속 가능한 이상징후 분석 체계가 수립될까?
관련 글
댓글 없음:
댓글 쓰기