[MITRE ATT&CK] Data-driven Detection 관점에서 ATT&CK 보기

◎ 개요

• 실무에서 ATT&CK를 가장 잘 쓰는 방법은 Technique 목록을 외우는 것이 아니라, 각 Technique가 어떤 텔레메트리로 관찰되는지 연결하는 것입니다.
• 즉, 탐지의 출발점을 공격자 이름이나 IOC가 아니라 로그 소스에 두는 방식이 Data-driven Detection입니다.
• 이 관점에서는 “어떤 로그를 수집해야 하는가”와 “그 로그로 어떤 Technique를 볼 수 있는가”가 같은 문제로 이어집니다.

 

◎ 왜 로그 중심인가

 - ATT&CK는 기술 이름만 나열하는 프레임워크가 아니라, 실제 관찰된 행위를 기반으로 설계된 지식베이스입니다.

• 따라서 탐지도 “이 기술은 위험하다”에서 끝나지 않고, “이 기술은 어떤 데이터로 보이는가”까지 내려가야 실무에 쓸 수 있습니다.
• 이때 로그는 단순 저장 대상이 아니라, 공격 행위를 증명하는 근거가 됩니다.

 

 - 로그 중심 접근의 장점은 세 가지입니다.

• 첫째, 탐지 규칙을 벤더 제품이 아닌 관찰 행위 기준으로 유지할 수 있습니다.
• 둘째, 커버리지 갭을 Technique 단위로 확인할 수 있습니다.
• 셋째, EDR, SIEM, 클라우드 감사 로그를 하나의 프레임으로 묶을 수 있습니다.

 

◎ EDR과 Sysmon

 - EDR과 Sysmon은 엔드포인트에서 가장 핵심적인 Data Source 계열입니다.

• 프로세스 생성, 자식 프로세스 관계, 커맨드라인, 파일 생성, 레지스트리 변경, 네트워크 연결 같은 흔적은 많은 Technique 탐지의 출발점이 됩니다.
• 특히 Windows 환경에서는 Sysmon과 Windows Event Log, 다양한 EDR 텔레메트리가 함께 사용되며, MITRE도 이런 이벤트 기반 매핑을 활용해 다양한 데이터 소스와 Technique를 연결해 왔습니다.
• 예를 들어 Script Interpreter 실행, 의심스러운 LOLBin 사용, 권한 상승 관련 행위, 방어 회피용 프로세스 조작 등은 프로세스 중심 로그 없이는 보기 어렵습니다.
• 즉, EDR과 Sysmon은 “무슨 파일이 있었는가”보다 “어떤 프로세스가 무엇을 실행했는가”를 잡아 주는 데 강합니다.
• 그래서 엔드포인트 탐지에서 가장 먼저 점검할 것은 탐지 룰이 아니라, 부모-자식 프로세스와 커맨드라인, 사용자, 해시, 실행 경로 같은 기본 필드가 충분히 남는지 여부입니다.

 

◎ CloudTrail과 클라우드 로그

 - 클라우드에서는 CloudTrail 같은 감사 로그가 ATT&CK 매핑의 중심이 됩니다.

• 클라우드 공격은 종종 파일 드롭보다 API 호출, 권한 변경, 리소스 생성, 토큰 사용, 역할 위임처럼 제어면에서 먼저 드러나기 때문입니다.
• 따라서 CloudTrail은 Initial Access, Persistence, Privilege Escalation, Defense Evasion, Exfiltration 관련 Technique를 볼 때 특히 중요합니다.
• 클라우드 로그는 엔드포인트 로그보다 “행위의 결과”가 먼저 보일 때가 많습니다.
• 예를 들어 누군가 IAM 정책을 수정하거나, 의심스러운 역할 전환을 시도하거나, 비정상적인 객체 접근을 만들면 그 자체가 탐지 포인트가 됩니다.
• 그래서 클라우드 탐지에서는 API 이름, 호출 주체, 대상 리소스, 소스 IP, 인증 방식, 지역 정보 같은 메타데이터가 매우 중요합니다.

 

 

◎ 어떤 로그가 어떤 Technique를 커버하는가

• 이 질문은 ATT&CK 실무의 핵심입니다.
• 정답은 “하나의 로그가 하나의 Technique만 커버한다”가 아니라, 여러 로그 소스가 하나의 Technique를 보완적으로 커버한다는 것입니다.
• 예를 들어 프로세스 생성은 EDR과 Sysmon이 강하고, 인증 관련 행위는 Windows 보안 로그나 IdP 로그가 강하며, 네트워크 기반 C2는 Zeek 같은 네트워크 텔레메트리가 강합니다.
• 따라서 커버리지를 볼 때는 Technique 이름만 보지 마시고, 어떤 관찰 지점이 그 Technique의 “증거”가 되는지를 보셔야 합니다.
• 예를 들어 같은 Lateral Movement라도 원격 서비스 실행은 인증 로그와 프로세스 로그가 필요하고, 클라우드 역할 이동은 CloudTrail과 IdP 로그가 필요할 수 있습니다.
• 즉, Technique 커버리지는 단일 장비로 판단하는 것이 아니라, 로그 조합으로 판단하는 경우가 많습니다.

 

◎ 커버리지 평가 방법

• 실무에서는 먼저 보유한 로그를 Data Source 기준으로 정리하시는 것이 좋습니다.
• 그다음 각 로그 소스가 어떤 Data Component를 제공하는지 확인하고, 그 컴포넌트가 어떤 Technique를 관찰할 수 있는지 매핑합니다.
• 이렇게 하면 “우리는 EDR이 있다”가 아니라 “우리는 프로세스 생성과 커맨드라인은 보지만, 특정 클라우드 API는 못 본다”처럼 훨씬 구체적인 평가가 가능합니다.
• 커버리지를 볼 때는 탐지 가능한 Technique 수보다, 어떤 전술에서 실제로 의미 있는 커버리지가 있는지를 보는 편이 더 중요합니다.
• 모든 Technique를 100% 커버하는 것은 현실적으로 어렵고, 공격자에게 중요한 단계부터 깊게 커버하는 전략이 더 실용적입니다.
• 특히 Initial Access, Execution, Credential Access, Lateral Movement, Exfiltration, Impact는 로그 품질에 따라 체감 보안 수준이 크게 달라집니다.

 

◎ 실무 적용 팁

 - 가장 먼저 하실 일은 SIEM과 EDR, Cloud 로그를 분리해서 보지 않는 것입니다.

• 엔드포인트에서 시작된 공격이 곧바로 계정, 클라우드, 네트워크로 이어지는 경우가 많기 때문에, 하나의 Technique를 여러 텔레메트리로 이어 붙여야 합니다.
• 예를 들어 프로세스 실행 이벤트와 인증 이벤트, 그리고 클라우드 API 로그를 시간순으로 엮으면 단편적인 알림보다 훨씬 정확한 공격 그림이 나옵니다.
• 또한 매핑할 때는 “이 로그가 있으면 대충 보인다”가 아니라, “어떤 필드가 있어야 기술을 식별할 수 있는가”까지 내려가셔야 합니다.
• 이 관점이 자리 잡으면 탐지 룰 품질, 오탐 감소, 헌팅 가설 수립이 모두 좋아집니다.
• 결국 Data-driven Detection은 ATT&CK를 로그 중심으로 재해석해, 실제 관측 가능한 공격 행위를 정확히 잡아내는 운영 방식이라고 보시면 됩니다.

 

◎ 정리

• ATT&CK에서 Data-driven Detection은 로그를 먼저 보고 Technique를 뒤따라 매핑하는 방식입니다.
• EDR과 Sysmon은 엔드포인트 행위를, CloudTrail은 클라우드 제어면 행위를, 네트워크 및 인증 로그는 보완 증거를 제공합니다.
• 따라서 “어떤 로그가 어떤 Technique를 커버하는가”라는 질문은 곧 “우리 환경에서 어떤 공격 행위를 실제로 볼 수 있는가”라는 질문과 같습니다.