> For the complete documentation index, see [llms.txt](https://docs.panther.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.panther.com/ko/detections/correlation-rules.md).
# 상관관계 룰(베타)
## **개요**
{% hint style="info" %}
상관관계 룰은 Panther 버전 1.108부터 오픈 베타이며, 모든 고객이 사용할 수 있습니다. 버그 보고와 기능 요청은 Panther 지원 팀과 공유해 주세요.
{% 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 사용자가 최소 백 번의 로그인 실패 후 성공적으로 로그인한 다음, 루트 사용자로 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).
상관관계 룰에 대해 알러트가 생성되면, 해당 상관관계 룰에서 참조하는 개별 룰, 예약된 룰, 그리고 상관관계 룰도 자체 알러트를 생성할 수도 있고, 생성하지 않을 수도 있습니다. 이는 다음에 따라 달라집니다:
* 각 개별 룰, 예약된 룰, 그리고 상관관계 룰에 알러트 기능이 활성화되어 있는지 여부
* 해당 `임계값` 개별 룰 또는 예약된 룰의 값과, 그리고 `MinMatchCount` 상관 룰의 값입니다. 상관 룰이 알러트를 생성하지만 이를 구성하는 룰들은 생성하지 않는 예외적인 경우는 개별 룰의 이벤트 임계값(다음을 사용하여 설정한 `임계값` 키)가 다음보다 높을 `MinMatchCount` 상관 룰의 값보다 높고, 실제 룰 일치 수가 그 중간쯤에 있을 때입니다.
### 그룹 vs. 시퀀스
상관 룰에는 두 가지 유형이 있습니다: [그룹](#group-correlation-rules) 그리고 [시퀀스](#sequence-correlation-rules). 그룹 및 시퀀스 상관 룰은 신호를 찾아야 하는 룰 집합을 정의합니다(또는 *아님* 찾아짐, 다음을 설정하여 `부재: true`).
그룹 상관 룰은 모든 룰이 신호(또는 부재)를 생성했다면, 신호가 발견된 순서와 상관없이 알러트를 생성합니다. 반면 시퀀스 룰은 알러트를 생성하기 위해 신호(또는 부재)가 발견되어야 하는 특정 순서를 정의합니다.
### 스케줄 및 룩백 윈도우 설정
각 상관 룰은 다음 두 가지를 모두 정의합니다:
* 스케줄: 다음에 의해 [`스케줄`](/ko/detections/correlation-rules/correlation-rule-reference.md#schedule-fields) 필드(다음 중 하나를 사용함 `RateMinutes` 또는 `CronExpression`), 스케줄은 상관 관계 룰이 얼마나 자주 실행되어야 하는지를 나타냅니다.
* 조회 기간: 다음에 의해 정의됨 `LookbackWindowMinutes` 필드이며, 조회 기간은 상관 관계 룰이 찾아야 할 과거의 분 수를 지정합니다 [신호](/ko/detections/signals.md) (또는 신호의 부재)에 대해, 해당 그룹 또는 시퀀스에 포함된 룰, 예약된 룰 또는 상관 관계 룰에 대해.
의 값을 설정할 때 `스케줄` 그리고 `LookbackWindowMinutes`, 몇 가지 요소를 고려하는 것이 좋습니다:
* 이 상관 룰에서 일치 항목에 대해 제때 알림을 받는 것이 얼마나 중요한지
* 예를 들어, 우선순위가 낮은 상관 룰은 24시간마다만 실행해도 충분할 수 있습니다. 또는 우선순위가 높은 상관 룰은 15분마다 실행하고 싶을 수 있습니다.
* 상관 룰이 찾고 있는 첫 번째 신호와 마지막 신호가 시간적으로 얼마나 떨어져 있어야 동일한 발생의 일부로 간주되어 일치 항목을 생성할 수 있는지
* 참조 [신호가 조회 범위 윈도우 사이에 분할되지 않도록 보장하기](#ensuring-signals-arent-split-between-lookback-windows)
* 상관 룰과 연결된 룰이 평가하는 데이터 소스에서 예상되는 최대 지연 시간
* 참조 [로그 소스 지연 시간을 고려하여 `LookbackWindowMinutes`](#accounting-for-log-source-latency-in-lookbackwindowminutes)
`스케줄` 그리고 `LookbackWindowMinutes` 값은 Snowflake 컴퓨팅 비용에 영향을 미칠 수 있습니다. 참조 [상관관계 룰을 더 효율적으로 만들기](#making-correlation-rules-more-efficient) 자세한 내용은.
#### 신호가 조회 범위 윈도우 사이에 분할되지 않도록 보장하기
필요한 신호가 여러 상관 룰 실행의 조회 범위 윈도우에 걸쳐 분할되어 검색 대상의 발생을 놓치지 않도록 조회 범위를 설정하는 것이 좋습니다.
피해야 할 상황의 예시
우리가 피하려는 이 상황을 보여주기 위해, 다음의 단순화된 상관관계 룰 구성 예시를 보세요:
```yaml
# 나쁜 예시; 복제하지 마세요
- 그룹:
- 룰ID: First.룰
- 룰ID: Second.룰
- 룰ID: Third.룰
일정:
주기분: 60
조회창분: 90
```
이 시나리오에서는 매 시간마다 correlation 룰이 이전 90분을 되돌아보며 다음에 포함된 세 개의 룰에 대한 신호를 찾습니다 `그룹`. 예를 들어, 이들 각 룰이 아래 시간에 신호를 매칭/생성했다고 해봅시다:
* 다음에 대한 신호 `첫 번째.룰` 오후 12:58에 생성됨
* 다음에 대한 신호 `두 번째.룰` 오후 1:05에 생성됨
* 다음에 대한 신호 `세 번째.룰` 오후 1:40에 생성됨
correlation 룰은 매시 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` 는 correlation 룰이 시퀀스이고 단계가 두 개뿐인 경우 같을 수 있습니다.)
다음을 구성하는 것이 권장됩니다. `LookbackWindowMinutes` 값을 구성하여 "최대 신호 시간 범위 분" 길이의 모든 가능한 창이 correlation 룰의 적어도 한 번의 실행에서 포함되도록 하세요. 일반적으로 다음 공식으로 가능합니다:
* 만약 `RateMinutes` <= "최대 신호 시간 범위 분":
* `LookbackWindowMinutes` = 2 x "최대 신호 시간 범위 분" + 로그 수집 지연
* 만약 `RateMinutes` > "최대 신호 시간 범위 분":
* `LookbackWindowMinutes` = "최대 신호 시간 범위 분" + `RateMinutes` + 로그 수집 지연
로그 수집 지연이 포함되는 이유를 이해하려면 다음을 참조하세요: [로그 소스 지연 시간을 고려하여 `LookbackWindowMinutes`](#accounting-for-log-source-latency-in-lookbackwindowminutes)
#### 로그 소스 지연 시간을 고려하여 `LookbackWindowMinutes`
로그 수집 지연은 correlation 룰과 연관된 룰이 평가하는 데이터 소스에서 예상되는 최대 지연 시간입니다.
신호는 관련 이벤트가 발생한 시간(`p_event_time`), *아님* 이벤트가 Panther에 수집된 시간(`p_parse_time`), 따라서 다음을 결정할 때 수집 지연을 고려해야 합니다 `LookbackWindowMinutes` 마지막으로 correlation 룰이 실행된 이후의 모든 "새" 데이터를 처리하고 있음을 보장하기 위해.
예를 들어, correlation 룰을 매시간 실행하도록 구성했다면(예: 다음을 설정하여 `RateMinutes` 로 `60`) 그리고 correlation 룰과 연관된 룰이 처리하는 로그의 소스에 따르면 Panther로의 로그 전달이 최대 3시간 지연될 수 있다고 명시되어 있다면, 다음과 같이 설정할 수 있습니다 `LookbackWindowMinutes` 로 `60 + 3*60`, 또는 `240`. 이를 더 자세히 설명하기 위해, 3시간의 수집 지연 때문에 Panther가 `오전 9:01` 다음과 같은 `p_event_time` 이르면 `오전 6:01`. `오전 10:00`, 최소한 다음 시점까지 되돌아봐야 합니다 `오전 6:01`.
### 이벤트 중복 제거
correlation 룰의 중복 제거 기간은 다음의 값입니다 [`LookbackWindowMinutes`](/ko/detections/correlation-rules/correlation-rule-reference.md#detection-fields) 필드. 이는 동일한 범위 내에서 겹치는 correlation 룰이 `LookbackWindowMinutes` 시간 범위에는 해당 상관관계 룰이 일치하게 만든 고유 이벤트만 포함됩니다.
상관관계 룰에서 참조된 개별 룰 및 예약된 룰에 대해 설정된 중복 제거( with `dedup()`, `DedupPeriodMinutes`, `임계값` , 또는 콘솔에서 설정한 값)은 해당 상관관계 룰에 적용되지 않습니다.
### 상관관계 룰 오류
상관관계 룰을 사용할 때 다음 오류 중 하나를 받을 수 있습니다:
* [단순 디택션 오류 코드](/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": "failed_login",
"p_event_time": "2023-12-08 10:27:03.496000000",
"p_알러트_context": {
"ip": "136.24.229.58",
"geolocation": "미국 캘리포니아주 샌프란시스코"
}
},
{
"p_룰_id": "Standard.BruteForceByIP",
"event_type": "failed_login",
"p_event_time": "2023-12-08 10:27:03.623000000",
"p_알러트_context": {
"ip": "136.24.229.58",
"geolocation": "미국 캘리포니아주 샌프란시스코"
}
},
{
"p_룰_id": "Standard.BruteForceByIP",
"event_type": "failed_login",
"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": "successful_login",
"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` 네 개의 룰 모두의 필드에 같은 값이 있어야 합니다.
```yaml
디택션:
- 그룹:
- ID: &failed_login 실패한 로그인
룰ID: Standard.BruteForceByIP
MinMatchCount: 7
- ID: &successful_login 성공한 로그인
룰ID: Okta.Login.Success
- ID: &root_access 루트 액세스
룰ID: AWS.Console.RootLogin
- ID: &missing_crowdstrike 누락된 Crowdstrike
룰ID: Crowdstrike.디택션.passthrough
부재: true
MatchCriteria:
ip:
- GroupID: *failed_login
Match: p_알러트_context.ip
- GroupID: *successful_login
Match: p_알러트_context.ip
- GroupID: *root_access
Match: p_알러트_context.sourceIPAddress
- GroupID: *missing_crowdstrike
Match: 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) (또는 신호의 부재)가 지정된 조회 범위 내에서 특정 순서로 발생해야 합니다.
시퀀스의 순서는 다음 내에 정의된 룰의 순서로 정의됩니다: `시퀀스` 키.
상관관계 룰이 모든 룰에 신호(또는 부재)가 있는지만으로 일치하도록 하고 특정 순서를 요구하지 않으려면 다음을 사용하세요: [그룹 상관관계 룰](#group-correlation-rules) 대신.
### 전이
시퀀스 내에서 선택적으로 전이를 정의할 수 있습니다. 전이는 시퀀스의 한 단계가 다음 단계로 이동하는 방식에 대한 추가 기준을 정의하며, 여기에는 단계 사이에 허용되는 시간과 일치해야 하는 이벤트 필드가 포함됩니다. 다음을 사용하면 `전이` 와 `WithinTimeFrameMinutes` 및/또는 `일치` 상관관계 룰의 구체성이 높아집니다.
전이가 정의된 경우, 다음에 포함된 룰 수보다 전이 수가 하나 적어야 합니다: `시퀀스`. 또한 다음 내의 항목들은 `전이` 다음과 같은 순서여야 합니다: `시퀀스` 목록.
현재, 상관관계 룰당 일치시킬 수 있는 필드 유형은 하나만 가능합니다(예: *모든* 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": "failed_login",
"p_event_time": "2023-12-08 10:27:03.496000000",
"p_알러트_context": {
"ip": "136.24.229.58",
"geolocation": "미국 캘리포니아주 샌프란시스코"
}
},
{
"p_룰_id": "Standard.BruteForceByIP",
"event_type": "failed_login",
"p_event_time": "2023-12-08 10:27:03.623000000",
"p_알러트_context": {
"ip": "136.24.229.58",
"geolocation": "미국 캘리포니아주 샌프란시스코"
}
},
{
"p_룰_id": "Standard.BruteForceByIP",
"event_type": "failed_login",
"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": "successful_login",
"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="전이 및 일치가 있는 시퀀스 " %}
다음을 사용하면 `전이` 와 `일치` 내에서 `시퀀스` 값이 일치해야 하는 이벤트 필드를 정의하고 싶다면 유용합니다.
```yaml
디택션:
- 시퀀스:
- ID: 실패한 로그인
룰ID: Standard.BruteForceByIP
MinMatchCount: 7
- ID: 성공한 로그인
룰ID: Okta.Login.Success
MinMatchCount: 1
- ID: 루트 로그인
룰ID: AWS.Console.RootLogin
MinMatchCount: 1
- ID: 누락된 Crowdstrike
룰ID: Crowdstrike.디택션.passthrough
부재: true
전이:
- ID: 무차별 대입 로그인 성공
출발: 실패한 로그인
도착: 성공한 로그인
WithinTimeFrameMinutes: 10
일치:
- 대상: client.ipAddress
- ID: 루트 권한 획득
출처: 로그인 성공
대상: 루트 로그인
일치:
- 출처: client.ipAddress
대상: p_알러트_context.sourceIPAddress
- ID: Crowdstrike 부재
출처: 루트 로그인
대상: Crowdstrike 누락
일치:
- 출처: p_알러트_context.sourceIPAddress
대상: p_any_ip_addresses
LookbackWindowMinutes: 60
EventEvaluationOrder: 시간 순서대로
일정:
RateMinutes: 30
TimeoutMinutes: 3
```
{% endtab %}
{% tab title="전환 포함, 일치 없음 시퀀스" %}
다음을 사용하면 `전이` 내에서 `시퀀스` 없이 `일치` 시퀀스의 두 단계가 발생해야 하는 시간 범위만 지정하고 싶다면 유용하며, 다음을 사용하여 `WithinTimeFrameMinutes`.
```yaml
디택션:
- 시퀀스:
- ID: 실패한 로그인
룰ID: Standard.BruteForceByIP
MinMatchCount: 7
- ID: 성공한 로그인
룰ID: Okta.Login.Success
- ID: 루트 로그인
룰ID: AWS.Console.RootLogin
- ID: 누락된 Crowdstrike
룰ID: Crowdstrike.디택션.passthrough
부재: true
전이:
- ID: 무차별 대입 로그인 성공
출발: 실패한 로그인
도착: 성공한 로그인
WithinTimeFrameMinutes: 10 # 시간 범위 정의
- ID: 루트 권한 획득
출처: 로그인 성공
대상: 루트 로그인
- ID: Crowdstrike 부재
출처: 루트 로그인
대상: Crowdstrike 누락
LookbackWindowMinutes: 60
일정:
RateMinutes: 30
TimeoutMinutes: 3
```
{% endtab %}
{% tab title="전환 없는 시퀀스" %}
생략할 수 있습니다 `전이` 내에서 `시퀀스` 이벤트 필드의 일치 대상이나 단계가 발생해야 하는 시간 범위를 지정하고 싶지 않다면.
```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 %}
단위 테스트는 다음의 상관관계 룰에 정의됩니다 **단위 테스트** 탭(Panther Console에서) 또는 최상위 `테스트` 필드(CLI 워크플로우에서)에 정의되며, 다음과 유사한 구조를 가집니다 [룰 또는 정책에 대한 단위 테스트](/ko/detections/testing.md).
각 상관관계 룰의 단위 테스트에는 다음이 포함되어야 합니다: `이름`, `예상 결과`, 그리고 `룰 출력` 필드. 단위 테스트의 YAML 구조와, 다음을 구성하는 방법을 포함해 자세히 알아보세요 `룰 출력` 값 [여기, 상관관계 룰 참조에서](/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
최소 일치 수: 10
- ID: OktaLoginSuccess
룰ID: Okta.Login.Success
MinMatchCount: 1
- ID: RootLogin
룰ID: AWS.Console.RootLogin
MinMatchCount: 1
전이:
- ID: Okta 무차별 대입 로그인
출발: OktaLoginFailure
도착: OktaLoginSuccess
WithinTimeFrameMinutes: 10
일치:
- 대상: client.ipAddress
- ID: AWS 루트 로그인
출발: OktaLoginSuccess
도착: RootLogin
일치:
- 출처: client.ipAddress
도착: srcIpAddress7
일정:
RateMinutes: 15
TimeoutMinutes: 2
LookbackWindowMinutes: 60
```
다음 테스트를 작성할 수 있습니다:
{% hint style="info" %}
아래 테스트가 룰의 YAML 파일에 포함되어 있었다면(CLI 워크플로에서 탐지를 관리할 때 필요함), 이 테스트들은 하나의 `테스트` 키.
{% endhint %}
{% tabs %}
{% tab title="절대 타임스탬프를 사용한 테스트" %}
로그인 시도가 10번 뒤에 성공적인 로그인과 그다음 루트 로그인이 이어지면, 상관 룰이 반환할 것으로 예상합니다 `true`. 이 테스트는 절대 타임스탬프를 사용합니다—절대 타임스탬프 사용 방법에 대해 자세히 알아보세요 [여기, 상관관계 룰 참조에서](/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="상대 타임스탬프를 사용한 테스트" %}
로그인 시도가 10번 뒤에 성공적인 로그인과 그다음 루트 로그인이 이어지면, 상관 룰이 반환할 것으로 예상합니다 `true`. 이 테스트는 상대 타임스탬프를 사용합니다—상대 타임스탬프 사용 방법에 대해 자세히 알아보세요 [여기, 상관관계 룰 참조에서](/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
이름: 성공 전 9번의 로그인 실패
예상 결과: 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 %}
## 상관 룰의 제한 사항
* 시퀀스가 전환을 사용하는 경우:
* 허용되는 전환 수는 시퀀스 컬렉션에 포함된 룰 수보다 하나 적습니다.
* 해당 목록의 항목 순서는 `전이` 목록은 해당 룰들의 순서와 일치해야 합니다 `시퀀스` 필드와.
* 이벤트 필드 매칭을 사용하는 경우:
* 이전 `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에서 흐름도 시각화 도구 사용
Correlation Rules를 작업하는 동안 Panther Console의 흐름도 시각화 도구를 사용할 수 있습니다. YAML로 구성하는 동안 상관 룰을 시각적으로 렌더링하며, UI는 룰에 대한 즉각적인 검증 피드백을 제공합니다.
### Console에서 YAML로 상관 룰 만들기
Panther Console에서 상관 룰을 만들려면 목록 보기에서 디택션을 선택해 YAML을 생성하거나, 직접 YAML을 구성할 수 있습니다.
{% tabs %}
{% tab title="룰을 선택하고 YAML 생성" %}
1. Panther Console의 왼쪽 탐색 막대에서 다음을 클릭하세요 **디택션**.
2. 디택션 목록에서 상관 룰에 포함할 각 디택션의 왼쪽에 있는 확인란을 클릭하세요.
* 디택션을 클릭하는 순서가 생성된 [시퀀스](#sequence-correlation-rules) 상관 룰의 순서가 됩니다.
3. 클릭 **상관**.\
4. 디택션 생성 페이지에서 상관 룰 구성을 완료하세요:
* **이름**: 상관 룰에 대한 설명적인 이름을 입력하세요.
* **ID** (선택 사항)**:** 펜 아이콘을 클릭하고 상관 룰에 대한 고유한 ID를 입력하세요.
* 오른쪽 상단의 **사용 설정** 토글은 다음으로 설정됩니다 `ON` 기본적으로. 룰을 비활성화하려면 토글을 `OFF`.
* 다음 아래의 **YAML 편집기** 탭:
* 원하는 경우 생성된 상관 룰을 수정할 수 있습니다. 기본적으로 룰은:
* 다음입니다 [`시퀀스`](/ko/detections/correlation-rules/correlation-rule-reference.md#detection-fields) 상관 룰의 순서가 됩니다.
* 다음으로 변경할 수 있습니다 [`그룹`](/ko/detections/correlation-rules/correlation-rule-reference.md#detection-fields) 를 클릭하여 **룰을 그룹으로 구성**.\
\
다음에서 자세히 알아보세요 [Console에서 시퀀스와 그룹 간 전환](#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) 일치 항목이 있을 때 생성되어야 하는지, 아니면 단지 [신호](/ko/detections/signals.md).
* (다음에만 적용됨 **알러트 생성** 이 설정된 경우 `ON`) **심각도:** 다음을 선택하세요 [심각도 수준](#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 편집기** 탭에서 상관 룰을 정의하세요.
* 기본적으로 상관 룰은 시퀀스로 구성됩니다 [`시퀀스`](/ko/detections/correlation-rules/correlation-rule-reference.md#detection-fields). 이를 다음으로 변경할 수 있습니다 [`그룹`](/ko/detections/correlation-rules/correlation-rule-reference.md#detection-fields) 를 클릭하여 **룰을 그룹으로 구성**.\
\
다음에서 자세히 알아보세요 [Console에서 시퀀스와 그룹 간 전환](#switching-between-sequence-and-group-in-the-console).
* 상관 디택션 YAML 구문에 대한 자세한 내용은 다음에서 확인할 수 있습니다 [상관관계 룰 참조](/ko/detections/correlation-rules/correlation-rule-reference.md)필수 및 선택 필드의 전체 목록을 포함하여.
* 다음 아래의 **알러트 설정** 탭:
* 다음 내부 **기본** 탭에서 다음 필드를 구성합니다:
* **알러트 생성**: 이 `ON/OFF` 토글은 알러트가 [알러트](/ko/alerts.md) 일치 항목이 있을 때 생성되어야 하는지, 아니면 단지 [신호](/ko/detections/signals.md).
* (다음에만 적용됨 **알러트 생성** 이 설정된 경우 `ON`) **심각도:** 다음을 선택하세요 [심각도 수준](#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 %}
#### Console에서 시퀀스와 그룹 간 전환
다음 기능을 사용하여 상관 룰을 시퀀스에서 그룹으로, 또는 그 반대로 전환할 수 있습니다: **룰을 그룹/시퀀스로 구성** 버튼을 다음의 오른쪽 상단에서 **YAML 편집기** 패널.
상관 룰이 이미 시퀀스이고 다음을 클릭하면 **룰을 그룹으로 구성**:
* 해당 `시퀀스` 키는 다음으로 변경됩니다 `그룹`.
* 해당 `전이` 섹션이 제거됩니다.
* A `MatchCriteria` 섹션이 추가됩니다.
* 이전에 다음을 수정한 경우 `MatchCriteria` 섹션이 추가됩니다. 그렇지 않으면 기본 `MatchCriteria` 섹션이 제공됩니다.
상관 룰이 이미 그룹이고 다음을 클릭하면 **룰을 시퀀스로 구성**:
* 해당 `그룹` 키는 다음으로 변경됩니다 `시퀀스`.
* 해당 `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:
- 태그
- 이동
- 여기
Description: >
이 상관관계 룰은 Panther CLI의 CLI 워크플로를 검증하기 위해 존재합니다
Runbook: >
먼저 이 사양 형식을 작성한 사람이 누구인지 확인한 다음, 피드백을 전달하여 알립니다.
Reference: https://www.a-clickable-link-to-more-info.com
디택션:
- 시퀀스:
- ID: 실패한 로그인
RuleID: Okta.Login.Fail
MinMatchCount: 7
- ID: 성공한 로그인
룰ID: Okta.Login.Success
MinMatchCount: 1
LookbackWindowMinutes: 15
일정:
RateMinutes: 5
TimeoutMinutes: 3
Tests:
- Name: 일치 항목이 없으면 룰은 false를 반환해야 함
예상 결과: false
룰 출력:
- ID: 실패한 로그인
Matches: {} # 빈 매핑은 일치 항목이 없음을 의미함
```
이 룰이 Panther에 업로드되면 Console에서 볼 수 있습니다.
## 상관관계 룰 전체 예시
### 유출된 GitHub 자격 증명 검색
이 `Discovering.Exfiltrated.Credentials` 상관관계 룰은 10분마다 다음이 있었는지 확인합니다 [신호](/ko/detections/signals.md) 다음에 대해 `AWS.CloudTrail.IaaS` 룰(아래 두 번째 탭에 정의됨) *아님* 이어서 다음에 대한 시그널이 `GitHub.CICD` 룰(아래 세 번째 탭에 정의됨)이 지난 10분 이내에 발생했는지 확인합니다.
{% tabs %}
{% tab title="유출된 자격 증명 검색" %}
```yaml
AnalysisType: correlation_룰
RuleID: 'Discovering.Exfiltrated.Credentials'
표시 이름: 'Discovering.Exfiltrated.Credentials'
Enabled: true
Severity: High
Description: >
최소 하나의 IaaS 활동 일치가 뒤따르지 않았습니다
10분 이내에 CI/CD 활동이 뒤따르지 않았습니다.
디택션:
- 시퀀스:
- ID: IaaS 활동
룰 ID: AWS.CloudTrail.IaaS
- ID: CI/CD 활동
룰 ID: Github.CICD
부재: true
전이:
- 출처: IaaS 활동
대상: CI/CD 활동
WithinTimeFrameMinutes: 10
일정:
분 간격: 10
TimeoutMinutes: 3
Tests:
- 이름: CI/CD 활동 없는 IaaS 활동
예상 결과: true
룰 출력:
- ID: IaaS 활동
일치 항목:
사용자 이름:
my_username: [1]
- 이름: CI/CD 활동이 있는 IaaS 활동
예상 결과: false
룰 출력:
- ID: IaaS 활동
일치 항목:
사용자 이름:
my_username: [1]
- ID: CI/CD 활동
일치 항목:
사용자 이름:
my_username: [2]
```
{% endtab %}
{% tab title="AWS.CloudTrail.IaaS" %}
```yaml
분석 유형: 룰
룰 ID: 'AWS.CloudTrail.IaaS'
표시 이름: 'AWS CloudTrail IaaS'
Enabled: true
로그 유형:
- AWS.CloudTrail
심각도: 정보
알림 생성: false
디택션:
- 키 경로: userIdentity.arn
조건: 포함
값:
- DeploymentUpdateGitHubRole
- 키 경로: eventName
조건: 포함
값:
- StartSession
- ListResources
- UpdateResource
- DescribeResource
- WriteLog
```
{% endtab %}
{% tab title="GitHub.CICD" %}
```yaml
분석 유형: 룰
룰 ID: 'GitHub.CICD'
표시 이름: 'GitHub CI/CD'
Enabled: true
로그 유형:
- GitHub.Audit
심각도: 정보
알림 생성: false
디택션:
- 키 경로: repository
조건: 같음
값: panther-labs/example-repo
- 키 경로: action
조건: 같음
값: workflows.created_workflow_run
- 키 경로: name
조건: 같음
값: CI
```
{% endtab %}
{% endtabs %}
### Okta 무차별 대입 로그인에서 AWS 루트 로그인으로
이 `Brute.Force.Login` 상관 룰은 30분마다 다음이 있었는지 확인합니다 [신호](/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_룰
룰 ID: 'Brute.Force.Login'
표시 이름: 'Brute.Force.Login'
Enabled: true
Severity: High
Description: >
적어도 100번의 실패한 로그인 뒤에 성공한 로그인
마지막 실패한 로그인 후 10분 이내에 발생한
그리고 AWS 콘솔에서 root 로그인.
디택션:
- 시퀀스:
- ID: 실패한 로그인
룰ID: Standard.BruteForceByIP
최소 일치 수: 100
- ID: 성공한 로그인
룰ID: Okta.Login.Success
MinMatchCount: 1
- ID: 루트 로그인
룰ID: AWS.Console.RootLogin
MinMatchCount: 1
전이:
- ID: 무차별 대입 로그인 성공
출발: 실패한 로그인
도착: 성공한 로그인
WithinTimeFrameMinutes: 10
일치:
- 출처: p_알러트_context.ip
대상: client.ipAddress
- ID: 루트 권한 획득
출처: 로그인 성공
대상: 루트 로그인
일치:
- 출처: client.ipAddress
대상: p_알러트_context.sourceIPAddress
LookbackWindowMinutes: 60
EventEvaluationOrder: 시간 순서대로
일정:
RateMinutes: 30
TimeoutMinutes: 3
Tests:
# 위의 "단위 테스트 예시"에서 이 상관관계 룰에 대한 추가 테스트를 참조하세요
- 이름: 상대 분 단위의 성공한 로그인
예상 결과: 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
분석 유형: 룰
룰 ID: 'Okta.Login.Success'
표시 이름: 'Okta 로그인 성공'
Enabled: true
로그 유형:
- Okta.SystemLog
심각도: 정보
알림 생성: false
디택션:
- 심층 키:
- 결과
- 결과
조건: 같음
값: SUCCESS
- 키: eventType
조건: 같음
값: user.session.start
```
{% endtab %}
{% endtabs %}
### 후속 보관 없이 GitHub 저장소 보안 정책이 비활성화됨
이 `Github.Repo.Security.Policy.Disabled.Without.Archival` 상관관계 룰은 10분마다 다음이 있었는지 확인합니다 [신호](/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_룰
룰 ID: 'Github.Repo.Security.Policy.Disabled.Without.Archival'
표시 이름: '깃허브 저장소 보안 정책 비활성화 - 보관 없음'
Enabled: true
Tags:
- 깃허브
- 저장소 보관됨
Severity: High
디택션:
- 시퀀스:
- ID: GitHub Advanced Security Change
룰 ID: GitHub.Advanced.Security.Change
- ID: Github Repo Archived
룰 ID: Github.Repo.Archived
부재: true
전이:
- ID: TR1
출처: GitHub Advanced Security Change
대상: Github Repo Archived
WithinTimeFrameMinutes: 10
일치:
- 기준: p_알러트_context.repo
일정:
분 간격: 10
TimeoutMinutes: 3
Tests:
- 이름: Github Repo Security Policy Disabled Without Archival
예상 결과: true
룰 출력:
- ID: GitHub Advanced Security Change
일치 항목:
p_알러트_context.repo:
my_production_repo: [1]
- 이름: Github Repo Security Policy Disabled With Archival
예상 결과: 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
분석 유형: 룰
룰 ID: 'GitHub.Repo.Archived'
표시 이름: 'GitHub 저장소 보관됨'
Enabled: true
로그 유형:
- GitHub.Audit
심각도: 정보
알림 생성: false
알러트컨텍스트:
- 키 이름: repo
키 값:
키 경로: repo
디택션:
- 키 경로: action
조건: 같음
값: repo.archived
```
{% endtab %}
{% endtabs %}
## 상관관계 룰을 더 효율적으로 만들기
상관관계 룰은 복잡한 패턴 인식을 사용하므로, 계산 비용이 많이 들 수 있습니다. 상관관계 룰과 관련된 Snowflake 비용을 줄이려면 다음 지침을 염두에 두세요.
### **상관관계 룰을 가능한 한 드물게 실행하세요**
상관관계 룰이 얼마나 자주 실행되는지—이는 해당 `스케줄` 값으로 결정되며—비용에 큰 영향을 미칠 수 있습니다. 따라서 상관관계 룰이 필요한 것보다 더 자주 실행되지 않도록 하는 것이 좋습니다(다만 디택션 필요 사항은 충족해야 합니다—참조 [설정 `스케줄`, 위의](#setting-schedule), 이 필드를 구성할 때의 고려 사항).
상관관계 룰의 실행 빈도와 비용 간의 관계를 생각할 때의 일반적인 지침은 다음과 같습니다: 상관관계 룰이 실행되는 간격을 두 배로 늘릴 때마다(예: 다음을 두 배로 늘려 `RateMinutes`), 생성되는 비용은 절반이 됩니다.
### **설정하세요 `LookbackWindowMinutes` 가능한 한 낮게**
상관관계 룰이 처리하는 데이터 양은 주로 해당 `LookbackWindowMinutes` 값에 의해 결정되며, 이 데이터 양은 상관관계 룰의 처리 시간과 그에 따른 비용의 주요 요인입니다. 상관관계 룰이 처리하는 데이터 양을 줄이려면 해당 값을 `LookbackWindowMinutes` 가능한 한 낮게 설정하는 것이 좋습니다(다만 디택션 필요 사항은 충족해야 합니다—참조 [설정 `LookbackWindowMinutes`, 위의](#setting-lookbackwindowminutes), 이 필드를 구성할 때의 고려 사항).
예를 들어, 두 룰이 서로 10분 이내에 각각 신호를 생성하는 시점을 식별하고 싶다고 해봅시다(다음을 사용하여 `WithinTimeFrameMinutes`). 설정하는 것은 `LookbackWindowMinutes` 를 정확히 `10` 로 설정하는 것은 권장되지 않지만, 다음과 같이 낮은 값도 안전하게 사용할 수 있습니다 `15`.
### **가능한 한 가장 낮은 카디널리티의 일치 필드를 선택하세요**
일치 필드의 카디널리티는 상관관계 룰 비용과 양의 상관관계가 있습니다. 상관관계 룰이 이벤트 값 일치를 사용하는 경우, 일치시킬 필드를 선택할 때 카디널리티가 더 낮은 필드를 사용하는 것이 좋습니다.
일치 필드의 카디널리티는 다음과 같은 몇 가지 요인의 영향을 받을 수 있습니다:
* 필드가 가질 수 있는 가능한 값의 수—가능한 값이 많을수록 카디널리티가 높아집니다.
* 예를 들어, `field_a` 는 세 가지 가능한 값 중 하나를 가질 수 있습니다(예: `"노란색"`, `"빨간색"`, 또는 `"파란색"`), 하지만 `field_b` 는 두 가지 값 중 하나만 가질 수 있습니다(예: `"보라색"` 또는 `"초록색"`), `field_b` 는 다음보다 카디널리티가 더 낮습니다 `field_a`.
* 필드의 데이터 유형—일반적으로 비스칼라 데이터 유형(i.e., `배열` 또는 `객체`)는 스칼라 데이터 유형(i.e., `문자열`, `불리언`, 또는 `숫자`).
* 예를 들어, 로그 스키마가 다음 둘 다를 하나의 `이메일` 그리고 `사용자 이름` 필드로 지정하고 `사용자 이름` [인디케이터](/ko/search/panther-fields.md#indicator-fields)라는 뜻이라면, 귀하의 `p_any_usernames` 필드는 둘 다 다음에 포함하게 됩니다 `배열` (예: `p_any_usernames: ["Bob Smith", "bob.smith@example.com"]`), 그 `p_any_usernames` 필드는 다음보다 더 높은 카디널리티를 가집니다 `이메일` 필드이며, 하나의 `문자열` 단일 값을 가진 타입.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## 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, and the optional `goal` query parameter:
```
GET https://docs.panther.com/ko/detections/correlation-rules.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.