(주)인젠 주임연구원 김성도

RFC 3227

Guidelines for Evidence Collection and Archiving

증거물수집과 증거보관에 관한 지침

Abstract

보안사고(Security incident)란 RFC2828(Internet Security Glossary)에 정의되어 있는데로 시스템의 보안정책이 위반되거나 깨어진 보안과 관련된 시스템관련 사고(event)를 말한다. 이 문서의 목적은 시스템 관리자(administrator)에게 이러한 시스템 보안사고에 관한 증거물수집과 파일보관에 관한 지침을 제공하기 위한 것이다.

증거수집이 정확하게 이루어진다면 공격자를 체포하는데 유용할 것이고 법정에서 증거로 받아들여지는 것도 용이해질 것이다.

Table of Contents

1. 소개

        1.1 문서에서 사용되는 용어의 관례

2. 증거수집과정의 운영지침

        2.1 휘발성의 순서

        2.2 피해야 할 일들

        2.3 프라이버시의 고려

        2.4 법률적인 고려

3. 수집절차

        3.1 투명성

        3.2 수집의 단계

4. 파일보관절차

        4.1 Chain of Custody

        4.2 파일보관

5. 필요한 툴(Tools)

6. 참고자료(References)

1. 소개(Introduction)

보안사고(Security incident)란 RFC2828(Internet Security Glossary)에 정의되어 있는대로 시스템의 보안정책이 위반되거나 깨어진 보안과 관련된 시스템관련 사고(event)를 말한다. 이 문서의 목적은 시스템 관리자(administrator)에게 이러한 시스템 보안사고에 관한 증거물수집과 파일보관에 관한 지침을 제공하기 위한 것이다. 모든 시스템관리자가 엄격하게 이 지침을 따라야 한다는 것은 아니다. 그보다는 침입사고와 관련된 정보를 보호하고 수집하는 일을 맡았을 때 그것에 대한 지침을 제공하고자 하자는 것이다.

시스템관리자의 입장에서 증거 수집은 많은 노력을 필요로 하는 작업이다. OS의 재설치하는 시간이나 시스템을 원상태로 복구시켜서 재가동시키는데 걸리는 시간이 최근에는 매우 단축되었다. 하지만 증거물을 수집하고 보관하는 기술은 진전된 내용이 없다. 더군다나 디스크와 메모리의 용량이 늘어나고 스텔스와 cover-your-tracks 전략을 공격자가 많이 사용하기 때문에 문제는 더욱 악화된다.

증거수집이 정확하게 이루어진다면 공격자를 체포하는데 유용할 것이고 법정에서 증거로 받아들여지는 것도 용이해질 것이다.

이 지침서는 독자 자신의 환경(Jurisdiction)에 맞는 증거수집절차에 관한 지침을 만들 때 모범이 되는 참고자료로 사용해야 한다. 또한 지침서를 만든 이후에는 반드시 법집행기관(law enforcement)에 문의하여 올바른 절차로 이루어졌는지 확인해야 한다.

1.1 문서에서 사용되는 용어의 관례

REQUIRED, MUST, MUST NOT, SHOULD, SHOULD NOT, MAY...

2. 증거수집과정의 운영지침

- 지역의 보안 정책에 가입하고 사고처리나 법집행을 하는 인원을 고용하라.

- 가능한 모든 자료를 수집하라.(Picture of the system)

- 날짜나 시간도 포함하여 자세히 기록하라. 가능하다면 자동으로 기록할 수 있는 장치를 사용한다.(예를 들어 Unix에서 script 프로그램을 사용한다. 이 프로그램의 출력이 동일한 디스크(증거물 디스크)에 생기지 않도록 조심한다.) 기록이나 인쇄물에 대해서는 날짜를 기입하고 서명한다.

- 시스템시간과 UTC와의 차이를 기록한다. Timestamp를 남길 때마다 UTC를 사용했는지 로컬타임을 사용했는지 표시한다.

- 당신이 언제 어떤 행동을 취했는지 증명(몇 년 후가 될 것이다.)할 수 있도록 준비해라. 자세한 기록이 중요하다.

- 수집과정에서 데이터의 변형을 최소화 한다. 이것은 파일의 내용뿐 아니라 파일이나 디렉토리의 Access Time도 포함한다.

- Remove external avenues for change.

-  수집(collection)을 할 것인가 분석(analysis)을 할 것인가 선택해야 한다면 먼저 수집을 하라.

- 얘기하면 입만 아프지만 절차를 계획할 때는 실행 가능한 것 이어야 한다. 사고대응 정책이나 절차는 특히 결정적인 순간에 실행가능한지 시험되어야 한다. 가능하다면 절차들은 정확성과 속도문제를 고려한다면 자동화하는 것이 좋다. 조직적으로 질서있게 움직여라.

- 각각의 장치에 대해 수집절차 지침서에 입각한 조직적인 접근이 필요하다. 속도가 중요하기 때문에 많은 수의 장치에 대한 수집이 필요할 경우 팀에게 분배하여 병렬로 증거수집을 하는 것이 좋다. 하지만 하나의 시스템에 대해서는 한단계식 차례로 절차를 수행해야 한다.

- 휘발성이 있는 것을 먼저 진행하고 그렇지 않은 것을 나중에 진행한다.(see the Order

         of Volatility below)

- 시스템 저장장치에 대해 bit 레벨의 복사를 수행해야 한다. 포렌식 분석을 할 때 파일의 access time 정보가 변경되기 쉽기 때문에 분석을 하기 위해서는 증거복사물에 대한 bit 레벨 복사를 해야 한다. 증거복사물을 가지고 분석을 하는 일이 없도록 한다.

2.1 휘발성의 순서 (Order of Volatility)

증거 수집을 할 때는 휘발성이 있는 것을 먼저 진행하고 그렇지 않은 것을 나중에 진행한다. 다음은 보통의 시스템에 대한 휘발성 순서의 예이다.

      -  registers, cache

      -  routing table, arp cache, process table, kernel statistics,

         memory

      -  temporary file systems

      -  disk

      -  remote logging and monitoring data that is relevant to the

         system in question

      -  physical configuration, network topology

      -  archival media

2.2 피해야 할 일들 (Things to avoid)

부주의한 행동으로 인해 증거물을 파괴하는 경우가 많다.

- 증거수집이 끝날 때 까지 시스템을 끄지 말아야 한다. 많은 양의 증거물이 파괴될 것이고 공격자가 증거물을 파괴하기 위한 시작, 종료 스크립트를 작성했을 수도 있다.

- 시스템상에 있는 프로그램을 믿지 말아라. 증거물 수집을 위해 보호된 장치(e.g., CD)에 따로 마련한 프로그램을 사용하라.(see below)

- 모든 파일의 access time을 변경시키는 프로그램을 사용하지 말아라(e.g., tar or xcopy)

- When removing external avenues for change, note that simply

         disconnecting or filtering from the network may trigger

         "deadman switches" that detect when they're off the net and

         wipe evidence.

2.3 프라이버시의 고려

- 프라이버시관련 법률이나 회사의 지침에 위배되지 않도록 주의하라. 특별히 증거물과 함께 수집된 어떠한 정보도 그 정보에 대한 접근 권한이 없는 다른 사람에게 공개되지 않도록 주의하라. 이러한 정보에는 로그파일(사용자의 행동 패턴을 보일 수 있다.)과 개인의 데이터파일이 포함된다.

- 정당성 없이 사람들의 프라이버시를 침해해서는 안된다. 충분한 이유가 없는 이상 특별히 접근할 필요 없는 영역에 저장된 정보들에 대해 수집해서는 안된다.(개인 저장장치)

- 사건 현장에서 행하는 증거수집 행동들이 당신 회사가 수립한 절차에 지원을 받는 것인지(위배되지 않는 것인지) 확실히 한다.

2.4 법률적인 고려

컴퓨터 증거물들은...

- 증거로서 인정될 수 있어야 한다 : 법정에 제출되기 전에 특정 법률에 부합되도록 해야 한다.

- 인증된 것이어야 한다 : 증거물과 사건과의 확실한 연관이 가능해야 한다.

- 완벽해야 한다 : 특별한 관점에서가 아닌 전체를 증명할 수 있어야 한다.(It must tell the whole story and not just a particular perspective)

- 신뢰할 수 있어야 한다 : 증거물의 수집과 처리과정에서 증거물의 확실성(authenticity)과 진실성(veracity)을 의심할 수 있는 여지가 없도록 해야 한다.

- 믿을 수 있어야 한다 : 법정에서 쉽게 믿을 수 있어야하고 이해할 수 있어야 한다.

3 수집 절차

수집절차는 가능한 최대한 자세히 세분해야 한다. 사고처리 과정에서 모호한 일이 일어나지 않도록 해야 하고 수집과정에서 의사결정(decision-making)을 해야 하는 상황을 최소화해야 한다.

3.1 투명성(Transparency)

증거 수집을 위해 사용한 방법들은 투명해야하고 재현 가능(Reproducible)해야 한다. 사용했던 방법들을 정확하기 재현할 수 있어야 하고 이러한 방법들은 독립적인 전문가에게 테스트 되어야 한다.

3.2 수집 절차

- 증거물이 어디에 있는가? 어떠한 시스템이 사건에 연루되어 있는지 기록하고 어떤 시스템으로부터 증거물을 수집할 것인지도 기록한다.

- 무엇이 연관되어 있는 것이고 증거물로서 인정될 수 있는지 확실히 하고 확실치 않을 때는 가능한 많이(충분하지 못한 것 보다 낫다) 수집한다.

- 각각의 시스템에 대해 적절한 휘발성 순서로 증거물을 얻는다.

- 변경을 초래할 수 있는 외부접근 수단을 제거한다.

- Section 5에 기술되어 있는 툴들을 이용하여 휘발성 순서대로 증거를 수집한다.

- 시스템 클럭(clock)의 편차(drift)를 기록한다.

- Question what else may be evidence as you work through the

   collection steps.

- 각각의 절차를 문서화한다.

- 관련된 사람들에 대한 정보도 잊어서는 안된다. 누가 그곳에 있었는지 무엇을 하고 있었는지 어떻게 반응했는지 기록해야 한다.

가능하다면 수집된 증거물에 대해 체크섬을 계산하거나 암호학적인 서명을 하는 것이 좋다. 그렇게 하면 증거물 보존에 대한 증명을 쉽게 할 수 있다. 물론 이후 증거물을 변형해서는 안된다.

4 파일보관 절차

증거물들은 엄격하게 보호되어야 한다. 또한 Chain of Custody가 명확하게 문서화되어야 한다.

4.1 Chain of Custody

증거물이 어떻게 발견되었고 어떻게 다루어졌는지를 비롯한 증거물에 관련된 모든 일들을 명확하게 기술할 수 있어야 한다.

아래의 내용들이 문서화 되어야 한다.

      -  Where, when, and by whom was the evidence discovered and collected.

어디서, 언제, 누가 증거물을 발견하였고 수집하였는가?

      -  Where, when and by whom was the evidence handled or examined.

어디서, 언제, 누가 증거물을 다루었고 검사하였는가?

      -  Who had custody of the evidence, during what period.  How was it stored.

누가 어느기간에 증거물을 관리했는가, 어떻게 저장되었는가?

      -  When the evidence changed custody, when and how did the transfer occur (include shipping numbers, etc.).

언제 관리에 대한 변경이 일어났고, 언제 어떻게 이송되었는가?

4.2 어디서 어떻게 보관할 것인가(Where and how to Archive)

가능하다면 보통 사용되는 매체(not obscure storage)에 보관해야 한다. 증거물에 대한 접근은 엄격히 통제되어야 하고 명확하게 문서화되어야 한다. 인가되지 않은 접근을 발견할 수 있어야 한다.

5 필요한 툴들

read-only 매체(e.g., a CD)에 저장된 증거 수집과 포렌식과 관련된 프로그램들을 가지고 있어야 한다. 각각의 운영체제(OS)에 해당하는 툴들을 사전에 준비해야 한다.

툴들에는 다음과 같은 것들이 있다.

- 프로세스를 검사하기 위한 프로그램(e.g., ps)

- 시스템 상태(state)를 검사하기 위한 프로그램(e.g., showrev, ifconfig, netstat, arp)

- bit-to-bit 복사를 할 수 있는 프로그램(e.g., dd, SafeBack)

- 체크섬이나 서명(Signature)을 생성할 수 있는 프로그램 (e.g., sha1sum, checksum-enabled dd, SafeBack, pgp)

- Core image를 생성할 수 있는 프로그램(e.g., gcore, gdb)

- 증거수집을 자동화할 수 있는 스크립트(e.g., Ther Coroner's Toolkit)

사용하는 모든 프로그램은 정적으로 링크(statically linked)되어야 한다.(read-only 매체에 저장된 파일 이외에 다른 라이브러리나 파일들이 필요없어야 한다)

근래의 rootkit들은 LKM을 통해 설치되기 때문에 툴들을 이용하여 정확한 시스템의 출력을 얻을 수 없을지도 모른다는 것을 고려해야 한다.

또한 사용하는 툴들에 대해 확실성(authenticity)과 진정성(reliability)을 증명할 수 있어야 g한다.

6 References

      Farmer, D., and W Venema, "Computer Forensics Analysis

               Class Handouts",http://www.fish.com/forensics/

      Bradner, S., "Key words for use in RFCs to Indicate

               Requirement Levels", BCP 14,RFC 2119

, March 1997.

      Fraser, B., "Site Security Handbook", FYI 8,RFC 2196

,

               September 1997.

      Brownlee, N. and  E. Guttman, "Expectations for Computer

               Security Incident Response", FYI 8,RFC 2350

, June 1998.

      Shirey, R., "Internet Security Glossary", FYI 36, RFC

               2828, May 2000.

7 Acknowledgements

   We gratefully acknowledge the constructive comments received from

   Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox,

   Andrew Rees, Steve Romig and Floyd Short.

8 Security Considerations

   This entire document discuses security issues.

9 Authors' Addresses

   Dominique Brezinski

   In-Q-Tel

   1000 Wilson Blvd., Ste. 2900

   Arlington, VA 22209

   USA

   EMail:dbrezinski@In-Q-Tel.org

   Tom Killalea

   Lisi/n na Bro/n

   Be/al A/tha na Muice

   Co. Mhaigh Eo

   IRELAND

   Phone: +1 206 266-2196

   EMail:tomk@neart.org

10.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to

   others, and derivative works that comment on or otherwise explain it

   or assist in its implementation may be prepared, copied, published

   and distributed, in whole or in part, without restriction of any

   kind, provided that the above copyright notice and this paragraph are

   included on all such copies and derivative works.  However, this

   document itself may not be modified in any way, such as by removing

   the copyright notice or references to the Internet Society or other

   Internet organizations, except as needed for the purpose of

   developing Internet standards in which case the procedures for

   copyrights defined in the Internet Standards process must be

   followed, or as required to translate it into languages other than

   English.

   The limited permissions granted above are perpetual and will not be

   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the

   Internet Society.