NEW 시큐레터 CDR 백서 발행 — MARS 분석 + CDR 무해화, N2SF 시대의 콘텐츠 보안 표준 답안 백서 다운로드 →

파일 무해화(Disarm) 원리 —
OOXML·HWP·PDF byte 단위 분해부터 재조립까지

판정이 아니라 분해다. ISO/IEC 29500 OOXML의 vbaProject.bin, ISO 32000 PDF의 /JavaScript·/OpenAction, HWP 5.0 OLE 복합 문서, HWPX ZIP의 BinData까지 — CDR이 309종 포맷을 어떤 규칙으로 분해하고 무엇을 제거한 뒤 어떻게 재조립하는지 스펙 수준에서 정리한다.

DISARM PIPELINE · STRUCTURAL DECOMPOSITION · 309 FORMATS INPUT FILE OOXML·HWP·PDF·RTF vbaProject.bin /JavaScript /OpenAction OLE Object externalLink DDE Field BinData/ Text Body Images Tables ① PARSE TREE 스펙 기반 해부 (실행 없음) Document Root Content Active Active-element catalog VBA · XLM · JS · OLE · DDE LNK · externalLink · RichMedia /Launch · /AA · EmbeddedFile ISO 29500 · 32000 · 26300 스펙 기반 구조 정합성 검증 ② DISARM 유형 기반 절제 · 판정 없음 ✓ 텍스트 · 표 · 이미지 ✓ 서식 · 레이아웃 ✓ 메타데이터 (정규화) ✗ vbaProject.bin ✗ /JavaScript · /OpenAction ✗ OLE · DDE · RichMedia ✗ externalLink · /Launch ✗ LNK · Embedded EXE ✗ RTF \objdata · \objclass False-positive = 0 (판정 없음) ③ REBUILD 포맷 정규 재조립 SAFE FILE 편집성 유지 레이아웃·스펙 준수 ⚡ SLCDR · 309 formats · 평균 34ms · KISA 100% 정합 · TTA GS 12.027s · Gartner 2025 40 vendors ISO/IEC 27001 Annex A.8.24 Information Sanitization — 판정 없는 구조적 방어

CDR은 판정하지 않는다. "이 파일이 악성인가"를 묻는 대신 "스펙상 실행 가능 영역이 어디인가"만 묻는다. 답은 ISO/IEC 29500(OOXML), ISO 32000(PDF), ISO/IEC 26300(ODF), 한컴 HWP 5.0 규격서에 이미 적혀 있다. 스펙이 vbaProject.bin·/JavaScript·/OpenAction·\objdata를 "실행 가능"으로 정의해 두었으므로 CDR은 그 바이트 범위를 정확히 제거한 뒤 스펙이 정의한 방식 그대로 재조립한다. 이 글은 OOXML의 /word/vbaProject.bin, PDF의 /RichMedia, HWP 5.0의 BodyText 스트림, HWPX의 Contents/section*.xml, RTF의 \objdata까지 — CDR이 309종 포맷을 어떤 규칙으로 해부하고 무엇을 삭제한 뒤 어떻게 재조립하는지 바이트 수준에서 설명한다.

34ms
SLCDR 평균 무해화 시간
DISARM Solution Intro[1]
309
지원 파일 포맷
Ensecure v2 at a Glance[2]
100%
KISA 악성 탐지 정합
구조 기반 분해[2]
40
Gartner 2025 CDR 벤더
Market Guide 확인[3]

1 Lead — 판정이 아니라 분해다

기존 보안은 "악성이냐 아니냐"의 이진 판정에서 출발한다. 시그니처는 알려진 해시를 찾고, 샌드박스는 실행 행위를 관찰하며, AI는 특징 벡터를 분류한다. 이 모든 접근은 "판단이 정확해야" 작동하며, 판단이 틀리면 제로데이가 통과하고 오탐이 업무를 막는다. CDR은 질문을 바꾼다 — "이 파일의 스펙 상 실행 가능 영역이 어디인가?" ISO/IEC 29500이 OOXML의 VBA 경로를, ISO 32000-2 §12.6.3이 PDF의 /OpenAction 엔트리를, Microsoft RTF 1.9.1이 \objdata 컨트롤 워드 문법을 명시한다. 답은 스펙 문서에 이미 인쇄되어 있다.

💡 Gartner의 CDR 정의 (Market Guide 2022·2023·2025 일관)

"CDR rebuilds files using only the known-good components of the original, sanitizing any active content and removing high-risk objects without relying on detection." — 핵심은 "without relying on detection". 탐지하지 않는다는 것이 CDR의 정의 요건이다[3].

ISO/IEC 27001:2022 Annex A.8.10·A.8.24·A.8.28 맥락에서 "information sanitization"은 외부 유입 콘텐츠의 구조적 위험을 제거하는 통제로 자리잡았다[4]. NIST SP 800-83 Rev.1도 "pre-processing of email attachments by removing active content"를 권고한다[5]. CDR은 이 권고의 구체 구현이다.

2 OOXML (ISO/IEC 29500) 해부 — vbaProject.bin · externalLink · customXml

OOXML은 ZIP 아카이브 + XML 파트 + 관계(Relationships)의 삼층 구조다[6]. .docx·.xlsx·.pptxunzip으로 풀면 바로 내부 구조가 드러난다.

ZIP 내부 디렉터리 구조

document.docx/
├── [Content_Types].xml        ← MIME 매핑, 타입 위조 탐지 지점
├── _rels/.rels                ← 루트 관계 (Target=외부 URL 벡터)
├── word/
│   ├── document.xml           ← 본문 (보존)
│   ├── vbaProject.bin         ← ⚠️ VBA 매크로 CFBF
│   ├── _rels/document.xml.rels ← ⚠️ externalLink · oleObject Target
│   ├── embeddings/            ← ⚠️ OLE 객체
│   ├── media/                 ← 이미지 (보존)
│   └── customXml/             ← ⚠️ Custom XML (APT 은닉)
└── docProps/                  ← 메타 (정규화)
OOXML 영역스펙 조항CDR 처리
word/vbaProject.binISO/IEC 29500-1 §13.3.17삭제 · [Content_Types].xml에서 application/vnd.ms-office.vbaProject 엔트리 제거 · .rels에서 관계 삭제
word/vbaData.xmlISO/IEC 29500-1 §17.5삭제 (매크로 UI 요소)
xl/externalLinks/ISO/IEC 29500-1 §18.14삭제 (원격 SMB·HTTP 자동 조회 벡터)
word/embeddings/*.binISO/IEC 29500-2 §11.3OLE CFBF 복호화 → 내부 파일 타입 확인 → 실행형이면 삭제, 문서형이면 재귀 무해화
customXml/item*.xmlISO/IEC 29500-1 §23기본 제거 (APT 그룹의 payload 은닉 경로)
word/_rels/*.rels TargetECMA-376 §11.2TargetMode="External" 관계 검사 · Follina류 ms-msdt: URI 차단
word/drawing/* OLEISO/IEC 29500-4Equation Editor(CVE-2017-11882) · 임베디드 OLE 식별 후 삭제
DDE 필드 w:fldCharISO/IEC 29500-1 §17.16DDEAUTO·DDE instrText 제거
⚠️ Follina (CVE-2022-30190) 사례

Follina는 word/_rels/document.xml.relsTarget="ms-msdt:..." 외부 관계로 MSDT를 호출하는 공격이었다[7]. CDR은 TargetMode="External" 관계를 열거·검증하며 ms-msdt:·javascript:·file: 비표준 스킴을 패치 KB5014699 이전에도 구조적으로 제거한다.

3 HWP 5.0 — Compound Document Format 스트림 해부

HWP 5.0은 MS-CFB(Compound File Binary Format) 기반 OLE 복합 문서다[8]. 내부는 파일 시스템처럼 Storage·Stream 계층이며, 한컴 HWP 5.0 파일 형식 규격서가 모든 스트림을 정의한다[9].

HWP 5.0 주요 Storage / Stream

Storage · Stream역할CDR 처리
FileHeader시그니처 "HWP Document File" + 버전 + 암호화 플래그검증 · 플래그 정규화
DocInfo문서 속성 · 서식 · 글꼴 · ID 매핑보존 (정규화)
BodyText/Section0..N본문 문단·표·그림 레코드보존 (Tag ID별 파싱)
BinData/BIN*.OLE⚠️ 임베디드 OLE 객체삭제 또는 재귀 무해화
BinData/BIN*.EPS⚠️ EPS PostScript (CVE-2017-8291 Ghostscript류)삭제
Scripts/DefaultJScript⚠️ 문서 스크립트삭제
PrvImage · PrvText미리보기 이미지·텍스트재생성
DocOptions/_LinkDoc외부 링크 문서 참조검증 · 외부 URL 제거
BodyText 레코드 태그HWPTAG_PARA_* · HWPTAG_CTRL_* 등 Tag ID 기반 바이너리 레코드화이트리스트 Tag ID만 재구성

HWP 5.0 규격은 BodyText 레코드를 "Tag ID(10 bit) + Level(10 bit) + Size(12 bit)" 헤더로 정의한다[9]. CDR은 HWPTAG 화이트리스트(약 80여 개)만 재조립하므로 규격 외 커스텀 태그 · 크기 필드 불일치(CVE-2015-6585류 타입 혼동)는 재조립 단계에서 구조적으로 제거된다.

💡 HWP의 CFBF 특성이 주는 이점

OLE 복합 문서는 각 스트림이 독립된 바이트 영역이다. BodyText를 건드리지 않고 BinData/ Storage만 드롭해도 문서는 유효하게 재조립된다. Storage 단위 삭제 가능 구조 덕에 CDR의 손실률이 구조적으로 낮다.

4 HWPX — OOXML 스타일 ZIP 구조

HWPX는 KS X 6101로 표준화한 OWPML(Open Word Processor Markup Language) 기반 포맷이다[10]. HWP 5.0의 바이너리 레코드를 XML로 재표현한 것으로 외형은 OOXML과 유사하다.

HWPX ZIP 내부

document.hwpx/
├── mimetype                    ← "application/hwp+zip"
├── META-INF/manifest.xml       ← 파트 매니페스트
├── Contents/
│   ├── header.xml              ← 문서 속성
│   ├── content.hpf             ← OPF 스타일 패키지
│   └── section0.xml ~ N.xml    ← 본문 (보존)
├── BinData/                    ← ⚠️ EPS/OLE 벡터
├── Scripts/                    ← ⚠️ 스크립트 제거
└── Preview/                    ← 미리보기 재생성

CDR은 mimetype 매직 검증 → manifest.xml 파트 열거 → section*.xml을 XSD 스키마로 검증하며 파싱한다. 화이트리스트 외 네임스페이스, BinData/의 실행형 리소스, Scripts/ 전체를 제거 후 ZIP 재패킹.

5 PDF (ISO 32000) — 객체 트리와 액션 엔트리

PDF는 간접 객체(indirect object) 그래프[11]. Document Catalog를 루트로 Page Tree·Outline·AcroForm이 분기하며 각 객체는 /Name 키-값 딕셔너리. 공격 벡터는 모두 특정 /Name 키에 있으므로 스펙이 공격 영역을 이미 명시한다.

PDF 실행 가능 엔트리 전수

PDF 엔트리ISO 32000-2 조항위협 · CDR 처리
/JavaScript · /JS§12.6.4.17Acrobat JS 엔진 실행 · 삭제
/OpenAction§12.6.3문서 열람 시 자동 실행 · 삭제
/AA (Additional Actions)§12.6.3페이지 열기·커서 이동·포커스 등 16종 트리거 · 삭제
/Launch§12.6.4.5외부 애플리케이션 실행 · 삭제
/URI§12.6.4.7URL 열기 · 검증 (스킴 화이트리스트)
/SubmitForm · /ImportData§12.7.5폼 자동 제출·데이터 주입 · 삭제
/GoToR · /GoToE§12.6.4.3원격 · 임베디드 문서 이동 · 삭제
/EmbeddedFile · /Filespec§7.11내장 파일 · 재귀 무해화 또는 삭제
/RichMedia§13.6Flash·3D·비디오 · 삭제
/XFA§12.7.7XML Forms Architecture · 삭제 (Adobe 2020 단종)
/NeedsRendering + XFA§7.7.2XFA 전용 렌더러 유도 · 제거
/3D§13.6.33D 스트림 (CVE-2018-4990류) · 삭제

Object Stream(/ObjStm)과 XRef Stream은 PDF 1.5 이후 압축 구조로 악성 객체 은닉에 악용된다. CDR은 모든 객체를 uncompressed로 전개한 뒤 액션 엔트리 제거, qpdf --object-streams=disable 수준의 정규화로 재직렬화한다[12].

⚠️ PDF "재구성" vs "필터링"의 차이

단순 /JavaScript 문자열 치환 제품은 /Name 객체의 hex 인코딩(/#4Aa#76aScript), object stream 은닉, 순환 참조를 회피하지 못한다. 진정한 CDR은 파서로 객체 그래프를 재구성한 뒤 의미론적으로 제거하고 재직렬화한다.

6 RTF — Control Word 기반 공격 벡터

RTF는 Microsoft가 1987년 발표한 평문 마크업 포맷이다. \control 워드로 제어되며 이진 객체는 \objdata 뒤에 hex 인코딩으로 임베드된다[13]. 단순한 외형과 달리 가장 악용이 많은 포맷 중 하나다.

RTF 주요 공격 control word

  • \objdata · \objclass · \objemb — 임베디드 OLE (Equation Editor CVE-2017-11882[14])
  • \objupdate · \objautlink — 자동 업데이트 · 자동 링크 트리거
  • \fonttbl 비정상 크기 — CVE-2023-21716 Heap Corruption[15]
  • \pict + \wmetafile8 — WMF/EMF 벡터 (CVE-2015-2545류)
  • \*\template · \*\datastore — Remote Template Injection
  • \field + INCLUDEPICTURE·DDEAUTO — 외부 리소스 자동 조회

CDR은 RTF 파서를 토큰 스트림 기반으로 재구성한다. 텍스트·문단 속성·글꼴 테이블은 유지하고 \objdata·\objclass·\objupdate·\*\template·\field 내 DDE 지시자·\pict의 WMF/EMF 위험 하위 타입을 제거 후 RTF 1.9 규격으로 재직렬화한다. \bin 길이 필드 조작(CVE-2023-21716 벡터)은 재직렬화 시점에 실제 데이터와 길이가 강제 일치되어 무효화된다.

7 이미지 — 메타데이터 · 스테가노그래피 제거

이미지는 문서에 비해 공격 표면이 좁지만 메타데이터 청크와 폴리글랏(Polyglot)이 주요 벡터다[16].

포맷공격 영역CDR 처리
PNGtEXt·iTXt·zTXt 메타 청크 · IDAT 스테가노그래피보조 청크 제거 후 재인코딩 (libpng 표준)
JPEGEXIF(APP1) · XMP · APP0~APP15 마커 · ICC 프로파일 오버플로우APP 마커 정규화 · 재인코딩
GIFApplication Extension · Comment Extension확장 블록 제거 · 재인코딩
SVG<script> · on* 이벤트 · href="javascript:" · <foreignObject>DOMPurify 수준 스크립트·이벤트 제거
TIFFIFD 필드 오버플로우 · 포인터 조작재인코딩
폴리글랏JPEG+ZIP, PNG+JAR 공존 파일시그니처·푸터 위치 검증 · 초과 데이터 절단

원칙은 "픽셀 디코딩 → 메타데이터 제거 → 표준 인코더로 재인코딩". LSB 수준 스테가노그래피는 시각적 차이 없이 재인코딩 과정에서 대부분 파괴된다.

8 Archive — 재귀 처리와 ZIP Bomb 방어

압축 파일은 컨테이너다 — 내부 파일을 모두 재귀 무해화하면서 압축 자체의 구조적 공격도 방어해야 한다.

  • 재귀 깊이 제한 — 기본 6~10단계. 42.zip류는 깊이 초과 시 drop[17]
  • 압축 해제율 임계 — 해제/압축 비율 1,000:1 초과 시 bomb 판정 → 격리
  • 경로 검증 — Zip-Slip(../) · 절대경로 · 심볼릭 링크 거부[18]
  • 타입 정합성 — 확장자와 매직 넘버 불일치 시 실제 타입 기준 무해화
  • 암호화 압축 — 정책에 따라 격리 또는 사용자 제공 패스워드 요구
  • 포맷 커버리지 — ZIP · RAR · 7Z · TAR · GZ · BZ2 · XZ · ALZ · ISO · CAB (ACE 기본 드롭)

9 Disarm 5단계 파이프라인 — Parse · Identify · Remove · Reconstruct · Validate

포맷별 해부를 하나의 파이프라인으로 정리하면 5단계를 모든 포맷에 동일하게 적용한다.

단계작업실패 처리
① Parse매직 넘버·시그니처 검증 · 스펙 기반 구조 트리 생성파싱 실패 = 유효하지 않은 구조 → 격리
② IdentifyActive element 카탈로그와 대조 · 각 노드에 "keep / sanitize / remove" 태깅미지 요소 = 보수적으로 remove
③ Remove · Sanitizeremove 태그 노드 드롭 · sanitize 노드는 속성 정규화-
④ Reconstruct스펙 준수 serializer로 재직렬화 · 관계·목차·상호참조 갱신직렬화 실패 시 원본 차단 + 관리자 알림
⑤ Validate재조립 결과를 스펙 검증기(XSD·PDF 검증·CFBF 체크)로 확인검증 실패 = 출력 거부

핵심은 ②와 ③이 "판정"이 아니라 "카탈로그 조회"라는 점이다. 카탈로그는 스펙과 CVE 이력에서 도출된 고정 목록이며 주관적 판단이 개입하지 않는다. 오탐의 구조적 제거가 여기서 나온다.

10 Reconstruction 원칙 — 시각 보존 · 편집성 유지 · 레이아웃 무결

Gartner 정의의 핵심 — "rebuilds files using only the known-good components of the original"[3]. 이 rebuild 품질이 CDR 제품의 실질 차별점이다.

  1. 시각 동등성 — 원본과 구별 불가. 텍스트·표·이미지·글꼴·여백·페이지 수 일치
  2. 편집성 보존 — 동일 포맷 재조립(DOCX→DOCX). 래스터화는 "file-type conversion"
  3. 레이아웃 무결 — 목차·상호참조·주석·책갈피 타깃 ID 유효
  4. 스펙 준수 — 포맷 검증기(Office validator · veraPDF · HWP Viewer) 통과
✅ 재조립 실패 시 설계 원칙

재조립이 스펙 검증을 통과하지 못하면 원본을 통과시키지 않는다. 차단하고 관리자에게 알리며 원본 해시·제거 시도 객체·실패 사유를 감사 증적으로 기록한다.

11 비교 매트릭스 — CDR vs File-type Conversion vs Sanitizer vs AV/Sandbox

"실행 콘텐츠를 제거한다"는 목표에 도달하는 방법은 여럿이며 각 접근의 trade-off가 다르다.

방식원리강점한계
CDR스펙 기반 파싱 → 요소 제거 → 스펙 기반 재조립 (동일 포맷)편집성 유지 · 제로데이 무관 · 오탐 0포맷별 스펙 구현 비용 · 재조립 품질은 벤더 의존
File-type ConversionDOCX→PDF, PDF→이미지 래스터화구현 단순 · 공격 표면 축소편집성 상실 · OCR 필요 · 업무 영향 큼
XML Sanitizer (DOMPurify류)HTML/XML 노드 필터웹 콘텐츠 적합OOXML의 바이너리 파트(CFBF·OLE) 처리 불가
AV Signature해시·패턴 매칭알려진 멀웨어 빠른 탐지변종·제로데이 미탐 · 판정 의존
Dynamic SandboxVM에서 실제 실행 관찰행위 기반 탐지반VM·시간지연·사용자상호작용 우회 · 파일리스 우회 · 처리시간 분 단위
Static ML Classifier바이트·특징 벡터 분류대량 스크리닝Adversarial 샘플 취약 · 오탐·미탐 동시 존재

실무에서는 CDR이 1차 게이트, 격리·블록된 파일에 대해 MARS 리버스엔지니어링 정적 분석이 2차 심층 분석을 담당하는 계층 구성이 일반적이다. 샌드박스·AV는 엔드포인트 보조.

12 실제 CVE 케이스 — 패치 이전에도 무해화로 차단된 사례

CDR의 실전 가치는 "패치 공백기 방어"다. 다음 CVE들은 CDR 제거 규칙에 자동 포함된 요소를 악용했다.

CVE벡터CDR 차단 규칙
CVE-2017-11882Equation Editor OLE (eqnedt32.exe, RTF \objdata)[14]RTF \objdata·\objclass 제거 → 패치(KB4011604) 이전에도 방어
CVE-2022-30190 (Follina)OOXML _rels/ Target="ms-msdt:"[7]TargetMode=External 비표준 스킴 제거 → 패치(KB5014699) 이전 방어
CVE-2023-21716RTF \fonttbl heap corruption[15]RTF 재직렬화 시 길이 필드 강제 정합 → 트리거 무효화
CVE-2021-40444 (MSHTML)OOXML OLE + CAB 경로 조작OLE 객체 · 외부 CAB 관계 제거
CVE-2018-4990PDF /JBIG2Decode + /JavaScript[19]/JavaScript 엔트리 삭제 → 익스플로잇 체인 중단
CVE-2025-29867Hancom Office 全라인 타입 혼동[20]HWPTAG 화이트리스트 재조립 → 비정상 태그 구조 제거
CVE-2017-8291EPS/Ghostscript (HWP BinData/BIN*.EPS)EPS 스트림 드롭
CVE-2015-6585HWPX para text 태그 타입 혼동[20]OWPML XSD 검증 + 태그 정규화

CVE 패치는 며칠~수개월이 걸린다. 그 공백 동안 유형 기반 제거는 CVE·패치 번호를 모르는 채 동일 원리로 방어한다. Gartner가 CDR을 "proactive · deterministic"으로 분류한 이유다[3].

13 309 포맷 family breakdown

SLCDR이 지원하는 309종 포맷[2]을 family별로 정리한다.

Family대표 포맷무해화 전략
OOXML / OPCDOCX · XLSX · PPTX · DOCM · VSDXZIP 재패킹 + Part Relationships 검증
Legacy Office (CFBF)DOC · XLS · PPT · MSGCFBF Storage 열거 · VBA/OLE 제거
한컴HWP 5.0 · HWPX · HWTStorage 드롭 + HWPTAG 화이트리스트
PDFPDF 1.3~2.0 · PDF/A객체 그래프 재구성 + 액션 제거
ODF (ISO 26300)ODT · ODS · ODPBasic/ 매크로 제거[21]
RTFRTF 1.5~1.9control word 토큰 재구성
이메일 컨테이너EML · MSG · MBOX · PST재귀 무해화 (본문+첨부)
ArchiveZIP · RAR · 7Z · ALZ · CAB · ISO재귀 해제 + 무해화 + 재압축
이미지PNG · JPG · GIF · TIFF · SVG메타 제거 + 재인코딩
CAD · 미디어 · 웹DWG · MP4 · HTML · CSV엔티티 파싱 · 메타 정규화 · 스크립트 제거

TTA GS 인증 기준 SLCDR의 대용량 복합 포맷 배치 처리 시간은 12.027초, 경량 문서 평균 무해화 시간은 34ms[1][2].

14 False-positive가 0인 이유 — "판정 없음"의 구조적 귀결

AV·샌드박스·ML은 모두 "악성 확률"을 판정한다. 임계 위=차단, 아래=통과. 임계 조정은 FP-FN trade-off다. FP=0 임계는 FN이 높고, FN=0 임계는 업무를 막는다. CDR은 임계 자체가 없다. 판정하지 않기 때문이다. 규칙은 결정론적 "스펙상 이 영역은 실행 가능하므로 제거"이며 확률이 개입하지 않는다. 정상 문서에서 매크로가 제거되는 것은 "오탐"이 아니라 "정책상 설계된 절제"다. 업무상 필요하면 서명 매크로 유지·경로 예외로 명시적 복원한다.

💡 "오탐 0"의 정확한 의미

CDR의 FP=0은 "멀쩡한 문서를 악성으로 판정해 차단하는 일이 없다"는 뜻. 문서는 항상 통과한다. 단, 내부 실행 가능 요소가 정책에 따라 제거된다. 이 절제는 오탐이 아니라 설계된 행동이며, SLA 100% 운영의 구조적 근거다.

15 시큐레터 제품 통합 — SLF · SLE · SLCDR · ConTI

시큐레터는 4개 제품으로 콘텐츠 보안을 구성한다.

제품배치 지점CDR 역할
SLF (파일 보안)파일 서버 · 업로드 게이트 · 망연계모든 유입 파일을 무해화하여 스토리지·내부망에 전달
SLE (이메일 보안, DISARM 통합)MX 앞단 · SMTP 릴레이첨부·본문 HTML 구조적 절제 후 전달
SLCDR (웹 콘텐츠 CDR)웹 업로드·다운로드 경로 · API 게이트웨이실시간 34ms 처리로 사용자 UX 유지
ConTI (위협 인텔리전스)4 제품 공통 후단제거된 active element의 해시·IoC·공격 캠페인 매핑 축적

4 제품은 동일 MARS 리버스엔지니어링 엔진 위에서 작동한다. CDR이 1차 절제, MARS가 2차 비실행 정적 분석을 담당하고 ConTI가 양쪽에서 추출된 구조 피처를 인텔리전스 자산으로 축적한다.

16 자주 묻는 질문 (FAQ)

Q1. 무해화된 파일은 원본과 완전히 같은가요?
바이너리는 다르지만 사용자가 열면 동일한 텍스트·표·이미지·서식을 본다. Gartner CDR 정의가 "known-good components 기반 재조립"을 필수 요건으로 규정한다[3]. 차이는 매크로·스크립트·OLE·DDE 등 실행 요소가 빠졌다는 점이다.
Q2. 편집 가능한 문서로 돌아오나요, 이미지로 바뀌나요?
CDR은 동일 포맷으로 재조립한다. DOCX→DOCX, PDF→PDF, HWP→HWP. 이미지로 래스터화하는 것은 "file-type conversion"이며 CDR과 별개다. 편집성 보존이 CDR 정의 요건이다.
Q3. 업무상 필요한 매크로가 있으면?
정책 기반 예외 처리. ① 서명된 매크로 화이트리스트, ② 도메인·송신자 예외, ③ 파일 경로 예외. 기본은 "전량 제거"이며 PoC 단계에서 업무 요건을 반영해 예외를 설계한다.
Q4. CDR이 제로데이를 막는다는 말은 정확한가요?
정확하다. 단, 제로데이가 CDR이 제거하는 유형(매크로·스크립트·OLE·외부링크 등)을 벡터로 쓰는 경우에 한한다. Follina·Equation Editor·CVE-2023-21716은 패치 이전에도 차단됐다. 포맷 렌더러 자체의 메모리 손상은 CDR 범위 밖이며 OS·앱 패치가 필요하다.
Q5. ISO/IEC 27001 개정판과의 연결?
ISO/IEC 27001:2022 Annex A.8.10·A.8.24·A.8.28의 "information sanitization" 맥락에서 외부 유입 콘텐츠의 활성 요소 제거가 권고된다[4]. NIST SP 800-83 Rev.1도 이메일 첨부 전처리를 권고한다[5]. CDR이 그 구체 구현이다.
Q6. 파일 타입 변환(PDF→이미지)이 대안이 되지 못하는 이유?
① 편집성 상실, ② OCR 왜곡으로 텍스트 검색 깨짐, ③ 메타데이터 소실. 특정 고위험 채널(망연계 등)에서 변환이 전략적으로 쓰이지만 일반 업무에서는 CDR이 적절하다.
Q7. Gartner Market Guide 2025의 CDR 시장 평가?
2025 Market Guide는 40여 개 벤더를 식별했다[3]. 이메일·파일 전송·웹·API 복합 배치가 표준이 되었고, OT·망연계·공공 채택이 가속 중이다.
Q8. 309종 포맷의 실무적 의미?
OOXML·PDF는 대부분 벤더가 처리하지만 HWP·HWPX·ALZ, 레거시(DOC·XLS·PPT·MSG), CAD(DWG·STEP), 이메일 컨테이너(PST·MBOX)까지 스펙 수준으로 구현한 벤더는 제한적이다. 309는 "공공·금융·제조의 실제 업무 포맷이 누락 없이 커버된다"의 지표다[2].

결론 — 스펙을 읽는 자가 구조를 이긴다

CDR이 작동하는 이유는 단순하다. 공격자가 악용하는 실행 가능 영역이 스펙 문서에 명시되어 있기 때문이다. ISO/IEC 29500이 vbaProject.bin을, ISO 32000이 /OpenAction을, RTF 1.9.1이 \objdata를, KS X 6101이 BinData/를 정의한다. 스펙대로 읽어 해당 바이트를 제거한 뒤 스펙대로 재직렬화하면, CVE 번호를 몰라도 Follina를 막고 패치 KB를 기다리지 않아도 Equation Editor를 차단한다.

판정 기반 보안은 "영리해져야" 한다. 시그니처를 늘리고 샌드박스 회피 탐지를 추가하고 ML을 재훈련한다. 매 라운드마다 공격자가 앞선다. CDR은 영리해질 필요가 없다. 스펙은 공격자가 바꿀 수 없다. 그래서 34ms 안에 결정론적으로 작동하고, 309종 포맷에서 동일 원리로 유효하며, 아직 발견되지 않은 CVE에도 같은 규칙으로 방어한다. Gartner 2025 Market Guide가 40여 개 벤더를 집계할 만큼 시장은 성숙했다. 남은 질문은 "어떤 CDR이 우리 포맷·업무·규제 맥락에 맞는가"다. PoC와 BMT에서 확인해야 할 것은 간단하다 — 귀사가 실제로 쓰는 파일을 실제 업무 시스템에서 작동시키는지. SLCDR은 그 검증의 기준점이 되고자 한다.

귀사 업무 파일로 CDR 품질을 검증하세요

실제 HWP·HWPX·DOCX·PDF·ALZ·MSG 샘플로 무해화 전후 비교 보고서를 제공합니다. 재조립 품질 · 34ms SLA · 감사 증적 · 정책 예외 설계까지 BMT 전 과정 지원.

SLCDR PoC 신청 → 공공 · 금융 · 제조 · 망연계 맞춤
REFERENCES
  1. SecuLetter Inc., DISARM Solution Introduction KO, 2025.06.13 (SLCDR 평균 무해화 시간 00:00.034 근거).
  2. SecuLetter Inc., Ensecure v2 — SecuLetter at a Glance, 2025.12.17 (309 file formats · KISA 100% · TTA GS 12.027s 근거).
  3. Gartner, Market Guide for Content Disarm and Reconstruction, 2022·2023·2025 — gartner.com.
  4. ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection — Information security management systems — Requirements, Annex A controls A.8.10 · A.8.24 · A.8.28 — iso.org/standard/27001.
  5. NIST, SP 800-83 Rev.1 — Guide to Malware Incident Prevention and Handling for Desktops and Laptopscsrc.nist.gov.
  6. ISO/IEC 29500:2016, Office Open XML File Formats — Part 1: Fundamentals and Markup Language Reference (ECMA-376) — iso.org/29500. Microsoft Open Specifications: learn.microsoft.com/ms-docx.
  7. MITRE, CVE-2022-30190 (Follina) — Microsoft Support Diagnostic Toolnvd.nist.gov/CVE-2022-30190. MSRC guidance: msrc.microsoft.com.
  8. Microsoft, [MS-CFB] Compound File Binary File Formatlearn.microsoft.com/ms-cfb.
  9. Hancom, HWP 5.0 파일 형식 (HWP Document File Format) 규격서hancom.com/hwpDownload.
  10. KS X 6101, 정보기술 — 개방형 워드 프로세서 마크업 언어(OWPML) (HWPX 표준) — standard.go.kr/KSX6101.
  11. ISO 32000-2:2020, Document management — Portable document format — Part 2: PDF 2.0iso.org/32000-2. Adobe PDF Reference archives: opensource.adobe.com.
  12. qpdf, Content-preserving PDF transformation toolqpdf.sourceforge.io. veraPDF PDF/A validator: verapdf.org.
  13. Microsoft, Rich Text Format (RTF) Specification, version 1.9.1, 2008 — interoperability.blob.core.windows.net.
  14. MITRE, CVE-2017-11882 — Microsoft Office Memory Corruption (Equation Editor)nvd.nist.gov/CVE-2017-11882. Microsoft Security Update: msrc.microsoft.com.
  15. MITRE, CVE-2023-21716 — Microsoft Word Remote Code Execution (RTF Heap Corruption)nvd.nist.gov/CVE-2023-21716.
  16. W3C, Portable Network Graphics (PNG) Specification (tEXt/iTXt/zTXt chunks) — w3.org/TR/png. JPEG/EXIF: CIPA DC-008 — cipa.jp.
  17. CERT/CC, VU#162289 Zip file format (zip bomb / 42.zip) resource exhaustionkb.cert.org.
  18. Snyk Research Team, Zip Slip Vulnerability Disclosure, 2018 — security.snyk.io/zip-slip.
  19. MITRE, CVE-2018-4990 — Adobe Acrobat Reader Out-of-Bounds Readnvd.nist.gov/CVE-2018-4990.
  20. SentinelOne / NVD, CVE-2025-29867 Hancom Office Type Confusion (全라인), 2026.2 — sentinelone.com/cve-2025-29867. CVE-2015-6585 HWPX: nvd.nist.gov/CVE-2015-6585.
  21. ISO/IEC 26300-1:2015, Open Document Format for Office Applications (OpenDocument) v1.2iso.org/26300. OASIS: docs.oasis-open.org.
  22. MITRE ATT&CK, T1137 · T1204.002 · T1566.001 · T1027attack.mitre.org/T1137.
  23. NIST, SP 800-88 Rev.1 Guidelines for Media Sanitizationcsrc.nist.gov.
  24. Microsoft, Macros from the internet are blocked by default in Office, 2022 — learn.microsoft.com.
  25. CERT/CC, VU#421280 — MS Office DDE command executionkb.cert.org.
  26. SecuLetter, MARS Platform — File Security Technologyseculetter.com.

기술 심화 실무 검토가 필요하신가요?

시큐레터 보안연구팀이 현재 환경을 함께 검토합니다. 기밀 유지 보장, 비용 없음.

PoC 신청