SIGMA 규칙이란 무엇인가: 초보자 가이드

[post-views]
5월 16, 2022 · 12 분 읽기
SIGMA 규칙이란 무엇인가: 초보자 가이드

이 블로그 게시물은 SIGMA를 탐지 언어로 활용하는 것을 주제로 하며, 가장 중요한 SIGMA 규칙 구성 요소(로그소스 및 탐지), SIGMA 분류 체계, SIGMA 규칙 테스트 등을 다룹니다. 및 SIGMA에 익숙하지 않은 분석가들이 첫 번째 규칙을 작성하도록 준비시키는 과정입니다. 또한, SIGMA를 이용한 탐지 엔지니어링에 대한 소음, 아이디어, 로그 소스 등의 짧은 토론도 제공합니다.

SIGMA 규칙 사례

과거에는 SIEM 탐지가 벤더/플랫폼별 사일로에 존재했습니다. 탐지 콘텐츠를 공유하려는 파트너들은 종종 한 벤더에서 다른 벤더로 쿼리를 번역해야 했습니다. 이는 지속 가능하지 않으며, 방어 사이버 보안 커뮤니티는 지속적으로 변화하는 적들과 보조를 맞추기 위해 탐지를 공유하는 방식을 개선해야 합니다.

YARA나 Snort 규칙과 마찬가지로, SIGMA는 파일이나 네트워크 트래픽 대신 SIEM에 초점을 둔 탐지를 공개적으로 공유하기 위한 또 다른 도구입니다. SIGMA는 방어자들이 공통 언어로 탐지(알림, 사용 사례)를 공유할 수 있도록 합니다.

Florian Roth와 Thomas Patzke에 의해 2017년 처음 공개된 SIGMA는 플랫폼에 구애받지 않는 검색의 길을 열고 있습니다. SIGMA 덕분에 방어자들은 벤더 및 플랫폼별 탐지 언어나 저장소에서 벗어나 커뮤니티의 힘을 활용하여 중요한 위협과 새로운 공격자 무역에 신속히 대응할 수 있습니다.

SIGMA를 사용하는 이유는 다양합니다:

  • 새로운 공격자 행동을 식별하고 탐지를 비디오 제품군 방식으로 공유하고자 하는 연구자 및 정보 팀
  • 다양한 SIEM / EDR / 로그 분석 솔루션 및 데이터 분류/스키마(ECS, CEF, CIM 등) 책임이 있는 MSSP / MDR
  • SIGMA 내에서 규칙을 정의함으로써 벤더 종속성을 피하고 플랫폼 간에 쉽게 이동할 수 있습니다.
  • 자신의 연구를 기반으로 탐지를 생성하려는 공략 보안 분야의 연구자들

참고: 이 블로그에서는 SIEM을 로그를 수집하고 검색하는 데 사용되는 모든 플랫폼을 설명하는 데 사용합니다. 여기에 나열된 많은 플랫폼이 ‘SIEM’이라는 정의에 들어맞지 않을 수도 있다는 것을 인식하고 있습니다. 하지만 ‘플랫폼’이나 ‘로그 플랫폼’이라는 용어는 너무 모호합니다.

SIGMA 규칙 생성

SIGMA 규칙을 작성하려면 SIGMA 스키마와 분류 체계에 대한 기본적인 지식, 아이디어, SIGMA에 적합한 아이디어, 테스트, 공유, 규칙 유지보수 등이 필요합니다.

이 블로그의 길이에도 불구하고 YAML과 창의적인 생각 덕분에 SIGMA는 쉽게 이해하고 작성할 수 있습니다. SOC Prime에서는 “누구나 SIGMA를 배울 수 있다”고 말하는 것을 좋아합니다. 탐지 엔지니어링의 예술은 더 복잡해질 수 있는 부분입니다.

Despite the length of this blog, thanks to YAML and forward thinking by the creators, SIGMA is easy to understand and write. At SOC Prime we like to say “anyone can learn SIGMA”. The art of detection engineering is where things can get more complicated. 

다음과 같은 많은 다른 리소스들이 있습니다 공식 위키 및 SIGMA 전문가들이 작성한 몇 가지 가이드가 있습니다(아래에 나열됨). 특정 함정이 있는데, 예를 들면 와일드카드의 적절한 처리 or 잘못된 필드 이름 이러한 것들이 깨진 규칙을 유발할 수 있으며, 이들 대부분은 이러한 리소스에서 다루어집니다.

SIGMA에 입문하려는 연구자라면, SOC Prime의 위협 포상 프로그램은 시작하고 약간의 현금을 벌 수 있는 좋은 기회입니다. 제출된 규칙은 철저한 검토 과정을 거치며, 여기서 우리는 귀하를 안내하고 잘못 이해한 것을 이해하도록 도와드리며 분석가로서 성장할 수 있도록 도와드립니다.

추천 읽기:

추천 관람:

SIGMA 규칙이 표현할 수 있는 탐지 유형

현재 두 가지 기본 유형의 규칙이 있습니다:

  • 일치에 기반을 둔 SIGMA 규칙은 널리 지원되며 작성하기 가장 쉬움
  • 일치 및 단순 상관관계를 기반으로 하는 SIGMA 규칙은 제한된 지원, 작성하기 덜 쉬움

참고: 다중 YAML SIGMA 규칙도 있지만, 이러한 규칙은 일반적으로 로그 소스 특정 규칙에 비해 인기가 줄어들었습니다. SOC Prime 팀은 일반적으로 다중 YAML 규칙을 만들지 않습니다. 이는 규칙 유지보수 및 배포에 불필요한 복잡성을 추가하기 때문입니다. 한 사람이 두 개의 SIGMA 규칙을 만들 수 있다면 다중 YAML SIGMA 규칙을 만들 수 있습니다.

간단한 SIGMA 규칙을 만들어 봅시다!

아이디어 (및 SIGMA와 함께하는 탐지 엔지니어링에 대한 몇 가지 생각)

사용자와 관리자들은 종종 텍스트 파일, 엑셀, 워드 등과 같은 평문 문서에 민감한 비밀번호를 보관합니다. 저는 적들이 환경 내에서 제가 발견하기 전에 이러한 파일을 식별할 수 있다는 점이 걱정됩니다. 우리는 사용자들에게 범죄 해커가 발견하기 전에 비밀번호를 올바르게 저장하는 방법을 지시하려고 합니다.

많은 SIGMA 규칙에서는 아이디어를 추상화하고 타겟을 ‘합리적으로’ 확대하는 것이 작성자에게 유익합니다. 이러한 아이디어에서는 설명된 행동만이 아니라 ‘보일 수 있는’ 행동에 대한 교육받은 추측을 할 수 있습니다. 예를 들어, 사용자가 비밀번호를 평문으로 저장하는 데 사용할 수 있는 추가 용어 및 확장에 대한 교육받은 추측을 할 수 있습니다. may 룰을 ‘확대’하는 아이디어는 많은 분석가의 본능에 반하는 것입니다. 모든 ‘거짓 긍정’을 제거하는 것이 규칙이 알려지지 않은 낯선 환경에서 소비될 때 원 저자의 목표가 아닙니다. 우리는 EDR 및 앤티바이러스 벤더가 거짓 긍정이 없는 탐지를 만드는 것에 대해 걱정하게 할 수 있습니다. SIGMA 규칙은 환경에서 테스트되고 쉽게 조정될 수 있습니다.

SIGMA는 쉽게 이해되고, 테스트 가능하며, 조정이 가능합니다. ‘세부 사항’과 같은 용어가 환경에 대해 너무 시끄러울 경우, 규칙을 구현하는 사람은 규칙을 조정할 수 있는 권한을 느껴야 합니다. 테스트 없이 모든 규칙을 한 번에 배포하면 재앙의 레시피가 됩니다. 규칙의 의도를 환경에 맞춰 다루고 조정하지 않고 규칙을 끄면 견고한 탐지 콘텐츠를 놓치게 됩니다.

SIGMA is easily understood, testable, and tunable. If a term like ‘details’ is too noisy for an environment, the person implementing the rule should feel empowered to tune the rule. Deploying all rules at once without testing is a recipe for disaster. Turning rules off instead of digesting and tuning their intentions for an environment will cause a shop to miss out on solid detection content. 

저는 psexec의 예를 드는 것을 좋아합니다. 어떤 환경에서는 psexec가 완전히 정상이며 호스트를 원격으로 관리할 때 관리자의 기본 방침입니다. 다른 환경에서는 psexec가 (아마도 정당하게) 승인되지 않았고 차단되며 관리자가 사용하는 것이 위반 행위로 간주됩니다. 따라서 모든 psexec 사용을 탐지하기 위한 SIGMA 규칙이 ‘시끄럽다’는 것은 환경에 따라 다를 수 있습니다. 테스트 없이 콘텐츠를 배포하면 소음을 조정하는 것이 항상 문제가 될 것입니다. ‘중요한’ 규칙으로 식별된 규칙만이 테스트 없이 안전하게 사용할 수 있도록 설계되었습니다.

우리의 비밀번호 노출 SIGMA 규칙을 생성하는 데 다시 돌아와서… 추가 파일 이름을 포함하도록 아이디어를 확장할 수 있습니다:

  • pw
  • psw
  • pass
  • 비밀번호
  • 비밀번호들
  • 계정들
  • 계정
  • 정보

와 같은 소프트웨어로 생성됨:

  • 메모장
  • 메모장++
  • 워드패드
  • 오피스 애플리케이션

데이터 소스 / 로그 소스

아이디어가 있으면 로그 소스가 필요합니다. SIGMA는 이론적으로 any 로그 소스를 지원하지만, 대부분의 사람들이 사용하는 로그 소스를 식별해야 합니다. 예를 들어, 데이터 손실 방지 로그 소스에 대한 규칙을 작성할 수는 있지만, 데이터 손실 방지는 드물게 SIEM에 구문 분석되어 수집되며, 업계에선 분명한 선호도가 없습니다. 그래서 유효한 규칙을 만들 수는 있지만, 채택되기가 어렵습니다.

Windows 엔드포인트 규칙의 경우, Sysmon은 시작하기에 좋은 장소입니다. Sysmon은 환경에 일반적으로 배포되며, 많은 로그 소스가 동의어 데이터를 제공합니다(EDRs 등). Sysmon에는 두 가지 주요 옵션이 있습니다: 프로세스 생성(Sigma에서 process_creation)과 파일 생성(Sigma에서 file_event).

프로세스 생성을 기반으로 탐지를 구축하므로 규칙이 가능한 한 유용하게 만들 수 있습니다. 프로세스 생성은 학습할 가치가 높은 훌륭한 로그 소스이며, 가장 유용하고 인기 있는 엔드포인트 탐지에 사용되는 로그 소스 중 하나입니다.

참고: 아이디어는 종종 데이터 소스 자체에서 직접 나옵니다. SIEM / 연구실에서 제공되는 데이터 유형을 검토하여 쉽게 쓸만한 SIGMA 규칙을 식별할 수 있습니다. 또한 공급 업체 문서와 같은 다른 자료를 사용할 수 있습니다.

sysmon 프로세스 생성 이벤트(이벤트 ID 1)를 사용하면 비밀번호가 포함된 파일에 접근하는 사용자가 다음과 같은 흥미로운 필드를 포함할 수 있습니다:

이미지: C:WindowsSystem32notepad.exe
명령줄: "C:WindowsSystem32NOTEPAD.EXE" C:UsersJohnDesktoppassword.txt

탐지 아이디어를 SIGMA에 맞추기

아이디어가 있고 작업할 데이터 소스가 있으면 규칙을 작성하기 시작할 수 있습니다.

문서화되지 않았지만, 규칙을 번역하는 데 필요한 구성 요소 는 오직 로그소스 & 탐지 (Splunk와 같은 일부 백엔드의 경우, 탐지만으로 충분합니다). 나머지는 SIGMA 규칙 소비자를 돕기 위한 ‘단지’ 메타 데이터입니다. 시작할 때는 이러한 최소 필드로 시작하는 것이 여러분의 이익이며 논리가 작동하는지 확인한 후 추가 SIGMA 필드 및 데이터를 추가하는 것이 좋습니다. 여러분의 규칙을 공개 SIGMA 저장소에 게시하고 싶다면, 이전 제출물을 확인하고 그들의 형식을 모방하는 것이 좋습니다.

잠재적 비밀번호 노출에 대한 기본 SIGMA 규칙 (최소 구성 요소):

제목: 잠재적 비밀번호 노출(명령줄을 통해)
저자: Adam Swan
태그:
  - attack.t1552.001 
  - attack.credential_access
로그소스:
  제품: windows
  카테고리: process_creation
탐지:
  선택:
    Image|endswith: 
      - 'notepad.exe'
      - 'word.exe'
      - 'excel.exe'
      - 'wordpad.exe'
      - 'notepad++.exe'
    CommandLine|contains:
      - 'pass' #비밀번호에 걸리며, 비밀번호 포함은 중복입니다
      - 'pwd'
      - 'pw.' #pw.txt 등 
      - '계정' #계정들
      - '비밀'
      - '세부 사항' #경험을 바탕으로 복수형 세부 사항을 포함했습니다
  조건: 선택

로그소스 구성 요소

The 로그소스 구성 요소는 SIGMA 백엔드 변환기(SIGMAC)가 해당 규칙이 어떤 데이터에 적용되어야 하는지 이해하는 데 도움이 됩니다. 규칙 작성자가 더 일반적인 규칙을 만들 수 있도록 합니다. 예를 들어, 로그소스 “제품: windows, 카테고리: process_creation”일 경우, 우리는 EventIDs(Sysmon 1, Windows 4688, ProcessRollup 등)를 지정할 필요가 없습니다. 규칙의 소비자는 SIGMA 구성에서 로그 소스와 연결하고자 하는 이벤트 ID, 인덱스 등을 지정할 수 있습니다. 인덱스, 이벤트 ID 등을 지정하지 않으면 소비자에게 불필요하게 성능이 비싼(비효율적인) 규칙이 될 가능성이 있습니다.

또한, 종종 원격 측정은 유사한 필드를 포함할 수 있지만 전혀 다른 행동을 의미할 수 있습니다. 예를 들어, Sysmon 네트워크 연결 이벤트(Event Id 3)와 프로세스 생성(Event ID 1)은 이미지 필드를 공유합니다. 프로세스 생성 이벤트에 있는 explorer.exe의 존재는 Sysmon 네트워크 연결 이벤트의 같은 필드 내에서는 전혀 다른 의미를 가집니다. 적절한 로그소스 구성 요소를 제공함으로써 탐지에 대한 귀중한 컨텍스트를 제공합니다. 이미지 field of a Sysmon network connection event is completely different from the existence of explorer.exe in a process creation event.  By providing the proper logsource component we provide invaluable context to the detection.

탐지 구성 요소

탐지 구성 요소는 작성자가 자신의 탐지 기준을 정의하는 곳입니다. 이는 적어도 한 개 이상의 선택 구성 요소 와 하나의 조건 구성 요소를 포함합니다. 상관 기반 규칙에는 필수 사항인 시간 프레임 구성 요소 가 선택적으로 존재할 수 있습니다.

선택 하위 구성 요소(s):

일반적으로 이는 다음과 같은 형태를 취합니다. 필드 A 포함/시작/끝/일치 값 B물론, 위의 예시 규칙에서 관찰된 것처럼, 필요하다면 작성자는 추가적인 논리를 포함할 수 있으며 예를 들어 필드 A 포함/시작/끝/일치 값 X, Y, 또는 Z. 형태로 확장할 수 있습니다. 이 논리는 항상 대소문자를 구분하지 않습니다.

보다 정밀하게 하거나 규칙의 복잡성을 증가시키는 ‘수정자’가 더 많이 있습니다. 예를 들어, 정규 표현식은 re 운영자를 통해 처리되며 작성자가 대소문자를 구분하는 쿼리를 작성할 수 있도록 지원합니다. 호환성을 위해 가능한 한 기본 정규 표현식 운영자만을 사용하는 것이 좋습니다. . ? + * | { } [ ] () ” .

선택은 이름이 붙여지며(예: 선택, 선택2, 선택3, 필터) 거의 모든 이름을 선택할 수 있습니다. 대개 선택 의 변형이 사용되지만, 선택을 바나나 로 명명해도 규칙은 여전히 작동할 것입니다. 일반적으로 필터 는 제외할 선택에 사용됩니다(예: 선택 및 필터 아님).

)

조건 하위 구성 요소:

조건 구성 요소는 모든 선택이 최종 쿼리에 어떻게 포함되어야 할지 정의하는 불리언 논리(AND, OR, NOT)를 포함합니다.예: (

선택_a 또는 선택_b) 및 필터 아님상관관계를 가진 조건 구성 요소:

현재 백엔드에서 지원하는 두 가지 유형의 상관관계가 있습니다. SIGMA 스키마에서 지원하는 다른 상관관계도 있지만, 아직 사용 가능한 백엔드에서는 지원되지 않습니다.

Y별로 Count():

Y 필드 값의 고유 인스턴스를 세고 이를 정적 숫자와 비교(크거나 작음)합니다.

예: Src_ip별로 Count() > 2

Y별로 Count(X):

Y 값당 X 필드 값의 고유 인스턴스를 세고 이를 정적 숫자와 비교(크거나 작음)합니다.

예: Src_ip별로 Count(EventID) > 2

일반적인 상관관계 사용 사례:

Count() by src_ip > 10

Count unique matching events by the source IP.

Count() by dst_ip > 10

Count unique matching events by the destination IP

Count(EventID) by ComputerName

This will let you search for unique instances of eventid. For instance, if you want to chain sysmon event ids 1 (process creation) AND event id 5.

e.g. a process is created and terminated in less than 1 min.

시간 프레임 서브 컴포넌트:

The 시간 프레임 구성 요소는 상관관계를 포함하는 조건과 함께 사용됩니다. 많은 백엔드들이 시간 프레임을 무시하지만, 일반적으로 항상 포함되어야 하며, 대부분의 저장소에서는 반드시 포함되어야 합니다, SOC Prime의 것 포함.

Splunk를 사용하는 완전한 예:

여기에는 Splunk와의 변환 예시가 포함된 몇 가지 SIGMA 예시가 있습니다. Splunk에 익숙하지 않은 경우, 별표(asterisks)는 와일드카드이며 별표로 둘러싸인 용어(예: *용어*)는 ‘포함’을, 선행 별표가 있는 용어(예: *용어)는 끝남을, 후행 별표가 있는 용어는 끝남을 나타냅니다(예: 용어*).

SIGMA detection component

Splunk Translation (Asterisk is a wildcard)

detection:

  selection:

    fieldX: 'suspicious'

  condition: selection

fieldX="suspicious"

detection:

  selection:

    fieldY|contains: 

     - 'suspicious'

     - 'malicious'

     - 'pernicious'

  condition: selection

(fieldY="*suspicious*" OR fieldY="*malicious*" OR fieldY="*pernicious*")

detection:

  selection:

     - fieldX: 'icious'

     - fieldX: 

        - 'susp'

        - 'mal'

        - 'pern'

  condition: selection

(FieldX="icious" AND (FieldX="susp" OR FieldX="mal" OR FieldX="pern"))

detection:

  selection:

     - FieldX|endswith: 'icious'

     - FieldX|startswith: 

        - 'susp'

        - 'mal'

        - 'pern'

  condition: selection

(FieldX="*icious" AND (FieldX="susp*" OR FieldX="mal*" OR FieldX="pern*"))

detection:

  selection:

     FieldX|endswith: 'icious'

  filter:

     FieldX|startswith: 

        - 'del'

        - 'ausp'

  condition: selection AND NOT filter

(FieldX="*icious" AND  NOT ((FieldX="del*" OR FieldX="ausp*")))

detection:

  selection:

     FieldX: 'suspicious'

  timeframe: 1m

  condition: selection | count by src_ip > 3

FieldX="suspicious" | eventstats count as val by src_ip| search val > 3

#notice splunk ignores the timeframe value, the value must be set at search by the user

detection:

  selection:

     FieldX: 'suspicious'

  condition: selection | count(ComputerName) by src_ip > 3

FieldX="suspicious" | eventstats dc(ComputerName) as val by src_ip | search val > 3

분류 체계 질문(예: 사용할 필드 이름)

이론적으로 원하는 필드 이름을 사용할 수 있으며, 누군가가 SIGMA 설정을 작성하여 여러분의 필드를 대응시킬 시간이 있어야 합니다.

참고: 필드 이름은 대소문자를 구분합니다! 명령 줄 and 명령 줄 는 두 개의 다른 값입니다. 명령 줄 는 기존 분류 체계의 일부이며 명령 줄 는 아닙니다.

이 말은, SIGMA에 의해 문서화된 필드 이름을 사용하는 것이 가장 좋습니다. 공개 SIGMA 저장소는 분류 체계를 문서화하는 세 가지 장소가 있습니다.

그리고 마지막으로 구성이나 규칙이 존재하지 않는 경우, 원로그 소스의 원래 필드 이름을 사용합니다. 필드 이름이 중첩 값에서 나온 경우(예: userIdentity 중첩됨 아래 accountId aws cloudtrail에서) 우리는 필드가 중첩됨을 나타내기 위해 SIEMs 간에 상대적으로 일관된 점을 사용합니다(예: userIdentity -> accountId 는 userIdentity.accountId).

가 됩니다.

SIGMA 규칙 테스트

간단한 몇 가지 단계가 있습니다:

  1. 규칙이 번역되는지 확인(uncoder나 SIGMAC을 사용하여)
  2. 합리적인 확인(예: 규칙이 원래 기대에 부합하는지, 올바른 분류 체계를 따르는지 등) – 함정 확인:랩 환경에서 규칙을 확인 랩 환경에서 규칙을 확인
  3. 규칙을 널리 공유하여 테스트 / SOC Prime 팀에 규칙을 위협 포상 프로그램을 통해 공유
  4. 규칙 작성자 관점에서 일반적으로 규칙의 백엔드 구현에 대해 걱정할 필요가 없습니다. SIGMA 백엔드 작성자와 SOC Prime과 같은 사람들이 유효한 규칙의 원래 의도를 충실하게 번역하는지 확인하는 것입니다. 버그가 확인되면 GitHub에 문제를 제기하는 것이 항상 유익합니다.

참고: From a rule author perspective, generally you should not worry about the backend implementations of rules. It is up to the SIGMA backend authors, and folks like SOC Prime to ensure that the translations meet the original intention of a valid rule. If a bug is identified, it is always worth submitting an issue to GitHub. 

행동 호소 및 미래 작업

이만큼 읽으셨다면, 첫 번째 규칙을 작성하고 공유할 준비가 되어 있습니다! 이 블로그를 즐기셨다면 SIGMAC을 사용하여 콘텐츠를 사용자 지정하는 데 관한 곧 다가올 또 다른 블로그를 즐기실 수 있을 것입니다.




이 기사가 도움이 되었나요?

동료들과 좋아요를 누르고 공유하세요.
SOC Prime의 Detection as Code 플랫폼에 가입하세요 귀하의 비즈니스와 가장 관련 있는 위협에 대한 가시성을 향상시키세요. 시작하고 즉각적인 가치를 창출하기 위해 지금 SOC Prime 전문가와의 미팅을 예약하세요.
무료 가입하기 미팅 예약하기

관련 게시물

XE 그룹 활동 탐지: 신용카드 스키밍에서 CVE-2024-57968 및 CVE-2025-25181 VeraCore 제로데이 취약점 악용까지
블로그, 최신 위협 — 3 분 읽기
XE 그룹 활동 탐지: 신용카드 스키밍에서 CVE-2024-57968 및 CVE-2025-25181 VeraCore 제로데이 취약점 악용까지
Veronika Telychko
CVE-2025-0411 탐지: 러시아 사이버 범죄 조직, 우크라이나 조직을 표적으로 삼아 7-Zip의 제로데이 취약점 악용
블로그, 최신 위협 — 4 분 읽기
CVE-2025-0411 탐지: 러시아 사이버 범죄 조직, 우크라이나 조직을 표적으로 삼아 7-Zip의 제로데이 취약점 악용
Veronika Telychko
Lumma Stealer 탐지: GitHub 인프라를 활용한 SectopRAT, Vidar, Cobeacon 및 기타 유형의 멀웨어 전파 정교한 캠페인
블로그, 최신 위협 — 3 분 읽기
Lumma Stealer 탐지: GitHub 인프라를 활용한 SectopRAT, Vidar, Cobeacon 및 기타 유형의 멀웨어 전파 정교한 캠페인
Veronika Telychko