예약 검색 예제

이 페이지에는 로그에서 의심스러운 활동을 조사할 때 사용하고자 할 수 있는 일반적인 사용 사례와 예제 검색이 포함되어 있습니다.

아래 예제는 효과적으로 사용하려면 로컬 환경에 대한 일부 맞춤 구성이 필요합니다. 모든 쿼리는 결과 크기를 제어해야 합니다. 이는 LIMIT 또는 GROUP BY 절.

예약된 검색이 실행될 때마다 귀사의 데이터 플랫폼에 비용이 발생합니다. 쿼리가 지정된 시간 초과 기간 내에 완료될 수 있는지 확인하십시오.

스트리밍 규칙

Panther는 예약된 규칙은 하나 이상과 연결됩니다 (저장된 검색 (간격으로) 실행하고 예약된 규칙과 함께 여러 소스의 데이터를 집계하고 긴 시간 범위에 걸쳐 작동하는 탐지를 생성할 수 있습니다.

가능하면 스트리밍 규칙을 사용해 탐지를 구현하려고 하십시오. 스트리밍 규칙은 지연 시간이 낮고 예약된 검색에 비해 비용이 적게 듭니다. 그러나 더 많은 컨텍스트가 필요한 탐지의 경우 예약된 검색이 적절한 솔루션입니다.

데이터 지연 및 시간 고려사항

효과적인 예약된 규칙을 작성하려면 이벤트가 기록된 시점부터 Panther에 도달할 때까지의 데이터 지연을 이해해야 합니다. 이 정보를 사용하여 예약 및 사용되는 시간 창을 적절히 조정하십시오.

예를 들어 AWS CloudTrail 데이터는 약 10분의 지연이 있습니다. 이는 Panther 기능 때문이 아니라 AWS의 제한으로 인한 것입니다. 지난 한 시간을 분석하려는 경우 모범 사례로 검색을 시간 정각에서 15분 후에 실행하도록 예약하는 것을 권장합니다.

이는 Panther 스트리밍 규칙에는 고려 사항이 아닙니다. 스트리밍 규칙은 데이터가 시스템에 처음 들어올 때 처리될 때 적용되기 때문입니다. 예약된 검색은 주기적으로 누적된 데이터를 되돌아보기 때문에 시간적 고려사항이 중요합니다.

경보 심각도

AWS 콘솔 액세스를 특정 IP 주소로 제한

예약된 검색과 예약된 규칙을 사용해 탐지를 생성하는 프로세스를 더 잘 이해하기 위해 매우 간단한 종단 간 예제로 시작해 보겠습니다. 회사 IP 공간 내의 IP 주소로 AWS 콘솔 액세스를 매우 엄격하게 제한한다고 가정합니다. 이 제어를 검증하기 위해 모든 AWS 콘솔 로그인이 이 IP 공간 내의 sourceIPAddress 에서 발생했는지 확인하고 싶습니다. 이러한 IP 블록의 테이블을 데이터레이크에 보관하고 있습니다. 참고: 이 예제는 단순한 동등 조인 연산을 사용하며 IP 블록 테이블이 모두 /32 주소라고 가정합니다. 현실적인 구현에서는 IP 블록 테이블에 CIDR 블록이 있고 CIDR 블록 내부에 있지 않은 항목을 찾는 검사가 필요합니다. 이는 독자가 연습으로 남깁니다.

15분마다 규칙이 실행되고 이전 30분을 검사한다고 가정해 보겠습니다(CloudTrail과 관련된 데이터의 고유한 지연을 다루기 위해 긴 창을 사용합니다).

완전한 공개: 당신은 할 수 있습니다 DynamoDB 또는 S3에서 IP 화이트리스트 테이블을 관리했다면 스트리밍 규칙을 사용하여 이 탐지를 구현할 수 있습니다. 매우 높은 볼륨의 로그 소스의 경우 아래와 같이 주기적인 배치 조인이 더 효율적일 것입니다.

이러한 이벤트를 탐지하는 쿼리는 다음과 같습니다:

SQL

SELECT
    ct.*
FROM
    panther_logs.public.aws_cloudtrail ct LEFT OUTER JOIN infrastructure.networking.egress_blocks egress
        ON (ct.sourceIPAddress = egress.ip)
절과 같은 필터 안에 있어야 합니다.
    p_occurs_since('30 minutes') 
    AND
    ct.eventtype = 'AwsConsoleSignIn'
    AND 
    egress.ip IS NULL -- 일치하지 않음!
LIMIT 1000 -- 우리는 이런 항목이 많지 않을 것으로 예상하지만 안전을 위해 여기에 추가했습니다!

주의할 점: p_occurs_since() 은 Panther의 SQL 매크로 로 예약된 쿼리 생성을 쉽게 해줍니다.

PantherFlow

예약된 검색의 출력은 예약된 규칙(파이썬)을 통해 흐르므로 반환되는 행 수를 신중하게 제어하는 것이 중요합니다. 권장되는 방법은 항상 를 제공하거나 LIMIT 절을 사용하거나 GROUP BY 몇 천 개 미만의 제한된 행을 반환하는 집계 사용과 같은 방법입니다.

이를 구현하려면:

1. 예약된 검색 생성 이 지침을 따라.

   • 아래 예제 스크린샷에서는 30분마다 실행되도록 선택되어 있습니다.

2. 예약된 검색이 활성으로 설정되어 있는지 확인하십시오.

3. 를 만드십시오 예약 규칙 예약된 검색의 출력에 대상이 되는. \

예약된 규칙은 스트리밍 규칙의 모든 기능을 가지며 경고를 사용자 지정하고 목적지를 지정할 수 있습니다. Panther의 중복 제거는 경고 폭주를 방지합니다. 위 규칙에서는 sourceIPAddress 중복 제거를 사용하여 30분당 1개의 경고만 생성되도록 합니다.

목록에 조인하는 이 패턴은 IOC 탐지(예: TOR 출구 노드, 악성 코드 해시 등과 같은 IOC 테이블 유지)에도 사용할 수 있습니다.

명령 및 제어(C2) 비컨 탐지

이 예제에서는 집계를 사용하여 C2 비컨을 찾는 매우 간단하지만 효과적인 행동 기반 탐지를 생성합니다.

이는 설명을 위한 과도하게 단순화된 탐지입니다. 허용 목록화 및 임계값 조정과 같은 정교화 없이 이를 사용하면 과도한 오탐을 유발할 수 있습니다(많은 비악의적인 프로세스가 "비컨" 역할을 합니다). 그렇긴 해도, 잘 이해된 네트워크와 적절한 허용 목록을 사용하면 이 기법은 매우 효과적일 수 있습니다.

우리는 C2 비컨을 하루에 최대 다섯 번 이하로 발생하고 3일 이상 반복되는 모든 IP 활동으로 정의할 것입니다. 이를 구현하려면:

SQL

WITH low_and_slow_daily_ip_activity AS (
SELECT
    date(p_event_time) as day,
    srcAddr as beacon_ip
FROM
    panther_logs.public.aws_vpcflow
절과 같은 필터 안에 있어야 합니다.
    p_occurs_since('1 week')
GROUP BY 1,2
HAVING count(1) <= 5 -- 활동이 적은 항목만, 이는 튜닝이 필요합니다
)
SELECT
 beacon_ip,
 count(1) as days
FROM
 low_and_slow_daily_ip_activity
GROUP BY 
 1
HAVING days >= 3 -- 최소 이만큼 활동이 있는 항목만
LIMIT 20 -- 경고 폭주를 피하기 위해!

PantherFlow

이를 구현하려면:

1. 예약된 검색 생성 이 지침을 따라.

   • 아래 예제 스크린샷에서는 이 작업을 매일 자정 1분 후에 실행되도록 크론 표현식을 사용합니다.

2. 예약된 검색이 활성으로 설정되어 있는지 확인하십시오.

3. 를 만드십시오 예약 규칙 예약된 검색의 출력에 대상이 되는:

내 엔드포인트 모니터링은 얼마나 잘 작동하고 있나?

이 가상 예에서는 엔드포인트 모니터링 소프트웨어로 CrowdStrike를 사용한다고 가정합니다. Panther는 로그를 수집하도록 구성되어 있으며 다음과 같은 CMDB 가 배포된 에이전트를 내부의 관련 사용자와 매핑하도록 채워져 있습니다.

다음과 같은 많은 이 데이터에 대해 물어볼 수 있는 흥미로운 질문이 많지만 이 예에서는 구체적으로 "지난 24시간 동안 어떤 엔드포인트가 전혀 데이터를 보고하지 않았는가?"라는 질문을 다루겠습니다.

CrowdStrike 로그에서 배포된 에이전트의 고유 ID는 aid 입니다. CMDB에는 참조 데이터로 aid 가 매핑되어 있습니다. 이 예에서는 다음과 같은 속성을 가진다고 가정하겠습니다: employee_name, employee_group 와 last_seen입니다. 직원 관련 속성은 현재 누가 엔드포인트를 사용하는지 식별하는 데 도움이 되며 last_seen 은(는) 네트워크 활동(예: VPN 접속, DHCP 리스, 인증, 생존성 감지 등)을 추적하는 백엔드 프로세스에 의해 업데이트된다고 가정하는 타임스탬프입니다.

이 질문에 답하려면 CMDB에 있는 에이전트들 중 정말로 지난 24시간 내 네트워크 활동은 있지만 에 설치해야 하며 CrowdStrike 활동이 전혀 없는 에이전트를 알고 싶습니다. 이는 에이전트가 실행되고 있지 않거나 비활성화되었을 수 있음을 나타내며(커버리지 격차를 의미) 아래 쿼리는 의심되는 특정 엔드포인트를 포함하여 직원 그룹별 보고서를 계산합니다:

SQL

WITH active_aids AS (
SELECT
     DISTINCT aid -- 고유 에이전트 ID만 일치시키기
FROM panther_logs.public.crowdstrike_aidmaster
WHERE p_occurs_since('1 day') -- 지난 24시간의 로그 데이터에서
)
SELECT
    cmdb.employee_group,
    count(1) AS num_inactive_endpoints,
    ARRAY_AGG(
        DISTINCT cmdb.aid || ' ' || cmdb.employee_name || ' ' || cmdb.employee_group
    ) as endpoints -- 여기서 특정 엔드포인트를 수집합니다
FROM 
  infrastructure.inventory.cmdb AS cmdb LEFT OUTER JOIN active_aids cs USING(aid)
절과 같은 필터 안에 있어야 합니다.
  cs.aid IS NULL -- 어떤 로그 데이터와도 일치하지 않음
AND 
  cmdb.last_seen BETWEEN current_date - 1 AND current_date -- 활성 상태일 가능성 있음
GROUP BY 1
ORDER BY 2 desc

PantherFlow

이를 구현하려면:

1. 예약된 검색 생성 이 지침을 따라.

   • 아래 예제 스크린샷에서는 이 작업을 매일 자정 1분 후에 실행되도록 크론 표현식을 사용합니다.

2. 예약된 검색이 활성으로 설정되어 있는지 확인하십시오.

3. 를 만드십시오 예약 규칙 예약된 검색의 출력에 대상이 되는:

CrowdStrikeRule

경고와 관련된 이벤트는 분석가가 검토할 수 있으며 직원 그룹당 최대 하나가 될 것입니다. "히트"는 endpoints 에 누적되어 직원 정보를 사용해 쉽게 검증할 수 있습니다. 모든 Panther 규칙과 마찬가지로 경고의 목적지를 사용자 지정할 수 있는 유연성이 있습니다. 예를 들어, employee_group 정의되어 있더라도 C-스위트 라면 아마 온콜에게 페이지를 생성할 수 있고, 기본 경고는 단순히 다음 날 검증을 위한 작업 큐로 전달될 수 있습니다.

비정상적인 Okta 로그인

설정은 Okta 로그 는 이벤트와 관련된 "누가", "어떤 장치로" 및 "어디서"라는 질문에 대한 답을 제공합니다. 이 정보는 도난된 자격 증명을 사용하는 공격자와 같은 의심스러운 행동을 식별하는 데 사용될 수 있습니다.

문제는 "의심스럽다"를 정의하는 것입니다. 한 가지 방법은 정상에서 벗어나는 것을 의심스러운 것으로 정의하는 것입니다. 각 사용자에 대한 기준선을 구성할 수 있다면 유의미한 변화가 있을 때 경고할 수 있습니다.

좋아 보이지만 이제는 유용한 보안 발견(과도한 오탐이 아닌)을 생성할 수 있도록 "유의미한 변화"를 정의해야 합니다. 이 예에서는 클라이언트 정보에 대한 유의미한 변화를 대상으로 하여 도난된 자격 증명을 나타낼 수 있는지를 탐지합니다. 참고: Okta 데이터는 컨텍스트가 매우 풍부하므로 이것은 이 데이터를 활용하는 한 가지 간단한 예일 뿐입니다.

VPN과 프록시 때문에 특정 IP 주소나 관련 지리적 정보를 사용해 의심스러운 활동을 식별하는 것은 실용적이지 않은 경우가 많습니다. 유사하게, 사용자는 새 장치를 사용하거나 여러 장치를 사용할 수 있으므로 장치를 바꿀 수 있습니다. 합법적인 사용자 간에는 상당한 변동이 예상됩니다. 그러나 특정 사용자에 대해서는 시간이 지남에 따라 더 일관성이 있을 것으로 기대합니다.

이 예에서는 각 행위자(actor)에 대해 과거 최대 30일 동안 다음을 계산하여 "정상"을 특징짓습니다:

• 사용된 고유 인증 클라이언트 수

• 사용된 고유 OS 버전 수

• 사용된 고유 장치 수

• 사용된 고유 위치 수(정의: 국가, 주/도, 도시)

우리는 이 네 가지 차원 중 어느 것과도 일치하지 않는 이벤트를 "의심스러운" 것으로 정의할 것입니다. 이는 다음을 의미합니다:

• 새 장치를 얻는 경우에는 경고를 받지 않습니다.

• 위치가 변경될 때에는 경고를 받지 않습니다.

• 우리는 경고를 모든 속성이 한꺼번에 변경될 때 경고를 받습니다,

  그리고 우리는 이것이 보안 관점에서 이상하고 흥미롭다고 가정합니다.

또한 신규 직원으로 인한 오탐을 피하기 위해 적어도 5일 이상의 이력이 있는 행위자만 고려합니다.

이를 하루에 한 번 전날을 대상으로 실행되도록 예약한다고 가정합니다.

이는 단지 예시일 뿐이며 다른 휴리스틱과 마찬가지로 튜닝이 필요하지만 행위자별로 자체 보정되는 장점이 있습니다.

위 사항을 계산하는 SQL은 다음과 같습니다:

SQL

WITH actor_baseline AS (
  SELECT
    actor:id as actor_id,
    ARRAY_AGG (DISTINCT client:id) as client_id_list,
    ARRAY_AGG (DISTINCT client:userAgent.os)  as client_os_list,
    ARRAY_AGG (DISTINCT client:device) as client_devices_list,
    ARRAY_AGG (DISTINCT 
       client:geographicalContext:country || client:geographicalContext:state || client:geographicalContext:city)
      as client_locations_list
  FROM
    panther_logs.public.okta_systemlog
  절과 같은 필터 안에 있어야 합니다.
    p_occurs_since('30 days') 
  GROUP BY 1
  HAVING
    COUNT(DISTINCT date(p_event_time)) > 5 -- 최소 5일의 이력
)
-- 현재 일자를 기준선과 비교하여 기준선 속성 중 어느 것과도 일치하지 않는 이벤트를 반환
SELECT
  logs.*
FROM
  panther_logs.public.okta_systemlog logs JOIN actor_baseline bl ON (actor:id = bl.actor_id)
절과 같은 필터 안에 있어야 합니다.
  p_occurs_since('1 day') 
  AND
  NOT ARRAY_CONTAINS(logs.client:id::variant, bl.client_id_list)
  AND
  NOT ARRAY_CONTAINS(logs.client:userAgent:os::variant, bl.client_os_list)
  AND
  NOT ARRAY_CONTAINS(logs.client:device::variant, bl.client_devices_list)
  AND
  NOT ARRAY_CONTAINS(
          (client:geographicalContext:country || 
           client:geographicalContext:state || 
           client:geographicalContext:city)::variant, bl.client_locations_list)

검색이 실행될 때마다 이러한 기준선을 재계산하는 것은 효율적이지 않습니다. 향후 Panther는 요약 테이블을 생성하는 기능을 지원하여 위에서 설명한 방법을 더 효율적으로 만들 수 있도록 할 예정입니다.

PantherFlow

비밀번호 스프레이(Password spraying) 탐지

비밀번호 스프레이 공격은 몇 가지 일반적으로 사용되는 비밀번호로 많은 계정(사용자 이름)에 접근을 시도하는 공격입니다. 전통적인 무차별 대입 공격은 하나의 계정을 대상으로 비밀번호를 추측하여 무단 액세스를 얻으려 합니다. 이는 대상 계정이 잠기게 될 수 있습니다. 일반적인 계정 잠금 정책은 설정된 기간 동안 실패 시도가 제한되어 있기 때문입니다(일반적으로 3~5회). 비밀번호 스프레이 공격(“low-and-slow” 방식이라고도 함)에서는 악의적 행위자가 여러 계정에 대해 먼저 하나의 일반적으로 사용되는 비밀번호(예: 'password123' 또는 'winter2017')로 시도하고, 그 다음에 두 번째 비밀번호를 시도하는 식으로 진행합니다. 이 기법은 빠르거나 빈번한 계정 잠금을 피하여 탐지되지 않도록 합니다.

이 동작을 탐지하는 핵심은 시간에 걸쳐 집계하고 실패한 로그인과 함께 다양한 사용자 이름의 수를 보는 것입니다. 아래 예제는 CloudTrail을 사용하지만 유사한 기법을 모든 인증 로그에서 사용할 수 있습니다. 선택된 임계값은 대상 네트워크에 맞게 조정되어야 합니다.

SQL

SELECT
  -- 이 정보는 경고 이벤트에 포함됩니다
  awsRegion as region,
  recipientAccountId as accountid,
  COUNT(DISTINCT useridentity:userName) as distinctUserNames,
  COUNT(1) as failures,
  MIN(p_event_time) as first_attempt,
  MAX(p_event_time) as last_attempt
FROM
  panther_logs.public.aws_cloudtrail
절과 같은 필터 안에 있어야 합니다.
  -- 이는 과거 3600초(1시간)를 되돌아보는 Panther 매크로입니다
  p_occurs_since('1 hour') 
  AND
  eventtype = 'AwsConsoleSignIn'
  AND
  responseElements:ConsoleLogin = 'Failure'
GROUP BY
  region, accountid
HAVING
  distinctUserNames > 5
   AND
  failures > 10

PantherFlow

DNS 터널 탐지

대부분의 네트워크에서 DNS를 일반적으로 차단할 수 없기 때문에 DNS 기반 데이터 유출 및 C2는 매우 효과적일 수 있습니다. DNS 기반 터널을 생성하는 많은 도구가 있습니다. 모든 DNS 터널이 악의적이지는 않습니다. 아이러니하게도 많은 안티바이러스 도구가 텔레메트리를 "본사"로 보내기 위해 DNS 터널을 사용합니다. 대부분의 보안 담당자는 DNS 터널을 불안하게 여기므로 네트워크에서 이를 탐지하는 것은 유용합니다. 간단한 트래픽 분석으로 이러한 터널을 쉽게 찾을 수 있지만 합법적인 터널이 존재하므로 아래 예제는 임계값과 화이트리스트 모두에 대해 로컬 환경에 맞춘 튜닝이 필요합니다.

잠재적 DNS 터널을 한 시간 동안 소수의 고유 도메인에 대해 흥미로운 양의 데이터를 이동시키는 DNS 서버(포트 53)로 정의하겠습니다.

이 검색을 매시간 실행하여 지난 1시간을 되돌아보고 이러한 터널을 식별한다고 가정합니다:

SQL

SELECT
  account_id,
  region,
  vpc_id,
  srcAddr, -- 외부
  srcIds:instance, -- 내부

  COUNT(1) as message_count,
  ARRAY_AGG(DISTINCT query_name) as query_names
FROM
  panther_logs.public.aws_vpcdns
절과 같은 필터 안에 있어야 합니다.
  p_occurs_since('1 hour')
  AND
  -- 간단한 화이트리스트
  query_name NOT LIKE '%amazonaws.com'
GROUP BY
  1,2,3,4,5
HAVING
  message_count >= 1000   -- 한 시간에 상당한 활동량
   AND
  ARRAY_SIZE(query_names) <= 2 -- 고유 도메인 수가 적음(실제 DNS 서버일 가능성이 낮음!)

PantherFlow

클라우드 인프라 월간 보고

Panther의 클라우드 보안(Cloud Security) 이 AWS 인프라를 보고할 수 있으므로 resource_history 테이블을 사용하여 운영 및 보안에 관심이 있을 수 있는 활동 통계를 계산할 수 있습니다.

간단한 예로 아래 보고서는 매월 초에 이전 달에 대해 예약 실행되어 모니터링되는 계정의 활동을 표시할 수 있습니다.

SQL

WITH monthly_report AS (
  SELECT
    accountId,
    changeType,
    ARRAY_AGG(DISTINCT resourceType) as resourceTypes,
    count(1) as objects
  FROM
    panther_cloudsecurity.public.resource_history
  절과 같은 필터 안에 있어야 합니다.
      DATE_TRUNC('MONTH', p_event_time) = DATE_TRUNC('MONTH', current_date - 1)  -- 지난달 전체(우리는 1일에 실행하므로)
    AND
    changeType <> 'SYNC' -- 이는 변경이 아닌 전체 레코드입니다
  GROUP BY 1,2
)
-- 파이썬 규칙에서 전달할 수 있는 단일 행의 JSON 객체로 전체 보고서를 원합니다
SELECT
  ARRAY_AGG(OBJECT_CONSTRUCT(*)) as monthly_report
FROM monthly_report

PantherFlow

예시 출력:

{
    "monthly_report": [
        {
            "ACCOUNTID": "34924069XXXX",
            "CHANGETYPE": "DELETED",
            "OBJECTS": 8,
            "RESOURCETYPES": [
                "AWS.IAM.Role"
            ]
        },
        {
            "ACCOUNTID": "34924069XXXX",
            "CHANGETYPE": "MODIFIED",
            "OBJECTS": 2388,
            "RESOURCETYPES": [
                "AWS.CloudTrail.Meta",
                "AWS.S3.Bucket",
                "AWS.CloudFormation.Stack",
                "AWS.CloudTrail",
                "AWS.IAM.Role"
            ]
        },
        {
            "ACCOUNTID": "34924069XXXX",
            "CHANGETYPE": "CREATED",
            "OBJECTS": 11,
            "RESOURCETYPES": [
                "AWS.IAM.Role",
                "AWS.CloudFormation.Stack",
                "AWS.KMS.Key"
            ]
        }
    ]
}

설정은 resource_history 테이블은 특정 리소스까지 자세히 포함하므로 필요에 따라 더 상세하게 만들 수 있는 검색 변형이 있습니다.

데이터베이스(Snowflake) 모니터링

Snowflake 활동을 Snowflake 감사 로그(Snowflake Audit Logs) 통합을 통해 통합하는 것을 지원합니다.

를 사용해 모니터링하는 것도 가능합니다.

민감한 데이터를 보관하는 데이터베이스는 공격 대상이 되는 경우가 많으므로 광범위한 보안 모니터링이 필요합니다. 이러한 쿼리는 Panther의 읽기 전용 롤이 snowflake.account_usage

 감사(audit) 데이터베이스에 접근할 수 있어야 합니다(이는 Snowflake 관리자에 의해 수행되어야 할 수 있습니다).
 GRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE panther_readonly_role;

USE ROLE accountadmin;

SQL

 이 쿼리는 사용자 이름별 실패한 로그인 패턴을 찾으며 정기적으로 실행해야 합니다:
  -- 지난 24시간 동안 실패한 로그인 2회를 초과한 사용자를 반환
  SELECT 
    -- 이는 SnowAlert 쿼리에서 수정되었습니다
    user_name,
    reported_client_type,
    ARRAY_AGG(DISTINCT error_code),
    ARRAY_AGG(DISTINCT error_message),
  COUNT(event_id) AS counts
  FROM snowflake.account_usage.login_history
    WHERE 1=1
    AND DATEDIFF(HOUR, event_timestamp, CURRENT_TIMESTAMP) < 24
  AND error_code IS NOT NULL
  GROUP BY reported_client_type, user_name

PantherFlow

| where counts >= 3

SQL

 Snowflake의 단일 IP별 실패한 로그인은 24시간 동안 IP별 로그인 시도를 살펴보고 실패한 로그인 2회를 초과하는 IP를 반환합니다. 이는 잠재적으로 의심스러운 활동을 강조하기 위해 24시간마다 실행되도록 예약할 수 있습니다. 이 접근 방식의 효과는 기업이 내부 IP 주소를 어떻게 처리하는지에 따라 달라질 수 있습니다.
  -- 지난 24시간 동안 실패한 로그인 2회를 초과한 사용자를 반환
  SELECT 
    -- 지난 24시간 동안 실패한 로그인 2회를 초과한 IP를 반환
    client_ip,
    MIN(event_timestamp) event_start,
    MAX(event_timestamp) event_end,
    user_name,
    reported_client_type,
    ARRAY_AGG(DISTINCT error_code),
    ARRAY_AGG(DISTINCT error_message),
  COUNT(event_id) AS counts
  FROM snowflake.account_usage.login_history
    timediff(second, event_start, event_end) as event_duration,
    AND DATEDIFF(HOUR, event_timestamp, CURRENT_TIMESTAMP) < 24
  AND DATEDIFF(HOUR,  event_timestamp, CURRENT_TIMESTAMP) < 24
  GROUP BY client_ip, reported_client_type

PantherFlow

| extend event_duration=time.trunc('s', event_end) - time.trunc('s', event_start)

SQL

SELECT
    지난 7일을 돌이켜보는 Snowflake에서의 관리자 권한 부여. 반드시 의심스러운 것은 아니지만 Snowflake 관리자들이 추적하고 싶어할 수 있는 사항입니다.
     current_account() AS environment
     , REGEXP_SUBSTR(query_text, '\\s([^\\s]+)\\s+to\\s',1,1,'ie') AS role_granted
     , start_time AS event_time
     , query_text AS event_data
     , user_name AS user_name
     , role_name
     , query_type
, query_id AS query_id
FROM snowflake.account_usage.login_history
  FROM snowflake.account_usage.query_history
  AND DATEDIFF(DAY,  start_time, CURRENT_TIMESTAMP) <= 7
  AND query_type='GRANT'
  AND execution_status='SUCCESS'

PantherFlow

role_granted=re.substr(query_text, '\\s([^\\s]+)\\s+to\\s',1,1,'ie')

계정 사용 뷰 쿼리하기 계정 사용(또는 account usage)을 쿼리하는 추가적인 예제는 Snowflake 문서를 참조하십시오.