요약
이 장은 어떤 시간순서가 왜 성립하지 않으며, 시계 오차를 반영한 대체 연표를 어떻게 세우는지를 묻는다. 성립하지 않는 순서의 조건과 시계 오차가 바꾸는 사건 순서, 시간대와 비동기 시각의 정규화를 차례로 살핀 뒤, 오차를 반영한 대체 연표를 구성한다. 대체 연표의 사실성 한계를 검토하며, 출처 표시와 신뢰 범위의 서술은 뒷장에서, 새 자료 발견 뒤의 수정 절차는 마지막 장에서 다룬다.
12.1성립하지 않는 순서의 조건
성립하지 않는 순서를 표시하면, 그 다음에는 무엇이 그 순서를 무너뜨렸는지 조건을 가려야 한다. 자료에는 시각 자체의 오차와, 수집·조회 방식이 시각을 바꾸는 경로가 함께 놓여 있다. 이 둘은 혼동하기 쉽지만 구분해서 읽어야 사건의 실체나 책임자를 함부로 추정하는 일을 막는다.
먼저 시각 자체가 정확하지 않은 경우다. 분석가가 사건의 정확한 시간순서를 세워야 한다면 파일의 시각을 보존해야 한다는 전제 아래, 미국 상무부 국립표준기술연구소(NIST), Guide to Integrating Forensic Techniques into Incident Response (NIST SP 800-86), 2006-08, 4.2.3·4.4절, 인쇄면 4-9·4-15쪽 (PDF 41·47쪽)은 파일 시각이 부정확할 수 있는 이유를 열거한다. 그중 첫 번째가 컴퓨터의 시계가 올바른 시간을 갖고 있지 않은 경우이며, 같은 자료는 "The computer’s clock does not have the correct time. For example, the clock may not have been synchronized regularly with an authoritative time source"라고 적는다. 기록된 시각이 권위 있는 시각 원천과 자주 맞춰지지 않았다면, 그 시각은 사건의 실제 선후와 어긋날 수 있다. 두 번째는 기록의 세밀함이 기대에 못 미치는 경우로, "The time may not be recorded with the expected level of detail, such omitting the seconds or minutes"라고 한다. 초나 분이 빠진 기록만으로는 같은 시각에 겹친 사건의 순서를 가릴 수 없다. 세 번째는 외부 개입으로, "An attacker may have altered the recorded file times"라는 사정도 남아 있다. 이 세 가지는 각각 원인이 다르므로 하나로 묶어 해석해서는 안 된다.
다음으로 수집 방식이 시각을 바꾸는 경우다. 미국 상무부 국립표준기술연구소(NIST), Guide to Integrating Forensic Techniques into Incident Response (NIST SP 800-86), 2006-08, 4.2.3·4.4절, 인쇄면 4-9·4-15쪽 (PDF 41·47쪽)은 "not all methods for collecting data files can preserve file times"라고 경고하면서, "Bit stream images can preserve file times because a bit-for-bit copy is generated; performing a logical backup using some tools may cause file creation times to be altered when the data file is copied"라고 구분한다. 비트 단위 사본은 시각을 그대로 옮기지만, 일부 도구로 논리적 백업을 하면 파일 생성 시각이 사본 과정에서 달라질 수 있다는 뜻이다. 이 경우 기록된 시각의 차이는 사건의 차이라기보다 수집 도구의 흔적에 가깝다. 이 사례에서 상대방이 제출한 계약 파일 세 개는 이름과 작성일 표시가 서로 다르지만, 각 파일이 어떤 방식으로 수집됐는지는 미정이다. 수집 방식이 확인되지 않은 채로는 그 작성일 표시의 차이를 사건 순서의 근거로 삼을 수 없다.
조회 과정에서 시각이 달라지는 경로도 따로 있다. 미국 상무부 국립표준기술연구소(NIST), Guide to Integrating Forensic Techniques into Incident Response (NIST SP 800-86), 2006-08, 4.2.3·4.4절, 인쇄면 4-9·4-15쪽 (PDF 41·47쪽)은 "some tools modify the last access time of a file or directory if the filesystem has been mounted with write permissions by the OS"라고 지적하고, 쓰기 방지 장치를 써도 "they cannot prevent the OS from caching the changes in memory (i.e., storing the changes in random access memory [RAM])"라며, 이어 "The OS might then report the cached MAC times rather than the actual times, thereby returning inaccurate results"라고 설명한다. 결국 "the last access time for data files and directories might change between queries, depending on the tool used to perform the query"할 수 있으므로, 분석가는 조회 방법의 세부를 기록해야 한다. 같은 파일을 두 번 조회했더니 마지막 접근 시각이 달랐다면, 그 차이가 접근 행위의 차인지 조회 도구의 차인지는 이 사정만으로는 정해지지 않는다.
따라서 특정 시간순서가 성립하지 않는다고 말하려면, 어느 쪽 조건이 해당하는지 먼저 밝혀야 한다. 시계 오차인지, 기록 세밀함의 결여인지, 외부 개입인지, 수집·조회 도구의 영향인지에 따라 같은 시각표가 품는 뜻이 달라진다. 이 사례에서 이메일 헤더의 송수신 일시와 경유 서버가 적혀 있으나 헤더가 어느 기준 시각으로 기록됐는지, 계약 파일의 작성일이 어느 도구로 읽힌 값인지는 미정이다. 남은 쟁점으로는 이메일 본문이 말한 첨부 파일이 묶음에 없다는 사정, 설명 문서의 작성 일자 표시와 본문이 말하는 시점이 어긋난다는 사정, 그리고 세 기록의 시각이 같은 시간대 기준인지가 있다. 자료에 확인된 오차 원인만으로 어느 파일이 승인된 본인지, 누가 먼저 알았는지, 설명 문서 작성 당시 어떤 자료가 검토됐는지를 단정할 수 없다. 자료가 있다는 사실은 법적 평가와 구분되어야 한다.
12.2시계 오차가 바꾼 사건 순서
기록의 수가 늘어나면 문제는 차례 자체로 옮겨간다. 앞에서 확인한 오차의 원인이 실제로 사건의 선후를 뒤바꾼다면, 묶음에 든 자료의 시간 표시만으로 그 순서를 확정할 수 없다. 시계 오차가 어떤 식으로 사건 순서를 바꾸는지, 오차를 반영한 대체 연표가 무엇을 말하고 무엇을 말하지 않는지 살핀다.
NIST SP 800-92는 기록을 만드는 호스트가 자기 내부 시계를 참조해 시각을 적는다고 전제한 뒤, 시계가 부정확하면 그 기록의 시각도 부정확하다고 밝힌다. "If a host's clock is inaccurate, the timestamps in its logs will also be inaccurate. This can make analysis of logs more difficult, particularly when logs from multiple hosts are being analyzed."[NIST SP 800-92, 미국 상무부 국립표준기술연구소(NIST), Guide to Computer Security Log Management (NIST SP 800-92), 2006-09, 2.3.1·3.1절, 인쇄면 2-9·3-4쪽 및 각주 24 (PDF 23·30쪽)] 이 사례에서 계약 파일 세 개와 이메일, 설명 문서가 각각 다른 기록 주체에서 만들어졌다면, 각각의 시각 표시는 각 기록의 내부 시계에 의존한다. 이메일 헤더의 송수신 일시나 경유 서버 표시도 그 기록 주체가 남긴 시각이며, 다른 기록의 시각과 곧바로 같다고 놓을 수 없다.
같은 자료는 오차가 어떤 결과를 낳는지 예를 들어 설명한다. "For example, timestamps might indicate that event A happened 45 seconds before event B, when event A actually happened two minutes after event B."[NIST SP 800-92, 미국 상무부 국립표준기술연구소(NIST), Guide to Computer Security Log Management (NIST SP 800-92), 2006-09, 2.3.1·3.1절, 인쇄면 2-9·3-4쪽 및 각주 24 (PDF 23·30쪽)] 시각 표시로는 A가 B보다 앞서지만 실제로는 B가 A보다 앞선 경우다. 이 예는 오차로 사건의 선후가 뒤바뀐다는 점을 보이지만, 이 예에 쓰인 45초나 2분을 묶음 안 다른 사건에 그대로 대입하는 것은 근거가 없다. 어느 파일이 먼저 만들어졌는지, 이메일의 변경합의가 계약 파일 수정보다 앞서는지는 예의 수치로 가릴 수 없다.
이 사례에서 묶음의 각 기록은 서로 다른 시각 표시를 담고 있다. 계약 파일 세 개에는 작성일 표시가 각각 다르고, 이메일 헤더에는 송수신 일시가, 설명 문서에는 문서 앞뒤의 작성 일자와 본문이 말하는 시점이 함께 들어 있다. 문서 앞뒤의 표시와 본문의 서술 시점이 다르다는 사실만으로 문서가 언제 만들어졌는지가 정해지지는 않는다. 자료가 제공한 예가 이 사례의 세 기록에도 같은 양으로 적용된다고 단정할 수 없고, 그 오차가 어느 방향인지도 확인되지 않았다.
이 사례에서 시간 순서를 단정할 수 없으므로, 그 순서에 놓인 비교도 함께 열려 있다. 이메일 본문에서 말한 첨부 파일이 묶음에 없다는 점, 그리고 이메일 본문이 요약한 합의 내용과 계약 파일 본의 승인 여부가 함께 미정이라는 점은 각각 확인된 사실이다. 그러나 첨부 파일의 부재를 근거로 이메일이 먼저 작성됐거나 늦게 작성됐다고 보는 것은 이 자료가 주지 않는 판단이고, 변경합의를 먼저 알았거나 나중에 알았다는 단정도 자료에 근거가 없다. 오차를 반영한 대체 연표는 선후가 확정되지 않았다는 사실을 드러낼 뿐, 누가 먼저 알았는지나 어떤 기록이 진실인지를 정하지 않는다.
따라서 묶음 안 자료에 적힌 시각은 그 자체로 사건의 실제 선후를 이루지 않는다. 앞 절에서 확인한 오차의 조건이 여기서 그대로 작동하며, 이 사례의 순서는 오차를 반영하지 않은 한 성립하지 않는다. 오차를 반영한 대체 연표는 선후의 미정을 함께 적어 두는 도구이고, 기록이 존재한다는 사실은 어떤 자료가 있는지를 말할 뿐 그 자료의 법적 평가를 내포하지 않는다.
12.3시간대와 비동기 시각의 정규화
시계 오차로 사건 순서가 뒤바뀔 수 있다는 확인에서 나아가, 이번에는 서로 다른 기준으로 적힌 시각을 한 기준에 맞추는 작업의 성격을 살핀다. 묶음 속 계약 파일과 이메일 헤더, 설명 문서에는 각각 다른 방식의 일시 표시가 들어 있다. 이러한 표시를 나란히 놓고 비교하려면 우선 하나의 형식으로 옮기는 절차가 필요하다.
그 절차의 일반적인 모습을 다음 자료가 설명한다. 미국 상무부 국립표준기술연구소(NIST), Guide to Computer Security Log Management (NIST SP 800-92), 2006-09, 3.1절, 인쇄면 3-4쪽은 기록 정규화를 두고 "In log normalization, each log data field is converted to a particular data representation and categorized consistently. One of the most common uses of normalization is storing dates and times in a single format."고 하였다. 날짜와 시각을 한 형식에 모으는 일이 정규화의 흔한 쓰임임을 알려준다. 이 사례에서 이메일 헤더의 일시와 계약 파일의 작성일 표시가 다른 방식으로 적혀 있다면, 비교를 시작하기 전에 표기를 하나로 맞추는 일이 먼저이다.
형식을 맞춘 뒤에도 시각의 기준 자체가 서로 다른 문제가 남는다. 같은 자료 2.3.1절, 인쇄면 2-9쪽은 각 기록이 자기 시계를 따라 시각을 적는다고 하면서 "Each host that generates logs typically references its internal clock when setting a timestamp for each log entry. If a host’s clock is inaccurate, the timestamps in its logs will also be inaccurate."고 하였다. 기록한 장치의 시계가 어긋나면 적힌 시각도 함께 어긋난다. 이 사례에서 세 기록의 시각이 같은 시간대 기준인지는 아직 정해지지 않았다.
시간대가 서로 다르면 기준을 한쪽으로 통일하는 보정이 뒤따른다. 같은 자료 각주 24는 "Organizations with systems in multiple time zones often need to convert all logged times to a single time zone. Also, systems’ clocks might not be in sync with each other, so it might be necessary to add or subtract times from the log entries recorded by out-of-sync sources."고 하였다. 시간대를 한 기준에 모으고, 어긋난 시계에 대해서는 더하거나 빼는 조정이 함께 이루어짐을 말한다. 다만 이 사례의 세 기록 가운데 어느 기준으로 옮길지, 그리고 어떤 만큼을 조정할지는 자료가 아직 정하지 않았다.
그와 같은 조정이 원래 기록을 바꾸는 것은 아니다. 정규화는 표시를 비교 가능하게 만드는 작업이며, 그 자체로 계약 파일 가운데 어느 것이 승인된 본인지, 이메일에서 말한 첨부가 실제로 존재했는지를 정하지 않는다. 같은 자료 3.1절은 정규화가 여러 형식이 쓰일 때 분석과 보고를 크게 쉽게 하지만 자원을 많이 쓰는 일이 될 수 있다고 하였다. 시각을 한 기준에 맞춘 뒤에도 각 기록이 지닌 불확실한 점은 그대로 남는다.
12.4오차를 반영한 대체 연표
정규화가 끝난 뒤에도 남는 것은 기록마다 붙은 시각의 오차이며, 그 오차를 연표에 어떻게 남길 것인지가 다음 문제이다. 연표를 만드는 방법에 관한 문서가 이에 관해 명시적으로 다룬다.
시간 데이터를 다루는 작업에서 우선할 것은 원래 기록의 보존이다. NIST SP 800-86은 연표의 정확성을 위해 기록된 시각 자체를 지켜야 함을 다음과 같이 말한다. "If an analyst needs to establish an accurate timeline of events, then the file times should be preserved." 여기서 'preserve'는 기록된 시각을 지우거나 바꾸지 말라는 뜻이며, 이 사례에서 계약 파일과 이메일 헤더에 적힌 날짜를 임의로 고쳐 쓸 수 없다는 기준이 된다.
그런데 보존된 시각조차 틀릴 수 있다는 점이 함께 적혀 있다. 같은 문서는 오차의 이유로 다음 세 가지를 든다. "The computer’s clock does not have the correct time. For example, the clock may not have been synchronized regularly with an authoritative time source." 다음으로, "The time may not be recorded with the expected level of detail, such omitting the seconds or minutes." 세 번째로, "An attacker may have altered the recorded file times." 이 셋은 이 사례의 이메일 헤더와 계약 파일, 설명 문서에 적힌 시각에도 그대로 걸릴 수 있는 오차 원인이다.
오차 원인이 다양하기 때문에 도구의 선택과 그 방법의 기록이 요구된다. NIST SP 800-86은 분석 방법을 남길 것을 다음과 같이 당부한다. "Because of these issues, analysts should take care in choosing a MAC viewing method and record the details of that method." 이 기준에 따르면 계약 파일과 이메일 본문의 시각을 어떻게 읽어 냈는지를 밝히지 않으면, 연표에 남긴 시각이 어디서 나온 것인지 확인할 길이 없다.
오차가 존재한다는 사실은 반대 방향의 기록으로도 확인된다. NIST SP 800-92는 서로 다른 호스트의 시각이 어긋날 때 벌어지는 일을 예로 설명한다. "timestamps might indicate that event A happened 45 seconds before event B, when event A actually happened two minutes after event B." 이 예는 순서가 뒤바뀌는 오차가 연표에서 그대로 드러날 수 있음을 말한다. 이 사례에서 세 기록의 선후가 보이는 대로 사실이 된다고 단정할 수 없는 까닭이다.
그렇다면 성립하지 않는 순서 대신 무엇을 놓을 것인가. NIST SP 800-92는 시각을 맞출 때도 조정의 근거가 있어야 함을 각주에서 밝힌다. "Also, systems’ clocks might not be in sync with each other, so it might be necessary to add or subtract times from the log entries recorded by out-of-sync sources." 이 말은 어긋난 시각을 손볼 여지가 있다는 뜻이지, 임의의 값으로 채워 넣어도 된다는 뜻은 아니다. 이 사례에서 시간대 기준이 맞는지, 손본 값이 무엇에 근거했는지가 미정인 한, 그 구간은 빈 채로 두어야 한다.
따라서 대체 연표는 확정된 순서를 그리는 그림이 아니라, 오차의 범위를 함께 적어 두는 기록이 된다. 각 기록에 대해 확인된 시각과 그 시각이 갖는 오차 원인을 나란히 두고, 선후를 정할 수 없는 자리는 정할 수 없는 자리로 남긴다. 자료가 적은 구간에 시점이나 간격을 채워 넣지 않는 것이 이 연표가 따르는 방식이다. 이 사례에서 계약 파일 셋 가운데 어떤 것이 승인된 본인지, 이메일 첨부가 존재했는지가 미정인 상태로 남는 것과 같은 이치이다.
이렇게 구성한 연표는 자료가 보여 준 시각의 나열에 그친다. 자료가 있다는 사실은 그 자체로 법적 평가가 아니며, 오차를 적어 두었다는 사실 역시 사건의 법적 평가를 정하지 않는다. 남은 것은 이 연표가 어디까지 사실을 말하고 어디까지 말하지 못하는지를 가리는 일이다.
12.5대체 연표의 사실성 한계
오차를 반영한 대체 연표를 세운 뒤에는, 그 연표가 얼마만큼 사실에 가까운지를 스스로 되묻지 않을 수 없다. 대체 연표는 성립하지 않는 순서를 피한 해석의 결과물이지만, 해석이 곧 사실의 확정은 아니다. 그러므로 연표가 무엇을 말하고 무엇을 말하지 못하는지, 그 경계를 함께 적어 두는 것이 이 단계의 남은 일이다.
대체 연표의 사실성을 논하기 전에, 그 연표의 바탕이 된 시각 자료가 정확한지부터 따져야 한다. 미국 상무부 국립표준기술연구소(NIST)는 Guide to Integrating Forensic Techniques into Incident Response (NIST SP 800-86), 2006-08, 4.2.3절, 인쇄면 4-9쪽 (PDF 41쪽)에서 파일 시각이 부정확할 수 있는 까닭을 다음과 같이 든다. "Analysts should also be aware that file times may not always be accurate. Among the reasons for such inaccuracies are the following: ! The computer’s clock does not have the correct time. For example, the clock may not have been synchronized regularly with an authoritative time source. ! The time may not be recorded with the expected level of detail, such omitting the seconds or minutes. ! An attacker may have altered the recorded file times." 이 기록은 시각 자료의 부정확함이 자료 수집 방법이나 기록 형식, 심지어 외부의 개입에서 비롯될 수 있음을 알려 준다. 이 사례에서 세 계약 파일의 작성일 표시와 이메일 헤더의 송수신 일시가 서로 어긋나 보인다면, 그 어긋남이 순서의 성립 여부만이 아니라 시각 자료 자체의 정확성 문제와 맞물려 있음을 함께 봐야 한다.
시각 자료를 읽는 방법에 따라서도 시각이 달라질 수 있다. 앞서 인용한 NIST SP 800-86, 4.4절, 인쇄면 4-15쪽 (PDF 47쪽)은 분석 도구가 시각을 다루는 방식의 차이를 다음과 같이 지적한다. "If multiple tools are used to complete an examination and analysis, the analyst should understand how each tool extracts, modifies, and displays file modification, access, and creation (MAC) times. For instance, some tools modify the last access time of a file or directory if the filesystem has been mounted with write permissions by the OS. Write-blockers can be used to prevent these tools from modifying the MAC times; however, although write-blockers can prevent these times from being modified on the media, they cannot prevent the OS from caching the changes in memory (i.e., storing the changes in random access memory [RAM])." 같은 자료를 두고 도구를 달리하면 표시된 시각이 달라질 수 있다는 뜻이다. 따라서 이 사례의 대체 연표에 적힌 시각은 어떤 도구로 어떻게 읽었는지를 함께 밝힌 표시로만 의미를 가진다.
여러 기록의 시각을 함께 놓고 볼 때에는 시간대의 문제도 먼저 손봐야 한다. 미국 상무부 국립표준기술연구소(NIST)는 Guide to Computer Security Log Management (NIST SP 800-92), 2006-09, 2.3.1절, 인쇄면 2-9쪽 (PDF 23쪽)에서 로그의 시각이 어긋나는 까닭을 다음과 같이 설명한다. "Each host that generates logs typically references its internal clock when setting a timestamp for each log entry. If a host’s clock is inaccurate, the timestamps in its logs will also be inaccurate. This can make analysis of logs more difficult, particularly when logs from multiple hosts are being analyzed. For example, timestamps might indicate that event A happened 45 seconds before event B, when event A actually happened two minutes after event B." 각 기록이 저마다의 시계를 따라 시각을 적었으므로, 두 시각의 차이가 곧 사건의 선후를 뜻하지 않을 수 있다. 이 사례에서 세 기록의 시각이 같은 시간대 기준인지 여전히 미정인 채로 남아 있는 한, 대체 연표는 그 미정을 미정으로 드러낸 표시에 그쳐야 한다.
자료의 형식을 맞추는 정규화는 분석을 돕지만 그 자체로 사실을 만들어 주지는 않는다. 같은 문서 3.1절, 인쇄면 3-4쪽 (PDF 30쪽)은 정규화의 범위와 함께 그 각주 24에서 시간 정규화가 품는 난점을 다음과 같이 적는다. "In log normalization, each log data field is converted to a particular data representation and categorized consistently. One of the most common uses of normalization is storing dates and times in a single format." 이어서 각주 24는 "Normalizing times is often particularly challenging. Organizations with systems in multiple time zones often need to convert all logged times to a single time zone. Also, systems’ clocks might not be in sync with each other, so it might be necessary to add or subtract times from the log entries recorded by out-of-sync sources." 라고 덧붙인다. 시각을 한 형식에 맞추어 적는 일은 표기를 한자리로 모으는 작업이지, 원래 시각이 서로 맞았다는 확인이 아니다. 이 사례에서 대체 연표가 세 기록의 시각을 나란히 놓아 보여 주더라도, 세 기록이 같은 시간대 기준으로 적혔는지는 그 연표만으로 확인되지 않는다.
따라서 대체 연표는 사건의 순서를 해석하는 데 쓰는 표시이지, 증명력의 판단 기준을 대신하지 않는다. 타임스탬프의 오차량이 얼마인지, 어느 계약 파일이 승인된 본인지, 이메일에서 말한 첨부 파일이 실제로 존재했는지, 설명 문서 작성 당시 어떤 자료가 검토되었는지는 이 사례에서 여전히 미정이다. 대체 연표가 말할 수 있는 것은, 확인된 표시들이 서로 어긋나므로 성립하지 않는 순서를 세우지 않겠다는 것과, 그 어긋남을 오차로 남겨 두겠다는 것에 그친다. 자료가 있다는 사실이 곧 법적 평가가 아니듯, 대체 연표에 시각이 적혀 있다는 사실도 곧 그 시각이 사실이라는 뜻은 아니다.
다룬 공식 문서
- 미국 상무부 국립표준기술연구소(NIST), Guide to Integrating Forensic Techniques into Incident Response (NIST SP 800-86), 2006-08, 4.2.3·4.4절, 인쇄면 4-9·4-15쪽 (PDF 41·47쪽)
- 미국 상무부 국립표준기술연구소(NIST), Guide to Computer Security Log Management (NIST SP 800-92), 2006-09, 2.3.1·3.1절, 인쇄면 2-9·3-4쪽 및 각주 24 (PDF 23·30쪽)