시작하기: SecOps의 YARA-L 2.0

다음에서 지원:

YARA-L 2.0은 모든 검색, 대시보드, 규칙 기반 위협 탐지를 위해 Google Security Operations를 지원하는 고유한 고도로 구조화된 쿼리 언어입니다. 이 문서는 위협을 탐색하는 보안 분석가이든 강력한 새 로직을 구축하는 감지 엔지니어이든 핵심 YARA-L 구조를 이해하고 이를 사용하는 실용적인 단계를 파악하는 데 도움이 됩니다.

시작하기 전에

YARA-L 구조 이해하기

모든 YARA-L 쿼리는 쿼리의 동작을 지정하는 명명된 고유한 섹션으로 구분됩니다.

이 구조를 통해 다단계 분석과 상관관계 분석이 가능합니다.

명령어 작업 선택사항 | 필수
meta 작성자, 설명, 심각도와 같은 규칙의 설명 메타데이터를 설정합니다. 검색 및 대시보드의 경우 선택사항입니다. 규칙에만 필요합니다.
events 이벤트를 정의하고 필터링합니다. 고려할 모든 데이터 소스 (주로 이벤트)를 선언하고 UDM 필드를 사용하여 필터링합니다. 검색, 대시보드, 규칙에 필요합니다 (쿼리의 핵심 로직).
match 이벤트를 기준으로 그룹화하고 지원되는 기간 (예: by 5m)을 지정할 수 있습니다. 집계가 발생하는 통계 검색의 경우에 따라 필요합니다. 다중 이벤트 상관 관계 쿼리에 필요합니다. 시간 사양은 규칙의 경우 match에서 필수이며 검색 및 대시보드의 경우 선택사항입니다.
outcome 필수 측정항목을 계산하고 통계를 가져옵니다 (예: count(), avg()). 선택사항입니다.
condition 결과를 반환 (검색)하거나 알림을 트리거 (규칙)하기 위해 충족해야 하는 로직을 정의합니다. 결과가 적용되는지 확인하기 위해 쿼리 변수 기준을 평가합니다 (예: $event >5). 검색 및 대시보드에서는 선택사항입니다. 규칙에만 필요합니다.
dedup 주요 변수 또는 이벤트 경로 (예: target.user.userid, target.ip, principal.hostname 또는 $host, $user과 같은 변수)를 기반으로 그룹화하여 중복 이벤트를 삭제합니다. 이벤트 변수에 대해 자세히 알아보세요. 선택사항입니다. 규칙에서 사용할 수 없습니다.
order 특정 필드 (예: asc)로 정의된 결과를 정렬합니다. 선택사항 (match가 사용되는 경우에만 적용됨) 규칙에서 사용할 수 없습니다.
limit 쿼리에서 반환되는 최대 이벤트 수를 제한합니다. 선택사항입니다. 규칙에서 사용할 수 없습니다.
select 쿼리 결과에 포함할 UDM 필드의 목록을 지정합니다. 선택사항입니다. 규칙에서 사용할 수 없습니다.
unselect 쿼리 결과에서 제외할 UDM 필드 목록을 지정합니다. 선택사항입니다. 규칙에서 사용할 수 없습니다.

YARA-L 데이터 소스 사용 가능 여부

YARA-L은 플랫폼의 위치에 따라 다양한 데이터 소스에 액세스할 수 있습니다. 이벤트, 엔티티 (ECG), 데이터 테이블은 검색, 대시보드, 규칙에서 모두 사용할 수 있습니다.

다음 표에는 YARA-L에서 사용할 수 있는 기능이 나와 있습니다.

기능 사용 가능
케이스 및 케이스 기록 대시보드
데이터 표 검색, 대시보드, 규칙
항목 (심전도) 검색, 대시보드, 규칙
수집 측정항목 대시보드
IoC 일치 대시보드
규칙 감지 대시보드, 규칙
규칙 집합 대시보드
이벤트 검색, 대시보드, 규칙
UEBA 측정항목 검색, 대시보드

Google SecOps의 모든 데이터는 목표에 따라 필터 검색과 통계 검색 (집계)이라는 두 가지 기본 방법을 사용하여 검색됩니다.

필터 검색 메서드를 사용하면 통계 집계의 오버헤드 없이 더 광범위한 원격 분석 스트림에서 특정 이벤트를 격리할 수 있습니다. 이 방법은 기준을 사용하여 로그나 네트워크 트래픽과 같은 대량의 보안 데이터를 타겟 결과 집합으로 좁힙니다. 로직에서는 events 섹션에 이벤트만 지정하면 됩니다.

첫 번째 YARA-L 필터 검색을 빌드하려면 다음 단계에 따라 로그인에 실패한 사용자를 검색하세요.

  1. Google SecOps에서 검색 페이지로 이동합니다.
  2. 로그인 이벤트 필터링:
    metadata.event_type = "USER_LOGIN"

    도움말: 검색 시 events: 섹션 헤더를 생략할 수 있습니다. 기본적으로 검색 구문은 이 섹션을 의미합니다.

  3. 비어 있지 않은 userid이 있는 사용자의 로그인 실패에 대한 event 작업 추가 
    metadata.event_type = "USER_LOGIN"
security_result.action = "FAIL"
principal.user.userid != ""
  4. 이 검색을 실행하여 결과를 확인하세요.

자리표시자 변수 사용

자리표시자 변수를 사용하여 이벤트에서 사용자 이름이나 IP 주소와 같은 특정 값을 추출합니다. 이러한 변수는 서로 다른 이벤트 간에 데이터를 비교하거나 최종 출력에 해당 값을 표시할 수 있는 임시 앵커 역할을 합니다.

자리표시자 변수를 적용하여 다음 작업을 실행합니다.

  • 브리지 데이터: $userid 또는 $ip와 같은 자리표시자를 사용하여 서로 다른 이벤트 변수 간의 일치 항목을 찾습니다. 예를 들어 $userid를 사용하여 로그인 및 로그아웃 이벤트 전반에서 사용자 식별자를 연결할 수 있습니다.
  • 결과 그룹화: match 섹션에서 자리표시자 변수를 사용하여 쿼리 출력의 창을 정의합니다(예: match: $userid over 1h).
  • 결과 만들기: 자리표시자를 사용하여 쿼리 출력에서 특정 데이터 포인트를 캡처하고 표시합니다.

예를 들어 $user = principal.user.userid를 할당하면 $user 변수는 이제 이벤트에서 추출된 특정 값을 보유합니다. 그런 다음 match 섹션에서 $user를 사용하여 해당 특정 사용자와 관련된 모든 활동을 그룹화합니다.

통계 검색 메서드를 사용하면 이벤트 집합 전반에서 계산을 실행하여 통계, 추세 또는 이상치를 파악할 수 있습니다. 개별 로그 목록을 반환하는 대신 데이터의 집계된 요약을 제공합니다. 이 로직은 match 섹션 (그룹화용)과 outcome 섹션 (계산용)을 사용합니다. outcome 섹션은 count(), sum(), avg(), max(), min(), stddev()과 같은 집계 함수를 지원합니다.

다음 예에서는 다음 쿼리 로직을 사용합니다.

  • events: 로그인 시도 실패에 대한 원시 데이터를 필터링합니다.
  • match: 그룹화 이벤트 (userid별)를 정의합니다.
  • outcome: 통계 집계 (사용자당 이벤트 수)를 실행합니다.

예: outcome 함수를 사용하여 로그인 실패 활동 집계

다음 예에서는 outcome 섹션의 집계 함수 (예: count() 또는 sum())를 사용하여 로그인 실패 활동을 요약합니다.

  1. match 섹션을 사용하여 로그인 실패 이벤트를 userid별로 그룹화합니다.

    metadata.event_type = "USER_LOGIN"
security_result.action = "FAIL"
principal.user.userid != ""

match:
  principal.user.userid

  2. outcome 변수로 정의된 각 사용자의 로그인 실패 횟수 ($failed_login_count)를 사용합니다.count

    metadata.event_type = "USER_LOGIN"
security_result.action = "FAIL"
principal.user.userid != ""

match:
  principal.$user.userid

outcome:
  $failed_login_count = count(metadata.id)

  3. 이 검색을 실행하여 결과를 확인하세요.

  4. 선택사항: match 섹션에 시간 요소를 추가합니다 (이 경우 day). 그런 다음 outcome 변수를 업데이트하여 더 명확하게 만듭니다 ($daily_failed_login_count).

    metadata.event_type = "USER_LOGIN"
security_result.action = "FAIL"
principal.user.userid != ""
$user =principal.user.userid

match:
  principal.$user.userid by day

outcome:
  $daily_failed_login_count = count(metadata.id)

검색에서 대시보드 위젯 만들기

첫 번째 검색 예 빌드에 표시된 것처럼 집계된 검색에서 대시보드 위젯을 만들 수 있습니다.

검색이 검증되면 다음과 같이 위젯으로 저장하고 대시보드에 추가할 수 있습니다.

  1. 결과가 표시되면 시각화 탭 > 대시보드에 추가를 클릭합니다.
  2. 위젯을 구성합니다.
    1. 위젯 이름을 지정합니다 (예: "Daily Failed Login").
    2. 기간 선택
    3. 기존 대시보드에 추가할지 새 대시보드에 추가할지 선택합니다.
    4. 추가를 클릭합니다.
  3. 선택사항: 대시보드에 직접 쿼리를 빌드합니다. 또는 선별된 대시보드를 복사하고 그 안에서 쿼리를 수정하여 시작할 수도 있습니다.
  4. 선택사항: YARA-L을 사용하여 맞춤 대시보드를 만들고 위젯을 추가할 수 있습니다. 자세한 내용은 맞춤 대시보드 만들기를 참고하세요.

대시보드 구성

새 대시보드를 빌드할 때 events 섹션은 필수 시작점입니다. 여기에서 match (결과 그룹화) 또는 outcome (출력 및 집계 계산)를 유연하게 사용할 수 있습니다.

예를 들어 events 및 match 섹션이 있는 대시보드를 만들 수 있습니다. 이 대시보드에는 by hour 버킷으로 그룹화된 감지의 심각도 ($severity)가 표시됩니다.

예: 심각도별로 시계열 집계

events 및 match 섹션을 사용하여 hour 버킷으로 그룹화된 감지의 심각도 ($severity)를 표시하는 대시보드를 만들 수 있습니다.

detection.detection.severity != "UNKNOWN_SEVERITY"
$severity = detection.detection.severity

match:
  $severity by hour

예: 총 심각한 영향 집계

마찬가지로 events 및 outcome 섹션을 사용하여 심각도가 높은 감지를 추적하는 대시보드를 만들 수 있습니다.

detection.detection.severity = "CRITICAL"
$severity = detection.detection.severity

outcome:
  $detection_count = count_distinct($severity)

예: 시간 경과에 따른 심각도별 감지량 시각화

다음 예에서는 콘솔을 통해 심각한 감지를 집계하고 기간을 지정할 수 있습니다. 대시보드에서 시각화를 빌드할 때 match 및 outcome 섹션을 모두 사용하는 경우가 많습니다.

detection.detection.severity != "UNKNOWN_SEVERITY"
$severity = detection.detection.severity

match:
  $severity by hour

outcome:
  $detection_count = count_distinct(detection.id)

예: 사용자 로그인 빈도 계산

다음 예에서는 match 및 outcome 섹션을 사용하여 특정 사용자의 login_count를 계산하는 데 중점을 둡니다.

events:
  metadata.event_type = "USER_LOGIN"

match:
  target.user.userid

outcome:
  $login_count = count(metadata.id)

규칙 빌드

규칙에는 다음 섹션이 필요합니다.

  • meta: 규칙 이름과 설명 세부정보를 포함합니다.
  • events: 이벤트 변수를 사용하여 데이터 소스와 필터를 정의합니다.
  • condition: 규칙이 트리거되려면 어떤 이벤트 변수가 있어야 하는지 지정합니다.

이벤트 변수 정의 및 사용

이벤트 변수는 논리적 컨테이너 역할을 하여 필터를 그룹화하므로 검색, 규칙 또는 대시보드 전체에서 특정 활동을 참조할 수 있습니다.

events 섹션에서 로직을 정의할 때 이벤트 변수 (예: $e)를 사용하여 기준에 맞는 특정 이벤트 (또는 이벤트 그룹)를 나타낼 수 있습니다.

예: 이벤트 변수 정의 및 필터링

이벤트 변수 (예: $e)를 정의하려면 쿼리의 events 섹션에서 접두사를 사용합니다. 이렇게 하면 변수로 표시할 이벤트가 선언됩니다. 예를 들어 $e.principal.hostname = "dev" 표현식은 각 이벤트를 평가하여 호스트 이름이 정확히 일치하는지 확인합니다.

$e.principal.hostname = "dev"
$e.metadata.event_type = "USER_LOGIN"

그런 다음 쿼리의 다른 섹션에서 해당 변수를 사용하여 특정 이벤트 그룹 (match, outcome, condition 섹션)과 데이터 필드를 참조할 수 있습니다.

규칙 구조 및 문법 정리

다음 규칙 구조와 문법을 사용하여 변수, 그룹화 로직, 트리거 기준점을 정의하세요.

요소 설명 예
규칙 구조 rule 블록에 쿼리를 래핑하고 감지를 식별하는 고유한 이름을 할당합니다. rule DailyFailedLoginAttempts { }
meta 섹션 필수 항목입니다. 규칙 관리를 개선하고 팀에 컨텍스트를 제공하기 위해 설명 메타데이터 (`author`, `description`, `severity` 등)가 포함됩니다. 규칙 관리를 위한 권장사항입니다. author = "Alex"
severity = "Medium"
이벤트 변수 규칙 쿼리에서 events 섹션의 각 필드에는 기준과 일치하는 특정 이벤트 (또는 이벤트 그룹)를 나타내는 이벤트 변수 (예: $e)가 접두사로 붙습니다. 필터의 논리적 그룹화 역할을 합니다.

검색을 YARA-L 규칙으로 변환 예에서 $e은 모든 사용자 로그인 실패를 나타냅니다.		 $e.metadata.event_type = "USER_LOGIN"
자리표시자 변수 나중에 쿼리에서 참조할 수 있는 일반 이름에 이벤트를 할당합니다. 자세한 내용은 자리표시자 변수 사용을 참고하세요. $userid = $e.principal.user.userid
match 섹션 그룹을 정의하고 지원되는 기간을 지정합니다. 검색을 YARA-L 규칙으로 변환 예시에서 match: $userid over day 그룹화는 각 24시간 기간 (1d) 내에서 사용자 ID별로 이벤트를 올바르게 그룹화합니다.

규칙을 작성할 때는 지원되는 기간을 지정하여 전환 확인 기간을 정의해야 합니다. 로직 요구사항에 따라 홉, 슬라이딩 또는 텀블링 창을 구현할 수 있습니다. over 연산자를 사용하면 명시적으로 홉 창이 생성됩니다. 		$userid over 1d
outcome 섹션 통계 집계를 실행하거나 특정 변수를 캡처하여 결과 알림의 정보를 더 풍부하게 만듭니다.

$e.metadata.id에서 count() 함수를 사용하여 각 match 그룹 내 이벤트를 집계합니다. $userid와 같은 변수를 할당하여 특정 UDM 필드를 캡처하고 결과 감지 출력에 더 많은 컨텍스트를 제공할 수도 있습니다.		 $failed_count = count($e.metadata.id)
condition 섹션 규칙이 감지를 생성하는 데 필요합니다.

condition 섹션에서 감지 기준점을 정의합니다. 예를 들어 #e > 5을 사용하려면 알림을 트리거하기 위해 이벤트 수가 5 (5)를 초과해야 합니다. 계산을 실행하지 않더라도 condition 섹션이 필요하며 이벤트 변수 (예: #e)의 존재를 명시해야 합니다.

환경의 기준을 분석하여 거짓양성을 최소화하면서 의심스러운 활동을 포착하는 기준을 설정합니다. 계산을 실행하지 않는 경우에도 condition 섹션이 필요하며 #e과 같은 이벤트 변수의 존재를 명시하면 됩니다.		 #e > 5 또는 $e

이 구조의 작동 방식을 이해하려면 다음 예시를 참고하세요.

예: 무차별 대입 감지 (로그인 실패 여러 번)

다음 예에서는 24시간 내에 단일 사용자의 로그인 시도가 여러 번 실패했는지 감지합니다.

rule DailyFailedLoginAttempts {
  meta:
    author = "Alex"
    description = "Detects multiple failed login attempts for a single user within a day."
    severity = "Medium"

  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.security_result.action = "FAIL"
    $e.principal.user.userid != ""
    $userid = $e.principal.user.userid

  match:
    $userid over 1d

  outcome:
    $daily_failed_login_count = count($e.metadata.id)

  condition:
    $daily_failed_login_count > 5
}

완료된 검색어를 감지를 생성하기 위한 신뢰할 수 있는 규칙으로 변환하려면 일반적으로 다음 단계를 따릅니다.

  1. Google SecOps에서 규칙 편집기로 이동합니다.
  2. 새 규칙을 시작합니다.
  3. 검색어를 붙여넣고 다음을 포함하여 규칙 구조에 맞게 수정합니다.
    • meta 섹션: 규칙 이름, 작성자, 심각도 수준을 포함한 메타데이터 규칙을 정의합니다.
    • event 섹션: 필수 검색과 달리 이름이 지정된 event 섹션 헤더가 있어야 합니다.
    • 이벤트 변수: 로직 내에서 특정 이벤트 (또는 이벤트 그룹)를 선언하고 참조합니다.
    • 지원되는 기간이 있는 match 섹션: 그룹화 키를 지정하고 시간 매개변수 (예: 5m 또는 1d)를 정의합니다. 참고: 규칙에서 match 섹션을 사용하는 경우 기간을 추가해야 합니다.
    • condition 섹션: 규칙을 트리거하기 위해 충족해야 하는 최종 로직 또는 임계값을 정의합니다.

고급: 멀티 이벤트 규칙 빌드

멀티 이벤트 규칙을 사용하여 특정 기간 내에 발생하는 다양한 유형의 활동을 연결합니다. 단일 이벤트를 살펴보는 대신 사용자가 로그인한 후 즉시 비정상적인 파일 다운로드를 실행하는 등 여러 이벤트를 연결하여 복잡한 위협을 식별합니다.

멀티 이벤트 규칙에는 다음 섹션이 필요합니다.

  • meta: 규칙 이름과 설명 세부정보를 포함합니다.
  • events: 이벤트 변수를 사용하여 데이터 소스와 필터를 정의합니다.
  • match: 이벤트를 연결하는 데 사용되는 기간과 자리표시자 변수를 설정합니다.
  • outcome알림에 대한 추가 컨텍스트를 캡처합니다. 멀티 이벤트 규칙에는 집계 함수가 필요합니다.
  • condition: 규칙이 트리거되려면 어떤 이벤트 변수가 있어야 하는지 지정합니다.

다중 이벤트 규칙을 빌드하려면 다음 단계를 따르세요.

  1. 이벤트 변수 정의: 이벤트 섹션에서 "PROCESS_LAUNCH" 이벤트를 캡처하는 $e1와 특정 악성 파일 해시를 캡처하는 $e2를 정의합니다.
  2. 자리표시자와 상관관계 지정: $user 자리표시자 변수를 사용하여 공유 기본 사용자 ID (예: $user = $e1.principal.user.userid and $user = $e2.principal.user.userid)로 이 두 개의 개별 이벤트 스트림을 연결합니다.
  3. 일치 항목 그룹화: match 섹션에서 이러한 이벤트가 5분 (5m)과 같은 설정된 시간 내에 동일한 $user에 대해 발생해야 한다고 지정합니다.

예: 멀티 이벤트 규칙 빌드

다음 예에서 $e1는 PROCESS_LAUNCH 이벤트를 나타내고 $e2는 특정 악성 해시가 있는 이벤트를 나타냅니다. $user 자리표시자 변수는 동일한 기본 사용자 ID로 이러한 이벤트를 상호 연관시킵니다.

rule MultiEventExample {
  meta:
    author = "Alex"
    description = "Detects a bad hash execution or a process launch from a specific IP for the same user."

  events:
    $e1.principal.ip = "1.1.1.1"
    $e1.metadata.event_type = "PROCESS_LAUNCH"
    $e2.target.file.sha256 = "badhash..."
    $user = $e1.principal.user.userid
    $user = $e2.principal.user.userid

  match:
    $user over 5m

  condition:
    $e1 or $e2
}

다음 규칙 구성요소는 예에 사용된 논리를 설명합니다.

  • 이벤트 변수: $e1 및 $e2의 두 이벤트 변수를 정의했습니다. 자리표시자 변수 $user를 사용하여 공통 userid 필드에서 이러한 이벤트를 조인했습니다.
  • match 섹션: 이 멀티 이벤트 규칙에 match 섹션을 포함하여 사용자를 기준으로 그룹화하고 이벤트의 상관관계를 지정하는 5분의 홉 시간 창 (5m)을 지정했습니다.
  • condition 섹션: 알림을 트리거하는 논리를 정의했습니다. 이 예시에서는 첫 번째 또는 두 번째 이벤트가 있는 경우 알림을 트리거합니다.

다른 도구를 사용하여 쿼리 빌드

이러한 도구는 YARA-L 채택을 작성, 검증, 가속화하는 데 필수적인 도구입니다.

  • UDM 조회 도구: UI 내에서 직접 UDM 필드 이름, 정의, 데이터 유형을 빠르게 검색하고 참조합니다. 필드 ID를 알 수 없는 경우 이 참조를 먼저 확인하세요.
  • 자연어에서 YARA-L로 검색: 검색창에 설명을 입력하여 초기 쿼리를 작성하거나 해당 YARA-L 제안을 가져오거나 번역합니다.
  • SPL → YARA-L 변환기 (실험실 도구): 경쟁업체 플랫폼에서 전환하는 경우 이 도구 (실험실 섹션에서 사용 가능)를 사용하여 기존 Splunk SPL 쿼리를 YARA-L로 변환합니다. 이렇게 하면 구조화된 시작점이 생성되어 마이그레이션을 가속화하고 감지 로직을 개선할 수 있습니다. Labs 도구를 사용하려면 Google SecOps에서 yourinstancename.chronicle.security/labs로 이동하세요.

다음 단계

도움이 더 필요하신가요? 커뮤니티 회원 및 Google SecOps 전문가에게 문의하여 답변을 받으세요.