규칙 재생 및 MTTD 이해

다음에서 지원:

Google secops SIEM

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

규칙 재생

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

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

• 단일 이벤트 규칙: UDM 보강 프로세스가 이전에 평가된 이벤트를 업데이트하면 시스템이 단일 이벤트 규칙을 재생합니다. (아래 데이터 테이블이 있는 규칙의 예외 참고)

• 기간이 지정된 단일 이벤트 (WSE) 규칙 및 데이터 테이블이 있는 단일 이벤트 규칙: 이러한 규칙에는 표준 단일 이벤트 및 멀티 이벤트 규칙과 다른 늦게 도착하는 데이터를 처리하기 위한 고유한 일정 메커니즘이 있습니다.

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

규칙 재생 트리거

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

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

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

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

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

• 단일 이벤트 규칙 (일치 창 또는 데이터 테이블 없음):

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

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

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

• 멀티 이벤트 규칙:

  • 멀티 이벤트 규칙은 일정에 따라 실행되며 늦게 도착하는 데이터를 고려하여 시간 블록을 재평가합니다. 규칙의 일정을 구성하는 방법에 따라 유효한 마감 창이 결정됩니다.
    • 기본 일정: 시스템은 일반적으로 이벤트 시간 후 약 5시간 및 24시간 후에 자동 조정 실행을 실행합니다. 24시간 실행이 완료된 후 데이터가 도착하면 해당 시간 창에 대해 이 규칙으로 평가되지 않습니다.
    • 맞춤설정 가능한 일정 사용 설정: 이 기능을 사용하면 '실행 빈도' 설정을 통해 실행 타이밍을 더 세부적으로 제어할 수 있습니다. 규칙의 맞춤설정된 일정 구성을 참고하세요. 주요 타이밍은 다음과 같습니다.
      • 첫 번째 실행: 시스템은 이벤트 시간과 구성된 오프셋 (예: T + 1시간)에 첫 번째 실행을 실행합니다.
      • 조정 실행 1: 시스템은 첫 번째 실행 후 약 4시간 후에 첫 번째 조정 실행을 실행합니다. 즉, 시스템은 최대 약 T + 4~5시간에 도착하는 이벤트를 포함할 수 있습니다.
      • 조정 실행 2 (조건부): 보강 완전성 보장을 사용 설정하면 시스템은 첫 번째 실행 후 약 30시간 후에 최종 조정 실행을 실행합니다. 이렇게 하면 시스템에서 늦게 도착하는 데이터를 처리할 수 있는 기간이 약 T + 30~31시간으로 연장됩니다.
    • 마감 영향: 맞춤설정 가능한 일정을 사용하면 마지막 조정 실행에 따라 늦게 도착하는 데이터를 포함하기 위한 유효한 마감이 결정됩니다. 이는 일반적으로 첫 번째 실행 후 약 4시간 또는 보강 완전성 보장 을 사용 설정한 경우 첫 번째 실행 후 약 30시간 후에 발생합니다. 특정 시간 창의 최종 조정 실행 후에 도착하는 이벤트 또는 보강은 해당 창에 대해 이 규칙으로 처리되지 않습니다.
  참고: 이러한 기간은 일반적이지만 다양한 시스템 요인과 처리 지연이 정확한 타이밍에 영향을 미칠 수 있습니다. 이러한 시간은 대략적인 시간으로 제공됩니다. 실행 일정에 대한 자세한 내용은 규칙 실행 일정 관리 및 규칙의 맞춤설정된 일정 구성을 참고하세요.

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

• 시나리오 1: 늦게 도착하는 소스 이벤트 - 단일 이벤트 규칙

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

• 시나리오 2: 늦은 보강 - 단일 이벤트 규칙

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

• 시나리오 3: 늦게 도착하는 소스 이벤트 - 멀티 이벤트 규칙 (기본 일정)

  • 이벤트가 이벤트 타임스탬프 후 10시간 후에 도착하면 시스템은 5시간 조정 실행 중에 이벤트를 놓치지만 24시간 조정 실행 중에 이벤트를 처리합니다. 25시간 늦게 도착하는 이벤트는 처리되지 않습니다.

• 시나리오 4: 늦게 도착하는 소스 이벤트 - 멀티 이벤트 규칙 (맞춤설정 가능한 일정)

  • 첫 번째 실행 오프셋이 1시간인 멀티 이벤트 규칙을 구성합니다. 이벤트가 타임스탬프 후 6시간 후에 도착합니다.
  • 이 이벤트는 첫 번째 실행 (T + 1시간)과 첫 번째 조정 실행 (T + 4시간)을 놓칩니다. 보강 완전성 보장 을 사용 설정하지 않으면 시스템에서 이 규칙으로 이벤트를 처리하지 않습니다.

• 시나리오 5: 늦은 보강 - 멀티 이벤트 규칙 (보강 완전성으로 맞춤설정 가능)

  • 멀티 이벤트 규칙의 오프셋은 1시간이며 보강 완전성 보장 을 사용 설정합니다. 이벤트의 보강 데이터가 이벤트 타임스탬프 후 28시간 후에 도착합니다.
  • 이 늦게 도착하는 보강 데이터 중 일부는 약 T + 30시간에 발생하는 두 번째 '조정 실행'에 사용할 수 있습니다 (보강 완전성 보장 을 사용 설정했기 때문). 보강 데이터를 사용할 수 있는 경우 시스템은 이 늦게 도착하는 보강을 사용하여 규칙을 재평가합니다.

• 시나리오 6: 늦게 도착하는 소스 이벤트 - 일치 창이 있는 멀티 이벤트 규칙

  • 멀티 이벤트 규칙에는 48시간 match 창과 보강 완전성 보장 이 사용 설정된 맞춤설정된 일정 (최종 조정 약 T + 30시간)이 있습니다. 이벤트가 타임스탬프 후 36시간 후에 도착합니다. 이벤트 시간은 다른 이벤트와 관련된 규칙의 일치 창 내에 있지만 최종 조정 실행 후에 도착했으므로 이 이벤트는 처리되지 않습니다. 마감은 일치 창뿐만 아니라 조정 일정과 관련된 도착 시간을 기준으로 합니다.

• 시나리오 7: 늦게 도착하는 소스 이벤트 - 기간이 지정된 단일 이벤트 규칙

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

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

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

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

늦게 도착하는 데이터로 인한 재보강 또는 컨텍스트 소스 업데이트 예: 항목 컨텍스트 그래프 (ECG) 의 지연 시간은 일반적으로 감지 지연 시간이 길어집니다.

이 시간 차이로 인해 감지가 '늦게' 또는 '지연'된 것으로 표시될 수 있으며, 이는 분석가를 혼동시키고 MTTD와 같은 실적 측정항목을 왜곡할 수 있습니다.

측정항목 구성요소	시간 소스	재생이 MTTD에 미치는 영향
감지 창 / 이벤트 타임스탬프	원래 보안 이벤트가 발생한 시간입니다.	재생은 이 시간을 이벤트 시간에 정확하게 유지합니다.
감지 시간 / 생성 시간	엔진에서 실제로 감지를 내보낸 시간입니다.	늦게 도착하는 보강 데이터를 통합하는 보조 (재생) 실행으로 인해 이 시간이 이벤트 타임스탬프에 비해 늦게 또는 지연된 것으로 표시됩니다. 이 델타는 MTTD 계산에 부정적인 영향을 미칩니다.

MTTD 측정 권장사항

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

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

아이콘은 시스템에서 30분 이상 늦게 도착하는 이벤트 데이터, 규칙 재처리 실행 또는 소급 검색에서 생성하는 감지를 식별합니다. 이 아이콘은 Google SecOps의 알림 페이지에도 표시됩니다.

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

가장 빠른 감지를 위해서는 단일 이벤트 규칙을 사용하세요. 이러한 규칙은 거의 실시간으로 실행되며 일반적으로 5분 미만의 지연 시간이 있습니다.

또한 복합 감지의 보다 포괄적인 사용을 지원합니다.

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

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

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

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

규칙을 최적화하여 늦은 보강에 대한 의존도 줄이기

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

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