🚀 심화 학습

Data Model, CIM, KV Store, tstats, Splunk ES, 최신 기능 (Splunk 9.x/10.x)

📊 Data Model이란?

데이터 모델은 이벤트의 계층적 분류 구조입니다. Root Object(최상위)에 기본 검색 조건(constraint)을 정의하고, Child Object에서 더 구체적인 하위 조건을 추가합니다.

일반 SPL 검색과 달리, 데이터 모델은 Acceleration(가속화)을 활성화하면 tsidx 파일에 사전 집계 데이터를 저장해 tstats/Pivot 조회 시 raw 이벤트를 읽지 않아 수십 배 빠릅니다.

Root Object (기본 검색 조건)
 └─ Child Object A  (추가 필터 1)
 └─ Child Object B  (추가 필터 2)
     └─ Child Object B-1  (세부 필터)

🔗 CIM이란?

CIM (Common Information Model)은 Splunk가 제공하는 표준 데이터 모델 집합입니다. Palo Alto 방화벽 로그의 src와 Cisco ASA 로그의 sourceIPAddress를 모두src_ip로 정규화해서, 벤더에 관계없이 동일한 SPL로 분석할 수 있습니다.

Splunk ES(Enterprise Security)는 CIM 표준 필드에 전적으로 의존합니다. CIM 매핑이 안 된 데이터는 ES Correlation Search에 잡히지 않습니다.

설치: Apps → Splunk Add-on for CIM (무료, Splunkbase)
경로: $SPLUNK_HOME/etc/apps/Splunk_SA_CIM/

CIM 데이터 모델 전체 목록 & 핵심 필드

모델명	필수 필드	태그	적용 소스
Authentication	action, app, dest, src, user	authentication	VPN, SSH, AD 로그인
Network Traffic	src_ip, src_port, dest_ip, dest_port, protocol, bytes_in, bytes_out, action	network, communicate	방화벽, 라우터
Web	src_ip, dest_ip, uri_path, http_method, status, bytes, uri_query	web	nginx, Apache, IIS
Malware	dest, signature, category, vendor_product, action, file_path	malware, attack	AV, EDR
Endpoint - Processes	dest, user, process, process_name, process_id, parent_process	endpoint, process	Sysmon, osquery
Endpoint - Filesystem	dest, file_path, file_name, action	endpoint, filesystem	Sysmon Event 11
Endpoint - Registry	dest, registry_path, registry_value_name, action	endpoint, registry	Sysmon Event 13
Email	src_user, recipient, subject, size, message_id, direction	email	Exchange, Postfix
Change	dest, src, user, action, object, object_path	change	ITSM, OS 변경
Network Sessions	src_ip, dest_ip, duration, bytes_in, bytes_out	network, session	NetFlow, IPFIX
DNS	src_ip, dest_ip, query, record_type, reply_code	network, dns	DNS 서버, Zeek
Vulnerabilities	dest, signature, cve, severity, vendor_product	report, vulnerability	Nessus, QualysGuard
Alerts	id, type, severity, description	alert	SIEM, IDS/IPS

CIM 매핑 전체 흐름

1원본 로그 수집 (Forwarder → Indexer)

2eventtypes.conf → 이벤트 유형 정의 (어떤 이벤트가 "인증 이벤트"인지)

3tags.conf → CIM 태그 부여 (authentication 태그 → Authentication 모델에 포함)

4props.conf → EVAL로 필드명 정규화 (vendor_action → CIM 표준 action 필드)

5Data Model Acceleration 활성화 (선택, tsidx 사전 집계)

6tstats / Pivot으로 표준화된 데이터 분석

단계별 CIM 매핑 가이드 — nginx 웹 로그 예시

STEP 1eventtypes.conf — 이벤트 유형 정의

역할: "어떤 이벤트가 특정 유형에 속하는가"를 정의합니다. 검색 조건으로 이벤트를 분류하는 레이블입니다.

# $SPLUNK_HOME/etc/apps/my_nginx_ta/default/eventtypes.conf

[nginx_access]
search = sourcetype=nginx:access
# → nginx 액세스 로그를 "nginx_access" 유형으로 분류

[nginx_error]
search = sourcetype=nginx:error
# → nginx 에러 로그를 "nginx_error" 유형으로 분류

💡 SPL에서 확인: search eventtype=nginx_access | head 5

STEP 2tags.conf — CIM 태그 부여

역할: eventtypes에 CIM 태그를 붙여서 어떤 Data Model에 포함시킬지 결정합니다. Web 모델은 web 태그가 필요합니다.

# $SPLUNK_HOME/etc/apps/my_nginx_ta/default/tags.conf

[eventtype=nginx_access]
web = enabled
# → nginx_access 이벤트에 "web" 태그 부여 → CIM Web 데이터 모델에 포함됨

[eventtype=nginx_error]
web = enabled
# 에러 로그도 Web 모델에 포함

# 예시: SSH 인증 로그 태그 (Authentication 모델)
[eventtype=sshd_auth]
authentication = enabled

💡 태그 확인: search sourcetype=nginx:access | tags | head 5

STEP 3props.conf — EVAL로 필드 정규화

역할: 벤더별로 다른 필드명을 CIM 표준 필드명으로 변환합니다. EVAL-<필드명> 형식으로 작성합니다.

# $SPLUNK_HOME/etc/apps/my_nginx_ta/default/props.conf

[nginx:access]
# CIM Web 모델 필드 정규화
EVAL-src_ip     = clientip         # nginx의 clientip → CIM src_ip
EVAL-dest_ip    = serverip         # nginx의 serverip → CIM dest_ip
EVAL-http_method = method          # nginx의 method → CIM http_method
EVAL-uri_path   = uri              # nginx의 uri → CIM uri_path
EVAL-status     = status           # 이름이 같으면 그대로도 OK
EVAL-bytes      = bytes_sent       # nginx bytes_sent → CIM bytes
EVAL-user_agent = useragent        # useragent → CIM user_agent
EVAL-url        = "http://" . dest_ip . uri  # 동적 계산도 가능

# 조건부 정규화 (Palo Alto 방화벽 예시)
# [pan:traffic]
# EVAL-action = if(action="allow", "allowed", if(action="deny", "blocked", "unknown"))

⚠️ EVAL-필드명은 검색 시 계산(search-time)됩니다. 인덱싱 시점이 아니므로 기존 데이터에도 즉시 적용됩니다.

STEP 4CIM 준수 여부 테스트

방법 1: SPL로 직접 datamodel 검색 — 결과가 나오면 매핑 성공

| datamodel Web Traffic search
| rename "Web.Traffic.*" AS *
| table _time, src_ip, dest_ip, uri_path, http_method, status, bytes
| head 10

방법 2: tstats로 확인

| tstats count FROM datamodel=Web WHERE index=web
  BY Web.src_ip, Web.http_method, Web.status

방법 3: 필드 존재 여부 확인

sourcetype=nginx:access
| table src_ip, http_method, uri_path, status, bytes, user_agent
| head 5
# src_ip 등 CIM 필드가 null 아닌 값으로 표시되면 성공

실전 매핑 예시

nginx → Web CIM

원본 필드명

clientip, method, uri, bytes_sent, status

↓ props.conf EVAL

CIM 표준 필드

src_ip, http_method, uri_path, bytes, status

tags: web

model: Web

syslog → Authentication CIM

원본 필드명

srcip, user, result, service

↓ props.conf EVAL

CIM 표준 필드

src, user, action (success/failure), app

tags: authentication

model: Authentication

Palo Alto → Network Traffic

원본 필드명

src, dst, sport, dport, proto, bytes

↓ props.conf EVAL

CIM 표준 필드

src_ip, dest_ip, src_port, dest_port, protocol, bytes_in

tags: network, communicate

model: Network_Traffic

Data Model Acceleration (DMA) 설정

UI에서 활성화하는 방법

1.Settings → Data Models 클릭
2.가속화할 Data Model 선택
3.Edit → Edit Acceleration 클릭
4.Enable Acceleration 체크
5.Summary Range (보존 기간) 설정 (예: 1 Month)
6.Save 클릭 → 5분 후 tsidx 생성 시작

저장 위치: $SPLUNK_DB/<index>/<bucket>/datamodel_summary/<dm_name>/<namespace>.tsidx
디스크 예상: 원본 인덱스의 약 10~15%

# datamodels.conf (수동 설정)
# $SPLUNK_HOME/etc/apps/my_app/local/datamodels.conf

[Web]
acceleration = true
acceleration.earliest_time = -1mon    # 1개월치 가속화
acceleration.backfill_time = -7d      # 초기 백필 기간
acceleration.max_time = 3600          # 가속화 검색 최대 실행 시간(초)
acceleration.schedule_priority = default

[Authentication]
acceleration = true
acceleration.earliest_time = -3mon
acceleration.cron_schedule = */5 * * * *  # 5분마다 업데이트

가속화 동작 흐름

5분마다가속화 검색 실행 → 새 이벤트를 tsidx에 추가

30분마다오래된 tsidx 정리 (retention 초과 데이터 제거)

쿼리 시tstats / Pivot → raw 이벤트 대신 tsidx에서 읽음

커스텀 Data Model 생성

예시: ERP 감사 로그용 커스텀 Data Model

UI 생성 경로: Settings → Data Models → New Data Model

Root Dataset 정의

# Root Object: ERP_Audit
# 기본 검색 (Constraint):
sourcetype=erp_audit

# → 이 데이터 모델은 ERP 감사 로그만 포함

Child Dataset 추가

# Child: ERP_Audit.Login_Events
# 추가 Constraint:
action IN ("login", "logout")

# Child: ERP_Audit.Data_Access
# 추가 Constraint:
object_category="customer_data"

JSON으로 직접 작성 (고급)

{
  "modelName": "ERP_Audit",
  "displayName": "ERP 감사 로그",
  "description": "ERP 시스템 감사 추적",
  "objects": [{
    "objectName": "ERP_Audit",
    "displayName": "ERP 감사",
    "parentName": "BaseEvent",
    "constraints": [{"search": "sourcetype=erp_audit"}],
    "fields": [
      {"fieldName": "user", "displayName": "사용자", "type": "string"},
      {"fieldName": "action", "displayName": "동작", "type": "string"},
      {"fieldName": "object", "displayName": "대상 객체", "type": "string"},
      {"fieldName": "result", "displayName": "결과", "type": "string"}
    ]
  }]
}

tstats + Data Model 심화 예시

기본 문법

| tstats <집계함수>
  FROM datamodel=<모델명>.<오브젝트명>
  WHERE <조건>
  BY <필드> [span=<시간>]

실제 예시 — 웹 상태코드 분석

| tstats count AS req_count,
         dc(Web.src_ip) AS unique_ips,
         avg(Web.bytes) AS avg_bytes
  FROM datamodel=Web.Traffic
  WHERE Web.status >= 400 AND index=web
  BY Web.status, Web.uri_path
  SPAN=1h
| sort -req_count

prestats — 기존 파이프에서 연결

index=web sourcetype=nginx
| tstats prestats=t count FROM datamodel=Web
  WHERE index=web BY Web.status
| stats count BY Web.status
# prestats=t: 이전 파이프 결과를 tstats에 입력으로 사용

인증 실패 brute-force 탐지

| tstats count AS failures
  FROM datamodel=Authentication.Failed_Authentication
  WHERE Authentication.action="failure"
    AND earliest=-15m
  BY Authentication.src, Authentication.user
| where failures > 10
| sort -failures

tstats 성능 팁

•FROM datamodel=모델명.오브젝트명 형식 — 오브젝트까지 지정해야 tsidx 최적화
•WHERE에 index= 조건 추가 → 검색 범위 축소
•BY 절 필드는 가속화된 필드만 사용 (그 외는 느려짐)
•allow_old_summaries=t 옵션으로 갭이 있어도 빠르게 처리
•DC (Distinct Count) 함수는 비용이 큼 — 필요할 때만 사용

Pivot vs tstats — 언제 어떤 걸 쓸까?

Pivot (GUI)

추천 상황: SPL 몰라도 되는 팀원, 빠른 보고서 생성

•Data Model 기반 드래그앤드롭 UI
•코드 없이 필터/집계/차트 생성
•비개발자/분석가 친화적
•생성된 보고서를 SPL로 변환해 볼 수 있음
•유연성 제한 (복잡한 로직 어려움)

tstats (SPL)

추천 상황: Correlation Search, 대량 데이터, 세밀한 제어

•tsidx 직접 조회 → 가장 빠른 집계
•WHERE 조건, prestats, 복잡한 JOIN 지원
•Splunk ES Correlation Search에서 주로 사용
•가속화 안 된 필드엔 성능 이점 없음
•개발자/보안 분석가 친화적