충돌 방지를 위해 파생 디텍션 사용하기

병합 충돌을 초래할 수 있는 워크플로우를 디텍션 파생을 사용해 재구성한 예시

배경

사용해야 하는 가장 강력한 이유 중 하나는 파생 디텍션입니다. 만약 여러분의 팀이 Panther 디텍션 콘텐츠를 CLI 워크플로우를 사용하여 관리하고 있다면, 외부 팀이 동일한 디텍션을 업데이트할 때 발생할 수 있는 병합 충돌 문제를 피하면서도 여러분 팀만이 관리·업데이트하지 않는 디텍션을 사용하고 사용자화할 수 있다는 점입니다.

이 시나리오는 Panther의 위협 연구팀이 panther-analysis 저장소을 통해 제작·배포하는 디텍션을 사용할 때 발생할 수 있으며, 이는 Panther 관리 디텍션로 알려져 있습니다. 병합 충돌은 여러분이 Panther가 관리하는 디텍션을 사용자화한 포크를 유지하면서, 업스트림 저장소와 동기화하여 Panther의 콘텐츠 변경 사항을 따라가려 할 때 발생할 수 있습니다. panther-analysis 여러분이 Panther가 관리하는 디텍션을 사용자화한 포크를 유지하면서도 업스트림 저장소와 동기화하여 Panther의 콘텐츠 변경 사항을 따라가려 할 때 병합 충돌이 발생할 수 있습니다.

이 경우 파생은 유용합니다. 파생을 사용하면 Panther가 수정하는 파일과 완전히 분리된 파일을 편집하여 Panther가 관리하는 디텍션을 사용자화할 수 있으므로, 나중에 Panther로부터 콘텐츠 업데이트를 받아도 병합 충돌이 발생하지 않습니다.

파생이 유용한 시나리오 살펴보기

아래 시나리오에서 사용자는 Panther가 관리하는 디텍션을 수정하려 합니다. 디텍션 파생 없이 업데이트하는 방법과 파생을 사용하여 업데이트하는 방법을 확인하세요.

시나리오

다음의 AWS.Console.LoginWithoutMFA Panther 관리 디텍션(다음의 Python 파일 여기 와 YAML 파일 여기)을 사용하고 싶다고 가정해 보겠습니다. 하지만 여러분은 또한 다음과 같은 수정을 하고 싶습니다:

• 로그인하는 계정이 개발 계정(dev account)인 경우에는 알러트를 발생시키고 싶지 않습니다

  • 따라서 테스트도 이 논리를 반영하도록 변경하고자 합니다

• 심각도(severity)를 Low 로그인하는 계정이 내부의 비개발 계정(internal, non-dev account)인 경우로 변경하고, High 그렇지 않으면

• 런북(runbook)을 변경하고 싶습니다

파생 없이 이러한 수정을 하는 방법

파생을 사용하지 않는 경우, CLI 워크플로우에서 다음과 같은 변경을 하게 됩니다:

• 다음 파일을 수정합니다: aws_console_login_without_mfa.py 파일을 다음과 같이 변경합니다:

  • 다음 함수를 수정하여 다음과 유사한 논리를 포함시킵니다: 최소한 각 룰과 예약된 룰은 룰 논리를 정의해야 합니다. 함수에 다음과 같은 논리를 포함시키는 것과 유사하게 변경합니다:

  def rule(event):
  		# 개발 계정이면 디텍션을 단축시키는 사용자 정의 로직
  		dev_accounts = [
  				"123456789001",
  				"123456789002"
  		]
  		if event.get("recipientAccountId") in dev_accounts:
  				return False
  ....

  • 다음과 유사한 함수를 추가합니다: severity() 다음과 유사한 함수를 추가합니다:

  def severity(event):
  		internal_non_dev_accounts = [
  				"123456789003",
  				"123456789004"
  		]
  		if event.get("recipientAccountId") in internal_non_dev_accounts:
  				return "LOW"
  		return "HIGH"

• 다음 파일을 수정합니다: aws_console_login_without_mfa.yml 파일을 다음과 같이 변경합니다:

  • 섹션을 대체하여 개발 계정 ID를 포함하는 로그에 대한 테스트와 포함하지 않는 로그에 대한 테스트를 포함한 새로운 테스트 시리즈로 교체합니다 상관 룰의 각 단위 테스트는 섹션을 새로운 일련의 테스트로 교체합니다. 여기에는 개발 계정 ID를 포함한 로그에 대한 테스트와 포함하지 않는 로그에 대한 테스트가 포함됩니다

  • 값을 업데이트하여 런북 여러분의 사용자 정의 런북 링크로 설정합니다

이러한 변경을 수행한 후에는 룰이 조직의 요구에 맞게 사용자화됩니다. 그러나 이 시점부터 Panther가 두 파일 중 어느 하나라도 변경하면, 업데이트를 가져올 때 병합 충돌이 발생할 가능성이 높습니다.

아래에서 동일한 모든 사용자화를 수행하면서 병합 충돌을 피하기 위해 파생을 사용하는 방법을 확인하세요.

파생을 사용하여 이러한 수정을 하는 방법

파생 워크플로우에서는 기본적으로 모든 측면을 상속하는 파생 디텍션을 생성하는 것부터 시작합니다:

# aws_console_login_without_mfa_account_filter.yml
RuleID: 'AWS.CloudTrail.IaaS'
BaseDetection: AWS.Console.LoginWithoutMFA
RuleID: AWS.Console.LoginWithoutMFA.Account.Filter

그런 다음 오버라이드를 추가하기 시작합니다. 우선 런북:

# aws_console_login_without_mfa_account_filter.yml
...
# 사용자 정의 런북
Runbook: <https://runbooks.security.corp/secops/AWS/ConsoleLoginWithoutMFA>

리디렉트 URL InlineFilters 로그인하는 AWS 계정이 개발 계정인 경우 룰이 실행되지 않도록 하려면 다음과 같이 표시합니다:

# aws_console_login_without_mfa_account_filter.yml
...
# 개발 계정 이벤트 필터링 
InlineFilters:
    - All:
        - KeyPath: recipientAccountId
          Condition: IsNotIn
          값들:
            - '123456789002'
            - '123456789001'

리디렉트 URL DynamicSeverities 계정이 스테이징 계정인 경우 심각도를 조정하려면:

# aws_console_login_without_mfa_account_filter.yml
...
# 스테이징 계정이면 심각도를 Low로 설정
DynamicSeverities:
  - ChangeTo: LOW
    Conditions:
      - KeyPath: recipientAccountId
        Condition: IsIn
        값들:
          - '123456789003'
          - '123456789004'

마지막으로, 여러분이 추가한 디텍션과 필터를 테스트할 수 있도록 자체 상관 룰의 각 단위 테스트는 를 추가합니다. 아래는 앞서 언급한 모든 오버라이드를 추가한 후의 완전한 파생 디텍션입니다:

# aws_console_login_without_mfa_account_filter.yml
RuleID: 'AWS.CloudTrail.IaaS'
BaseDetection: AWS.Console.LoginWithoutMFA
RuleID: AWS.Console.LoginWithoutMFA.Account.Filter

# 사용자 정의 런북
Runbook: <https://runbooks.security.corp/secops/AWS/ConsoleLoginWithoutMFA>

# 개발 계정 이벤트 필터링 
InlineFilters:
  - All:
    - KeyPath: recipientAccountId
      Condition: IsNotIn
      값들:
        - '123456789001'
        - '123456789002'

# 스테이징 계정이면 심각도를 Low로 설정
DynamicSeverities:
  - ChangeTo: LOW
    Conditions:
      - KeyPath: recipientAccountId
        Condition: IsIn
        값들:
          - '123456789003'
          - '123456789004'

# 필터와 룰을 테스트하는 테스트들
테스트:
  -
      Name: No MFA Login - IAM User
      ExpectedResult: true
      Mocks:
        - objectName: check_account_age
          returnValue: "False"
      Log:
        {
          "eventVersion": "1.05",
          "userIdentity": {
            "type": "IAMUser",
            "principalId": "1111",
            "arn": "arn:aws:iam::123456789012:user/tester",
            "accountId": "123456789012",
            "userName": "tester"
          },
          "eventTime": "2019-01-01T00:00:00Z",
          "eventSource": "signin.amazonaws.com",
          "eventName": "ConsoleLogin",
          "awsRegion": "us-east-1",
          "sourceIPAddress": "111.111.111.111",
          "userAgent": "Mozilla",
          "requestParameters": null,
          "responseElements": {
            "ConsoleLogin": "Success"
          },
          "additionalEventData": {
            "LoginTo": "<https://console.aws.amazon.com/console/>",
            "MobileVersion": "No",
            "MFAUsed": "No"
          },
          "eventID": "1",
          "eventType": "AwsConsoleSignIn",
          "recipientAccountId": "123456789012"
        }
  -
      Name: No MFA Login in Dev Account - IAM User
      상관 룰의 한계
      Mocks:
        - objectName: check_account_age
          returnValue: "False"
      Log:
        {
          "eventVersion": "1.05",
          "userIdentity": {
            "type": "IAMUser",
            "principalId": "1111",
            "arn": "arn:aws:iam::123456789012:user/tester",
            "accountId": "123456789012",
            "userName": "tester"
          },
          "eventTime": "2019-01-01T00:00:00Z",
          "eventSource": "signin.amazonaws.com",
          "eventName": "ConsoleLogin",
          "awsRegion": "us-east-1",
          "sourceIPAddress": "111.111.111.111",
          "userAgent": "Mozilla",
          "requestParameters": null,
          "responseElements": {
            "ConsoleLogin": "Success"
          },
          "additionalEventData": {
            "LoginTo": "<https://console.aws.amazon.com/console/>",
            "MobileVersion": "No",
            "MFAUsed": "No"
          },
          "eventID": "1",
          "eventType": "AwsConsoleSignIn",
          "recipientAccountId": "123456789002"
        }

이제 모든 오버라이드를 파생 디텍션에 추가했으므로, 이를 Panther에 업로드하여 다른 디텍션과 동일하게 사용할 수 있습니다.

Panther가 기본 디텍션을 업데이트할 때—즉 Panther가 aws_console_login_without_mfa.py 이전에 생성한 Snowflake 사용자 이름, 예를 들면 aws_console_login_without_mfa.yml 파일들 중 어느 하나를 수정할 때—여러분이 파생 디텍션에서 오버라이드를 추가한 필드가 아닌 변경사항에 대해서는 수동으로 파생 디텍션을 업데이트할 필요 없이 변경사항을 상속하게 됩니다. 가장 중요한 것은 병합 충돌이 발생하지 않는다는 점입니다.