예약된 검색 예시

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

아래 예제는 효과를 위해 로컬 환경에 대한 일부 사용자 지정이 필요합니다. 모든 쿼리는 결과 크기를 제어해야 한다는 점에 유의하세요. 이는 다음과 같이 수행할 수 있습니다: LIMIT 이전에 생성한 Snowflake 사용자 이름, 예를 들면 GROUP BY 절.

스케줄된 검색이 실행될 때마다 회사는 데이터 플랫폼에 비용이 발생합니다. 쿼리가 지정된 타임아웃 기간 내에 완료될 수 있는지 확인하십시오.

스트리밍 룰

Panther는 여러분이 스케줄된 검색 (저장된 검색 (간격으로) 실행하고 스케줄된 룰과 함께 여러 소스의 데이터를 집계하여 장기간에 걸친 디텍션을 생성할 수 있게 합니다.

가능하면 스트리밍 룰을 사용하여 디텍션을 구현하려고 하세요. 스트리밍 룰은 지연 시간이 낮고 스케줄된 검색보다 비용이 저렴합니다. 그러나 때로는 디텍션에 더 많은 컨텍스트가 필요하여 스케줄된 검색이 적절한 해결책인 경우가 있습니다.

데이터 지연 및 타이밍 고려사항

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

예를 들어, AWS CloudTrail 데이터는 약 10분의 지연이 있습니다. 이는 Panther 기능이 아닌 AWS의 한계로 인한 것입니다. 지난 한 시간을 분석하려면 모범 사례로 검색을 매 정시 15분 후에 실행하도록 예약하는 것을 권장합니다.

이는 데이터가 시스템으로 들어올 때 처음 처리될 때 적용되는 Panther 스트리밍 룰에는 해당되지 않습니다. 스케줄된 검색은 주기적으로 누적된 데이터를 되돌아보기 때문에 타이밍 고려사항이 중요합니다.

예제

AWS 콘솔 접근을 특정 IP 주소로 제한하기

스케줄된 검색과 스케줄된 룰을 사용하여 디텍션을 생성하는 프로세스를 더 잘 이해하기 위해 매우 간단한 엔드투엔드 예제로 시작해 보겠습니다. 회사 IP 공간의 IP 주소에서만 AWS 콘솔 접근을 매우 엄격하게 제한한다고 가정합시다. 이 제어를 검증하려면 모든 AWS 콘솔 로그인에 대해 sourceIPAddress 이 IP 공간 내에서 발생했는지 확인하고자 합니다. 이러한 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)
WHERE
    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분에 하나의 알러트만 생성하도록 합니다.

이와 같은 목록에 조인하는 패턴은 TOR 출구 노드, 악성코드 해시 등과 같은 IOC 테이블을 유지하여 IOC 디텍션에도 사용할 수 있습니다.

커맨드 앤 컨트롤(C2) 비컨 탐지

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

이 디텍션은 설명을 위한 과도하게 단순화된 예시입니다. 허용목록 및 임계값 조정과 같은 정교화 없이 이를 사용하면 과도한 오탐을 유발할 수 있습니다(비악의적인 많은 프로세스도 "비컨"을 할 수 있습니다). 그럼에도 불구하고 잘 이해된 네트워크에서 적절한 허용목록을 사용하면 이 기술은 매우 효과적일 수 있습니다.

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

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
WHERE
    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분에 실행되도록 Cron 표현식을 사용했습니다.

2. 스케줄된 검색이 활성화되어 있는지 확인하세요.

3. 만드세요 예약된 룰 스케줄된 검색의 출력에 대상이 되는:

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

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

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

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

이 질문에 답하려면 CMDB에서 어떤 에이전트가 정말로 지난 24시간 동안 네트워크 활동이 있지만 Enterprise 조직 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)
WHERE
  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분에 실행되도록 Cron 표현식을 사용했습니다.

2. 스케줄된 검색이 활성화되어 있는지 확인하세요.

3. 만드세요 예약된 룰 스케줄된 검색의 출력에 대상이 되는:

CrowdStrikeRule

알러트와 관련된 이벤트는 분석가가 검토할 수 있으며, 직원 그룹별로 최대 하나가 될 것입니다. "히트"는 endpoints 에 누적되어 직원 정보를 사용하여 쉽게 검증할 수 있습니다. 모든 Panther 룰과 마찬가지로 알러트의 목적지를 커스터마이즈할 수 있는 유연성이 있습니다. 예를 들어, 만약 employee_group 정의되어 C-스위트 라면 온콜로 페이지를 보낼 수 있고, 기본 알러트는 단순히 다음 날 검증을 위한 작업 큐로 갈 수 있습니다.

이상한 Okta 로그인

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

도전 과제는 "의심스러움"을 정의하는 것입니다. 한 가지 방법은 정상에서의 편차로 의심스러움을 정의하는 것입니다. 각 사용자에 대한 베이스라인을 구성할 수 있다면 유의미한 변화가 있을 때 알러트할 수 있습니다.

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

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

이 예제에서는 각 행위자에 대해 최대 과거 30일 동안 다음을 계산하여 "정상"을 특징으로 정의합니다:

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

• 사용된 고유 운영체제 버전

• 사용된 고유 디바이스

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

우리는 네 가지 차원 중 하나에도 전혀 일치하지 않는 이벤트를 "의심스러움"으로 정의합니다. 이는 다음을 의미합니다:

• 새 디바이스를 얻어도 알러트가 발생하지 않습니다.

• 위치를 변경해도 알러트가 발생하지 않습니다.

• 우리는 발생할 것입니다 모든 속성이 동시에 변경될 때 알러트를 받습니다,

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

신규 직원으로 인한 오탐을 피하기 위해 최소 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
  WHERE
    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)
WHERE
  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

패스워드 스프레이 탐지

패스워드 스프레이는 몇 가지 일반적으로 사용되는 비밀번호로 다수의 계정(사용자 이름)에 접근을 시도하는 공격입니다. 전통적인 무차별 대입 공격은 단일 계정의 비밀번호를 추측하여 무단 접근을 시도합니다. 이는 흔히 설정된 기간 내 실패 시도 수(일반적으로 3~5회)에 따라 대상 계정이 잠기게 되어 빠르게 탐지될 수 있습니다. 패스워드 스프레이 공격(“저속·저빈도” 방식이라고도 함)에서는 공격자가 여러 계정에 대해 하나의 일반적으로 사용되는 비밀번호(예: '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
WHERE
  -- 이는 3600초(1시간)를 되돌아보는 Panther 매크로입니다
  내에서 사용될 때, 현재 시간을 기준으로 하는 대신 예약된 실행 시간이 기준으로 사용됩니다. 예를 들어 쿼리가 매 시간의 시작에 실행되도록 예약된 경우, 
  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
WHERE
  내에서 사용될 때, 현재 시간을 기준으로 하는 대신 예약된 실행 시간이 기준으로 사용됩니다. 예를 들어 쿼리가 매 시간의 시작에 실행되도록 예약된 경우,
  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 클라우드 보안 가 AWS 인프라에 대한 보고를 제공할 수 있으므로 resource_history 테이블을 사용하여 운영 및 보안에 관심이 있을 수 있는 활동 통계를 계산할 수 있습니다.

간단한 예로 아래 보고서는 모니터링 계정의 지난 달 활동을 보여주기 위해 매월 1일에 실행되도록 예약할 수 있습니다.

SQL

WITH monthly_report AS (
  SELECT
    accountId,
    changeType,
    ARRAY_AGG(DISTINCT resourceType) as resourceTypes,
    count(1) as objects
  FROM
    panther_cloudsecurity.public.resource_history
  WHERE
      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 감사 로그 통합을 통해 지원합니다.

민감한 데이터를 보유한 데이터베이스는 종종 공격 대상이 되므로 광범위한 보안 모니터링이 필요합니다.

이러한 쿼리는 Panther의 읽기 전용 역할이 snowflake.account_usage 감사 데이터베이스에 접근할 수 있어야 합니다(이는 Snowflake 관리자에 의해 수행되어야 할 수 있음).

 USE ROLE accountadmin;
 GRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE panther_readonly_role;

이 쿼리는 사용자 이름별로 실패한 로그인 패턴을 찾으며 정기적으로 실행되어야 합니다:

SQL

 -- 지난 24시간 동안 실패한 로그인 2회를 초과한 사용자 반환
  -- 이는 SnowAlert 쿼리에서 수정된 것입니다
  SELECT 
    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
  HAVING counts >=3;

PantherFlow

단일 IP에 의한 Snowflake 실패한 로그인은 24시간 동안 IP별 로그인 시도를 보고 실패한 로그인 2회를 초과한 IP를 반환합니다. 이는 잠재적으로 의심스러운 활동을 강조하기 위해 24시간마다 실행되도록 예약할 수 있습니다. 이 접근의 효과는 기업 내부 IP 주소를 어떻게 처리하는지에 따라 달라질 수 있습니다.

SQL

 -- 지난 24시간 동안 실패한 로그인 2회를 초과한 IP 반환
  -- 이는 SnowAlert 쿼리에서 수정된 것입니다
  SELECT 
    client_ip,
    MIN(event_timestamp) event_start,
    MAX(event_timestamp) event_end,
    timediff(second, event_start, event_end) as event_duration,
    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 client_ip, reported_client_type
  HAVING counts >= 3;

PantherFlow

Snowflake에서의 관리자 권한 부여는 지난 7일을 되돌아봅니다. 이는 반드시 의심스러운 것은 아니지만 Snowflake 관리자들이 추적하고 싶어할 수 있는 항목입니다.

SQL

SELECT
    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.query_history
WHERE 1=1
  AND DATEDIFF(DAY,  start_time, CURRENT_TIMESTAMP) <= 7
  AND query_type='GRANT'
  AND execution_status='SUCCESS'
  AND (role_granted ILIKE '%securityadmin%'  OR role_granted ILIKE '%accountadmin%' OR role_granted ILIKE '%admin%')

PantherFlow

계정 사용 뷰 쿼리하기

추가적인 계정 사용 쿼리에 대한 예시는 Snowflake 문서를 참조하세요.