Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

규칙 성능 모니터링

다음에서 지원:

Google SecOps SIEM

이 가이드는 Google Security Operations에서 규칙을 생성, 배포, 모니터링하는 보안 엔지니어를 대상으로 합니다. Google SecOps 인스턴스에서 사용할 수 있는 데이터를 사용하여 규칙이 의도한 대로 작동하고 리소스를 과도하게 소비하지 않는지 모니터링하는 방법을 설명합니다. 이 데이터는 지연된 감지를 디버그하고, 늦게 도착하는 풍부한 데이터가 규칙에 미치는 영향을 파악하고, 평균 감지 시간 (MTTD)이 가장 높은 규칙을 식별하는 데 도움이 됩니다.

이 가이드에서는 다음 작업에 관한 문서를 제공합니다.

초기 출시 중에 규칙을 평가하고, 알림을 수신하고, 규칙 대시보드를 확인하여 상태를 모니터링하는 방법
감지 지연의 원인 (예: 늦은 수집 또는 비효율적인 로직)을 식별하고 감지까지의 평균 시간 (MTTD) 보고를 조정하거나 추가 규칙 제외를 사용하여 규칙을 조정하는 방법

시작하기 전에

이 문서에 설명된 대로 규칙을 보고 수정하려면 Chronicle API 편집자여야 합니다. 자세한 내용은 Google Security Operations 역할 및 권한을 참고하세요.

Google SecOps에서 규칙의 효과를 분석하기 전에 YARA-L 언어, YARA-L 쿼리, 규칙을 만들고 관리하는 방법, 대시보드를 만드는 방법을 잘 이해해야 합니다.

주요 용어

규칙: 로그 데이터가 Google SecOps 계정으로 수집될 때 위협을 자동으로 식별합니다.
할당량: 데이터 수집량, 데이터에 대해 실행할 수 있는 쿼리의 수와 복잡성, Google SecOps 계정에서 활성화된 규칙의 수와 복잡성에 대한 제한입니다.
알림 및 감지: Google SecOps 및 자체 보안 인프라에서 식별한 보안 문제로, 주의가 필요합니다.
수집: 보안 데이터를 Google SecOps로 가져오고 UDM으로 변환하는 프로세스입니다.
규칙 재실행: 관련 컨텍스트 데이터가 초기 이벤트 데이터보다 늦게 도착하거나 처리되는 경우 기존 데이터에 대해 규칙을 자동으로 다시 실행합니다.
RetroHunt: 기존 데이터에 새 규칙을 적용하여 이전에 발견되지 않은 위협을 식별합니다.

규칙 분석 방법

다음 섹션에서는 규칙의 성능을 분석하는 방법을 설명합니다.

배포 후 규칙 테스트 및 평가

프로덕션에 규칙을 처음 배포할 때는 Rule Observability 대시보드에서 24~48시간 동안 모니터링하세요.

대시보드로 이동합니다.
Rule Observability을 검색합니다.
규칙 열에서 새 규칙을 검색합니다. 규칙 관측 가능성 대시보드에는 감지 수, 수집 지연 시간, 수집부터 감지까지의 시간과 같은 통계가 포함됩니다.

규칙 논리가 우선순위가 높은 알림을 생성하기 전에 인위적인 지연을 발생시키지 않도록 하려면 감지 스키마 참조를 사용하면 됩니다. 스키마는 보안 알림을 모니터링하는 데 사용되는 구조화된 형식을 정의합니다. 감지 빈도, 위험 분포, 규칙 성능을 추적하는 데 최적화되어 있습니다. 쿼리 예를 자세히 살펴보면 스키마를 사용하는 방법을 더 잘 파악할 수 있습니다.

규칙 결과 지연의 이유 파악

다음 단계를 완료하여 규칙 결과가 지연되는지, 지연된다면 그 이유는 무엇인지 확인하세요.

감지 > 알림 및 IOC로 이동합니다.
알림 탭에서 감지 유형 열을 찾습니다.
노란색 전구 아이콘이 있는 알림을 검색합니다.
아이콘 위로 마우스를 가져가서 다음 중 어떤 요소로 감지가 트리거되었는지 확인합니다.
- 규칙 재처리: 규칙 재실행으로 인해 생성됨
- RetroHunt: 사용자가 수동으로 트리거합니다.
- 지연된 이벤트 데이터: 늦게 도착한 데이터로 인해 규칙 재생으로 생성됩니다.

규칙 재처리로 인해 생성된 감지에 대한 자세한 설명은 규칙 리플레이를 참고하세요.

감지 시간을 기준으로 알림 필터링

감지 > 알림 및 IOC로 이동합니다.
알림 탭에서 감지 시간 열의 필터 요소를 사용하여 도착 시간을 기준으로 감지를 정렬합니다.
표 상단에서 새로고침 아이콘 을 클릭하고 지금 새로고침을 클릭합니다. Google SecOps 계정에 도착한 최신 알림과 각 알림과 연결된 규칙을 확인할 수 있습니다 (규칙 이름 열 확인).

메타데이터 검사

규칙의 실적에 대한 추가 정보를 확인하려면 latencyMetrics을 사용하여 원시 감지 JSON을 검사하여 oldestEventTime와 oldestIngestionTime의 차이점을 찾으면 됩니다.

감지 타이밍 값

다음 표에는 DetectionTimingDetails와 관련된 열거된 값이 나와 있습니다.

값	설명	MTTD 영향
`UNSPECIFIED`	표준 일정 예약 기간 내에 감지가 생성되었습니다.	MTTD의 그라운드 트루스입니다.
`REPROCESSING`	규칙 재생 (예: 늦게 도착한 데이터)으로 인해 생성되었습니다.	운영 위험을 나타내며 보고서에 포함되어야 합니다.
`RETROHUNT`	이전 레트로헌트 실행을 통해 생성되었습니다.	일반적으로 표준 MTTD 보고에서 필터링됩니다.

예: `latencyMetrics` 메타데이터

다음 latencyMetrics 예에서는 이벤트가 발생한 시간(oldestEventTime 대 newestEventTime)과 이벤트가 수집된 시간(oldestIngestionTime 대 newestIngestionTime) 간의 시간 차이를 보여줍니다. 이벤트와 Google SecOps 계정으로의 수집 간 지연 시간은 약 53분입니다.

"detectionTimingDetails": ["DETECTION_TIMING_DETAILS_REPROCESSING"],
"latencyMetrics": {
  "oldestIngestionTime": "2025-12-09T16:54:14Z",
  "newestIngestionTime": "2025-12-09T16:54:14Z",
  "oldestEventTime": "2025-12-09T16:01:06Z",
  "newestEventTime": "2025-12-09T16:01:06Z"
}

문제 해결

다음 표에는 규칙과 관련하여 발생할 수 있는 문제와 해결 방법이 나와 있습니다.

문제	해결 방법
전구 아이콘이 표시되지만 열거형은 `UNSPECIFIED.`입니다.	이벤트 시간과 수집 시간의 차이가 30분을 초과하는 경우 이는 정상적인 동작입니다. 데이터 상태 허브 측정항목을 사용하여 수집 지연의 원인을 조사합니다.
이벤트 시간에 비해 감지가 늦게 표시됩니다.	`detectionTimingDetails`을 확인합니다. 열거형 값이 `REPROCESSING`인 경우 지연은 규칙 실행 지연 시간보다는 늦게 도착한 풍부한 데이터로 인한 것일 수 있습니다. `UNSPECIFIED`인 경우 규칙 로직의 효율성을 조사합니다.
과도한 컴퓨팅	규칙이 너무 많은 데이터를 스캔하거나 비효율적인 로직이 있는 것 같습니다. 규칙 제외로 이동하거나 필터 오프로드를 사용하여 규칙을 조정하여 데이터 검색 범위를 좁힙니다.

알려진 제한사항

기준점의 엄격성: 지연된 데이터의 시각적 신호는 30분 기준점으로 고정되어 있으며 사용자 정의 지연 시간 창을 고려하지 않습니다.
데이터 상태: 규칙 관측 가능성은 규칙 상태를 알려주지만, 데이터 상태 모니터링 (수집에 가까움)은 일반적인 지연 도착 데이터 문제를 포착하는 데 더 효과적입니다.
할당량 시행: 대시보드에 리소스 사용량이 표시되지만 규칙이 할당량 한도에 가까워질 때 실시간 알림이 제공되지는 않습니다.

다음 단계

규칙 리플레이 및 규칙 감지 지연에 대한 자세한 내용은 다음을 참고하세요.

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