규칙 감지 지연 이해

다음에서 지원:

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

감지 규칙 개요

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

예상되는 지연과 예측할 수 없는 지연

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

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

감지 생성 방법

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

  • 스트리밍 엔진: 표준 및 창이 있는 단일 이벤트 규칙을 거의 실시간으로 (일반적으로 수집 후 5분 이내) 지속적으로 평가하는 고속 파이프라인입니다. 늦게 도착하는 이벤트와 소급 보강은 표준 실행 중에 지속적으로 평가됩니다.
  • 쿼리 엔진: 여러 이벤트 또는 외부 데이터 조인에서 시간 기반 이벤트 상관관계가 필요한 규칙을 평가합니다.
    • 복잡한 단일 이벤트 규칙: 참조 목록 또는 데이터 테이블을 쿼리하는 단일 이벤트 규칙을 포함합니다.
    • 멀티 이벤트 규칙: 구성된 일정에 따라 이벤트 시간의 일괄 처리된 블록 (예: 10분 또는 1시간 간격 또는 48시간 초과 기간의 경우 match_window / 10)에서 데이터를 쿼리합니다.
  • 이전 데이터에 대한 규칙 실행: Retrohunt를 통해 이전 로그에 대해 소급하여 규칙을 평가합니다. 이전 스캔이 완료되면 감지가 표시됩니다.
  • 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시 (15:00 UTC)에 발생하고 시간대 메타데이터 없이 15:05 UTC에 Google SecOps에 도착합니다. 시스템은 타임스탬프를 10:00 UTC로 해석하여 규칙 평가를 백그라운드 트루업 실행으로 연기하는 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. 이벤트가 ip_address = 10.0.0.5 (호스트 이름 알 수 없음)로 오후 1시에 도착합니다.
    2. 오후 2시 30분에 10.0.0.5를 workstation-123에 연결하는 DHCP 로그가 도착합니다.
    3. 별칭 지정 파이프라인은 이전 오후 1시 이벤트를 principal.hostname = workstation-123으로 업데이트합니다.
    4. 후속 규칙 재생은 보강된 호스트 이름을 평가하고 초기 실행 중에 트리거되지 않은 감지를 표시합니다.

참조 목록

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

존재하지 않는 규칙

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

데이터 처리 및 트루업 제한사항

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

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

규칙 감지 지연 문제 해결

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

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

감지 지연 시간을 단축하는 팁

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

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

다음 단계

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

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