규칙 감지 지연 이해하기

다음에서 지원:

이 문서에서는 Google Security Operations의 규칙 감지 지연을 설명하고, 수집 및 처리 파이프라인 전반의 요인을 식별하며, 구조화된 문제 해결 접근 방식을 간략하게 설명하고, 감지 지연 시간을 줄이는 기법을 제공합니다.

감지 규칙 개요

감지 규칙은 정규화된 원시 로그(일반 및 항목 범용 데이터 모델(UDM) 이벤트 모두)를 검사하여 규칙 사양에 따라 보안 감지를 생성합니다. 엔티티 UDM 이벤트에는 일반적으로 사용자 또는 애셋 메타데이터와 같은 컨텍스트 정보가 포함됩니다. 감지 규칙은 이전에 생성된 감지를 평가하여 복합 알림을 생성할 수도 있습니다.

예상되는 지연과 예상치 못한 지연

감지 지연 시간은 규칙 로직, 데이터 종속성, 시스템 처리 주기에 따라 다릅니다. 지연은 두 가지 유형으로 분류됩니다.

  • 예상 지연: 수집 프로세스, 규칙 유형, 실행 빈도, 감지 생성 방법, 일치 기간, 알려진 시스템 제한과 같은 구조적 요인으로 인해 발생하는 지연입니다. 감지 규칙 구성 및 일정 매개변수를 조정하여 예상되는 지연을 최소화할 수 있습니다.
  • 예측할 수 없는 지연: 데이터 소스의 로그 전송 병목 현상, Google SecOps 서비스 내의 일시적인 처리 지연 시간, 지연된 컨텍스트 가용성, UDM 재강화 주기 등 외부 또는 동적 파이프라인 조건으로 인해 발생하는 지연입니다.

감지 생성 방법

Google SecOps는 다음 실행 파이프라인을 통해 규칙 감지를 생성합니다.

  • 스트리밍 엔진: 표준 및 윈도우 단일 이벤트 규칙을 거의 실시간으로 (일반적으로 수집 후 5분 이내) 지속적으로 평가하는 고속 파이프라인입니다. 늦게 도착하는 이벤트와 소급 적용되는 보강은 표준 실행 중에 지속적으로 평가됩니다.
  • 쿼리 엔진: 여러 이벤트 또는 외부 데이터 조인에서 시간 기반 이벤트 상관관계가 필요한 규칙을 평가합니다.
    • 복잡한 단일 이벤트 규칙: 참조 목록 또는 데이터 테이블을 쿼리하는 단일 이벤트 규칙이 포함됩니다.
    • 멀티 이벤트 규칙: 구성된 일정에 따라 이벤트 시간의 일괄 처리된 블록 (예: 10분 또는 1시간 간격, 48시간이 넘는 기간의 경우 match_window / 10)에서 데이터를 쿼리합니다.
  • 이전 데이터에 대해 실행되는 규칙: 레트로헌트를 통해 이전 로그에 대해 소급하여 규칙을 평가합니다. 이전 스캔이 완료되면 감지가 표시됩니다.
  • UDM 이벤트 재강화: 이전 이벤트에 새 컨텍스트 또는 업데이트된 항목 데이터가 추가되면 이전에 처리된 시간 블록을 다시 평가합니다.

규칙 감지 지연의 원인

감지가 표시되는 속도는 규칙 복잡성, 예약 간격, 데이터 수집 지연 시간, 컨텍스트 보강 파이프라인에 따라 달라집니다.

규칙 유형 및 복잡성

감지 규칙은 지연 시간 프로필이 서로 다른 여러 카테고리로 나뉩니다.

단일 이벤트 규칙

단일 이벤트 규칙은 연속 스트리밍 엔진에서 거의 실시간으로 실행되며 감지 지연 시간이 가장 짧습니다. 이러한 규칙은 외부 데이터 세트, 데이터 테이블 또는 멀티 이벤트 일치 기간을 조인하지 않고 개별 이벤트를 평가합니다.

복잡한 단일 이벤트 규칙

이러한 규칙은 단일 이벤트를 평가하지만 추가 데이터 종속 항목을 통합합니다.

  • 기간이 지정된 단일 이벤트 규칙: match 섹션이 포함된 단일 이벤트 규칙입니다 (예: 기간 내에 단일 이벤트가 조건과 일치하는지 평가). 이러한 규칙은 데이터가 수집될 때 연속 스트리밍 엔진에서 거의 실시간으로 평가됩니다.
  • 참조 단일 이벤트 규칙: 이벤트 속성을 참조 목록 또는 데이터 테이블과 비교하는 단일 이벤트 규칙입니다.

여러 이벤트 규칙

다중 이벤트 규칙은 지정된 일치 기간 동안 두 개 이상의 UDM 이벤트 조건을 상호 연관시키고 예약된 일괄 간격으로 실행됩니다.

  • 표준 멀티 이벤트 규칙: 기간에 걸쳐 여러 이벤트를 집계하고 10분 또는 1시간 간격 (또는 기간이 48시간을 초과하는 경우 match_window / 10)으로 실행합니다.
  • 컨텍스트 인식 규칙: 컨텍스트 인식 분석을 사용하여 이벤트 데이터를 UDM 항목 이벤트 (예: user_context 또는 asset_context)와 상호 연관시킵니다. 컨텍스트 인식 규칙은 여러 데이터 피드를 사용하므로 수집 타이밍에 더 민감합니다. 자세한 내용은 규칙에서 컨텍스트 보강 데이터 사용을 참고하세요.

규칙 실행 빈도

구성된 실행 빈도에 따라 쿼리 엔진이 이벤트 시간 블록을 평가하는 빈도가 결정됩니다.

  • 거의 실시간: 단일 이벤트 규칙 (표준 및 윈도우)에 대한 지속적인 평가
  • 10분 빈도: 일치 기간이 60분 미만인 멀티 이벤트 규칙에 사용할 수 있습니다.
  • 1시간 빈도: 일치 기간이 48시간 이하인 멀티 이벤트 규칙의 기본 간격입니다.
  • match_window / 10 빈도: 일치 기간이 48시간을 초과하는 멀티 이벤트 규칙에 자동으로 할당됩니다 (예: 100시간 일치 기간의 경우 10시간마다 실행, 10일 기간의 경우 24시간마다 실행).

일치 기간

멀티 이벤트 규칙의 경우 일치 기간은 이벤트를 집계하는 데 필요한 관찰 기간을 정의합니다. 전체 기간이 경과할 때까지 감지가 표시될 수 없습니다.

로그 수집 지연

수집 지연은 소스에서 이벤트가 발생한 시점과 Google SecOps가 로그를 수신하고 파싱하는 시점 사이의 경과 시간입니다.

이벤트가 해당 시간대의 초기 예정 평가 후에 도착하면 첫 번째 실행을 놓치게 됩니다. 시스템은 기본 실행 후 약 4시간 (선택적으로 보강 완료 시 30시간) 후에 발생하는 후속 자동 백그라운드 실행 (조정 실행)에서 늦게 도착한 데이터를 캡처합니다.

  • 예: 규칙이 30분 내에 이벤트 A (이벤트 시간 오전 9시 3분)와 이벤트 B (이벤트 시간 오전 9시 5분)의 상관관계를 지정합니다. 이벤트 A가 오전 10시 5분 (1시간 지연)에 도착하면 오전 9시~9시 30분 블록의 초기 실행을 놓치게 됩니다. 시스템은 기본 실행 후 약 4시간 (오후 2시경) 후에 후속 조정 실행 중에 차단을 재평가하여 이벤트가 발생한 후 약 5시간 후에 감지를 생성합니다.

시간대 불일치

Google SecOps는 기본적으로 로그 타임스탬프를 UTC로 해석합니다. 로그 소스에서 명시적 시간대 오프셋을 생략하면 시스템에서 타임스탬프를 UTC로 처리하므로 즉시 수신되더라도 로그가 늦게 도착한 것처럼 보일 수 있습니다.

  • 예: 이벤트가 동부 표준시 오전 10시 (UTC 15시)에 발생하고 시간대 메타데이터 없이 UTC 15시 5분에 Google SecOps에 도착합니다. 시스템은 타임스탬프를 10:00(UTC)으로 해석하여 규칙 평가를 백그라운드 true-up 실행으로 연기하는 5시간의 수집 지연이 발생합니다.

해결 방법: 시간대 불일치를 해결하려면 다음 단계를 따르세요.

  • 이벤트 타임스탬프에 명시적 UTC 시간대 오프셋이 포함되도록 로그 소스를 구성합니다.
  • 지원팀에 문의하여 특정 인제스트 피드의 시간대 재정의를 설정하세요.
  • 수집 전에 BindPlane 프로세서를 사용하여 로그 본문 타임스탬프를 UTC로 정규화합니다. 자세한 내용은 BindPlane을 사용하여 로그 본문 타임스탬프 수정을 참고하세요.

컨텍스트 기반 조인 및 데이터 보강

Google SecOps는 보조 소스에서 ID, 애셋, 위협 메타데이터를 추가하여 UDM 이벤트를 보강합니다. 컨텍스트 사용 가능 여부가 지연되면 감지 타이밍이 길어질 수 있습니다.

별칭 지정 및 보강 메커니즘

별칭 지정 및 보강은 원시 지표를 조직 컨텍스트와 연관시킵니다.

  • 별칭 지정: 데이터 소스 전반에서 동일한 항목의 여러 식별자를 식별하고 연결합니다 (예: DHCP 로그의 IP 주소를 alex-macbook와 같은 MAC 주소 및 호스트 이름에 매핑하거나 사용자 ID를 직원 직책에 매핑).
  • 보강: 별칭이 지정된 컨텍스트로 정규화된 UDM 이벤트 필드를 채웁니다 (예: 원시 이벤트에 IP 주소만 있는 경우 $udm.event.principal.hostname 채우기).

지원되는 보강 유형에는 애셋, 사용자, 프로세스, 파일 해시 메타데이터, 지리적 위치, 클라우드 리소스가 포함됩니다. 자세한 내용은 UDM 보강 및 별칭 지정 개요를 참고하세요.

UDM 이벤트 재강화

시스템은 컨텍스트 소스가 진화함에 따라 과거 이벤트를 지속적으로 업데이트합니다.

  • 기본 데이터 변경: 새 문맥 데이터가 도착하면 수집 후 최대 24시간 동안 이전 이벤트를 업데이트할 수 있습니다.
  • 강화 시스템 업데이트: 엔티티 메타데이터, IP 위치정보 또는 VirusTotal 위협 인텔리전스가 업데이트되면 규칙 엔진은 업데이트된 컨텍스트로 감지를 생성하기 위해 기록된 차단을 재평가합니다 (일반적으로 예약된 조정 실행 또는 재처리 중에).
  • 지연된 컨텍스트 데이터: 컨텍스트 데이터 (예: 호스트 이름)가 이벤트 로그가 기록된 다음 날 도착하면 시스템에서 UDM 이벤트를 다시 보강하고 후속 조정 실행에서 보강된 레코드를 평가합니다.
  • 컨텍스트 수정: 풍부한 정보 업데이트로 이벤트 속성이 변경되는 경우 (예: IP 지리정보를 USA에서 Canada로 업데이트) 업데이트된 값과 일치하는 규칙은 후속 재평가 중에 감지를 트리거합니다.

항목 컨텍스트 그래프 (ECG) 처리

엔티티 컨텍스트 그래프 (ECG)는 침해 지표 (IOC)와 엔터프라이즈 애셋 그래프 데이터를 상호 연관시킵니다. ECG 파이프라인은 데이터 볼륨에 따라 30시간 또는 최대 며칠이 걸릴 수 있는 일괄 처리를 사용하므로 graph.entity 필드를 참조하는 규칙은 그래프 관계가 완전히 계산된 후에 감지를 생성합니다.

이전 규칙 실행 및 RetroHunt

이전 데이터에 대해 규칙을 실행하면 선택한 기간 전체에서 RetroHunt 검색이 완료된 후에만 감지가 생성됩니다.

  • 소급 적용되는 풍부한 정보 워크플로:
    1. 오후 1시에 ip_address = 10.0.0.5 (호스트 이름 알 수 없음) 이벤트가 도착합니다.
    2. 오후 2시 30분에 10.0.0.5을 workstation-123에 연결하는 DHCP 로그가 도착합니다.
    3. 별칭 지정 파이프라인은 principal.hostname = workstation-123로 이전 오후 1시 이벤트를 업데이트합니다.
    4. 후속 규칙 재생은 풍부해진 호스트 이름을 평가하고 초기 실행 중에 트리거되지 않은 감지를 표시합니다.

참조 목록

참조 목록을 쿼리하는 규칙은 실행 시 최신 목록 버전에 대해 평가됩니다. 참조 목록을 업데이트하면 예약된 규칙이 이전에 수집된 로그에 대해 소급하여 감지를 생성할 수 있습니다.

존재하지 않는 규칙

거짓양성을 방지하기 위해 시스템은 존재하지 않음 조건 (예: !$e 또는 #e=0)을 확인하는 규칙을 평가하기 전에 최소 1시간의 버퍼를 도입하여 모든 관련 로그가 도착할 시간을 보장합니다.

데이터 처리 및 조정 제한사항

감지 지연 시간을 평가할 때는 다음 시스템 동작에 유의하세요.

  • 강화 처리: 컨텍스트 강화는 초기 수집 후 최대 24시간 동안 이전 UDM 이벤트를 업데이트할 수 있습니다.
  • 트루업 주기: 다중 이벤트 규칙은 기본 실행 후 약 4시간 (선택적으로 30시간) 후에 자동으로 다시 실행되어 늦게 도착하는 데이터를 포착합니다. 자세한 내용은 규칙 리플레이 및 MTTD 이해하기를 참고하세요.
  • 감지 한도: 플랫폼 용량 및 제한 경계는 감지 한도 이해하기를 참고하세요.

규칙 감지 지연 문제 해결

규칙에서 지연된 감지를 생성한 이유를 진단하려면 Google SecOps 콘솔에서 다음 휴리스틱 및 파이프라인 단계를 검사하세요.

  • 규칙 메타데이터 및 일정 검토: 규칙 대시보드에서 규칙 이름, 규칙 유형, 규칙 일정 열을 확인하여 규칙의 실행 엔진과 기준 평가 빈도를 파악합니다.
  • 이벤트 시간과 수집 시간 비교: 감지 탭에서 감지를 찾아 이벤트 타임스탬프와 수집 타임스탬프를 비교합니다. 이벤트 시간과 수집된 시간의 차이가 30분을 초과하면 소스 또는 수집 중 로그 전송 지연으로 인해 지연 시간이 발생한 것입니다. 30분 이상 늦게 도착한 이벤트 데이터, 자동 조정 실행, 재처리 파이프라인 또는 레트로헌트에서 생성된 감지에는 감지 유형 열에 아이콘이 표시됩니다.
  • 컨텍스트 소스 종속 항목 검토: 규칙이 principal 보강, UDM 별칭 지정 또는 graph.entity 필드를 참조하는지 확인합니다. 컨텍스트 파이프라인은 비동기식으로 처리되며 후속 조정 실행 중에 감지가 표시될 수 있습니다.
  • 빈도 및 매치 기간 호환성 확인: 구성된 실행 빈도가 매치 기간 크기와 일치하는지 확인합니다 (예: 15분 매치 기간이 있는 규칙이 10분 또는 1시간으로 예약되어 있는지 확인).
  • 데이터 피드 중단 확인: 수집 로그와 피드 관리 대시보드에서 수집 지연 또는 일시적인 소스 중단을 검토합니다.

감지 지연을 줄이기 위한 팁

환경 전반에서 감지 지연을 최소화하려면 다음 최적화 기법을 적용하세요.

  • 규칙 실행 빈도 최적화:
    • 단일 이벤트 규칙 (표준 및 윈도우)에는 거의 실시간을 사용합니다.
    • 일치 기간이 60분 미만인 멀티 이벤트 규칙에 대해 10분 일정을 구성합니다.
    • 빠른 알림이 필요한 1~48시간의 일치 기간이 있는 규칙에는 1시간을 사용합니다.
  • 일치 기간 조정: 상관관계가 있는 위협 행위를 포착하는 데 필요한 최소 기간으로 일치 기간을 설정합니다.
  • 로그 전송 병목 현상 제거: 포워더와 수집기가 이벤트 데이터를 즉시 전송하여 로그가 초기 실행 창에서 누락되지 않도록 합니다.
  • 시간대 구성 검증: 로그 소스가 명시적 UTC 오프셋을 제공하여 5시간 이상의 인지된 수집 지연을 방지합니다.
  • 컨텍스트 및 비존재 조건 감사: 의도적인 버퍼링 기간이 도입되므로 감지 로직에 필요한 경우에만 컨텍스트가 보강된 필드와 비존재 조건 (!$e)을 사용합니다.

다음 단계

관련 일정 개념 및 구성 워크플로를 살펴보려면 다음 문서를 참고하세요.

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