상관 규칙(베타)

상관 규칙은 로그 간의 상관관계를 설정하고 이상을 식별하며 복잡한 공격 행동을 모델링한 다음 알러트를 생성합니다

개요

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

Panther에서 상관 룰을 사용하면 여러 로그 타입에 걸친 여러 동작을 추적할 수 있습니다. 상관 룰에서는 그룹 또는 특정 시퀀스 의 시그널 이 특정 시간 창 내에 발생해야 일치로 간주되는지를 지정한 다음 신호를 생성하고 선택적으로 알러트.

또한 부재 를 상관 룰 조건에 포함할 수 있습니다. 상관 룰의 일치는 룰 매치나 알러트가 아니라 신호에 의해 결정되기 때문에, 알러팅이 비활성화된 룰, 스케줄된 룰 및 상관 룰을 포함하는 것이 가능합니다. 알러팅이 비활성화된.

예를 들어 상관 룰이 알러트를 생성하도록 하려는 경우에 특히 유용할 수 있습니다:

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

• GitHub 리포지토리에 대해 고급 보안 설정이 비활성화되었고 이후 아카이브되지 않은 경우(아래 전체 예시 참조)

아래에서 커스텀 상관 룰을 생성하는 방법을 배우세요그리고 상관 룰을 구성하는 YAML 키에 대한 자세한 내용은 상관 룰 참조에서 확인하세요. 또한 Panther 관리형 상관 룰.

상관 룰을 사용하면 Snowflake 컴퓨트 비용이 증가할 수 있습니다. 상관 룰을 더 비용 효율적으로 만드는 방법은 상관 룰을 더 효율적으로 만드는 방법를(을) 아래에서 확인하십시오.

상관 룰 작동 방식

상관 룰은 YAML로 작성되며 이전에 생성된 룰, 스케줄된 룰및/또는 상관 룰을 참조합니다. 각 상관 룰은 스케줄에 따라 실행되며및 "룩백 윈도우(lookback window)"를 정의합니다. 즉, 룰이 과거에서 찾아야 하는 시간 범위를 의미하며 시그널 (또는 신호의 부재)를 찾습니다.

상관 룰에 다음과 같은 추가 조건을 적용할 수 있습니다:

• 특정 룰에 대해 발견되어야 하는 최소 신호 수 또는 최대값 요구

• 한 룰에서 다른 룰로 특정 이벤트 값이 일치하도록 요구(예: 모든 개별 룰의 신호가 동일한 IP 주소를 포함하도록 요구)

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

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

상관 룰의 일치는 시그널을 생성합니다. 상관 룰에 알러팅이 활성화된 경우 룰 매치가 생성되며, 이는 상관 룰의 중복 제거 구성. 여기에서 신호, 룰 매치 및 알러트의 차이에 대해 자세히 알아보세요.

상관 룰에 대해 알러트가 생성되면 상관 룰에 참조된 개별 룰, 스케줄된 룰 및 상관 룰이 자체 알러트를 생성할 수도 있고 생성하지 않을 수도 있습니다. 이는 다음에 따라 달라집니다:

• 각 개별 룰, 스케줄된 룰 및 상관 룰에 알러팅이 활성화되어 있는지 여부

• 사용자를 사용할 것이며, 개별 룰 또는 스케줄된 룰의 임계값 값 및 상관 룰의 MinMatchCount 값. 상관 룰이 알러트를 생성할 수 있지만 이를 구성하는 룰들이 알러트를 생성하지 않는 한 가지 특이한 경우는 개별 룰의 이벤트 임계값(키 개별 룰 또는 스케줄된 룰의 임계값 이(가) 설정된 경우)이 상관 룰의 상관 룰의 MinMatchCount 값보다 높고 실제 룰 매치 수가 그 사이 어딘가에 있는 경우입니다.

그룹 vs 시퀀스

상관 룰에는 두 가지 유형이 있습니다: 그룹 와 시퀀스그룹 및 시퀀스 상관 룰 모두 신호가 찾아져야 하는(또는 Enterprise 조직 찾지 않아야 하는) Absence: true).

그룹 상관 룰은 모든 룰이 신호(또는 부재)를 생성하면 신호가 발견된 순서와 상관없이 알러트를 생성합니다. 반면 시퀀스 룰은 알러트를 생성하려면 신호(또는 부재)가 특정 순서로 발견되어야 함을 정의합니다.

스케줄 및 룩백 윈도우 설정

각 상관 룰은 다음 두 가지를 정의합니다:

• 스케줄: Schedule 필드로 정의되며(이 필드는 RateMinutes 이전에 생성한 Snowflake 사용자 이름, 예를 들면 또는CronExpression

• 을 사용), 스케줄은 상관 룰이 얼마나 자주 실행되어야 하는지를 나타냅니다. 룩백 윈도우: LookbackWindowMinutes 시그널 필드로 정의되며, 룩백 윈도우는 상관 룰이 그룹 또는 시퀀스에 포함된 룰, 스케줄된 룰 또는 상관 룰에 대해 신호(또는 신호의 부재)를 찾기 위해 과거 몇 분을 살펴볼지를 지정합니다.

값을 설정할 때에는 다음 몇 가지 요소를 고려하는 것이 권장됩니다: Schedule 와 룩백 윈도우: 값

• 이 상관 룰의 일치에 대해 적시에 알림을 받는 것이 얼마나 중요한지

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

• 상관 룰이 찾으려는 첫 번째 신호와 마지막 신호 사이의 시간 간격이 동일한 발생으로 간주되어 일치로 이어질 수 있을 만큼 얼마나 떨어져 있을 수 있는지

  • 참조 신호가 룩백 윈도우 사이에 분리되지 않도록 보장하기

• 상관 룰에 연관된 룰이 평가하는 데이터 소스에서 예상되는 최대 지연(레이턴시)

  • 참조 값에서 로그 소스 지연을 고려하는 것 룩백 윈도우:

Schedule 와 룩백 윈도우: 값을 늘리면 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 는 상관 룰이 시퀀스이며 두 단계만 지정한 경우 같을 수 있습니다.)

다음 공식을 사용하여 모든 가능한 길이 "최대 신호 지속 시간(분)"의 윈도우가 적어도 한 번의 상관 룰 실행 내에 포함되도록 룩백 윈도우: 값을 구성하는 것이 권장됩니다. 일반적으로 다음 공식으로 가능합니다:

• 만약 RateMinutes <= "최대 신호 지속 시간(분)":

  • 룩백 윈도우: = 2 x "최대 신호 지속 시간(분)" + 로그 수집 지연

• 만약 RateMinutes > "최대 신호 지속 시간(분)":

  • 룩백 윈도우: = "최대 신호 지속 시간(분)" + RateMinutes + 로그 수집 지연

로그 수집 지연의 포함을 이해하려면 다음을 참조하세요: 값에서 로그 소스 지연을 고려하는 것 룩백 윈도우:

값에서 로그 소스 지연을 고려하는 것 룩백 윈도우:

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

신호는 관련 이벤트가 발생한 시간(p_event_time), Enterprise 조직 이벤트가 Panther에 수집된 시간(을 클릭하여 전송하십시오. 알러트 활동에서 수동 알러트 전달 기록을 볼 수 있습니다.)에 기반하여 룩백 윈도우 내에서 페치되므로, 룩백 윈도우: 을 결정할 때 수집 지연을 고려하여 마지막으로 상관 룰이 실행된 이후의 모든 "새로운" 데이터를 처리하고 있는지 확인해야 합니다.

예를 들어 상관 룰을 매시간 실행되도록 구성한 경우(예: RateMinutes 에서 60) 상관 룰에 연관된 룰이 처리하는 로그 소스가 Panther로의 로그 전달을 최대 3시간까지 지연할 수 있다고 명시되어 있으면, 룩백 윈도우: 에서 60 + 3*60, 또는 240을 설정할 수 있습니다. 이를 더 설명하면, 3시간의 수집 지연 때문에 Panther에서 9:01am 에 수신된 데이터는 p_event_time 최소 6:01am의 을(를) 가질 수 있습니다. 상관 룰이 매시간 정시에, 예를 들어10:00am 6:01am.

에 실행된다면 최소한

이벤트의 중복 제거 룩백 윈도우: 상관 룰의 중복 제거 기간은 룩백 윈도우: 필드의 값입니다. 이는 동일한

시간 프레임 내의 중첩된 상관 룰이 해당 상관 룰을 매치하게 만든 고유 이벤트만 포함하게 됨을 의미합니다. 상관 룰에서 참조된 개별 룰 및 스케줄된 룰에 설정된(예:, dedup(), 개별 룰 또는 스케줄된 룰의 임계값DedupPeriodMinutes

또는 콘솔에서 설정된) 중복 제거는 상관 룰에는 적용되지 않습니다.

상관 룰 오류

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

• : 상관 룰을 구성하는 데 잘못된 구문을 사용했습니다디텍션 오류

• : 상관 룰 실행에 실패했습니다시스템 오류 룩백 윈도우: : 상관 룰이 타임아웃되었습니다(대개 너무 큰

값 때문일 가능성이 높음)

그룹 상관 룰 시그널 그룹 상관 룰은 주어진 룩백 윈도우 내에서 특정 룰의 신호(또는 신호의 부재)가 발생해야 하는 룰 집합을 정의합니다. 신호는 어떤 순서로든 발생할 수 있습니다.

이 이벤트 집합이 특정 순서로 발생하기를 원하면 시퀀스 상관 룰 를 따르십시오.

MatchCriteria

그룹 상관 룰에서 MatchCriteria 키는 상관 룰이 통과하려면 개별 룰, 스케줄된 룰 및 상관 룰별로 값이 일치해야 하는 필드를 정의합니다.

여러 로그 타입, 스케줄된 룰 또는 상관 룰과 연결된 룰의 경우 오직 p_ 필드만 일치시킬 수 있습니다. (하나의 로그 타입과만 연관된 룰의 경우에는 어떤 필드든 일치시킬 수 있습니다.) 일치 기준이 정의되지 않으면 특정 이벤트 필드 값의 일치 요구가 없기 때문에 상관 룰의 특이성이 낮아집니다.

다음에 대해 자세히 알아보세요:

그룹 상관 룰에서, MatchCriteria 켜기 상관 룰 참조.

상관 룰의 MinMatchCount

는 선택적 필드로서 이 상관 룰이 매치되기 위해 매치되어야 하는 개별 룰, 스케줄된 룰 또는 상관 룰의 최소 개수를 지정합니다(이들은 상관 룰의 MinMatchCount 에 정의됩니다). Group예를 들어 만약

내에 다섯 개의 룰을 나열하고 Group 을 추가하고 MinMatchCount: 2를 설정하면, 다섯 개의 룰 중 임의의 두 개가 신호를 생성하면 상관 룰이 매치됩니다.

상관 룰의 MinMatchCount 는 또한 Group에 정의된 개별 룰에서 사용할 수 있는 필드입니다. 두 필드가 함께 사용되는 예시는 MinMatchCount가 있는 그룹 예시를(을) 아래에서 확인하십시오.

그룹 예시

아래 예시는 다음 JSON 이벤트들을 참조합니다:

예시 이벤트

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

[
  {
    "p_rule_id": "Standard.BruteForceByIP",
    "event_type": "failed_login",
    "p_event_time": "2023-12-08 10:27:03.496000000",
    "p_alert_context": {
      "ip": "136.24.229.58",
      "geolocation": "미국 캘리포니아주 샌프란시스코"
    }
  },
  {
    "p_rule_id": "Standard.BruteForceByIP",
    "event_type": "failed_login",
    "p_event_time": "2023-12-08 10:27:03.623000000",
    "p_alert_context": {
      "ip": "136.24.229.58",
      "geolocation": "미국 캘리포니아주 샌프란시스코"
    }
  },
  {
    "p_rule_id": "Standard.BruteForceByIP",
    "event_type": "failed_login",
    "p_event_time": "2023-12-08 10:27:03.861000000",
    "p_alert_context": {
      "ip": "136.24.229.58",
      "geolocation": "미국 캘리포니아주 샌프란시스코"
    }
  },
  {
    "p_rule_id": "Okta.Login.Success",
    "event_type": "successful_login",
    "p_event_time": "2023-12-08 10:27:54.317000000",
    "p_alert_context": {
      "ip": "136.24.229.58",
      "geolocation": "미국 캘리포니아주 샌프란시스코"
    }
  },
  {
    "p_rule_id": "AWS.Console.RootLogin",
    "eventType": "AwsApiCall",
    "p_event_time": "2023-12-08 10:30:13.274000000",
    "p_alert_context": {
      "sourceIPAddress": "136.24.229.58"
    }
  }
]

MatchCriteria가 있는 그룹

이 예시에서 MatchCriteria 는 네 개의 모든 룰에서 IP 필드가 동일한 값을 가져야 함을 지정합니다.

event, "data", "details", "request", "path", default="<NO_REQUEST_PATH_FOUND>"
  - Group:
      - ID: &failed_login Failed Login
        RuleID: Standard.BruteForceByIP
        MinMatchCount: 7
      - ID: &successful_login Successful Login
        RuleID: Okta.Login.Success
      - ID: &root_access Root Access
        RuleID: AWS.Console.RootLogin
      - ID: &missing_crowdstrike Missing Crowdstrike 
        RuleID: Crowdstrike.Detection.passthrough
        Absence: true
    MatchCriteria:
      ip:
        - GroupID: *failed_login
          Match: p_alert_context.ip
        - GroupID: *successful_login
          Match: p_alert_context.ip
        - GroupID: *root_access
          Match: p_alert_context.sourceIPAddress
        - GroupID: *missing_crowdstrike
          Match: p_any_ip_addresses
    EventEvaluationOrder: Chronological
    LookbackWindowMinutes: 60
    Schedule:
      RateMinutes: 30
      TimeoutMinutes: 7

MatchCriteria가 없는 그룹

MinMatchCount가 있는 그룹

내에 정의된 룰의 순서로 정의됩니다.

룰들이 단순히 모두 신호(또는 부재)를 갖는지만으로 매치되게 하고 특정 순서를 요구하지 않으려면 시그널 그룹 상관 룰

을 사용하세요. 전이(Transitions) 키.

시퀀스 내에서 선택적으로 전이를 정의할 수 있습니다. 전이는 시퀀스의 한 단계가 다음 단계로 어떻게 넘어갈 수 있는지에 대한 추가 기준을 정의하며, 단계 간 허용 시간 및 어떤 이벤트 필드가 일치해야 하는지를 포함합니다. Match 를 따르십시오.

를 사용하면 상관 룰의 특이성이 증가합니다.

전이가 정의되어 있으면 전이 수는 를 사용하면 상관 룰의 특이성이 증가합니다. 에서 생성된 검색은 WithinTimeFrameMinutes 및/또는 에 포함된 룰 수보다 하나 적어야 합니다. 또한 내의 항목들은

리스트와 동일한 순서여야 합니다. 전이(Transitions)현재 상관 룰당 일치시킬 수 있는 필드 유형은 하나뿐입니다(예: 를 사용하면 상관 룰의 특이성이 증가합니다. IP 주소 필드 또는 전이(Transitions) 이메일 주소 필드). 여러 로그 타입, 스케줄된 룰 또는 상관 룰과 연관된 룰의 경우 오직

에 대해 자세히 알아보세요: 모든 시퀀스 예시 모든 전이와 Match가 있는 시퀀스 p_ 필드만 일치시킬 수 있습니다. (하나의 로그 타입과만 연관된 룰의 경우에는 어떤 필드든 일치시킬 수 있습니다.) 일치 기준이 정의되지 않으면 특정 이벤트 필드 값의 일치 요구가 없기 때문에 상관 룰의 특이성이 낮아집니다.

내에서 상관 룰 참조.

는 값이 일치해야 하는 이벤트 필드를 정의하고자 할 때 유용합니다.

아래 예시는 다음 JSON 이벤트들을 참조합니다:

예시 이벤트

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

[
  {
    "p_rule_id": "Standard.BruteForceByIP",
    "event_type": "failed_login",
    "p_event_time": "2023-12-08 10:27:03.496000000",
    "p_alert_context": {
      "ip": "136.24.229.58",
      "geolocation": "미국 캘리포니아주 샌프란시스코"
    }
  },
  {
    "p_rule_id": "Standard.BruteForceByIP",
    "event_type": "failed_login",
    "p_event_time": "2023-12-08 10:27:03.623000000",
    "p_alert_context": {
      "ip": "136.24.229.58",
      "geolocation": "미국 캘리포니아주 샌프란시스코"
    }
  },
  {
    "p_rule_id": "Standard.BruteForceByIP",
    "event_type": "failed_login",
    "p_event_time": "2023-12-08 10:27:03.861000000",
    "p_alert_context": {
      "ip": "136.24.229.58",
      "geolocation": "미국 캘리포니아주 샌프란시스코"
    }
  },
  {
    "p_rule_id": "Okta.Login.Success",
    "event_type": "successful_login",
    "p_event_time": "2023-12-08 10:27:54.317000000",
    "p_alert_context": {
      "ip": "136.24.229.58",
      "geolocation": "미국 캘리포니아주 샌프란시스코"
    }
  },
  {
    "p_rule_id": "AWS.Console.RootLogin",
    "eventType": "AwsApiCall",
    "p_event_time": "2023-12-08 10:30:13.274000000",
    "p_alert_context": {
      "sourceIPAddress": "136.24.229.58"
    }
  }
]

- Sequence:

수신한 알러트를 조사할 때 일반적인 조사 워크플로는 다음과 같습니다: 를 사용하면 상관 룰의 특이성이 증가합니다. 에서 생성된 검색은 에 포함된 룰 수보다 하나 적어야 합니다. 또한 - ID: Failed Login 전이(Transitions) - ID: Successful Login

event, "data", "details", "request", "path", default="<NO_REQUEST_PATH_FOUND>"
  MinMatchCount: 1
      - ID: Root Login
        RuleID: Standard.BruteForceByIP
        MinMatchCount: 7
      - ID: Missing Crowdstrike
        RuleID: Okta.Login.Success
        Transitions:
      - ID: Brute Force Login Success
        RuleID: AWS.Console.RootLogin
        Transitions:
      From: Failed Login 
        RuleID: Crowdstrike.Detection.passthrough
        Absence: true
    To: Successful Login
      WithinTimeFrameMinutes: 10
        Match:
        - On: client.ipAddress
        - ID: Gained Root Access
        From: Successful Login
          To: Root Login
      - From: client.ipAddress
        To: p_alert_context.sourceIPAddress
        - ID: Absence of Crowdstrike
        From: Successful Login
          From: Root Login
            To: Missing Crowdstrike
      - From: p_alert_context.sourceIPAddress
        To: p_any_ip_addresses
        전이와 Match 없이 시퀀스
        From: Successful Login
          는 두 단계가 발생해야 하는 시간 프레임만 지정하고자 할 때 유용합니다.
            WithinTimeFrameMinutes: 10 # 시간 프레임 정의
    LookbackWindowMinutes: 60
    EventEvaluationOrder: Chronological
    Schedule:
      RateMinutes: 30
      TimeoutMinutes: 3

전이 없는 시퀀스

을(를) 생략할 수 있습니다.

단위 테스트는 Panther 콘솔의

Unit Tests 상관 룰에서 일치가 발생하면 어떤 일이 발생하는가).

탭 또는 CLI 워크플로의 최상위

Tests 필드에 상관 룰에 정의되며, 룰 또는 정책에 대한 단위 테스트와 유사한 구조로 구성됩니다. 상관 룰의 각 단위 테스트는 ExpectedResult RuleOutputs.

필드를 포함해야 합니다. 단위 테스트용 YAML 구조와 이름, 를 구성하는 방법에 대해 자세히 알아보려면 상관 룰 참조의및 부분을 참조하세요. 상관 룰에 대한 테스트를 작성한 후에는 부분을 참조하세요. 값 명령을 사용하여 테스트를 실행할 수 있습니다..

상관 룰에 대해 프로그램 방식으로 업로드할 수 있습니다 Dependabot은 종속성을 업데이트하기 위해 PR을 열 수 있습니다. 그러나 Dependabot은 리포지토리의 시크릿에 접근할 수 없습니다. 이는 API 시크릿이 필요한 GitHub 워크플로우(예: 를 실행하려면 API 토큰이 필요합니다—관련 내용은를 참조하세요. pat test 단위 테스트 예시 API 토큰으로 인증하기 을 참조하세요.

다음 상관 룰을 사용합니다:

- ID: OktaLoginFailure

MinMatchCount: 1
    RuleID: Okta.Login.Failure
      MinMatchCount: 10
      - ID: OktaLoginSuccess
    - ID: RootLogin
      RuleID: Okta.Login.Success
      Transitions:
    - ID: Okta Brute Force Login
      RuleID: AWS.Console.RootLogin
      Transitions:
  
  To: Successful Login
    From: OktaLoginFailure
      To: OktaLoginSuccess
      - ID: AWS Root Login
      - ID: Gained Root Access
      From: Successful Login
        To: Root Login
    From: OktaLoginSuccess
      To: RootLogin
      To: srcIpAddress7
      From: Successful Login
        From: Root Login
          RateMinutes: 15
  
  Schedule:
    TimeoutMinutes: 2
    다음과 같은 테스트를 작성할 수 있습니다:
  
  LookbackWindowMinutes: 60

아래 테스트들이 룰의 YAML 파일에 포함되어 있다면(CLI 워크플로에서 디텍션을 관리할 때 요구되는 것처럼) 이들은

아래에 위치하게 됩니다. 상관 룰의 각 단위 테스트는 키.

절대 타임스탬프를 사용하는 테스트

만약 10회의 로그인 시도가 성공적인 로그인 및 루트 로그인으로 이어진다면 상관 룰은 부울 값를 반환할 것으로 예상됩니다. 이 테스트는 절대 타임스탬프를 사용합니다—절대 타임스탬프 사용 방법에 대해 더 알아보세요 명령을 사용하여 테스트를 실행할 수 있습니다..

Name: Successful Login with Timestamps
ExpectedResult: true
RuleOutputs:
  RuleID: Okta.Login.Failure
    Matches:
      client.ipAddress:
      # 원래 룰의 MinMatchCount가 10이므로 적어도 10개의 타임스탬프가 필요합니다
        123.123.123.123: ["2006-01-02T15:04:05Z", "2006-01-02T15:04:06Z","2006-01-02T15:04:07Z", "2006-01-02T15:04:08Z", "2006-01-02T15:04:09Z", "2006-01-02T15:04:10Z", "2006-01-02T15:04:11Z", "2006-01-02T15:04:12Z", "2006-01-02T15:04:13Z", "2006-01-02T15:04:14Z"]
  - ID: RootLogin
    Matches:
      client.ipAddress:
        123.123.123.123: ["2006-01-02T15:04:15Z"]
  - ID: Okta Brute Force Login
    Matches:
      srcIpAddress7:
        123.123.123.123: ["2006-01-02T15:04:16Z"]

상대 타임스탬프를 사용하는 테스트

Test w/ExpectedResult: false

시퀀스가 전이를 사용하는 경우:

• 허용되는 전이 수는 시퀀스 컬렉션에 포함된 룰 수보다 하나 적습니다.

  • 항목들의 순서는

  • 리스트가 를 사용하면 상관 룰의 특이성이 증가합니다. 내 룰의 순서와 일치해야 합니다. 전이(Transitions) 필드에 붙여넣으세요.

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

  • 이전 Match.On/Match.From 의 값은 다음 Match.On/Match.To 값을 복사하세요.

  • 와 일치해야 합니다. Match.On/Match.From/Match.To 이전에 생성한 Snowflake 사용자 이름, 예를 들면 여러 로그 타입, 스케줄된 룰 또는 상관 룰과 연관된 룰의 경우, MatchCriteria.Match p_ 에 대한 값은 에 나열된 필드 중 하나여야 합니다..

  • Standard Fields

  • 상관 룰 전체에서 일치시킬 수 있는 필드 유형은 하나뿐입니다. 예를 들어 IP 주소만 일치시킬 수 있거나 이메일 주소만 일치시킬 수 있습니다.

불일치를 기반으로 이벤트 필드 매칭을 사용하는 것은 불가능합니다. 예를 들어 상관 룰의 한 단계의 IP 주소가 다음 단계의 IP 주소와 일치하지 않을 때 상관 룰이 통과하도록 하는 것은 불가능합니다.

상관 룰 생성 방법 상관 룰 참조.

상관 룰은 Panther 콘솔에서 또는 로컬에서 작성할 수 있습니다. 상관 룰을 구성하는 YAML 키에 대한 설명은 Panther 관리형 상관 룰에서 확인하세요. 커스텀 상관 룰을 생성하는 것 외에도 다음을 활용할 수 있습니다: 콘솔의 panther-analysis 저장소의

correlation_rules

디렉토리에 있는

를 활용할 수 있습니다.

콘솔의 플로우차트 시각화 도구 사용

Panther 콘솔에서 상관 룰 작업 중 플로우차트 시각화 도구를 사용할 수 있습니다. 이는 YAML로 상관 룰을 구성하는 동안 시각적으로 렌더링하며 UI는 룰에 대한 즉각적인 유효성 검사 피드백을 제공합니다.

1. Panther 콘솔의 왼쪽 탐색 창에서 디텍션.

2. 콘솔에서 YAML로 상관 룰 생성하기

   • Panther 콘솔에서 상관 룰을 생성하려면 목록 보기에서 디텍션을 선택하여 YAML을 생성하거나 직접 YAML을 구성할 수 있습니다. 시퀀스 룰 선택 및 YAML 생성

3. 를 선택하고 Panther가 설치된 계정 ID를 입력하십시오. 디텍션 목록에서 상관 룰에 포함하려는 각 디텍션의 왼쪽에 있는 체크박스를 클릭하세요..

4. 디텍션을 클릭하는 순서가 생성된

   • 이름상관 룰의 순서가 됩니다.

   • ID (선택 사항): Correlate

   • 디텍션 생성 페이지에서 상관 룰 구성을 완료하세요: 사용 : 상관 룰에 대한 설명적 이름을 입력하세요. 켜기 펜 아이콘을 클릭하여 상관 룰에 고유 ID를 입력하세요. OFF.

   • 우측 상단의 토글은 기본적으로 로 설정됩니다. 룰을 비활성화하려면 토글을

     • 로 전환하세요.

       • YAML Editor 전이(Transitions) 룰 선택 및 YAML 생성

         • 탭에서: Group 원한다면 생성된 상관 룰을 수정하세요. 기본적으로 룰은: 로 되어 있습니다.. 클릭하여 이를 콘솔에서 시퀀스와 그룹 간 전환.

       • 설정 상관 룰의 MinMatchCount 에서 1 상관 규칙에 포함된 모든 룰 및 예약된 룰에 대해.

       • 내에서 를 사용하면 상관 룰의 특이성이 증가합니다.，설정 Match.On 각 전환에 대해 p_any_usernames.

         • 다음을 업데이트할 수 있습니다 Match.On 값 또는 대신 사용 Match.To 와 Match.From.

       • 설정 Schedule.RateMinutes 에서 15 와 Schedule.TimeoutMinutes 에서 2.

       • 설정 룩백 윈도우: 에서 60.

     • 상관 디택션 YAML 문법에 대한 자세한 내용은 상관 룰 참조에서 확인할 수 있으며 필수 및 선택 필드의 전체 목록이 포함되어 있습니다.

   • 우측 상단의 알러트 설정 로 설정됩니다. 룰을 비활성화하려면 토글을

     • 내부의 기본 탭에서 다음 필드를 구성하십시오:

       • 알러트 생성: 이 ON/OFF 토글은 알러트의 여부를 나타냅니다 알러트 가 생성될지, 아니면 단지 신호.

       • (다음인 경우에만 적용됨 알러트 생성 값이 다음으로 설정되어 있습니다 켜기) 심각도: 다음에서 선택 심각도 수준 이 디텍션에 의해 트리거된 알러트에 대해.

       • (다음인 경우에만 적용됨 알러트 생성 값이 다음으로 설정되어 있습니다 켜기) 대상 재정의: 선택적으로 심각도에 관계없이 이 디텍션에 대한 알러트를 받을 대상을 선택하십시오.

       
     • (다음인 경우에만 적용됨 알러트 생성 값이 다음으로 설정되어 있습니다 켜기) 내부의 컨텍스트 하위 탭에서 선택적으로 다음 필드의 값을 제공하십시오:

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

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

         • 자세한 내용은 알러트 런북.

         • 설명적인 런북을 제공하는 것이 권장되며 Panther AI 알러트 분류 이것을 고려할 것입니다.

       • 참조: 이 룰과 관련된 더 많은 정보에 대한 외부 링크를 입력하세요.

       • 요약 속성: 이 디텍션으로 트리거된 알러트에 표시할 속성을 입력하세요.

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

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

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

         • 알러트 요약에 대한 자세한 정보는 알러트 할당 및 관리.

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

       • 일반 구성 프레임워크 매핑 이벤트 이름

         1. 를 선택하고 Panther가 설치된 계정 ID를 입력하십시오. 새로 추가 보고서를 입력하려면.

         2. 다음 필드에 대해 값을 제공하십시오:

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

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

   • 우측 상단의 필드에 상관 룰에 정의되며, 룰 또는 정책에 대한 탭에서 선택적으로 테스트를 추가하십시오:

     1. 를 선택하고 Panther가 설치된 계정 ID를 입력하십시오. + 새 단위 테스트 추가.

        • 이 상관 규칙에 대한 테스트용 보일러플레이트 코드가 채워집니다.

     2. 채워진 텍스트를 필요에 따라 조정하고, 일치 항목.

     3. 코드 편집기 아래에서 클릭 테스트 실행 테스트를 평가하려면.

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

처음부터 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):
      - 이 상관 규칙과 관련된 특정 보고서 섹션
  태그:
    - 태그
    - 이동
    - 여기
  LookupName: my_lookup_table # 고유한 표시 이름
    이 상관 규칙은 Panther CLI의 CLI 워크플로를 검증하기 위해 존재합니다
  Runbook: >
    먼저 누가 이 스펙 형식을 작성했는지 확인한 다음 피드백으로 그들에게 알리십시오.
  참조: https://www.a-clickable-link-to-more-info.com
  event, "data", "details", "request", "path", default="<NO_REQUEST_PATH_FOUND>"
    MinMatchCount: 1
        - ID: Root Login
          RuleID: Okta.Login.Fail
          MinMatchCount: 7
        - ID: Missing Crowdstrike
          RuleID: Okta.Login.Success
          Transitions:
      LookbackWindowMinutes: 15
      Schedule:
        RateMinutes: 5
        TimeoutMinutes: 3
  테스트:
    - Name: 일치 항목이 없으면 룰은 false를 반환해야 함
      상관 룰의 한계
      RuleOutputs:
        - ID: Root Login
          Matches: {} # 빈 매핑은 일치 항목이 없음을 의미

이 룰이 Panther에 업로드된 후 콘솔에서 볼 수 있습니다.

상관 규칙 전체 예제

유출된 GitHub 자격 증명 탐지

이 Discovering.Exfiltrated.Credentials 상관 규칙은 마지막 10분 동안 신호 가 있었는지 확인하기 위해 10분마다 검사합니다. AWS.CloudTrail.IaaS 룰(아래 두 번째 탭에 정의됨) Enterprise 조직 그 다음에 신호가 있었는지 GitHub.CICD 룰(아래 세 번째 탭에 정의됨)에 대해.

유출된 자격 증명 탐지

AnalysisType: correlation_rule
RuleID: 'Discovering.Exfiltrated.Credentials'
DisplayName: 'Discovering.Exfiltrated.Credentials'
Enabled: true
Severity: High
LookupName: my_lookup_table # 고유한 표시 이름
  CI/CD 활동이 10분 이내에 뒤따르지 않은 최소 하나의 IaaS 활동 일치가 있었습니다. 
  - ID: IaaS 활동 
event, "data", "details", "request", "path", default="<NO_REQUEST_PATH_FOUND>"
  MinMatchCount: 1
      RuleID: AWS.CloudTrail.IaaS
        - ID: CICD 활동
      RuleID: Github.CICD
        - From: IaaS 활동
        Absence: true
    To: Successful Login 
      To: CICD 활동
        RateMinutes: 10
        - ID: Gained Root Access
    Schedule:
      - Name: CICD 활동이 없는 IaaS 활동
      TimeoutMinutes: 3
테스트:
  username:
    ExpectedResult: true
    RuleOutputs:
      RuleID: AWS.CloudTrail.IaaS
        Matches:
          my_username: [1] 
            - Name: CICD 활동이 있는 IaaS 활동
  my_username: [2]
    상관 룰의 한계
    RuleOutputs:
      RuleID: AWS.CloudTrail.IaaS
        Matches:
          my_username: [1] 
            - Name: CICD 활동이 있는 IaaS 활동
      RuleID: Github.CICD
        Matches:
          my_username: [1] 
            AnalysisType: rule

AWS.CloudTrail.IaaS

GitHub.CICD

Brute.Force.Login

이 상관 규칙은 마지막 30분 동안 가 있었는지 확인하기 위해 30분마다 검사합니다. 신호 가 있었는지 확인하기 위해 10분마다 검사합니다. 시퀀스 상관 룰은 주어진 룩백 윈도우 내에서 특정 순서로 발생해야 하는 룰 집합을 정의합니다(또는 신호의 부재). 룰 다음에 신호가 있었는지 그리고 AWS.Console.RootLogin에서 적어도 하나의 신호가 있는 경우 룰(아래 두 번째 탭에 정의됨) 다음에 신호가 있었는지 세 룰 모두에서 신호가 있는 경우(그 중 적어도 일곱 신호가 룰, 추가 시간 프레임 및 이벤트 IP 값 일치 요구 사항과 함께.

무차별 대입 로그인

AnalysisType: correlation_rule
RuleID: 'Brute.Force.Login'
DisplayName: 'Brute.Force.Login'
Enabled: true
Severity: High
LookupName: my_lookup_table # 고유한 표시 이름
  최소 100회의 로그인 실패 후 성공적인 로그인이 있었고
  마지막 실패한 로그인으로부터 10분 이내에 발생했으며
  그런 다음 AWS 콘솔에서 루트 로그인이 있었습니다. 
event, "data", "details", "request", "path", default="<NO_REQUEST_PATH_FOUND>"
  MinMatchCount: 1
      - ID: Root Login
        RuleID: Standard.BruteForceByIP
        MinMatchCount: 100
      - ID: Missing Crowdstrike
        RuleID: Okta.Login.Success
        Transitions:
      - ID: Brute Force Login Success
        RuleID: AWS.Console.RootLogin
        Transitions:
    To: Successful Login
      WithinTimeFrameMinutes: 10
        Match:
        - On: client.ipAddress
        - ID: Gained Root Access
        From: Successful Login
          - From: p_alert_context.ip
            To: client.ipAddress
      - From: client.ipAddress
        To: p_alert_context.sourceIPAddress
        - ID: Absence of Crowdstrike
        From: Successful Login
          From: Root Login
            To: Missing Crowdstrike
    LookbackWindowMinutes: 60
    EventEvaluationOrder: Chronological
    Schedule:
      RateMinutes: 30
      TimeoutMinutes: 3
테스트:
# 이 상관 규칙에 대한 추가 테스트는 위의 "단위 테스트 예제"를 참조하십시오
  - Name: 상대적 분 단위의 성공적인 로그인
    ExpectedResult: true
    RuleOutputs:
      - ID: Root Login
        Matches:
          client.ipAddress:
          # 원래 룰의 MinMatchCount가 10이므로 적어도 10개의 타임스탬프가 필요합니다
            123.123.123.123: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
      - ID: Missing Crowdstrike
        Matches:
          client.ipAddress:
            123.123.123.123: [11]
      - ID: Brute Force Login Success
        Matches:
          srcIpAddress7:
            123.123.123.123: [12]

그리고 AWS.Console.RootLogin에서 적어도 하나의 신호가 있는 경우

GitHub 저장소 보안 정책이 비활성화된 후 보관되지 않음

이 Github.Repo.Security.Policy.Disabled.Without.Archival 상관 규칙은 마지막 10분 동안 신호 가 있었는지 확인하기 위해 10분마다 검사합니다. GitHub.Advanced.Security.Change 룰 Enterprise 조직 그 다음에 신호가 있었는지 GitHub.Repo.Archived 아래 두 번째 탭에 정의된 룰에서 또한 p_alert_context.repo 이벤트 필드에 대한 일치하는 값이 지난 10분 이내에 있는 경우.

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
태그:
  - Github
  - Repo Archived
Severity: High
event, "data", "details", "request", "path", default="<NO_REQUEST_PATH_FOUND>"
  MinMatchCount: 1
      - ID: GitHub 고급 보안 변경
        RuleID: GitHub.Advanced.Security.Change
      - ID: Github Repo Archived
        RuleID: Github.Repo.Archived
        Absence: true
    To: Successful Login
      - ID: TR1
        From: GitHub 고급 보안 변경
        To: Github Repo Archived
        - ID: Gained Root Access
        From: Successful Login
          - On: p_alert_context.repo
    Schedule:
      - Name: CICD 활동이 없는 IaaS 활동
      TimeoutMinutes: 3
테스트:
  - Name: Github Repo Security Policy Disabled Without Archival
    ExpectedResult: true
    RuleOutputs:
      - ID: GitHub 고급 보안 변경
        Matches:
          p_alert_context.repo:
            my_production_repo: [1]
  - Name: Github Repo Security Policy Disabled With Archival
    상관 룰의 한계
    RuleOutputs:
      - ID: GitHub 고급 보안 변경
        Matches:
          p_alert_context.repo:
            my_production_repo: [1]
      - ID: Github Repo Archived
        Matches:
          p_alert_context.repo:
            my_production_repo: [2]

GitHub.Repo.Archived

상관 룰을 더 효율적으로 만드는 방법

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

상관 규칙을 가능한 한 자주 실행하지 마십시오

상관 규칙이 실행되는 빈도는 해당 Schedule 값에 의해 결정되며 비용에 큰 영향을 줄 수 있습니다. 따라서 상관 규칙이 필요 이상으로 자주 실행되지 않도록(감지 요구 사항을 충족하는 범위 내에서—참조 설정 Schedule위의 , 이 필드를 구성할 때의 고려 사항).상관 규칙 실행 빈도와 비용 간의 관계에 대한 일반적인 지침은: 상관 규칙이 실행되는 간격을 두 배로 늘릴 때마다(예:

) 발생하는 비용이 절반으로 줄어듭니다. RateMinutes가능한 한 낮게

다음 값을 설정하세요 룩백 윈도우: 상관 규칙이 처리하는 데이터 양은 주로 그

값에 의해 정의되며 이 데이터 양이 처리 시간과 결과 비용의 주요 요인입니다. 상관 규칙이 처리하는 데이터 양을 줄이려면 해당 룩백 윈도우: 값을 가능한 한 낮게 설정하는 것이 권장됩니다(감지 요구 사항을 충족하는 범위 내에서—참조 룩백 윈도우: 예를 들어 두 룰이 서로 10분 이내에 신호를 생성하는 시점을 식별하려는 경우(사용하여 설정 룩백 윈도우: 위의 , 이 필드를 구성할 때의 고려 사항).상관 규칙 실행 빈도와 비용 간의 관계에 대한 일반적인 지침은: 상관 규칙이 실행되는 간격을 두 배로 늘릴 때마다(예:

). WithinTimeFrameMinutes정확히 로 설정하는 것은 권장되지 않지만 룩백 윈도우: 값을 10 만큼 낮게 안전하게 사용할 수 있습니다. 15.

가능한 한 낮은 카디널리티 필드 선택

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

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

• 해당 필드가 가질 수 있는 가능한 값의 수—가능한 값이 많을수록 카디널리티가 높아집니다.

  • 예를 들어, 만약 field_a 가 세 가지 가능한 값 중 하나를 가질 수 있다면(예: "yellow", "red", 또는 "blue"), 그러나 field_b 는 단 두 가지 값만 가질 수 있다면(예: "purple" 이전에 생성한 Snowflake 사용자 이름, 예를 들면 "green"), field_b )라면 field_a.

• field_b는 field_a보다 낮은 카디널리티를 가집니다. 배열 이전에 생성한 Snowflake 사용자 이름, 예를 들면 object필드의 데이터 타입—일반적으로 비스칼라 데이터 타입(즉, 문자열, 불리언, 또는 숫자).

  • )을 가진 필드는 스칼라 데이터 타입(즉, email 와 )을 가진 필드보다 카디널리티가 높습니다. 예를 들어, 로그 스키마가 )을 가진 필드보다 카디널리티가 높습니다. username필드를 p_any_usernames 지표로 지정하고 있어 배열 (예, 필드가 둘 다 포함하도록 하면p_any_usernames: ["Bob Smith", "[email protected]"] p_any_usernames ) 해당 email 필드는 문자열 필드보다 더 높은 카디널리티를 가지며, 후자는 단일 값을 가지는 타입입니다.