CDR 도입 가이드 —
유입 경로 점검부터 운영 안정화까지 5단계

CDR(Content Disarm and Reconstruction)은 파일 안의 능동 요소를 걷어내고 문서를 다시 만드는 방식이다. 원리는 한 문장으로 설명되지만 도입은 그렇게 간단하지 않다. 어느 경로에 둘지, 매크로가 필요한 부서를 어떻게 처리할지, 암호화된 첨부파일을 어디로 보낼지, PoC에서 무엇을 측정할지를 정하지 않으면 엔진이 좋아도 예외 요청이 쌓이고, 결국 꺼진 채로 남는다. 이 CDR 도입 가이드는 도입을 유입 경로 인벤토리 → 정책 설계 → PoC·BMT → 단계적 배포 → 운영 안정화의 5단계로 나누고, 단계마다 만들어야 할 산출물과 점검 항목을 시큐레터 공식 자료와 공개 표준을 근거로 정리한다.

CDR 도입이 흔들리는 지점은 엔진 성능보다 범위 정의인 경우가 많다. "문서형 악성코드를 막는다"는 목표는 너무 넓어서, 무엇을 처리하고 무엇을 다른 통제에 맡길지 판단할 기준이 되지 못한다. 범위는 위협이 실제로 들어오는 방식에서 출발해야 한다.

문서를 이용한 공격은 대체로 세 가지 조건이 겹칠 때 성립한다. 첫째, 파일이 조직 안으로 들어온다. 유입 경로는 이메일 첨부, 웹 업로드, 망간 자료전송, 외부 저장매체 등으로 다양하다. 이 가운데 악성 첨부파일을 단 스피어피싱 이메일을 MITRE ATT&CK는 스피어피싱 첨부파일(T1566.001)로 분류한다^[8]. 둘째, 사용자가 그 파일을 연다. ATT&CK의 사용자 실행: 악성 파일(T1204.002)이 이 단계다^[10]. 셋째, 파일 안의 능동 요소가 동작한다. 매크로, OLE 개체, DDE 필드, PDF의 JavaScript·실행 액션, 외부 리소스를 불러오는 링크가 여기에 해당한다. 문서 자체에는 코드가 없고 열릴 때 원격 템플릿을 불러오는 기법도 있다. ATT&CK는 이를 템플릿 인젝션(T1221)으로 따로 분류한다^[9].

CDR이 개입하는 지점은 세 번째 조건이다. CDR 방식은 일반적으로 파일을 포맷 명세에 따라 해석하고, 허용된 구성 요소만 남겨 새 파일을 쓴다. 원본 바이트를 그대로 통과시키지 않기 때문에, 알려지지 않은 취약점을 노린 파일이라도 그 취약점이 기대는 구조가 재작성 과정에서 남지 않으면 효과가 사라진다. 시큐레터는 이 과정을 CDR 파일 스캔(액티브 콘텐츠 분석) → 액티브 콘텐츠 제거 → 파일 재생성의 3단계로 설명한다^[1].

반대로 CDR이 맡지 않는 영역도 범위 문서에 적어 둔다. 범위가 명확해야 PoC 평가표도 명확해진다.

도입 검토에서 반복되는 질문은 "이미 백신과 샌드박스가 있는데 또 무엇을 추가하느냐"다. 이 질문에 답하려면 각 방식이 무엇을 잘하는지 먼저 공정하게 적어야 한다. 상대 방식을 실제보다 약하게 그리면 내부 검토에서 곧바로 반박당한다.

탐지 기반 솔루션은 알려진 악성코드와 그 변형군을 빠르고 적은 자원으로 걸러낸다. 개별 해시만 쓰는 것이 아니라 일반화된 시그니처, 휴리스틱, 평판 정보를 함께 쓰기 때문에 같은 계열의 새 변형 일부도 잡아낸다. 무엇보다 판정 결과를 남긴다는 점이 중요하다. 사고 조사, 차단 근거, 위협 공유에는 판정이 필요하다.

샌드박스 기반 솔루션은 파일을 격리 환경에서 실제로 열어 행위를 관찰한다. 시그니처가 없는 위협도 행위로 드러날 수 있고, 생성되는 프로세스·네트워크 연결·파일 변경 같은 상세 정보를 사고 대응에 넘겨준다. 다만 공격자는 분석 환경을 알아차리고 동작을 멈추거나 늦추는 기법을 쓴다. ATT&CK는 이를 가상화·샌드박스 회피(T1497)로 정리한다^[14]. 분석 환경을 얼마나 실제 업무 환경에 가깝게 구성하느냐에 따라 결과가 달라지고, 관찰에 시간이 걸리므로 이메일 지연을 어떻게 다룰지 운영 결정이 필요하다.

CDR은 판정 대신 결과물을 바꾼다. 파일이 실행 환경을 감지하는지와 무관하게 재작성된 파일이 전달되므로, 환경 회피에 기대는 공격은 같은 방식으로 작동하지 않는다. 대신 CDR에는 고유한 한계가 있다. 지원하지 않는 포맷은 처리할 수 없고, 매크로처럼 업무에 필요한 기능도 함께 제거되며, 재작성 과정에서 문서의 전자서명이 유지되지 않을 수 있다. 그리고 판정 정보를 주지 않는다.

표에서 보듯 세 방식은 서로의 약점을 겹쳐 덮는다. 실무에서는 판정과 무해화를 함께 쓰는 구성이 자연스럽다. 판정 엔진이 악성으로 확정한 파일은 차단하고 분석 정보를 남기며, 판정이 서지 않거나 정상으로 보이는 파일도 무해화를 거쳐 전달한다. 시큐레터의 MARS 엔진은 리버스 엔지니어링 기반으로 파일을 분석하는 공통 엔진이며, 시큐레터는 이를 행위 기반으로 악성코드 내역을 탐지하고 플랫폼 버전과 무관하게 탐지하는 방식으로 설명한다^[3]. 이메일 영역의 SLE는 DISARM을 통합한 이메일 보안 제품이다^[2].

아래 5단계는 각 단계가 다음 단계의 입력을 만들도록 배열했다. 인벤토리가 없으면 정책을 쓸 수 없고, 정책이 없으면 PoC 평가표를 만들 수 없으며, PoC 결과가 없으면 배포 순서를 정할 근거가 없다. 일정이 빠듯할수록 단계를 건너뛰고 싶어지지만, 건너뛴 단계의 결정은 운영 중 민원으로 되돌아온다.

CDR 도입 가이드의 첫 단계인 인벤토리의 목적은 "파일이 어디로 들어오는가"를 목록이 아니라 수치로 만드는 것이다. 메일 게이트웨이, 망간 자료전송 시스템, 웹 서비스 업로드 서버의 로그를 일정 기간 수집해 경로별 일 처리 건수, 포맷 분포, 파일 크기 분포, 암호화 파일 비율을 뽑는다. 업무 주기를 반영하려면 월말·분기말 같은 처리량 정점이 수집 기간에 들어가도록 잡는다.

이 수치는 이후 모든 단계에 쓰인다. 포맷 분포는 정책 매트릭스의 행이 되고, 처리량 정점은 PoC의 부하 시험 조건이 되며, 암호화 비율은 별도 처리 흐름이 얼마나 많은 사용자에게 영향을 주는지 알려준다. 이메일 경로를 우선 살피는 이유도 수치로 설명할 수 있다. 시큐레터 회사 소개 자료는 악성코드 공격의 1차 경로로 이메일 75%를 제시한다^[2]. 다만 조직마다 경로별 비중은 다르므로, 외부 수치는 출발점으로만 쓰고 자기 조직 로그로 다시 확인한다.

웹 업로드 경로는 자주 빠진다. 민원 서류나 증빙 파일을 받는 웹 서비스는 외부 사용자가 올리고 내부 직원이 여는 구조라서, 이메일과 같은 위험을 갖는데도 메일 보안 범위에 들어가지 않는다. 인벤토리 단계에서 "외부인이 올리고 내부인이 여는 파일"이라는 기준으로 서비스를 다시 훑으면 이런 경로가 드러난다.

인벤토리에서 함께 찾아야 할 것은 무해화가 업무를 깨뜨릴 수 있는 부서다. 매크로가 포함된 엑셀 양식으로 외부 기관과 자료를 주고받는 부서, 전자서명된 PDF를 원본 그대로 보관해야 하는 계약·법무 부서, 설계 도면이나 특수 포맷을 다루는 부서가 대표적이다. 이들 부서의 담당자를 2단계 정책 설계 회의에 처음부터 참여시킨다. 운영이 시작된 뒤에 이들의 불만을 처음 듣게 되면, 그때는 예외 처리 말고는 선택지가 거의 남지 않는다.

정책 설계는 "무엇을 지울지"보다 "지운 뒤 무엇을 사용자에게 줄지"를 정하는 일이다. 같은 매크로 포함 문서라도 매크로를 제거한 문서를 전달할지, 원본은 격리해 두고 요청 시 해제할지, 아예 차단할지는 경로와 부서에 따라 달라질 수 있다. 이 선택을 표로 만든 것이 정책 매트릭스다.

표의 "기본 처리"와 "원본 처리"는 예시다. 실제 값은 조직의 위험 수용 수준과 제품이 제공하는 옵션에 따라 정한다. 중요한 것은 각 칸이 비어 있지 않도록 하는 것이다. 빈칸은 운영 중 담당자가 그때그때 판단하게 되고, 그 판단은 기록으로 남지 않는다.

매크로 정책은 조건을 나눠 생각한다. Office에는 인터넷에서 받은 파일의 매크로를 기본으로 차단하는 기능이 있다. 이 동작은 Windows 환경에서 Access·Excel·PowerPoint·Visio·Word 파일에 적용되며, 파일에 인터넷 출처 표시(Mark of the Web)가 붙어 있는지, 신뢰할 수 있는 위치·정책 설정이 어떻게 되어 있는지에 따라 결과가 달라진다^[7]. 압축 해제 도구나 전달 경로에 따라 출처 표시가 유지되지 않는 경우도 있으므로, 이 기능 하나에 매크로 통제를 맡기기보다 파일이 사용자에게 닿기 전 단계에서 매크로를 제거하는 층을 두는 편이 조건 의존성을 줄인다. 반대로 매크로가 업무에 필요한 부서는 예외 절차로 따로 다룬다.

원격 템플릿과 외부 링크는 놓치기 쉽다. DOCX 파일 자체에는 매크로를 담을 수 없지만, word/_rels/settings.xml.rels 에 관계 형식 http://schemas.openxmlformats.org/officeDocument/2006/relationships/attachedTemplate 의 외부 대상을 지정하면 문서를 열 때 원격 템플릿을 불러오도록 만들 수 있다. 정책 매트릭스의 OOXML 행에 "외부 관계 참조 처리"를 별도 항목으로 적고, PoC에서 이런 파일이 처리 후 외부 요청을 보내지 않는지 확인한다.

암호화 파일은 CDR의 구조적 한계가 가장 직접 드러나는 영역이다. 비밀번호 없이 내부 구조를 해석할 수 없으므로 일반적으로 세 가지 흐름 중 하나를 고른다. 차단하고 발신자에게 다른 방식으로 보내도록 안내하거나, 격리한 뒤 수신자가 비밀번호를 제출하면 해제해 무해화하거나, 위험을 수용하고 원본을 전달하면서 다른 통제에 맡기는 방식이다. 어떤 흐름을 고르든 1단계에서 잰 암호화 비율을 근거로 영향받는 사용자 수를 문서에 적어 둔다. 이 숫자가 없으면 운영 시작 첫 주의 민원 규모를 예측할 수 없다.

전자서명 문서는 재생성 후 서명 검증 결과가 달라질 수 있다. 전자서명은 파일의 특정 바이트 범위를 보호하므로, 재생성이 그 서명 대상 범위의 내용을 바꾸면 검증은 실패한다. 반면 PDF는 증분 업데이트로 기존 서명 범위를 보존한 채 변경을 덧붙일 수 있고, 서명 설정에 따라 허용되는 변경도 있다. 따라서 결과는 서명 유형, 허용 변경 설정, 제품의 처리 방식에 따라 달라진다. 일반적인 CDR 재생성은 파일을 새로 쓰므로 서명이 유지되지 않을 수 있다고 전제하고, 자기 조직의 서명 문서로 PoC에서 검증 결과를 직접 확인한다. 유지되지 않는 경우의 선택지는 무해화 전에 서명 검증을 수행하고 결과를 기록하는 방식, 서명 문서가 오가는 특정 경로를 예외로 두는 방식, 원본을 증빙용으로 보관하고 열람용으로는 무해화본을 쓰는 방식이 있다. 계약·법무 부서와 함께 정한다.

원본 보관에는 세 가지 값이 필요하다. 보관 기간, 해제 권한자, 해제 시 수행할 추가 검사다. 원본 해제를 사용자 셀프서비스로 열어 두면 편하지만, 공격자가 "원본을 받아야 내용이 보인다"고 유도하는 사회공학에 노출된다. 해제 요청에 사유를 남기게 하고, 해제 전 판정 엔진의 분석을 거치게 하는 구성이 안전하다.

PoC의 목적은 제품이 좋다는 것을 확인하는 데 있지 않다. 2단계에서 쓴 정책이 우리 파일에서 실제로 작동하는지를 확인하는 데 있다. 그래서 평가 항목은 제품 소개 자료의 목차가 아니라 정책 매트릭스에서 나와야 한다. 이 CDR 도입 가이드에서 PoC를 가장 길게 다루는 이유도 여기에 있다. 도입 이후 생기는 문제 상당수는 PoC에서 미리 볼 수 있었던 것들이다.

샘플은 세 묶음으로 준비한다.

첫째, 정상 업무 파일. 1단계에서 뽑은 포맷 상위 목록에 맞춰 실제 업무 문서를 모은다. 개인정보가 포함되지 않도록 비식별 처리한 사본을 쓴다. 공공 서식처럼 표와 각주가 많은 HWP 문서, 차트와 피벗이 들어간 엑셀, 글꼴을 내장한 PDF, 수식이 많은 기술 문서를 일부러 포함한다. 이 묶음은 보존 품질을 본다.

둘째, 위협 재현 파일. 매크로, OLE 개체, DDE 필드, 원격 템플릿 참조, PDF JavaScript 같은 능동 요소를 담은 시험용 파일이다. 공개 연구용 샘플을 쓸 경우 격리된 시험망에서만 다루고, 취급 절차를 보안 담당 부서와 미리 합의한다. 무해한 동작(예: 외부 요청 발생 여부만 기록하는 링크)으로 능동 요소를 재현한 파일을 직접 만들어 쓰는 방법도 있다. 이 묶음은 제거 효과를 본다.

셋째, 경계 사례 파일. 손상된 파일, 확장자와 실제 포맷이 다른 파일, 여러 겹으로 중첩된 압축 파일, 1단계에서 확인한 최대 크기에 가까운 대용량 파일, 암호화 파일이다. 이 묶음은 실패할 때 어떻게 실패하는지를 본다. 처리하지 못한 파일을 통과시키는지 차단하는지, 그 결과를 사용자와 관리자에게 어떻게 알리는지가 운영 품질을 가른다.

시간 측정은 측정 지점을 먼저 정의한다. 시큐레터 자료의 두 수치는 서로 다른 것을 잰다. 34ms는 CDR의 평균 무해화 소요시간이다^[1]. 12.027초는 TTA 인증을 받은 응답시간으로, 시큐레터는 이를 악성 메일 분석 처리 속도로 설명한다^[2][3]. 하나는 무해화, 하나는 분석이다. PoC 평가표에서도 두 값을 한 칸에 섞지 않는다. 여기에 사용자가 실제로 느끼는 종단 지연, 즉 메일이 게이트웨이에 도착한 시점부터 받은편지함에 보이는 시점까지를 따로 잰다. 종단 지연에는 큐 대기, 압축 해제, 네트워크 구간이 포함되므로 엔진 처리 시간보다 길다. 이해관계자에게 보고할 숫자는 종단 지연이다.

보존 품질은 사람이 본다. 자동 비교 도구로 렌더링 차이를 걸러낼 수는 있지만, "업무에 지장이 있는가"는 실제 사용 부서가 판단해야 한다. 1단계에서 찾은 민감 부서의 담당자에게 무해화본 묶음을 주고, 문서별로 사용 가능·수정 필요·사용 불가를 표시하게 한다. 이 결과가 4단계 배포 순서와 예외 범위의 근거가 된다.

도입 검토 문서에는 제품의 인증과 수치가 들어간다. 이 값들은 의사결정의 근거가 되지만, 각 값이 어떤 조건에서 무엇을 쟀는지를 함께 적어야 오해를 막는다. 아래 표는 시큐레터 공식 자료에 있는 항목을 정리하고, PoC에서 추가로 확인할 것을 붙였다.

인증 수치는 인증 시험의 조건 안에서 나온 결과다. 그 조건이 자기 조직의 파일 구성, 처리량, 네트워크 구조와 같다는 보장은 없다. 그래서 인증은 후보군을 좁히는 근거로 쓰고, 최종 판단은 PoC 결과로 한다. 이렇게 나눠 쓰면 내부 감사나 조달 심사에서 "인증 수치를 그대로 기대 효과로 적었다"는 지적을 피할 수 있다.

포맷 수도 같은 방식으로 읽는다. 지원 포맷이 많다는 것은 예외 처리해야 할 파일이 줄어든다는 뜻이지만, 의사결정에 중요한 것은 1단계에서 뽑은 자기 조직의 상위 포맷이 처리되는지, 그리고 국내 업무 환경에서 비중이 큰 HWP·HWPX를 레이아웃 손상 없이 처리하는지다. 포맷 수와 보존 품질은 별개의 평가 항목으로 둔다.

배포는 한 번에 전사로 켜지 않는다. 경로와 부서를 나눠 순서를 정하고, 각 단계마다 다음 단계로 넘어갈 조건과 되돌릴 조건을 미리 적는다. 순서는 조직마다 다르지만, 결정 기준은 공통으로 쓸 수 있다. 외부 노출이 큰 경로, 정책이 단순한 경로, PoC에서 보존 품질 문제가 적었던 부서부터 시작하는 것이다.

표의 순서는 하나의 예시다. 공공기관처럼 망간 자료전송이 주된 외부 파일 유입 경로인 조직은 4번을 앞으로 당길 수 있다. 어떤 순서든 "왜 이 순서인가"를 1단계 수치와 3단계 결과로 설명할 수 있어야 한다.

사용자 안내는 배포 전에 나간다. 무해화된 문서를 받은 사용자는 매크로 버튼이 동작하지 않거나 임베디드 개체가 보이지 않는 이유를 모른다. 메일 본문이나 파일명에 처리 사실을 표시할 수 있다면 표시하고, 원본이 필요할 때 무엇을 해야 하는지 한 문단으로 안내한다. 이 안내문이 없으면 사용자는 발신자에게 다시 보내 달라고 요청하고, 발신자는 같은 파일을 다른 경로로 보내려 한다. 우회 경로가 생기는 출발점이다.

롤백 기준은 숫자로 쓴다. "문제가 생기면 되돌린다"가 아니라 "메일 종단 지연이 PoC 측정값의 일정 배수를 넘는 상태가 한 시간 이상 지속되면 해당 경로를 우회 모드로 전환한다"처럼 지표, 임계값, 지속 시간, 실행 권한자를 적는다. 우회 모드에서 어떤 통제가 남는지도 함께 적는다. 롤백 기준이 숫자로 정해져 있으면 장애 상황에서 판단을 놓고 논쟁하느라 시간을 쓰지 않는다.

운영 단계의 질문은 두 가지다. 무해화가 위험을 줄이고 있는가, 그리고 업무를 방해하지 않고 있는가. 첫 번째 질문만 보면 정책은 점점 엄격해지고, 두 번째 질문만 보면 예외가 늘어난다. 두 질문을 같은 대시보드에 놓고 함께 봐야 균형을 잡을 수 있다.

원본 해제 요청률은 운영 초기에 높게 나오는 것이 자연스럽다. 중요한 것은 추세다. 사용자 안내와 예외 절차가 자리를 잡으면 요청률은 내려가야 한다. 내려가지 않는다면 특정 부서나 포맷에서 보존 품질 문제가 있다는 신호일 가능성이 높으므로, 요청이 몰리는 파일을 표본 추출해 무해화본을 직접 열어 본다.

제거 로그는 사고 대응과도 연결된다. CDR은 판정을 내리지 않지만, 어떤 파일에서 어떤 요소가 제거됐는지는 남는다. 같은 발신처에서 원격 템플릿 참조가 반복해서 제거되고 있다면 판정 엔진의 결과, 메일 헤더 정보와 함께 묶어 분석할 가치가 있다. 제거 로그를 외부 로그 시스템에 보내 다른 보안 이벤트와 같은 화면에서 보도록 구성한다. 위협 인텔리전스 제품인 ConTI처럼 외부 위협 정보를 함께 쓰면, 제거된 요소의 추세가 특정 공격 활동과 관련이 있는지 판단하는 데 도움이 된다.

정책 검토는 정기 일정으로 묶는다. 분기마다 지표를 근거로 매트릭스의 각 칸을 다시 보고, 바꾼 내용과 이유를 개정 이력에 남긴다. 개정 이력은 정책을 정기적으로 검토하고 운영 지표에 따라 조정해 왔다는 사실을 보여 주는 자료이므로, 감사 대응에서 운영 증거로 제출할 수 있다. 이 CDR 도입 가이드가 5단계 산출물에 개정 이력을 넣은 이유다.

공공과 금융에서 CDR 도입은 규제 대응 근거와 함께 검토된다. 이때 흔한 실수는 "CDR을 도입하면 해당 통제항목이 충족된다"고 쓰는 것이다. 통제항목 충족 여부는 기관의 해석과 심사로 정해지며, 하나의 제품이 하나의 항목을 혼자 충족시키는 경우는 드물다. 문서에는 어떤 통제 목표에 어떤 방식으로 기여하는가를 적는다.

공공 영역에서는 국가망보안체계(N2SF)가 기준이다. 국가사이버안보센터는 N2SF 가이드라인을 공개했고^[4], 이후 보안통제 항목을 260개 수준으로 확대하는 개편이 보도되었다^[5]. KISA는 실제 적용 사례를 모은 실증 사례집을 냈다^[6]. CDR 도입 문서에는 등급별 데이터가 오가는 경로 중 외부 파일이 들어오는 지점을 표시하고, 그 지점에서 무해화가 어떤 위험을 줄이는지 적는다. 항목별 매핑은 기관이 적용 중인 가이드라인 버전을 기준으로 한다.

민간과 금융에서는 ISMS-P 인증기준의 악성코드 통제(2.10.9)가 대표적인 연결 지점이다^[11]. 국제 기준으로는 NIST SP 800-53의 악성코드 보호(SI-3) 통제가 있다^[12]. 영국 국가사이버보안센터(NCSC)는 외부 데이터를 들여올 때 변환·검증을 거치는 설계를 아키텍처 패턴으로 설명한다^[13]. 이런 문서를 근거로 쓰면 "왜 탐지만으로 충분하지 않은가"를 내부 설득 자료에서 외부 기준으로 설명할 수 있다.

도입 검토 회의에서 나오는 반론은 대개 예상할 수 있다. 미리 답을 정리해 두면 회의가 결정으로 이어진다. 아래 답은 모두 앞 단계의 산출물을 근거로 삼는다는 점에 주목한다.

비용 질문에 "사고 한 건의 피해에 비하면 작다"고 답하는 것은 설득력이 약하다. 피해액 추정은 가정에 크게 좌우되고, 반론하는 쪽도 같은 방식으로 다른 숫자를 만들 수 있다. 대신 통제 대상의 규모(경로별 처리 건수), 대체 수단의 비용(예: 외부 파일을 수작업으로 검토하는 데 드는 인력), 감사 대응 산출물을 나란히 놓는 편이 검증 가능한 논리가 된다.

마지막으로, 단계를 건너뛰었을 때 나타나는 전형적인 결과를 정리한다. 각 패턴 옆에 어느 단계에서 막을 수 있었는지 적었다. CDR 도입 가이드의 5단계를 거꾸로 읽는 방법이기도 하다.

이 패턴들은 기술 문제라기보다 프로젝트 관리 문제다. 엔진을 바꿔도 같은 패턴은 반복된다. 반대로 단계별 산출물이 갖춰져 있으면, 제품을 바꾸거나 경로를 추가할 때도 같은 문서를 다시 쓸 수 있다.