eDiscovery은 미국에서 소송에 관련된 자료를 제출하기 위한 과정에서 사용되는 전체적인 과정을 뜻하며, 한국에서도 이와 비슷한 솔루션을 제작하려는 여러 가지 시도가 있다. 관련한 개념적인 자료를 공유한다.

1. FORENSIC INSIGHT;
DIGITAL FORENSICS COMMUNITY IN KOREA
Feature of eDiscovery Solution
goodsped
(goodsped76@outlook.com)

2. forensicinsight.org Page 2
Contents
1. Data Set
2. Structure
3. Concept of Search Function
4. Additional Function
5. More

3. forensicinsight.org Page 3
Data Set

4.  Source Data
• 실제의 Evidence와 동일한 사본이며 해당 데이터가 프로세싱된 데이터가 별도의 데이터 보관구역에 격납됨
• Evidence 데이터와 처리된 데이터가 존재하며 아카이브는 다시 Decompress된 데이터가 한 개 더 유지된다.
• Evidence Data가 파손되었다거나 추가적인 처리를 필요로 하는 경우에는 데이터를 Replace하게되는데 이때에는
이 구역에 보관된 데이터를 교환하게되지만 기본적으로 Source Data만 변경될뿐 Description Data들에게는 영
향을 주지 않는다.(물론 LOG로써 그러한 작업기록이 유지되어야만 한다.)
 Description Data
• 처음 Source Data부분에 Evidence가 복제를 하면서 해당 데이터가 가진 Meta와 더불어 Operator에 의해서 추가
된 데이터 (Custodian Mapping등의 사용자가 지정할 수 있는 데이터)들의 셋트가 발생된다.
• 프로세스후에도 새로운 자료들이 생성되게되며 때로는 각각의 Description Data의 상호작용 (예를들어 DeDup,
Set Operation)에 의해서 새로운 Attribute가 발생되는 경우가 있다.
 Attorney’s Description Data
• Operator에 의해서 발생된 데이터가 아닌 고객(주로 Attorney)에 의해서 생성되는 데이터이다.
• Coding(Review중 Tag를 입력)에서 발생되는 데이터로써 각각의 조건들은 향후 검색의 인자로써 쓰여지기 때문
에 Value는 기본적으로 정수나 스트링등의 단위로 유지하는게 일반적이지만 문자열을 받아들이는 Attribute도
생각할수 있다. 향후 이 데이터 안에 리뷰완료후에 추가적인 Attribute가 Append되는 경우도 있는데 이는 차후
에 설명하도록 하겠다.
Data Set

5.  각각의 DB에 보관되며 위의 구조로 구분되어 보관되어진다. 통상 원본데이터는 두개의 사본으로 유지되며 한 개의
사본은 서버에 업로드 된후 어떠한 액세스(갱신)과정을 피해 유지되도록 하는게 좋다. 이후 두번째 사본에서
아카이브(PST, ZIP)등의 파일은 거기서 세번째의 즉, 파일 분해가 완료된 사본이 완성되게된다.
 기본적으로 데이터에 대해서 Unique ID를 부여한다. 이는 향후 Production이 완료된후 Bates Number가 Description
Data에 유지된다. (해당 Unique ID는 Description Data로써 보관된다)
 Doc, txt, jpg, rtf등의 파일에는 각각의 고유ID가 붙게 된다. 하지만 이 시점에서 PST또한 고유 ID가 붙는다. 이렇게 1차
처리를 하고 나면 PST나 ZIP의 경우는 2차 처리를 진행하게 된다. 이 시점에서 분해된 각각의 MSG에도 고유 ID가
붙는다. 거기서 다시 MSG내부에 doc, jpg, txt같은 파일이 나타나게된다면 그것에 대해 3차 프로세스를 진행하게 되고
각각의 파일에 고유 ID를 부여하게 된다. 물론 설명을 위해 순차별로 나눈 것이지만 실제의 프로세스에서는
물리적으로 보여지는 파일에 대해서 xls를 처리하고 pst를 만나면 그 pst내부의 msg를 처리하고 다시 그 내부의
첨부까지 처리를 하 고난 뒤에 다음 파일을 진행하는 것이 되므로 실제로 연속된 번호를 부여하는 고유ID이기 때문에
메일 본문(MSG)와 그 본문의 첨부들은 비슷한 번호에서 보여지게 된다.
Data Set

6.  Hash는 파일의 레코드 첫부분에서 마지막 까지를 계산해서 얻어낸 값이다. 즉 내용이 바뀌지 않았다 해도 파일을
열었다거나 임의의 일반적 파일카피를 실시하는 경우에도 Hash가 일치하지 않을 경우가 많다. 예를 들어 itunes를
설치하면 발생하는 bonjour가 각각의 대상자의 PC에 있다한들 그것이 설치한 시기에 따라 다른 타임 스탬프를 가지고
있으면 Forensic관점에선 중복이라고 보기 힘들다. 하지만 Discovery의 입장에서는 이러한 부분에 대해서 동일
파일이라고 구분할 필요가 있다. 즉 해당 파일의 레코드 처음부터 끝까지에 대한 Hash계산이 아닌 해당 파일의 해당
어플리케이션에서 열었을 때 보여지는 파일의 (내용상의) 첫부분에서부터 마지막 부분까지를 계산하게된다. 이렇게
되면 해당 파일의 내용을 제외한 부분에 영향을 받지 않고 중복을 검사해낼수 있다.
 같은 내용의 메일을 Sender 와 Receiver가 주고받지만 Header가 다소 다르고, Receiver가 다수인경우 이러한 메일들이
중복이라는 판단을 하기 위해서는 Header가 포함되서는 안된다. 그러한 이유로 데이터들의 내용상의 중복만을
검사하도록 해야하며, Email의 경우는 Near Deduplication이라는 기능으로 메일의 스레드가 상당부분 발생되었을
경우 해당 메일의 스레드중 파생된것들중 최종의(최신의)의 메일만을 리뷰하도록 하게하며 그러한 중복이 발생된
문서를 망라한 하나의 Family로써 하나의 통합된 Tag를 부여할수 있는 일관적인 작업을 가능케한다.
eDiscovery In these day

7. forensicinsight.org Page 7
Structure

8. Structure
 서버는 Evidence에 의한 훼손(바이러스, 악성코드)및 적절한 데이터 처리(예를 들어 처리하는 서버가 한글판 인경우
다른 언어로 작성된 데이터를 처리하면서 깨진채로 처리되는 경우가 있으므로)를 위해서 프로세스용 서버와
검색/인터페이스부분을 VM등으로 구분하여 데이터를 처리하는 것이 좋다. 물론 DB를 좀더 쉽게 다루기 위해서나
데이터의 보안성을 향상시킬 목적으로 각각의 환경을 가상 환경내에서 별도의 환경으로 구분하면서 얻는 이점이
있지만 그것의 부작용으로써 물리적으로 동일한 서버임에도 몇번은 외부의 VPN스위치나 F/W를 경유하는 의미없는
데이터의 송수신량이 증가되어 전체적으로 퍼포먼스를 떨어트리는 경향도 있다. 다만 DB가 업그레이드되거나 혹은
검색/인터페이스부분의 교체도 상당히 편리하다는점을 장점으로 꼽을수 있다.
 리뷰어(클라이언트)측에서 어떠한 기능을 호출하게되는 경우, 그 기능이 DB내의 일부지역을 검색하고 그 결과를
가시화하는 과정에 있어서의 움직임이 상당한 Task로 작용하는 경우가 있다. VLAN등으로 가능한 의미없는 패킷들이
내부의 스위치/허브에서 맴돌지 않도록 충분히 컨트롤되어야한다.
 보안성 제고를 위해서 솔루션내의 파일은 별도의 권한설정없이 로컬에 내려 받아지지 않도록 고안되어야하며, 문서의
출력이 필요할 때는 LOG에 유지되며 별도의 워터마크등을 씌워서 프린트되도록 하는 기능이 탑재되어있다.

9. forensicinsight.org Page 9
Concept of Search Function

10. Concept of Search Function
 검색되지 않는 데이터들
• ESI가 아닌 파일  스캔된 문서, 혹은 이미지파일등 텍스트를 담고 있지 않은 파일
• 보호된 파일  DRM이나 패스워드가 걸려있는 파일
• 읽을수 있는 문서가 아닌 파일  mp3, avi파일이나 dwg, emp 같은 특수한 어플리케이션 데이터
• 읽을수 있으나 대상이 아닐수 있는 파일  *.h, *.c 같은 소스코드 같은 의미가 모호한 데이터일부
 기본적 검색방식
• 통상 CMD에서도 활용하는 와일드카드(*)와 물음표(?)
• 근방검색
• 정규 표현식 (Regular Expression)
• Empty & Not Empty

11. forensicinsight.org Page 11
Additional Function

12. Additional Function
 “Set Operation”
 Near DeDuplication
 다양한 HiLight, hyperlink (또는 점프)기능
• (하이퍼링크) (하일라이트) (KW 그룹별 색상설정) (OCR문서와 스캔문서를 레이어화)
• (회전/줌) (메모기능) (북마크기능) (네이티브 뷰어로 전환보기)
• (Redaction) (Coding Log)
 Progress Report 기능과 자동화 기능
 Exception Handling
 Batch