IOC(Indicator Of Compromise, 침해지표)

 

 Mandiant社에서 OpenIOC(Indicator Of Compromise) 프로젝트를 2011년에 시작한 것으로 필자는 알고 있는 반면, 국내에서는 아직 IOC에 대한 글이나 IOC 파일 등이 존재하지 않는 것 같아 IOC에 대해 알아보고 어떤면에서 사용하면 좋은지 생각해보고자 이렇게 글을 쓰게 되었다.

1. IOC란?

 IOC(Indicator Of Compromise)는 한문장으로 표현하면 다음과 같다.

"여러 침해사고의 흔적들을 일정한 포맷으로 정리 해 놓은 문서 또는 파일"

 사실 IOC의 개념은 Mandiant社가 처음으로 제안한 것은 아니다. 이런 지침등의 관련 표준안으로는 대표적으로 CSIRTs(Computer Security Incident Response Teams)의 IODEF(The Incident Object Description Exchange Format, RFC 5070)이 있다. 문서를 보면 여러개의 그룹별로 엔트리를 나누어 해당 포맷을 작성하는 사람이나 보는 사람이 이해하기 편하도록 구성되어 있다. 이와 같은 개념을 바탕으로 확장성을 겸비한 OpenIOC가 탄생했다고 볼 수 있다.

 그렇다면 IOC, 즉 침해지표는 왜, 어디서, 어떻게 사용을 할까? 침해지표의 이름 그대로 사용처는 대부분 침해사고 부분이다. 보통 침해사고는 악성코드에 의한 침해사고를 생각하기 쉬운데 OpenIOC의 프로젝트 목적을 보면 악성코드 침해사고는 물론 해커에 의한 침해사고에도 IOC가 적용되게끔 설계했다고 나와 있다. 그리고 IOC를 이용 해 침해사고 PC에서 흔적을 찾아내는 것 뿐만이 아닌 해당 침해지표를 이용 해 여러 방화벽이나 탐지시스템, 차단시스템의 룰을 정의할 수 있도록 포맷자체를 간단히 OR, AND와 Item을 직관적으로 표현 해 두었다. IOC는 XML을 이용하여 작성 할 수도 있고, Mandiant社에서 제공하는 IOC Editor를 이용 해 작성 할 수도 있다. 

그렇다면 IOC 프로세스는 어떠할까? 다음은 IOC의 LifeCycle이다.

[그림 1 - IOC LifeCycle]

IOC의 LifeCycle에 진입을 하게 되면 먼저 IOC를 생성하게 된다.(IOC Creation) 생성할 때의 내용은 기본적인 침해사고의 흔적들인데 흔적들로는 대표적으로 파일의 해시값, 네트워크 트래픽 또는 통신 서버의 주소(Domain Or IP), 레지스트리 키 또는 값, 프로세스 명 등을 예로 들 수 있다.

 다음으로 생성한 IOC를 여러 기관들에게 배포하게 된다.(Deploy IOCs) 배포 했을 때 IOC는 독립적으로 침해사고의 지표가 될 수도 있지만, 기관의 성격에 따라 IOC를 근거로 침입관련 시스템의 룰로 재생성 될 수 있다.

 배포가 되었다고 끝이 나는 것이 아니다. 현대의 침해사고는 굉장히 많은 변형을 생산해 낸다. 그러므로 추가적인 침해가 의심되는 시스템을 분석 해야 한다.(Identify Suspect Systems)

 추가적으로 분석해야 할 시스템이 선정되면 침해사고와 관련된 흔적들을 수집한다.(Preserve/Collect Evidence) 마지막으로, 수집 된 증거들을 분석한다.(Analyze Data) 그리고 분석한 결과를 IOC 포맷으로 작성한다.(IOC Creation)

IOC는 한번으로 끝나는 것이 아니라 계속해서 증거수집과 분석을 통해 IOC 자체를 확장시켜야 한다. 그러므로 위와 같은 LifeCycle이 절대적으로 필요하며, 멈추어서는 안된다.

2. IOC 작성 방법

 앞에서 잠깐 언급을 했었지만, IOC의 포맷은 굉장히 직관적이어서 누구나 손 쉽게 작성이 가능하다.

[그림 2 - IOC Editor]

[그림 2]는 IOC 작성할 때 사용하는 IOC Editor로 새로운 문서를 생성하게 되면 위와 같은 모습이다. 사용자가 작성해야 할 부분을 살펴보면 다음과 같다.

 - Name : IOC의 제목

 - Author : IOC의 작성자 이름

 - GUID : IOC 파일의 고유 번호

 - Created, Modified : 생성날짜, 수정날짜

 - Desciption : IOC 설명

위 항목들 아래에는 실제 IOC 내용이 들어가는 부분으로 OR, AND 로직을 이용 해 IOC 내용을 구성하게 된다.

 2.1. 로직 

 IOC 로직에는 OR, AND 단 두가지만 존재하는데 해당 로직은 프로그래밍언어를 다뤄본 사람이라면 충분히 이해하고 다룰 수 있는 로직이다. 예를 들어 다음과 같은 IOC 내용이 있다고 가정하자.

[그림 3 - OR 예시]

위 내용은 다음의 내용과 동일한 의미를 지닌다.

(File Name contains MaJ3stY) || (File Owner contains Administator)

그렇다면 OR와 AND를 같이 사용하면 어떨까? 다음 예시를 한번 살펴보자.

[그림 4 - 로직 혼합(OR, AND) 예시]

위 내용은 다음의 내용과 동일한 의미를 지닌다.

((File Name contains MaJ3stY) || (File Owner contains Administator)) || ((Disk Name contains Test) && (Network DNS contains MaJ3stY.site.com) && ((Process PID is 1899) || (Email Received From IP contains 1.1.1.1)))

 혼합되어 있는 것은 조금 복잡해 보이지만, 각 로직속에 들어 있는 모든 아이템들은 해당 로직으로 연결된다는 것만 이해하면 된다. OR 로직안에 AND 로직이 들어 있더라도 AND 로직 전체는 OR 로직으로 연결된다는 의미이다. 참고로 같은 로직을 연속적으로 사용하면 안된다. 

IOC 작성 시 사용되는 아이템의 모든 목록은 다음을 참고하거나 IOC Editor를 참고하기 바란다.

Full Item List : http://openioc.org/terms/Current.iocterms

다음은 예시로 작성 해 본 3.20 사이버테러 때 발견된 AmAgent.exe의 IOC이다.

[그림 5 - AmAgent.exe IOC]

3. IOC 사용

 IOC 파일은 IOC Finder라는 툴에서 사용하게 된다. 해당 시스템에서 해당 IOC에 기록되어 있는 흔적이 있는지 살펴보기 위해 IOC Finder 툴로 침해 시스템의 흔적을 수집하고 IOC와 대조하게 된다. 다음 글에 사용법과 예시가 좋은게 있으니 참고하기 바란다.

Red Oct IOC : http://www.ahnlab.co.kr/company/site/pr/comSecuNews/comSecuNewsView.do?seq=20776

4. 우리가 생각해야 할 것

 현재 우리나라에서는 공식적으로 IOC를 이용한 사례는 아직까지 없다. IOC는 사용 방법과 주체에 따라 굉장히 도움이 많이 되는 침해사고 대응방법 중 하나이다. 하지만 외국과는 다르게 우리나라에서는 아직 IOC를 알고 있는 사람도 드물고 IOC를 주도적으로 하는 기관 또한 존재하지 않는다. 예를 들어 3.20 사이버 테러가 발생한 직후 IOC를 이용한 정보교류가 있었다면 이번에 했던 침해사고 대응처럼 서로 이야기가 맞지 않고 우왕좌왕하지 않았을 것이라 개인적으로 생각한다. 현재 보안업계에서는 정부 주도로 컨트롤 타워가 필요하다고 이야기하는데 컨트롤 타워가 만약에 생긴다면 컨트롤 타워 내부에 IOC를 관리하는 부서 또는 기관이 생겨야 한다고 본다.

 많은 변종이 발생하는 악성코드 침해사고에 있어서 컨트롤 타워의 역할은 굉장히 중요하다. 기초가 되는 IOC를 배포하면 각 기관들은 자신들이 분석하는 변종에 관한 흔적들을 배포 받은 IOC에 업데이트 하여 다시 컨트롤 타워로 보내주면 추후 비슷하거나 동일한 악성코드에 의해 발생하는 침해사고에 있어서는 굉장히 발빠르게 대응 할 수 있게 되기 때문이다. 여기서 당연히 컨트롤 타워가 보유하고 있는 IOC는 공개되어 있어야 한다.

 하루 빨리 국내에서도 IOC를 활용한 침해사고 대응이 활발 해 졌으면 하는 작은 바람을 내비추며 이 글을 마무리 한다.