규칙 실행 예약 이해

다음에서 지원:

이 문서는 Google Security Operations에서 규칙 실행을 예약하는 방법을 이해하고 관리하려는 보안 분석가, 엔지니어, 플랫폼 관리자를 대상으로 합니다. 규칙 구성이 처리 빈도를 결정하는 방법, 시스템이 거의 실시간 스트리밍과 예약된 일괄 처리의 균형을 맞추는 방법, 백그라운드 실행이 늦게 도착하는 로그와 컨텍스트 보강을 처리하는 방법을 설명합니다.

일반적인 사용 사례

올바른 일정을 선택하거나 이해하는 것은 위협 심각도와 논리 복잡성에 따라 다릅니다.

  • 우선순위가 높은 알림: 추가 이벤트 상관관계가 필요하지 않은 단일 이벤트 일치에 대해 거의 실시간으로 중요한 위협을 감지하여 공격자 체류 시간을 줄입니다.
  • 복잡한 상관관계 및 보고: 개수, 합계 또는 슬라이딩 일치 기간을 계산하는 멀티 이벤트 규칙에 예약된 간격 (예: 10분 또는 1시간)을 사용합니다. 예약된 간격은 시스템이 실행 전에 관련 로그를 수집하고 보강하여 규정 준수 및 추세 분석을 위한 알림 정확도를 개선합니다.

주요 용어

  • 결정적 빈도: 시스템이 규칙의 일치 기간 및 규칙 유형에 따라 자동으로 할당하는 기준 실행 간격입니다.
  • 기본 실행 (T + 오프셋): 이벤트 시간 블록에 대한 감지 논리의 초기 실행입니다. 결제 지연은 늦게 도착하는 데이터를 고려하기 위해 추가된 오프셋을 나타냅니다.
  • 결제 지연: 규칙 평가가 시작되기 전에 늦게 도착하는 로그를 처리할 수 있도록 기본 실행에 추가된 버퍼 기간입니다.
  • 트루업 실행 (규칙 재생): 기본 실행 후에 도착한 로그 또는 보강 데이터를 캡처하기 위해 이전에 처리된 시간 기간을 재평가하는 자동 백그라운드 실행입니다.
  • 보강: 파이프라인 처리 중에 로그에 컨텍스트 (예: 애셋 메타데이터, 사용자 ID 또는 위협 인텔리전스 지표)를 추가하는 프로세스입니다.
  • 감지 지연: 이벤트 타임스탬프와 감지 생성 사이의 총 경과 시간입니다.

시작하기 전에

환경이 다음 요구사항을 충족하는지 확인합니다.

  • 권한: 규칙 일정을 수정하려면 Chronicle API 관리자 (roles/chronicle.admin) 또는 Chronicle API 편집자 (roles/chronicle.editor) IAM 역할이 있어야 하며, 규칙 대시보드에서 일정을 검사하려면 Chronicle API 뷰어 (roles/chronicle.viewer) 역할이 있어야 합니다.
  • 환경 확인: 예약된 간격 집계를 지원하려면 로그가 통합 데이터 모델 (UDM)에 매핑되어 있어야 합니다.

규칙 예약 작동 방식

Google SecOps는 수천 개의 규칙에서 거의 실시간 감지 지연 시간과 플랫폼 안정성의 균형을 맞춥니다. 플랫폼은 두 가지 기본 실행 모델을 사용합니다.

  1. 스트리밍 엔진: 표준 및 창이 있는 단일 이벤트 규칙 (일치 기간이 48시간을 초과하는 경우에도)을 거의 실시간으로 (일반적으로 수집 후 5분 이내) 지속적으로 평가합니다. 늦게 도착하는 이벤트와 소급 보강은 표준 실행 중에 지속적으로 평가됩니다.
  2. 예약된 쿼리 엔진: 복잡한 단일 이벤트 규칙 (참조 목록 또는 데이터 테이블 포함)을 거의 실시간으로 평가하고, 이벤트 시간의 일괄 처리 블록 (예: 10분 또는 1시간 간격 또는 48시간을 초과하는 기간의 경우 match_window / 10)에서 멀티 이벤트 규칙을 평가합니다. 멀티 이벤트 규칙에는 소스 전반에서 이벤트를 집계하고 상관관계를 지정하는 시간 기간이 필요합니다.

기본 일정 구성

규칙을 사용 설정하면 Google SecOps는 규칙의 논리 및 일치 기간에 따라 기본 실행 빈도를 자동으로 결정합니다.

규칙 유형 및 기간 크기 실행 빈도 평가 시점 트루업 실행
단일 이벤트 규칙 (표준 또는 창이 있는) 실시간 도착 직후(5분 미만) 아니요. 표준 실행에서 늦게 도착하는 보강된 데이터를 지속적으로 평가합니다.
단일 이벤트 규칙 (참조 목록 또는 데이터 테이블 포함) 거의 실시간 도착 직후(5분 미만) 아니요. 표준 쿼리 실행 중에 늦게 도착하는 보강된 데이터를 지속적으로 평가합니다.
멀티 이벤트 규칙 (window <= 48h) 1시간마다 (또는 기간이 1시간 미만인 경우 10분마다 맞춤설정 가능) 도착 후 1~2시간 예. 자동화된 4시간 트루업 실행과 선택적 30시간 트루업 실행이 포함됩니다.
멀티 이벤트 규칙 (window > 48h) match_window / 10 (예: 10일 일치 기간의 경우 1일마다) 일치 기간에 따라 다름 (match_window / 10) 아니요. 후속 중복 실행 중에 늦게 도착하는 보강된 데이터를 평가합니다.

자동 트루업 실행

수집 지연 시간 또는 늦게 도착하는 보강 메타데이터 (예: 애셋 태그 또는 사용자 별칭)로 인해 감지가 누락되는 것을 방지하기 위해 시스템은 멀티 이벤트 규칙 (window <= 48h)에 대해 백그라운드 트루업 실행을 자동으로 실행합니다.

  1. 초기 실행: 즉각적인 위협을 노출하기 위해 예약된 간격에 따라 최대한 빨리 실행됩니다.
  2. 첫 번째 트루업 실행 (4시간): 늦게 도착하는 로그를 캡처하기 위해 초기 실행 후 약 4시간 후에 시간 블록을 재평가합니다. 이 단계에서는 전체 데이터 보강을 기다리지 않습니다.
  3. 두 번째 트루업 실행 (30시간): (선택사항) 모든 추가 컨텍스트 및 데이터 보강 파이프라인이 완료된 후 초기 실행 후 약 30시간 후에 실행됩니다.

트루업 동작 및 시나리오에 대한 자세한 내용은 규칙 재생 및 MTTD 이해를 참고하세요.

맞춤설정 가능한 일정

일치 기간이 48시간 이하인 맞춤 멀티 이벤트 규칙의 경우 Google SecOps를 사용하면 시스템 기본값에 전적으로 의존하는 대신 일정 매개변수를 맞춤설정할 수 있습니다.

  • 빈도 선택: 10분마다 (일치 기간이 60분 미만인 경우) 또는 1시간마다와 같은 실행 빈도를 선택합니다.
  • 결제 지연: 알려진 로그 소스 수집 지연 시간을 수용하기 위해 버퍼 지연 (T + 오프셋)을 추가합니다.
  • 보강 완료: 최종 평가 전에 모든 외부 메타데이터 조인이 완료되도록 트루업 처리를 30시간으로 연장합니다.

전체 구성 단계는 규칙의 맞춤설정된 일정 구성을 참고하세요.

규칙 대시보드의 일정 표시 여부

규칙 대시보드 의 규칙 일정 열에는 각 활성 규칙에 할당된 실행 일정이 표시됩니다. 비활성 규칙은 사용 설정될 때까지 활성 일정을 표시하지 않습니다.

실행 빈도를 수정하거나, 결제 지연 시간을 추가하거나, 맞춤 멀티 이벤트 규칙의 보강 대기 시간을 조정하려면 규칙의 맞춤설정된 일정 구성을 참고하세요.

감지 소스 지표

알림 페이지 및 규칙 대시보드의 감지 유형 열은 감지가 초기 실행에서 발생했는지 아니면 자동 백그라운드 실행에서 발생했는지 나타냅니다.

  • 아이콘 없음: 감지가 기본 실행 (T) 중에 또는 연속 스트리밍 엔진을 사용하여 생성되었습니다.
  • 전구 아이콘 : 감지가 30분 이상 늦게 도착하는 이벤트 데이터, 자동 트루업 실행, 재처리 파이프라인 또는 소급 검색에서 발생했습니다.

지연 시간 및 문제 해결 고려사항

규칙 실행 빈도는 감지 속도에 직접적인 영향을 미칩니다. 규칙을 설계하고 모니터링할 때는 다음 동작에 유의하세요.

  • 시간별 일정: 사용 가능한 최신 데이터를 사용하여 매시간 실행됩니다. 기본적으로 추가 버퍼는 적용되지 않습니다.
  • 일치 기간이 48시간을 초과하는 경우: 시스템은 이러한 규칙을 match_window / 10의 비율로 실행하며 트루업 실행을 실행하지 않습니다.
  • 실행 간의 불일치: 로그 수집이 지연되었거나 초기 평가 후에 컨텍스트 보강 (예: 엔티티 그래프 해결)이 완료된 경우 첫 번째 실행에서 트리거되지 않는 감지가 트루업 실행 중에 트리거될 수 있습니다.
  • 맞춤설정 옵션 누락: 단일 이벤트 규칙은 거의 실시간으로 평가되며 간격 맞춤설정을 지원하지 않습니다. 선별된 규칙은 고정 시스템 일정을 따릅니다. 일치 기간이 48시간을 초과하는 맞춤 멀티 이벤트 규칙은 match_window / 10의 빈도로 실행되며 맞춤설정할 수 없습니다.
  • 지원되지 않는 간격: 거의 실시간 실행을 선택할 수 없는 경우 규칙은 시간 전반에서 이벤트 상관관계가 필요한 멀티 이벤트 규칙이거나 예약된 일괄 처리 쿼리 엔진이 필요한 집계 (예: count 또는 sum)를 포함합니다.

자세한 문제 해결 단계는 규칙 감지 지연 이해를 참고하세요.

다음 단계

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

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