파일 보안 솔루션 선택 기준 —
BMT에서 확인할 8가지 검증 항목

파일 보안 솔루션 선택은 제안서의 숫자가 아니라 우리 조직의 파일로 치른 BMT 결과로 결정해야 한다. 같은 '탐지율'과 '처리 속도'라도 어떤 샘플을, 어떤 부하에서, 어떤 판정 기준으로 쟀는지에 따라 의미가 달라진다. 제안서의 숫자는 공급사가 정한 조건에서 나온 값이고, 운영 환경의 숫자는 우리 파일과 우리 트래픽이 정한다. 이 글은 공공·금융·엔터프라이즈 보안 담당자가 BMT를 직접 설계할 수 있도록 샘플 세트 구성법, 8가지 검증 항목별 시험 방법과 판정 기준, 채점 방식, 자주 빠지는 함정을 정리한다. 설명은 공개 표준과 위협 분류 체계를 기준으로 한다.

파일 보안 제품을 비교하는 자리에서 가장 먼저 오가는 것은 숫자다. 지원 포맷 수, 탐지율, 처리 시간, 인증 목록이 그렇다. 이 숫자들은 모두 의미가 있지만 측정 조건이 붙어 있다. 어떤 샘플 집합으로 쟀는지, 단일 요청인지 동시 요청인지, 평균인지 최댓값인지, 탐지만 했는지 무해화까지 했는지에 따라 같은 숫자도 다른 사실을 말한다.

운영 환경과 제안서 수치 사이에는 보통 세 가지 간격이 생긴다. 첫째는 샘플 간격이다. 공급사가 준비한 샘플은 그 제품이 잘 다루는 포맷에 치우치기 쉽고, 우리 조직에 실제로 들어오는 파일 분포와 다르다. 둘째는 환경 간격이다. 메일 서버, 망연계 구간, 웹 업로드 서버의 부하와 파일 크기 분포는 조직마다 다르다. 셋째는 판정 간격이다. "막았다"의 정의가 탐지 경보인지, 격리인지, 능동 요소가 제거된 결과물 전달인지 합의하지 않으면 비교표의 칸이 같은 것을 가리키지 않는다.

NIST의 보안 시험 가이드는 시험을 실행하기 전에 범위, 방법, 규칙, 성공 기준을 계획 단계에서 정하도록 권고한다^[4]. BMT도 같다. 시험을 먼저 돌리고 결과를 해석하면, 해석은 결과가 좋게 나온 제품 쪽으로 기운다. 판정 기준과 합격선을 먼저 문서로 고정해야 BMT가 비교 도구로 작동한다.

BMT 일정을 잡기 전에 세 가지를 먼저 정한다. 유입 경로 지도, 판정 기준과 합격선, 역할 분담이다. 이 세 가지가 없으면 시험 항목이 공급사 제안 순서를 따라가게 되고, 결과표는 각 제품의 강점 목록이 된다.

유입 경로 지도는 파일이 조직 안으로 들어오는 모든 지점과 그 경로의 파일 분포를 적은 표다. 외부 메일 첨부, 내부 메일 첨부, 망연계 자료 전송, 대민·대고객 웹 업로드, 협력사 파일 교환, 이동식 매체 반입이 대표적이다. 경로마다 최근 일정 기간의 포맷 비율, 파일 크기 분포, 피크 시간대 건수를 함께 적는다. 공개 위협 분류 체계는 첨부파일 기반 피싱을 별도의 초기 침투 기법으로 정의한다^[5]. 이런 분류는 어떤 경로를 지도에 빠짐없이 넣어야 하는지 알려 주는 출발점이 된다. 다만 우리 조직에서 어느 경로가 가장 무거운지는 일반론이 아니라 우리 로그가 말하므로, 경로별 비중은 반드시 자체 수치로 채운다.

판정 기준과 합격선은 항목별로 "무엇을 재고, 어떤 값이면 통과인가"를 정하는 일이다. 예를 들어 "무해화 결과물에 매크로 저장 영역이 남아 있지 않을 것", "피크 부하에서 p99 지연이 정해 둔 상한 이하일 것", "업무 담당자 판정에서 사용 불가 문서가 일정 비율 이하일 것"처럼 쓴다. 필수 항목과 가점 항목을 구분해 두면 채점 단계의 논쟁이 줄어든다.

역할 분담은 보안팀만으로 BMT를 치르지 않기 위한 장치다. 결과 문서의 품질은 그 문서를 매일 쓰는 업무 담당자가 판정해야 하고, 연동과 장애 시험은 메일·네트워크 담당자가 함께해야 한다.

샘플 세트는 네 묶음으로 나눈다. 묶음마다 확인하려는 성질이 다르기 때문에, 하나의 '탐지율' 숫자로 합치지 않고 묶음별로 따로 집계한다.

묶음 A는 가장 자주 생략되지만 가장 중요하다. 보안 제품이 정상 업무 파일을 망가뜨리면 사용자는 우회 경로를 찾고, 그 순간 보안 통제 전체가 약해진다. 정상 파일 비중을 충분히 두어야 오탐과 품질 문제가 통계적으로 드러난다. 업무 파일 사본을 쓸 때는 이름, 연락처, 계좌 정보 같은 개인정보와 영업 기밀을 먼저 지우거나 가린다.

묶음 B는 기본 능력과 경보 흐름을 확인하는 용도다. 악성 샘플 수를 늘리는 것보다, 우리 경로에 실제로 들어올 법한 포맷과 기법이 고르게 섞였는지가 중요하다. 경보·로그 파이프라인만 점검할 때는 업계 표준 시험 파일을 쓸 수 있다^[16]. 단, 이 시험 파일은 문서 속 능동 요소를 대표하지 않으므로 무해화 능력 평가에는 쓰지 않는다.

묶음 C는 이 글에서 가장 권하는 묶음이다. 악성 여부와 상관없이 "능동 요소가 결과물에 남는가"를 확인할 수 있고, 실제 악성코드를 다루지 않아도 된다. 같은 파일에 능동 요소를 하나씩 넣은 변형을 만들면 어떤 요소에서 차이가 나는지 정확히 짚을 수 있다.

묶음 D는 파서의 견고성과 예외 처리 정책을 본다. 처리하지 못하는 파일을 그냥 통과시키는지, 격리하는지, 관리자에게 알리는지가 여기서 드러난다.

첫 번째 항목은 제품이 파일을 확장자가 아니라 실제 구조로 판별하는가다. 공격자는 확장자를 바꾸는 것만으로 일부 필터를 지나간다. RTF 파일을 .doc 로 보내거나, 매크로 포함 형식을 일반 문서 확장자로 바꾸는 방식이 그 예다.

OOXML 계열은 확장자와 MIME 타입이 매크로 포함 여부를 구분한다. 일반 Word 문서는 application/vnd.openxmlformats-officedocument.wordprocessingml.document, 매크로 포함 Word 문서는 application/vnd.ms-word.document.macroEnabled.12 다. OOXML의 패키지 구조와 관계 정의는 ECMA-376 표준에 공개되어 있다^[6]. BMT에서는 선언된 확장자·MIME과 실제 내부 구조가 다른 파일을 넣고, 제품이 실제 구조 기준으로 처리하는지 확인한다.

두 번째로 볼 것은 중첩 구조다. 압축 파일 안의 문서, 문서 안에 삽입된 다른 문서, 그 안의 개체처럼 여러 겹으로 싸인 파일을 몇 단계까지 해석하는지, 한도를 넘으면 어떻게 처리하는지 시험한다. PDF도 첨부 파일과 삽입 스트림을 가질 수 있으며, 그 구조는 ISO 32000-2에 정의되어 있다^[7].

세 번째는 암호화 파일이다. 비밀번호가 걸린 압축 파일이나 문서는 열지 않고는 내용을 검사할 수 없다. 공격자가 검사 회피를 위해 파일을 암호화하거나 난독화하는 것은 공개 위협 분류 체계에도 정리된 기법이다^[8]. 제품이 차단, 격리, 사용자 비밀번호 입력 후 검사 중 어떤 선택지를 주는지, 그 선택을 경로별로 다르게 둘 수 있는지 확인한다.

마지막으로 국내 환경에서는 HWP와 HWPX를 반드시 포함한다. 공공·금융 경로에서 한글 문서 비중이 높다면, 한글 문서의 버전별 변형과 삽입 개체를 별도 하위 묶음으로 구성한다.

시큐레터 공식 자료는 309개 파일 포맷 지원을 제시한다^[1]. 다만 BMT에서 물을 질문은 "몇 종인가"가 아니라 "우리 유입 상위 포맷과 그 변형이 모두 지원 범위 안에 있는가"다. 이 질문은 어느 후보에게나 똑같이 적용한다.

CDR 방식은 일반적으로 파일을 포맷 사양에 따라 해석해 능동 요소를 찾아내고, 정책상 허용하지 않는 요소를 걷어낸 뒤 파일을 다시 만든다. 사용자에게 전달되는 것은 원본 바이트가 아니라 다시 만들어진 파일이다. 이 점이 탐지 방식과 평가 기준을 갈라놓는다. 탐지 결과는 "통과·차단"으로 끝나지만, 무해화 결과물은 업무 담당자가 실제로 열어 쓰는 문서이므로 원본과 업무상 같은 문서로 쓰일 수 있는지가 핵심 평가 항목이 된다.

품질은 보안팀이 아니라 그 문서를 매일 쓰는 사람이 판정해야 한다. 원본과 결과물을 같은 뷰어에서 나란히 열고 다음을 확인한다.

전자서명은 따로 다룬다. 서명은 서명 당시의 바이트를 근거로 검증되므로, 내용을 다시 쓴 파일에서는 원래 서명이 유효하지 않게 되는 것이 일반적이다. 이것은 특정 제품의 결함이 아니라 재생성 방식의 성질이다. 서명 검증이 업무에 필요한 경로라면 원본을 안전하게 보관하고 검증 절차를 별도로 두는 정책을 함께 설계해야 하며, BMT에서는 그 정책을 제품이 지원하는지 본다.

판정은 문서별로 "그대로 사용 가능 / 경미한 차이 / 업무 지장 / 사용 불가" 같은 등급으로 기록한다. 소프트웨어 품질 모델이 기능 적합성과 사용성을 별도 특성으로 나누듯^[9], "위협 요소가 제거되었는가"와 "업무에 쓸 수 있는가"는 별개의 축으로 채점한다.

처리 시간은 평균 하나로 보지 않는다. 평균이 짧아도 일부 대용량 파일이나 복잡한 구조의 파일에서 긴 지연이 생기면, 사용자는 그 몇 건 때문에 메일이 늦게 온다고 느낀다. BMT에서는 평균, 중앙값, p95, p99, 최댓값을 함께 기록하고 파일 크기 구간별로 나누어 본다.

측정 지점도 정해야 한다. 엔진 내부 처리 시간만 재면 큐 대기, 네트워크 전송, 연동 모듈의 시간이 빠진다. 사용자가 체감하는 값은 메일 수신 시각에서 사서함 도착 시각까지, 업로드 요청에서 응답까지처럼 경로 끝에서 끝까지 잰 시간이다. 두 값을 모두 기록하면 지연이 어디서 생기는지 분리할 수 있다.

부하 조건은 유입 경로 지도의 피크 시간대를 재현한다. 평상시 건수로만 시험하면 큐 적체가 드러나지 않는다. 피크 부하의 일정 배수까지 단계적으로 올리면서 지연 곡선이 어디서 꺾이는지 확인하고, 그 지점이 우리 피크와 얼마나 떨어져 있는지 여유율로 기록한다.

처리량 시험에서는 처리 실패율도 함께 본다. 부하가 높아질 때 처리 실패나 시간 초과가 늘어나는지, 그때 파일이 어떤 상태로 처리되는지(통과·보류·격리)는 8번 항목인 장애 동작과 연결된다.

파일 보안 제품은 크게 판정하는 방식과 무해화하는 방식으로 나눌 수 있고, 둘은 잘하는 일이 다르다. 공정한 BMT를 위해 각 방식이 할 수 있는 일부터 정리한다.

탐지 기반 솔루션은 알려진 위협을 빠르고 정확하게 판정한다. 시그니처와 휴리스틱, 평판 정보를 함께 쓰면 알려진 악성 파일의 변형도 상당 부분 잡아내고, 판정 결과와 지표를 남겨 사고 대응과 위협 헌팅에 쓸 수 있게 한다. 샌드박스 기반 솔루션은 파일을 실제로 실행해 행위를 관찰하므로, 시그니처가 없는 위협도 행위로 판정할 수 있고 상세 분석 보고서를 남긴다.

동시에 공격자도 이 방식들을 알고 있다. 실행 환경이 가상 환경인지 확인한 뒤 동작을 멈추거나 실행을 지연하는 기법은 공개 위협 분류 체계에 별도 기법으로 정리되어 있다^[10]. 문서가 열릴 때 외부 서버의 템플릿을 불러오도록 하는 기법도 있다^[11]. 이 경우 분석 시점에 원격 자원이 비어 있으면 관찰할 행위가 없고, 공격자는 나중에 원격 자원을 바꿔 넣을 수 있다.

CDR 방식은 일반적으로 악성 여부를 판정하는 데 의존하지 않고, 정책상 허용하지 않는 능동 요소를 결과물에서 빼는 데 초점을 둔다. 그래서 BMT 질문이 달라진다. "악성으로 판정했는가"가 아니라 "능동 요소가 결과물에 남았는가"를 본다. 대신 CDR 결과물만으로는 그 파일이 악성이었는지, 누가 어떤 의도로 보냈는지 알 수 없으므로, 판정 정보가 필요한 조직은 탐지 결과와 무해화 결과를 함께 남기는 설계를 검토한다.

시험은 3장의 묶음 C로 한다. 자체 제작한 능동 콘텐츠 파일을 넣고 결과물을 직접 열어 구조를 확인한다.

판정 기반 후보에는 같은 샘플을 넣고 "경보를 냈는가"와 "파일이 사용자에게 도달했는가"를 함께 기록한다. 자체 제작 샘플은 무해하므로 판정 기반 제품이 통과시키는 것이 오히려 정상 동작일 수 있다. 그래서 이 묶음의 결과는 '탐지 실패'로 채점하지 않고, 능동 요소가 사용자에게 도달했는지라는 사실로만 기록한다. 이 구분을 지켜야 서로 다른 방식의 제품을 공정하게 비교할 수 있다.

모든 경로에 같은 정책을 걸 수 있는 조직은 드물다. 재무 부서는 매크로가 들어간 정산 양식을 써야 하고, 법무 부서는 서명 문서 원본이 필요하며, 대민 업로드 경로는 가장 엄격해야 한다. 그래서 BMT에서는 정책을 얼마나 잘게 나눌 수 있는지와 예외를 얼마나 통제된 방식으로 허용하는지를 본다.

확인할 정책 단위는 경로, 부서·사용자 그룹, 발신 도메인, 파일 유형, 능동 요소 종류다. 예를 들어 "외부 메일 첨부의 매크로는 제거하되, 특정 협력사 도메인에서 재무 그룹으로 오는 스프레드시트는 원본 요청 승인 절차를 거쳐 받을 수 있다" 같은 정책을 실제로 설정해 보고, 설정한 대로 동작하는지 묶음 A·C로 확인한다.

원본 요청 흐름도 시험한다. 사용자가 무해화 결과물이 아닌 원본을 요청할 때 누가 승인하는지, 승인 전 원본에 대한 추가 검사가 있는지, 원본 전달 기록이 남는지, 승인에 걸리는 시간이 업무에 수용 가능한지를 본다.

운영체제와 오피스의 내장 통제와 겹치는 영역도 정리한다. 예를 들어 Office는 인터넷에서 받은 파일의 VBA 매크로를 기본으로 차단한다^[12]. 다만 이 동작은 파일에 인터넷 출처 표시가 붙어 있는지, 지원되는 Office 버전과 애플리케이션인지, 신뢰할 수 있는 위치나 조직 정책 예외가 있는지에 따라 달라진다. 출처 표시는 파일을 받는 방식과 압축 해제 도구의 종류·버전에 따라 전달되지 않을 수도 있다. 따라서 BMT에서는 "내장 통제가 이미 막는 경우"와 "내장 통제가 적용되지 않는 경로"를 나누어 시험하고, 후보 제품이 후자를 어떻게 다루는지 확인한다.

보안 사고 조사와 감사에서 묻는 것은 "그때 무엇이 들어왔고, 무엇을 했는가"다. 파일 보안 제품의 로그가 이 질문에 답하지 못하면 차단을 했어도 증명할 수 없다. BMT에서는 시험 중 생성된 로그를 내보내 다음 항목이 남는지 확인한다.

로그를 외부로 보내는 방식도 본다. 통합 보안 관제 시스템이 받을 수 있는 형식으로 내보내는지, 필드가 일관된지, 대량 처리 중에도 로그 누락이 없는지 확인한다. 원본 파일 보관 기간과 접근 권한 설정도 함께 시험한다.

로그 자체의 개인정보 처리도 확인 대상이다. 파일명, 메일 주소, 사용자 계정은 개인정보를 포함할 수 있다. 로그 필드 마스킹, 보존 기간 설정, 열람 권한 분리가 가능한지 확인하고, 조직의 개인정보 처리 기준에 맞춰 설정할 수 있는지 본다.

공공기관이라면 국가 망 보안체계(N2SF)도 고려한다. N2SF는 정보와 시스템을 등급으로 나누고 등급에 맞는 보안 통제를 적용하는 체계이며, 등급이 다른 영역 사이로 자료가 이동하는 지점의 통제를 어떻게 설계할지가 중요한 과제가 된다^[14]. 실제 기관의 적용 사례는 KISA가 실증 사례집으로 정리했다^[15]. BMT에서는 제품의 로그와 정책 기록이 기관이 정한 통제 항목의 이행 근거로 쓰일 수 있는지를 감사 담당자와 함께 검토한다. 구체적 통제 항목과의 대응은 기관의 등급 분류와 적용 범위에 따라 달라지므로 일반화하지 않는다.

파일 보안 솔루션 선택에서 연동은 문서로 확인되는 항목이 아니다. "지원한다"는 답변과 "우리 구성에서 붙는다"는 사실은 다르다. BMT에서는 유입 경로 지도의 주요 경로마다 실제 구성과 같은 격리 환경을 꾸리고 연동을 시험한다.

다단계 구성의 처리 순서도 확인한다. 예를 들어 기존 백신 검사와 무해화를 모두 거치는 경로에서는 어느 쪽을 먼저 두느냐에 따라 로그 의미와 지연이 달라진다. 암호화 파일이 어느 지점에서 풀리는지, 같은 파일이 두 번 처리되는 중복은 없는지 시험 기록으로 남긴다.

시큐레터 제품은 구간과 메일 운영 형태에 따라 나뉘고, 제품마다 탐지와 무해화 구성이 다르다. 망연계·웹게시판 구간은 구축형 파일 보안 제품인 SLF가 맡으며, MARS 탐지와 CDR을 기본 탑재한다. 메일은 운영 형태에 따라 제품이 다르다. 구축형 메일 서버에는 SLE가 붙으며 MARS 탐지와 CDR을 기본 탑재하고 스팸·악성·피싱·BEC 등 이메일 공격 전반을 막는다. MS 365·Gmail 같은 SaaS 메일에는 SLE와 별개 제품인 DISARM이 쓰이며, CDR과 BEC 탐지를 제공하고 APT 탐지는 포함하지 않는다. 네이버·카카오·하이웍스 등 국내 메일 서비스용 SaaS인 SLES는 APT 탐지를 제공하고 CDR은 포함하지 않는다. CDR만 필요한 구축형 환경에는 CDR 전용 제품인 SLCDR이 있으며, 탐지는 백신·YARA·TI로 한다. 이처럼 같은 회사 제품이라도 담긴 기능이 다르므로, BMT에서는 경로마다 실제로 배치할 제품으로 시험하고 그 제품에 탐지·무해화 중 무엇이 들어 있는지를 시험표에 먼저 적어 둔다. 어느 공급사든 경로별 제품이 따로 있다면 정책·로그가 제품 사이에서 일관되게 관리되는지까지 확인한다.

파일 보안 제품은 업무 경로 한가운데에 놓인다. 제품이 멈추면 메일, 자료 전송, 업로드가 함께 멈추거나, 반대로 검사 없이 통과된다. 어느 쪽을 택할지는 경로마다 다르게 정해야 하고, BMT에서는 그 선택이 설정대로 동작하는지 직접 확인한다.

장애 시 기본 동작은 두 가지로 나뉜다. 검사 없이 통과시키는 방식은 업무 연속성을 지키지만 그 시간 동안 통제가 사라진다. 대기·보류시키는 방식은 통제를 지키지만 업무가 멈춘다. 대민 업로드나 망연계처럼 위험도가 높은 경로는 보류를, 내부 메일처럼 대체 통제가 있는 경로는 다른 선택을 할 수 있다. 경로별로 이 선택을 따로 설정할 수 있는지 확인한다.

장애 주입 시험은 격리 시험망에서만 한다. 처리 엔진 프로세스 중지, 연동 구간 네트워크 단절, 저장 공간 부족, 처리 시간 초과를 하나씩 일으키고 다음을 기록한다.

• 장애 동안 들어온 파일이 설정한 기본 동작대로 처리되었는가
• 관리자에게 알림이 갔고, 알림 내용으로 원인을 짐작할 수 있는가
• 복구 후 적체된 파일이 재처리되었고, 중복 처리나 누락은 없는가
• 장애 구간 처리 내역이 로그로 남았는가

업데이트와 롤백도 운영성의 핵심이다. 포맷 해석기와 정책 엔진은 새로운 포맷 변형과 기법에 맞춰 갱신되어야 한다. 업데이트가 서비스 중단 없이 적용되는지, 문제가 생기면 이전 버전으로 되돌릴 수 있는지, 업데이트 내역이 공개되는지 확인한다.

마지막으로 관리 화면을 실제 운영자가 써 본다. 오탐 신고 처리, 원본 요청 승인, 정책 변경 이력 조회, 특정 파일 처리 내역 검색을 실제 업무처럼 수행하고 걸린 시간과 단계 수를 기록한다. 운영자가 매일 반복하는 작업이 번거로우면 정책은 점점 느슨해진다.

8개 항목을 같은 무게로 더하면 조직의 사정이 반영되지 않는다. 가중치는 유입 경로 지도와 조직 유형에서 나온다. 아래 표는 하나의 예시이며, 실제 가중치는 BMT 전 2단계에서 문서로 확정한다.

가중치와 별개로 탈락 조건을 둔다. 탈락 조건에 걸리면 다른 항목 점수가 높아도 후보에서 제외한다. 예시는 다음과 같다.

• 미지원·처리 실패 파일을 알림 없이 통과시킨다
• 묶음 C의 능동 요소가 결과물에 남은 채 사용자에게 도달한다(무해화 방식 후보의 경우)
• 묶음 A에서 업무 담당자가 '사용 불가'로 판정한 문서가 합격선을 넘는다
• 장애 시 기본 동작이 설정과 다르게 작동한다
• 처리 내역 로그가 누락되거나 외부로 내보낼 수 없다

점수는 항목별 원점수와 가중 점수를 모두 남긴다. 의사결정 회의에서 가중치를 바꾸자는 의견이 나오면, 원점수를 그대로 둔 채 가중치만 다시 적용해 결과가 어떻게 달라지는지 보여 줄 수 있다.

이 밖에도 OOXML 문서만으로 시험하고 HWP·PDF·압축 파일을 빠뜨리는 경우, 단일 파일로만 지연을 재고 동시 요청을 빼는 경우, BMT 기간에만 공급사 엔지니어가 상주해 운영 난이도가 가려지는 경우가 있다. 마지막 경우를 피하려면 BMT 후반부의 정책 변경과 오탐 처리를 조직의 운영자가 직접 수행하게 한다.

파일 보안 솔루션 선택이 끝난 뒤에도 BMT 자료는 버리지 않는다. 샘플 세트와 측정 스크립트, 채점표는 운영 중 정기 점검과 차기 갱신 평가에서 그대로 기준선이 된다.

"공인 인증을 받은 제품이면 BMT를 생략해도 되지 않는가." 공인 인증은 정해진 시험 조건에서 제품의 능력을 제3자가 확인했다는 뜻이고, 후보군을 좁히는 데 유효한 근거다. 시큐레터도 KISA 인증(2020)에서 악성코드 탐지율 100%를, TTA GS 인증에서 분석 시간 12초(실측 12.027초)를 확인받았다^[1]. 다만 인증 시험의 샘플과 환경은 우리 조직의 유입 분포·연동 구성·정책과 같지 않다. 인증은 "이 제품이 이런 능력을 갖췄다"를 말하고, BMT는 "이 제품이 우리 환경에서 그 능력을 발휘한다"를 확인한다. 두 근거는 서로를 대체하지 않는다.

"CDR을 도입하면 기존 탐지 제품은 필요 없는가." 그렇지 않다. 7장에서 정리했듯 탐지 기반과 샌드박스 기반 방식은 판정 정보와 분석 보고서를 남기고, 이는 사고 대응과 위협 헌팅에 쓰인다. CDR은 판정이 어려운 문서 속 능동 요소를 결과물에서 빼는 데 강점이 있다. 두 방식은 서로 다른 질문에 답하므로, BMT의 목적은 하나를 고르는 것이 아니라 경로별로 어떤 조합이 맞는지를 정하는 데 둔다.

"BMT에 드는 시간과 인력이 부담된다." 범위를 줄일 수는 있다. 유입 경로 지도에서 위험과 물량이 가장 큰 경로 하나를 먼저 시험하고, 나머지 경로는 도입 후 단계적으로 확대하는 방식이다. 다만 필수 항목인 포맷 판별, 문서 품질, 장애 동작은 줄이지 않는다. 포맷 판별의 빈틈은 검사되지 않는 파일 유형으로, 문서 품질 문제는 사용자의 우회 경로로, 장애 동작의 오류는 검사 없이 통과된 구간으로 이어진다. 세 가지 모두 운영 중에 드러나면 정책과 연동 구성을 다시 설계해야 하므로, 도입 전에 확인하는 편이 되돌리는 부담이 적다.

"샘플을 아무리 준비해도 실제 위협을 모두 대표할 수는 없다." 맞다. 그래서 샘플 세트의 목표는 모든 위협의 재현이 아니라 구조적 성질의 확인이다. 묶음 C처럼 능동 요소 종류별로 나눈 샘플은, 개별 악성코드가 바뀌어도 그 요소가 처리되는 방식이 바뀌지 않는지를 확인하게 해 준다.

시큐레터 제품은 탐지와 무해화를 함께 쓰는 구조를 기본으로 하되, 10장에서 정리했듯 제품마다 담긴 기능이 다르다. SLF와 SLE에는 MARS 탐지 엔진과 CDR이 기본 탑재되어 있다. MARS는 자동화된 리버스 엔지니어링 기반의 악성코드 탐지 엔진이다^[3]. 문서를 어셈블리 수준까지 분해해, 악성 행위가 일어나기 전에 취약점의 근원을 찾아내는 방식이다. 7장에서 본 가상환경 회피, 시간차 공격, 사용자 행위 조건 같은 우회 기법은 행위 기반(샌드박스) 방식이 놓치기 쉬운 공격인데, MARS는 이를 근본 원인 분석으로 잡는다. 탐지 범위는 문서에 그치지 않아서, 문서·이미지·압축 파일은 리버스 엔지니어링으로, 실행 파일은 백신·YARA·평판 분석으로 탐지한다. 어떤 탐지도 모든 위협을 잡을 수는 없으므로, 탐지가 놓친 것은 CDR 무해화가 막도록 둘을 함께 쓴다.

SLCDR은 CDR 전용 제품이라 리버스 엔지니어링 기반 탐지가 없고, 탐지는 백신·YARA·TI로 한다. 따라서 SLCDR을 시험할 때는 묶음 B의 판정 결과를 SLF·SLE와 같은 칸에 넣지 않고, 무해화 결과와 백신·평판 판정을 나눠 기록한다. 이 글의 8개 항목은 시큐레터 제품에도 그대로 적용되며, 후보에 넣는다면 다음처럼 대응시켜 시험을 설계할 수 있다.

시큐레터는 Gartner CDR Market Guide(2022)에서 글로벌 대표 벤더 40곳 가운데 유일한 한국 기업으로 소개되었다^[1]. 이런 외부 평가와 앞서 언급한 공인 인증은 후보군을 정하는 근거가 되지만, 최종 판단은 이 글의 방식대로 조직이 직접 설계한 BMT 결과에 두기를 권한다.