Splunk 검색 규칙을 Microsoft Sentinel 마이그레이션

Splunk 검색 규칙은 Microsoft Sentinel 분석 규칙과 비교되는 SIEM(보안 정보 및 이벤트 관리) 구성 요소입니다. 이 문서에서는 Microsoft Sentinel 식별, 비교 및 마이그레이션하는 개념을 설명합니다. 가장 좋은 방법은 자동으로 변환할 OOTB(기본 제공) 분석 규칙을 식별하는 SIEM 마이그레이션 환경으로 시작하는 것입니다.

Splunk 가시성 배포를 마이그레이션하려는 경우 Splunk에서 Azure 모니터 로그로 마이그레이션하는 방법에 대해 자세히 알아보세요.

감사 규칙

Microsoft Sentinel 기계 학습 분석을 사용하여 충실도가 높고 실행 가능한 인시던트가 생성됩니다. 기존 Splunk 검색 중 일부는 Microsoft Sentinel 중복될 수 있으므로 모두 맹목적으로 마이그레이션하지 마세요. 기존 검색 규칙을 식별할 때 이러한 고려 사항을 검토합니다.

• 비즈니스 우선 순위 및 효율성을 고려하여 규칙 마이그레이션을 정당화하는 사용 사례를 선택해야 합니다.
• Microsoft Sentinel 규칙 유형을 이해하고 있는지 확인합니다.
• 규칙 용어를 이해하고 있는지 확인합니다.
• 지난 6~12개월 동안 경고가 없는 오래된 규칙을 검토하고 여전히 관련성이 있는지 확인합니다.
• 일상적으로 무시하는 하위 수준 위협 또는 경고를 제거합니다.
• 연결된 데이터 원본을 확인하고 데이터 연결 방법을 검토합니다. Microsoft Sentinel 규칙을 사용하도록 설정하기 전에 데이터 형식이 Log Analytics 작업 영역에 있어야 합니다. 데이터 수집 대화를 다시 검토하여 검색하려는 사용 사례 전반에서 데이터 깊이와 폭을 확인합니다. 그런 다음 SIEM 마이그레이션 환경을 사용하여 데이터 원본이 적절하게 매핑되도록 합니다.

규칙 마이그레이션

마이그레이션할 Splunk 검색을 식별한 후 마이그레이션 프로세스에 대한 다음 고려 사항을 검토합니다.

• Microsoft Sentinel OOTB 분석 규칙의 기존 기능을 현재 사용 사례와 비교합니다. SIEM 마이그레이션 환경을 사용하여 OOTB 템플릿으로 자동으로 변환되는 Splunk 검색을 확인합니다.
• OOTB 분석 규칙에 맞지 않는 검색을 변환합니다. Splunk 검색을 자동으로 변환하는 가장 좋은 방법은 SIEM 마이그레이션 환경을 사용하는 것입니다.
• SOC Prime Threat Detection Marketplace와 같은 커뮤니티 리소스를 탐색하여 사용 사례에 대한 더 많은 알고리즘을 알아봅니다.
• 기본 제공 규칙을 사용할 수 없거나 자동으로 변환되지 않는 경우 검색을 수동으로 변환합니다. 새 KQL 쿼리를 만들고 규칙 매핑을 검토합니다.

자세한 내용은 검색 규칙 마이그레이션 모범 사례를 참조하세요.

규칙 마이그레이션 단계

1. 마이그레이션하려는 각 규칙에 대한 테스트 시스템이 있는지 확인합니다.

   1. 전체 테스트 시나리오 및 스크립트를 포함하여 마이그레이션된 규칙에 대한 유효성 검사 프로세스를 준비합니다.

   2. 팀에 마이그레이션된 규칙을 테스트하는 데 유용한 리소스가 있는지 확인합니다.

   3. 필요한 데이터 원본이 연결되어 있는지 확인하고 데이터 연결 방법을 검토합니다.

2. 검색을 Microsoft Sentinel OOTB 템플릿으로 사용할 수 있는지 확인합니다.

   • SIEM 마이그레이션 환경을 사용하여 OOTB 템플릿의 번역 및 설치를 자동화합니다.

     자세한 내용은 SIEM 마이그레이션 환경 사용을 참조하세요.

   • 검색에 반영되지 않은 사용 사례가 있는 경우 OOTB 규칙 템플릿을 사용하여 사용자 고유의 작업 영역에 대한 규칙을 만듭니다.

     Microsoft Sentinel 콘텐츠 허브로 이동합니다.

     분석 규칙 템플릿에 대한 콘텐츠 형식을 필터링합니다.

     해당하는 각 콘텐츠 허브 솔루션 또는 독립 실행형 분석 규칙 템플릿을 찾아 서 설치/업데이트 합니다.

     자세한 내용은 기본 제공 위협 검색을 참조하세요.

   • Microsoft Sentinel OOTB 규칙에서 다루지 않는 검색이 있는 경우 먼저 자동 변환을 위해 SIEM 마이그레이션 환경을 사용해 보세요.

   • OOTB 규칙이나 SIEM 마이그레이션이 검색을 완전히 변환하지 않으면 규칙을 수동으로 만듭니다. 이러한 경우 다음 단계를 사용하여 규칙을 만듭니다.

     1. 규칙에서 사용할 데이터 원본을 식별합니다. 데이터 원본과 데이터 테이블 간에 매핑 테이블을 만들어 쿼리하려는 Microsoft Sentinel 테이블을 식별합니다.

     2. 규칙에서 사용하려는 데이터의 특성, 필드 또는 엔터티를 식별합니다.

     3. 규칙 조건 및 논리를 식별합니다. 이 단계에서는 KQL 쿼리를 생성하는 방법에 대한 샘플로 규칙 템플릿을 찾는 것이 좋습니다.

        필터, 상관 관계 규칙, 활성 목록, 참조 집합, 관심 목록, 검색 변칙, 집계 등을 고려합니다. 레거시 SIEM에서 제공하는 참조를 사용하여 쿼리 구문을 가장 잘 매핑하는 방법을 이해할 수 있습니다.

     4. 트리거 조건 및 규칙 작업을 식별한 다음, KQL 쿼리를 생성하고 검토합니다. 쿼리를 검토할 때 KQL 최적화 지침 리소스를 고려합니다.

3. 각 관련 사용 사례를 사용하여 규칙을 테스트합니다. 예상 결과를 제공하지 않는 경우 KQL을 검토하고 편집한 다음 다시 테스트합니다.

4. 만족하면 마이그레이션된 규칙을 고려합니다. 필요에 따라 규칙 작업에 대한 플레이북을 만듭니다. 자세한 내용은 Microsoft Sentinel 플레이북을 사용하여 위협 대응 자동화를 참조하세요.

분석 규칙에 대해 자세히 알아보세요.

• 위협을 감지하는 사용자 지정 분석 규칙을 만듭니다. 경고 그룹화 를 사용하여 지정된 기간 내에 발생하는 경고를 그룹화하여 경고 피로를 줄입니다.
• SOC 엔지니어가 조사 중에 추적할 증거의 일부로 엔터티를 정의할 수 있도록 데이터 필드를 Microsoft Sentinel 엔터티에 매핑합니다. 또한 엔터티 매핑을 사용하면 SOC 분석가가 시간과 노력을 줄일 수 있는 직관적인 [조사 그래프](investigation-cases.md#use-the-investigation-graph-to-deep-dive)를 활용할 수 있습니다.
• 인시던트 미리 보기 창에서 특정 인시던트와 관련된 이벤트, 경고 및 책갈피를 표시하기 위해 증거를 사용하는 방법의 예로 UEBA 데이터를 사용하여 인시던트를 조사합니다.
• KQL(Kusto 쿼리 언어) - 데이터를 처리하고 결과를 반환하기 위해 Log Analytics 데이터베이스에 읽기 전용 요청을 보내는 데 사용할 수 있습니다. KQL은 엔드포인트용 Microsoft Defender 및 Application Insights와 같은 다른 Microsoft 서비스에서도 사용됩니다.

규칙 용어 비교

이 표에서는 SPL(검색 처리 언어)을 기반으로 하는 Splunk 검색과 비교하여 Microsoft Sentinel Kusto 쿼리 언어(KQL)를 기반으로 하는 규칙의 개념을 명확히 하는 데 도움이 됩니다.

규칙 샘플 매핑 및 비교

이러한 샘플을 사용하여 다양한 시나리오에서 Splunk에서 Microsoft Sentinel 규칙을 비교하고 매핑합니다.

일반 검색 명령

lookup 명령: KQL 예제

Users 
| where UserID in ((externaldata (UserID:string) [
@"https://storageaccount.blob.core.windows.net/storagecontainer/users.txt" 
h@"?...SAS..." // Secret token to access the blob 
])) | ... 

stats 명령: KQL 예제

Sales 
| summarize NumTransactions=count(), 
Total=sum(UnitPrice * NumUnits) by Fruit, 
StartOfMonth=startofmonth(SellDateTime) 

mstats 명령: KQL 예제

T | summarize count() by price_range=bin(price, 10.0) 

transaction command: SPL 예제

sourcetype=MyLogTable type=Event
| transaction ActivityId startswith="Start" endswith="Stop"
| Rename timestamp as StartTime
| Table City, ActivityId, StartTime, Duration

transaction 명령: KQL 예제

let Events = MyLogTable | where type=="Event";
Events
| where Name == "Start"
| project Name, City, ActivityId, StartTime=timestamp
| join (Events
| where Name == "Stop"
| project StopTime=timestamp, ActivityId)
on ActivityId
| project City, ActivityId, StartTime, 
Duration = StopTime – StartTime

를 사용하여 row_window_session() 직렬화된 행 집합의 열에 대한 세션 시작 값을 계산합니다.

...| extend SessionStarted = row_window_session(
Timestamp, 1h, 5m, ID != prev(ID))

eventstats command: SPL 예제

… | bin span=1m _time
|stats count AS count_i by _time, category
| eventstats sum(count_i) as count_total by _time

eventstats 명령: KQL 예제

다음은 문을 사용하는 예제입니다 join .

let binSize = 1h;
let detail = SecurityEvent 
| summarize detail_count = count() by EventID,
tbin = bin(TimeGenerated, binSize);
let summary = SecurityEvent
| summarize sum_count = count() by 
tbin = bin(TimeGenerated, binSize);
detail 
| join kind=leftouter (summary) on tbin 
| project-away tbin1

다음은 문을 사용하는 예제입니다 make_list .

let binSize = 1m;
SecurityEvent
| where TimeGenerated >= ago(24h)
| summarize TotalEvents = count() by EventID, 
groupBin =bin(TimeGenerated, binSize)
|summarize make_list(EventID), make_list(TotalEvents), 
sum(TotalEvents) by groupBin
| mvexpand list_EventID, list_TotalEvents

anomalydetection command: SPL 예제

sourcetype=nasdaq earliest=-10y
| anomalydetection Close _ Price

anomalydetection 명령: KQL 예제

let LookBackPeriod= 7d;
let disableAccountLogon=SignIn
| where ResultType == "50057"
| where ResultDescription has "account is disabled";
disableAccountLogon
| make-series Trend=count() default=0 on TimeGenerated 
in range(startofday(ago(LookBackPeriod)), now(), 1d)
| extend (RSquare,Slope,Variance,RVariance,Interception,
LineFit)=series_fit_line(Trend)
| extend (anomalies,score) = 
series_decompose_anomalies(Trend)

일반적인 eval 명령

case(X,"Y",…) SPL 예제

case(error == 404, "Not found",
error == 500,"Internal Server Error",
error == 200, "OK")

case(X,"Y",…) KQL 예제

T
| extend Message = case(error == 404, "Not found", 
error == 500,"Internal Server Error", "OK") 

if(X,Y,Z) KQL 예제

iif(floor(Timestamp, 1d)==floor(now(), 1d), 
"today", "anotherday")

isint(X) KQL 예제

iif(gettype(X) =="long","TRUE","FALSE")

isstr(X) KQL 예제

iif(gettype(X) =="string","TRUE","FALSE")

like(X,"y") 예제

… | where field has "addr"

… | where field contains "addr"

… | where field startswith "addr"

… | where field matches regex "^addr.*"

min(X,…) KQL 예제

min_of (expr_1, expr_2 ...)

…|summarize min(expr)

…| summarize arg_min(Price,*) by Product

mvfilter(X) KQL 예제

T | mv-apply Metric to typeof(real) on 
(
 top 2 by Metric desc
)

mvjoin(X,Y) KQL 예제

strcat_array(dynamic([1, 2, 3]), "->")

relative time(X,Y) KQL 예제

let toUnixTime = (dt:datetime)
{
(dt - datetime(1970-01-01))/1s 
};

replace(X,Y,Z) KQL 예제

replace( @'^(\d{1,2})/(\d{1,2})/', @'\2/\1/',date)

strptime(X,Y) KQL 예제

format_datetime(datetime('2017-08-16 11:25:10'),
'HH:mm')

time() KQL 예제

format_datetime(datetime(2015-12-14 02:03:04),
'h:m:s')

tostring(X,Y)

필드 값을 X 문자열로 반환합니다.

• 값 X 이 숫자인 경우 는 X 문자열 값으로 다시 포맷됩니다.
• 가 부울 값이면 X 가 X 또는 FALSE로 TRUE 다시 포맷됩니다.
• 가 숫자인 경우 X 두 번째 인수 Y 는 선택 사항이며(16진수로 변환X), commas (쉼표와 소수 자릿수가 있는 형식X) 또는 duration (시간 형식에서 읽기 가능한 시간 형식으로 변환X: HH:MM:SS)일 수 hex 있습니다.

tostring(X,Y) SPL 예제

이 예제에서는 다음을 반환합니다.

foo=615 and foo2=00:10:15:

… | eval foo=615 | eval foo2 = tostring(
foo, "duration")

urldecode(X) SPL 예제

urldecode("http%3A%2F%2Fwww.splunk.com%2Fdownload%3Fr%3Dheader")

일반적인 stats 명령 KQL 예제

다음 단계

이 문서에서는 Splunk에서 Microsoft Sentinel 마이그레이션 규칙을 매핑하는 방법을 알아보았습니다.