시스템 오류

Panther의 시스템 오류는 Panther 플랫폼이 예상대로 작동하지 않을 때 경고합니다

개요

Panther의 시스템 오류는 Panther 플랫폼의 일부가 예상대로 작동하지 않을 때 알러트를 발생시킵니다. 여기에는 다음이 포함됩니다:

이러한 유형의 알러트는 다음으로 분류됩니다 시스템 오류 이미 스키마를 생성한 경우 이 옵션을 선택하세요. 클릭하세요 시스템 오류 항상 다음을 갖습니다 치명적(CRITICAL) 심각도 수준—그리고 알러트 대상으로 전송됩니다 수신하도록 구성된 시스템 오류심각도 치명적(CRITICAL) 심각도의 알러트를 수신하도록 구성되어 있지 않더라도. 수동으로 구성할 수 있는 로그 중단 알람을 제외하고는 자동으로 생성됩니다. 룰 또는 예약된 룰의 Python 처리가 15초를 초과하여 실행될 때. 알러트는 Panther 콘솔의 다음 위치에서 볼 수 있습니다 알러트 및 오류 > 시스템 오류.

circle-info

다음을 수신하도록 알러트를 구성하는 것이 강력히 권장됩니다 룰 오류 및 예약된 룰 오류 다음을 수신하도록 룰 또는 예약된 룰의 Python 처리가 15초를 초과하여 실행될 때. 알러트 유형.

시스템 오류는 Panther 콘솔의 인앱 알림 유형이기도 합니다. 알림에 대해 자세히 알아보려면 알림 및 오류.

시스템 오류 알람 구성 방법

모든 유형의 시스템 오류에 대한 알러트를 받도록 하려면:

  • 다음을 수신하는 알러트 대상을 구성하십시오 룰 또는 예약된 룰의 Python 처리가 15초를 초과하여 실행될 때. 알러트 유형.

  • 데이터가 더 이상 수신되지 않을 때 알러트를 트리거하는 로그 소스에 대해 로그 중단 알람을 구성하십시오.

    • 로그 분류 오류, 알러트 전송 실패, S3 GetObject 오류 및 클라우드 보안 스캔 실패에 대해서는 알러트를 활성화할 필요가 없습니다.

시스템 오류에 대한 알러트 대상 구성

기본적으로 Panther는 시스템 오류 알러트를 다음으로 전송합니다 알러트 페이지에서 Panther 콘솔. 또한 이러한 알러트를 수신하도록 하나의 알러트 대상을 구성하는 것이 강력히 권장됩니다.

circle-info

다음을 수신하도록 구성된 알러트 대상 시스템 오류 심각도의 알러트를 수신하도록 대상이 구성되어 있지 않더라도 수신합니다 치명적(CRITICAL) 심각도.

이러한 알러트를 사용자 지정 알러트 대상으로 전송되도록 보장하려면 다음 단계를 따르십시오:

  1. Panther 콘솔에 로그인합니다.

  2. 왼쪽 사이드바 탐색에서 클릭하십시오 구성 > 알러트 대상

  3. 기존 알러트 대상을 선택하거나 새 알러트 대상 추가.

  4. 알러트 대상의 구성 페이지에서 다음을 추가하십시오 시스템 오류알러트 유형 이벤트 이름

On the configuration screen for a Slack destination in the Panther Console, "System Errors" is one of the selected Alert Types.

로그 소스의 로그 드롭오프 알람 구성

Panther는 개별 로그 소스에 대한 이벤트 임계값 알람을 설정할 수 있게 하며, 특정 시간 간격 동안 데이터가 수신되지 않으면 알러트를 트리거합니다.

예를 들어 임계값을 15분으로 구성하면 15분 동안 이벤트가 처리되지 않으면 알러트를 받게 됩니다.

이는 Panther에 잘못 연결되었거나 Panther 외부에서 문제가 발생한 로그 소스에 유용할 수 있습니다.

circle-exclamation

새 로그 소스 또는 기존 로그 소스에 알람을 추가할 수 있습니다:

새 로그 소스에 대한 알람 설정

  1. Panther 콘솔의 왼쪽 탐색 창에서 구성 > 로그 소스.

  2. 오른쪽 상단에서 새로 만들기.

  3. 온보딩 워크플로우의 각 단계를 완료하십시오.

  4. 온보딩 워크플로우 끝의 성공 페이지에서, 가 활성화될 수 있습니다 기본값은 설정의 기본값은. 이 설정을 활성화된 상태로 두십시오.

    • 다음의 옆에 있는 숫자: 이 예약된 검색을 선택한 일정에 따라 실행되도록 하려면 토글을 필드에 원하는 기간을 입력하십시오 Panther가 이벤트가 처리되지 않았다는 알러트를 보내기 전에 얼마나 기다려야 합니까?.

The "Trigger an alert when no events are processed" toggle is set to YES. The "How long should Panther wait before it sends you an alert that no events have been processed" setting is set to 1 Day

시스템 오류의 유형

로그 소스 상태 알러트

Panther는 로그 소스에 대한 헬스 체크를 수행하여 Panther가 소스에 올바르게 연결되어 있고 올바른 자격증명을 보유하며 소스에서 지속적으로 데이터를 수신하고 있는지 확인합니다.

로그 중단 알러트

Panther는 개별 로그 소스에 대한 이벤트 임계값 알람을 설정할 수 있게 하며, 특정 시간 간격 동안 데이터가 수신되지 않으면 알러트를 트리거합니다. 이러한 알러트를 활성화하는 방법에 대한 지침은 위 섹션을 참조하십시오: 로그 소스의 로그 드롭오프 알람 구성.

다음에 대해서는 로그 중단 알람을 설정할 수 없습니다 Panther 감사 로그로그 소스로 활성화된 경우.

로그 분류 알러트

들어오는 로그가 해당 로그 소스에 연결된 스키마에 따라 올바르게 파싱되지 못할 때 Panther는 로그 분류 알러트를 생성합니다. 이럴 때:

  • 분류에 실패한 로그는 데이터 레이크로 전송되며 다음이라는 테이블에서 검색할 수 있습니다 classification_failures 에서 panther_rule_matches 데이터베이스.

  • 첫 로그가 분류에 실패하면 즉시 알러트가 생성됩니다. 알러트는 분류에 실패하는 모든 로그 라인을 표시합니다.

Panther 콘솔의 알러트 세부 정보 페이지는 파싱에 실패한 로그 라인을 강조하여 로그 유형의 해당 스키마에서 수정하거나 추가해야 할 라인을 판단하는 데 도움을 줍니다.

알러트에는 해당 로그 소스의 로그 소스 운영 페이지로 가는 링크가 포함되어 있으며, 해당 페이지의 Health 탭에서 분류에 실패한 이벤트 비율을 볼 수 있습니다.

로그 소스 운영 페이지에는 그래프가 포함되어 있습니다. 그래프는 이벤트가 잘못 분류되는 비율을 보여줍니다.

분류 실패 수정

circle-info

초기 분류에 실패한 이벤트의 재분류는 Panther 버전 1.114부터 오픈 베타이며 모든 고객이 이용할 수 있습니다. 버그 리포트 및 기능 요청은 Panther 지원 팀에 공유해 주십시오.

로그 소스 중 하나가 분류 실패를 받으면 다음 단계로 이를 수정할 수 있습니다:

  1. 로그 소스에 둘 이상의 스키마가 연결되어 있다면, 어떤 스키마가 실패했는지 식별하십시오.

    • 이 정보는 다음에서 찾을 수 있습니다 헬스 로그 소스 상세 페이지의 탭 또는 Data Explorer의 다음 테이블에서 직접 찾을 수 있습니다 classification_failures 에서 panther_rule_matches 데이터베이스.

  2. 스키마가 이벤트를 파싱하지 못한 이유를 이해하십시오. 분류 실패의 일반적인 원인은 다음과 같습니다:

    • 다음과 함께 필드가 있음 required:true 일부 들어오는 데이터에 존재하지 않음

    • 필드에 다음이 있음 type:string 하지만 실제로 수신된 데이터는 object인 필드가

    • 타임스탬프 필드의 형식 정의가 잘못되었음

    • 이벤트가 소스에 구성되지 않은 로그 유형이었음

    • 이벤트가 다른 방식으로 잘못 형성됨

  3. 다음을 클릭하여 분류 실패 알러트를 해결하십시오 해결로 표시.

    Under an "Overview" tab, a button labeled "Mark as Resolved" is circled.
  4. 페이지에서 이벤트 재처리하시겠습니까? 표시되는 팝업 모달에서 분류에 실패한 이벤트를 다음 중 하나를 클릭하여 처리하십시오:

    • (베타) 이벤트 재처리: 분류에 실패한 이벤트가 다시 처리됩니다. Under a "Reprocess events?" header, a "Reprocess Events" button is circled.

      circle-exclamation
      • 재처리가 성공적으로 완료되면 다음을 받게 됩니다 시스템 알림: A rectangle with an "i" icon on the left side says, "Panther completed reclassifying logs for source [Test Source]"

      • 분류가 다시 실패하면 새 분류 실패 알러트를 받게 됩니다.

    • 재처리 건너뛰기: 분류에 실패한 이벤트는 Panther로 수집되지 않습니다.

S3 GetObject 오류 알림

Panther가 S3 객체를 가져오지 못할 때 S3 GetObject 오류 알러트가 생성됩니다. 이럴 때 기본적으로 다음 동작이 수행됩니다:

  • Panther는 S3 객체를 데이터 레이크에 저장하며, 이는 Data Explorer에서 다음 제목의 테이블을 통해 쿼리할 수 있습니다 panther_monitor.data_audit.

  • Panther가 지난 24시간 내에 어떤 S3 객체도 가져오지 못하면 알러트가 생성됩니다. 알러트는 실패하는 특정 S3 객체를 표시합니다.

circle-info

이 유형의 오류는 Panther가 로그 이벤트를 수집하려 할 때 다음을 초과할 경우 생성됩니다 데이터 수집 크기 제한(15 MB). 유사한 오류가 CloudWatch, Azure Blob Storage 및 Google Cloud Storage(GCS)에 대해서도 생성됩니다.

알러트 전송 실패

알러트 전송 실패 알러트는 Panther가 알러트를 대상에 전달하지 못할 때 생성됩니다.

알러트를 처음 전달하려는 시도가 실패하면 Panther는 자동으로 재전송을 시도합니다. 알러트 전송 실패가 특정 임계값을 초과하면 시스템 상태 알러트가 생성되어 룰 또는 예약된 룰의 Python 처리가 15초를 초과하여 실행될 때. 알러트를 수신하도록 구성된 모든 알러트 대상으로 전송됩니다.

클라우드 보안 스캔 실패

클라우드 보안 스캔 실패 알러트는 "액세스 거부" 오류로 인해 Panther가 클라우드 리소스를 스캔하지 못할 때 생성됩니다.

이는 스캔을 허용하도록 권한이 제대로 구성되지 않았을 때 발생합니다. 이는 일반적으로 다음 시나리오 중 하나로 인해 발생합니다:

  • 당사의 스캐닝 역할(PantherAuditRole)에 충분한 권한이 구성되지 않음.

    • 이 역할의 권한은 거의 변경되지 않으므로 이는 매우 드문 경우입니다. 이는 다음을 최신 버전으로 업데이트하여 해결할 수 있습니다. PantherAuditRole 로 업데이트하십시오.

  • AWS 조직의 서비스 제어 정책(SCP)이 당사의 스캐닝 역할이 스캔을 수행하는 것을 방해하고 있음.

    • 일반적으로 특정 리전이나 서비스에 제한이 있는 SCP에서 발생합니다. 이는 SCP를 수정하여 당사 스캐닝 역할에 대한 예외를 추가하거나 클라우드 보안 통합을 수정하여 특정 리전 또는 리소스 유형을 제외하도록 하여 해결할 수 있습니다.

  • AWS 리소스 기반 정책이 당사의 스캐닝 역할이 스캔을 수행하는 것을 방해하고 있음.

    • AWS에서 권한은 양방향입니다. PantherAuditRole 리소스에 접근할 수 있는 권한이 부여될 수 있지만 리소스 자체가 당사 역할에 접근 허용 권한을 주지 않을 수 있습니다. 이는 리소스 기반 정책을 수정하여 당사 스캐닝 역할에 대한 예외를 추가하거나 클라우드 보안 통합을 수정하여 특정 리소스나 리소스 유형을 제외하도록 하여 해결할 수 있습니다.

알러트는 어떤 리소스에서 스캔이 실패했는지와 스캔 실패를 초래한 AWS 오류를 표시합니다:

The image shows an alert in the Panther Console titled "Source [panther-account] has scanning errors." The "Events" tab is open, and it includes metadata for the alert.

이 정보를 사용하여 정확한 권한 문제를 찾아낼 수 있습니다. 위 예에서는 다음을 볼 수 있습니다 어떤 리소스 기반 정책도 kms:ListResourcetags 작업을 허용하지 않음. 이는 문제의 원인이 리소스 기반 정책과 관련되었음을 나타냅니다.

마지막 업데이트

도움이 되었나요?