01 - 탐지 엔지니어링: 분야부터 스크립트, 파이프라인까지
끊임없이 진화하는 사이버 위협 환경에서 다음과 같은 능력을 갖추십시오. 감지하다 심각한 피해를 입히기 전의 악의적인 활동은 회복력이 있는 조직과 취약한 조직. 수십 년 동안 위협 탐지는 임시 서면 규칙, 바이러스 백신 서명 및 SOC 분석가의 개별 직관에 맡겨집니다. 오늘, 이러한 장인적 접근 방식은 더 이상 지속 가능하지 않습니다. 로그의 양, 로그의 복잡성 클라우드 네이티브 인프라와 공격자의 정교함을 위해서는 접근 방식이 필요합니다. 공학적이고 체계적인.
이렇게 탄생했어요 탐지공학: 원칙을 적용하는 학문 소프트웨어 엔지니어링에서 소프트웨어를 생성, 테스트, 배포 및 유지 관리하는 프로세스까지 탐지 규칙. 더 이상 SIEM에서 격리된 쿼리를 작성하는 것이 아니라 구축하는 것입니다. 자동화된 파이프라인, 탐지 버전을 코드로 지정하고 데이터로 테스트합니다. 시뮬레이션하고 객관적인 지표로 측정합니다.
이 기사에서 배울 내용
- 탐지공학이란 무엇이며 왜 자율적인 학문이 되었는가?
- 탐지를 위해 임시 스크립트에서 CI/CD 파이프라인으로의 진화
- 탐지의 전체 수명 주기: 가설, 개발, 테스트, 배포, 조정
- 주요 탐지 유형: 시그니처 기반, 행동 기반, 이상 기반
- 품질 지표: 참양성률, 거짓양성률, MTTD, MTTR
- SIEM/SOAR 생태계 및 주요 데이터 소스
- 보안 규칙에 대한 코드로서의 탐지 및 CI/CD 파이프라인 개념
- Sigma 규칙, Python 스크립트 및 YAML 구성을 사용한 실제 예
탐지공학이란?
La 탐지공학 디자인, 개발, 원격 측정 내에서 악의적인 활동을 식별하는 논리 테스트 및 유지 관리 조직의. 이 원격 측정에는 엔드포인트, 클라우드 인프라, ID 공급자, 웹 애플리케이션, 네트워크 시스템 등이 있습니다.
SOC 분석가가 SIEM에 쿼리를 작성하는 기존 접근 방식과 달리 특정 사건에 대응하여 탐지 엔지니어링은 다음을 채택합니다. 작업 흐름 구조화된 현대 소프트웨어 개발을 연상시킵니다: 코드 버전 관리, 코드 검토, 자동화된 테스트, 지속적인 배포 및 프로덕션 성능 모니터링.
"탐지 엔지니어링은 코딩에 대한 소프트웨어 엔지니어링과 마찬가지로 SOC에 있습니다. 즉, 임시, 반응적 활동을 체계적이고 측정 가능하며 지속적으로 개선되는 규율로 전환합니다."
- SANS 연구소, 2025 탐지 엔지니어링 설문조사
탐지 공학의 세 가지 기둥
이 분야는 성숙도를 정의하는 세 가지 상호 연결된 기둥을 기반으로 합니다.
- 위협 인텔리전스 - 상대가 누구인지, 어떤 기술을 사용하는지 이해 (MITRE ATT&CK), 조직의 어떤 자산이 위험에 처해 있는지 확인하세요. 이해도 없이 위협의 깊이에 따라 탐지는 일반적이며 그다지 효과적이지 않습니다.
- 데이터 엔지니어링 - 필요한 로그가 수집되고 정규화되었는지 확인 및 분석이 가능합니다. 작동하는 데이터가 그렇지 않은 경우 완벽하고 쓸모없는 탐지입니다. 존재하거나 품질이 좋지 않습니다.
- 소프트웨어 공학 - 소프트웨어 개발 모범 사례 적용: 버전 제어, 테스트, CI/CD, 문서, 측정항목. 탐지를 처리해야 합니다. 생산 코드로.
진화: 임시 스크립트에서 엔지니어링 분야까지
현대 탐지공학으로 이어진 길은 네 가지로 나눌 수 있다 각각의 단계는 성숙도와 자동화 수준이 높아지는 특징이 있습니다.
1단계: 서명 시대(1990-2005)
초기 탐지 형태는 다음을 기반으로 했습니다. 정적 서명: 알려진 패턴 악성 코드, 악성 파일의 해시, 네트워크 페이로드의 특정 문자열. 모든 바이러스 백신 및 IDS (침입 탐지 시스템)은 주기적으로 업데이트되는 서명 데이터베이스를 유지 관리했습니다. 이 접근 방식은 알려진 위협에 대해 합리적으로 잘 작동했지만 완전히 얼굴을 인식하지 못했습니다. 새로운 변형이나 맞춤형 공격까지.
2단계: SIEM 스크립트의 시대(2005-2015)
전자의 확산과 함께 시엠 (보안정보 및 이벤트 관리), 분석가들은 맞춤형 쿼리와 상관 관계를 작성하기 시작했습니다. 각 분석가는 고유한 접근 방식, 고유한 스크립트, 고유한 명명 규칙. 규칙이 생성되었습니다. 버전 관리 없이, 테스트 없이, 문서화 없이 SIEM 웹 인터페이스에서 직접 표준화. 분석가가 조직을 떠날 때 그의 탐지는 종종 후계자들이 이해할 수 없는 일이다.
3단계: 탐지 공학의 탄생(2015-2022)
2015년부터 2022년 사이에 보안 커뮤니티는 다음과 같은 조치의 필요성을 인식하기 시작합니다. 좀 더 구조화된 접근 방식. 다음과 같은 표준 형식이 탄생했습니다. 시그마 (2017) 탐지 규칙, 프레임워크 마이터 공격&CK 참고가 됩니다 적의 기술을 매핑하는 데 보편적이며 최초의 전담 탐지 팀 엔지니어링은 보다 성숙한 조직에 나타납니다.
4단계: 코드형 탐지 및 CI/CD 파이프라인(2022년~현재)
오늘날 가장 발전된 조직에서는 탐지를 소프트웨어 코드와 똑같이 취급합니다. 규칙은 선언적 형식(Sigma, YAML)으로 작성되고 Git 저장소에 버전이 지정됩니다. 시뮬레이션된 데이터로 자동 테스트되고, CI/CD 파이프라인을 통해 배포되고, 모니터링됩니다. 전용 대시보드가 있습니다. 에 따르면 SANS 2025 탐지 엔지니어링 설문조사, 60%의 조직이 전담 탐지 엔지니어링 팀을 유지하고 있으며, 70%는 이미 조직화된 팀을 구축한 직원 수 5,000명 이상의 기업 중
| 단계 | 기간 | 접근하다 | 악기 | 제한 |
|---|---|---|---|---|
| 정적 서명 | 1990-2005 | 알려진 서명에 대한 패턴 일치 | 바이러스 백신, IDS(Snort) | 보이지 않는 제로데이, 높은 대기 시간 |
| SIEM 스크립트 | 2005-2015 | SIEM의 임시 쿼리 | 스플렁크, 아크사이트, QRadar | 버전이 없고, 테스트되지 않은, 고립된 지식 |
| 탐지공학 | 2015-2022 | 표준을 갖춘 구조화된 워크플로우 | 시그마, ATT&CK, ELK | 여전히 수동 프로세스가 많음 |
| 코드로 탐지 | 2022년~현재 | CI/CD 파이프라인, 모두 버전 지정됨 | 힘내, CI/CD, 시그마, SOAR | 조직적 성숙도 필요 |
탐지의 수명주기
각 탐지는 품질, 효율성 및 보안을 보장하는 잘 정의된 수명 주기를 따릅니다. 시간이 지남에 따른 유지 관리 가능성. 주기는 6가지 기본 단계로 구성되며 각 단계는 다음과 같습니다. 결과물 및 특정 품질 기준.
1. 가설(가설)
모든 것은 하나에서 시작된다 위협 가설. 분석가 또는 탐지 엔지니어 특정 공격 기술을 식별합니다(예: "공격자가 다음을 사용할 수 있습니다. 악성 페이로드를 다운로드하고 실행하는 PowerShell") 그리고 방법에 대한 가설을 세웁니다. 이 활동은 사용 가능한 로그에 나타납니다. 가설의 출처는 다음과 같습니다.
- 위협 인텔리전스 - 활성 캠페인에 대한 보고, 관찰된 TTP
- 마이터 공격&CK - 특정 전술에 매핑된 기술
- 사후 사고 - 과거 사건에서 얻은 교훈
- 레드팀 조사 결과 - 침투 테스트 및 퍼플팀 구성 결과
- 격차 분석 - 탐지 범위가 없는 ATT&CK 기술
2. 개발(개발)
가설이 정의되면 탐지 엔지니어는 탐지 규칙을 작성합니다. 이 형식 선택(Sigma, SIEM 기본 쿼리, Python 스크립트), 정의가 포함됩니다. 필요한 소스 로그, 선택 및 필터링 논리, 문서화 메타데이터(작성자, 심각도, ATT&CK 매핑, 알려진 오탐).
3. 테스트 및 검증(테스트)
배포하기 전에 실제 데이터와 시뮬레이션 데이터를 기준으로 검색 내용을 검증해야 합니다. 테스트에는 다음이 포함됩니다. 진양성 테스트 (규칙이 시뮬레이션된 공격을 탐지합니까?) 위양성 테스트 (규칙이 합법적인 활동에 대한 경고를 생성합니까?), e 성능 테스트 (이 규칙은 볼륨에 대해 충분히 효율적입니다. 생산 로그?).
4. 배포
규칙을 형식으로 변환하는 자동화된 파이프라인을 통해 배포가 이루어집니다. 대상 SIEM에 기본적으로 포함되어 프로덕션 환경에 배포하고 정확성을 확인합니다. 운영. 성숙한 환경에서는 이 프로세스가 CI/CD를 통해 완전히 자동화됩니다.
5. 모니터링 및 지표
생산이 시작되면 탐지가 지속적으로 모니터링됩니다. 주요 지표 생성된 경고의 양, 참/거짓 긍정 비율, 평균 시간이 포함됩니다. 탐지(MTTD) 및 SOC 분석가 로드에 미치는 영향.
6. 튜닝 및 유지 관리
생산 과정에서 수집된 데이터를 기반으로 탐지가 지속적으로 개선됩니다. 는 조정에는 반복되는 거짓 긍정에 대한 예외 추가, 확장이 포함될 수 있습니다. 기술의 변형을 다루는 논리 또는 그 이상은 아니더라도 규칙의 사용 중단 관련.
모범 사례: 퍼플 팀 구성
Il 보라색 팀 피드백 루프를 크게 가속화합니다. 감지 수명주기. 레드팀의 공격 스킬과 방어 스킬의 결합 블루팀의 실제 공격 기법을 시뮬레이션하고 탐지 내용의 검증이 가능합니다. 가설과 검증된 탐지 사이의 시간을 몇 주에서 몇 시간으로 단축합니다.
탐지 유형: IOC에서 행동까지
탐지는 사용된 탐지 논리에 따라 분류될 수 있습니다. 각 유형에는 특정한 장점과 한계가 있으며 성숙한 탐지 프로그램이 이를 결합합니다. 모두 계층화 된 방식으로.
1. 시그니처 기반 탐지
시그니처 기반 탐지 검색 정확한 패턴 데이터: 파일 해시 명령, IP 주소 또는 알려진 악성 도메인(IOC - 표시기)의 알려진 특정 문자열 타협). 가장 간단하고 빠른 유형으로 오탐률이 매우 낮지만, 새로운 위협이나 변종 위협에는 전혀 효과가 없습니다.
title: Emotet Loader Hash Detection
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: stable
description: Detects known Emotet loader by file hash
author: Detection Engineering Team
date: 2025/10/15
references:
- https://attack.mitre.org/software/S0367/
logsource:
category: file_event
product: windows
detection:
selection:
Hashes|contains:
- 'SHA256=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'
- 'SHA256=a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a'
- 'MD5=d41d8cd98f00b204e9800998ecf8427e'
condition: selection
falsepositives:
- Unlikely, known malicious hashes
level: critical
tags:
- attack.execution
- attack.t1204.0022. 행동 탐지
행동 탐지가 찾고 있는 것 액션 시퀀스 또는 패턴 특정 IOC에 관계없이 의심스러운 활동을 나타내는 동작입니다. 예를 들어 Mimikatz의 특정 해시를 찾는 대신 행동 탐지 자격 증명을 추출하기 위해 LSASS 메모리에 액세스하는 모든 프로세스를 찾을 수 있습니다. 이 접근 방식은 공격자가 변경할 수 있기 때문에 회피에 훨씬 더 저항력이 있습니다. 도구는 있지만 기본 기술은 거의 변경할 수 없습니다.
title: Suspicious LSASS Process Access - Credential Dumping
id: b2c3d4e5-f6a7-8901-bcde-f12345678901
status: experimental
description: |
Detects process access to LSASS memory, a common technique
for credential dumping (T1003.001). Focuses on behavior
rather than specific tool signatures.
author: Federico Calo
date: 2025/11/20
references:
- https://attack.mitre.org/techniques/T1003/001/
logsource:
category: process_access
product: windows
detection:
selection:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|contains:
- '0x1010' # PROCESS_QUERY_LIMITED_INFORMATION + PROCESS_VM_READ
- '0x1038' # Read memory access
- '0x1FFFFF' # PROCESS_ALL_ACCESS
filter_legitimate:
SourceImage|endswith:
- '\MsMpEng.exe' # Windows Defender
- '\csrss.exe' # Client Server Runtime
- '\wmiprvse.exe' # WMI Provider
- '\svchost.exe' # Service Host
filter_system:
SourceUser|contains: 'SYSTEM'
SourceImage|startswith: 'C:\Windows\System32\'
condition: selection and not filter_legitimate and not filter_system
falsepositives:
- Legitimate security tools performing memory scanning
- EDR solutions with high-privilege access
level: high
tags:
- attack.credential_access
- attack.t1003.0013. 이상 기반 탐지
이상 기반 탐지는 정규성의 기준선 전자 상당한 편차를 보고합니다. 예를 들어, 사용자가 일반적으로 다음에서 로그인하는 경우 업무 시간 동안 이탈리아에 본사를 둔 경우 오전 3시에 중국에서 로그인하면 변칙. 이 접근 방식은 완전히 알려지지 않은(제로데이) 위협을 탐지할 수 있으며, 그러나 특히 동적 환경에서는 더 많은 거짓 긍정을 생성하는 경향이 있습니다.
4. 위협 사냥
위협 사냥은 하나의 과정이다 적극적이고 가설 중심적 어느 분석가는 자동 탐지를 피할 수 있는 위협을 적극적으로 찾습니다. 자동화된 탐지와 달리 위협 사냥은 탐색적이며 종종 새로운 탐지는 코드화되고 자동화됩니다.
| 감지 유형 | 정도 | 제로데이 보장 | 거짓 긍정 | 유지 | Esempio |
|---|---|---|---|---|---|
| 서명 기반 | 매우 높음 | 없음 | 매우 낮음 | 높음(IOC 업데이트) | 해시 파일, 악성 IP |
| 행동 | 높은 | 좋은 | 보통 | 평균 | LSASS 액세스, 측면 이동 |
| 이상 기반 | 변하기 쉬운 | 훌륭한 | 높은 | 높음(기준 조정) | 비정상적인 로그인, 비정상적인 트래픽 |
| 위협 사냥 | 매우 높음 | 훌륭한 | 최소(수동) | 높음(분석가 필요) | 탐색적 분석, 가설 |
탐지에 대한 품질 지표
그렇지 않으면 감지가 유용하지 않습니다. 측정 가능. 품질 지표 탐지 규칙의 효율성을 평가하고 프로세스를 안내할 수 있습니다. 탐지 엔지니어링 프로그램에 대한 투자를 조정하고 정당화합니다.
기본 운영 측정항목
| 미터법 | 설명 | 목표 | 개선 방법 |
|---|---|---|---|
| MTTD (평균 감지 시간) | 악의적인 활동이 발생한 순간부터 경고가 생성되기까지의 평균 시간 | < 4시간(최상위 팀: < 30분) | 더 나은 로그 범위, 실시간 감지 |
| MTTR (평균 응답 시간) | 탐지부터 억제/해결까지의 평균 시간 | 4시간 미만 | SOAR 자동화, 정의된 플레이북 |
| 참양성률 (TPR) | 실제 위협에 해당하는 경고의 비율 | > 80%(중요), > 60%(높음) | 지속적인 튜닝, 고급 필터링 |
| 거짓양성률 (FPR) | 합법적인 활동에 대해 생성된 경고 비율 | < 크리티컬의 경우 25% | 화이트리스트, 강화된 컨텍스트, 상관관계 |
| 거짓음성률 (FNR) | 탐지되지 않은 실제 위협의 비율 | < 1% | 퍼플팀 구성, 위협 사냥 |
| ATT&CK 적용 범위 | 하나 이상의 탐지에 포함된 MITRE ATT&CK 기술의 비율 | > 관련 기술의 70% | 정기적인 격차 분석, 우선순위 지정 |
탐지 점수 계산
탐지 프로그램의 전반적인 품질과 탐지 성숙도 점수, 여러 지표를 하나의 점수로 결합합니다. 정규화되었습니다. 다음은 Python의 계산 예입니다.
from dataclasses import dataclass
from typing import List
@dataclass(frozen=True)
class DetectionMetrics:
"""Immutable snapshot of detection performance metrics."""
rule_id: str
true_positives: int
false_positives: int
false_negatives: int
total_alerts: int
avg_detection_time_minutes: float # MTTD
avg_response_time_minutes: float # MTTR
@property
def precision(self) -> float:
"""TP / (TP + FP) - How many alerts are real threats."""
denominator = self.true_positives + self.false_positives
return self.true_positives / denominator if denominator > 0 else 0.0
@property
def recall(self) -> float:
"""TP / (TP + FN) - How many real threats are caught."""
denominator = self.true_positives + self.false_negatives
return self.true_positives / denominator if denominator > 0 else 0.0
@property
def f1_score(self) -> float:
"""Harmonic mean of precision and recall."""
p, r = self.precision, self.recall
return 2 * (p * r) / (p + r) if (p + r) > 0 else 0.0
def calculate_maturity_score(metrics_list: List[DetectionMetrics]) -> dict:
"""Calculate overall detection program maturity score.
Returns an immutable dict with aggregated metrics.
"""
if not metrics_list:
return {"score": 0, "grade": "F", "details": {}}
avg_precision = sum(m.precision for m in metrics_list) / len(metrics_list)
avg_recall = sum(m.recall for m in metrics_list) / len(metrics_list)
avg_f1 = sum(m.f1_score for m in metrics_list) / len(metrics_list)
avg_mttd = sum(m.avg_detection_time_minutes for m in metrics_list) / len(metrics_list)
avg_mttr = sum(m.avg_response_time_minutes for m in metrics_list) / len(metrics_list)
# Weighted maturity score (0-100)
precision_score = avg_precision * 25 # 25% weight
recall_score = avg_recall * 25 # 25% weight
f1_component = avg_f1 * 20 # 20% weight
mttd_score = max(0, (240 - avg_mttd) / 240) * 15 # 15% weight (240min = 4h target)
mttr_score = max(0, (240 - avg_mttr) / 240) * 15 # 15% weight
total_score = (precision_score + recall_score + f1_component
+ mttd_score + mttr_score) * 100
grade_thresholds = [
(90, "A"), (80, "B"), (70, "C"), (60, "D")
]
grade = next(
(g for threshold, g in grade_thresholds if total_score >= threshold),
"F"
)
return {
"score": round(total_score, 1),
"grade": grade,
"details": {
"avg_precision": round(avg_precision, 3),
"avg_recall": round(avg_recall, 3),
"avg_f1": round(avg_f1, 3),
"avg_mttd_minutes": round(avg_mttd, 1),
"avg_mttr_minutes": round(avg_mttr, 1),
"total_rules_evaluated": len(metrics_list),
},
}
# Esempio di utilizzo
sample_metrics = [
DetectionMetrics("SIGMA-001", 45, 5, 2, 50, 15.0, 35.0),
DetectionMetrics("SIGMA-002", 120, 30, 8, 150, 8.5, 22.0),
DetectionMetrics("SIGMA-003", 200, 15, 5, 215, 3.2, 12.0),
]
result = calculate_maturity_score(sample_metrics)
print(f"Detection Maturity Score: {result['score']} ({result['grade']})")
print(f"Details: {result['details']}")주의: 허영 지표
탐지 프로그램의 성공 여부를 측정하지 마세요. 총 수 규칙의 또는 생성된 경고 수. 이는 측정항목입니다. 심각한 문제를 가릴 수 있는 허영 지표. 50명이 있는 조직 5,000개의 규칙을 생성하는 것보다 훨씬 더 안전합니다. 수천 건의 잘못된 긍정으로 인해 분석가들 사이에 경고 피로가 발생합니다.
SIEM/SOAR 생태계
Il 시엠 (보안정보 및 이벤트 관리)와 마음 탐지 엔지니어링 인프라의 일부입니다. 그리고 이를 수집하고 표준화하는 플랫폼은 조직 내 모든 소스의 로그를 연관시키고 분석합니다. 그만큼 날기 (보안 오케스트레이션, 자동화 및 대응)이 SIEM을 보완합니다. 사전 정의된 플레이북을 통해 경고에 대한 응답을 자동화합니다.
주요 SIEM 플랫폼 개요
| 플랫폼 | 유형 | 쿼리 언어 | 강점 | 이상적인 사용 사례 |
|---|---|---|---|---|
| 스플렁크 엔터프라이즈 | 온프레미스/클라우드 | SPL | 성숙도, 앱 생태계, 유연성 | 복잡한 기업, 성숙한 SOC |
| 탄력적 SIEM | 오픈소스/클라우드 | KQL / EQL / ES|QL | 오픈소스, 확장성, 비용 | 저예산 클라우드 기반 팀 |
| 마이크로소프트 센티넬 | 클라우드(Azure) | KQL | Azure/M365 통합, AI 내장 | Microsoft 중심 조직 |
| Google SecOps(연대기) | 클라우드(GCP) | YARA-L | 무제한 보존, 속도 | 대용량 데이터, GCP |
| CrowdStrike Falcon LogScale | 구름 | 로그스케일 쿼리 | 신속한 섭취, 압축 | CrowdStrike 조직 |
| 스모 로직 | 구름 | 스모 논리 쿼리 | 네이티브 SaaS, 사용 편의성 | 클라우드 우선, SaaS 중심 |
기본 데이터 소스
탐지 품질은 데이터의 품질과 완전성에 직접적으로 좌우됩니다. 가능합니다. 효과적인 탐지 프로그램을 위한 기본 데이터 소스는 다음과 같습니다.
- 엔드포인트 원격 측정 - 프로세스 로그, 파일 시스템 이벤트, 레지스트리 변경, 네트워크 연결. 출처: EDR(CrowdStrike, SentinelOne, Microsoft Defender), Sysmon
- 네트워크 원격 측정 - NetFlow, DNS 쿼리, HTTP/TLS 메타데이터, PCAP 선택적. 소스: 방화벽, IDS/IPS, 프록시, DNS 확인자
- 신원 및 액세스 - 인증 이벤트, 권한 상승, 그룹 멤버십이 변경됩니다. 출처: Active Directory, Entra ID, Okta, CyberArk
- Cloud 감사 로그 - API 호출, 구성 변경, 리소스 생성. 출처: AWS CloudTrail, Azure 활동 로그, GCP 감사 로그
- 애플리케이션 로그 - 웹 서버 접속 로그, 애플리케이션 오류, WAF 이벤트. 소스: Nginx, Apache, CloudFront, 사용자 정의 애플리케이션
- 이메일 보안 - 피싱 시도, 악성 첨부 파일, BEC 탐지. 출처: O365용 Microsoft Defender, Proofpoint, Mimecast
데이터 정규화: 보이지 않는 기초
없이 데이터 정규화, 탐지는 취약하고 이식성이 없습니다.
모든 SIEM과 모든 소스는 동일한 개념에 대해 "로그인 실패"라는 다른 형식을 사용합니다.
그것은 다음과 같이 보일 수 있습니다 EventID 4625 윈도우에서, sshd: Failed password
리눅스에서 또는 {"eventType": "user.session.start", "outcome": "FAILURE"}
옥타에서. 다음과 같은 정규화 방식을 채택합니다. ECS(탄력적 공통 스키마),
OCSF(개방형 사이버 보안 스키마 프레임워크) 또는 Sigma의 데이터 모델을 사용하면
감지 기능을 한 번만 작성하고 모든 소스에 적용합니다.
코드로서의 탐지: 최신 패러다임
코드로 감지(DaC) 개발 관행을 적용하는 접근 방식 탐지 규칙을 관리하는 소프트웨어입니다. 규칙을 만들고 수정하는 대신 SIEM 그래픽 인터페이스를 통해 탐지 내용이 코드로 작성되고 버전이 지정됩니다. Git 리포지토리에서 풀 요청을 통해 코드 검토를 받고 자동으로 테스트됨 CI/CD 파이프라인을 통해 제공됩니다.
코드로 탐지의 장점
전통적인 접근 방식과 비교
- 버전 관리 - 모든 변경 사항은 Git에서 추적되며 롤백 가능
- 코드 검토 - 탐지는 배포 전에 동료 검토를 거칩니다.
- 자동화된 테스트 - 긍정적이고 부정적인 데이터를 이용한 자동 검증
- 재현성 - 탐지의 전체 상태를 저장소에서 재구성할 수 있습니다.
운영상의 이점
- 속도 - 탐지는 며칠이 아닌 몇 분 만에 생산에 들어갑니다.
- 일관성 - 균일한 품질기준 적용
- 감사 추적 - 규정 준수를 위한 완벽한 추적성
- 협동 - 여러 팀이 동일한 저장소에 기여할 수 있습니다.
코드로 탐지 저장소의 구조
detections/
rules/
credential_access/
lsass_memory_access.yml
brute_force_login.yml
kerberoasting.yml
execution/
powershell_encoded_command.yml
suspicious_wmi_execution.yml
lateral_movement/
psexec_usage.yml
rdp_from_unusual_source.yml
persistence/
scheduled_task_creation.yml
registry_run_key.yml
tests/
credential_access/
lsass_memory_access_test.json
brute_force_login_test.json
execution/
powershell_encoded_command_test.json
config/
sigma_config.yml
siem_mappings.yml
exclusions.yml
pipelines/
ci.yml
cd.yml
docs/
CONTRIBUTING.md
STYLE_GUIDE.md
REVIEW_CHECKLIST.md
README.md탐지를 위한 CI/CD 파이프라인
CI/CD 감지 파이프라인은 커밋부터 프로덕션까지 전체 프로세스를 자동화합니다. 다음은 GitHub Actions 구성의 예입니다.
name: Detection CI/CD Pipeline
on:
pull_request:
paths: ['rules/**', 'tests/**']
push:
branches: [main]
paths: ['rules/**']
jobs:
validate:
name: Validate Sigma Rules
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install sigma-cli
run: pip install sigma-cli pySigma-backend-splunk pySigma-backend-elasticsearch
- name: Lint Sigma Rules
run: |
sigma check rules/ --validation-config config/sigma_config.yml
echo "All rules pass validation"
- name: Verify ATT&CK Mapping
run: |
python scripts/verify_attack_tags.py rules/
echo "All rules have valid ATT&CK mappings"
test:
name: Test Detection Logic
needs: validate
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run True Positive Tests
run: |
python scripts/run_tests.py \
--rules-dir rules/ \
--tests-dir tests/ \
--test-type true_positive
- name: Run False Positive Tests
run: |
python scripts/run_tests.py \
--rules-dir rules/ \
--tests-dir tests/ \
--test-type false_positive
- name: Generate Coverage Report
run: python scripts/coverage_report.py --output reports/coverage.json
deploy:
name: Deploy to SIEM
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
- name: Convert Sigma to Splunk SPL
run: |
sigma convert \
--target splunk \
--pipeline splunk_windows \
rules/ \
--output converted/splunk/
- name: Deploy to Splunk via API
env:
SPLUNK_TOKEN: ${{ secrets.SPLUNK_API_TOKEN }}
SPLUNK_URL: ${{ secrets.SPLUNK_URL }}
run: |
python scripts/deploy_splunk.py \
--rules-dir converted/splunk/ \
--splunk-url "$SPLUNK_URL" \
--token "$SPLUNK_TOKEN"
- name: Update ATT&CK Coverage Map
run: python scripts/update_attack_coverage.py완전한 코드로서의 감지 흐름
- 탐지 엔지니어가 Git 분기에 새로운 Sigma 규칙을 생성합니다.
- 규칙 및 관련 테스트가 포함된 Pull Request를 엽니다.
- CI 파이프라인은 구문 검증, TP/FP 테스트, ATT&CK 매핑 검증을 수행합니다.
- 피어 리뷰어는 논리, 문서 및 적용 범위를 확인한 후 PR을 승인합니다.
- 기본으로 병합하면 규칙을 변환하고 이를 SIEM에 배포하는 CD 파이프라인이 활성화됩니다.
- 모니터링 대시보드는 프로덕션 환경의 탐지 성능을 추적합니다.
효과적인 탐지 작성: 원칙 및 패턴
평범한 탐지와 우수한 탐지의 차이는 탐지의 깊이에 있습니다. 공격 기법에 대한 이해, 오탐 필터링 품질 그리고 문서의 완전성. 기본 원칙은 다음과 같습니다.
원칙 1: 도구가 아닌 기술로 시작하세요
"Mimikatz"에 대한 탐지를 작성하지 마십시오. 기술 di LSASS 메모리 액세스를 통한 자격 증명 덤핑 (T1003.001). 이 접근 방식은 이를 다루고 있습니다. 자동으로 동일한 기술을 구현하는 모든 도구 아직 알려지지 않은 미래.
원칙 2: 레이어 감지(감지 피라미드)
동일한 기술에 대해 다단계 감지를 구현합니다. 해시 기반 탐지 (사소하게 회피 가능)은 여전히 정교하지 않은 공격자를 포착할 수 있지만 행동 탐지는 보다 진보된 탐지를 포착합니다. 이러한 계층적 접근 방식과 으로 알려진 심층 탐지.
원칙 3: 항상 컨텍스트를 문서화하세요
각 탐지에는 다음이 포함되어야 합니다. 동기 부여 (왜 이런 감지가 존재한다), ATT&CK 매핑 (어떤 기술을 다루는지), 나는 거짓 알려진 긍정적인 점 (적법한 활동이 규칙을 트리거할 수 있음) 응답 플레이북 (탐지가 트리거될 때 분석가가 수행해야 하는 작업)
전체 예: Log Analysis Python을 사용한 탐지
"""
Brute Force Detection Module
MITRE ATT&CK: T1110.001 - Brute Force: Password Guessing
Detects multiple failed login attempts followed by a success.
"""
from dataclasses import dataclass, field
from datetime import datetime, timedelta
from collections import defaultdict
from typing import Optional
@dataclass(frozen=True)
class LoginEvent:
"""Immutable representation of a login event."""
timestamp: datetime
username: str
source_ip: str
success: bool
service: str # 'ssh', 'rdp', 'web', 'vpn'
@dataclass(frozen=True)
class BruteForceAlert:
"""Immutable alert generated by the detector."""
username: str
source_ip: str
failed_count: int
time_window_minutes: int
first_attempt: datetime
last_attempt: datetime
successful_login: bool
severity: str # 'medium', 'high', 'critical'
mitre_technique: str = "T1110.001"
@dataclass(frozen=True)
class DetectionConfig:
"""Immutable configuration for brute force detection."""
failed_threshold: int = 5
time_window_minutes: int = 10
lockout_threshold: int = 20
whitelist_ips: tuple = ()
monitored_services: tuple = ('ssh', 'rdp', 'web', 'vpn')
class BruteForceDetector:
"""Stateless brute force detection engine.
Analyzes login events and produces alerts when
brute force patterns are detected.
"""
def __init__(self, config: Optional[DetectionConfig] = None):
self._config = config or DetectionConfig()
def analyze(self, events: list[LoginEvent]) -> list[BruteForceAlert]:
"""Analyze a batch of login events for brute force patterns.
Returns a new list of alerts (no mutation of input).
"""
# Group events by (source_ip, username)
grouped = defaultdict(list)
for event in events:
if (event.service in self._config.monitored_services
and event.source_ip not in self._config.whitelist_ips):
key = (event.source_ip, event.username)
grouped[key].append(event)
alerts = []
for (source_ip, username), user_events in grouped.items():
sorted_events = sorted(user_events, key=lambda e: e.timestamp)
alert = self._check_brute_force(source_ip, username, sorted_events)
if alert is not None:
alerts.append(alert)
return alerts
def _check_brute_force(
self, source_ip: str, username: str, events: list[LoginEvent]
) -> Optional[BruteForceAlert]:
"""Check if events match a brute force pattern."""
window = timedelta(minutes=self._config.time_window_minutes)
failed_events = [e for e in events if not e.success]
if len(failed_events) < self._config.failed_threshold:
return None
# Check if failures cluster within the time window
for i, start_event in enumerate(failed_events):
window_end = start_event.timestamp + window
window_failures = [
e for e in failed_events[i:]
if e.timestamp <= window_end
]
if len(window_failures) >= self._config.failed_threshold:
# Check for subsequent successful login
success_after = any(
e.success and e.timestamp >= start_event.timestamp
for e in events
)
severity = self._calculate_severity(
len(window_failures), success_after
)
return BruteForceAlert(
username=username,
source_ip=source_ip,
failed_count=len(window_failures),
time_window_minutes=self._config.time_window_minutes,
first_attempt=window_failures[0].timestamp,
last_attempt=window_failures[-1].timestamp,
successful_login=success_after,
severity=severity,
)
return None
def _calculate_severity(self, failed_count: int, success: bool) -> str:
"""Determine alert severity based on pattern characteristics."""
if success and failed_count >= self._config.lockout_threshold:
return "critical" # Many failures + success = likely compromised
if success:
return "high" # Fewer failures + success = suspicious
if failed_count >= self._config.lockout_threshold:
return "high" # Many failures = active attack
return "medium" # Moderate failures = possible attackMITRE ATT&CK: 참조 프레임워크
프레임워크 마이터 공격&CK (적대적 전술, 기술 및 공통 지식)과 상대방의 기술을 매핑하고 분류하기 위한 보편적인 참조 자료입니다. 탐지 엔지니어링을 위해 ATT&CK는 설명할 수 있는 공통 언어를 제공합니다. 무엇 우리는 다음을 측정하기 위한 매트릭스를 찾습니다. 적용 범위 우리의 탐지.
탐지 엔지니어링에 ATT&CK를 사용하는 방법
- 우선순위 - 모든 ATT&CK 기술이 동일하게 생성되는 것은 아닙니다. 귀하의 조직과 관련이 있습니다. 상대가 가장 많이 사용하는 기술 식별 해당 분야(위협 인텔리전스)에 리소스를 집중하세요.
- 격차 분석 - 기존 탐지를 ATT&CK 기술에 매핑 노출되지 않은 영역을 보려면 사용 ATT&CK 네비게이터 에 대한 현재 적용 범위를 보여주는 히트맵을 만듭니다.
-
태그 지정 - 각 시그마 및 탐지 규칙에는 ATT&CK 태그가 포함되어야 합니다.
해당(예:
attack.t1003.001). 이를 통해 다음을 집계할 수 있습니다. 기술과 전술에 대한 지표. - 측정 - 각 전술에 적용되는 기술의 비율을 추적하세요. (초기 액세스, 실행, 지속성 등) 현실적인 적용 범위 목표를 정의합니다.
| 전술 | 예시 기술 | 주요 데이터 소스 | 난이도 감지 |
|---|---|---|---|
| 초기 액세스 | T1566 피싱, T1190 공개 앱 악용 | 이메일, WAF, 프록시 | 평균 |
| 실행 | T1059 명령줄, T1204 사용자 실행 | Sysmon, EDR, 프로세스 로그 | 낮음-중간 |
| 고집 | T1053 예약된 작업, T1547 부팅 자동 시작 | 레지스트리, 파일 시스템, EDR | 평균 |
| 권한 승격 | T1068 공격, T1078 유효한 계정 | EDR, AD 로그, 클라우드 감사 | 높은 |
| 방어회피 | T1070 표시기 제거, T1027 난독화 | EDR, 시스몬, AMSI | 매우 높음 |
| 자격 증명 액세스 | T1003 OS 자격 증명 덤핑, T1110 무차별 대입 | EDR, AD 로그, 인증 로그 | 평균 |
| 측면 운동 | T1021 원격 서비스, T1570 측면 도구 전송 | 네트워크, AD 로그, EDR | 높은 |
| 유출 | Alt 프로토콜을 통한 T1048 유출, T1567 웹 서비스 | DLP, 프록시, DNS, NetFlow | 매우 높음 |
팀 구조 및 역할
효과적인 탐지 엔지니어링 프로그램에는 여러 기술의 조합이 필요합니다 한 사람에게서는 거의 발견되지 않습니다. 팀 구조는 다음에 따라 다릅니다. 조직의 규모는 크지만 주요 역할은 잘 정의되어 있습니다.
주요 역할
- 탐지 엔지니어 - 중심 역할. 규칙 작성, 테스트 및 유지 관리 탐지의. 위협 인텔리전스, SIEM 쿼리 언어, 스크립팅 기술이 필요합니다. (Python) 및 대상 플랫폼 로그에 대한 지식. SANS 설문조사 2025에 따르면, 60%의 조직에는 최소 한 명의 전담 탐지 엔지니어가 있습니다.
- 위협 인텔리전스 분석가 - 위협에 대한 컨텍스트 제공: 어떤 위협인지 APT 그룹이 활동하고 있는지, 어떤 기술을 사용하는지, 어떤 지표를 찾아야 하는지 등을 살펴보겠습니다. 그것은 그들에게 먹이를 준다 실행 가능한 지능을 갖춘 탐지 가설.
- 데이터 엔지니어/로그 설계자 - 품질과 가용성을 고려합니다. 데이터: 새로운 로그 소스 온보딩, 정규화, 구문 분석 및 관리 수집 인프라의 모습입니다.
- SOC 분석가 - 탐지의 최종 사용자입니다. 피드백 제공 경고 품질의 기본: 오탐지가 너무 많습니까? 경고를 실행할 수 없습니까? 컨텍스트 정보가 누락되었나요?
- 레드팀 / 퍼플팀 - 상대방의 기술을 시뮬레이션하여 검증합니다. 탐지. 레드팀 피드백은 개선을 위한 가장 효과적인 메커니즘입니다. 적용 범위와 규칙에 대한 충실성.
소규모 팀을 위한 조직
모든 조직이 전담 탐지 엔지니어링 팀을 가질 여유가 있는 것은 아닙니다. 소규모 보안 팀(3~5명)의 경우 권장되는 접근 방식은 다음과 같습니다.
- 할당 20~30%의 시간 디텍션엔지니어링의 SOC 분석가들
- 입양하다 시그마 커뮤니티 규칙 기준으로(SigmaHQ 저장소)
- 구현 구조화된 피드백 프로세스 경고 분류에서
- 사용 코드로 탐지 간단한 파이프라인(Git + 배포 스크립트)으로도 가능
- 집중하다 10-15 가장 관련성이 높은 ATT&CK 기술 귀하의 부문에 대한
실제 사례: 사고부터 탐지 파이프라인까지
논의된 개념을 구체적으로 설명하기 위해 현실적인 예를 살펴보겠습니다. 생산 현장의 격차 발견부터 탐지까지의 전체 경로입니다.
시나리오: PowerShell 인코딩 명령을 통한 손상
퍼플 팀 구성 훈련 중에 레드 팀은 악성 페이로드를 실행합니다.
Base64로 인코딩된 명령과 함께 PowerShell 사용(-EncodedCommand).
공격은 검색만 했기 때문에 기존 탐지에서는 탐지되지 않습니다.
일반적인 인코딩 패턴이 아닌 알려진 PowerShell 명령의 특정 문자열입니다.
1단계: 가설 및 분석
탐지 엔지니어는 다음과 같은 가설을 세웁니다. "PowerShell을 사용하는 경우
-엔터프라이즈 환경의 EncodedCommand는 의심스러운 것으로 간주되어야 합니다.
합법적인 소프트웨어는 명령을 인코딩할 필요가 거의 없습니다." 분석
지난 30일 동안의 로그 확인: 50,000번의 PowerShell 실행 중 12번만 사용
-EncodedCommand, 모두 알려진 IT 자동화 스크립트에 기인합니다.
2단계: 시그마 법칙
title: Suspicious PowerShell Encoded Command Execution
id: f4a3b2c1-d5e6-7890-abcd-ef0123456789
status: test
description: |
Detects execution of PowerShell with encoded commands (-enc,
-EncodedCommand). Legitimate use is rare in enterprise environments.
Attackers commonly use this to obfuscate malicious payloads.
author: Federico Calo
date: 2025/12/01
modified: 2025/12/15
references:
- https://attack.mitre.org/techniques/T1059/001/
- https://attack.mitre.org/techniques/T1027/010/
logsource:
category: process_creation
product: windows
detection:
selection_powershell:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
selection_encoded:
CommandLine|contains:
- '-enc '
- '-EncodedCommand'
- '-encodedcommand'
- '-ec '
filter_known_automation:
ParentImage|endswith: '\sccm_agent.exe'
User|contains: 'SVC_AUTOMATION'
condition: selection_powershell and selection_encoded and not filter_known_automation
falsepositives:
- SCCM automation scripts (filtered)
- Custom IT automation using encoded commands (add to filter)
level: high
tags:
- attack.execution
- attack.t1059.001
- attack.defense_evasion
- attack.t1027.0103단계: 테스트, 배포 및 결과
규칙은 5가지 참양성 시나리오(인코딩된 명령의 변형)와 20가지 시나리오로 테스트되었습니다. 거짓 부정 시나리오(합법적인 PowerShell 실행). 파이프라인을 통한 배포 후 CI/CD, 처음 30일 동안 탐지는 8개의 경고를 생성합니다: 6개의 참 긍정(의심스러운 스크립트) 분석용), 거짓양성 1개(필터에 추가할 새 자동화 스크립트) 1개의 중요한 참양성으로 인해 무단 액세스가 발견되었습니다.
측정 가능한 결과
- 정도: 87.5%(총 경고 8개 중 7TP)
- MTTD: "감지되지 않음"에서 4.2분(평균 경고 생성 시간)으로 감소
- ATT&CK 적용 범위: 맵에 +2 기술(T1059.001, T1027.010)이 추가되었습니다.
- 실질적인 영향: 45분 이내에 활성 장애 1개 발견 및 격리
결론 및 다음 단계
탐지 엔지니어링은 보안의 근본적인 패러다임 변화를 나타냅니다. 운영. SIEM에 더 나은 규칙을 작성하는 것뿐만 아니라 구축하는 것도 중요합니다. 에 완전한 엔지니어링 프로세스 이는 전체 수명주기에 걸쳐 탐지: 위협 가설부터 프로덕션 검증까지.
기억해야 할 핵심 사항:
- 품질이 양을 이긴다 - 50개의 고충실도 탐지는 무한합니다. 경고 소음을 생성하는 5,000개의 규칙보다 더 유용합니다.
- 탐지를 코드로 처리 - 버전 관리, 코드 검토, 자동화된 테스트 CI/CD 파이프라인은 선택이 아닌 기본입니다.
- 모든 것을 측정하세요 - MTTD, MTTR, 정밀도, 리콜, ATT&CK 적용 범위. 없이 측정항목으로는 지속적인 개선이 불가능합니다.
- 기술부터 시작하라 - 탐지를 MITRE ATT&CK에 매핑하고 집중합니다. 귀하의 조직과 가장 관련성이 높은 기술에 대한 리소스입니다.
- 데이터 품질에 투자하세요 - 그것 없이는 완벽하고 쓸모없는 탐지 작업할 데이터입니다. 로그 소스의 정규화 및 온보딩은 전체 프로그램의 보이지 않는 기초.
다음 기사에서
시리즈의 다음 기사에서는 이에 대해 더 자세히 알아볼 것입니다. 시그마 규칙: 휴대용 탐지를 작성하기 위한 표준 형식입니다. 우리는 완전한 구문을 볼 것입니다. 고급 수정자, 주요 SIEM을 위한 변환 백엔드 등을 구축하겠습니다. 가장 중요한 ATT&CK 기술에 대한 완전한 규칙 세트입니다.