◎ 개요

  • MITRE ATT&CK를 실무에서 활용하실 때는 Technique 이름만 보는 것보다, 그 주변에 붙은 구성요소를 함께 읽으셔야 합니다.
  • Data Sources와 Data Components는 어떤 텔레메트리를 수집해야 하는지를 보여 주고, Mitigations는 위험을 줄이는 방법을, Detections는 어떤 관찰로 공격을 잡을 수 있는지를 설명합니다.
  • 여기에 Software와 Groups까지 연결하면 “누가, 어떤 도구로, 어떤 행위를 했는지”를 하나의 맥락으로 볼 수 있습니다.

 

◎ Data Sources와 Data Components

  • Data Sources는 보안 장비나 로그가 수집하는 정보의 주제, 즉 파일, 프로세스, 네트워크 트래픽 같은 큰 범주를 뜻합니다.
  • 다만 v19.1 기준에서는 단순히 “로그 종류”를 나열하는 수준을 넘어서, 그 안에서 어떤 속성이나 값이 Technique 탐지에 중요한지 Data Component로 세분화해 보여 줍니다.
  • 즉, Data Source가 큰 틀이라면 Data Component는 실제 탐지에 필요한 구체적인 관찰 단위라고 이해하시면 됩니다.
  • 이 구분이 중요한 이유는 실무에서 “Sysmon을 쓰자” 같은 표현만으로는 부족하기 때문입니다.
  • 예를 들어 Process, File, Registry, Network Traffic처럼 같은 Data Source 계열 안에서도 어떤 이벤트와 어떤 필드가 필요한지가 달라집니다.
  • 그래서 ATT&CK는 이제 데이터 수집 자체보다, 탐지에 유의미한 세부 관찰 지점을 더 잘 드러내는 방향으로 정리되고 있습니다.

 

◎ Mitigations, Detections, Software, Groups

 - Mitigations는 특정 Technique이나 Sub-technique의 위험을 줄이기 위한 대응책을 뜻합니다.

  • 예를 들어 사용자 교육, 권한 최소화, 보안 설정 강화, 응용 프로그램 제어 같은 조치가 이에 해당할 수 있습니다.
  • 즉, Mitigations는 탐지 이전 또는 탐지와 병행해서 공격 가능성을 낮추는 방어 수단입니다.

 

 - Detections는 해당 Technique를 어떤 관찰로 식별할 수 있는지 보여 주는 항목입니다.

  • ATT&CK v11부터는 Detection이 Data Sources와 더 명시적으로 연결되었고, 최신 모델에서는 Detection Strategy와 Analytics 흐름으로 더 구조화되고 있습니다.
  • 그래서 사용자는 “무엇을 막을 것인가”는 Mitigation에서, “무엇을 잡을 것인가”는 Detection에서 따로 읽으시면 됩니다.

 

 - Software와 Groups는 위협 맥락을 붙여 주는 요소입니다.

  • Software는 공격에 사용된 도구나 악성코드, Groups는 실제 위협 행위자나 공격 집단을 의미합니다.
  • 이 두 항목이 중요하 이유는 같은 Technique이라도 어떤 그룹이, 어떤 도구를 써서, 어떤 순서로 실행했는지를 보여 주기 때문입니다.

 

 

◎ Detection 필드 읽는 법

 - ATT&CK에서 Detection 필드는 단순한 설명문이 아니라, 실제로 어떤 로그와 어떤 조건을 봐야 하는지를 담고 있습니다.

  • 기술 페이지에서 Detection을 읽으실 때는 먼저 “어떤 행위를 찾으려는가”를 보고, 그 다음 “어떤 Data Source나 Data Component가 필요한가”를 확인하시는 순서가 좋습니다.
  • 이렇게 읽으면 탐지 텍스트가 추상적인 문장처럼 보이지 않고, 실무 룰 설계용 체크리스트처럼 보입니다.

 

 - 최근 ATT&CK 데이터 모델 문서에서는 Detection을 Behavior-to-Telemetry 연결의 일부로 설명합니다.

  • 즉, Technique 설명, Detection 문장, 관련 Log Source, 그리고 조정 가능한 값들이 하나의 흐름으로 이어진다는 뜻입니다.
  • 실무에서는 이 부분을 통해 “어떤 필드가 있어야 탐지가 가능한지”, “어떤 조건을 환경에 맞게 조정해야 하는지”를 판단할 수 있습니다.

 

 - 예를 들어

  • 어떤 Detection이 프로세스 생성과 시간 상관관계를 요구한다면, 단순히 프로세스 이벤트만 있는 것이 아니라 부모-자식 관계, 실행 경로, 시간창 같은 요소가 필요할 수 있습니다.
  • 또 어떤 Detection은 파일 쓰기와 실행 이벤트의 연계를 요구할 수 있으므로, 파일 시스템 이벤트와 실행 이벤트를 함께 수집해야 의미가 생깁니다.
  • 따라서 Detection은 “이 기술은 위험하다”가 아니라 “이 기술을 잡으려면 어떤 관찰이 필요한가”를 읽는 항목으로 보시는 것이 맞습니다.

 

◎ 실무에서 연결하는 방법

 - 실무에서는 Technique 하나를 볼 때 다음 순서로 읽으시면 좋습니다.

  • 어떤 Data Source와 Data Component가 필요한지 확인합니다.
  • Detection이 어떤 조건을 기대하는지 봅니다.
  • Mitigation으로 어떤 사전 방어가 가능한지 확인합니다.
  • 실제 사용 사례가 어떤 Software와 Group에 연결되는지 검토합니다.

 

 - 이렇게 보면 ATT&CK는 단순한 분류표가 아니라, 수집-탐지-완화-위협 맥락을 한 번에 연결하는 운영형 지식베이스가 됩니다.

  • 특히 SIEM이나 EDR 환경에서는 Data Component를 기준으로 로그 품질을 따지고, Detection 문장을 기준으로 룰 조건을 점검하는 방식이 가장 실용적입니다.
  • 결국 ATT&CK를 잘 쓴다는 것은 Technique ID를 외우는 것이 아니라, 그 기술을 둘러싼 데이터와 방어 요소를 함께 읽는 습관을 만드는 것입니다.

 

◎ 정리

  • Data Sources는 큰 텔레메트리 범주이고, Data Components는 그 안에서 실제 탐지에 필요한 구체적 관찰 단위입니다.
  • Mitigations는 위험을 낮추는 방법, Detections는 행위를 식별하는 방법, Software와 Groups는 실제 공격 맥락을 제공하는 요소입니다.
  • 그리고 Detection 필드는 “무엇을 수집해야 하며, 어떤 조건으로 봐야 하는가”를 읽는 자리로 이해하시면 실무 활용도가 크게 올라갑니다.

 

 

 

반응형

+ Recent posts