SIEM, EDR, XDR 간 탐지 규칙 이식성

탐지 규칙의 이동성은 위협 탐지 논리를 작성하고 관리하여 전체적으로 다시 쓰지 않고도 SIEM, EDR, XDR 플랫폼 간에 이동할 수 있도록 하는 관행입니다.

새로운 SIEM 플랫폼으로 전환하면 내 탐지 규칙은 어떻게 되나요?

플랫폼의 고유 쿼리 언어로 작성된 규칙은 이동하지 않습니다. SPL은 Splunk에 그대로 있고 KQL은 Microsoft Sentinel에 그대로 있습니다. YARA-L은 Google SecOps에 그대로 있습니다. 이주할 때 이러한 규칙은 대상 플랫폼에 맞게 다시 작성하거나 번역해야 합니다.

번역 충실도는 언어 쌍이 아닌 구성에 따라 다릅니다. 두 가지 저하 축이 생존하는 것을 결정합니다.

축 1: 필드 매핑. 소스 필드 분류법(CIM, ASIM, ECS, OCSF, Sysmon-native, 벤더 고유)은 불완전하게 매핑됩니다. 매핑되지 않거나 이름이 변경된 필드는 규칙을 조용히 좁히거나 깨뜨립니다.

축 2: 구성 의미론. 집계 및 시간 창 의미론, 순서 또는 트랜잭션 논리, 정규 표현식 방언 및 평가/조회/조인 스타일 함수는 대상 플랫폼에서 부분적으로만 유사한 기능을 갖고 있습니다. 이 축이 재작성의 비율을 차지합니다.

Sigma 규칙은 번역을 위해 설계되었습니다. 작성 후 각 백엔드로 번역됩니다. pySigma, sigma-cli또는 Uncoder.

번역은 보존이 아닙니다. 번역된 각 규칙은 신뢰하기 전에 대상의 구문 분석된 필드에 대해 백엔드별로 검증해야 합니다. 구문적으로 올바른 번역이라도 새 플랫폼에 존재하지 않는 필드를 참조할 수 있습니다.

텔레메트리 파이프라인 라우팅은 별도의 메커니즘입니다. 로그 스트림을 새 목적지로 라우팅한다고 해서 거기서 실행되던 탐지 논리가 이동되지는 않습니다. SPL은 로그가 어디에 도착하더라도 그대로 SPL입니다.

벤더 특정 탐지 규칙과 벤더 독립 탐지 규칙의 차이는 무엇입니까?

벤더 특정 규칙은 플랫폼의 자산입니다. 벤더 독립 규칙은 팀의 자산입니다.

차원	SPL (Splunk)	KQL (Microsoft Sentinel)	YARA-L (Google SecOps)	Sigma
네이티브로 작동	Splunk	Microsoft Sentinel	Google SecOps	직접적으로는 없습니다. IBM QRadar, Elastic, CrowdStrike 및 기타 소프트웨어에도 번역됩니다.
이를 이동하려면	대상 언어로 재작성	대상 언어로 재작성	대상 언어로 재작성	pySigma/sigma-cli 또는 Uncoder를 통한 번역, 그런 다음 필드 매핑 검증
소유 주체	Splunk 배포	Sentinel 워크스페이스	SecOps 테넌트	버전 관리 중인 귀하의 팀
멀티 플랫폼 비용	N 복사본 작성	N 복사본 작성	N 복사본 작성	백엔드별로 한 번 변환하고 백엔드별로 한 번 검증

이 비용 차이는 이주 및 멀티 플랫폼 운영 시 나타납니다. 벤더 독립 탐지 논리는 스택 전체에서 이동 가능합니다.

Splunk에서 Microsoft Sentinel로 탐지 콘텐츠를 어떻게 이주합니까?

6단계입니다. SPL과 KQL은 데이터 모델, 필드 명명 및 함수 의미론에서 차이가 있기 때문에 이 언어 쌍은 더 어렵습니다.

SPL 규칙 조사. 저장된 모든 검색, 경고, 상관 검색을 내보냅니다. 각 규칙의 데이터 모델 종속성(소스 유형, 색인, 필드 이름)을 기록합니다.

구조 유형별로 분류합니다. 규칙을 세 가지로 분류합니다: 간단한 선택 논리 (깨끗하게 이식), 필드 매핑 종속 (매핑 작업과 함께 이식), 상관/상태 논리 (수동 재작성 예상).

Sigma를 통해 번역합니다. SPL 규칙을 Sigma로 변환한 다음 Microsoft Sentinel 백엔드, sigma-cli 또는 Uncoder를 사용하여 pySigma로 Sigma를 KQL로 번역합니다. 이는 구문을 처리합니다. 필드 매핑은 처리하지 않습니다.

Sentinel 스키마에 맞게 필드를 매핑합니다. CIM 필드명을 ASIM 등가물에 맞춥니다. Microsoft는 그들의 스키마를 learn.microsoft.com에서 문서화합니다. 번역된 규칙의 모든 필드는 대상 테이블의 열로 해결되어야 합니다.

Sentinel 테이블에서 테스트합니다. 번역된 각 규칙을 실제 수집된 데이터에 대해 실행합니다. 스키마 변경 후 매칭을 검증할 수 있도록 규칙마다 테스트 이벤트를 유지하십시오.

병렬 실행 창과 함께 전환하십시오. 두 플랫폼에서 동일한 로그 소스를 실행합니다. 경고 출력을 비교합니다. 동일한 이벤트에 대해 KQL 버전이 작동하는 경우에만 SPL 버전을 은퇴합니다.

전환 전에 두 플랫폼에 배포된 규칙을 MITRE ATT&CK 기술에 매핑하고 두 지도를 비교하여 전환 후가 아닌 전환 전에 누락된 기술이 드러나도록 합니다. SOC Prime의 MITRE ATT&CK 감사가 감지 및 데이터 소스를 ATT&CK와 서비스로 매핑합니다. MITRE ATT&CK 감사 이주 전에는 기술이 누락된 경우가 드러나도록 합니다.

규칙 라이브러리를 이주 중인가요? SOC Prime의 Prime Architect 를 사용하여 크로스 플랫폼 규칙 번역, 위협 연구 및 탐지 엔지니어링 워크플로를 탐색하세요.

영업 문의

SPL과 같은 쿼리 언어를 KQL로 번역하는 모범 사례는 무엇입니까?

구문이 아닌 논리를 번역하십시오. 문자별 이동은 대상이 인구를 채우지 않을 수 있는 필드를 참조하는 취약한 규칙을 생성합니다.

대상 스키마에 맞춰 필드를 매핑하십시오. 필드 이름이 그대로 전환된다고 가정하지 마십시오. Splunk CIM과 Sentinel ASIM은 다른 계약입니다. 이주 작업은 이들 간 매핑에 달려 있습니다.
규칙당 테스트 이벤트를 유지하십시오. 알려진 나쁜 이벤트와 알려진 선의의 이벤트가 짝을 이룹니다. 번역된 규칙이 나쁜 것을 일치시키지 않고 선의의 것을 거부하지 않으면 번역에서 무언가가 잘못된 것입니다.
번역기가 플래그 지정한 모든 것을 검토하십시오. 자동화된 번역기는 일반 선택 논리를 잘 처리합니다. 상관 규칙, 고유 함수 및 복잡한 집계는 인간의 검토가 필요합니다.
도구를 명명하십시오. Prime Architect Sigma를 65개의 탐지 언어로번역하고 SPL 및 KQL과 같은 기본 쿼리 언어 간을 마이그레이션하여 연결된 환경에 필드 매핑 사전 설정을 적용하고 관리되는 규칙 저장소에서 지원되는 대상 플랫폼으로 배포합니다. 오픈 소스 Uncoder IO는 번역 단계를 다루며 자체 호스팅할 수 있습니다 ( Uncoder IO GitHub 소스에서). 필드 매핑 검증을 제거하지 않는 이 세 가지 중 어떤 것도 없습니다.).

예: EventCode=4688 및 New_Process_Name(Splunk CIM)을 EventID == 4688 및 NewProcessName(Sentinel SecurityEvent 테이블)으로 번역하는 간단한 프로세스 생성 규칙. 동일한 사실, 플랫폼 계약당 필드 이름이 다릅니다.

SPL의 끝에 고정된 와일드카드는 KQL endswith 연산자가 됩니다. 이 쌍은 단일 이벤트 필드 매칭이기 때문에 작동합니다. 상관 규칙은 이렇게 깔끔하게 번역되지 않습니다.

규칙 라이브러리 이주는 얼마나 걸리며 무엇이 이를 결정합니까?

세 가지 원동력이 노력을 결정합니다.

규칙 수. 규칙이 많을수록 검증 사이클이 더 많습니다. 번역된 각 규칙은 대상에 수집된 데이터를 대상으로 한 테스트 실행이 필요합니다.

사용자 정의 필드 및 데이터 모델 종속성. 벤더 고유 필드, 사용자 지정 추출 또는 조회 테이블을 참조하는 규칙은 필드별 매핑 작업이 필요합니다. 소스에 커스터마이즈가 많을수록 마이그레이션 작업이 많아집니다.

검증 노력. 번역된 각 규칙은 대상 플랫폼의 구문 분석된 필드에 대해 검증해야 합니다. 구문으로 올바른 번역은 대상 스키마가 참조된 필드를 채우지 않으면 조용히 실패할 수 있습니다.

이주 평가를 통해 제공되는 솔직한 결과물은 규칙 하나당 분류입니다: 깨끗하게 이식, 매핑이 가능한 경우 처리, 수동 재작성 필요. 전체 라이브러리를 위한 단일 시간 추정치는 노력의 분포를 잘못 나타냅니다.

다음 번에는 잠금 상태를 피하려면 어떻게 해야 할까요?

세 가지 실천 사항.

Sigma에서 작성하십시오. 처음부터 벤더 독립 탐지 논리를 작성하십시오. Sigma 규칙은 모든 주요 SIEM, EDR 및 XDR 플랫폼에 번역됩니다. SOC Prime의 Core에 있는 Sigma 규칙과 같이 이미 Sigma에서 소싱된 탐지 콘텐츠는 첫 번째 규칙부터 라이브러리를 이동 가능하게 유지합니다. SOC Prime’s Core에 있는 Sigma 규칙과 같은 경우에 탐지 콘텐츠 소스는 처음부터 라이브러리를 이동 가능하게 유지합니다.

논리를 버전 제어로 유지하십시오. 대상 백엔드에 대한 필드 매핑 및 테스트 이벤트와 함께 Git에서 탐지 규칙을 저장하십시오. 규칙은 플랫폼이 아니라 팀과 함께 이동합니다.

배포 시에 번역하십시오. pySigma, sigma-cli 또는 Uncoder를 사용하여 배포 시 플랫폼 네이티브 쿼리를 생성합니다. 소스는 이동 가능하게 유지됩니다. 컴파일된 출력은 일회용입니다.

이러한 분리는 플랫폼 마이그레이션이 탐지 논리가 아닌 번역 대상을 변경한다는 것을 의미합니다.

파이프라인을 통한 텔레메트리 라우팅이 탐지 이동성을 제공합니까?

아니오. 텔레메트리 파이프라인(Cribl 및 유사 도구)은 데이터를 이동합니다. 탐지 논리를 이동하지 않습니다.

파이프라인을 통해 Splunk에서 Microsoft Sentinel로 로그 스트림을 라우팅하면 이벤트가 새 목적지로 제공됩니다. Splunk에서 해당 이벤트에 대해 실행되던 SPL 규칙은 따라가지 않고 그대로 SPL로 남아 있습니다. 감지 논리는 대상 플랫폼에 대해 여전히 번역되거나 다시 작성되어야 합니다.

파이프라인 라우팅은 데이터 전송 문제를 해결합니다. 탐지 이동 가능성은 논리 번역 문제를 해결합니다. 이는 독립적입니다. 탐지를 이식하지 않고 텔레메트리를 새 SIEM으로 라우팅하는 팀은 새로운 장소에 데이터를 두고 매칭할 규칙이 없게 됩니다.

예외는 탐지 자체를 실행하는 파이프라인입니다: SOC Prime의 Prime Detect는 SIEM 전에 파이프라인 계층에서 Sigma 규칙을 적용하며, 오픈 소스 버전은 GitHub에 있습니다. GitHub.

에서.

Sigma로도 모든 것이 번역되지는 않습니다. 네 가지 구조 클래스는 대상 플랫폼에서 수동 재작성이 필요합니다.

상관 및 상태 논리. 개수 및 값 집계, 시간 순서, 다중 이벤트 상관 관계. Sigma는 v2 사양에서 상관 규칙 유형을 추가했지만 pySigma 백엔드에 따라 백엔드 지원이 다릅니다. 일정 설정 대 스트리밍 실행도 규칙의 표현 가능성을 변경합니다.
독점 함수. Splunk 트랜잭션, 평가 표현식, 조회 기반 강화, 매크로. KQL 유사체는 부분적입니다.
일부 집계 패턴. 창을 넘어선 임계값 구성 및 통계 … by … span= 패턴은 플랫폼 간 고르게 번역되지 않습니다.
스키마 의존 필드 참조. 동일한 Sigma 프로세스 생성 규칙은 파이프라인에 따라 다른 필드에 놓입니다. Sysmon에서는 Image입니다. Splunk Windows Security에서는 New_Process_Name입니다. 번역은 실제 배포된 스키마에 대해서만 올바릅니다.

이러한 구조는 규칙별 분류가 가장 중요한 곳입니다. 수동 검증이 필요하며 많은 경우 처음부터 재작성해야 할 것을 예상하십시오.

이주 준비 체크리스트

[ ] 전체 규칙 인벤토리 내보내기 (저장된 검색, 경고, 상관 관계 검색)

[ ] 각 규칙 분류: 깨끗하게 이식 / 매핑 작업 필요 / 재작성 필요

[ ] 필드 매핑 표 구축: 소스 스키마에서 대상 스키마로

[ ] 이동 가능한 규칙의 Sigma 버전 생성 및 버전 관리에 저장

[ ] 번역 도구 선택 (pySigma/sigma-cli, Uncoder, 또는 둘 다)

[ ] 규칙당 테스트 이벤트 쌍 생성 (하나는 알려진 나쁜, 하나는 알려진 선의의)

[ ] 번역된 규칙을 실제 수집된 데이터와 함께 대상 테이블에 대해 검증 완료

[ ] 수동으로 재작성이 필요한 상관 및 상태 규칙 식별

[ ] 독점 함수 카탈로그 작성 (트랜잭션, 평가, 조회, 매크로)

[ ] 병렬 실행 창 정의: 두 플랫폼에서 동일한 소스를 수집

[ ] 경고 출력 비교 기준 문서화

[ ] 소스 플랫폼으로 복귀하기 위한 롤백 계획 정의

FAQ

새로운 SIEM 플랫폼으로 전환하면 내 탐지 규칙은 어떻게 되나요?

플랫폼 네이티브 규칙은 이동하지 않습니다. SPL, KQL 및 YARA-L은 대상 플랫폼에 맞게 다시 작성되거나 번역되어야 합니다. Sigma에서 작성한 규칙은 백엔드별로 한 번 번역되며, 번역된 각 규칙은 대상의 구문 분석된 필드를 대상으로 검증해야 합니다. 상관, 상태 논리, 독점 함수, 일부 집계 패턴은 깔끔하게 번역되지 않습니다.

Splunk에서 Microsoft Sentinel로 탐지 콘텐츠를 어떻게 이주합니까?

SPL 규칙을 인벤토리화하고, 구성 유형별로 각각 분류한 후, Sigma와 pySigma 또는 Uncoder를 통해 번역하고, Splunk 스키마에서 Sentinel 스키마로 필드를 매핑하고, 진짜 Sentinel에 수집된 데이터에 대해 각 규칙을 테스트한 후, 병렬 실행 창과 함께 전환한 다음 SPL 버전을 은퇴합니다. Microsoft는 learn.microsoft.com에서 Sentinel 스키마를 문서화합니다.

벤더 특정 탐지 규칙과 벤더 독립 탐지 규칙의 차이점은 무엇입니까?

벤더 특정 규칙은 실행되는 플랫폼의 자산입니다. Sigma에서 작성된 벤더 독립 규칙은 팀의 자산이며, 버전 관리에서 유지되며 백엔드별로 번역됩니다. 이러한 비용 차이는 이주와 멀티 플랫폼 운영에서 드러납니다.

파이프라인을 통해 텔레메트리를 라우팅하면 감지를 이동할 수 있나요?

아니오. 텔레메트리 파이프라인은 데이터를 새 목적지로 이동합니다. 실행되던 탐지 논리를 이동하지 않습니다. SPL은 로그가 도착하는 곳마다 그대로 SPL로 남아 있으므로 규칙은 여전히 번역되거나 다시 작성해야 합니다.

SPL과 같은 쿼리 언어를 KQL로 번역하는 모범 사례는 무엇입니까?

구문이 아닌 논리를 번역하십시오. 대상 스키마에 맞춰 모든 필드를 매핑하고, 규칙마다 알려진 나쁜 것과 선의의 테스트 이벤트를 유지하며, 번역기가 플래그 표시한 모든 것을 검토하세요. 상관 규칙 및 독점 함수는 인간의 검토가 필요합니다. pySigma, sigma-cli 및 Uncoder는 Sigma 번역을 처리하며, 어떤 것도 필드 매핑 검증을 제거하지 않습니다.

기존 SIEM 범위를 평가하고 전환 계획을 세우십시오 Prime Hunt. Prime Hunt는 모든 SIEM 규칙을 검토하고, 격차를 식별하고, SIEM 마이그레이션 전에 필요한 전체 범위 작업을 수행합니다.