MITRE ATT&CK을 탐지 목록이 아니라 빈틈 지도처럼 쓰는 법

핵심 요약

ATT&CK 매트릭스의 색칠 비율은 탐지 능력을 증명하지 않는다. 중요한 것은 우리 자산에 현실적인 공격 경로를 고르고, 필요한 로그가 실제 수집되는지, 분석 규칙이 시험됐는지, 경보 후 대응 절차와 소유자가 있는지를 기법별로 연결해 빈틈을 우선순위화하는 것이다.

MITRE ATT&CK을 도입한 조직이 가장 먼저 만드는 산출물은 대개 색칠된 매트릭스다. SIEM 규칙에 technique ID를 붙이고 녹색 셀을 늘리면 진척이 눈에 보인다. 하지만 같은 기법에 규칙이 열 개 있어도 필요한 로그가 빠지거나, 공격을 재현했을 때 경보가 울리지 않거나, 경보를 받은 분석가가 무엇을 해야 할지 모르면 실질 커버리지는 없다.

ATT&CK은 제품 점수표가 아니라 공격자 행동을 대화하기 위한 지식 기반이다. ATT&CK Navigator도 방어 커버리지와 레드·블루팀 계획을 시각화하는 도구이지, 녹색 셀의 개수를 보안 성숙도로 환산하는 도구가 아니다. 따라서 “몇 퍼센트를 커버하는가”보다 어떤 중요한 경로가 보이지 않는가를 질문해야 한다.

커버리지의 단위를 technique에서 운영 능력으로 바꾼다

기법 하나를 탐지한다고 말하려면 최소 여섯 요소가 필요하다.

요소	확인 질문	증거
위협 관련성	우리 자산과 위협 행위자에게 현실적인가	위협 모델, 사고·CTI 근거
데이터 가용성	필요한 로그와 필드가 수집되는가	데이터 소스·필드 목록
센서 건강도	누락·지연·파서 오류를 알 수 있는가	수집 SLO와 상태 경보
분석 로직	행위를 구분하는 규칙이 구현됐는가	쿼리, 버전, 테스트 케이스
검증	실제 또는 모의 행위로 경보를 확인했는가	테스트 실행 결과와 날짜
대응	경보를 누가 조사하고 무엇을 차단하는가	runbook, 소유자, SLA

이 중 하나라도 없으면 상태를 “탐지 완료”로 표시하지 않는다. 예를 들어 endpoint process 로그는 있지만 명령행 인자가 비어 있다면 일부 PowerShell·셸 행위를 구분할 수 없다. 규칙은 있어도 마지막 테스트가 1년 전이라면 에이전트나 스키마 변경 후 깨졌을 가능성이 있다.

MITRE는 ATT&CK의 방어 콘텐츠를 계속 개편한다. 2025년 10월 공개된 ATT&CK v18에서는 technique 페이지의 기존 detection 내용을 Detection Strategies와 Analytics 중심으로 재구성하고, 기존 Data Sources 객체를 deprecated 처리했다.

Detection Strategies는 탐지하려는 행동 개념을, Analytics는 플랫폼별 구현 논리를 표현한다. 2026년 4월에는 v19가 공개됐으므로 조직 내부 매핑은 사용 중인 ATT&CK 버전과 객체 ID를 고정하고, 업그레이드 때 변경 영향을 추적해야 한다.

우선순위는 자산과 공격 경로에서 시작한다

모든 technique을 동일하게 다루면 인력이 분산된다. 다음 순서로 범위를 좁힌다.

중요 업무와 자산을 고른다. IdP, 고객 데이터 저장소, CI/CD, 클라우드 control plane처럼 침해 시 피해가 큰 시스템을 먼저 선정한다.
현실적인 초기 접근을 정한다. 피싱, 공개 서비스 취약점, 유출 자격증명, 공급망 등 조직에 해당하는 경로를 고른다.
목표까지의 행동 사슬을 만든다. 권한 상승, 자격증명 접근, 횡적 이동, 수집, 유출 또는 영향 단계로 이어 본다.
현재 보이는 지점을 표시한다. 로그가 있는 곳, 탐지가 있는 곳, 테스트된 곳을 구분한다.
한 단계만 놓치면 전체 경로가 보이지 않는 지점을 우선 보완한다.

예를 들어 클라우드 관리자 계정 탈취가 핵심 위험이라면 endpoint persistence 셀을 광범위하게 채우기보다 IdP 로그인, MFA 변경, 신규 OAuth 앱, cloud role 추가, audit log 비활성화, 대량 데이터 접근을 연결하는 것이 먼저다.

상태를 한 가지 색으로 표현하지 않는다

다음과 같이 다차원 상태를 두면 과장된 커버리지를 줄일 수 있다.

0 = 범위 밖이거나 아직 평가하지 않음
1 = 필요한 데이터가 없음
2 = 데이터는 있으나 분석 규칙이 없음
3 = 규칙은 있으나 공격 재현으로 검증하지 않음
4 = 검증 완료, 대응 runbook과 소유자 있음
X = 예외 또는 수용된 잔여 위험, 만료일 필요

Navigator layer에는 점수 외에도 데이터 소스, 규칙 ID, 마지막 검증일, 담당 팀, 환경을 메모한다. 단, 점수를 합산해 “전체 78%”처럼 단일 수치로 보고하면 중요도가 다른 기법이 동일하게 계산된다. 경영 보고에는 핵심 공격 경로별로 완전히 관찰 가능한 경로 수, 검증되지 않은 고위험 단계, 데이터 공백의 예상 피해를 보여주는 편이 낫다.

데이터 소스부터 거꾸로 확인한다

MITRE ATT&CK 데이터 구성요소는 어떤 객체와 행위를 관찰해야 하는지 정리하는 데 도움이 된다. 그러나 “Windows Event Log 수집”처럼 제품 수준으로 적으면 실제 탐지 가능성을 알 수 없다. 다음 필드까지 내려가야 한다.

이벤트를 만든 주체와 대상 identity
process image, parent, command line, hash
source/destination IP, port, protocol, direction
cloud API action, resource, account, region, user agent
authentication result, MFA method, device, session ID
object read/write/delete와 이전·이후 값
event time, ingest time, parser version

각 필드의 null 비율과 지연을 감시한다. 공격 탐지 규칙보다 먼저 “오늘 endpoint 로그가 30% 줄었는가”, “클라우드 리전 하나가 빠졌는가”, “파서 업데이트 뒤 필드명이 바뀌었는가”를 알아야 한다.

검증은 규칙 생성과 분리하지 않는다

탐지 규칙은 PR처럼 버전 관리하고, 최소한 다음 테스트를 붙인다.

정상 행위가 과도하게 경보를 만들지 않는지 확인하는 양성·음성 샘플
technique을 안전하게 재현하는 모의 행위
기대 데이터와 필드가 수집됐는지 확인하는 assertion
경보가 올바른 자산·사용자·심각도로 생성되는지 확인
runbook 링크와 담당 queue가 실제 연결되는지 확인
suppression과 allowlist가 공격 변형을 가리지 않는지 확인

퍼플팀 훈련에서는 “공격 성공”보다 관찰 지점을 기록한다. 어떤 단계에서 로그가 없었는지, 어떤 필드가 비어 있었는지, 경보가 너무 늦었는지, 분석가가 추가 조회 권한을 갖고 있었는지를 남긴다. 결과는 매트릭스 색상뿐 아니라 센서·파서·규칙·runbook backlog로 전환한다.

자주 실패하는 방식

모든 SIEM 규칙에 ATT&CK ID를 붙이면 끝난다

한 규칙이 여러 행위를 포괄하거나 같은 technique을 수십 개 규칙이 중복할 수 있다. ID 태깅은 검색성을 높이지만 검증 증거가 아니다.

technique 수가 많은 제품을 선택한다

벤더가 주장하는 매핑은 데이터 품질, 환경 설정, 라이선스, 튜닝 상태를 반영하지 않을 수 있다. 실제 조직 로그로 테스트한 결과만 내부 커버리지로 인정한다.

침해 사례를 그대로 복사한다

유명 공격 그룹의 전체 technique을 가져오면 우리 환경에 없는 플랫폼과 자산이 섞인다. 위협 인텔리전스는 우선순위 입력 중 하나이며, 자산 중요도와 노출도를 함께 봐야 한다.

예방 통제를 탐지로 계산한다

MFA나 application allowlisting은 중요하지만, 우회 또는 실패를 관찰할 신호가 별도로 필요하다. 예방, 탐지, 대응을 다른 열로 관리한다.

ATT&CK 버전 변경을 추적하지 않는다

technique 분할·통합·폐기와 탐지 객체 개편이 내부 대시보드를 깨뜨릴 수 있다. 버전 업그레이드 시 mapping diff와 규칙 영향 검토를 수행한다.

탐지 파이프라인 자체의 위험 신호

데이터 소스별 이벤트 수 급감 또는 갑작스러운 증가
필수 필드 null 비율과 파서 오류 상승
수집 지연이 조사 허용 시간을 넘음
규칙 비활성화, suppression 확대, 임계값 변경
고위험 규칙의 마지막 검증일 초과
경보가 티켓으로 전환되지 않거나 소유 queue가 없음
반복 오탐 때문에 분석가가 자동 종료하는 비율 증가
동일 공격 테스트가 환경별로 다른 결과를 냄
ATT&CK 업데이트 후 orphan mapping 증가

90일 개선 계획

1~30일: 범위를 줄인다

중요 자산 3~5개와 핵심 공격 경로를 선정한다.
현재 규칙과 로그를 technique이 아니라 자산·데이터 소스 기준으로 목록화한다.
검증 이력이 없는 녹색 셀을 별도 상태로 되돌린다.

31~60일: 데이터 공백을 메운다

핵심 경로에서 가장 큰 로그 공백 3개를 해결한다.
수집 SLO, 필드 완전성, 파서 상태 경보를 만든다.
상위 탐지 규칙에 테스트 케이스와 owner를 붙인다.

61~90일: 공격 사슬을 검증한다

안전한 퍼플팀 시나리오를 실행한다.
탐지부터 triage, containment까지 시간을 측정한다.
결과를 다음 분기 센서·규칙·자동화 투자로 연결한다.

랜섬웨어 시나리오는 백업 불변성과 복구 검증, 취약점 악용 경로는 CISA KEV 패치 triage, 클라우드·함수형 환경은 서버리스 보안과 연결하면 ATT&CK 지도를 실제 운영 과제로 바꾸기 쉽다.

최종 판단

좋은 ATT&CK 지도는 녹색이 많은 지도가 아니다. 조직에 중요한 공격 경로에서 “어디까지 보이고, 어디서 끊기며, 누가 그 빈틈을 고칠 것인지”를 설명하는 지도다. 데이터 존재, 규칙 구현, 공격 검증, 대응 절차를 분리해 표시하면 ATT&CK은 장식용 매트릭스가 아니라 탐지 투자와 훈련 순서를 정하는 운영 도구가 된다.