D3FEND 관점으로 방어 통제 점검표를 만드는 방법 – 문과출신 IT공돌이의 유유자적

조회 300좋아요 1

방어 통제 점검표는 “보안 솔루션이 있다”는 사실을 적는 문서가 아닙니다. 어떤 위협 행동을 어떤 기능으로 줄이고, 그 기능이 어떤 조건에서 작동하며, 운영자가 어떤 증거로 확인할 수 있는지를 정리해야 합니다. 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 지식을 실제 통제 점검표로 번역하는 방법을 어렵게 생각할 필요는 없습니다. 방어 통제 점검은 자물쇠를 샀는지 보는 일이 아니라 실제 문이 잠기고 다시 열리는지 시험하는 일입니다.

이 글에서는 다음과 같은 상황을 떠올리면 됩니다. 방어 기법의 이름을 제품 보유 여부로 체크하지 않고 보호 대상·설정값·증거·담당자·재시험 날짜로 구체화한다. 처음부터 완벽하게 하려 하지 말고, 아래 순서를 하나씩 끝내면 됩니다.

1단계. 중요 자산과 공격 표면을 정하고 연결할 ATT&CK 기법을 고른다

쉽게 말하면, 지금은 ‘중요 자산과 공격 표면을 정하고 연결할 ATT&CK 기법을 고른다’에만 집중하면 됩니다. 기법 이름을 많이 고르기보다 우리 시스템에서 실제로 일어날 수 있는 한두 가지부터 연결하세요.

이 단계에서 답해야 할 질문은 ‘중요 자산과 공격 표면을 정하고 연결할 ATT&CK 기법을 고른다’입니다. 목록을 전부 가져오면 우리 환경과 상관없는 항목이 섞입니다. 현재 사용하는 계정, 서버, AI 도구에서 실제로 가능한 경로만 고르고 그 이유를 짧게 적으세요. ‘D3FEND 지식을 실제 통제 점검표로 번역하는 방법’에 관해 확인한 날짜와 자료의 이름을 짧게 적어 두면 며칠 뒤에도 왜 그렇게 결정했는지 다시 알 수 있습니다.

2단계. D3FEND에서 대응 가능한 방어 기법과 관계를 확인한다

쉽게 말하면, 지금은 ‘D3FEND에서 대응 가능한 방어 기법과 관계를 확인한다’에만 집중하면 됩니다. 기법 이름을 많이 고르기보다 우리 시스템에서 실제로 일어날 수 있는 한두 가지부터 연결하세요.

이 단계에서 답해야 할 질문은 ‘D3FEND에서 대응 가능한 방어 기법과 관계를 확인한다’입니다. 목록을 전부 가져오면 우리 환경과 상관없는 항목이 섞입니다. 현재 사용하는 계정, 서버, AI 도구에서 실제로 가능한 경로만 고르고 그 이유를 짧게 적으세요. ‘D3FEND 지식을 실제 통제 점검표로 번역하는 방법’에 관해 확인한 날짜와 자료의 이름을 짧게 적어 두면 며칠 뒤에도 왜 그렇게 결정했는지 다시 알 수 있습니다.

3단계. 추상 기법을 현재 보안 제품의 설정과 운영 절차로 나눈다

쉽게 말하면, 지금은 ‘추상 기법을 현재 보안 제품의 설정과 운영 절차로 나눈다’에만 집중하면 됩니다. 한 번에 여러 조건을 바꾸지 말고 이 항목 하나를 확인한 뒤 결과를 적어 두세요. 그래야 다음 단계에서 문제가 생겨도 원인을 찾기 쉽습니다.

이 단계에서 답해야 할 질문은 ‘추상 기법을 현재 보안 제품의 설정과 운영 절차로 나눈다’입니다. 목록을 전부 가져오면 우리 환경과 상관없는 항목이 섞입니다. 현재 사용하는 계정, 서버, AI 도구에서 실제로 가능한 경로만 고르고 그 이유를 짧게 적으세요. ‘D3FEND 지식을 실제 통제 점검표로 번역하는 방법’에 관해 확인한 날짜와 자료의 이름을 짧게 적어 두면 며칠 뒤에도 왜 그렇게 결정했는지 다시 알 수 있습니다.

4단계. 통제가 작동했다는 증거가 될 로그·화면·정책 값을 정한다

쉽게 말하면, 지금은 ‘통제가 작동했다는 증거가 될 로그·화면·정책 값을 정한다’에만 집중하면 됩니다. 날짜와 대상, 결과를 함께 남겨야 나중에 같은 일이 생겼을 때 무엇이 달라졌는지 찾을 수 있습니다.

이 단계에서 답해야 할 질문은 ‘통제가 작동했다는 증거가 될 로그·화면·정책 값을 정한다’입니다. 결과는 ‘괜찮아 보인다’로 끝내지 말고 실제 값이나 열린 화면으로 확인합니다. 답을 찾지 못했다면 다음 단계로 넘어가지 말고 범위를 더 작게 나누어 보세요. ‘D3FEND 지식을 실제 통제 점검표로 번역하는 방법’에 관해 확인한 날짜와 자료의 이름을 짧게 적어 두면 며칠 뒤에도 왜 그렇게 결정했는지 다시 알 수 있습니다.

5단계. 우회·오탐·성능 저하 같은 부작용과 예외 승인 조건을 기록한다

쉽게 말하면, 지금은 ‘우회·오탐·성능 저하 같은 부작용과 예외 승인 조건을 기록한다’에만 집중하면 됩니다. 날짜와 대상, 결과를 함께 남겨야 나중에 같은 일이 생겼을 때 무엇이 달라졌는지 찾을 수 있습니다.

이 단계에서 답해야 할 질문은 ‘우회·오탐·성능 저하 같은 부작용과 예외 승인 조건을 기록한다’입니다. 정확도가 떨어지거나 사용자가 문제를 제기했을 때 자동 처리를 멈출 기준이 필요합니다. 멈춘 동안 사람이 대신 처리하는 방법과 다시 시작할 승인자를 정하세요. ‘D3FEND 지식을 실제 통제 점검표로 번역하는 방법’에 관해 확인한 날짜와 자료의 이름을 짧게 적어 두면 며칠 뒤에도 왜 그렇게 결정했는지 다시 알 수 있습니다.

6단계. 샘플 공격과 정상 업무를 모두 실행해 차단과 업무 지속을 함께 검증한다

쉽게 말하면, 지금은 ‘샘플 공격과 정상 업무를 모두 실행해 차단과 업무 지속을 함께 검증한다’에만 집중하면 됩니다. 나쁜 동작이 막히는 것과 평소 업무가 계속되는 것을 같은 시험에서 확인해야 합니다.

이 단계에서 답해야 할 질문은 ‘샘플 공격과 정상 업무를 모두 실행해 차단과 업무 지속을 함께 검증한다’입니다. 공격만 넣어 보면 무엇이든 막는 규칙이 좋아 보일 수 있습니다. 평소 사용하는 정상 요청도 같은 수만큼 넣어 필요한 일이 계속되는지 비교하세요. ‘D3FEND 지식을 실제 통제 점검표로 번역하는 방법’에 관해 확인한 날짜와 자료의 이름을 짧게 적어 두면 며칠 뒤에도 왜 그렇게 결정했는지 다시 알 수 있습니다.

왜 이 순서로 해야 할까요?

처음 두 단계인 ‘중요 자산과 공격 표면을 정하고 연결할 ATT&CK 기법을 고른다’와 ‘D3FEND에서 대응 가능한 방어 기법과 관계를 확인한다’는 출발 조건을 확인하는 과정입니다. 이 답이 틀리면 뒤에서 아무리 열심히 해도 잘못된 대상이나 조건을 기준으로 움직이게 됩니다. 서두르기보다 공식 자료와 실제 환경이 맞는지 먼저 확인하세요.

가운데 두 단계인 ‘추상 기법을 현재 보안 제품의 설정과 운영 절차로 나눈다’와 ‘통제가 작동했다는 증거가 될 로그·화면·정책 값을 정한다’는 계획을 실제 행동으로 바꾸면서 위험을 줄이는 과정입니다. 한 번에 범위를 넓히지 말고 작은 예시 하나로 먼저 해 보세요. 예상과 실제가 다르면 그 자리에서 멈춰 차이를 찾아야 뒤 단계의 판단도 정확해집니다.

마지막 두 단계인 ‘우회·오탐·성능 저하 같은 부작용과 예외 승인 조건을 기록한다’와 ‘샘플 공격과 정상 업무를 모두 실행해 차단과 업무 지속을 함께 검증한다’는 결과가 쓸 만한지 확인하고 다음에도 같은 방법을 쓸 수 있게 마무리하는 과정입니다. 끝났다는 느낌보다 실제 화면, 수치, 서류, 현장 상태로 답을 확인하세요. 문제가 생겼을 때 선택할 두 번째 방법까지 정해 두면 처음 계획이 어긋나도 당황하지 않습니다.

한 번에 이해하는 쉬운 예시

제품에 차단 기능이 있다는 사실만으로는 부족합니다. 시험 파일이나 허용된 모의 요청을 보내 실제로 막혔는지, 정상 업무는 계속되는지를 함께 확인합니다.

혼자 결정하기 어려운 순간

실제 공격을 흉내 내는 시험은 허가된 시험망과 정해진 시간 안에서만 해야 합니다. 업무 서버에 영향을 줄 가능성이 있거나 로그에 개인정보가 들어 있다면 보안 담당자와 시스템 책임자에게 범위와 중지 조건을 먼저 확인하세요. 이 글의 주제인 ‘D3FEND 지식을 실제 통제 점검표로 번역하는 방법’에서도 모르는 부분을 억지로 채우기보다, 확인되지 않은 점을 그대로 표시하고 답을 얻은 뒤 다음 단계로 넘어가는 것이 가장 빠릅니다.

예상과 다를 때 이렇게 하세요

‘D3FEND 지식을 실제 통제 점검표로 번역하는 방법’에서 예상과 다른 상황이 생기면 다음처럼 대응합니다. 예상과 다른 경고나 차단이 나오면 시험을 멈추고 격리된 범위가 맞는지 확인합니다. 정상 업무가 막혔는지, 필요한 로그가 빠졌는지부터 살핀 뒤 규칙 하나만 고쳐 다시 시험합니다.

함께 읽을 글

더 확인할 자료

아래 자료는 D3FEND 관점의 방어 통제 점검표를 만들 때 참고할 만한 공식 자료입니다.