규칙 리플레이 및 MTTD 이해

다음에서 지원:

이 문서에서는 규칙 재실행 (정리 실행 또는 조정 실행이라고도 함)이 늦게 도착하는 데이터와 컨텍스트 업데이트를 처리하는 방법과 이러한 재실행이 감지까지 걸리는 평균 시간 (MTTD) 측정항목에 미치는 영향을 설명합니다.

규칙 다시보기

Google Security Operations는 대량의 보안 데이터를 처리합니다. 컨텍스트 또는 상관관계 데이터에 의존하는 규칙의 정확한 감지를 보장하기 위해 규칙 엔진은 규칙 재실행 프로세스를 자동으로 실행합니다.

규칙 재생 프로세스는 다음 카테고리의 규칙을 처리합니다.

  • 단일 이벤트 규칙: 이러한 규칙은 UDM 보강 프로세스에서 이전에 평가된 이벤트를 업데이트할 때 재생됩니다. 데이터 테이블이 있는 규칙과 관련된 예외는 이 문서의 뒷부분에 있는 데이터가 늦게 도착하는 시나리오를 참고하세요.

  • 데이터 테이블이 있는 윈도우 단일 이벤트 (WSE) 규칙 및 단일 이벤트 규칙: 이러한 규칙에는 표준 단일 이벤트 및 멀티 이벤트 규칙과 다른 늦게 도착하는 데이터를 처리하기 위한 별도의 예약 메커니즘이 있습니다.

  • 여러 이벤트 규칙: 이러한 규칙은 일정에 따라 실행되어 이벤트 시간 블록을 처리합니다. 이러한 시스템은 사용자 또는 애셋 컨텍스트 데이터나 침해 지표 (IOC)와 같은 지연된 보강 업데이트를 포착하기 위해 서로 다른 간격으로 동일한 시간 블록을 반복적으로 재평가합니다. 정확한 시간은 일정 구성에 따라 다릅니다.

규칙 재생 트리거

시스템은 초기 규칙 실행 후 데이터가 도착하거나 업데이트되더라도 탐지를 포착할 수 있도록 규칙을 재평가 (다시 실행)합니다. 이 늦게 도착하는 데이터에는 다음 카테고리가 포함됩니다.

  • 늦게 도착하는 소스 이벤트: 원시 로그 또는 UDM 이벤트 자체가 이벤트의 실제 타임스탬프보다 훨씬 늦게 Google SecOps에 도착합니다.
  • 늦게 도착하는 풍부한 데이터: 이벤트와 관련된 컨텍스트 데이터 (예: 사용자, 애셋, 위협 인텔리전스)가 이벤트가 처음 처리된 후에 제공되거나 시스템에서 업데이트합니다. 이는 엔티티 컨텍스트 그래프 (ECG)와 같은 보강 파이프라인이 일괄적으로 데이터를 처리하거나 외부 데이터 소스에 의존하기 때문에 발생하는 경우가 많습니다.
  • 소급 UDM 보강 업데이트: 늦게 도착한 소스 데이터 (예: 호스트 이름을 업데이트하는 DHCP 레코드)로 인해 UDM 이벤트 필드가 변경됩니다. $udm.event.principal.hostname와 같이 감지 로직에서 별칭이 지정된 필드(강화된 필드)를 사용하는 규칙은 소스 데이터가 지연될 때 리플레이를 트리거할 수 있습니다. 이 늦은 도착은 소급하여 해당 필드 값을 업데이트합니다.

시스템은 규칙 유형과 지연된 데이터의 특성에 따라 규칙 재생을 다르게 트리거합니다. 목표는 감지 적시성과 데이터 완전성 간의 균형을 맞추는 것입니다.

시스템에서 규칙 유형별로 늦게 도착하는 데이터를 처리하는 방법

규칙 유형과 구성에 따라 지연 도착 데이터가 규칙 재평가를 트리거할 수 있는 시간 범위가 결정됩니다.

  • 단일 이벤트 규칙 (일치 기간 또는 데이터 표 없음):

    • 지연된 소스 이벤트: 일반적으로 이러한 규칙은 시스템에 도착할 때 타임스탬프가 얼마나 오래되었는지와 관계없이 이벤트를 처리합니다. 시스템은 지연된 소스 이벤트의 초기 처리에 엄격한 컷오프 기간을 적용하지 않습니다.
    • 지연된 보강: 이전에 평가된 이벤트의 보강 데이터가 도착하거나 업데이트가 발생하면 시스템에서 새 컨텍스트를 사용하여 이벤트에 대해 이러한 단일 이벤트 규칙을 다시 평가합니다. 이러한 상황은 초기 이벤트가 발생한 후 몇 시간 또는 며칠 후에 발생할 수 있습니다.

  • 데이터 테이블이 있는 기간별 단일 이벤트 (WSE) 규칙 및 단일 이벤트 규칙:

    • 이러한 규칙은 다른 단일 이벤트 규칙 또는 멀티 이벤트 규칙의 조정 일정과 동일한 지연 데이터 처리를 따르지 않습니다.
    • 동작은 다음과 같습니다.
      • 컷오프: 이러한 규칙은 이벤트 타임스탬프 이후 7일 이상 지나서 수집된 이벤트를 처리하지 않습니다.
      • 늦게 도착하는 데이터 (<7일): 시스템에서 7일 미만으로 늦게 도착하는 이벤트를 처리하지만 지연 시간이 더 길어질 수 있습니다.
      • 늦게 도착한 소스 이벤트: 이벤트 타임스탬프 후 7일 이상 지나 데이터가 Google SecOps에 도착하면 WSE 규칙에서 이벤트를 처리하지 않습니다.
      • 컨텍스트 업데이트: 이벤트의 컨텍스트가 늦게 도착하거나 이벤트가 소급하여 보강되는 경우 시스템은 보강된 이벤트에 대해 규칙을 자동으로 재평가합니다. 이 규칙 재실행은 초기 평가에서 감지가 발생하지 않았더라도 새로운 감지를 트리거할 수 있습니다.
      • 지연된 보강: 보강으로 인해 UDM 이벤트가 업데이트되면 (수집 후 최대 7일이 걸릴 수 있음) 시스템에서 업데이트된 이벤트에 대해 이러한 규칙을 다시 평가합니다. 하지만 다른 규칙 유형과 달리 데이터 표 콘텐츠를 업데이트해도 이러한 규칙에 대해 이전 이벤트가 자동으로 재평가되지는 않습니다.
      • 전환 확인 기간: 이러한 규칙은 약 7일의 전환 확인 기간을 사용하여 이벤트를 재평가합니다. 이 7일 기간 내에 속하는 이벤트에 대한 보강 데이터가 도착하면 규칙이 다시 평가됩니다.

  • 다중 이벤트 규칙:

    • 여러 이벤트 규칙은 일정에 따라 실행되며 늦은 데이터를 고려하여 시간 블록을 재평가합니다. 규칙의 일정에 따라 유효한 차단 기간이 결정됩니다.
      • 기본 실행: 시스템은 이벤트 시간과 구성된 정산 지연 시간 (예: T + 1시간)에 첫 번째 평가를 실행합니다.
      • 업데이트 실행 1: 시스템은 기본 실행 후 약 4시간 후에 첫 번째 업데이트 실행을 실행합니다. 이렇게 하면 시스템이 늦게 도착한 이벤트를 포함할 수 있습니다.
      • 트루업 실행 2 (조건부): 강화 완전성 보장을 사용 설정하면 기본 실행 후 약 30시간이 지나 시스템에서 최종 트루업 실행을 실행합니다. 이렇게 하면 시스템이 늦게 도착하는 데이터와 컨텍스트 보강을 최대 약 30시간까지 처리할 수 있습니다.
      • 컷오프 영향: 최종 조정 실행에 따라 지연 데이터를 포함하기 위한 유효 컷오프가 결정됩니다. 이 작업은 일반적으로 기본 실행 후 약 4시간이 지나면 발생합니다 (강화 완전성 보장을 사용 설정한 경우 기본 실행 후 약 30시간). 특정 기간의 최종 트루업 실행 후에 도착하는 이벤트 또는 보강은 해당 기간에 대해 이 규칙에 의해 처리되지 않습니다.

늦게 도착하는 데이터 시나리오의 예

  • 시나리오 1: 소스 이벤트 지연 - 단일 이벤트 규칙

    • Google SecOps는 3일 전의 타임스탬프가 있는 이벤트를 수집합니다. 표준 단일 이벤트 규칙은 이 이벤트를 새 데이터로 처리합니다.

  • 시나리오 2: 지연된 보강 - 단일 이벤트 규칙

    • 시스템에서 어제 로그인 이벤트를 처리했습니다. 오늘날에는 관련 사용자의 새로운 정보 (예: 부서 변경)를 수집하고 보강합니다. 시스템은 업데이트된 사용자 컨텍스트를 사용하여 로그인 이벤트에 대해 단일 이벤트 규칙을 다시 평가합니다.

  • 시나리오 3: 늦은 소스 이벤트 - 다중 이벤트 규칙 (기본 4시간 조정)

    • 기본 설정으로 예약된 멀티 이벤트 규칙의 경우 이벤트 타임스탬프로부터 3시간 후에 이벤트가 도착합니다. 이 이벤트는 초기 기본 실행 (T + 1시간)을 놓쳤지만 시스템에서 4시간의 조정 실행 중에 처리합니다.

  • 시나리오 4: 늦은 소스 이벤트 - 다중 이벤트 규칙 (강화 완성도 없음)

    • Ensure enrichment completeness를 사용 설정하지 않고 기본 실행 오프셋이 1시간인 멀티 이벤트 규칙을 구성합니다. 이벤트는 타임스탬프가 찍힌 후 6시간이 지나면 도착합니다.
    • 이 이벤트는 기본 실행 (T + 1시간)과 첫 번째 조정 실행 (T + 4시간)을 놓칩니다. 이 이벤트는 최종 조정 실행 후에 도착했으므로 해당 기간에 대해 처리되지 않습니다.

  • 시나리오 5: 지연된 보강 - 다중 이벤트 규칙 (보강 완료 포함)

    • 멀티 이벤트 규칙에 1시간 오프셋이 있고 보강 완전성 보장을 사용 설정합니다. 이벤트의 보강 데이터는 이벤트 타임스탬프 후 28시간이 지나면 도착합니다.
    • 시스템은 약 T + 31시간에 두 번째 조정 실행 중에 이 지연된 보강을 사용하여 규칙을 재평가합니다.

  • 시나리오 6: 지연된 소스 이벤트 - 일치 기간이 있는 멀티 이벤트 규칙

    • 멀티 이벤트 규칙에는 48시간 match 기간과 강화 완전성 보장이 사용 설정된 일정이 있습니다 (T + 30시간 전후의 최종 조정). 이벤트가 타임스탬프 후 36시간이 지나 도착합니다. 이 이벤트는 최종 조정 실행 후에 도착했기 때문에 이벤트 시간이 다른 이벤트에 비해 규칙의 일치 기간 내에 있더라도 처리되지 않습니다. 컷오프는 일치 기간뿐만 아니라 조정 일정에 따른 도착 시간을 기준으로 합니다.

  • 시나리오 7: 늦은 소스 이벤트 - 기간이 지정된 단일 이벤트 규칙

    • 8일 전의 타임스탬프가 있는 소스 이벤트가 늦게 도착하면 WSE 규칙의 7일 전환 확인 기간을 벗어나 처리되지 않을 수 있습니다.

타이밍 측정항목에 미치는 영향

규칙 재생으로 감지가 발생하면 시스템에서 다음 용어를 사용합니다.

  • 알림의 감지 기간 또는 이벤트 타임스탬프는 원래 악의적인 활동이 발생한 시간을 나타냅니다.
  • 생성 시간은 시스템에서 감지를 생성하는 시간으로, 훨씬 나중일 수 있으며 때로는 몇 시간 또는 며칠 후일 수도 있습니다.
  • 감지 지연 시간은 이벤트 타임스탬프와 감지의 생성 시간 간의 시간 차이입니다.

타임라인 델타 및 MTTD

초기 이벤트 타임스탬프와 감지 생성 사이의 경과 시간은 MTTD 계산에 직접적인 영향을 미칩니다.

파이프라인 / 일정 단계 평가 시기 MTTD 측정에 미치는 영향
단일 이벤트 규칙 (스트리밍) 연속(도착 후 5분 미만) 실시간 감지는 MTTD에 미치는 영향이 최소화된 진정한 플랫폼 속도를 나타냅니다.
다중 이벤트 규칙 (기본 실행) 도착 후 1~2시간 (구성된 정산 지연 시간 포함) 여러 이벤트 상관관계 상태를 집계하는 데 필요한 피할 수 없는 일괄 버퍼링 기간이 포함됩니다.
다중 이벤트 규칙 (조정 실행) 기본 실행 후 4시간 또는 30시간 늦은 보강 데이터를 통합하는 보조 (리플레이) 실행으로 인해 이 시간이 이벤트 타임스탬프에 비해 늦거나 지연된 것으로 표시됩니다. 이 델타는 MTTD 계산에 부정적인 영향을 미칩니다.

MTTD 측정 권장사항

MTTD는 초기 침해부터 위협의 효과적인 탐지까지의 시간을 정량화합니다. 규칙 재생으로 트리거된 감지를 분석할 때는 다음 권장사항을 적용하여 정확한 MTTD 측정항목을 유지하세요.

Google SecOps는 MTTD를 정확하게 측정하기 위해 사용자가 쿼리할 수 있는 여러 측정항목을 제공합니다. 이러한 측정항목에 대한 자세한 내용은 대시보드 페이지의 샘플 YARA-L 2.0 쿼리를 참고하세요.

감지 유형 열의 아이콘은 30분 이상 지연된 이벤트 데이터, 자동 보정 실행, 재처리 파이프라인 또는 레트로헌트에서 생성된 감지를 식별합니다. 이 아이콘은 Google SecOps의 알림 페이지에도 표시됩니다.

실시간 감지 시스템 우선순위 지정

가장 빠른 감지를 위해서는 단일 이벤트 규칙을 사용하세요. 이러한 규칙은 일반적으로 5분 미만의 지연으로 거의 실시간으로 실행됩니다. 또한 복합 감지를 더욱 포괄적으로 사용할 수 있습니다.

멀티 이벤트 규칙에서 규칙 재실행 고려

멀티 이벤트 규칙은 예약된 실행 빈도로 인해 본질적으로 지연 시간이 더 깁니다. 다중 이벤트 규칙에서 감지된 MTTD를 측정할 때는 자동 규칙 재생이 적용 범위와 정확도를 높인다는 점을 고려하세요. 이러한 리플레이는 늦은 컨텍스트가 필요한 위협을 포착하는 경우가 많으므로 이러한 탐지의 보고된 지연 시간이 증가합니다.

  • 중요하고 시간에 민감한 알림: 단일 이벤트 규칙 또는 실행 빈도가 가장 짧은 멀티 이벤트 규칙을 사용합니다. 일치 창을 줄여도 지연 시간에 직접적인 영향을 미치지는 않지만 최소 지연 시간을 설정하여 효율성을 높일 수 있습니다.

  • 복잡하고 장기간의 상관관계 (UEBA, 다단계 공격): 이러한 규칙은 비동기적으로 업데이트될 수 있는 광범위한 컨텍스트 조인 또는 참조 목록을 사용합니다. 문맥 또는 이벤트 데이터가 늦게 도착하여 지연 시간이 길어질 수 있지만 절대적인 속도보다는 충실도가 높은 감지라는 이점이 있습니다.

규칙을 최적화하여 지연된 보강에 대한 의존도 줄이기

감지 속도를 최적화하고 소급 적용되는 보강 실행의 영향을 최소화하려면 가능한 경우 규칙 로직에서 별칭이 지정되지 않은 필드 (다운스트림 보강 파이프라인에서 처리하지 않는 필드)를 사용하는 것이 좋습니다.

다음 단계

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

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