# 상관관계 룰 (베타)
## **개요**
{% hint style="info" %}
상관관계 룰은 Panther 버전 1.108부터 오픈 베타로 제공되며, 모든 고객에게 이용 가능합니다. 버그 보고와 기능 요청은 Panther 지원 팀에 공유해 주세요.
{% endhint %}
{% hint style="warning" %}
이 기능은 현재 다음과는 호환되지 않습니다. [Databricks 백엔드.](/ko/search/backend/databricks.md)
{% endhint %}
Panther에서 상관관계 룰을 사용하면 로그 유형 전반에 걸쳐 여러 작업을 추적할 수 있습니다. 상관관계 룰에서는 다음을 지정합니다. [그룹](#group-correlation-rules) 또는 특정 [시퀀스](#sequence-correlation-rules) 의 [시그널](/ko/detections/signals.md) 이 일정한 시간 창 내에 발생해야 일치로 간주되며, 그다음 시그널을 생성하고 선택적으로 [알러트](/ko/alerts.md).
또한 다음 항목의 *부재* 를 상관관계 룰 기준에 포함할 수 있습니다. 상관관계 룰의 일치는 룰 일치나 알러트가 아니라 시그널에 의해 결정되므로, 알러트가 비활성화된 [룰, 예약된 룰, 상관관계 룰을 포함할 수 있습니다.](/ko/detections/signals.md#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 키에 대해 더 알아보기 [상관관계 룰 참조](/ko/detections/correlation-rules/correlation-rule-reference.md). 또한 다음을 활용할 수도 있습니다. [Panther에서 관리하는 상관관계 룰](https://github.com/panther-labs/panther-analysis/tree/main/correlation_rules).
{% hint style="warning" %}
상관관계 룰을 사용하면 Snowflake 컴퓨팅 비용이 증가할 수 있습니다. 상관관계 룰을 더 비용 효율적으로 만드는 방법은 다음 가이드를 참조하세요. [상관관계 룰을 더 효율적으로 만들기](#making-correlation-rules-more-efficient)에서 토큰 회전에 대한 지침을 확인하세요.
{% endhint %}
## 상관관계 룰의 작동 방식
상관관계 룰은 YAML로 작성되며, 이전에 생성된 [룰](/ko/detections/rules.md), [예약된 룰](/ko/detections/rules.md)및/또는 상관관계 룰을 참조합니다. 각 상관관계 룰은 [일정에 따라 실행되며](#setting-schedule), 그리고 ["룩백 윈도우"를 정의합니다.](#setting-lookbackwindowminutes) 즉, 룰이 찾기 위해 과거에서 살펴봐야 하는 시간의 양을 의미합니다. [시그널](/ko/detections/signals.md) (또는 시그널의 부재).
상관관계 룰에는 다음과 같은 추가 기준을 적용할 수 있습니다.
* 특정 룰에 대해 찾을 시그널의 최소 개수 또는 최대
* 한 룰에서 다른 룰로 특정 이벤트 값이 일치해야 함(예: 모든 개별 룰의 시그널에 동일한 IP 주소가 포함되도록 요구)
* 다음 단계가 [시퀀스](#sequence-correlation-rules) 일정한 시간 내에 발생해야 함
### 상관관계 룰에서 일치가 발생하면 어떻게 되나요
상관관계 룰의 일치는 [시그널](/ko/detections/signals.md). 상관관계 룰에서 알러트가 활성화되어 있으면 룰 일치가 생성되며, 이는 상관관계 룰의 [중복 제거 구성](#deduplication-of-events). [시그널, 룰 일치, 알러트의 차이에 대해 더 알아보기](https://docs.panther.com/ko/detections/pages/28a2f0a91092222209c65334fa10beb60037d689#signals-vs.-rule-matches-vs.-alerts).
상관관계 룰에 대해 알러트가 생성될 때, 해당 상관관계 룰에서 참조하는 개별 룰, 예약된 룰, 상관관계 룰도 자체 알러트를 생성할 수도 있고 생성하지 않을 수도 있습니다. 이는 다음에 따라 달라집니다:
* 각 개별 룰, 예약된 룰, 상관관계 룰에 알러트가 활성화되어 있는지 여부
* The `임계값` 개별 룰 또는 예약된 룰의 값, 그리고 `MinMatchCount` 상관 룰의 값. 상관 룰이 알러트를 생성할 수는 있지만 이를 구성하는 룰들은 생성하지 못하는 한 가지 엣지 케이스는 개별 룰의 이벤트 임계값(다음으로 설정한 `임계값` 키)이 `MinMatchCount` 상관 룰의 값보다 높고, 실제 룰 일치 수가 그 중간쯤에 있는 경우입니다.
### 그룹 vs. 시퀀스
상관 룰에는 두 가지 유형이 있습니다: [그룹](#group-correlation-rules) 및 [시퀀스](#sequence-correlation-rules). 그룹 상관 룰과 시퀀스 상관 룰은 신호를 찾아야 하는 룰 집합을 정의합니다(또는 *찾지* 못함, 다음을 설정하여 `부재: true`).
그룹 상관 관계 룰은 모든 룰이 신호(또는 부재)를 생성한 경우, 신호가 발견된 순서와 관계없이 알러트를 생성합니다. 그러나 시퀀스 룰은 알러트를 생성하기 위해 신호(또는 부재)가 발견되어야 하는 특정한 순서를 정의합니다.
### 일정 및 조회 범위 창 설정
각 상관 관계 룰은 다음 두 가지를 모두 정의합니다:
* 일정: 다음에 의해 정의됨 [`Schedule`](/ko/detections/correlation-rules/correlation-rule-reference.md#schedule-fields) 필드(다음 중 하나를 사용함 `RateMinutes` 또는 `CronExpression`), 일정은 상관 관계 룰이 얼마나 자주 실행되어야 하는지를 나타냅니다.
* 룰백 윈도우: 다음에 의해 정의됨 `LookbackWindowMinutes` 필드, 룰백 윈도우는 상관 룰이 찾기 위해 과거로 몇 분을 살펴봐야 하는지를 지정합니다 [시그널](/ko/detections/signals.md) (또는 신호의 부재) 그룹 또는 시퀀스에 포함된 룰, 예약된 룰, 또는 상관 룰에 대해.
값을 설정할 때 `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) 자세한 정보는.
#### 신호가 룰백 윈도우 사이에서 분리되지 않도록 보장
필요한 신호가 여러 상관 룰 실행의 룩백 윈도우에 걸쳐 분할되어, 찾고 있는 항목의 발생을 놓치지 않도록 룩백 윈도우를 설정하는 것이 권장됩니다.
피해야 할 상황의 예
우리가 피하려고 하는 이 상황을 설명하기 위해, 다음의 단순화된 correlation 룰 구성을 살펴보세요:
```yaml
# 나쁜 예시; 복제하지 마세요
- 그룹:
- 룰ID: First.룰
- 룰ID: Second.룰
- 룰ID: Third.룰
일정:
RateMinutes: 60
LookbackWindowMinutes: 90
```
이 시나리오에서는 매시간 상관관계 룰이 이전 90분을 되돌아보며 다음 항목에 포함된 세 개의 룰에 대한 신호를 찾습니다. `그룹`. 각 룰이 아래 시간에 신호를 일치/생성했다고 가정해 봅시다:
* 신호 대상 `First.룰` 오후 12:58에 생성됨
* 신호 대상 `Second.룰` 1:05 PM에 생성됨
* 신호 대상 `Third.룰` 1:40 PM에 생성됨
상관 룰은 매시간 30분에 실행되도록 예약되어 있습니다. 다음 시간에 실행됩니다:
* 1:30 PM(12:00 PM까지 되돌아봄): 첫 번째와 두 번째 신호(12:58 및 1:05 PM)만 보므로 일치를 생성하지 않습니다.
* 2:30 PM(1:00 PM까지 되돌아봄): 두 번째와 세 번째 신호(1:05 및 1:40 PM)만 보며, 역시 일치를 생성하지 않습니다.
이 상관 룰의 작성자는 세 룰에 대한 모든 신호가 42분 이내(12:58와 1:40 PM 사이)에 생성되었다면 상관 룰이 일치했을 것이라고 예상했을 가능성이 큽니다. 그러나 상관 룰의 단일 실행에서 조회 범위 내에 필요한 세 신호가 모두 발견되지 않았기 때문에 일치는 생성되지 않았습니다.
상관 룰이 일치하는 데 필요한 신호가 서로 다른 실행으로 분리되지 않도록 하려면(즉, 동일한 조회 범위에 포함되도록 하려면), 먼저 첫 번째 신호와 마지막 신호가 시간상 얼마나 떨어져 있어야 같은 발생으로 간주되어 경고되어야 하는지 결정합니다. 편의상 이 값을 "최대 신호 시간 범위 분(minute)"이라고 부르겠습니다.
(이것은 다음과 혼동해서는 안 됩니다 [`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` 를 `60`로 설정하여) 상관 룰과 연결된 룰이 처리하는 로그의 원본에서 Panther로의 로그 전달이 최대 3시간까지 지연될 수 있다고 명시한다면, 다음과 같이 설정할 수 있습니다. `LookbackWindowMinutes` 를 `60 + 3*60`, 또는 `240`. 이를 더 설명하자면, 3시간 수집 지연 때문에 Panther가 `오전 9:01` 에 받은 데이터는 `p_event_time` 만큼 빨라서 `오전 6:01`. 상관 룰이 매시간 정시에 실행된다면 `오전 10:00`까지는 최소한 되돌아봐야 합니다. `오전 6:01`.
### 이벤트 중복 제거
상관 룰의 중복 제거 기간은 [`LookbackWindowMinutes`](/ko/detections/correlation-rules/correlation-rule-reference.md#detection-fields) 필드의 값입니다. 이는 동일한 `LookbackWindowMinutes` 시간 범위 내의 겹치는 상관 룰이 해당 상관 룰을 일치시키는 원인이 된 고유한 이벤트만 포함함을 의미합니다.
개별 룰에서 설정된 중복 제거와 상관 룰에서 참조되는 예약 룰의 중복 제거( `dedup()`, `DedupPeriodMinutes`, `임계값`또는 Console에서 설정됨)는 상관 룰에 적용되지 않습니다.
### 상관 룰 오류
상관관계 룰을 작업하는 동안 다음 오류 중 하나를 받을 수 있습니다:
* [Simple 디택션 오류 코드](/ko/detections/rules/writing-simple-detections/simple-detection-error-codes.md): 잘못된 구문을 사용하여 상관관계 룰을 구성했습니다
* [디택션 오류](/ko/alerts.md#overview): 상관관계 룰 실행에 실패했습니다
* [시스템 오류](/ko/system-configuration/notifications/system-errors.md): 상관관계 룰의 시간이 초과되었습니다(아마도 너무 큰 `LookbackWindowMinutes` 값 때문에)
## 그룹 상관관계 룰
그룹 상관관계 룰은 다음에 대한 룰 모음을 정의합니다 [시그널](/ko/detections/signals.md) (또는 신호의 부재)가 주어진 룩백 윈도우 내에서 발생해야 합니다. 신호는 어떤 순서로든 발생할 수 있습니다.
이벤트 모음이 특정 순서로 발생하도록 하려면 대신 [시퀀스 상관 룰](#sequence-correlation-rules) 을 사용하세요.
### MatchCriteria
그룹 상관 룰에서 `MatchCriteria` 키는 상관 룰이 통과하려면 값이 일치해야 하는 필드를 룰, 예약 룰, 상관 룰별로 정의합니다.
여러 로그 유형, 예약 룰 또는 상관 룰과 연결된 룰의 경우에는 [`p_` 필드](/ko/search/panther-fields.md) 만 매칭할 수 있습니다. (하나의 로그 유형에만 연결된 룰의 경우에는 어떤 필드와도 매칭할 수 있습니다.)
일치 기준이 정의되지 않은 경우, 특정 이벤트 필드 값이 일치해야 한다는 요구 사항이 없으므로 상관관계 룰은 덜 구체적입니다.
자세히 알아보기 `MatchCriteria` 에서 [상관관계 룰 참조](/ko/detections/correlation-rules/correlation-rule-reference.md#matchcriteria-fields).
### MinMatchCount
그룹 상관관계 룰에서, `MinMatchCount` 은(는) 개별 룰, 예약된 룰 또는 상관관계 룰(에서 정의됨)의 최소 개수를 지정하는 선택적 필드입니다. `그룹`이 일치하려면 이 상관관계 룰과 일치해야 합니다.
예를 들어, 내에 다섯 개의 룰을 나열하고 `그룹` 을(를) 추가한 다음 `MinMatchCount: 2`를 지정하면, 다섯 개의 룰 중 임의의 두 개가 신호를 생성할 때 상관관계 룰이 일치합니다.
`MinMatchCount` 다음에서 정의된 개별 규칙에도 사용할 수 있는 필드입니다 `그룹`. 함께 사용되는 두 필드를 모두 다음에서 확인하세요 [MinMatchCount를 사용한 그룹 예시](#group-with-minmatchcount)에서 토큰 회전에 대한 지침을 확인하세요.
### 그룹 예시
아래 예제는 다음 JSON 이벤트를 참조합니다:
예시 이벤트
이 샘플 이벤트에는 가독성을 위해 일부 필드만 포함되어 있습니다.
```json
[
{
"p_룰_id": "Standard.BruteForceByIP",
"event_type": "로그인 실패",
"p_event_time": "2023-12-08 10:27:03.496000000",
"p_알러트_context": {
"ip": "136.24.229.58",
"geolocation": "미국 캘리포니아주 샌프란시스코"
}
},
{
"p_룰_id": "Standard.BruteForceByIP",
"event_type": "로그인 실패",
"p_event_time": "2023-12-08 10:27:03.623000000",
"p_알러트_context": {
"ip": "136.24.229.58",
"geolocation": "미국 캘리포니아주 샌프란시스코"
}
},
{
"p_룰_id": "Standard.BruteForceByIP",
"event_type": "로그인 실패",
"p_event_time": "2023-12-08 10:27:03.861000000",
"p_알러트_context": {
"ip": "136.24.229.58",
"geolocation": "미국 캘리포니아주 샌프란시스코"
}
},
{
"p_룰_id": "Okta.Login.Success",
"event_type": "성공적인 로그인",
"p_event_time": "2023-12-08 10:27:54.317000000",
"p_알러트_context": {
"ip": "136.24.229.58",
"geolocation": "미국 캘리포니아주 샌프란시스코"
}
},
{
"p_룰_id": "AWS.Console.RootLogin",
"eventType": "AwsApiCall",
"p_event_time": "2023-12-08 10:30:13.274000000",
"p_알러트_context": {
"sourceIPAddress": "136.24.229.58"
}
}
]
```
{% tabs %}
{% tab title="MatchCriteria가 있는 그룹" %}
이 예에서는, `MatchCriteria` 다음과 같이 지정합니다. `IP` 필드가 4개의 모든 규칙에서 동일한 값을 포함해야 합니다.
```yaml
디택션:
- 그룹:
- ID: &failed_login 로그인 실패
RuleID: Standard.BruteForceByIP
MinMatchCount: 7
- ID: &successful_login 성공한 로그인
RuleID: Okta.Login.Success
- ID: &root_access 루트 액세스
RuleID: AWS.Console.RootLogin
- ID: &missing_crowdstrike 누락된 Crowdstrike
RuleID: Crowdstrike.디택션.passthrough
부재: true
MatchCriteria:
ip:
- GroupID: *failed_login
Match: p_알러트_context.ip
- 그룹ID: *successful_login
Match: p_알러트_context.ip
- 그룹ID: *root_access
일치: p_알러트_context.sourceIPAddress
- 그룹ID: *missing_crowdstrike
일치: p_any_ip_addresses
EventEvaluationOrder: 연대순
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.디택션.passthrough
부재: 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 %}
## 시퀀스 상관 룰
시퀀스 상관 룰은 다음에 대한 룰 모음을 정의합니다. [시그널](/ko/detections/signals.md) (또는 신호의 부재)가 주어진 조회 범위 내에서 특정한 순서로 발생해야 합니다.
시퀀스의 순서는 `Sequence` 키 내에 정의된 룰의 순서로 결정됩니다.
모든 룰에 신호(또는 부재)가 있기만 하면 되고 특정한 순서는 필요하지 않도록 상관 룰을 일치시키고 싶다면, [그룹 상관 룰](#group-correlation-rules) 을 사용하세요.
### 전이
시퀀스 내에서 선택적으로 전이를 정의할 수 있습니다. 전이는 시퀀스의 한 단계가 다음 단계로 이동하는 방식에 대한 추가 기준을 정의하며, 단계 사이에 경과할 수 있는 시간과 일치해야 하는 이벤트 필드도 포함합니다. `전이` 를 `WithinTimeFrameMinutes` 및/또는 `일치` 를 사용하면 상관 룰의 구체성이 높아집니다.
전이가 정의된 경우, `Sequence`에 포함된 룰 수보다 전이 수가 하나 적어야 합니다. 또한, `전이` 내 항목은 `Sequence` 목록과 동일한 순서여야 합니다.
현재 상관 룰당 일치시킬 수 있는 필드 유형은 하나만 가능합니다(예: *모든* IP 주소 필드 또는 *모든* 이메일 주소 필드). 여러 로그 유형, 예약 룰 또는 상관 룰과 연결된 룰의 경우, [`p_` 필드](/ko/search/panther-fields.md) 만 매칭할 수 있습니다. (하나의 로그 유형에만 연결된 룰의 경우에는 어떤 필드와도 매칭할 수 있습니다.)
전이에 대해 자세히 알아보려면 [상관관계 룰 참조](/ko/detections/correlation-rules/correlation-rule-reference.md#transitions-fields).
### 시퀀스 예시
아래 예제는 다음 JSON 이벤트를 참조합니다:
예시 이벤트
이 샘플 이벤트에는 가독성을 위해 일부 필드만 포함되어 있습니다.
```json
[
{
"p_룰_id": "Standard.BruteForceByIP",
"event_type": "로그인 실패",
"p_event_time": "2023-12-08 10:27:03.496000000",
"p_알러트_context": {
"ip": "136.24.229.58",
"geolocation": "미국 캘리포니아주 샌프란시스코"
}
},
{
"p_룰_id": "Standard.BruteForceByIP",
"event_type": "로그인 실패",
"p_event_time": "2023-12-08 10:27:03.623000000",
"p_알러트_context": {
"ip": "136.24.229.58",
"geolocation": "미국 캘리포니아주 샌프란시스코"
}
},
{
"p_룰_id": "Standard.BruteForceByIP",
"event_type": "로그인 실패",
"p_event_time": "2023-12-08 10:27:03.861000000",
"p_알러트_context": {
"ip": "136.24.229.58",
"geolocation": "미국 캘리포니아주 샌프란시스코"
}
},
{
"p_룰_id": "Okta.Login.Success",
"event_type": "성공적인 로그인",
"p_event_time": "2023-12-08 10:27:54.317000000",
"p_알러트_context": {
"ip": "136.24.229.58",
"geolocation": "미국 캘리포니아주 샌프란시스코"
}
},
{
"p_룰_id": "AWS.Console.RootLogin",
"eventType": "AwsApiCall",
"p_event_time": "2023-12-08 10:30:13.274000000",
"p_알러트_context": {
"sourceIPAddress": "136.24.229.58"
}
}
]
```
{% tabs %}
{% tab title="전이 및 일치가 포함된 시퀀스 " %}
을 사용하여 `전이` 를 `일치` 내에서 `Sequence` 값이 일치해야 하는 이벤트 필드를 정의하려는 경우 유용합니다.
```yaml
디택션:
- 시퀀스:
- ID: 실패한 로그인
RuleID: Standard.BruteForceByIP
MinMatchCount: 7
- ID: 성공한 로그인
RuleID: Okta.Login.Success
최소일치수: 1
- ID: 루트 로그인
RuleID: AWS.Console.RootLogin
최소일치수: 1
- ID: Crowdstrike 누락
RuleID: Crowdstrike.디택션.passthrough
부재: true
전이:
- ID: 무차별 대입 로그인 성공
From: 실패한 로그인
To: 성공한 로그인
WithinTimeFrameMinutes: 10
일치:
- On: client.ipAddress
- ID: 루트 접근 획득
From: 성공한 로그인
To: 루트 로그인
일치:
- From: client.ipAddress
To: p_알러트_context.sourceIPAddress
- ID: Crowdstrike 부재
From: 루트 로그인
대상: Crowdstrike 누락
일치:
- 출처: p_알러트_context.sourceIPAddress
대상: p_any_ip_addresses
LookbackWindowMinutes: 60
EventEvaluationOrder: 연대순
일정:
RateMinutes: 30
TimeoutMinutes: 3
```
{% endtab %}
{% tab title="전환이 있는 시퀀스 / 전환 없음 / 매치 없음" %}
을 사용하여 `전이` 내에서 `Sequence` 없이 `일치` 사용하면 두 단계가 시퀀스 내에서 발생해야 하는 시간 범위를 지정하기만 하면 될 때 유용합니다. `WithinTimeFrameMinutes`.
```yaml
디택션:
- 시퀀스:
- ID: 실패한 로그인
RuleID: Standard.BruteForceByIP
MinMatchCount: 7
- ID: 성공한 로그인
RuleID: Okta.Login.Success
- ID: 루트 로그인
RuleID: AWS.Console.RootLogin
- ID: Crowdstrike 누락
RuleID: Crowdstrike.디택션.passthrough
부재: true
전이:
- ID: 무차별 대입 로그인 성공
From: 실패한 로그인
To: 성공한 로그인
WithinTimeFrameMinutes: 10 # 시간 범위 정의
- ID: 루트 접근 획득
From: 성공한 로그인
To: 루트 로그인
- ID: Crowdstrike 부재
From: 루트 로그인
대상: 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.디택션.passthrough
부재: true
LookbackWindowMinutes: 60
일정:
RateMinutes: 30
TimeoutMinutes: 3
```
{% endtab %}
{% endtabs %}
## 상관 룰 테스트
특정 조건이 주어졌을 때 상관 룰에 대한 일치 항목이 생성되는지 평가하기 위해 상관 룰에 단위 테스트를 추가할 수 있습니다(잠재적으로 알러트를 생성함—참조 [상관관계 룰에서 일치가 발생하면 어떻게 되나요](#what-happens-when-there-is-a-match-on-a-correlation-rule)).
{% hint style="info" %}
상관 룰 테스트는 상관 로직만 테스트하기 위한 것입니다. 상관 룰을 구성하는 개별 룰의 룰 로직을 테스트하려면, 개별 룰 자체의 단위 테스트를 사용하세요.
{% endhint %}
단위 테스트는 다음 위치의 상관 룰에 정의됩니다 **단위 테스트** 탭(팬서 콘솔에서) 또는 최상위 `테스트` 필드(CLI 워크플로에서)에 정의되며, 다음과 유사한 구조를 가집니다 [룰 또는 정책에 대한 단위 테스트](/ko/detections/testing.md).
각 correlation 룰에 대한 각 단위 테스트에는 a가 포함되어야 합니다 `이름`, `기대 결과`, 그리고 `규칙 출력` 필드입니다. 단위를 테스트하기 위한 YAML 구조에 대해 자세히 알아보세요. 여기에는 구성하는 방법도 포함됩니다. `규칙 출력` 값 [여기, Correlation 룰 참조](/ko/detections/correlation-rules/correlation-rule-reference.md#tests-fields).
{% hint style="info" %}
상관 규칙에 대한 테스트를 작성한 후에는 다음을 사용하여 실행할 수 있습니다. [Panther Analysis Tool `테스트` 명령](/ko/panther/detections-repo/pat/pat-commands.md#test-running-unit-tests). 실행 중 `pat test` 상관관계 규칙에는 API 토큰이 필요합니다—참조 [API 토큰으로 인증하기](/ko/panther/detections-repo/pat/install-configure-and-authenticate-with-pat.md#authenticating-with-an-api-token) 자세한 정보는.
{% endhint %}
### 단위 테스트 예제
다음 상관 관계 룰 사용:
```yaml
- 시퀀스:
- ID: OktaLoginFailure
룰ID: Okta.Login.Failure
MinMatchCount: 10
- ID: OktaLoginSuccess
RuleID: Okta.Login.Success
최소일치수: 1
- ID: RootLogin
RuleID: AWS.Console.RootLogin
최소일치수: 1
전이:
- ID: Okta 무차별 대입 로그인
From: OktaLoginFailure
To: OktaLoginSuccess
WithinTimeFrameMinutes: 10
일치:
- On: client.ipAddress
- ID: AWS Root Login
From: OktaLoginSuccess
To: RootLogin
일치:
- From: client.ipAddress
To: srcIpAddress7
일정:
RateMinutes: 15
TimeoutMinutes: 2
LookbackWindowMinutes: 60
```
다음과 같은 테스트를 작성할 수 있습니다:
{% hint style="info" %}
아래 테스트가 룰의 YAML 파일에 포함되어 있다면(CLI 워크플로에서 탐지를 관리할 때 요구됨), 이 테스트는 다음 아래에 배치됩니다: `테스트` 키 내에 정의된 룰의 순서로 결정됩니다.
{% endhint %}
{% tabs %}
{% tab title="절대 타임스탬프를 사용하는 테스트" %}
열 번의 로그인 시도가 이어서 성공적인 로그인, 그 다음 루트 로그인이 발생하면, 상관관계 룰은 다음을 반환할 것으로 예상합니다 `true`. 이 테스트는 절대 타임스탬프를 사용합니다—절대 타임스탬프를 사용하는 방법에 대해 자세히 알아보세요 [여기, Correlation 룰 참조](/ko/detections/correlation-rules/correlation-rule-reference.md#matchvalue-fields).
{% code overflow="wrap" %}
```yaml
이름: 타임스탬프가 있는 성공적인 로그인
예상 결과: true
룰 출력:
- ID: OktaLoginFailure
일치 항목:
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
일치 항목:
client.ipAddress:
123.123.123.123: ["2006-01-02T15:04:15Z"]
- ID: RootLogin
일치 항목:
srcIpAddress7:
123.123.123.123: ["2006-01-02T15:04:16Z"]
```
{% endcode %}
{% endtab %}
{% tab title="상대 타임스탬프를 사용한 테스트" %}
열 번의 로그인 시도가 이어서 성공적인 로그인, 그 다음 루트 로그인이 발생하면, 상관관계 룰은 다음을 반환할 것으로 예상합니다 `true`. 이 테스트는 상대 타임스탬프를 사용합니다—상대 타임스탬프를 사용하는 방법에 대해 자세히 알아보세요 [여기, Correlation 룰 참조](/ko/detections/correlation-rules/correlation-rule-reference.md#matchvalue-fields).
{% code overflow="wrap" %}
```yaml
이름: 상대 분을 사용한 성공적인 로그인
예상 결과: true
룰 출력:
- ID: OktaLoginFailure
일치 항목:
client.ipAddress:
# 원래 룰의 MinMatchCount가 10이므로, 최소 10개의 타임스탬프가 필요합니다
123.123.123.123: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
- ID: OktaLoginSuccess
일치 항목:
client.ipAddress:
123.123.123.123: [11]
- ID: RootLogin
일치 항목:
srcIpAddress7:
123.123.123.123: [12]
```
{% endcode %}
{% endtab %}
{% tab title="예상 결과: false를 사용한 테스트" %}
이 테스트는 룰이 다음으로 평가되기를 기대합니다 `false` 왜냐하면 *아홉* 개의 로그인 시도가 성공적인 로그인으로 이어질 뿐, 10개가 아니기 때문입니다.
```yaml
이름: 성공 전에 아홉 번의 로그인 실패
예상 결과: false
룰 출력:
- ID: OktaLoginFailure
일치 항목:
client.ipAddress:
123.123.123.123: [1, 2, 3, 4, 5, 6, 7, 8, 9]
- ID: OktaLoginSuccess
일치 항목:
client.ipAddress:
123.123.123.123: [10]
- ID: RootLogin
일치 항목:
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_` 의 필드에 나열된 [표준 필드](/ko/search/panther-fields.md).
* 상관 룰 전체에서 하나의 유형의 필드만 일치시킬 수 있습니다. 예를 들어, IP 주소만 일치시킬 수 있거나 이메일 주소만 일치시킬 수 있습니다.
* 일치하지 않는 값에 대해 이벤트 필드 일치를 사용하는 것은 불가능합니다. 예를 들어, 상관 룰의 한 단계에 있는 IP 주소가 다음 단계의 IP 주소와 일치하지 않는 경우 상관 룰이 통과하도록 할 수 없습니다.
## 상관 룰을 만드는 방법
Panther Console 또는 로컬에서 상관 룰을 작성할 수 있습니다. 상관 룰을 구성하는 데 사용되는 YAML 키에 대한 설명은 [상관관계 룰 참조](/ko/detections/correlation-rules/correlation-rule-reference.md).
사용자 지정 상관 룰을 만드는 것 외에도, 다음도 활용할 수 있습니다 [Panther에서 관리하는 상관관계 룰](https://github.com/panther-labs/panther-analysis/tree/main/correlation_rules), 다음에서 제공됩니다 `correlation_rules` 디렉터리의 `panther-analysis` 저장소.
### Console에서 흐름도 시각화 도구 사용하기
상관 룰 작업 중 Panther Console의 흐름도 시각화 도구를 사용할 수 있습니다. 이는 YAML로 상관 룰을 구성하는 동안 룰을 시각적으로 렌더링하며, UI는 룰에 대한 즉각적인 유효성 검사 피드백을 제공합니다.
### 콘솔에서 YAML로 상관 룰 생성하기
Panther Console에서 상관 룰을 생성하려면, 목록 보기에서 디택션을 선택해 YAML을 생성하거나 직접 YAML을 작성할 수 있습니다.
{% tabs %}
{% tab title="룰을 선택하고 YAML 생성" %}
1. 왼쪽 탐색 모음에서 Panther Console의 **디택션**.
2. 디택션 목록에서 상관 룰에 포함할 각 디택션의 왼쪽에 있는 확인란을 클릭하세요.
* 디택션을 클릭한 순서가 생성된 [시퀀스](#sequence-correlation-rules) 상관 룰의 순서가 됩니다.
3. 클릭 **상관**.\
4. 디택션 생성 페이지에서 상관 룰 구성을 완료하세요:
* **이름**: 상관 룰에 대한 설명이 포함된 이름을 입력하세요.
* **ID** (선택 사항)**:** 펜 아이콘을 클릭하고 상관 룰에 사용할 고유한 ID를 입력하세요.
* 오른쪽 상단에서 **활성화** 토글은 기본적으로 `ON` 으로 설정됩니다. 룰을 비활성화하려면 토글을 `OFF`.
* 로 전환하세요. **YAML Editor** 탭 아래에서:
* 원하는 경우 생성된 상관 룰을 수정할 수 있습니다. 기본적으로 룰은 다음과 같습니다:
* 다음입니다: [`Sequence`](/ko/detections/correlation-rules/correlation-rule-reference.md#detection-fields) 상관 룰의 순서가 됩니다.
* 이것을 다음으로 변경할 수 있습니다 [`그룹`](/ko/detections/correlation-rules/correlation-rule-reference.md#detection-fields) 를 **룰을 그룹으로 정리**.\
\
자세히 알아보기: [콘솔에서 sequence와 group 간 전환](#switching-between-sequence-and-group-in-the-console).
* 다음을 설정합니다 [`MinMatchCount`](/ko/detections/correlation-rules/correlation-rule-reference.md#group-and-sequence-fields-rule-references) 를 `1` 상관 룰에 포함된 모든 룰 및 예약된 룰에 대해.
* 다음 내에서 [`전이`](/ko/detections/correlation-rules/correlation-rule-reference.md#transitions-fields), 다음을 설정합니다 [`Match.On`](/ko/detections/correlation-rules/correlation-rule-reference.md#match-fields) 각 전환에 대해 다음으로 `p_any_usernames`.
* 다음을 업데이트할 수 있습니다 `Match.On` 값을 사용하거나, 대신 다음을 사용할 수 있습니다 [`Match.To`](/ko/detections/correlation-rules/correlation-rule-reference.md#match-fields) 및 [`Match.From`](/ko/detections/correlation-rules/correlation-rule-reference.md#match-fields).
* 다음을 설정합니다 [`Schedule.RateMinutes`](/ko/detections/correlation-rules/correlation-rule-reference.md#schedule-fields) 를 `15` 및 [`Schedule.TimeoutMinutes`](/ko/detections/correlation-rules/correlation-rule-reference.md#schedule-fields) 를 `2`.
* 다음을 설정합니다 [`LookbackWindowMinutes`](/ko/detections/correlation-rules/correlation-rule-reference.md#detection-fields) 를 `60`.
* 상관 디택션 YAML 구문에 대한 자세한 정보는 다음에서 확인할 수 있습니다 [상관관계 룰 참조](/ko/detections/correlation-rules/correlation-rule-reference.md), 필요한 필드와 선택적 필드의 전체 목록을 포함합니다.
* 로 전환하세요. **알러트 설정** 탭 아래에서:
* 다음 내에서 **기본** 탭에서 다음 필드를 구성하세요:
* **알러트 생성**: 이 `ON/OFF` 토글은 일치 항목이 있을 때 알러트를 생성할지, 아니면 [알러트](/ko/alerts.md) 만 생성할지를 나타냅니다. [signal](/ko/detections/signals.md).
* (다음의 경우에만 적용됨 **알러트 생성** 가 `ON`) **심각도:** \&#xNAN; [심각도 수준](#alert-severity) 이 디택션으로 인해 트리거된 알러트에 대해.
* (다음의 경우에만 적용됨 **알러트 생성** 가 `ON`) **대상 오버라이드:** 심각도와 관계없이 이 디택션에 대한 알러트를 받을 대상을 선택할 수 있습니다.
* (다음의 경우에만 적용됨 **알러트 생성** 가 `ON`) 다음 **컨텍스트** 하위 탭에서 다음 필드에 대한 값을 선택적으로 제공합니다:
* **설명**: 룰에 대한 추가 컨텍스트를 입력합니다.
* **런북**: 이 룰과 관련된 절차 및 작업을 입력합니다.
* 자세히 알아보기: [알러트 런북](/ko/alerts/alert-runbooks.md).
* 설명적인 런북을 제공하는 것이 좋습니다. 왜냐하면 [Panther AI 알러트 분류](/ko/alerts.md#ai-alert-triage) 가 이를 고려하기 때문입니다.
* **참조**: 이 룰과 관련된 추가 정보를 위한 외부 링크를 입력합니다.
* **요약 속성**: 이 디택션으로 인해 트리거된 알러트에 표시할 속성을 입력합니다.
* 중첩 필드를 요약 속성으로 사용하려면, Summary Attribute 필드에서 Snowflake 점 표기법을 사용해 JSON 객체의 경로를 따라가세요:
`:..`
그러면 알러트 요약은 알러트에서 참조된 객체에 대해 생성됩니다. [Snowflake에서 반구조화 데이터 탐색에 대해 자세히 알아보려면 여기를 참조하세요.](https://docs.snowflake.com/en/user-guide/querying-semistructured.html#label-traversing-semistructured-data)
* 알러트 요약에 대한 자세한 내용은 다음을 참조하세요. [알러트 지정 및 관리](/ko/alerts/alert-management.md).
* **태그**: 룰을 한눈에 이해하는 데 도움이 되는 사용자 지정 태그를 입력합니다(예: `HIPAA`.)
* 에서 **프레임워크 매핑** 섹션:
1. 클릭 **새로 추가** 보고서를 입력하려면.
2. 다음 필드에 대한 값을 제공합니다:
* **보고서 키**: 보고서와 관련된 키를 입력합니다.
* **보고서 값**: 해당 보고서의 값을 입력합니다.
* 로 전환하세요. **단위 테스트** 탭에서, 선택적으로 테스트를 추가합니다:
1. 클릭 **+ 새 단위 테스트 추가**.
* 이 상관 관계 룰에 대한 테스트의 보일러플레이트 코드가 채워집니다.
2. 채워진 텍스트를 필요한 대로 조정하고, 테스트의 나머지를 채우세요. 여기에는 다음의 내용도 포함됩니다. `일치`.
3. 코드 편집기 아래에서 다음을 클릭하세요. **테스트 실행** 하여 테스트를 평가합니다.\
5. 를 클릭하세요. 오른쪽 상단에서 **배포**.
{% endtab %}
{% tab title="YAML을 처음부터 작성" %}
1. 왼쪽 탐색 모음에서 Panther Console의 **빌드** > **디택션**.
2. 클릭 **새로 만들기**.
3. 를 클릭할 수 있습니다. **상관 관계 룰** 타일의 **시작**.
4. 디택션 생성 페이지에서 다음 필드를 입력하세요:
* **이름**: 상관 룰에 대한 설명이 포함된 이름을 입력하세요.
* **ID** (선택 사항)**:** 펜 아이콘을 클릭하고 상관 룰에 사용할 고유한 ID를 입력하세요.
* 오른쪽 상단에서 **활성화** 토글은 기본적으로 `ON` 으로 설정됩니다. 룰을 비활성화하려면 토글을 `OFF`.
* 로 전환하세요. **YAML Editor** 탭에서 상관 관계 룰을 정의합니다.
* 기본적으로, 상관관계 룰은 다음과 같이 구성됩니다 [`Sequence`](/ko/detections/correlation-rules/correlation-rule-reference.md#detection-fields). 이를 다음으로 변경할 수 있습니다 [`그룹`](/ko/detections/correlation-rules/correlation-rule-reference.md#detection-fields) 를 **룰을 그룹으로 정리**.\
\
자세히 알아보기: [콘솔에서 sequence와 group 간 전환](#switching-between-sequence-and-group-in-the-console).
* 상관 디택션 YAML 구문에 대한 자세한 정보는 다음에서 확인할 수 있습니다 [상관관계 룰 참조](/ko/detections/correlation-rules/correlation-rule-reference.md), 필요한 필드와 선택적 필드의 전체 목록을 포함합니다.
* 로 전환하세요. **알러트 설정** 탭 아래에서:
* 다음 내에서 **기본** 탭에서 다음 필드를 구성하세요:
* **알러트 생성**: 이 `ON/OFF` 토글은 일치 항목이 있을 때 알러트를 생성할지, 아니면 [알러트](/ko/alerts.md) 만 생성할지를 나타냅니다. [signal](/ko/detections/signals.md).
* (다음의 경우에만 적용됨 **알러트 생성** 가 `ON`) **심각도:** \&#xNAN; [심각도 수준](#alert-severity) 이 디택션으로 인해 트리거된 알러트에 대해.
* (다음의 경우에만 적용됨 **알러트 생성** 가 `ON`) **대상 오버라이드:** 심각도와 관계없이 이 디택션에 대한 알러트를 받을 대상을 선택할 수 있습니다.
* (다음의 경우에만 적용됨 **알러트 생성** 가 `ON`) 다음 **컨텍스트** 하위 탭에서 다음 필드에 대한 값을 선택적으로 제공합니다:
* **설명**: 룰에 대한 추가 컨텍스트를 입력합니다.
* **런북**: 이 룰과 관련된 절차 및 작업을 입력합니다.
* 자세히 알아보기: [알러트 런북](/ko/alerts/alert-runbooks.md).
* 설명적인 런북을 제공하는 것이 좋습니다. 왜냐하면 [Panther AI 알러트 분류](/ko/alerts.md#ai-alert-triage) 가 이를 고려하기 때문입니다.
* **참조**: 이 룰과 관련된 추가 정보를 위한 외부 링크를 입력합니다.
* **요약 속성**: 이 디택션으로 인해 트리거된 알러트에 표시할 속성을 입력합니다.
* 중첩 필드를 요약 속성으로 사용하려면, Summary Attribute 필드에서 Snowflake 점 표기법을 사용해 JSON 객체의 경로를 따라가세요:
`:..`
그러면 알러트 요약은 알러트에서 참조된 객체에 대해 생성됩니다. [Snowflake에서 반구조화 데이터 탐색에 대해 자세히 알아보려면 여기를 참조하세요.](https://docs.snowflake.com/en/user-guide/querying-semistructured.html#label-traversing-semistructured-data)
* 알러트 요약에 대한 자세한 내용은 다음을 참조하세요. [알러트 지정 및 관리](/ko/alerts/alert-management.md).
* **태그**: 룰을 한눈에 이해하는 데 도움이 되는 사용자 지정 태그를 입력합니다(예: `HIPAA`.)
* 에서 **프레임워크 매핑** 섹션:
1. 클릭 **새로 추가** 보고서를 입력하려면.
2. 다음 필드에 대한 값을 제공합니다:
* **보고서 키**: 보고서와 관련된 키를 입력합니다.
* **보고서 값**: 해당 보고서의 값을 입력합니다.
* 로 전환하세요. **단위 테스트** 탭에서, 선택적으로 테스트를 추가합니다:
1. 클릭 **+ 새 단위 테스트 추가**.
* 이 상관 관계 룰에 대한 테스트의 보일러플레이트 코드가 채워집니다.
2. 채워진 텍스트를 필요한 대로 조정하고, 테스트의 나머지를 채우세요. 여기에는 다음의 내용도 포함됩니다. `일치`.
3. 코드 편집기 아래에서 다음을 클릭하세요. **테스트 실행** 하여 테스트를 평가합니다.\
5. 를 클릭하세요. 오른쪽 상단에서 **배포**.
{% endtab %}
{% endtabs %}
#### 콘솔에서 sequence와 group 간 전환
상관관계 룰을 시퀀스에서 그룹으로, 또는 그 반대로 전환할 수 있습니다. 이때 **룰을 그룹/시퀀스로 구성** 버튼을 **YAML Editor** 패널의 오른쪽 상단에서 사용합니다.
상관관계 룰이 이미 시퀀스인 상태에서 다음을 클릭하면 **룰을 그룹으로 정리**:
* The `Sequence` 키가 다음으로 변경됩니다 `그룹`.
* The `전이` 섹션이 제거됩니다.
* A `MatchCriteria` 섹션이 추가됩니다.
* 이전에 `MatchCriteria` 섹션을 편집한 적이 있다면 해당 버전이 추가됩니다. 그렇지 않으면 기본 `MatchCriteria` 섹션이 제공됩니다.
상관관계 룰이 이미 그룹인 상태에서 다음을 클릭하면 **룰을 시퀀스로 구성**:
* The `그룹` 키가 다음으로 변경됩니다 `Sequence`.
* The `MatchCriteria` 섹션이 제거됩니다.
* A `전이` 섹션이 추가됩니다.
* 이전에 `전이` 섹션을 편집한 적이 있다면 해당 버전이 추가됩니다. 그렇지 않으면 기본 `전이` 섹션이 제공됩니다.
### CLI 워크플로에서 YAML로 상관관계 룰 만들기
지침 펼치기
Correlations 디택션을 로컬에서 작성하는 경우(Panther Console에서 작성하는 대신), GitHub 또는 GitLab 같은 버전 관리 시스템에서 로컬 디택션 파일을 관리하는 것을 권장합니다.
**폴더 설정**
상관관계 룰을 폴더로 그룹화하는 경우, 각 폴더 이름에는 반드시 `룰` 이 포함되어 있어야 업로드 중(PAT 또는 Console의 대량 업로더 사용 시) 해당 항목을 찾을 수 있습니다.
**파일 설정**
각 상관관계 룰은 다음으로 구성됩니다:
* YAML 명세 파일(다음이 있는 파일 `.yml` 확장자)로, 디택션 로직과 디택션의 메타데이터 속성을 포함합니다.
상관 디택션 YAML 구문에 대한 자세한 정보는 다음에서 확인할 수 있습니다 [상관관계 룰 참조](/ko/detections/correlation-rules/correlation-rule-reference.md), 필요한 필드와 선택적 필드의 전체 목록을 포함합니다.
* 아래 템플릿을 사용하여 YAML 파일(예: `my_new_correlation_룰.yml`)을 생성하세요(최상위 `디택션` 키 포함):
```yaml
AnalysisType: correlation_룰
DisplayName: 명세 형식을 확인하기 위한 예시 상관관계 룰
Enabled: true
RuleID: Correlation.Type.Behavior.MoreContext
Severity: High
Reports:
ReportName (예: CIS, MITRE ATT&CK):
- 이 상관관계 룰과 관련된 특정 보고서 섹션
Tags:
- 태그
- 이동
- 여기
YAML 구성 파일을 만드세요. 필수 및 허용되는 값의 전체 목록은
이 상관관계 룰은 Panther CLI의 CLI 워크플로를 검증하기 위해 존재합니다
Runbook: >
먼저, 이 spec 형식을 누가 작성했는지 알아낸 다음 피드백을 전달하세요.
Reference: https://www.a-clickable-link-to-more-info.com
디택션:
- 시퀀스:
- ID: 실패한 로그인
RuleID: Okta.Login.Fail
MinMatchCount: 7
- ID: 성공한 로그인
RuleID: Okta.Login.Success
최소일치수: 1
LookbackWindowMinutes: 15
일정:
RateMinutes: 5
TimeoutMinutes: 3
Tests:
- 이름: 일치 항목이 없으면 룰은 false를 반환해야 함
예상 결과: false
룰 출력:
- ID: 실패한 로그인
일치 항목: {} # 빈 매핑은 일치 항목이 없음을 의미함
```
이 룰이 Panther에 업로드되면 Console에서 볼 수 있습니다.
## 상관 룰 전체 예시
### 유출된 GitHub 자격 증명 탐지
이것 `Discovering.Exfiltrated.Credentials` 상관 룰은 10분마다 [signal](/ko/detections/signals.md) 에 대한 `AWS.CloudTrail.IaaS` 룰(아래 두 번째 탭에 정의됨) *찾지* 뒤이어 신호가 `GitHub.CICD` 룰(아래 세 번째 탭에 정의됨)에서 지난 10분 동안 있었는지 확인합니다.
{% tabs %}
{% tab title="유출된 자격 증명 탐지" %}
```yaml
AnalysisType: correlation_룰
RuleID: 'Discovering.Exfiltrated.Credentials'
DisplayName: 'Discovering.Exfiltrated.Credentials'
Enabled: true
Severity: High
YAML 구성 파일을 만드세요. 필수 및 허용되는 값의 전체 목록은
적어도 하나의 IaaS 활동 일치 항목이 뒤따르지 않았습니다
10분 이내에 CI/CD 활동이.
디택션:
- 시퀀스:
- ID: IaaS 활동
RuleID: AWS.CloudTrail.IaaS
- ID: CICD 활동
RuleID: Github.CICD
부재: true
전이:
- From: IaaS 활동
- To: CICD 활동
WithinTimeFrameMinutes: 10
일정:
RateMinutes: 10
TimeoutMinutes: 3
Tests:
- Name: CICD 활동이 없는 IaaS 활동
예상 결과: true
룰 출력:
- ID: IaaS 활동
일치 항목:
username:
my_username: [1]
- Name: CICD 활동이 있는 IaaS 활동
예상 결과: false
룰 출력:
- ID: IaaS 활동
일치 항목:
username:
my_username: [1]
- ID: CICD 활동
일치 항목:
username:
my_username: [2]
```
{% endtab %}
{% tab title="AWS.CloudTrail.IaaS" %}
```yaml
AnalysisType: 룰
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: 룰
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분마다 확인하여 다음이 있었는지 확인합니다. [signal](/ko/detections/signals.md) 에 대한 [`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_룰
RuleID: 'Brute.Force.Login'
DisplayName: 'Brute.Force.Login'
Enabled: true
Severity: High
YAML 구성 파일을 만드세요. 필수 및 허용되는 값의 전체 목록은
최소 100회의 실패한 로그인 후 성공한 로그인
가 마지막 실패한 로그인 후 10분 이내에 발생했으며
그다음 AWS 콘솔에서 루트 로그인이 발생한 경우
디택션:
- 시퀀스:
- ID: 실패한 로그인
RuleID: Standard.BruteForceByIP
MinMatchCount: 100
- ID: 성공한 로그인
RuleID: Okta.Login.Success
최소일치수: 1
- ID: 루트 로그인
RuleID: AWS.Console.RootLogin
최소일치수: 1
전이:
- ID: 무차별 대입 로그인 성공
From: 실패한 로그인
To: 성공한 로그인
WithinTimeFrameMinutes: 10
일치:
- From: p_알러트_context.ip
To: client.ipAddress
- ID: 루트 접근 획득
From: 성공한 로그인
To: 루트 로그인
일치:
- From: client.ipAddress
To: p_알러트_context.sourceIPAddress
LookbackWindowMinutes: 60
EventEvaluationOrder: 연대순
일정:
RateMinutes: 30
TimeoutMinutes: 3
Tests:
# 이 상관 룰에 대한 추가 테스트는 위의 "단위 테스트 예제"를 참조하세요
- Name: 상대 분을 사용한 성공적인 로그인
예상 결과: true
룰 출력:
- ID: 실패한 로그인
일치 항목:
client.ipAddress:
# 원래 룰의 MinMatchCount가 10이므로, 최소 10개의 타임스탬프가 필요합니다
123.123.123.123: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
- ID: 성공한 로그인
일치 항목:
client.ipAddress:
123.123.123.123: [11]
- ID: 루트 로그인
일치 항목:
srcIpAddress7:
123.123.123.123: [12]
```
{% endtab %}
{% tab title="Okta.Login.Success" %}
```yaml
AnalysisType: 룰
RuleID: 'Okta.Login.Success'
DisplayName: 'Okta 로그인 성공'
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분마다 [signal](/ko/detections/signals.md) 에 대한 [`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_알러트_context.repo` 이벤트 필드에 대한 일치하는 값도 지난 10분 이내에 있습니다.
{% tabs %}
{% tab title="Github.Repo.Security.Policy.Disabled.Without.Archival" %}
```yaml
AnalysisType: correlation_룰
RuleID: 'Github.Repo.Security.Policy.Disabled.Without.Archival'
DisplayName: 'Github 리포지토리 보안 정책이 아카이브 없이 비활성화됨'
Enabled: true
Tags:
- Github
- 리포지토리 아카이브됨
Severity: High
디택션:
- 시퀀스:
- ID: GitHub Advanced Security Change
RuleID: GitHub.Advanced.Security.Change
- ID: Github Repo Archived
RuleID: Github.Repo.Archived
부재: true
전이:
- ID: TR1
From: GitHub Advanced Security Change
대상: Github Repo 보관됨
WithinTimeFrameMinutes: 10
일치:
- 위치: p_알러트_context.repo
일정:
RateMinutes: 10
TimeoutMinutes: 3
Tests:
- 이름: 보관 없이 Github Repo 보안 정책 비활성화
예상 결과: true
룰 출력:
- ID: GitHub Advanced Security Change
일치 항목:
p_알러트_context.repo:
my_production_repo: [1]
- 이름: 보관과 함께 Github Repo 보안 정책 비활성화
예상 결과: false
룰 출력:
- ID: GitHub Advanced Security Change
일치 항목:
p_알러트_context.repo:
my_production_repo: [1]
- ID: Github Repo Archived
일치 항목:
p_알러트_context.repo:
my_production_repo: [2]
```
{% endtab %}
{% tab title="GitHub.Repo.Archived" %}
```yaml
AnalysisType: 룰
RuleID: 'GitHub.Repo.Archived'
DisplayName: 'GitHub Repo 보관됨'
Enabled: true
LogTypes:
- GitHub.Audit
Severity: Info
CreateAlert: false
AlertContext:
- KeyName: repo
KeyValue:
KeyPath: repo
디택션:
- KeyPath: action
Condition: Equals
값: 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"`, 또는 `"blue"`), 반면 `field_b` 필드는 두 가지 값 중 하나만 가질 수 있다면(예: `"purple"` 또는 `"green"`), `field_b` 의 카디널리티가 `field_a`.
* 필드의 데이터 유형—일반적으로 비스칼라 데이터 유형(즉, `배열` 또는 `객체`)는 스칼라 데이터 유형을 가진 필드보다 더 높은 카디널리티를 가집니다(즉, `string`, `불리언`, 또는 `숫자`).
* 예를 들어, 로그 스키마가 둘 다 다음을 지정하는 경우 `email` 및 `username` 필드를 `username` [indicator](/ko/search/panther-fields.md#indicator-fields), 즉, 귀하의 `p_any_usernames` 필드는 둘 다를 다음에 포함합니다 `배열` (예: `p_any_usernames: ["Bob Smith", "bob.smith@example.com"]`), 그 `p_any_usernames` 필드는 다음의 `email` 필드보다 더 높은 카디널리티를 가지며, 해당 필드는 `string` 유형으로 단일 값을 갖습니다.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.panther.com/ko/detections/correlation-rules.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.