규칙 감지 지연 이해하기

다음에서 지원:

Google secops SIEM

이 문서에서는 Google Security Operations의 규칙 감지 지연을 설명하고, 지연에 영향을 미치는 요인을 파악하며, 문제 해결 접근 방식을 간략하게 설명하고, 가능한 경우 지연을 줄이는 기법을 제안합니다.

감지 규칙

감지 규칙은 정규화된 원시 로그인 일반 및 항목 범용 데이터 모델 (UDM) 이벤트를 모두 검사하여 규칙 사양에 따라 감지를 생성합니다. 엔티티 UDM 이벤트에는 일반적으로 사용자 또는 애셋 세부정보와 같은 컨텍스트 정보가 포함됩니다. 또한 규칙은 이전에 생성된 감지 항목을 기반으로 감지 항목을 생성합니다.

예상된 지연과 예상치 못한 지연

규칙 감지에는 항상 지연이 발생하며, 지연 시간은 거의 실시간에서 몇 분 또는 몇 시간까지 다양합니다. 규칙 유형, 실행 빈도, 감지 생성 방법과 같은 요소가 이러한 지연에 영향을 미칩니다. 이 문서에서는 이러한 지연 요인과 기타 지연 요인을 살펴봅니다.

지연은 예상 또는 예측 불가로 분류됩니다.

• 예상되는 지연: 이러한 지연은 수집 프로세스와 감지 규칙을 설정할 때 선택한 구성으로 인해 발생합니다.
  예를 들어 감지를 만드는 데 시간이 걸립니다. 이러한 지연은 규칙 유형, 실행 빈도, 감지 생성 방법, 알려진 제한사항, 기타 예측 가능한 요인과 같은 알려진 구조적 요인에 따라 달라집니다.
  이 문서에 설명된 대로 감지 규칙 구성을 변경하거나 조정하여 이러한 지연을 최소화할 수 있습니다.
  자세한 내용은 지연 시간 단축을 위한 팁을 참고하세요.

• 예상치 못한 지연: 이벤트 데이터가 Google SecOps에 도착하는 데 걸리는 시간, Google SecOps 서비스 내 처리 파이프라인의 일시적인 속도 저하, 재강화, 기타 데이터 처리 지연 등 여러 요인으로 인해 발생하는 규칙별 또는 이벤트별 지연입니다.

규칙 감지 지연 분석

규칙 감지 지연을 분석하려면 규칙과 주변 요인에 관한 정보를 찾으세요.

1. Google SecOps 콘솔에서 감지 > 규칙 및 감지로 이동합니다.

   규칙 대시보드에는 Rule name, Rule type, Run frequency과 같은 규칙 메타데이터가 표시됩니다.

   자세한 내용은 규칙 대시보드에서 규칙 보기를 참고하세요.

2. 규칙 대시보드에서 검색을 사용하여 감지 지연이 긴 규칙을 식별합니다.

3. 특정 규칙 실행의 경우 감지 지연 시간에 영향을 미칠 수 있는 여러 요인이 있습니다. Rule type, Run frequency, Event type, Event time, Ingested time과 같은 측정기준은 특정 감지가 지연된 이유를 파악하는 데 유용한 휴리스틱입니다.

4. 다음 주제를 숙지하여 이러한 요소가 규칙 감지 지연에 미치는 영향을 파악하세요.

   • 감지 생성 방법
   • 알려진 제한사항
   • 규칙 감지 지연에 영향을 미치는 요인

감지 생성 방법

시스템에서 규칙 감지를 생성하는 방법을 알아보고 감지 생성 방법이 감지 지연에 미치는 영향을 파악하세요.

시스템은 다음과 같은 방식으로 규칙 감지를 생성합니다.

1. 스트리밍 엔진

   스트리밍 엔진은 일반적으로 5분 미만의 지연으로 작동하는 빠른 파이프라인입니다. 참조 목록이나 데이터 테이블과 같은 일치 섹션이 없고 외부 데이터 세트가 없는 단일 이벤트 규칙을 처리합니다.

2. 쿼리 엔진

   쿼리 엔진은 다음과 같이 규칙을 처리합니다.

   • 복잡한 단일 이벤트 규칙:

     • 참조 목록 또는 데이터 테이블을 참조하는 단일 이벤트 규칙
     • 간단한 조건으로 일치 창을 사용하는 창이 있는 단일 이벤트 규칙 예를 들어 '이벤트 수가 0보다 큰 이벤트'입니다. 이러한 규칙은 새 데이터가 수집되고 규칙 처리에 사용할 수 있게 되면 고빈도 (실시간) 쿼리 속도로 실행됩니다.

   • 다중 이벤트 규칙: 이러한 규칙은 설정한 일정에 따라 이벤트 시간 블록(10분, 시간별, 일별)에 대해 데이터를 쿼리합니다.
     예를 들어 10분 일정의 경우 규칙은 업스트림 처리 타임라인에 따라 5~8시간 및 24~48시간 후에 이벤트 시간 블록을 다시 쿼리합니다.

3. 이전 데이터에 대해 실행되는 규칙

   자세한 내용은 레트로 헌트를 참고하세요.

4. UDM 이벤트 재강화

   자세한 내용은 UDM 이벤트 재강화 및 엔티티 컨텍스트 그래프 처리를 참고하세요.

알려진 제한사항

다음은 규칙 감지 지연의 원인이 되는 표준 제한사항입니다.

• 강화 지연이 예상보다 오래 걸릴 수 있습니다. 보강 재처리로 인해 후속 규칙 실행에서 데이터를 다시 평가합니다. 시스템은 여러 번의 보강을 실행하며 마지막 실행은 이벤트 시간 3일 후에 발생합니다.
• 다중 이벤트 규칙은 기본 이벤트의 이벤트 시간으로부터 몇 시간이 지난 후에 도착하는 컨텍스트 데이터를 결합하는 경우가 많습니다. 이 컨텍스트 데이터의 지연 시간이 길면 재강화 처리와 규칙 재실행이 상호작용하여 감지가 지연될 수 있습니다. Google SecOps는 이 기능을 사용하여 매우 늦게 도착하는 데이터를 처리하지만, 탐지 기간 (이벤트 시간 블록)과 알림 생성 시간 사이에 긴 시간 간격이 있는 것으로 표시됩니다.
• 컨텍스트 인식 규칙은 애셋 및 ID 별칭 지정 또는 항목 컨텍스트 그래프와 같은 보강 소스를 사용하는 규칙입니다. 이러한 규칙은 여러 이벤트 소스를 사용하므로 지연이 발생할 가능성이 더 높습니다.
• 시스템은 초기 규칙 실행 후 5~8시간 사이에 규칙을 다시 실행하고 24~48시간 사이에 다시 실행합니다. 이 두 개의 별도 규칙 재실행은 재처리 파이프라인 실행 시간에 따라 발생합니다.

규칙 감지 지연 문제 해결

소거법을 통해 규칙 감지 지연 문제를 해결합니다.

다음 제안된 접근 방식을 따라 규칙 감지 지연을 조사하고 해결하세요.

1. 명백한 지연 확인:

   수집 지연이 있는지 확인합니다.

   1. Google SecOps 콘솔에서 감지 > 규칙 및 감지로 이동합니다.

   2. 규칙 대시보드에서 분석할 규칙을 검색합니다.

   3. Event time와 Ingested time을 비교합니다.

      예를 들어 특정 규칙 감지의 경우 Event time와 Ingested time 사이에 큰 격차가 있으면 감지 지연이 예상되는 지연에 기인할 수 있습니다.

2. 컨텍스트 소스 수집 시간 검토:

   컨텍스트 소스의 수집 시간을 확인합니다.

   컨텍스트 인식 규칙에는 다음 컨텍스트 소스가 포함될 수 있습니다. 수거 시간을 확인합니다.

   • UDM 보강에서 파생된 필드입니다.
   • principal 필드가 포함된 이벤트

   • graph.entity 필드를 참조하는 규칙

     graph.entity 구문을 사용하여 엔티티 컨텍스트 그래프 (ECG)를 참조하는 규칙은 특히 지연 시간이 길 수 있습니다. 예를 들어 ECG 파이프라인은 컨텍스트 데이터를 생성하며, 이 프로세스는 데이터 유형에 따라 30시간 또는 경우에 따라 최대 8일이 걸릴 수 있습니다.

   자세한 내용은 데이터 처리 지연을 참고하세요.

3. 규칙의 실행 빈도 및 일치 기간 구성을 검토합니다.

   • 빈도: 규칙의 실행 빈도를 확인합니다. 실행 빈도가 낮게 구성된 규칙은 자연스럽게 감지 지연이 길어집니다.
   • 일치 기간: 규칙에 일치 기간이 있는 경우 최소 지연 시간은 해당 기간입니다.
   • 실행 빈도와 일치 기간의 관계: 실행 빈도가 일치 기간과 호환되는지 확인합니다. 예를 들어 일치 기간이 5분인 경우 10분 실행 빈도가 허용됩니다. 하지만 일치 기간이 10분을 초과하면 다음으로 사용 가능한 실행 빈도인 1시간을 사용하세요.

4. 최근 인시던트 확인:

   데이터 피드의 지연 또는 문제를 일으켰을 수 있는 최근 사고가 있는지 확인합니다.

지연 시간을 줄이기 위한 팁

감지 규칙 구성을 업데이트하려면 규칙 편집기를 사용하여 규칙 관리를 참고하세요.

가능한 경우 다음 기법을 사용하여 지연을 줄이세요.

• 지연 시간에 민감한 규칙의 경우 가장 자주 실행되는 옵션을 사용하세요.

  • 규칙 실행 빈도 늘리기:

    지연을 줄이려면 규칙 유형과 일치 기간에 따라 가능한 가장 높은 빈도를 구성하세요.

    • 단일 이벤트 규칙: 거의 실시간을 사용합니다.
    • 일치 기간이 60분 미만인 멀티 이벤트 규칙: 10분을 사용합니다.
    • 일치 기간이 60분 이상인 규칙: 적절한 경우 1시간 또는 24시간을 사용합니다.

    자세한 내용은 실행 빈도 설정을 참고하세요.

  • 일치 기간 줄이기:

    일치 기간이 짧을수록 효율성이 높아집니다. 10분 처리를 사용 설정하려면 60분 일치 기간을 59분으로 변경합니다.

• 늦게 도착하는 데이터 방지:

  늦게 도착한 데이터는 초기 쿼리를 놓치고 시스템은 5~8시간 후에 이벤트 시간 블록을 다시 쿼리할 때만 이를 처리하므로 상당한 지연이 발생합니다. 정시 데이터는 일반적으로 20분 정도 지연됩니다.

규칙 감지 지연의 원인

규칙 유형, 실행 빈도, Google SecOps의 수집 속도는 규칙 감지 지연의 주요 요인입니다.

다음 요인이 규칙 감지 지연에 영향을 미칩니다.

규칙 유형

• 단일 이벤트 규칙:

  단일 이벤트 규칙은 스트리밍 접근 방식을 사용하여 거의 실시간으로 실행되므로 가능한 경우 지연을 최소화하는 데 사용하세요.

  • 간단한 단일 이벤트 규칙

    이러한 규칙은 단일 이벤트를 감지하며 참조 목록, 데이터 테이블, 일치 기간 또는 사용자 및 조직체 행동 분석 (UEBA)을 사용하지 않습니다. 이러한 규칙은 스트리밍 방식으로 거의 실시간으로 실행되며 탐지 지연이 가장 짧습니다.

    참고: suppression_window 옵션을 사용하여 단일 이벤트 규칙에 알림 숨기기를 적용할 수 있습니다.

  • 복잡한 단일 이벤트 규칙

    • 기간 단일 이벤트 규칙

      일치 기간이 포함된 단일 이벤트 규칙으로, 일반적으로 다른 단일 이벤트 규칙보다 지연 시간이 약간 더 깁니다. 일치 창은 일반적으로 규칙이 하나 이상의 이벤트를 검사하는 기간입니다.

    • 단일 이벤트 규칙 참조

      참조 목록 또는 데이터 표가 포함된 단일 이벤트 규칙입니다.

• 여러 이벤트 규칙:

  여러 이벤트 규칙은 예약된 일정에 따라 실행되므로 예약된 실행 간의 시간으로 인해 지연이 길어집니다.

  • 여러 이벤트 규칙

    이러한 규칙은 두 개 이상의 UDM 이벤트 조건을 검사합니다. 일반적으로 일치 기간과 여러 조건이 있습니다.

  • 컨텍스트 인식 규칙

    컨텍스트 인식 규칙을 사용하면 원격 분석의 행동 패턴과 이러한 패턴의 영향을 받는 항목 컨텍스트를 모두 이해할 수 있습니다.

    • 이러한 규칙은 두 개 이상의 조건으로 구성되지만 하나 이상의 조건은 UDM 항목 이벤트입니다 (UDM 이벤트가 context 유형임, 예: user_context).
    • 이러한 유형의 규칙은 지연이 더 길며 탐지에 며칠이 걸리는 경우가 많습니다.
    • 컨텍스트 인식 규칙은 시스템에서 먼저 필요한 컨텍스트 데이터를 생성해야 하므로 일반적으로 지연이 가장 깁니다.

단일 이벤트와 여러 이벤트 규칙의 차이점에 대해 자세히 알아보세요.

규칙 실행 빈도

규칙 실행 빈도는 감지 지연에 직접적인 영향을 미칩니다.

• 거의 실시간: 실시간 데이터에 대해 규칙이 더 자주 실행되며 지속적으로 실행됩니다. 이는 단일 이벤트 규칙에만 적용됩니다.
• 기타 빈도: 기타 규칙 유형의 경우 다음 빈도를 설정할 수 있습니다.
  • 10분 빈도는 일치 기간이 60분 미만인 경우에 유효합니다.
  • 1시간 및 24시간 빈도는 일치 기간이 48시간 미만인 경우에 유효합니다.
  • 24시간 빈도는 48시간 이상의 모든 일치 기간에 유효합니다.

가능한 해결 방법: 더 빠른 감지를 위해 더 짧은 실행 빈도와 더 작은 일치 기간을 사용하세요. 더 짧은 일치 기간 (1시간 미만)을 사용하면 더 자주 실행됩니다.

일치 기간

규칙에 일치 기간이 있는 경우 시스템이 전체 기간이 발생할 때까지 기다려야 하므로 기간이 최소 감지 지연 시간을 결정합니다.

수집 지연

수집 지연은 이벤트가 발생한 후 Google SecOps에서 데이터를 수집하는 데 걸리는 시간을 의미합니다.

데이터가 늦게 도착하면 초기 쿼리 기간을 놓치게 됩니다. 후속 기록 처리 쿼리에서 이를 선택하지만 이로 인해 5~8시간의 지연이 발생할 수 있습니다.

예를 들어 이벤트 A (오전 9시 3분 이벤트 시간)와 이벤트 B (오전 9시 5분 이벤트 시간)는 30분 이내에 두 개의 이벤트를 찾는 규칙의 일부입니다. 이벤트 A가 오전 10시 5분 (1시간 지연)에 도착하면 오전 9시~9시 30분 블록의 초기 쿼리를 놓치게 됩니다. 오후 2~5시 사이에 해당 블록에 대한 후속 쿼리가 실행되면 감지가 생성되어 5~8시간의 지연이 발생합니다.

문제 해결: 이벤트가 발생하는 즉시 Google SecOps로 데이터를 전송하는지 확인합니다. 감지를 검토할 때는 UDM 이벤트와 수집 타임스탬프를 주의 깊게 확인하세요.

시간대 문제

Google SecOps SIEM 기본 시간대는 UTC입니다. 로그에 명시적인 시간대 정의가 포함되지 않으면 시스템에서 UTC로 해석합니다. 잘못된 해석으로 인해 시스템에서 실시간으로 로그를 수신하더라도 로그가 늦게 도착한 것으로 처리되어 감지가 지연될 수 있습니다.

예를 들어 이벤트 시간이 오전 10시(동부 시간)(15:00 UTC)인 로그가 15:05 UTC에 도착하지만 시간대가 없습니다. 로그에 시간대가 없는 경우 시스템은 이벤트 시간을 10:00 UTC로 해석합니다. 그런 다음 시스템에서 해석된 이벤트 시간(오전 10시(UTC))과 실제 수집 시간(오후 3시 5분(UTC)) 간의 5시간 지연을 계산합니다. 이 계산된 지연으로 인해 규칙에서 실시간 수집을 기반으로 처리에 우선순위를 지정하므로 감지 지연이 발생합니다.

해결 방법: 원래 데이터의 이벤트 타임스탬프가 UTC 이외의 시간대에 있는 경우 다음 중 하나를 시도해 보세요.

• 원본 데이터의 이벤트 시간대를 업데이트합니다.
• 로그 소스에서 시간대를 업데이트할 수 없는 경우 지원팀에 문의하여 시간대를 재정의하세요.
• 또는 BindPlane 프로세서를 사용하여 타임스탬프를 수정하고 UTC로 형식을 지정하거나 적절한 시간대 표시기를 추가합니다. 자세한 내용은 BindPlane을 사용하여 로그 본문 타임스탬프 수정을 참고하세요.

컨텍스트 조인

UEBA 또는 항목 그래프와 같은 문맥 데이터를 사용하는 다중 이벤트 규칙은 지연 시간이 더 길 수 있습니다. Google SecOps에서 먼저 컨텍스트 데이터를 생성해야 합니다.

보강 시스템

Google SecOps는 다른 소스의 컨텍스트 데이터를 추가하여 UDM 이벤트를 보강합니다. 이 과정은 일반적으로 30분 이내에 완료됩니다. 이 보강된 데이터를 UDM 이벤트에 추가하는 데 지연이 발생하면 감지 시간이 늘어날 수 있습니다.

규칙에서 보강된 필드를 평가하는지 확인하려면 이벤트 뷰어를 검토하세요. 규칙에서 보강된 필드를 평가하는 경우 감지가 지연될 수 있습니다.

자세한 내용은 데이터 보강을 참고하세요.

별칭 지정 및 보강

별칭 지정과 보강은 Google SecOps 보안 데이터 보강 프로세스의 두 단계로, 이벤트 레코드와 컨텍스트 데이터를 상호 연관시키고 추가합니다. 별칭 지정은 연결을 찾고 강화는 해당 연결된 데이터로 UDM 필드를 채웁니다. 이 프로세스를 통해 채워진 필드를 별칭이 지정된 필드 또는 강화된 필드라고 합니다.

• 별칭 지정: 동일한 항목의 여러 이름 또는 식별자를 식별하고 연결하는 프로세스입니다. 표시기를 설명하는 추가 컨텍스트 데이터를 찾습니다. 예를 들어 별칭을 사용하면 단일 hostname (예: alex-macbook)를 IP addresses, MAC addresses (DHCP 로그에서) 또는 user ID (예: alex)와 같은 관련 표시기를 job title 및 employment status (사용자 컨텍스트 데이터에서)에 연결할 수 있습니다.
• 보강: 별칭 지정에서 수집된 정보를 사용하여 UDM 이벤트에 컨텍스트를 추가하는 프로세스입니다. 예를 들어 IP address만 있는 새 이벤트가 도착하면 보강 프로세스에서 별칭이 지정된 데이터를 사용하여 연결된 hostname (예: alex-macbook)을 찾고 $udm.event.principal.hostname 필드를 채웁니다.

Google SecOps는 애셋 (예: 호스트 이름, IP, MAC), 사용자, 프로세스, 파일 해시 메타데이터, 지리적 위치, 클라우드 리소스 등 여러 엔티티 유형의 별칭 지정 및 보강을 지원합니다. 자세한 내용은 UDM 보강 및 별칭 지정 개요를 참고하세요.

UDM 이벤트 재강화

• 기본 데이터 변경: 시스템에서 이벤트를 수집한 후 이벤트 수집 후 기본 데이터가 변경되면 시스템에서 최대 24시간 동안 이전 데이터를 다시 처리하고 이벤트를 업데이트합니다.

• 강화 시스템 업데이트: 강화 시스템에서 엔티티 또는 프로세스 메타데이터, IP 지리정보, VirusTotal 표시기를 업데이트하면 규칙 엔진에서 24~48시간 후에 이러한 블록을 다시 평가하여 업데이트를 포착합니다.
  예: 오전 9시 3분에 발생한 이벤트에는 entity.asset.hostname = hostnameA가 있지만 IP는 없습니다. 오전 8시 55분의 DHCP 로그에 hostnameA = IP 1.2.3.4가 표시됩니다. 규칙 엔진은 오전 9시 10분에 실행되며 규칙이 일치하지 않습니다. 강화 처리 파이프라인은 해당 기간의 hostnameA를 1.2.3.4와 상호 연관시켜 UDM 이벤트를 업데이트합니다. 이제 규칙이 일치하고 시스템에서 감지를 생성합니다.

• 지연된 컨텍스트 데이터: 초기 로그 후 3일이 지나 hostname와 같은 컨텍스트 데이터를 전송하면 시스템에서 UDM 이벤트를 다시 보강합니다. 이 다시 보강된 데이터를 찾는 규칙이 다시 실행되어 감지를 생성합니다. 이 기능은 컨텍스트가 지연되더라도 시스템에서 감지를 생성하도록 합니다.

• 강화 데이터 변경: 강화 데이터가 변경되면 처음에는 일치하지 않았던 규칙이 나중에 일치할 수 있습니다.
  예를 들어 오전 9시 3분에 발생하는 이벤트에는 entity.ip_geo_artifact.country_or_region = USA이 있습니다. 규칙 엔진이 오전 9시 10분에 실행되어 오전 9시~10시를 쿼리하고 규칙이 일치하지 않습니다. 나중에 리치 미디어 재처리에서 지리정보를 캐나다로 업데이트합니다. 규칙이 다시 실행되면 이제 일치하고 시스템에서 감지를 생성합니다.

항목 컨텍스트 그래프 처리

시스템은 침해 지표 (IOC) 또는 애셋 컨텍스트 데이터와 같은 컨텍스트를 제공하기 위해 로그 데이터에 항목 컨텍스트 그래프 (ECG) 정보를 생성하고 추가합니다. ECG 파이프라인은 주로 일괄 처리에 의존하므로 엔티티 컨텍스트 정보는 규칙 실행으로 감지가 생성된 후에만 업데이트되는 경우가 많습니다.

레트로 헌트

Retro Hunt를 사용하여 이전 데이터에 대해 규칙을 실행하면 Retro Hunt 프로세스가 완료된 후에만 감지가 생성됩니다. 이 프로세스에는 상당한 시간이 걸릴 수 있으며, 이로 인해 감지가 지연됩니다.

소급 업데이트 프로세스의 예:

1. 초기 이벤트: ip_address = 10.0.0.5가 포함된 이벤트가 오후 1시에 도착합니다. 현재 hostname을 알 수 없습니다.
2. 별칭 지정 소스 도착: 2시 30분 (1시간 이상 후)에 1시의 DHCP 로그가 도착하여 10.0.0.5를 workstation-123에 연결합니다.
3. 소급 적용: 별칭 시스템이 이 새로운 링크를 처리합니다. 오후 1시부터 UDM 이벤트를 소급하여 업데이트하고, 이전에 비어 있던 $udm.event.principal.hostname 필드를 workstation-123 값으로 보강합니다.
4. 감지: 이제 후속 규칙 실행 (정리 실행)에서 풍부해진 값 (workstation-123)을 확인하고 이전에 누락된 감지를 트리거할 수 있습니다.

참고: 실시간 감지 규칙의 지연 시간 모니터링 측정항목과 레트로헌트 감지 규칙의 지연 시간 모니터링 측정항목을 구분할 수 없습니다. 감지 지연 시간 모니터링 측정항목이 왜곡되지 않도록 라이브 규칙을 사용하여 소급 검색 규칙을 시뮬레이션하지 마세요. 전용 감지 규칙을 만들어 소급 검색 규칙으로 실행하는 것이 좋습니다.

참조 목록

규칙 실행은 항상 최신 버전의 참조 목록을 사용합니다. 예약된 규칙이 다시 실행되면 시스템에서 업데이트된 참조 목록 콘텐츠를 기반으로 새로운 감지를 생성할 수 있습니다. 이러한 감지는 참조 목록 업데이트 전에 수집된 데이터를 기반으로 하므로 늦게 표시될 수 있습니다.

감지 지연을 줄이려면 다음을 수행하세요.

• 이벤트가 발생하는 즉시 로그 데이터를 Google SecOps로 전송합니다.
• 감사 규칙을 검토하여 존재하지 않는 데이터 또는 컨텍스트가 보강된 데이터를 사용할지 결정합니다.
• 실행 빈도를 더 적게 구성합니다.

존재하지 않는 규칙

시스템은 존재하지 않음을 확인하는 규칙 (예: !$e 또는 #e=0을 포함하는 규칙)을 실행하기 전에 최소 1시간을 기다려 데이터가 도착할 시간을 보장합니다.

데이터 처리 지연

시스템은 초기 감지를 생성한 후에도 데이터를 계속 처리하여 새로운 감지 또는 업데이트된 감지를 생성할 수 있습니다. 자세한 내용은 규칙 재실행이 트리거되는 경우를 참고하세요.

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