# 상관 룰(베타) ## **개요** {% hint style="info" %} 상관관계 룰은 Panther 1.108 버전부터 오픈 베타이며, 모든 고객이 사용할 수 있습니다. 버그 보고와 기능 요청은 Panther 지원 팀과 공유해 주세요. {% endhint %} {% hint style="warning" %} 이 기능은 현재 다음과 호환되지 않습니다. [Databricks 백엔드.](https://docs.panther.com/ko/search/backend/databricks) {% endhint %} Panther에서 상관관계 룰을 사용하면 로그 유형 전반에 걸친 여러 작업을 추적할 수 있습니다. 상관관계 룰에서는 다음을 지정합니다. [그룹](#group-correlation-rules) 또는 특정 [시퀀스](#sequence-correlation-rules) 의 [신호](https://docs.panther.com/ko/detections/signals) 이 일정한 시간 창 안에 발생해야 일치로 간주되며, 그다음 신호를 생성하고 선택적으로 [알러트](https://docs.panther.com/ko/alerts). 다음도 포함할 수 있습니다. *부재* 를 상관관계 룰 기준에 포함할 수 있습니다. 상관관계 룰의 일치는 룰 일치나 알러트가 아니라 신호를 기준으로 결정되므로, 알러트가 [비활성화된 룰](https://docs.panther.com/ko/signals#how-to-create-a-rule-that-only-produces-signals). 상관관계 룰은 예를 들어 다음과 같은 경우 알러트를 생성하고 싶을 때 특히 유용할 수 있습니다: * 어떤 Okta 사용자가 100회 이상의 로그인 실패 후 성공적으로 로그인한 다음, AWS에 루트 사용자로 로그인하는 경우([아래의 전체 예제 보기](#brute-force-okta-login-to-aws-root-login)) * GitHub 저장소에서 고급 보안 설정이 비활성화된 다음, 보관되지 않은 경우([아래의 전체 예제 보기](#github-repository-security-policy-disabled-without-subsequent-archival)) [아래에서 사용자 정의 상관관계 룰을 만드는 방법 알아보기](#how-to-create-a-correlation-rule), 그리고 상관관계 룰을 구성하는 YAML 키에 대해 더 알아보기 [상관관계 룰 참조](https://docs.panther.com/ko/detections/correlation-rules/correlation-rule-reference). 또한 다음도 활용할 수 있습니다. [Panther 관리 상관관계 룰](https://github.com/panther-labs/panther-analysis/tree/main/correlation_rules). {% hint style="warning" %} 상관관계 룰을 사용하면 Snowflake 컴퓨팅 비용이 증가할 수 있습니다. 상관관계 룰의 비용 효율을 높이는 방법은 다음의 지침을 참조하세요. [상관관계 룰을 더 효율적으로 만드는 방법](#making-correlation-rules-more-efficient), 아래. {% endhint %} ## 상관관계 룰의 작동 방식 상관관계 룰은 YAML로 작성되며, 이전에 생성된 [룰](https://docs.panther.com/ko/detections/rules), [예약된 룰](https://docs.panther.com/ko/detections/rules)및/또는 상관관계 룰을 참조합니다. 각 상관관계 룰은 [일정에 따라 실행되며](#setting-schedule), 그리고 ["룩백 창"을 정의합니다.](#setting-lookbackwindowminutes) 즉, 룰이 과거의 어느 시점까지를 살펴보며 [신호](https://docs.panther.com/ko/detections/signals) (또는 신호의 부재)를 찾을지에 대한 시간입니다. 상관관계 룰에 다음과 같은 추가 기준을 적용할 수 있습니다: * 특정 룰에 대해 찾아야 하는 신호의 최소 개수 또는 최대 * 한 룰에서 다른 룰로 특정 이벤트 값이 일치해야 함(예: 모든 개별 룰의 신호가 동일한 IP 주소를 포함해야 함) * 다음 단계가 [시퀀스](#sequence-correlation-rules) 일정 시간 내에 발생해야 함 ### 상관관계 룰에 일치가 있을 때 일어나는 일 상관관계 룰의 일치는 [신호](https://docs.panther.com/ko/detections/signals). 상관관계 룰에서 알러트가 활성화되어 있으면 룰 일치가 생성되며, 상관관계 룰의 [중복 제거 구성](#deduplication-of-events). [신호, 룰 일치, 알러트의 차이에 대해 여기서 더 알아보기](https://docs.panther.com/ko/detections/..#signals-vs.-rule-matches-vs.-alerts). 상관관계 룰에 대해 알러트가 생성될 때, 상관관계 룰에서 참조된 개별 룰, 예약된 룰, 상관관계 룰이 자체 알러트를 생성할 수도 있고 생성하지 않을 수도 있습니다. 이는 다음에 따라 달라집니다: * 각 개별 룰, 예약된 룰, 상관관계 룰에 알러트가 활성화되어 있는지 여부 * 개별 룰 또는 예약된 룰의 `Threshold` 값과 상관관계 룰의 `MinMatchCount` 값입니다. 상관관계 룰은 알러트를 생성하지만 이를 구성하는 룰은 생성하지 않는 예외적 상황은, 개별 룰의 이벤트 임계값( `Threshold` 키로 설정됨)이 상관관계 룰의 `MinMatchCount` 보다 높고 실제 룰 일치 수가 그 중간쯤인 경우입니다. ### 그룹 vs. 시퀀스 상관관계 룰에는 두 가지 유형이 있습니다: [그룹](#group-correlation-rules) 및 [시퀀스](#sequence-correlation-rules). 그룹과 시퀀스 상관관계 룰 모두 신호가 찾아져야 하는 룰의 모음(또는 *찾아지지 않아야 하는* 를 설정하여 `Absence: true`). 그룹 상관관계 룰은 신호가 발견된 순서와 상관없이 모든 룰에서 신호(또는 부재)가 생성되면 알러트를 생성합니다. 반면 시퀀스 룰은 알러트를 생성하기 위해 신호(또는 부재)가 특정 순서로 발견되어야 합니다. ### 일정과 룩백 창 설정 각 상관관계 룰은 다음 두 가지를 정의합니다: * 일정: 다음에 의해 정의됨 [`Schedule`](https://docs.panther.com/ko/detections/correlation-rule-reference#schedule-fields) 필드(다음 중 하나를 사용함 `RateMinutes` 또는 `CronExpression`), 일정은 상관관계 룰이 얼마나 자주 실행되어야 하는지를 나타냅니다. * 룩백 창: 다음에 의해 정의됨 `LookbackWindowMinutes` 필드이며, 룩백 창은 상관관계 룰이 과거 몇 분까지 살펴보며 [신호](https://docs.panther.com/ko/detections/signals) (또는 신호의 부재)를 해당 그룹 또는 시퀀스에 포함된 룰, 예약된 룰, 상관관계 룰에 대해 찾을지를 지정합니다. 다음 값들을 설정할 때 `Schedule` 및 `LookbackWindowMinutes`, 몇 가지 요소를 고려하는 것이 좋습니다: * 이 상관관계 룰의 일치에 대해 적시에 알러트를 받는 것이 얼마나 중요한지 * 예를 들어 우선순위가 낮은 상관관계 룰은 24시간마다 한 번만 실행해도 충분할 수 있습니다. 반대로 우선순위가 높은 상관관계 룰은 15분마다 실행하고 싶을 수 있습니다. * 상관관계 룰이 찾는 첫 번째 신호와 마지막 신호가 시간상 얼마나 떨어져 있을 수 있는지, 그래야 같은 발생으로 간주되어 일치를 생성할 수 있는지 * 참조 [신호가 룩백 창 사이에 분리되지 않도록 하기](#ensuring-signals-arent-split-between-lookback-windows) * 상관관계 룰과 연관된 룰이 평가하는 데이터 소스에서 예상되는 최대 지연 시간 * 참조 [다음에서 로그 소스 지연 시간 고려하기 `LookbackWindowMinutes`](#accounting-for-log-source-latency-in-lookbackwindowminutes) `Schedule` 및 `LookbackWindowMinutes` 값은 Snowflake 컴퓨팅 비용에 영향을 줄 수 있습니다. 자세한 내용은 [상관관계 룰을 더 효율적으로 만드는 방법](#making-correlation-rules-more-efficient) 를 참조하세요. #### 신호가 룩백 창 사이에 분리되지 않도록 하기 필요한 신호가 여러 상관관계 룰 실행의 룩백 창 사이에 분리되어 검색 중인 항목의 발생을 놓치지 않도록 룩백 창을 설정하는 것이 좋습니다.
피해야 할 상황의 예 우리가 피하려는 이 상황을 설명하기 위해, 다음의 단순화된 상관관계 룰 구성을 보겠습니다: ```yaml # 잘못된 예시; 복제하지 말 것 - 그룹: - RuleID: First.Rule - RuleID: Second.Rule - RuleID: Third.Rule 일정: RateMinutes: 60 LookbackWindowMinutes: 90 ``` 이 시나리오에서는 매시간 상관관계 룰이 이전 90분을 되돌아보며 `그룹`에 포함된 세 룰의 신호를 찾습니다. 각 룰이 아래 시간에 일치/신호 생성했다고 가정해 봅시다: * 신호 대상 `First.Rule` 오후 12:58에 생성됨 * 신호 대상 `Second.Rule` 오후 1:05에 생성됨 * 신호 대상 `Third.Rule` 오후 1:40에 생성됨 상관관계 룰은 매시 30분에 실행되도록 예약되어 있습니다. 다음 시간에 실행됩니다: * 오후 1:30(오후 12:00까지 되돌아봄): 첫 번째와 두 번째 신호(오후 12:58과 1:05)만 보이며, 따라서 일치를 생성하지 않습니다. * 오후 2:30(오후 1:00까지 되돌아봄): 두 번째와 세 번째 신호(오후 1:05와 1:40)만 보이며, 역시 일치를 생성하지 않습니다. 이 상관관계 룰의 작성자는 세 룰의 신호가 모두 42분 내(오후 12:58부터 1:40까지)에 생성되면 상관관계 룰이 일치했을 것이라고 기대했을 가능성이 높습니다. 그러나 상관관계 룰의 한 번 실행에서 룩백 창 내에 필요한 세 신호가 모두 발견되지 않았기 때문에 일치가 생성되지 않았습니다.
상관관계 룰의 일치에 필요한 신호가 서로 다른 실행에 걸쳐 분리되지 않도록(즉, 같은 룩백 창에 포함되도록) 하려면, 먼저 첫 번째 신호와 마지막 신호가 시간상 얼마나 떨어져 있어도 같은 발생으로 간주되어 알러트되어야 하는지 결정합니다. 편의상 이 값을 "최대 신호 시간 범위 분"이라고 부르겠습니다. (이 값은 다음과 혼동하면 안 됩니다 [`WithinTimeFrameMinutes`](https://docs.panther.com/detections/correlation-rules/correlation-rule-reference#transitions-fields), 이는 통과하려면 시퀀스의 두 단계가 발생해야 하는 시간 범위입니다. 상관관계 룰이 시퀀스이고 두 단계만 지정하는 경우에는 "최대 신호 시간 범위 분"과 `WithinTimeFrameMinutes` 가 같을 수 있습니다.) 다음의 값을 구성하는 것이 좋습니다. `LookbackWindowMinutes` 값이 "최대 신호 시간 범위 분" 길이의 가능한 모든 창을 상관관계 룰의 최소 한 번 실행에서 포괄하도록 하세요. 일반적으로 다음 공식으로 이를 수행할 수 있습니다: * 만약 `RateMinutes` <= "최대 신호 시간 범위 분": * `LookbackWindowMinutes` = 2 x "최대 신호 시간 범위 분" + 로그 수집 지연 시간 * 만약 `RateMinutes` > "최대 신호 시간 범위 분": * `LookbackWindowMinutes` = "최대 신호 시간 범위 분" + `RateMinutes` + 로그 수집 지연 시간 로그 수집 지연 시간을 포함하는 이유를 이해하려면 [다음에서 로그 소스 지연 시간 고려하기 `LookbackWindowMinutes`](#accounting-for-log-source-latency-in-lookbackwindowminutes) #### 다음에서 로그 소스 지연 시간 고려하기 `LookbackWindowMinutes` 로그 수집 지연 시간은 상관관계 룰과 연관된 룰이 평가하는 데이터 소스에서 예상되는 최대 지연 시간입니다. 신호는 연관된 이벤트가 발생한 시간 기준으로 룩백 창 안에서 조회되므로(`p_event_time`), *찾아지지 않아야 하는* 이벤트가 Panther에 수집된 시간(`p_parse_time`), 상관관계 룰이 마지막으로 실행된 이후의 모든 "새로운" 데이터를 처리하고 있는지 확인하려면 수집 지연 시간을 고려해야 합니다. `LookbackWindowMinutes` 예를 들어 상관관계 룰이 매시간 실행되도록 설정되어 있고(예: 를 `RateMinutes` 로 설정), 상관관계 룰과 연관된 룰이 처리하는 로그의 소스에서 Panther로의 로그 전달이 최대 3시간 지연될 수 있다고 하면, `60`을 설정할 수 있습니다. 또는 `LookbackWindowMinutes` 로 설정), 상관관계 룰과 연관된 룰이 처리하는 로그의 소스에서 Panther로의 로그 전달이 최대 3시간 지연될 수 있다고 하면, `60 + 3*60`. 이를 더 구체적으로 보면, 3시간의 수집 지연 때문에 Panther가 `240`오전 9:01에 받은 데이터는 `오전 6:01` 만큼 이른 `p_event_time` 의 `시간을 가질 수 있습니다. 상관관계 룰이 매시간 정시에 실행된다면`오전 10:00에 `, 최소한`까지 되돌아봐야 합니다. `시간을 가질 수 있습니다. 상관관계 룰이 매시간 정시에 실행된다면`. ### 이벤트의 중복 제거 상관관계 룰에서 중복 제거 기간은 [`LookbackWindowMinutes`](https://docs.panther.com/ko/detections/correlation-rule-reference#detection-fields) 필드의 값입니다. 즉, 같은 `LookbackWindowMinutes` 시간 범위 내에서 겹치는 상관관계 룰은 해당 상관관계 룰의 일치를 유발한 고유 이벤트만 포함합니다. 상관관계 룰에서 참조되는 개별 룰과 예약된 룰에 설정된 중복 제거( `dedup()`, `DedupPeriodMinutes`, `Threshold` 또는 Console에서 설정됨)는 상관관계 룰에 적용되지 않습니다. ### 상관관계 룰 오류 상관관계 룰을 작업하는 동안 다음 오류 중 하나를 받을 수 있습니다: * [Simple Detections 오류 코드](https://docs.panther.com/ko/detections/rules/writing-simple-detections/simple-detection-error-codes): 잘못된 구문을 사용하여 상관관계 룰을 구성했습니다 * [디택션 오류](https://docs.panther.com/ko/alerts#overview): 상관관계 룰 실행이 실패했습니다 * [시스템 오류](https://docs.panther.com/ko/system-configuration/notifications/system-errors): 상관관계 룰이 시간 초과되었습니다(아마도 너무 큰 `LookbackWindowMinutes` 값 때문일 수 있음) ## 그룹 상관관계 룰 그룹 상관관계 룰은 [신호](https://docs.panther.com/ko/detections/signals) (또는 신호의 부재)가 주어진 룩백 창 안에서 발생해야 하는 룰의 모음을 정의합니다. 신호는 어떤 순서로든 발생할 수 있습니다. 이벤트 모음이 특정 순서로 발생하길 원한다면 대신 [시퀀스 상관관계 룰](#sequence-correlation-rules) 을 사용하세요. ### MatchCriteria 그룹 상관관계 룰에서 `MatchCriteria` 키는 상관관계 룰이 통과하기 위해 일치하는 값을 가져야 하는 각 룰, 예약된 룰, 상관관계 룰의 필드를 정의합니다. 여러 로그 유형, 예약된 룰 또는 상관관계 룰과 연관된 룰의 경우 [`p_` 필드](https://docs.panther.com/ko/search/panther-fields) 만 일치시킬 수 있습니다. (하나의 로그 유형에만 연관된 룰의 경우, 어떤 필드든 일치시킬 수 있습니다.) 일치 기준이 정의되지 않으면, 특정 이벤트 필드 값이 일치해야 한다는 요구 사항이 없기 때문에 상관관계 룰의 구체성이 낮아집니다. 다음에 대해 더 알아보기 `MatchCriteria` on [상관관계 룰 참조](https://docs.panther.com/ko/detections/correlation-rule-reference#matchcriteria-fields). ### MinMatchCount 그룹 상관관계 룰에서 `MinMatchCount` 는 이 상관관계 룰이 일치하기 위해 필요한 최소 개수의 개별 룰, 예약된 룰 또는 상관관계 룰( `그룹`에 정의됨)을 지정하는 선택적 필드입니다. 예를 들어 `그룹` 에 다섯 개의 룰을 나열하고 `MinMatchCount: 2`를 추가하면, 다섯 개 룰 중 임의의 두 룰이 신호를 생성할 때 상관관계 룰이 일치합니다. `MinMatchCount` 는 `그룹`에 정의된 개별 룰에서도 사용할 수 있는 필드입니다. 아래의 [MinMatchCount가 있는 그룹 예제](#group-with-minmatchcount), 아래. ### 그룹 예제 아래 예제는 다음 JSON 이벤트를 참조합니다:
예제 이벤트 가독성을 위해 이 샘플 이벤트에는 일부 필드만 포함되어 있습니다. ```json [ { "p_rule_id": "Standard.BruteForceByIP", "event_type": "failed_login", "p_event_time": "2023-12-08 10:27:03.496000000", "p_alert_context": { "ip": "136.24.229.58", "geolocation": "미국 캘리포니아주 샌프란시스코" } }, { "p_rule_id": "Standard.BruteForceByIP", "event_type": "failed_login", "p_event_time": "2023-12-08 10:27:03.623000000", "p_alert_context": { "ip": "136.24.229.58", "geolocation": "미국 캘리포니아주 샌프란시스코" } }, { "p_rule_id": "Standard.BruteForceByIP", "event_type": "failed_login", "p_event_time": "2023-12-08 10:27:03.861000000", "p_alert_context": { "ip": "136.24.229.58", "geolocation": "미국 캘리포니아주 샌프란시스코" } }, { "p_rule_id": "Okta.Login.Success", "event_type": "successful_login", "p_event_time": "2023-12-08 10:27:54.317000000", "p_alert_context": { "ip": "136.24.229.58", "geolocation": "미국 캘리포니아주 샌프란시스코" } }, { "p_rule_id": "AWS.Console.RootLogin", "eventType": "AwsApiCall", "p_event_time": "2023-12-08 10:30:13.274000000", "p_alert_context": { "sourceIPAddress": "136.24.229.58" } } ] ```
{% tabs %} {% tab title="MatchCriteria가 있는 그룹" %} 이 예제에서 `MatchCriteria` 는 `IP` 필드가 네 개의 모든 룰에서 동일한 값을 포함해야 한다고 지정합니다. ```yaml 디택션: - 그룹: - ID: &failed_login Failed Login RuleID: Standard.BruteForceByIP MinMatchCount: 7 - ID: &successful_login Successful Login RuleID: Okta.Login.Success - ID: &root_access Root Access RuleID: AWS.Console.RootLogin - ID: &missing_crowdstrike Missing Crowdstrike RuleID: Crowdstrike.Detection.passthrough Absence: true MatchCriteria: ip: - GroupID: *failed_login Match: p_alert_context.ip - GroupID: *successful_login Match: p_alert_context.ip - GroupID: *root_access Match: p_alert_context.sourceIPAddress - GroupID: *missing_crowdstrike Match: p_any_ip_addresses EventEvaluationOrder: Chronological LookbackWindowMinutes: 60 일정: RateMinutes: 30 TimeoutMinutes: 7 ``` {% endtab %} {% tab title="MatchCriteria가 없는 그룹" %} 이 예제에서는 첫 번째 세 룰에 대한 신호가 발견되고 *찾아지지 않아야 하는* 네 번째 룰에는 신호가 없으면, 상관관계 룰은 통과합니다. ```yaml 디택션: - 그룹: - RuleID: Standard.BruteForceByIP MinMatchCount: 7 - RuleID: Okta.Login.Success - RuleID: AWS.Console.RootLogin - RuleID: Crowdstrike.Detection.passthrough Absence: true LookbackWindowMinutes: 60 일정: RateMinutes: 30 TimeoutMinutes: 3 ``` {% endtab %} {% tab title="MinMatchCount가 있는 그룹" %} 이 예제에서 `MinMatchCount` 값은 `디텍션` 아래에 정의된 세 룰 중 어떤 두 개에 대해 신호가 발견되면 상관관계 룰이 일치함을 지정합니다. `그룹`또한 `MinMatchCount` 가 `그룹`와 함께 사용되는 `MinMatchCount`것도 있습니다. 이 상관관계 룰이 통과하는 경우의 예는 아래 목록을 참조하세요. ```yaml 디택션: - 그룹: - RuleID: Standard.BruteForceByIP MinMatchCount: 7 - RuleID: Okta.Login.Success - RuleID: AWS.Console.RootLogin MinMatchCount: 2 LookbackWindowMinutes: 60 일정: RateMinutes: 30 TimeoutMinutes: 3 ``` 위의 상관관계 룰은 다음 상황 중 어느 하나에서도 통과합니다: * 다음에서 적어도 하나의 신호가 있을 때 `Okta.Login.Success` 그리고 다음에서 적어도 하나의 신호가 있을 때 `AWS.Console.RootLogin` * 다음에서 적어도 7개의 신호가 있을 때 `Standard.BruteForceByIP` 그리고 다음에서 적어도 하나의 신호가 있을 때 `Okta.Login.Success` * 다음에서 적어도 7개의 신호가 있을 때 `Standard.BruteForceByIP` 그리고 다음에서 적어도 하나의 신호가 있을 때 `AWS.Console.RootLogin` * 세 룰 모두에서 신호가 있을 때(적어도 7개의 신호가 `Standard.BruteForceByIP`) {% endtab %} {% endtabs %} ## 시퀀스 상관관계 룰 시퀀스 상관관계 룰은 [신호](https://docs.panther.com/ko/detections/signals) (또는 신호의 부재)가 주어진 룩백 창 안에서 특정 순서로 발생해야 하는 룰의 모음을 정의합니다. 시퀀스의 순서는 `Sequence` 키 안에 정의된 룰의 순서로 정해집니다. 상관관계 룰이 특정 순서를 요구하지 않고 단지 모든 룰에 신호(또는 부재)가 있으면 일치하도록 하려면 [그룹 상관관계 룰](#group-correlation-rules) 을 사용하세요. ### 전환 시퀀스 내에서는 전환을 선택적으로 정의할 수 있습니다. 전환은 각 단계 사이에 얼마나 많은 시간이 경과할 수 있는지, 그리고 어떤 이벤트 필드가 일치해야 하는지 등을 포함하여 시퀀스의 한 단계가 다음 단계로 이동하는 추가 기준을 정의합니다. `전환` 사용 `WithinTimeFrameMinutes` 과 `Match` 를 함께 사용하면 상관관계 룰의 구체성이 높아집니다. 전환이 정의된 경우, `Sequence`에 포함된 룰 수보다 하나 적은 수의 전환이 있어야 합니다. 또한 `전환` 내 항목들은 `Sequence` 목록의 순서와 동일해야 합니다. 현재 상관관계 룰당 일치시킬 수 있는 필드 유형은 하나만 가능합니다(예: *모든* IP 주소 필드 또는 *모든* 이메일 주소 필드). 여러 로그 유형, 예약된 룰 또는 상관관계 룰과 연관된 룰의 경우 [`p_` 필드](https://docs.panther.com/ko/search/panther-fields) 만 일치시킬 수 있습니다. (하나의 로그 유형에만 연관된 룰의 경우, 어떤 필드든 일치시킬 수 있습니다.) 전환에 대해 더 알아보기 [상관관계 룰 참조](https://docs.panther.com/ko/detections/correlation-rule-reference#transitions-fields). ### 시퀀스 예제 아래 예제는 다음 JSON 이벤트를 참조합니다:
예제 이벤트 가독성을 위해 이 샘플 이벤트에는 일부 필드만 포함되어 있습니다. ```json [ { "p_rule_id": "Standard.BruteForceByIP", "event_type": "failed_login", "p_event_time": "2023-12-08 10:27:03.496000000", "p_alert_context": { "ip": "136.24.229.58", "geolocation": "미국 캘리포니아주 샌프란시스코" } }, { "p_rule_id": "Standard.BruteForceByIP", "event_type": "failed_login", "p_event_time": "2023-12-08 10:27:03.623000000", "p_alert_context": { "ip": "136.24.229.58", "geolocation": "미국 캘리포니아주 샌프란시스코" } }, { "p_rule_id": "Standard.BruteForceByIP", "event_type": "failed_login", "p_event_time": "2023-12-08 10:27:03.861000000", "p_alert_context": { "ip": "136.24.229.58", "geolocation": "미국 캘리포니아주 샌프란시스코" } }, { "p_rule_id": "Okta.Login.Success", "event_type": "successful_login", "p_event_time": "2023-12-08 10:27:54.317000000", "p_alert_context": { "ip": "136.24.229.58", "geolocation": "미국 캘리포니아주 샌프란시스코" } }, { "p_rule_id": "AWS.Console.RootLogin", "eventType": "AwsApiCall", "p_event_time": "2023-12-08 10:30:13.274000000", "p_alert_context": { "sourceIPAddress": "136.24.229.58" } } ] ```
{% tabs %} {% tab title="전환 및 Match가 있는 시퀀스 " %} 사용 `전환` 사용 `Match` 을 `Sequence` 내에서 사용하는 것은 값이 일치해야 하는 이벤트 필드를 정의하고 싶을 때 유용합니다. ```yaml 디택션: - 시퀀스: - ID: Failed Login RuleID: Standard.BruteForceByIP MinMatchCount: 7 - ID: Successful Login RuleID: Okta.Login.Success MinMatchCount: 1 - ID: Root Login RuleID: AWS.Console.RootLogin MinMatchCount: 1 - ID: Missing Crowdstrike RuleID: Crowdstrike.Detection.passthrough Absence: true 전환: - ID: Brute Force Login Success From: Failed Login To: Successful Login WithinTimeFrameMinutes: 10 Match: - On: client.ipAddress - ID: Gained Root Access From: Successful Login To: Root Login Match: - From: client.ipAddress To: p_alert_context.sourceIPAddress - ID: Absence of Crowdstrike From: Root Login To: Missing Crowdstrike Match: - From: p_alert_context.sourceIPAddress To: p_any_ip_addresses LookbackWindowMinutes: 60 EventEvaluationOrder: Chronological 일정: RateMinutes: 30 TimeoutMinutes: 3 ``` {% endtab %} {% tab title="전환이 없는 시퀀스" %} 사용 `전환` 을 `Sequence` 없이 `Match` 는 다음을 사용하여 시퀀스의 두 단계가 발생해야 하는 시간 범위만 지정하고 싶을 때 유용합니다. `WithinTimeFrameMinutes`. ```yaml 디택션: - 시퀀스: - ID: Failed Login RuleID: Standard.BruteForceByIP MinMatchCount: 7 - ID: Successful Login RuleID: Okta.Login.Success - ID: Root Login RuleID: AWS.Console.RootLogin - ID: Missing Crowdstrike RuleID: Crowdstrike.Detection.passthrough Absence: true 전환: - ID: Brute Force Login Success From: Failed Login To: Successful Login WithinTimeFrameMinutes: 10 # 시간 범위 정의 - ID: Gained Root Access From: Successful Login To: Root Login - ID: Absence of Crowdstrike From: Root Login To: Missing Crowdstrike LookbackWindowMinutes: 60 일정: RateMinutes: 30 TimeoutMinutes: 3 ``` {% endtab %} {% tab title="전환이 없는 시퀀스" %} 다음을 생략할 수 있습니다. `전환` 내에서 `Sequence` 이벤트 필드를 일치시키거나 단계가 발생해야 하는 시간 범위를 지정하고 싶지 않다면. ```yaml 디택션: - 시퀀스: - RuleID: Standard.BruteForceByIP MinMatchCount: 7 - RuleID: Okta.Login.Success - RuleID: AWS.Console.RootLogin - RuleID: Crowdstrike.Detection.passthrough Absence: true LookbackWindowMinutes: 60 일정: RateMinutes: 30 TimeoutMinutes: 3 ``` {% endtab %} {% endtabs %} ## 상관관계 룰 테스트 특정 조건이 주어졌을 때 상관관계 룰에 대한 일치가 생성될지 여부를 평가하도록 상관관계 룰에 단위 테스트를 추가할 수 있습니다(잠재적으로 알러트를 생성함—참조 [상관관계 룰에 일치가 있을 때 일어나는 일](#what-happens-when-there-is-a-match-on-a-correlation-rule)). {% hint style="info" %} 상관관계 룰 테스트는 상관관계 로직만 테스트하기 위해 존재합니다. 상관관계 룰을 구성하는 개별 룰의 룰 로직을 테스트하려면 개별 룰 자체에 있는 단위 테스트를 사용하세요. {% endhint %} 단위 테스트는 상관관계 룰의 **단위 테스트** 탭( Panther Console에서) 또는 최상위 `Tests` 필드(CLI 워크플로우에서)에 정의되며, 구조는 [룰 또는 정책의 단위 테스트](https://docs.panther.com/ko/detections/testing). 와 유사합니다. `상관관계 룰의 각 단위 테스트에는`, `Name`, 그리고 `ExpectedResult` RuleOutputs `ExpectedResult` 필드가 포함되어야 합니다. 단위 테스트의 YAML 구조와 [값을 구성하는 방법에 대해 자세히 알아보려면 여기](https://docs.panther.com/ko/detections/correlation-rule-reference#tests-fields). {% hint style="info" %} 상관관계 룰 테스트를 작성한 후에는 다음을 사용해 실행할 수 있습니다. [Panther 분석 도구 `test` 명령](https://docs.panther.com/ko/panther/detections-repo/pat/pat-commands#test-running-unit-tests). `pat test` 로 상관관계 룰을 실행하려면 API 토큰이 필요합니다—다음 참조 [API 토큰으로 인증하기](https://docs.panther.com/ko/panther/detections-repo/pat/install-configure-and-authenticate-with-pat#authenticating-with-an-api-token) 를 참조하세요. {% endhint %} ### 단위 테스트 예제 다음 상관관계 룰을 사용합니다: ```yaml - 시퀀스: - ID: OktaLoginFailure RuleID: Okta.Login.Failure MinMatchCount: 10 - ID: OktaLoginSuccess RuleID: Okta.Login.Success MinMatchCount: 1 - ID: RootLogin RuleID: AWS.Console.RootLogin MinMatchCount: 1 전환: - ID: Okta Brute Force Login From: OktaLoginFailure To: OktaLoginSuccess WithinTimeFrameMinutes: 10 Match: - On: client.ipAddress - ID: AWS Root Login From: OktaLoginSuccess To: RootLogin Match: - From: client.ipAddress To: srcIpAddress7 일정: RateMinutes: 15 TimeoutMinutes: 2 LookbackWindowMinutes: 60 ``` 다음 테스트를 작성할 수 있습니다: {% hint style="info" %} 아래의 테스트가 룰의 YAML 파일에 포함된다면(CLI 워크플로우에서 디텍션을 관리할 때 필요함), 그것들은 `Tests` 키 안에 정의된 룰의 순서로 정해집니다. {% endhint %} {% tabs %} {% tab title="절대 타임스탬프를 사용하는 테스트" %} 만약 아래 테스트에서 열 번의 로그인 시도가 있고 그 뒤 성공적인 로그인이 이어진 다음 루트 로그인이 발생하면, 상관관계 룰이 `true`. 이 테스트는 절대 타임스탬프를 사용합니다—절대 타임스탬프 사용 방법에 대해 더 알아보기 [값을 구성하는 방법에 대해 자세히 알아보려면 여기](https://docs.panther.com/ko/detections/correlation-rule-reference#matchvalue-fields). {% code overflow="wrap" %} ```yaml Name: 타임스탬프가 있는 성공적인 로그인 ExpectedResult: true RuleOutputs: - ID: OktaLoginFailure Matches: client.ipAddress: # 원래 룰의 MinMatchCount가 10이므로 최소 10개의 타임스탬프가 필요합니다 123.123.123.123: ["2006-01-02T15:04:05Z", "2006-01-02T15:04:06Z","2006-01-02T15:04:07Z", "2006-01-02T15:04:08Z", "2006-01-02T15:04:09Z", "2006-01-02T15:04:10Z", "2006-01-02T15:04:11Z", "2006-01-02T15:04:12Z", "2006-01-02T15:04:13Z", "2006-01-02T15:04:14Z"] - ID: OktaLoginSuccess Matches: client.ipAddress: 123.123.123.123: ["2006-01-02T15:04:15Z"] - ID: RootLogin Matches: srcIpAddress7: 123.123.123.123: ["2006-01-02T15:04:16Z"] ``` {% endcode %} {% endtab %} {% tab title="상대 타임스탬프를 사용하는 테스트" %} 만약 아래 테스트에서 열 번의 로그인 시도가 있고 그 뒤 성공적인 로그인이 이어진 다음 루트 로그인이 발생하면, 상관관계 룰이 `true`. 이 테스트는 상대 타임스탬프를 사용합니다—상대 타임스탬프 사용 방법에 대해 더 알아보기 [값을 구성하는 방법에 대해 자세히 알아보려면 여기](https://docs.panther.com/ko/detections/correlation-rule-reference#matchvalue-fields). {% code overflow="wrap" %} ```yaml Name: 상대 분 단위 성공적인 로그인 ExpectedResult: true RuleOutputs: - ID: OktaLoginFailure Matches: client.ipAddress: # 원래 룰의 MinMatchCount가 10이므로 최소 10개의 타임스탬프가 필요합니다 123.123.123.123: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] - ID: OktaLoginSuccess Matches: client.ipAddress: 123.123.123.123: [11] - ID: RootLogin Matches: srcIpAddress7: 123.123.123.123: [12] ``` {% endcode %} {% endtab %} {% tab title="Test w/ExpectedResult: false" %} 이 테스트는 룰이 다음으로 평가되길 기대합니다. `false` 왜냐하면 *아홉* 번의 로그인 시도만 있고 그 뒤 성공적인 로그인이 이어지며, 10번이 아니기 때문입니다. ```yaml Name: 성공 전 9번의 로그인 실패 ExpectedResult: false RuleOutputs: - ID: OktaLoginFailure Matches: client.ipAddress: 123.123.123.123: [1, 2, 3, 4, 5, 6, 7, 8, 9] - ID: OktaLoginSuccess Matches: client.ipAddress: 123.123.123.123: [10] - ID: RootLogin Matches: srcIpAddress7: 123.123.123.123: [11] ``` {% endtab %} {% endtabs %} ## 상관관계 룰의 제한사항 * 시퀀스가 전환을 사용하면: * 허용되는 전환 수는 시퀀스 컬렉션에 포함된 룰 수보다 하나 적습니다. * 다음의 항목 순서는 `전환` 목록이 `Sequence` 필드의 룰 순서와 일치해야 합니다. * 이벤트 필드 일치를 사용하는 경우: * 이전 `Match.On`/`Match.From` 다음과 일치해야 합니다 `Match.On`/`Match.To` 값. * 둘 이상의 로그 유형, 예약 룰, 또는 상관 룰과 연결된 룰의 경우, 다음의 값은 `Match.On`/`Match.From`/`Match.To` 또는 `MatchCriteria.Match` 중 하나여야 합니다 `p_` 에 나열된 필드 [표준 필드](https://docs.panther.com/ko/search/panther-fields). * 상관 룰 전반에 걸쳐서는 한 가지 유형의 필드만 일치시킬 수 있습니다. 예를 들어, IP 주소만 일치시킬 수 있거나 이메일 주소만 일치시킬 수 있습니다. * 일치하지 않는 값에 대해 이벤트 필드 일치를 사용하는 것은 불가능합니다. 예를 들어, 상관 룰의 한 단계에서 나온 IP 주소가 다음 단계의 IP 주소와 일치하지 않는데도 상관 룰이 통과하도록 하는 것은 불가능합니다. ## 상관 룰을 만드는 방법 Panther Console 또는 로컬에서 상관 룰을 작성할 수 있습니다. 상관 룰을 구성하는 데 사용되는 YAML 키에 대한 설명은 다음을 참조하세요. [상관관계 룰 참조](https://docs.panther.com/ko/detections/correlation-rules/correlation-rule-reference). 사용자 지정 상관 룰을 만드는 것 외에도 다음도 활용할 수 있습니다 [Panther 관리 상관관계 룰](https://github.com/panther-labs/panther-analysis/tree/main/correlation_rules), 다음 위치에서 제공됩니다 `correlation_rules` 디렉터리의 `panther-analysis` 저장소. ### Console에서 흐름도 시각화 도구 사용하기 상관 룰을 작업하는 동안 Panther Console의 흐름도 시각화 도구를 사용할 수 있습니다. 이는 YAML로 상관 룰을 구성하는 동안 이를 시각적으로 렌더링하며, UI는 룰에 대한 즉각적인 유효성 검사 피드백을 제공합니다.
To the left of the YAML representation of a Correlation Rule called "Okta Brute Force Login into AWS Root Login," is the graphical, visual builder representation. Each of the three rules in the Sequence has its own rectangle in the builder.
### Console에서 YAML로 상관 룰 만들기 Panther Console에서 상관 룰을 만들려면, 목록 보기에서 디텍션을 선택하여 YAML을 생성하거나 YAML을 직접 구성할 수 있습니다. {% tabs %} {% tab title="룰 선택 및 YAML 생성" %} 1. Panther Console의 왼쪽 탐색 모음에서 **디텍션**. 2. 디텍션 목록에서 상관 룰에 포함하려는 각 디텍션의 왼쪽에 있는 체크박스를 클릭하세요. * 디텍션을 클릭하는 순서가 생성되는 [시퀀스](#sequence-correlation-rules) 상관 룰의 순서가 됩니다. 3. 클릭하세요 **상관**.\ ![Four buttons are shown: Download, Delete, Enable, Disable, and Correlate.](https://2400888838-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LgdiSWdyJcXPahGi9Rs-2910905616%2Fuploads%2Fgit-blob-5e0001a3248a23a5a3a14300f14141d9a1fb0a9d%2FScreenshot%202024-06-25%20at%2011.35.27%20AM.png?alt=media) 4. 디텍션 생성 페이지에서 상관 룰 구성을 완료하세요: * **상관관계 룰의 각 단위 테스트에는**: 상관 룰에 대한 설명이 포함된 이름을 입력하세요. * **ID** (선택 사항)**:** 펜 아이콘을 클릭하고 상관 룰에 대한 고유 ID를 입력하세요. * 오른쪽 상단에서 **Enabled** 토글은 기본적으로 `ON` 으로 설정됩니다. 룰을 비활성화하려면 토글을 `OFF`. * 다음 아래에서 **YAML Editor** 탭: * 원하는 경우 생성된 상관 룰을 수정할 수 있습니다. 기본적으로 룰은 다음과 같습니다: * 하나의 [`Sequence`](https://docs.panther.com/ko/detections/correlation-rule-reference#detection-fields) 상관 룰의 순서가 됩니다. * 로 변경할 수 있습니다 [`그룹`](https://docs.panther.com/ko/detections/correlation-rule-reference#detection-fields) 을 클릭하여 **룰을 그룹으로 구성**.\ ![A "YAML Editor" is selected, and an "Organize Rules as Group" button is circled.](https://2400888838-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LgdiSWdyJcXPahGi9Rs-2910905616%2Fuploads%2Fgit-blob-d0a458ac3437694910d3eafb8d5f1e372b1d43c3%2FScreenshot%202024-06-25%20at%2011.37.58%20AM.png?alt=media)\ 자세히 알아보기 [Console에서 시퀀스와 그룹 전환하기](#switching-between-sequence-and-group-in-the-console). * 설정합니다 [`MinMatchCount`](https://docs.panther.com/ko/detections/correlation-rule-reference#group-and-sequence-fields-rule-references) 로 설정), 상관관계 룰과 연관된 룰이 처리하는 로그의 소스에서 Panther로의 로그 전달이 최대 3시간 지연될 수 있다고 하면, `1` 상관 룰에 포함된 모든 룰과 예약 룰에 대해. * 내부에서 [`전환`](https://docs.panther.com/ko/detections/correlation-rule-reference#transitions-fields), 설정합니다 [`Match.On`](https://docs.panther.com/ko/detections/correlation-rule-reference#match-fields) 각 전환마다 `p_any_usernames`. * 다음을 업데이트할 수 있습니다 `Match.On` 값을, 또는 대신 다음을 사용할 수 있습니다 [`Match.To`](https://docs.panther.com/ko/detections/correlation-rule-reference#match-fields) 및 [`Match.From`](https://docs.panther.com/ko/detections/correlation-rule-reference#match-fields). * 설정합니다 [`Schedule.RateMinutes`](https://docs.panther.com/ko/detections/correlation-rule-reference#schedule-fields) 로 설정), 상관관계 룰과 연관된 룰이 처리하는 로그의 소스에서 Panther로의 로그 전달이 최대 3시간 지연될 수 있다고 하면, `15` 및 [`Schedule.TimeoutMinutes`](https://docs.panther.com/ko/detections/correlation-rule-reference#schedule-fields) 로 설정), 상관관계 룰과 연관된 룰이 처리하는 로그의 소스에서 Panther로의 로그 전달이 최대 3시간 지연될 수 있다고 하면, `2`. * 설정합니다 [`LookbackWindowMinutes`](https://docs.panther.com/ko/detections/correlation-rule-reference#detection-fields) 로 설정), 상관관계 룰과 연관된 룰이 처리하는 로그의 소스에서 Panther로의 로그 전달이 최대 3시간 지연될 수 있다고 하면, `60`. * 상관 디텍션 YAML 구문에 대한 자세한 정보는 다음에서 확인할 수 있습니다 [상관관계 룰 참조](https://docs.panther.com/ko/detections/correlation-rules/correlation-rule-reference), 필수 및 선택 필드의 전체 목록을 포함합니다. * 다음 아래에서 **알러트 설정** 탭: * 다음 내부의 **기본** 탭에서 다음 필드를 구성하세요: * **알러트 생성**: 이 `ON/OFF` 토글은 일치가 발생했을 때 [알러트](https://docs.panther.com/ko/alerts) 를 생성할지, 아니면 단지 [신호](https://docs.panther.com/ko/detections/signals). * 만 생성할지를 나타냅니다 (다음 경우에만 적용됨 **알러트 생성** 가 다음으로 설정된 경우 `ON`) **심각도:** 선택하세요 [심각도 수준](#alert-severity) 이 디텍션에 의해 트리거되는 알러트에 대해. * 만 생성할지를 나타냅니다 (다음 경우에만 적용됨 **알러트 생성** 가 다음으로 설정된 경우 `ON`) **대상 재정의:** 선택적으로 심각도와 관계없이 이 디텍션의 알러트를 받을 대상을 선택하세요.
* 만 생성할지를 나타냅니다 (다음 경우에만 적용됨 **알러트 생성** 가 다음으로 설정된 경우 `ON`) 다음 내부의 **컨텍스트** 하위 탭에서 다음 필드에 대해 선택적으로 값을 제공하세요: * **설명**: 룰에 대한 추가 컨텍스트를 입력하세요. * **런북**: 이 룰과 관련된 절차와 작업을 입력하세요. * 자세히 알아보기 [알러트 런북](https://docs.panther.com/ko/alerts/alert-runbooks). * 설명적인 런북을 제공하는 것이 권장됩니다. 왜냐하면 [Panther AI 알러트 분류](https://docs.panther.com/ko/alerts#ai-alert-triage) 가 이를 고려하기 때문입니다. * **참조**: 이 룰과 관련된 자세한 정보를 위한 외부 링크를 입력하세요. * **요약 속성**: 이 디텍션에 의해 트리거되는 알러트에서 보여줄 속성을 입력하세요. * 중첩 필드를 요약 속성으로 사용하려면 Summary Attribute 필드에서 Snowflake 점 표기법을 사용하여 JSON 객체의 경로를 탐색하세요: `:..` 그러면 알러트에서 참조된 객체에 대한 알러트 요약이 생성됩니다. [Snowflake에서 반정형 데이터를 탐색하는 방법에 대해 자세히 알아보세요.](https://docs.snowflake.com/en/user-guide/querying-semistructured.html#label-traversing-semistructured-data) * 알러트 요약에 대한 자세한 내용은 다음을 참조하세요 [알러트 지정 및 관리](https://docs.panther.com/ko/alerts/alert-management). * **태그**: 룰을 한눈에 이해하는 데 도움이 되는 사용자 지정 태그를 입력하세요(예: `HIPAA`.) * 다음 내부의 **프레임워크 매핑** 섹션: 1. 클릭하세요 **새로 추가** 를 눌러 보고서를 입력하세요. 2. 다음 필드의 값을 제공하세요: * **보고서 키**: 보고서와 관련된 키를 입력하세요. * **보고서 값**: 해당 보고서의 값을 입력하세요. * 다음 아래에서 **단위 테스트** 탭에서 선택적으로 테스트를 추가하세요: 1. 클릭하세요 **+ 새 단위 테스트 추가**. * 이 상관 룰에 대한 테스트용 기본 코드가 채워집니다. 2. 채워진 텍스트를 필요한 대로 조정하고, 다음의 내용을 포함하여 테스트의 나머지 부분을 채우세요 `일치`. 3. 코드 편집기 아래에서 **테스트 실행** 을 클릭하여 테스트를 평가하세요.\ ![](https://2400888838-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LgdiSWdyJcXPahGi9Rs-2910905616%2Fuploads%2Fgit-blob-71bea7b107432af6f0d7bd86dc489aacd328fcc6%2Funitteststab.png?alt=media) 5. 오른쪽 상단에서 **배포**. {% endtab %} {% tab title="처음부터 YAML 작성" %} 1. Panther Console의 왼쪽 탐색 모음에서 **빌드** > **디텍션**. 2. 클릭하세요 **새로 만들기**. 3. 다음에서 **상관 룰** 타일에서 **시작**. 4. 디텍션 생성 페이지에서 다음 필드를 채우세요: * **상관관계 룰의 각 단위 테스트에는**: 상관 룰에 대한 설명이 포함된 이름을 입력하세요. * **ID** (선택 사항)**:** 펜 아이콘을 클릭하고 상관 룰에 대한 고유 ID를 입력하세요. * 오른쪽 상단에서 **Enabled** 토글은 기본적으로 `ON` 으로 설정됩니다. 룰을 비활성화하려면 토글을 `OFF`. * 다음 아래에서 **YAML Editor** 탭에서 상관 룰을 정의하세요. * 기본적으로 상관 룰은 다음으로 구성됩니다 [`Sequence`](https://docs.panther.com/ko/detections/correlation-rule-reference#detection-fields). 이를 다음으로 변경할 수 있습니다 [`그룹`](https://docs.panther.com/ko/detections/correlation-rule-reference#detection-fields) 을 클릭하여 **룰을 그룹으로 구성**.\ ![A "YAML Editor" is selected, and an "Organize Rules as Group" button is circled.](https://2400888838-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LgdiSWdyJcXPahGi9Rs-2910905616%2Fuploads%2Fgit-blob-d0a458ac3437694910d3eafb8d5f1e372b1d43c3%2FScreenshot%202024-06-25%20at%2011.37.58%20AM.png?alt=media)\ 자세히 알아보기 [Console에서 시퀀스와 그룹 전환하기](#switching-between-sequence-and-group-in-the-console). * 상관 디텍션 YAML 구문에 대한 자세한 정보는 다음에서 확인할 수 있습니다 [상관관계 룰 참조](https://docs.panther.com/ko/detections/correlation-rules/correlation-rule-reference), 필수 및 선택 필드의 전체 목록을 포함합니다. * 다음 아래에서 **알러트 설정** 탭: * 다음 내부의 **기본** 탭에서 다음 필드를 구성하세요: * **알러트 생성**: 이 `ON/OFF` 토글은 일치가 발생했을 때 [알러트](https://docs.panther.com/ko/alerts) 를 생성할지, 아니면 단지 [신호](https://docs.panther.com/ko/detections/signals). * 만 생성할지를 나타냅니다 (다음 경우에만 적용됨 **알러트 생성** 가 다음으로 설정된 경우 `ON`) **심각도:** 선택하세요 [심각도 수준](#alert-severity) 이 디텍션에 의해 트리거되는 알러트에 대해. * 만 생성할지를 나타냅니다 (다음 경우에만 적용됨 **알러트 생성** 가 다음으로 설정된 경우 `ON`) **대상 재정의:** 선택적으로 심각도와 관계없이 이 디텍션의 알러트를 받을 대상을 선택하세요.
* 만 생성할지를 나타냅니다 (다음 경우에만 적용됨 **알러트 생성** 가 다음으로 설정된 경우 `ON`) 다음 내부의 **컨텍스트** 하위 탭에서 다음 필드에 대해 선택적으로 값을 제공하세요: * **설명**: 룰에 대한 추가 컨텍스트를 입력하세요. * **런북**: 이 룰과 관련된 절차와 작업을 입력하세요. * 자세히 알아보기 [알러트 런북](https://docs.panther.com/ko/alerts/alert-runbooks). * 설명적인 런북을 제공하는 것이 권장됩니다. 왜냐하면 [Panther AI 알러트 분류](https://docs.panther.com/ko/alerts#ai-alert-triage) 가 이를 고려하기 때문입니다. * **참조**: 이 룰과 관련된 자세한 정보를 위한 외부 링크를 입력하세요. * **요약 속성**: 이 디텍션에 의해 트리거되는 알러트에서 보여줄 속성을 입력하세요. * 중첩 필드를 요약 속성으로 사용하려면 Summary Attribute 필드에서 Snowflake 점 표기법을 사용하여 JSON 객체의 경로를 탐색하세요: `:..` 그러면 알러트에서 참조된 객체에 대한 알러트 요약이 생성됩니다. [Snowflake에서 반정형 데이터를 탐색하는 방법에 대해 자세히 알아보세요.](https://docs.snowflake.com/en/user-guide/querying-semistructured.html#label-traversing-semistructured-data) * 알러트 요약에 대한 자세한 내용은 다음을 참조하세요 [알러트 지정 및 관리](https://docs.panther.com/ko/alerts/alert-management). * **태그**: 룰을 한눈에 이해하는 데 도움이 되는 사용자 지정 태그를 입력하세요(예: `HIPAA`.) * 다음 내부의 **프레임워크 매핑** 섹션: 1. 클릭하세요 **새로 추가** 를 눌러 보고서를 입력하세요. 2. 다음 필드의 값을 제공하세요: * **보고서 키**: 보고서와 관련된 키를 입력하세요. * **보고서 값**: 해당 보고서의 값을 입력하세요. * 다음 아래에서 **단위 테스트** 탭에서 선택적으로 테스트를 추가하세요: 1. 클릭하세요 **+ 새 단위 테스트 추가**. * 이 상관 룰에 대한 테스트용 기본 코드가 채워집니다. 2. 채워진 텍스트를 필요한 대로 조정하고, 다음의 내용을 포함하여 테스트의 나머지 부분을 채우세요 `일치`. 3. 코드 편집기 아래에서 **테스트 실행** 을 클릭하여 테스트를 평가하세요.\ ![](https://2400888838-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LgdiSWdyJcXPahGi9Rs-2910905616%2Fuploads%2Fgit-blob-71bea7b107432af6f0d7bd86dc489aacd328fcc6%2Funitteststab.png?alt=media) 5. 오른쪽 상단에서 **배포**. {% endtab %} {% endtabs %} #### Console에서 시퀀스와 그룹 전환하기 상관 룰을 시퀀스에서 그룹으로, 그리고 그 반대로 전환할 수 있으며, 다음을 사용합니다 **룰을 그룹/시퀀스로 구성** 버튼은 우측 상단에 있는 **YAML Editor** 패널. 상관 룰이 이미 시퀀스 상태에서 **룰을 그룹으로 구성**: * 개별 룰 또는 예약된 룰의 `Sequence` 키는 다음으로 변경됩니다 `그룹`. * 개별 룰 또는 예약된 룰의 `전환` 섹션이 제거됩니다. * 하나의 `MatchCriteria` 섹션이 추가됩니다. * 이전에 편집한 `MatchCriteria` 섹션이 있다면, 해당 버전이 추가됩니다. 그렇지 않으면 기본 `MatchCriteria` 섹션이 제공됩니다. 상관 룰이 이미 그룹 상태에서 **룰을 시퀀스로 구성**: * 개별 룰 또는 예약된 룰의 `그룹` 키는 다음으로 변경됩니다 `Sequence`. * 개별 룰 또는 예약된 룰의 `MatchCriteria` 섹션이 제거됩니다. * 하나의 `전환` 섹션이 추가됩니다. * 이전에 편집한 `전환` 섹션이 있다면, 해당 버전이 추가됩니다. 그렇지 않으면 기본 `전환` 섹션이 제공됩니다. ### CLI 워크플로우에서 YAML로 상관 룰 만들기
지침 펼치기 Panther Console 대신 로컬에서 Correlations 디텍션을 작성하는 경우, GitHub 또는 GitLab 같은 버전 관리 시스템에서 로컬 디텍션 파일을 관리하는 것을 권장합니다. **폴더 설정** 상관 룰을 폴더로 그룹화하는 경우, 각 폴더 이름에는 다음이 포함되어야 합니다 `룰` 업로드 중에 찾을 수 있도록 하기 위해서입니다(PAT 또는 Console의 대량 업로더 사용). **파일 설정** 각 상관 룰은 다음으로 구성됩니다: * YAML 명세 파일(다음 확장자를 가진 파일 `.yml` 디텍션 로직과 디텍션의 메타데이터 속성을 포함하는 파일). 상관 디텍션 YAML 구문에 대한 자세한 정보는 다음에서 확인할 수 있습니다 [상관관계 룰 참조](https://docs.panther.com/ko/detections/correlation-rules/correlation-rule-reference), 필수 및 선택 필드의 전체 목록을 포함합니다. * YAML 파일을 만드세요(예: `my_new_correlation_rule.yml`) 아래 템플릿을 사용하여(상위 수준의 `디텍션` 키를 포함): ```yaml AnalysisType: correlation_rule DisplayName: 사양 형식 확인용 예시 상관 룰 Enabled: true RuleID: Correlation.Type.Behavior.MoreContext Severity: High Reports: ReportName(예: CIS, MITRE ATT&CK): - 이 상관 룰과 관련된 특정 보고서 섹션 Tags: - 태그 - 가세요 - 여기 Description: > 이 상관 룰은 Panther CLI의 CLI 워크플로우를 검증하기 위해 존재합니다 Runbook: > 먼저, 이 사양 형식을 작성한 사람이 누구인지 확인한 다음, 피드백과 함께 그에게 알리세요. Reference: https://www.a-clickable-link-to-more-info.com 디택션: - 시퀀스: - ID: Failed Login RuleID: Okta.Login.Fail MinMatchCount: 7 - ID: Successful Login RuleID: Okta.Login.Success MinMatchCount: 1 LookbackWindowMinutes: 15 일정: RateMinutes: 5 TimeoutMinutes: 3 Tests: - Name: 일치가 없으면 룰은 false를 반환해야 함 ExpectedResult: false RuleOutputs: - ID: Failed Login Matches: {} # 빈 매핑은 일치가 없음을 의미합니다 ``` 이 룰이 Panther에 업로드되면 Console에서 볼 수 있습니다.
## 상관 룰 전체 예시 ### 유출된 GitHub 자격 증명 발견 이 `Discovering.Exfiltrated.Credentials` 상관 룰은 10분마다 확인하여 다음이 있었는지 봅니다 [신호](https://docs.panther.com/ko/detections/signals) 에 대한 `AWS.CloudTrail.IaaS` 룰(아래 두 번째 탭에 정의됨) *찾아지지 않아야 하는* 그 다음에 신호가 이어지는지 여부를 `GitHub.CICD` 룰(아래 세 번째 탭에 정의됨)이 지난 10분 내에 있었는지 확인합니다.
{% tabs %} {% tab title="유출된 자격 증명 발견" %} ```yaml AnalysisType: correlation_rule RuleID: 'Discovering.Exfiltrated.Credentials' DisplayName: 'Discovering.Exfiltrated.Credentials' Enabled: true Severity: High Description: > 최소 한 번의 IaaS 활동 일치가 뒤따르지 않았습니다 10분 이내의 CI/CD 활동으로. 디택션: - 시퀀스: - ID: IaaS 활동 RuleID: AWS.CloudTrail.IaaS - ID: CICD 활동 RuleID: Github.CICD Absence: true 전환: - From: IaaS 활동 - To: CICD 활동 WithinTimeFrameMinutes: 10 일정: RateMinutes: 10 TimeoutMinutes: 3 Tests: - Name: CICD 활동이 없는 IaaS 활동 ExpectedResult: true RuleOutputs: - ID: IaaS 활동 Matches: username: my_username: [1] - Name: CICD 활동이 있는 IaaS 활동 ExpectedResult: false RuleOutputs: - ID: IaaS 활동 Matches: username: my_username: [1] - ID: CICD 활동 Matches: username: my_username: [2] ``` {% endtab %} {% tab title="AWS.CloudTrail.IaaS" %} ```yaml AnalysisType: rule RuleID: 'AWS.CloudTrail.IaaS' DisplayName: 'AWS CloudTrail IaaS' Enabled: true LogTypes: - AWS.CloudTrail Severity: Info CreateAlert: false 디택션: - KeyPath: userIdentity.arn Condition: IsIn Values: - DeploymentUpdateGitHubRole - KeyPath: eventName Condition: IsIn Values: - StartSession - ListResources - UpdateResource - DescribeResource - WriteLog ``` {% endtab %} {% tab title="GitHub.CICD" %} ```yaml AnalysisType: rule RuleID: 'GitHub.CICD' DisplayName: 'GitHub CICD' Enabled: true LogTypes: - GitHub.Audit Severity: Info CreateAlert: false 디택션: - KeyPath: repository Condition: Equals Value: panther-labs/example-repo - KeyPath: action Condition: Equals Value: workflows.created_workflow_run - KeyPath: name Condition: Equals Value: CI ``` {% endtab %} {% endtabs %} ### AWS 루트 로그인으로의 Okta 로그인 무차별 대입 이 `Brute.Force.Login` 상관 룰은 30분마다 확인하여 다음이 있었는지 봅니다 [신호](https://docs.panther.com/ko/detections/signals) 에 대한 [`Standard.BruteForceByIP`](https://github.com/panther-labs/panther-analysis/blob/main/rules/standard_rules/brute_force_by_ip.py) 룰 다음에 신호가 이어지는지 `Okta.Login.Success` 룰(아래 두 번째 탭에 정의됨) 다음에 신호가 이어지는지 [`AWS.Console.RootLogin`](https://github.com/panther-labs/panther-analysis/blob/main/rules/aws_cloudtrail_rules/aws_console_root_login.py) 룰, 추가적인 시간 범위 및 이벤트 IP 값 일치 요구 사항과 함께.
{% tabs %} {% tab title="무차별 대입 로그인" %} ```yaml AnalysisType: correlation_rule RuleID: 'Brute.Force.Login' DisplayName: 'Brute.Force.Login' Enabled: true Severity: High Description: > 적어도 100번의 실패한 로그인 후 성공한 로그인 마지막 실패한 로그인 후 10분 이내에 발생한 그리고 그 다음 AWS 콘솔에서의 루트 로그인. 디택션: - 시퀀스: - ID: Failed Login RuleID: Standard.BruteForceByIP MinMatchCount: 100 - ID: Successful Login RuleID: Okta.Login.Success MinMatchCount: 1 - ID: Root Login RuleID: AWS.Console.RootLogin MinMatchCount: 1 전환: - ID: Brute Force Login Success From: Failed Login To: Successful Login WithinTimeFrameMinutes: 10 Match: - From: p_alert_context.ip - To: client.ipAddress - ID: Gained Root Access From: Successful Login To: Root Login Match: - From: client.ipAddress To: p_alert_context.sourceIPAddress LookbackWindowMinutes: 60 EventEvaluationOrder: Chronological 일정: RateMinutes: 30 TimeoutMinutes: 3 Tests: # 이 상관 룰에 대한 추가 테스트는 위의 "단위 테스트 예시"를 참조하세요 - Name: 상대 분 단위의 성공적인 로그인 ExpectedResult: true RuleOutputs: - ID: Failed Login Matches: client.ipAddress: # 원래 룰의 MinMatchCount가 10이므로 최소 10개의 타임스탬프가 필요합니다 123.123.123.123: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] - ID: Successful Login Matches: client.ipAddress: 123.123.123.123: [11] - ID: Root Login Matches: srcIpAddress7: 123.123.123.123: [12] ``` {% endtab %} {% tab title="Okta.Login.Success" %} ```yaml AnalysisType: rule RuleID: 'Okta.Login.Success' DisplayName: 'Okta Login Success' Enabled: true LogTypes: - Okta.SystemLog Severity: Info CreateAlert: false 디택션: - DeepKey: - outcome - result Condition: Equals Value: SUCCESS - Key: eventType Condition: Equals Value: user.session.start ``` {% endtab %} {% endtabs %} ### 후속 보관 없이 GitHub 저장소 보안 정책 비활성화 이 `Github.Repo.Security.Policy.Disabled.Without.Archival` 상관 룰은 10분마다 확인하여 다음이 있었는지 봅니다 [신호](https://docs.panther.com/ko/detections/signals) 에 대한 [`GitHub.Advanced.Security.Change` ](https://github.com/panther-labs/panther-analysis/blob/main/rules/github_rules/github_advanced_security_change.py)룰 *찾아지지 않아야 하는* 그 다음에 신호가 이어지는지 여부를 `GitHub.Repo.Archived` 룰(아래 두 번째 탭에 정의됨)이며, 다음에 대한 일치하는 값도 있습니다 `p_alert_context.repo` 지난 10분 내의 이벤트 필드.
{% tabs %} {% tab title="Github.Repo.Security.Policy.Disabled.Without.Archival" %} ```yaml AnalysisType: correlation_rule RuleID: 'Github.Repo.Security.Policy.Disabled.Without.Archival' DisplayName: 'Github Repo Security Policy Disabled Without Archival' Enabled: true Tags: - Github - Repo Archived Severity: High 디택션: - 시퀀스: - ID: GitHub Advanced Security Change RuleID: GitHub.Advanced.Security.Change - ID: Github Repo Archived RuleID: Github.Repo.Archived Absence: true 전환: - ID: TR1 - From: GitHub Advanced Security Change - To: Github Repo Archived WithinTimeFrameMinutes: 10 Match: - On: p_alert_context.repo 일정: RateMinutes: 10 TimeoutMinutes: 3 Tests: - Name: Github Repo Security Policy Disabled Without Archival ExpectedResult: true RuleOutputs: - ID: GitHub Advanced Security Change Matches: p_alert_context.repo: my_production_repo: [1] - Name: Github Repo Security Policy Disabled With Archival ExpectedResult: false RuleOutputs: - ID: GitHub Advanced Security Change Matches: p_alert_context.repo: my_production_repo: [1] - ID: Github Repo Archived Matches: p_alert_context.repo: my_production_repo: [2] ``` {% endtab %} {% tab title="GitHub.Repo.Archived" %} ```yaml AnalysisType: rule RuleID: 'GitHub.Repo.Archived' DisplayName: 'GitHub Repo Archived' Enabled: true LogTypes: - GitHub.Audit Severity: Info CreateAlert: false AlertContext: - KeyName: repo KeyValue: KeyPath: repo 디택션: - KeyPath: action Condition: Equals Value: repo.archived ``` {% endtab %} {% endtabs %} ## 상관관계 룰을 더 효율적으로 만드는 방법 상관 룰은 복잡한 패턴 인식을 사용하므로 계산 비용이 많이 들 수 있습니다. 상관 룰과 관련된 Snowflake 비용을 줄이려면 다음 지침을 염두에 두세요. ### **상관 룰 실행 빈도를 가능한 한 낮게 유지하세요** 상관 룰이 실행되는 빈도(즉, 해당 `Schedule` 값으로 결정됨)는 비용에 큰 영향을 줄 수 있습니다. 따라서 감지 요구 사항을 충족하는 한(자세한 구성 고려 사항은 다음을 참조하세요 [설정 `Schedule`, 위](#setting-schedule), 이 필드를 구성할 때의 고려 사항). 상관 룰의 실행 빈도와 비용의 관계를 생각할 때의 일반적인 지침은 다음과 같습니다. 상관 룰이 실행되는 간격을 두 배로 늘릴 때마다(예: 다음을 두 배로 늘려 `RateMinutes`), 생성되는 비용은 절반으로 줄어듭니다. ### **다음을 가능한 한 낮게 설정하세요 `LookbackWindowMinutes` 상관 룰이 실행되는 데이터 양은 주로 해당** 값에 의해 정의되며, 이 데이터 양은 상관 룰의 처리 시간과 그에 따른 비용의 주요 요인입니다. 상관 룰이 처리하는 데이터 양을 줄이기 위해 해당 `LookbackWindowMinutes` 값을 가능한 한 낮게 설정하는 것이 권장됩니다(감지 요구 사항을 충족하는 한—다음을 참조하세요 `LookbackWindowMinutes` ). [설정 `LookbackWindowMinutes`, 위](#setting-lookbackwindowminutes), 이 필드를 구성할 때의 고려 사항). 예를 들어, 두 개의 룰이 각각 10분 이내에 신호를 생성하는 시점을 식별하고 싶다고 해봅시다( `WithinTimeFrameMinutes`를 사용하여). 다음을 설정하는 것은 `LookbackWindowMinutes` 정확히 `10` 로는 권장되지 않지만, 다음과 같이 낮은 값을 안전하게 사용할 수 있습니다 `15`. ### **가능한 한 가장 낮은 카디널리티의 매치 필드를 선택하세요** 매치 필드 카디널리티는 상관 룰 비용과 양의 상관관계가 있습니다. 상관 룰이 이벤트 값 매칭을 사용하는 경우, 어떤 필드와 일치시킬지 선택할 때는 카디널리티가 낮은 필드를 사용하는 것이 권장됩니다. 매치 필드의 카디널리티는 다음을 포함한 몇 가지 요인의 영향을 받을 수 있습니다: * 필드가 가질 수 있는 가능한 값의 수 — 가능한 값이 많을수록 카디널리티가 높아집니다. * 예를 들어, `field_a` 가 세 가지 가능한 값 중 하나를 가질 수 있고(예: `"yellow"`, `"red"`. 이를 더 구체적으로 보면, 3시간의 수집 지연 때문에 Panther가 `"blue"`), 하지만 `field_b` 는 두 값 중 하나만 가질 수 있다면(예: `"purple"` 또는 `"green"`), `field_b` 는 다음보다 카디널리티가 낮습니다 `field_a`. * 필드의 데이터 유형 — 일반적으로 비스칼라 데이터 유형(즉, `array` 또는 `object`인 필드)은 스칼라 데이터 유형(즉, `string`, `boolean`. 이를 더 구체적으로 보면, 3시간의 수집 지연 때문에 Panther가 `number`). * 예를 들어, 로그 스키마가 이메일과 사용자 이름 둘 다를 `email` 및 `username` 필드를 `username` [indicator](https://docs.panther.com/ko/search/panther-fields#indicator-fields)로 지정한다면, 즉 `p_any_usernames` 필드가 이 둘을 모두 `array` (예: `p_any_usernames: ["Bob Smith", "bob.smith@example.com"]`)에 포함하게 된다면, 해당 `p_any_usernames` 필드는 `email` 필드보다 더 높은 카디널리티를 갖게 되며, 그 `string` 유형은 단일 값을 가집니다.