방어 통제 점검표는 “보안 솔루션이 있다”는 사실을 적는 문서가 아닙니다. 어떤 위협 행동을 어떤 기능으로 줄이고, 그 기능이 어떤 조건에서 작동하며, 운영자가 어떤 증거로 확인할 수 있는지를 정리해야 합니다. D3FEND 관점의 점검표는 통제 존재 여부를 기능, 범위, 증거, 한계, 책임, 검증 주기로 바꾸는 문서입니다.
MITRE D3FEND는 사이버보안 방어 대책 기법의 지식 그래프입니다. ATT&CK가 공격자 전술과 기법을 이해하는 데 도움을 준다면, D3FEND는 방어 기술 기능과 대응 개념을 더 구조적으로 생각하게 해 줍니다. 다만 D3FEND는 특정 제품이나 방어책의 효과를 보장하는 정답표가 아닙니다. 조직은 D3FEND를 출발점으로 삼고, 자산, 로그, 운영 역량, 책임 체계에 맞게 점검표를 구체화해야 합니다.
D3FEND 점검표의 목적
D3FEND 관점의 방어 통제 점검표는 통제가 “있는가”보다 “작동하는가”를 묻기 위한 도구입니다. 예를 들어 “EDR 있음”이라고 쓰는 대신, 어떤 자산에 설치되어 있고, 어떤 행위를 탐지하며, 어떤 로그를 남기고, 누가 경보를 확인하고, 어떤 상황에서 실패할 수 있는지 적어야 합니다.
점검표의 목적은 다음과 같습니다.
- 방어 통제가 어떤 공격자 행동을 줄이는지 설명한다.
- 예방, 탐지, 분석, 대응, 복구 기능을 구분한다.
- 통제가 작동했다는 증거를 확인한다.
- 예외 자산과 미관리 영역을 드러낸다.
- 통제의 한계와 실패 조건을 기록한다.
- 운영 책임자와 재검토 주기를 정한다.
이렇게 작성해야 점검표가 감사용 체크박스가 아니라 보안 운영 개선 도구가 됩니다.
ATT&CK와 연결해 방어 목적을 정한다
D3FEND 점검표는 ATT&CK와 연결할 때 더 명확해집니다. ATT&CK 기법은 공격자 행동을 설명하고, D3FEND는 그 행동을 줄이기 위해 어떤 방어 기능을 생각할 수 있는지 돕습니다.
예를 들어 특정 공격자 행동을 줄이고 싶다면 다음 질문으로 시작합니다.
| 질문 | 의미 |
|---|---|
| 어떤 ATT&CK 전술이나 기법과 관련 있는가? | 방어 통제의 목적을 공격자 행동과 연결합니다. |
| 이 행동이 우리 환경에서 가능한가? | 자산, 계정, 네트워크, 클라우드 범위를 확인합니다. |
| 어떤 D3FEND 기능으로 줄일 수 있는가? | 예방, 탐지, 분석, 격리, 복구 관점을 나눕니다. |
| 통제가 작동했다는 증거는 무엇인가? | 로그, 알림, 테스트 결과, 훈련 기록을 확인합니다. |
이 과정을 거치면 “방화벽 있음”, “EDR 있음” 같은 표현이 “어떤 행동을 줄이는 어떤 기능이 어떤 범위에서 작동한다”는 설명으로 바뀝니다.
통제 기능을 분류한다
방어 통제는 하나의 기능만 갖지 않을 수 있습니다. 어떤 통제는 예방에 가깝고, 어떤 통제는 탐지에 가깝고, 어떤 통제는 대응과 복구에 더 가깝습니다. D3FEND 관점에서는 이 기능을 나누어 기록하는 것이 중요합니다.
| 기능 영역 | 점검 질문 |
|---|---|
| 예방 | 공격자 행동이 발생하기 어렵게 만드는가? |
| 탐지 | 의심 행동이 발생했을 때 알 수 있는가? |
| 분석 | 경보의 의미와 영향 범위를 판단할 증거가 있는가? |
| 대응 | 계정 잠금, 격리, 차단 같은 조치를 실행할 수 있는가? |
| 복구 | 정상 상태로 되돌리고 재발을 줄일 수 있는가? |
| 검증 | 훈련이나 테스트로 통제가 작동하는지 확인했는가? |
이 구분은 통제의 한계를 드러냅니다. 예를 들어 MFA는 계정 침해 위험을 줄이는 예방 통제에 가깝지만, 이미 탈취된 세션을 탐지하거나 복구하는 기능까지 자동으로 제공하지는 않습니다. 따라서 MFA가 있다고 해서 탐지와 대응 점검이 필요 없어지는 것은 아닙니다.
점검표에 들어갈 항목
실무 점검표에는 최소한 다음 항목이 들어가야 합니다.
| 항목 | 작성 내용 |
|---|---|
| 통제 이름 | 제품명보다 기능 중심으로 적습니다. |
| 관련 ATT&CK 행동 | 줄이려는 공격자 전술이나 기법을 적습니다. |
| D3FEND 기능 | 예방, 탐지, 분석, 대응, 복구, 검증 중 어디에 해당하는지 적습니다. |
| 적용 범위 | 자산, 계정, 네트워크, 클라우드, 애플리케이션 범위를 적습니다. |
| 작동 증거 | 로그, 알림, 대시보드, 테스트 결과를 적습니다. |
| 예외 | 적용되지 않는 계정, 자산, 업무 예외를 적습니다. |
| 한계 | 우회 가능성, 오탐, 누락, 운영 제약을 적습니다. |
| 책임자 | 점검, 승인, 변경, 대응 담당자를 적습니다. |
| 재검토 주기 | 월간, 분기, 변경 시, 훈련 후 등 기준을 적습니다. |
이 표를 채우면 “통제가 있다”는 말이 훨씬 구체적인 운영 질문으로 바뀝니다.
통제 증거를 확인한다
통제 점검에서 가장 중요한 것은 증거입니다. 통제가 있다고 주장하려면 작동 증거가 있어야 합니다.
증거는 다음과 같은 형태일 수 있습니다.
- SIEM에 들어오는 이벤트
- EDR 경보와 대응 기록
- IAM 권한 변경 로그
- 네트워크 차단 정책과 변경 승인 기록
- 백업 복구 테스트 결과
- 취약점 조치 이력
- 훈련 중 탐지와 대응 기록
- 예외 승인 문서
증거가 없으면 통제는 운영적으로 확인되지 않은 상태입니다. 예를 들어 로그 수집 정책이 있어도 실제 SIEM에 이벤트가 들어오지 않는다면 탐지 통제로 보기 어렵습니다.
예외와 한계를 기록한다
좋은 점검표는 통제의 빈틈을 숨기지 않습니다. 예외와 한계를 적어야 실제 위험을 볼 수 있습니다.
예외에는 다음 항목이 포함될 수 있습니다.
- 미관리 자산
- 레거시 시스템
- 예외 승인 계정
- 외부 협력사 계정
- 로그 미수집 구간
- 운영상 차단할 수 없는 업무 흐름
한계에는 다음 항목이 들어갈 수 있습니다.
- 오탐이 많아 경보를 무시하게 되는 문제
- 로그 지연으로 실시간 대응이 어려운 문제
- 통제 우회 가능성
- 담당자 부재 시 대응 지연
- 정책 변경 후 검증 누락
예외와 한계는 약점 자랑이 아닙니다. 다음 개선 과제를 정하기 위한 근거입니다.
검증 주기를 정한다
방어 통제는 한 번 점검하고 끝나지 않습니다. 시스템이 바뀌고, 계정이 바뀌고, 공격 기법이 바뀌고, 운영자가 바뀝니다. 따라서 검증 주기를 정해야 합니다.
검증은 다음 상황에서 다시 수행하는 것이 좋습니다.
- 주요 시스템이 추가되거나 변경될 때
- 권한 정책이 바뀔 때
- 로그 수집 구조가 바뀔 때
- 보안 솔루션 정책이 변경될 때
- 훈련이나 사고 대응에서 공백이 발견될 때
- 오탐이나 누락이 반복될 때
검증 방법은 간단한 로그 샘플 확인부터 테이블탑 훈련, 사이버레인지 훈련, 탐지 룰 테스트까지 다양합니다. 중요한 것은 점검표에 검증 날짜와 결과, 다음 조치가 남는 것입니다.
예를 들어 계정 보호 통제를 점검한다면 “MFA 적용”만 확인하지 않습니다. 어떤 계정에 MFA가 적용되는지, 예외 계정은 누구의 승인을 받았는지, 세션 탈취나 비정상 위치 로그인은 어떤 로그로 확인하는지, 경보가 발생하면 누가 계정을 잠그는지까지 봐야 합니다. 이 항목들이 빠져 있으면 통제는 존재하지만 운영 가능한 통제로 보기 어렵습니다.
백업 통제도 마찬가지입니다. “백업 있음”은 충분한 점검 항목이 아닙니다. 백업 대상 자산, 백업 주기, 복구 테스트 날짜, 무결성 검증 결과, 복구 권한자, 랜섬웨어 상황에서의 격리 기준까지 확인해야 합니다. D3FEND 관점의 점검표는 이런 식으로 통제 이름을 실제 작동 조건으로 바꾸는 데 의미가 있습니다.
AI 시스템이 포함될 때 ATLAS도 함께 본다
조직의 방어 통제가 AI 서비스나 모델 운영 환경까지 포함한다면 MITRE ATLAS도 함께 볼 수 있습니다. ATLAS는 AI 시스템에 대한 공격자 전술과 기법을 정리합니다.
AI 시스템에서는 일반 보안 통제 외에도 다음 항목을 점검해야 합니다.
- 모델 입력과 출력 로그의 보호
- 프롬프트 정책과 우회 시도 탐지
- 검색 문서나 학습 데이터 변경 관리
- 모델 배포 파이프라인 접근 통제
- AI 결과에 대한 검증과 사람 승인 기준
다만 ATLAS는 D3FEND를 대체하지 않습니다. AI 시스템도 계정, 권한, 로그, 네트워크, 배포 파이프라인 위에서 작동합니다. ATLAS는 AI 특수 위험을 추가로 확인하는 기준으로 보는 편이 좋습니다.
결론
D3FEND 관점으로 방어 통제 점검표를 만든다는 것은 방어책 이름을 많이 적는 일이 아닙니다. 통제가 어떤 공격자 행동을 줄이고, 어떤 기능으로 작동하며, 어떤 증거가 남고, 어떤 한계가 있으며, 누가 언제 다시 검증할지를 정리하는 일입니다.
좋은 점검표는 “있음/없음”보다 “작동 조건과 증거”를 봅니다. ATT&CK로 방어 목적을 정하고, D3FEND로 방어 기능을 분류하고, 실제 로그와 훈련 기록으로 통제 효과를 확인해야 합니다.
보안 통제의 가치는 제품 보유 여부가 아니라 운영 가능성에서 나옵니다. D3FEND는 그 운영 가능성을 묻는 언어로 활용할 때 가장 실용적입니다.
더 확인할 자료
아래 자료는 D3FEND 관점의 방어 통제 점검표를 만들 때 참고할 만한 공식 자료입니다.