sims718718/unifiedthreathunting보안 팀을 위한 트리거, SMART 가설, 실행 가능성 게이트, 범위 설정, 헌트 계획, 결과 보고를 포괄하는 구조화되고 반복 가능한 위협 헌팅 방법론을 문서화합니다.
리드 위협 헌터로서, 저는 위협 헌팅 프로그램을 처음부터 구축하는 임무를 맡았습니다. 이 과정에서 위협 헌팅이 실제로 무엇인지, 그리고 이를 어떻게 의미 있는 결과로 전환할 수 있는지에 대해 많은 고민을 했습니다. 위협 헌팅, 탐지 엔지니어링, 사이버 위협 인텔리전스(CTI), 포렌식에 관한 다양한 방법론을 읽고, 미국 공군에서의 경험까지 더하는 데 많은 시간을 투자했습니다. 그러나 프로그램을 구축하면서, 저는 하나의 프로세스, 즉 통합 위협 헌팅 프로세스가 필요하다는 것을 깨달았습니다. 저는 이 프로세스를 조직에 구조화되고 명확한 헌팅 방식을 제공하고 궁극적으로 의미 있는 성과를 도출하기 위해 개발했습니다.
graph LR
Z[Step 0: Environment Context] --> A[Triggering Event]
A --> B[Hypothesis Development]
B --> C[Initial Assessment]
C --> D[Feasibility Assessment]
D --> E[Define Scope & Objectives]
E --> F[Formalize Hunt Plan]
F --> G[Execute Hunt]
G --> H[Document Outcomes]
H --> I[Report & Iterate]
I --> A
위협 헌팅은 통제를 우회한 위협을 능동적으로 찾는 행위입니다. 그 정의는 확립되어 있지만, 이를 하나의 프로그램으로 운영하는 방법은 그렇지 않습니다. 이 프로세스는 종합(synthesis)이며, 아래 표는 그것에 대한 정직한 회계입니다:
| 출처 | 여기서 기여하는 것 |
|---|---|
| Sqrrl / Hunting Maturity Model (Bianco) | Maturity & Metrics에서 사용된 핵심 루프와 성숙도 사다리 |
| TaHiTI | 진정한 시작점으로서의 트리거, 그리고 종료 시 인접 프로세스로의 핸드오버 |
| PEAK | 헌트 유형 분류(가설 / 베이스라인 / 모델 지원)와 결과 중심의 "지식을 가지고 행동하라"는 종료 방식 |
| AIMOD2 | 가정된 침해(assumed breach) 전제와 유형화된 결과 범주 |
| OTHF | 반복 가능한 팀 기능으로서 헌트를 운영하기 위한 운영적 프레이밍 |
| 이 프로세스가 추가하는 것 | Step 0 환경 컨텍스트 · 엄격한 실현 가능성 GO / NO-GO / CONDITIONAL 게이트 · 유형화된 결과를 갖춘 Jira Epic/Story/Task · 루브릭으로 게이트된 가설과 명세화된 탐지 핸드오프 |
차별점은 마지막 행입니다. 나머지 모든 것은 다른 사람들의 작업 위에 서 있으며, References에 인용되어 있습니다.
헌트 운영을 수행하기 위해 설명된 다양한 방법이 있습니다: 구조화, 비구조화, TTP 중심, 인텔 중심, 데이터 중심 등. 이 통합 위협 헌팅 프로세스가 구조화된 것처럼 보일 수 있지만, 그렇다고 해서 여러분의 가설이 비구조화된 방식으로 데이터에 의해 주도될 수 없다는 의미는 아닙니다. 이 프로세스는 다양한 유형의 위협 헌팅을 통합하여 모듈식 접근을 가능하게 하는 것을 목표로 합니다. 우리는 가설을 철저히 검증하기 위해 이 모든 기법을 사용할 것입니다.
목표는 만능 해결책이 없는 모듈식 위협 헌팅 접근입니다. 사용 가능한 모든 기법을 활용하십시오.
실제로, 선택하는 헌트 유형은 DAIKI 체인(Data → Information → Knowledge → Insight)에서 어디에서 시작하는지에 따라 달라집니다:
| 헌트 유형 | 시작점 | 특징 |
|---|---|---|
| 탐색적 (EDA) | 원시 데이터 | 베이스라이닝, 데이터 형태 이해, 사전 가설 없음 |
| 가설 기반 (HBO) | 상황 인식 | 팀 지식을 기반으로 신뢰할 수 있는 공격 시나리오 테스트 |
| 위협 정보 기반 (TIO) | 실행 가능한 CTI | 인텔리전스 주도, 알려진 행위자 또는 TTP 중심 |
| 퍼플 작전 (DPO) | 레드팀 인사이트 | 공격/방어 공동 검증 |
데이터 과학 원칙에 따라, 헌트 유형에 관계없이 헌트와 관련된 데이터 소스를 탐색하고 이해하는 것을 목표로 해야 합니다. 이 저장소의 /Data_Analysis 폴더에는 해당 탐색 단계를 위한 지원 기법과 노트북이 포함되어 있습니다.
추가로, 위협 인텔리전스는 시작점이든 아니든 운영을 주도하는 데 도움을 주기 위해 전체 프로세스에 깊이 배어 있습니다.Threat Intelligence
참고: 일반적으로 행위나 TTP에 초점을 맞추고 싶겠지만, IoC가 진정으로 실행 가능하고 시의적절하다면 그 나름의 가치가 있습니다. 환경 전반에 걸쳐 IoC를 헌팅하는 것은 진정한 위협 헌팅은 아니지만, 여전히 유용한 정보와 또 다른 시작점을 제공할 수 있습니다. 이는 헌트 사이클의 일부가 될 수 있지만, 헌트 그 자체 전체가 되어서는 안 됩니다.
어떤 헌트가 시작되기 전에, 환경을 기록하여 모든 하위 산출물(쿼리, 필드 이름, 범위 결정)이 일반적으로 작성되는 것이 아니라 실제로 여러분이 일하는 곳에 맞춰지도록 하십시오. 제가 이것을 명시적인 단계로 추가한 이유는, 아무도 가지고 있지 않은 데이터 소스를 참조하거나 완전히 잘못된 방언으로 작성된 쿼리를 참조하는 헌트 계획을 계속 보았기 때문입니다. 여기서 몇 분을 투자하면 나중에 몇 시간을 절약할 수 있습니다.
최소한 다음을 문서화하십시오:
| 컨텍스트 | 중요한 이유 |
|---|---|
| SIEM / 데이터 플랫폼 | Splunk SPL, KQL, Elastic DSL, Chronicle은 각각 작성하는 모든 쿼리를 형성합니다 |
| EDR 플랫폼 | CrowdStrike, SentinelOne, Defender for Endpoint는 각각 다른 텔레메트리 필드 이름을 사용합니다 |
| 환경 유형 | 온프레미스, 클라우드 네이티브(AWS/Azure/GCP), 또는 하이브리드는 어떤 로그가 존재하는지 자체를 바꿉니다 |
| 산업 분야 | 어떤 위협 행위자가 현실적으로 관련성이 있는지를 결정합니다 |
| 로그 보존 기간 | 어떤 시간 범위를 실제로 쿼리할 수 있는지 결정합니다 |
| 헌트 성숙도 수준 | 처음 헌팅하는 사람은 발판이 필요하고, 숙련된 팀은 골격을 원합니다 |
이것을 Epic 상단에 Environment Profile 블록으로 문서화하십시오. 빠르게 움직이고 있다면, 절대적인 최소값은 SIEM 플랫폼과 환경 유형이며, 그보다 적으면 쿼리가 일반적이게 됩니다.
여러 조직에 걸쳐 헌팅하나요? (MSSP/MDR, 연합 자회사, 또는 공유 SIEM 플랫폼.)
tenants/<id>/profile.yaml레지스트리에 테넌트당 하나의 프로필을 유지하고, 각 Epic이 프로필을 내장하는 대신tenant: <id>를 참조하도록 하십시오. 실현 가능성 이전에 권한을 확인하십시오: RoE/계약 적용 범위가 없는 테넌트, 또는allowed_actions밖의 계획된 작업은 NOT AUTHORIZED이며 거기서 중단됩니다. 단일 조직 팀은 이것을 건너뛸 수 있습니다. Multi-Tenant Operation을 참조하십시오.
TaHiTI 프레임워크에서 차용하여, 위협 헌팅은 트리거 이벤트로 시작합니다. 이 이벤트들은 헌트의 개시를 정당화합니다. TaHiTI에 따르면, 트리거는 다음을 포함할 수 있습니다:
우리 조직의 경우, 이들과 함께 이해관계자의 직접적인 요구사항이나 환경에 영향을 미치는 취약점 공개와 같은 몇 가지 추가 트리거를 사용합니다.
일부 프레임워크는 초기 가설(여기서는 2단계)로 위협 헌트를 시작하지만, 저는 묻습니다: 애초에 그 가설에 어떻게 도달합니까?
초기 가설로 이어지는 트리거 이벤트가 있을 가능성이 큽니다. 아이작 뉴턴이 어떤 힘이 그것을 끌어내리는지 궁금해하기 전에 사과가 떨어지는 것을 본 것처럼, 그 사과는 중력에 대한 가설로 이어진 트리거 이벤트였습니다. 마찬가지로, 우리는 가설에 도달하기 전에도 트리거를 가져야 합니다.
헌팅 트리거 (출처: Targeted Hunting Integrating Threat Intelligence (TaHiTI))
다음으로, 그리고 아마도 가장 중요한 단계는 헌트 가설을 세우는 것입니다. 이 단계는 중요하지만, 동시에 가장 모호할 수 있습니다. 여러분의 가설은 금광으로 이끌 수도 있고, 끝없는 토끼굴로 빠뜨릴 수도 있습니다.
데이터 과학 원칙에서, 여러분의 가설은 분석을 안내할 검증 가능한 진술을 만드는 것입니다. 뿐만 아니라, 가설을 SMART하게 만드는 것을 목표로 해야 합니다:
유용한 템플릿:
우리는 **[위협 행위자 / 기법 / 행위]**가 **[데이터 소스]**의 **[관찰 가능한 지표]**로 입증되어 우리 환경에 존재할 수 있다고 가설을 세우며, 이는 [시간 프레임] 내에 **[테스트 방법론]**으로 검증할 수 있습니다.
예시 1 (CTI 주도, TIO):
우리는 Kerberos 사전 인증이 비활성화된 계정에 대해 AS-REP Roasting(T1558.004)을 사용하는 적대자가 우리 환경에 존재할 수 있다고 가설을 세우며, 이는 Splunk Windows Security 로그에서 비도메인 컨트롤러 소스로부터의 사전 인증 유형 0을 가진 Event ID 4768로 입증되며, 스프린트가 끝날 때까지 지난 30일의 인증 이벤트를 쿼리하고 서비스 계정 인벤토리와 상관 분석하여 검증할 수 있습니다.
예시 2 (행위 주도, HBO):
우리는 업무 시간 외에 권한 있는 계정의 비정상적인 대화형 로그온이 자격 증명 오용을 나타낼 수 있다고 가설을 세우며, 이는 Domain Admins 그룹의 계정에 대한 CrowdStrike 텔레메트리의 Event ID 4624(유형 2 또는 10) 및 4672로 입증되며, 60일의 로그온 이력을 베이스라이닝하고 2주 내에 2 표준편차를 초과하는 편차를 표시하여 검증할 수 있습니다.
가설을 세울 때 실제로 여러 경쟁 가설을 개발할 수 있습니다. 이에 대해 읽을 만한 책은 CIA의 Center for the Study of Intelligence에서 출판한 Richards J. Heuer의 Psychology of Intelligence Analysis입니다. Heuer는 경쟁 가설(Competing Hypotheses)을 설명하는데, 이는 여러분의 헌팅 노력에 유익합니다.
이 프로세스는 여러 가설을 정의하고 그중 가장 타당한 것을 결정하는 것을 포함하며, 가설 구축 단계에 엄격성을 부여하여 헌트의 기반을 정의하는 데 도움을 줍니다. 7단계 프로세스는 다음과 같습니다:
다음 두 단계는 가설에 기반하여 헌트를 실행해야 하는지 여부를 정의하기 위해 이 프로세스에 기댑니다.
추가로, AIMOD2 프레임워크의 핵심 개념은 **가정된 침해(assumed breach)**라는 근본 가설이며, 우리는 적대자가 이미 우리의 통제를 우회했다는 가정 아래 알려지지 않은 것을 식별하는 데 초점을 맞춥니다.
초기 평가(Initial Assessment) 단계에서, 우리는 가설을 뒷받침할 데이터를 수집하고 조사합니다. 여기에는 내부 및 외부 소스가 모두 포함됩니다.
여기서의 하위 단계는 비즈니스 또는 기술 소유자를 식별하고 필요시 인터뷰하는 것입니다. 헌트에 따라 더 깊은 이해를 위해 SME를 참여시켜야 할 수 있습니다. 항상 필요한 것은 아니며, 경험이나 과거 헌트를 통해 시스템, 로깅, 애플리케이션을 이미 알고 있을 수 있습니다.
목표는 시스템의 전문가가 되는 것이 아니라, 환경에 대한 충분한 이해를 개발하는 것입니다.
헌트 활동을 계획하기 전에, 실현 가능성을 평가해야 합니다. 여기에는 다음이 포함됩니다:
본질적으로, 우리는 묻습니다: "들인 노력에 비해 얻는 것이 가치가 있는가?"
텔레메트리를 사용할 수 없다면, 묻습니다: 사용할 수 있게 만들 수 있는가? 그렇게 하는 데 어떤 노력이 필요한가?
각 실현 가능성 평가는 명확한 결정을 산출해야 합니다: