상관 규칙(베타)

상관 규칙은 로그 전반에 걸쳐 상관관계를 설정하고 이상을 식별하며 복잡한 공격 행동을 모델링한 후 경고를 생성합니다

개요

상관 규칙은 Panther 버전 1.108부터 오픈 베타이며 모든 고객이 사용할 수 있습니다. 버그 보고서나 기능 요청이 있으면 Panther 지원팀에 공유해 주세요.

Panther에서 상관 규칙을 사용하면 여러 로그 유형에 걸친 여러 동작을 추적할 수 있습니다. 상관 규칙에서는 다음을 지정합니다. 그룹 또는 특정 시퀀스 의 시그널 이 특정 시간 창 내에 발생해야 일치로 간주되는지 — 그런 다음 시그널을 생성하고 선택적으로 경보.

또한 상관 규칙 기준에 시그널의 부재 를 포함할 수 있습니다. 상관 규칙의 일치 여부는 규칙 일치나 경보가 아니라 시그널로 결정되므로 규칙, 예약 규칙 및 상관 규칙을 포함하여 경보가 비활성화된.

상관 규칙은 예를 들어 다음과 같은 상황에서 경보를 생성하려는 경우 특히 유용할 수 있습니다:

• 특정 Okta 사용자가 최소 백 번의 실패한 로그인 시도 후 성공적으로 로그인한 다음 AWS에 루트 사용자로 로그인하는 경우 (아래 전체 예시 참조)

• GitHub 저장소에서 고급 보안 설정이 비활성화된 후 저장소가 보관(archived)되지 않은 경우 (아래 전체 예시 참조)

아래에서 사용자 정의 상관 규칙을 만드는 방법을 알아보세요및 상관 규칙을 구성하는 YAML 키에 대한 자세한 내용은 상관 규칙 참조를 확인하세요. 또한 다음을 활용할 수 있습니다 Panther 관리 상관 규칙.

상관 규칙을 사용하면 Snowflake 컴퓨트 비용이 증가할 수 있습니다. 상관 규칙을 보다 비용 효율적으로 만드는 방법은 다음 지침을 참조하세요 상관 규칙 효율화하기아래를 참조하세요.

상관 규칙 작동 방식

상관 규칙은 YAML로 작성되며 이전에 생성된 규칙, 예약 규칙및/또는 상관 규칙을 참조합니다. 각 상관 규칙은 일정에 따라 실행되며 및 “조회 창(lookback window)”을 정의합니다, 즉 규칙이 과거 어느 정도 기간을 조회하여 시그널 (또는 시그널의 부재)를 찾을지의 양을 의미합니다.

상관 규칙에 다음과 같은 추가 기준을 적용할 수 있습니다:

• 특정 규칙에 대해 발견되어야 할 최소 시그널 수 또는 최대값 요구

• 한 규칙에서 다른 규칙까지 특정 이벤트 값이 일치하도록 요구(예: 모든 개별 규칙의 시그널이 동일한 IP 주소를 포함하도록 요구)

• 내에서 시퀀스 후속 단계가 특정 시간 내에 발생했어야 함을 요구

상관 규칙에서 일치가 발생하면 어떤 일이 발생하는가

상관 규칙의 일치는 시그널를 생성합니다. 상관 규칙에 경보가 활성화되어 있으면 규칙 일치가 생성되고, 이는 상관 규칙의 중복 제거 구성. 에서 설정한 대로 경보를 생성할 수 있습니다. 시그널, 규칙 일치 및 경보의 차이에 대해 자세히 알아보세요..

상관 규칙에 대해 경보가 생성되면 상관 규칙에 참조된 개별 규칙, 예약 규칙 및 상관 규칙이 자체 경보를 생성할 수도 있고 생성하지 않을 수도 있습니다. 이는 다음에 따라 달라집니다:

• 각 개별 규칙, 예약 규칙 및 상관 규칙에 경보가 활성화되어 있는지 여부

• 를 입력하세요 임계값 개별 규칙 또는 예약 규칙의 값 및 MinMatchCount 상관 규칙의 값. 상관 규칙은 경보를 생성할 수 있지만 이를 구성하는 규칙들은 경보를 생성하지 못하는 엣지 케이스는 개별 규칙의 이벤트 임계값( 임계값 키로 설정됨)이 상관 규칙의 MinMatchCount 값보다 높고 실제 규칙 일치 수가 그 중간 어딘가에 있는 경우입니다.

그룹 vs. 시퀀스

상관 규칙에는 두 가지 유형이 있습니다: 그룹 및 시퀀스. 그룹 및 시퀀스 상관 규칙 모두 시그널이 찾아져야 하는(또는 찾아지지 ) 집합을 정의하며, 이는 Absence: true).

로 설정하여 시그널의 부재로 정의할 수 있습니다. 그룹 상관 규칙은 모든 규칙이 시그널(또는 부재)을 생성하면 시그널이 발견된 순서와 상관없이 경보를 생성합니다. 반면 시퀀스 규칙은 경보를 생성하려면 시그널(또는 부재)이 특정 순서로 발견되어야 함을 정의합니다.

일정 및 조회 창 설정하기

각 상관 규칙은 다음 두 가지를 모두 정의합니다:

• 일정: Schedule 필드로 정의되며(이는 RateMinutes 또는 또는CronExpression

• 을 사용), 일정은 상관 규칙이 얼마나 자주 실행되어야 하는지를 나타냅니다. 조회 창(lookback window): LookbackWindowMinutes 시그널 필드로 정의되며, 조회 창은 그룹 또는 시퀀스에 포함된 규칙, 예약 규칙 또는 상관 규칙에 대해 과거 몇 분을 조회할지 지정합니다(또는 시그널의 부재를).

값을 설정할 때 Schedule 및 조회 창(lookback window):다음 몇 가지 요소를 고려하는 것이 권장됩니다:

• 이 상관 규칙의 일치에 대해 적시에 경보를 받는 것이 얼마나 중요한지

  • 예를 들어, 우선순위가 낮은 상관 규칙은 24시간마다 한 번만 실행해도 충분할 수 있지만, 우선순위가 높은 상관 규칙은 15분마다 실행하도록 설정할 수 있습니다.

• 상관 규칙이 찾고자 하는 첫 번째 시그널과 마지막 시그널이 얼마나 시간적으로 떨어져 있어야 동일한 발생으로 간주되어 일치를 생성할 수 있는지

  • 참조 시그널이 조회 창 사이에 분할되지 않도록 보장하기

• 상관 규칙과 관련된 규칙이 평가하는 데이터 소스에서 예상되는 최대 지연(latency)

  • 참조 값에서 로그 소스 지연을 고려하는 것 조회 창(lookback window):

Schedule 및 조회 창(lookback window): 은 Snowflake 컴퓨트 비용에 영향을 미칠 수 있습니다. 자세한 내용은 상관 규칙 효율화하기 를 참조하세요.

시그널이 조회 창 사이에 분할되지 않도록 보장하기

조회 창을 설정할 때 필요한 시그널이 여러 상관 규칙 실행의 조회 창에 걸쳐 분할되어 검색되지 않는 일이 발생하지 않도록 구성하는 것이 권장됩니다.

피해야 할 상황의 예

우리가 피하려는 상황을 설명하기 위해, 다음의 단순화된 상관 규칙 구성을 고려해 보세요:

 # 잘못된 예; 복제하지 마세요
 - Group:
    - RuleID: First.Rule
    - RuleID: Second.Rule
    - RuleID: Third.Rule
   Schedule:
     RateMinutes: 60
   LookbackWindowMinutes: 90

이 시나리오에서 상관 규칙은 매 시간마다 이전 90분을 조회하여 그룹에 포함된 세 규칙의 시그널을 찾습니다. Group. 각 규칙이 아래 시간에 일치/시그널을 생성했다고 가정해 보겠습니다:

• 시그널: First.Rule 가 12:58 PM에 생성됨

• 시그널: Second.Rule 가 1:05 PM에 생성됨

• 시그널: Third.Rule 가 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)에 생성되었다면 상관 규칙이 일치할 것으로 기대했을 가능성이 큽니다. 그러나 필요 시그널 세 개가 단일 상관 규칙 실행의 조회 창 내에서 모두 발견되지 않았기 때문에 일치가 생성되지 않았습니다.

상관 규칙이 일치하기 위해 필요한 시그널이 서로 다른 실행으로 분할되지 않도록(즉 동일한 조회 창에 포함되도록) 하려면 먼저 첫 번째와 마지막 시그널이 얼마나 시간적으로 떨어져 있어야 동일한 발생으로 간주될지를 결정하세요. 편의상 이 값을 “최대 시그널 기간(분)”이라고 부르겠습니다.

(이 값은 WithinTimeFrameMinutes와 혼동해서는 안 됩니다. 이는 시퀀스의 두 단계가 통과하기 위해 발생해야 하는 시간 프레임입니다. “최대 시그널 기간(분)”과 WithinTimeFrameMinutes 는 상관 규칙이 시퀀스이고 두 단계만 지정된 경우 동일할 수 있습니다.)

다음 공식을 사용하면 모든 가능한 길이 "최대 시그널 기간(분)"의 윈도우가 적어도 한 번의 상관 규칙 실행 내에 포함되도록 조회 창(lookback window): 값을 구성하는 것이 권장됩니다. 일반적으로 다음 공식으로 가능합니 다:

• 다중 시리즈: 각기 다른 색의 여러 선으로 표현되는 RateMinutes <= "최대 시그널 기간(분)":

  • 조회 창(lookback window): = 2 x "최대 시그널 기간(분)" + 로그 수집 지연

• 다중 시리즈: 각기 다른 색의 여러 선으로 표현되는 RateMinutes > "최대 시그널 기간(분)":

  • 조회 창(lookback window): = "최대 시그널 기간(분)" + RateMinutes + 로그 수집 지연

로그 수집 지연의 포함 이유를 이해하려면 다음을 참조하세요 값에서 로그 소스 지연을 고려하는 것 조회 창(lookback window):

값에서 로그 소스 지연을 고려하는 것 조회 창(lookback window):

로그 수집 지연은 상관 규칙과 관련된 규칙이 평가하는 데이터 소스에서 예상되는 최대 지연입니다.

시그널은 관련 이벤트가 발생한 시간(p_event_time), 찾아지지 —Panther에 이벤트가 수집된 시간(p_parse_time)이 아니라 발생 시간 기준으로 조회 창 내에서 가져오므로 조회 창을 결정할 때 수집 지연을 고려해야 합니다. 조회 창(lookback window): 이는 상관 규칙이 마지막으로 실행된 이후의 모든 “새로운” 데이터를 처리하고 있는지 확인하기 위함입니다.

예를 들어 상관 규칙을 매시간 실행하도록 구성한 경우(예: RateMinutes 를 60로 설정하여) 상관 규칙과 관련된 규칙이 처리하는 로그의 소스가 Panther로 로그 전달을 최대 3시간 지연할 수 있다고 명시한다면, 조회 창(lookback window): 를 60 + 3*60또는 240를 설정할 수 있습니다. 이를 더 설명하면, 3시간 수집 지연 때문에 Panther에서 9:01am에 수신된 데이터는 9:01am 에 대해 p_event_time 최소 6:01am만큼 이른 발생 시간을 가질 수 있습니다. 상관 규칙이 매시간 정각에 실행된다면,10:00am 6:01am.

최소한

이전까지 조회해야 할 것입니다. 조회 창(lookback window): 이벤트 중복 제거 조회 창(lookback window): 상관 규칙의 중복 제거 기간은

필드의 값입니다. 이는 동일한 시간 프레임 내의 겹치는 상관 규칙이 해당 상관 규칙이 일치하게 만든 고유한 이벤트만 포함한다는 것을 의미합니다., 상관 규칙에서 참조된 개별 규칙 및 예약 규칙에 설정된 중복 제거(dedup() 또는, 임계값DedupPeriodMinutes

로 설정하거나 콘솔에서 설정한)는 상관 규칙에는 적용되지 않습니다.

상관 규칙 오류

• 상관 규칙 작업 중 다음 오류 중 하나를 받을 수 있습니다:Simple Detections 오류 코드

• : 상관 규칙을 구성하는 데 잘못된 구문을 사용했습니다Detection 오류

• : 상관 규칙 실행에 실패했습니다시스템 오류 조회 창(lookback window): : 상관 규칙이 시간 초과되었습니다(대개 너무 큰

값 때문일 가능성이 높음)

그룹 상관 규칙 시그널 그룹 상관 규칙은 특정 조회 창 내에서 발생해야 하는(또는 시그널의 부재가 있어야 하는) 규칙 모음을 정의합니다. 시그널은 어떤 순서로든 발생할 수 있습니다.

이벤트들이 특정 순서로 발생하기를 원한다면 시퀀스 상관 규칙 을 사용하세요.

MatchCriteria

그룹 상관 규칙에서 MatchCriteria 키는 각 규칙, 예약 규칙 및 상관 규칙에 대해 일치해야 하는 필드를 정의합니다.

여러 로그 유형, 예약 규칙 또는 상관 규칙에 연결된 규칙의 경우 오직 탭은 각 선언된 요약 속성에 대해 상위 다섯 개 속성을 표시합니다. 필드들 만 일치시킬 수 있습니다. (하나의 로그 유형에만 연결된 규칙의 경우에는 어떤 필드든 일치시킬 수 있습니다.)

MatchCriteria가 정의되지 않으면 특정 이벤트 필드 값이 일치해야 한다는 요구사항이 없으므로 상관 규칙의 특이성이 낮아집니다.

에 대해 자세히 알아보세요 MatchCriteria )를 가진 결과 집합을 생성한 후 상관 규칙 참조.

MinMatchCount

그룹 상관 규칙에서, MinMatchCount 는 선택적 필드로서 이 상관 규칙이 통과하려면(일치하려면) 일치해야 하는 개별 규칙, 예약 규칙 또는 상관 규칙(에서 정의된)의 최소 개수를 지정합니다. Group예를 들어, 다섯 개의 규칙을

내에 나열하고 Group MinMatchCount: 2 를 추가하면, 다섯 규칙 중 어느 두 규칙이라도 시그널을 생성하면 상관 규칙이 일치합니다.는 또한

MinMatchCount 에 정의된 개별 규칙에서 사용할 수 있는 필드입니다. 두 필드가 함께 사용된 예시는 GroupMinMatchCount가 있는 그룹 예시 그룹 예시들아래를 참조하세요.

아래 예시는 다음 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": "San Francisco, California in United States"
      "p_event_time": "2023-12-08 10:27:03.623000000",
    }
  },
  {
    "event_type": "failed_login",
    "p_event_time": "2023-12-08 10:27:03.496000000",
    "p_event_time": "2023-12-08 10:27:03.861000000",
    "ip": "136.24.229.58",
      "geolocation": "San Francisco, California in United States"
      "p_event_time": "2023-12-08 10:27:03.623000000",
    }
  },
  {
    "event_type": "failed_login",
    "p_event_time": "2023-12-08 10:27:03.496000000",
    "p_rule_id": "Okta.Login.Success",
    "ip": "136.24.229.58",
      "geolocation": "San Francisco, California in United States"
      "p_event_time": "2023-12-08 10:27:03.623000000",
    }
  },
  {
    "event_type": "successful_login",
    "p_event_time": "2023-12-08 10:27:54.317000000",
    "p_rule_id": "AWS.Console.RootLogin",
    "ip": "136.24.229.58",
      "geolocation": "San Francisco, California in United States"
      "p_event_time": "2023-12-08 10:27:03.623000000",
    }
  },
  {
    "eventType": "AwsApiCall",
    "p_event_time": "2023-12-08 10:30:13.274000000",
    "sourceIPAddress": "136.24.229.58"
    "ip": "136.24.229.58",
      MatchCriteria가 있는 그룹
    }
  }
]

이 예시에서,

는 네 규칙 모두의 MatchCriteria IP 필드가 동일한 값을 가져야 함을 지정합니다. - ID: &failed_login Failed Login

탐지:
  - Group:
      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 
        MatchCriteria:
        Absence: true
    ip:
      - GroupID: *failed_login
        Match: p_alert_context.ip
          - GroupID: *successful_login
        - GroupID: *root_access
          - GroupID: *successful_login
        Match: p_alert_context.sourceIPAddress
          - GroupID: *missing_crowdstrike
        Match: p_any_ip_addresses
          EventEvaluationOrder: Chronological
    LookbackWindowMinutes: 60
    RateMinutes: 30
    Schedule:
      TimeoutMinutes: 7
      MatchCriteria 없는 그룹

이 예시에서, 처음 세 규칙에 대한 시그널이 발견되었지만

이 예시에서,

키 내에 정의된 규칙의 순서로 정의됩니다.

규칙들이 모두 시그널(또는 부재)을 가지기만 하면 일치하도록 하고 특정 순서를 요구하지 않으려면 시그널 그룹 상관 규칙

을 사용하세요. 전환(Transitions) 시퀀스 내에서 전환을 선택적으로 정의할 수 있습니다. 전환은 시퀀스의 한 단계에서 다음 단계로 이동하는 방법에 대한 추가 기준(단계 사이에 허용되는 시간 및 어떤 이벤트 필드가 일치해야 하는지 등)을 정의합니다.

및/또는 Match 을 사용하세요.

를 사용하면 상관 규칙의 특이성이 높아집니다.

전환이 정의된 경우, 를 사용하면 상관 규칙의 특이성이 높아집니다. 와(과) 함께 사용하면 유용합니다 WithinTimeFrameMinutes 에 포함된 규칙 수보다 전환 수는 하나 적어야 합니다. 또한 내 항목은 목록과 같은 순서여야 합니다.

현재 상관 규칙당 일치시킬 수 있는 필드 유형은 하나만 가능합니다(예: IP 주소 필드 또는 이메일 주소 필드). 여러 로그 유형, 예약 규칙 또는 상관 규칙에 연결된 규칙의 경우 오직 전환(Transitions)에 대해 자세히 알아보세요 를 사용하면 상관 규칙의 특이성이 높아집니다. 시퀀스 예시 전환(Transitions) 전환 및 Match가 있는 시퀀스

내에서 모든 를 사용하는 것은 값이 일치해야 하는 이벤트 필드를 정의하려는 경우에 유용합니다. 모든 - Sequence: 탭은 각 선언된 요약 속성에 대해 상위 다섯 개 속성을 표시합니다. 필드들 만 일치시킬 수 있습니다. (하나의 로그 유형에만 연결된 규칙의 경우에는 어떤 필드든 일치시킬 수 있습니다.)

- ID: Failed Login 상관 규칙 참조.

- ID: Successful Login

예시 이벤트

이 샘플 이벤트들은 가독성을 위해 필드의 하위 집합을 포함합니다.

"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": "San Francisco, California in United States"
      "p_event_time": "2023-12-08 10:27:03.623000000",
    }
  },
  {
    "event_type": "failed_login",
    "p_event_time": "2023-12-08 10:27:03.496000000",
    "p_event_time": "2023-12-08 10:27:03.861000000",
    "ip": "136.24.229.58",
      "geolocation": "San Francisco, California in United States"
      "p_event_time": "2023-12-08 10:27:03.623000000",
    }
  },
  {
    "event_type": "failed_login",
    "p_event_time": "2023-12-08 10:27:03.496000000",
    "p_rule_id": "Okta.Login.Success",
    "ip": "136.24.229.58",
      "geolocation": "San Francisco, California in United States"
      "p_event_time": "2023-12-08 10:27:03.623000000",
    }
  },
  {
    "event_type": "successful_login",
    "p_event_time": "2023-12-08 10:27:54.317000000",
    "p_rule_id": "AWS.Console.RootLogin",
    "ip": "136.24.229.58",
      "geolocation": "San Francisco, California in United States"
      "p_event_time": "2023-12-08 10:27:03.623000000",
    }
  },
  {
    "eventType": "AwsApiCall",
    "p_event_time": "2023-12-08 10:30:13.274000000",
    "sourceIPAddress": "136.24.229.58"
    "ip": "136.24.229.58",
      MatchCriteria가 있는 그룹
    }
  }
]

MinMatchCount: 1

- ID: Root Login 를 사용하면 상관 규칙의 특이성이 높아집니다. 와(과) 함께 사용하면 유용합니다 내 항목은 - ID: Missing Crowdstrike 전환(Transitions) Transitions:

탐지:
  - ID: Brute Force Login Success
      From: Failed Login
        MinMatchCount: 7
        - ID: &successful_login Successful Login
      To: Successful Login
        - ID: &root_access Root Access
        WithinTimeFrameMinutes: 10
      Match:
        - ID: &missing_crowdstrike Missing Crowdstrike
        WithinTimeFrameMinutes: 10
      - On: client.ipAddress 
        MatchCriteria:
        Absence: true
    - ID: Gained Root Access
      From: Successful Login
        To: Root Login
        - From: client.ipAddress
        To: p_alert_context.sourceIPAddress
        - ID: Absence of Crowdstrike
          From: Root Login
      To: Missing Crowdstrike
        - From: p_alert_context.sourceIPAddress
        To: p_any_ip_addresses
        - ID: Absence of Crowdstrike
          전환은 있으나 Match가 없는 시퀀스
            는 없지만
      은(는) 두 단계가 발생해야 하는 시간 프레임만 지정하려는 경우에 유용합니다.
        WithinTimeFrameMinutes: 10 # 시간 프레임 정의
        전환이 없는 시퀀스
        - ID: Absence of Crowdstrike
          이벤트 필드 일치나 단계가 발생해야 하는 시간 프레임을 지정하고 싶지 않다면
            내에서
    RateMinutes: 30
    LookbackWindowMinutes: 60
    Schedule:
      TimeoutMinutes: 7
      MinMatchCount가 있는 그룹

를 생략할 수 있습니다.

단위 테스트는 Panther 콘솔의

필드에서 상관 규칙에 정의되며, 규칙이나 정책의

단위 테스트와 유사한 구조를 가집니다. 상관 규칙에서 일치가 발생하면 어떤 일이 발생하는가).

각 상관 규칙의 단위 테스트는 반드시

ExpectedResult RuleOutputs 필드를 포함해야 합니다. 단위 테스트의 YAML 구조와 값을 구성하는 방법에 대해 자세히 알아보려면 상관 규칙 참조의 해당 항목을 확인하세요. 상관 규칙에 대한 테스트를 작성한 후 다음 명령을 사용하여 테스트를 실행할 수 있습니다..

. 상관 규칙에 대해 이름(Name), 를 실행하려면 API 토큰이 필요합니다 — 자세한 내용은 및 를 참조하세요. 단위 테스트 예시 를 참조하세요. 다음 상관 규칙을 사용: - ID: OktaLoginFailure.

RuleID: Okta.Login.Failure Panther 분석 도구 테스트 MinMatchCount: 10- ID: OktaLoginSuccess pat test - ID: RootLogin API 토큰으로 인증하기 를 참조하세요.

- ID: Okta Brute Force Login

From: OktaLoginFailure

- ID: Brute Force Login Success
    To: OktaLoginSuccess
      - ID: AWS Root Login
      From: OktaLoginSuccess
    To: RootLogin
      - ID: &root_access Root Access
      WithinTimeFrameMinutes: 10
    To: srcIpAddress7
      - ID: &missing_crowdstrike Missing Crowdstrike
      WithinTimeFrameMinutes: 10
  
  - ID: Gained Root Access
    RateMinutes: 15
      TimeoutMinutes: 2
      다음과 같은 테스트를 작성할 수 있습니다:
      To: p_alert_context.sourceIPAddress
      - ID: Absence of Crowdstrike
        From: Root Login
    다음 테스트들이 규칙의 YAML 파일에 포함되어 있다면(CLI 워크플로우에서 탐지를 관리할 때 요구되는 대로), 이들은
      아래에 위치합니다.
      절대 타임스탬프를 사용하는 테스트
      - ID: Absence of Crowdstrike
        전환은 있으나 Match가 없는 시퀀스
          열 번의 로그인 시도가 있고 그 뒤에 성공 로그인과 루트 로그인이 있는 경우, 상관 규칙은
  
  Schedule:
    true
    를 반환할 것으로 예상됩니다. 이 테스트는 절대 타임스탬프를 사용합니다 — 절대 타임스탬프 사용 방법에 대해 더 알아보세요.
  
  RateMinutes: 30

Name: Successful Login with Timestamps

ExpectedResult: true 값을 구성하는 방법에 대해 자세히 알아보려면 상관 규칙 참조의 해당 항목을 확인하세요. 시퀀스 내에서 전환을 선택적으로 정의할 수 있습니다. 전환은 시퀀스의 한 단계에서 다음 단계로 이동하는 방법에 대한 추가 기준(단계 사이에 허용되는 시간 및 어떤 이벤트 필드가 일치해야 하는지 등)을 정의합니다.

RuleOutputs:

Matches: client.ipAddress:# 원래 규칙의 MinMatchCount가 10이므로 최소 10개의 타임스탬프가 필요합니다 - ID: OktaLoginFailure.

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"]
123.123.123.123: ["2006-01-02T15:04:15Z"]
srcIpAddress7:
  To: OktaLoginSuccess
    123.123.123.123: ["2006-01-02T15:04:16Z"]
      상대 타임스탬프를 사용하는 테스트
      이 테스트는 상대 타임스탬프를 사용합니다 — 상대 타임스탬프 사용 방법에 대해 더 알아보세요.
        Name: Successful Login with Relative Minutes
  To: RootLogin
    123.123.123.123: ["2006-01-02T15:04:16Z"]
      상대 타임스탬프를 사용하는 테스트
        ExpectedResult: false
  To: srcIpAddress7
    123.123.123.123: ["2006-01-02T15:04:16Z"]
      이 테스트는 규칙이
        를 평가할 것으로 예상합니다.

왜냐하면 성공 이전의 로그인 시도가

Name: Nine Login Failures Before Success

이벤트 필드 매칭을 사용하는 경우:

• 이전

  • Match.On

  • 의 값은 다음 를 사용하면 상관 규칙의 특이성이 높아집니다. Match.From 전환(Transitions) 필드에 붙여넣으세요.

• 과 일치해야 하며

  • 다음 Match.To/와 일치해야 합니다. 여러 로그 유형, 예약 규칙 또는 상관 규칙에 연결된 규칙의 경우, Match.To/MatchCriteria.Match 차트가 있습니다.

  • 의 값은 Match.To/와 일치해야 합니다./MatchCriteria.Match 또는 에 나열된 필드 중 하나여야 합니다. 표준 필드 탭은 각 선언된 요약 속성에 대해 상위 다섯 개 속성을 표시합니다. 상관 규칙 전체에서 일치시킬 수 있는 필드 유형은 하나뿐입니다. 예를 들어 IP 주소만 일치시킬 수 있거나 이메일 주소만 일치시킬 수 있습니다. 다음 단계의 값이 일치하지 않는 경우를 위해 이벤트 필드 매칭을 사용하는 것은 불가능합니다. 예를 들어 상관 규칙의 한 단계의 IP 주소가 다음 단계의 IP 주소와 일치하지 않을 때 상관 규칙이 통과하도록 하는 것은 불가능합니다..

  • 상관 규칙 생성 방법

  • 상관 규칙은 Panther 콘솔에서 또는 로컬에서 작성할 수 있습니다. 상관 규칙을 구성하는 YAML 키에 대한 설명은

를 참조하세요.

사용자 정의 상관 규칙을 생성하는 것 외에도, 다음을 활용할 수 있습니다 상관 규칙 참조.

Panther에서 제공하는 규칙 Panther 관리 상관 규칙이는 리포지토리의 correlation_rules panther-analysis 디렉터리에서 사용할 수 있습니다.

콘솔의 흐름도 시각화 도구 사용하기

Panther 콘솔에서 상관 규칙 작업 중 흐름도 시각화 도구를 사용할 수 있습니다. 이는 YAML로 상관 규칙을 구성하는 동안 규칙을 시각적으로 렌더링하고 UI가 규칙에 대해 즉시 유효성 검사를 제공하도록 합니다.

콘솔에서 YAML로 상관 규칙 생성하기

Panther 콘솔에서 상관 규칙을 생성하려면 탐지 목록 보기에서 탐지를 선택하여 YAML을 생성하거나 직접 YAML을 구성할 수 있습니다.

규칙 선택 및 YAML 생성

1. Panther 콘솔의 왼쪽 탐색 바에서 다음을 클릭합니다 탐지(Detections).

2. 탐지 목록에서 상관 규칙에 포함하려는 각 탐지의 왼쪽에 있는 체크박스를 클릭하세요.

   • 탐지를 클릭한 순서가 생성된 시퀀스 상관 규칙의 순서가 됩니다.

3. 클릭 상관관계.

4. 탐지 생성 페이지에서 상관 규칙 구성을 마치십시오:

   • 이름(Name): 상관 규칙에 대한 설명명을 입력하세요.

   • ID (선택 사항): 펜 아이콘을 클릭하고 상관 규칙에 대한 고유 ID를 입력하세요.

   • 오른쪽 상단에서 Enabled 토글은 다음으로 설정됩니다 ON 기본적으로. 규칙을 비활성화하려면 토글을 OFF.

   • 아래의 YAML 편집기 탭:

     • 원하면 생성된 상관 규칙을 수정하세요. 규칙은 기본적으로:

       • 입니다 전환(Transitions) 상관 규칙의 순서가 됩니다.

         • 클릭하여 이것을 변경할 수 있습니다 Group 을(를) 클릭하여 규칙을 그룹으로 구성. 자세한 내용은 콘솔에서 시퀀스와 그룹 전환.

       • 다음을 설정합니다 MinMatchCount 를 1 상관 규칙에 포함된 모든 규칙 및 예약 규칙에 대해.

       • 내부의 를 사용하면 상관 규칙의 특이성이 높아집니다.에서, 각 전환에 대해 Match.To 다음으로 설정합니다 p_any_usernames.

         • 다음을 업데이트할 수 있습니다 Match.To 값들이나, 대신에 MatchCriteria.Match 및 와 일치해야 합니다..

       • 다음을 설정합니다 Schedule.RateMinutes 를 15 및 Schedule.TimeoutMinutes 를 2.

       • 다음을 설정합니다 조회 창(lookback window): 를 60.

     • 상관 탐지 YAML 구문에 대한 자세한 정보는 상관 규칙 참조에서 찾을 수 있으며 필수 및 선택 필드 전체 목록을 포함합니다.

   • 아래의 경보 설정 탭:

     • 내부의 기본 탭에서 다음 필드를 구성하세요:

       • 경보 생성: 이 ON/OFF 토글은 일치 항목이 있을 때 경보 가 생성되어야 하는지, 또는 단지 신호만 생성되어야 하는지를 나타냅니다,.

       • (해당되는 경우에만 경보 생성 가 ON) 심각도: 다음을 선택하세요 심각도 수준 이 탐지로 인해 생성된 경보에 대해 적용됩니다.

       • (해당되는 경우에만 경보 생성 가 ON) 대상 재정의: 선택적으로 심각도와 무관하게 이 탐지의 경보를 받을 대상을 선택하세요.

       
     • (해당되는 경우에만 경보 생성 가 ON) 내부의 컨텍스트 하위 탭에서 선택적으로 다음 필드의 값을 제공하세요:

       • 설명: 규칙에 대한 추가 컨텍스트를 입력하세요.

       • 런북: 이 규칙과 관련된 절차와 운영을 입력하세요.

         • 자세한 내용은 경보 런북.

         • 에서 더 알아보세요. 설명적인 런북을 제공하는 것이 권장됩니다, 왜냐하면 Panther AI 경보 분류 가 이를 고려하기 때문입니다.

       • 참조: 이 규칙과 관련된 추가 정보로 연결되는 외부 링크를 입력하세요.

       • 요약 속성: 이 탐지로 인해 생성된 경보에서 보여주고 싶은 속성을 입력하세요.

         • 중첩된 필드를 요약 속성으로 사용하려면 Summary Attribute 필드에서 Snowflake 점 표기법을 사용하여 JSON 객체의 경로를 탐색하세요:

           <column>:<level1_element>.<level2_element>.<level3_element>

           그런 다음 경보 요약은 경보에서 참조된 객체에 대해 생성됩니다. Snowflake에서 반구조화된 데이터를 탐색하는 방법에 대해 자세히 알아보세요.

         • 경보 요약에 대한 자세한 내용은 경보 할당 및 관리.

       • 태그: 규칙을 한눈에 이해하는 데 도움이 되는 사용자 지정 태그를 입력하세요 (예: HIPAA.)

       • 위의 프레임워크 매핑 섹션:

         1. 클릭 새로 추가 를 클릭하여 보고서를 입력하세요.

         2. 다음 필드에 값을 제공하세요:

            • 보고서 키: 보고서와 관련된 키를 입력하세요.

            • 보고서 값: 해당 보고서의 값을 입력하세요.

   • 아래의 RuleOutputs 탭에서 선택적으로 테스트를 추가하세요:

     1. 클릭 + 새 단위 테스트 추가.

        • 이 상관 규칙에 대한 테스트의 기본 코드가 채워집니다.

     2. 채워진 텍스트를 필요한 대로 조정하고 테스트의 나머지 부분(특히 일치 항목.

     3. 코드 편집기 아래에서, 테스트 실행 을 클릭하여 테스트를 평가하세요.

5. 오른쪽 상단에서 배포.

처음부터 YAML 작성

콘솔에서 시퀀스와 그룹 전환

시퀀스를 그룹으로, 또는 그 반대로 전환하려면 콘솔의 규칙을 그룹/시퀀스로 구성 버튼을 사용하세요, YAML 편집기 패널의 오른쪽 상단에 있습니다.

상관 규칙이 이미 시퀀스이고 당신이 클릭하면 규칙을 그룹으로 구성:

• 를 입력하세요 전환(Transitions) 키는 다음으로 변경됩니다 Group.

• 를 입력하세요 를 사용하면 상관 규칙의 특이성이 높아집니다. 섹션이 제거됩니다.

• A MatchCriteria 섹션이 추가됩니다.

  • 이전에 MatchCriteria 섹션을 편집한 적이 있다면 해당 버전이 추가됩니다. 그렇지 않으면 기본 MatchCriteria 섹션이 제공됩니다.

상관 규칙이 이미 그룹이고 당신이 클릭하면 규칙을 시퀀스로 구성:

• 를 입력하세요 Group 키는 다음으로 변경됩니다 전환(Transitions).

• 를 입력하세요 MatchCriteria 섹션이 제거됩니다.

• A 를 사용하면 상관 규칙의 특이성이 높아집니다. 섹션이 추가됩니다.

  • 이전에 를 사용하면 상관 규칙의 특이성이 높아집니다. 섹션을 편집한 적이 있다면 해당 버전이 추가됩니다. 그렇지 않으면 기본 를 사용하면 상관 규칙의 특이성이 높아집니다. 섹션이 제공됩니다.

CLI 워크플로우에서 YAML로 상관 규칙 생성

지침 확장

Correlations 탐지를 로컬에서 작성하는 경우(콘솔이 아닌), 로컬 탐지 파일을 GitHub나 GitLab과 같은 버전 관리 시스템에서 관리하는 것을 권장합니다.

폴더 설정

상관 규칙을 폴더로 그룹화하는 경우 각 폴더 이름에 규칙 가 포함되어야 업로드(콘솔의 PAT 또는 일괄 업로더 사용 시) 중에 찾아집니다.

파일 설정

각 상관 규칙은 다음으로 구성됩니다:

• YAML 명세 파일(확장자가 .yml 인 파일)로 탐지 로직과 탐지의 메타데이터 속성을 포함합니다.

상관 탐지 YAML 구문에 대한 자세한 정보는 상관 규칙 참조에서 찾을 수 있으며 필수 및 선택 필드 전체 목록을 포함합니다.

• 아래의 템플릿(최상위 키 포함)을 사용하여 YAML 파일(예:my_new_correlation_rule.yml 는 )을 생성하세요:

  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: Brute Force Login Success
        From: Failed Login
          RuleID: Okta.Login.Fail
          - ID: &successful_login Successful Login
        To: Successful Login
          - ID: &root_access Root Access
          WithinTimeFrameMinutes: 10
      LookbackWindowMinutes: 15
      Schedule:
        RateMinutes: 5
        MinMatchCount가 있는 그룹
  Tests:
    - Name: 일치 항목이 없으면 규칙은 false를 반환해야 함
      목록의 규칙 순서와 일치해야 합니다.
      srcIpAddress7:
        From: Failed Login
          Matches: {} # 빈 매핑은 일치 항목이 없음을 의미함

이 규칙이 Panther에 업로드되면 콘솔에서 볼 수 있습니다.

상관 규칙 전체 예시

유출된 GitHub 자격증명 탐지

이 Discovering.Exfiltrated.Credentials 상관 규칙은 마지막 10분 동안 신호만 생성되어야 하는지를 나타냅니다, 가 있었는지 확인하기 위해 10분마다 확인합니다 AWS.CloudTrail.IaaS 규칙(아래 두 번째 탭에 정의됨) 찾아지지 다음으로 이어지는 신호가 있었는지 GitHub.CICD 규칙(아래 세 번째 탭에 정의됨).

유출된 자격증명 탐지

AnalysisType: correlation_rule
RuleID: 'Discovering.Exfiltrated.Credentials'
DisplayName: 'Discovering.Exfiltrated.Credentials'
Enabled: true
Severity: High
Description: >
  적어도 하나의 IaaS 활동 일치가 있었고 10분 이내에 CI/CD 활동으로 이어지지 않았습니다. 
  10분 이내에. 
탐지:
  - ID: Brute Force Login Success
      - ID: IaaS 활동
        RuleID: AWS.CloudTrail.IaaS
      - ID: CICD 활동
        RuleID: Github.CICD
        Absence: true
    - ID: Gained Root Access 
      - From: IaaS 활동
        To: CICD 활동
        To: p_alert_context.sourceIPAddress
    Schedule:
      RateMinutes: 10
      MinMatchCount가 있는 그룹
Tests:
  - Name: CICD 활동 없이 발생한 IaaS 활동
    123.123.123.123: ["2006-01-02T15:04:15Z"]
    srcIpAddress7:
      - ID: IaaS 활동
        123.123.123.123: ["2006-01-02T15:04:16Z"]
          username: 
            my_username: [1]
  - Name: CICD 활동과 함께한 IaaS 활동
    목록의 규칙 순서와 일치해야 합니다.
    srcIpAddress7:
      - ID: IaaS 활동
        123.123.123.123: ["2006-01-02T15:04:16Z"]
          username: 
            my_username: [1]
      - ID: CICD 활동
        123.123.123.123: ["2006-01-02T15:04:16Z"]
          username: 
            my_username: [2]

AWS.CloudTrail.IaaS

GitHub.CICD

AWS 루트 로그인으로의 Okta 무차별 대입 로그인

이 Brute.Force.Login 상관 규칙은 30분마다 다음이 있었는지 확인합니다 신호만 생성되어야 하는지를 나타냅니다, 가 있었는지 확인하기 위해 10분마다 확인합니다 시퀀스의 순서는 규칙 다음에 신호가 있었는지 Standard.BruteForceByIP로부터 최소 일곱 개의 시그널이 있을 때 두 번째 탭에 정의된 규칙 다음에 신호가 있었는지 시퀀스 상관 규칙 추가 시간 프레임 및 이벤트 IP 값 일치 요구사항이 있습니다.

무차별 대입 로그인

AnalysisType: correlation_rule
RuleID: 'Brute.Force.Login'
DisplayName: 'Brute.Force.Login'
Enabled: true
Severity: High
Description: >
  최소 100개의 실패한 로그인 이후 10분 이내에 발생한 성공적인 로그인
  마지막 실패한 로그인으로부터 10분 이내에 발생했고
  그런 다음 AWS 콘솔에서의 루트 로그인. 
탐지:
  - ID: Brute Force Login Success
      From: Failed Login
        MinMatchCount: 7
        최소 일치 수: 100
      To: Successful Login
        - ID: &root_access Root Access
        WithinTimeFrameMinutes: 10
      Match:
        - ID: &missing_crowdstrike Missing Crowdstrike
        WithinTimeFrameMinutes: 10
    - ID: Gained Root Access
      From: Successful Login
        To: Root Login
        - From: client.ipAddress
        To: p_alert_context.sourceIPAddress
        - ID: Absence of Crowdstrike
          - From: p_alert_context.ip
            To: client.ipAddress
      To: Missing Crowdstrike
        - From: p_alert_context.sourceIPAddress
        To: p_any_ip_addresses
        - ID: Absence of Crowdstrike
          전환은 있으나 Match가 없는 시퀀스
            는 없지만
    RateMinutes: 30
    LookbackWindowMinutes: 60
    Schedule:
      TimeoutMinutes: 7
      MinMatchCount가 있는 그룹
Tests:
# 이 상관 규칙에 대한 추가 테스트는 위의 "단위 테스트 예시"에서 확인하세요
  - Name: 상대적 분 단위로 성공한 로그인
    123.123.123.123: ["2006-01-02T15:04:15Z"]
    srcIpAddress7:
      From: Failed Login
        123.123.123.123: ["2006-01-02T15:04:16Z"]
          상대 타임스탬프를 사용하는 테스트
          이 테스트는 상대 타임스탬프를 사용합니다 — 상대 타임스탬프 사용 방법에 대해 더 알아보세요.
            123.123.123.123: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
      To: Successful Login
        123.123.123.123: ["2006-01-02T15:04:16Z"]
          상대 타임스탬프를 사용하는 테스트
            123.123.123.123: [11]
      Match:
        123.123.123.123: ["2006-01-02T15:04:16Z"]
          이 테스트는 규칙이
            123.123.123.123: [12]

Standard.BruteForceByIP로부터 최소 일곱 개의 시그널이 있을 때

후속 보관 없이 리포지토리 보안 정책이 비활성화된 GitHub 저장소

이 Github.Repo.Security.Policy.Disabled.Without.Archival 상관 규칙은 마지막 10분 동안 신호만 생성되어야 하는지를 나타냅니다, 가 있었는지 확인하기 위해 10분마다 확인합니다 GitHub.Advanced.Security.Change 규칙 찾아지지 다음으로 이어지는 신호가 있었는지 GitHub.Repo.Archived 규칙(아래 두 번째 탭에 정의됨)이며 또한 지난 10분 내에 이벤트 필드의 p_alert_context.repo 값과 일치하는 값이 있는 경우입니다.

Github.Repo.Security.Policy.Disabled.Without.Archival

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: Brute Force Login Success
      - ID: GitHub 고급 보안 변경
        RuleID: GitHub.Advanced.Security.Change
      - ID: Github Repo Archived
        RuleID: Github.Repo.Archived
        Absence: true
    - ID: Gained Root Access
      - ID: TR1
        From: GitHub 고급 보안 변경
        To: Github Repo Archived
        To: p_alert_context.sourceIPAddress
        - ID: Absence of Crowdstrike
          - On: p_alert_context.repo
    Schedule:
      RateMinutes: 10
      MinMatchCount가 있는 그룹
Tests:
  - Name: 보관 없이 비활성화된 Github 리포지토리 보안 정책
    123.123.123.123: ["2006-01-02T15:04:15Z"]
    srcIpAddress7:
      - ID: GitHub 고급 보안 변경
        123.123.123.123: ["2006-01-02T15:04:16Z"]
          p_alert_context.repo:
            my_production_repo: [1]
  - Name: 보관과 함께 비활성화된 Github 리포지토리 보안 정책
    목록의 규칙 순서와 일치해야 합니다.
    srcIpAddress7:
      - ID: GitHub 고급 보안 변경
        123.123.123.123: ["2006-01-02T15:04:16Z"]
          p_alert_context.repo:
            my_production_repo: [1]
      - ID: Github Repo Archived
        123.123.123.123: ["2006-01-02T15:04:16Z"]
          p_alert_context.repo:
            my_production_repo: [2]

GitHub.Repo.Archived

상관 규칙 효율화하기

상관 규칙은 복잡한 패턴 인식을 사용하므로 계산 비용이 많이 들 수 있습니다. 상관 규칙과 관련된 Snowflake 비용을 줄이려면 다음 지침을 염두에 두세요.

상관 규칙을 가능한 한 적게 실행하세요

상관 규칙이 얼마나 자주 실행되는지는 해당 규칙의 Schedule 값에 의해 결정되며 비용에 큰 영향을 줄 수 있습니다. 따라서 상관 규칙이 필요 이상으로 자주 실행되지 않도록 하는 것이 권장됩니다(탐지 요구를 충족하는 범위 내에서 — 자세한 내용은 설정 Schedule을(를) 위를 참조하세요,이 필드를 구성할 때 고려사항).

상관 규칙의 실행 빈도와 비용 간 관계를 생각할 때의 일반적인 지침은: 상관 규칙이 실행되는 간격을 두 배로 늘릴 때마다(예: RateMinutes) 발생하는 비용은 절반으로 줄어든다는 것입니다.

다음으로 설정 조회 창(lookback window): 을(를) 가능한 한 낮게 설정하세요

상관 규칙이 처리하는 데이터 양은 주로 그 규칙의 조회 창(lookback window): 값에 의해 정의되며 이 데이터 양은 규칙의 처리 시간과 결과 비용에 큰 영향을 미칩니다. 따라서 상관 규칙이 처리하는 데이터 양을 줄이기 위해 해당 규칙의 조회 창(lookback window): 값을 가능한 한 낮게 설정하는 것이 권장됩니다(탐지 요구를 충족하는 범위 내에서 — 자세한 내용은 설정 조회 창(lookback window):을(를) 위를 참조하세요,이 필드를 구성할 때 고려사항).

예를 들어, 두 규칙이 각각 10분 이내에 신호를 생성했는지 식별하고 싶다고 가정해 보겠습니다 ( WithinTimeFrameMinutes를 사용). 조회 창(lookback window): 을(를) 정확히 10 로 설정하는 것은 권장되지 않지만, 안전하게 15.

만큼 낮은 값을 사용할 수 있습니다

일치 필드는 가능한 한 낮은 카디널리티를 가진 것을 선택하세요

일치 필드의 카디널리티는 상관 규칙 비용과 정(+)의 상관관계가 있습니다. 상관 규칙이 이벤트 값 일치를 사용할 경우, 어떤 필드를 일치시킬지 선택할 때 더 낮은 카디널리티를 가진 필드를 사용하는 것이 권장됩니다.

• 일치 필드의 카디널리티는 다음을 포함한 몇 가지 요인에 의해 영향을 받을 수 있습니다:

  • 필드가 가질 수 있는 가능한 값의 수 — 가능한 값이 많을수록 카디널리티가 높아집니다. 예를 들어, 만약 field_a 가 세 가지 가능한 값 중 하나를 가질 수 있다면(예:, "yellow"또는 "red""blue" ), 그러나 field_b 는 항상 두 가지 값 중 하나만 가질 수 있다면(예: 또는 "purple"), ), 그러나 "green" 예를 들어, 만약.

• 는 보다 카디널리티가 낮습니다. 또는 필드의 데이터 유형 — 일반적으로 비스칼라 데이터 유형(즉,배열 객체, )을 가진 필드는 스칼라 데이터 유형(즉,또는 문자열).

  • 불리언 email 및 숫자 )을 가진 필드보다 더 높은 카디널리티를 갖습니다. 숫자 예를 들어, 로그 스키마가username p_any_usernames 필드를 보다 카디널리티가 낮습니다. (예: 지표로 지정하여 해당필드가 둘 다를 포함하도록 한다면 p_any_usernames p_any_usernames: ["Bob Smith", "[email protected]"] email ), 그 객체 필드는 단일 값을 가지는 타입을 가진 필드보다 카디널리티가 더 높을 것입니다.