# Panther AI 모범 사례 ## 개요 보안 산업은 인간 규모에서 AI 규모로 전환하고 있으며, Panther AI는 그 흐름을 완성하도록 설계되었습니다. Panther AI는 사후에 AI를 경직된 아키텍처에 덧붙이는 대신, 분류, 조사, 대응 전반에 걸쳐 내장되어 있어 각 단계에서 적절한 조치가 자동으로 이루어집니다. Panther AI는 알러트를 조사하고 해결하는 데 걸리는 시간을 크게 줄일 수 있지만, 그 효과는 어떻게 구성하고 사용하는지에 달려 있습니다. 이 가이드는 다음에 대한 모범 사례를 다룹니다 [프롬프팅](#write-better-prompts-with-the-star-framework), [환경 설정](#configure-your-organizational-profile), [Auto-Triage 구성](#use-auto-triage-strategically), 그리고 [런북 작성](#write-ai-native-runbooks). *** ## 모범 사례 ### STAR 프레임워크로 더 나은 프롬프트 작성하기 Panther AI는 사용자가 제공한 컨텍스트에 반응합니다. 구조화된 프롬프트는 특히 여러 로그 소스를 조회하거나 특정 출력 형식을 반환해야 하는 복잡한 조사에서 개방형 프롬프트보다 일관되게 더 나은 결과를 만듭니다. Specific, Targeted, Actionable, Relevant(STAR) 프레임워크는 어떤 프롬프트든 구조화하기 위한 실용적인 방법입니다: | 문자 | 원칙 | 포함할 내용 | | ----- | ---------- | --------------------------------------------------------------- | | **S** | Specific | 찾거나 수행하고 싶은 것을 정확히 | | **T** | Targeted | 이름이 지정된 로그 유형, 필드, 엔터티(예: `AWS.CloudTrail`, `john@example.com`) | | **A** | Actionable | 원하는 출력(예: "요약", "sourceIP별로 집계", "막대 차트로 시각화") | | **R** | Relevant | 시간 범위 및 위협 모델링 메모와 같은 문맥적 세부 정보(예: "지난 24시간 동안") | #### 역할별 프롬프트 예시 **보안 분석가 — 알러트 분류** > 에 대한 불가능한 이동 알러트를 조사하고 있습니다. 모든 `ConsoleLogin` 활동을 찾아서 이 사용자의 세션이 하이재킹되었는지 확인하세요 `AWS.CloudTrail` 및 `Okta.SystemLog` 지난 24시간 동안. 연대기 순서의 타임라인과 BLUF 요약을 제공하세요. **위협 헌터 — 선제적 검색** > 상대의 인프라에 관한 새로운 위협 인텔리전스를 받았습니다. AWS.VPCFlow 로그에서 malicious-domain.com에 대한 연결을 검색하여 알려진 도메인으로의 네트워크 연결이 있는지 탐지하세요. 결과를 sourceIP별로 그룹화하고 스택 막대 차트를 사용하여 상위 10개 표적 내부 자산을 시각화하세요. **디택션 엔지니어 — AWS Console 무차별 대입** > 무차별 대입 공격에 대한 범위를 확장해야 합니다. AWS Console 무차별 대입 시도에 대한 새로운 Panther 디택션을 생성하세요. 룰은 10분 내에 동일한 소스 IP에서 5회가 넘는 실패한 `ConsoleLogin` 이벤트가 있을 때 `AWS.CloudTrail` 로그를 사용하여 트리거되어야 하며, 회사 CIDR 10.0.0.0/8은 제외합니다. 디택션을 Python으로 출력하고 심각도는 HIGH로 설정하세요. {% hint style="info" %} 더 많은 프롬프트 예시는 다음에서 확인하세요 [Panther AI Workflow Examples](https://claude.ai/chat/examples.md). {% endhint %} *** ### 조직 프로필 구성하기 Panther AI는 환경을 이해할수록 훨씬 더 유용해집니다. [**조직 프로필**](https://docs.panther.com/ko/system-configuration#configuration) (다음 위치에서 찾을 수 있음 **Settings > Panther AI**)은 모든 AI 상호작용에 내장되는 지속적인 컨텍스트 계층 역할을 하므로, 모든 프롬프트에서 인프라를 반복해서 설명할 필요가 없습니다. 조직 프로필을 사용하여 다음을 수행하세요: * **환경 정의** — 네트워크 토폴로지를 매핑하여 Panther AI가 내부와 외부를 추론할 수 있게 하세요. * 예를 들면: *"내부 서브넷은 10.0.0.0/8입니다. AWS 계정 123456789012는 우리의 프로덕션 환경입니다."* * **SOP 내장하기** — 사고 대응 정책을 직접 인코딩하세요. * 예를 들면: *"측면 이동이 탐지되면, 최종 권고는 반드시 IR 팀에 호출하는 것이어야 합니다."* * **자산 중요도 분류** — 디택션 심각도와 관계없이 고가치 환경이 적절한 긴급도로 처리되도록 하세요. * 예를 들면: *" `prod-payments` 계정이 포함된 모든 알러트는 디택션 심각도와 관계없이 HIGH 우선순위로 처리되어야 합니다."* * **알려진 정상 서비스 계정 정의** — 예상되는 자동화로 인한 오탐 노이즈를 줄이세요. * 예를 들면: *"IAM 역할 `arn:aws:iam::123456789012:role/DataPipelineRole` 은 매일 밤 예약된 S3 동기화를 수행하며 정상입니다."* 조직 프로필이 더 구체적일수록, 분석가가 개별 프롬프트에 포함해야 하는 후속 컨텍스트는 더 줄어듭니다. *** ### 자동 실행 AI 알러트 분류를 전략적으로 사용하기 [Panther AI는 새 알러트가 생성되는 즉시](https://docs.panther.com/ko/alerts#auto-run-ai-alert-triage) 이를 자동으로 분류할 수 있어 조사 시간을 크게 줄여줍니다. 그러나 생성형 AI는 강력하지만 연산 비용이 큰 자원입니다. 모든 알러트에 대해 자동 실행 분류를 돌리는 것은 AI 실행 횟수를 빠르게 소모할 수 있는 안티 패턴입니다. 목표는 깊이 있는 분석 기능이 실제로 필요할 때만 AI를 실행하는 것입니다. #### 1단계: 먼저 디택션을 조정하세요 자동 실행 AI 알러트 분류를 구성하기 전에 AI에 도달하는 저충실도 신호의 양을 줄이세요: * **Python에서 허용 목록 추가** — 취약점 스캐너, CI/CD 서비스 계정, 일상적인 자동화(예: `drive-sync@gserviceaccount.com`). * **조정** [**중복 제거 설정**](https://docs.panther.com/ko/detections/rules#deduplication-of-alerts) — Panther의 이벤트 그룹화를 사용하여 단일 소음 원천으로 인한 알러트 폭주가 AI 대기열을 가득 채우지 않도록 하세요. #### 2단계: 디택션 태그로 자동 실행 분류를 게이트하기 신호 품질이 충분히 높아지면, 깊이 있는 분석의 이점을 실제로 얻는 알러트에만 자동 실행 분류가 수행되도록 구성하세요. **Settings > Panther AI**에서 [디택션 태그](https://docs.panther.com/ko/alerts#delay-auto-run-ai-alert-triage) 를 지정하여 자동 실행을 트리거해야 합니다. Panther AI는 구성된 태그 중 최소 하나를 가진 디택션에서 발생한 알러트만 자동 분류합니다. 시작할 때 권장되는 태그: | 태그 | 사용 시점 | | ------------------------------------- | ----------------------------------------------------------------------------------------------------- | | `ai-triage:auto` | AI 대기열로 라우팅하려는 모든 디택션에 대한 명시적 옵트인 태그 | | `threat:uba` 또는 `identity-compromise` | 사용자 행동 분석 및 아이덴티티 알러트는 AI에 매우 적합합니다. 이 에이전트는 30일 기준선을 빠르게 조회하고 Okta 및 AWS 로그 전반의 활동을 교차 참조하는 데 뛰어납니다. | | `context-heavy` | 결론에 도달하기 전에 일반적으로 3개 이상의 로그 소스를 통해 피벗해야 하는 복잡한 디택션 | {% hint style="info" %} Auto-Triage 구성 방법 알아보기 [알러트 및 대상](https://docs.panther.com/ko/alerts). {% endhint %} *** ### AI 네이티브 런북 작성하기 [Panther AI가 알러트를 분류할 때](https://docs.panther.com/ko/alerts/alert-runbooks#how-panther-ai-uses-an-alert-runbook)연결된 디택션 런북을 읽고 그 단계를 자율적으로 실행합니다. 역사적으로 런북은 인간 분석가를 위해 작성되었으며, AI가 작업하는 데 충분한 정보를 주지 못하는 모호한 지침으로 가득합니다. Panther AI가 의미 있는 조사를 수행하려면 런북은 명시적이고 순차적이며 기계가 읽을 수 있어야 합니다. #### 런북 지침 안내 | ✅ 포함 | ❌ 피하기 | | --------------------------------------------- | --------------------------- | | 조회할 특정 로그 유형 | "알러트 이벤트를 검토하세요"와 같은 모호한 지침 | | 이름이 지정된 알러트 필드(예: `{user_arn}`, `{sourceIP}`) | "유사한 알러트를 확인하세요" 같은 일반적인 안내 | | 정의된 시간 창(예: "알러트 전후 6시간") | "추가 조사"와 같은 모호한 언어 | | 알려진 정상 값 및 기준 패턴 | 구체적인 쿼리로 변환되지 않는 지침 | | 참/거짓 양성 판정 기준 | 기준을 정의하지 않고 인간의 판단을 가정하는 단계 | #### 예시 **❌ 모호한 런북(사람을 위해 작성됨)** > 관련 사용자 활동을 검색하세요. 사용자가 이상한 행동을 했는지 확인하세요. 결과를 문서화하세요. Panther AI는 이를 실행할 수 없습니다. 조회할 로그 테이블도 없고, 시간 창도 없으며, "이상한"의 정의도 없습니다. **✅ AI 네이티브 런북** > 1\. 조회 `AWS.CloudTrail` 에 대한 모든 API 호출을 `{user_arn}` 이 알러트 전후 6시간 동안. > > 2\. 액세스된 S3 오브젝트 키가 알려진 민감 데이터 패턴과 일치하는지 확인합니다. > > 3\. 활동이 사용자의 30일 기준선 범위를 벗어나면 `{sourceIP}` 가 회사 VPN 범위와 일치하는지 확인합니다. > > 4\. 만약 `{sourceIP}` 가 회사 VPN 범위에 없고 `{user_arn}` 가 지난 30일 동안 이 작업을 수행한 적이 없다면, 참 양성으로 간주하고 IR 팀에 에스컬레이션합니다. 이 방식이 작동하는 이유는 로그 소스를 명시하고, 실제 알러트 필드를 참조하며, 시간 창을 정의하고, 분류를 위한 명확한 기준을 AI에 제공하고, 참/거짓 양성 판정을 마무리하기 때문입니다. #### 런북 템플릿 런북을 처음 작성할 때는 다음 구조를 사용하세요: ``` 1. [작업] [특정 필드]를 [시간 창] 내 [로그 유형]에서. 예: 알러트 24시간 전 AWS.CloudTrail에서 {user_arn}의 모든 API 호출을 조회합니다. 2. [확인 / 비교 / 검증] [특정 조건]. 예: 주체가 지난 30일 동안 이 리소스에 액세스했는지 확인합니다. 3. [검색 / 찾기] [관련 활동]을 [시간 창] 내에서. 예: 지난 7일 동안 이 사용자로부터 다른 알러트나 비정상 활동이 있는지 확인합니다. ``` ## Panther AI 데이터레이크 쿼리 제한 Panther AI는 강력하지만, 엄격한 아키텍처 제약 하에서 동작합니다. 이러한 제한을 이해하면 더 나은 런북을 작성하고, 기대치를 조정하고, 시스템에 맞서기보다 시스템과 함께 작동하는 조사를 설계하는 데 도움이 됩니다. {% hint style="warning" %} Panther AI는 넓은 시간 범위나 데이터 소스를 조사하라고 요청받았을 때 "모든" 데이터를 조회하지 않습니다. 모든 쿼리는 결과의 완전성에 영향을 미치는 엄격한 제한을 받습니다. {% endhint %} | 제한 사항 | 세부 정보 | 조사 전략 | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | **쿼리 결과는 100 KB로 제한됩니다** | 각 쿼리 결과 집합은 약 100 KB로 제한됩니다. 대량 환경에서는 실제 활동의 일부만 나타날 수 있습니다. 이는 LLM 컨텍스트 창이 압도되는 것을 방지하기 위한 안전 제한입니다. | 집계 쿼리(예: `GROUP BY`, `COUNT`)를 사용하여 크기 제한 내에서 수백만 이벤트를 요약하세요. 원시 이벤트를 가져오기 전에 특정 IP나 사용자로 범위를 좁히세요. 필요한 열만 선택하고 — `SELECT *`. | | **쿼리에는 시간 필터가 필요합니다** | Panther AI는 시간 필터가 포함되지 않은 쿼리를 거부합니다. Panther의 데이터 레이크는 이벤트 시간 기준으로 파티셔닝되어 있으며, 범위가 없는 쿼리는 전체 테이블을 스캔하게 됩니다. 시간 필터가 있더라도 고볼륨 소스에서 범위가 너무 넓으면(예: "지난 1년") 결과가 불완전할 수 있습니다. | 24시간 창으로 시작하고 필요할 때만 넓히세요. 기준선 분석에서는 모든 이벤트를 가져오기보다 특정 엔터티(사용자, IP, 리소스)를 기준으로 삼으세요. | | **최근 이벤트는 아직 수집 지연 때문에 조회할 수 없을 수 있습니다** | 지난 몇 초에서 몇 분 사이의 이벤트는 활성 인시던트 동안 쿼리 결과에 나타나지 않을 수 있습니다. | 진행 중인 인시던트의 경우, 가장 최근 이벤트는 Panther 콘솔의 라이브 알러트 보기를 사용하세요. 초기 이벤트가 수집된 후에는 역사적 상관 관계 분석을 위해 Panther AI로 전환하세요. | ### 고볼륨 조사를 위한 효과적인 프롬프트 작성하기 고볼륨 데이터 소스를 조사할 때, 프롬프트를 어떻게 구조화하느냐에 따라 유용한 요약을 얻을지, 쿼리 한도에 걸릴지가 결정됩니다. Panther AI의 쿼리 제약 내에서 의미 있는 결과를 얻으려면 집계와 필터를 사용하세요. | ✅ 좋은 프롬프트 | ❌ 나쁜 프롬프트 | 이유 | | ------------------------------------------------------------------------------------- | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | "지난 7일 동안 user 에 대한 상위 10개 CloudTrail API 호출을 이벤트 수별로 그룹화하여 요약하세요." | "지난 한 달간의 모든 CloudTrail 로그를 보여주세요." | 엔터티 필터(특정 사용자), 집계(`GROUP BY`, `COUNT`), 결과 제한, 그리고 이름이 지정된 로그 **소스** 를 결합하면 전체 테이블 스캔을 방지하고 결과를 실행 가능하게 유지할 수 있습니다. | | "지난 24시간 동안 source IP별로 실패한 ConsoleLogin 이벤트 수를 계산하세요." | "모든 실패한 로그인 시도를 보여주세요." | 특정 이벤트 유형, 집계, 그리고 좁은 시간 창(24시간)은 무제한 스캔 없이 위협 헌팅을 수행하기 위한 가장 강력한 패턴입니다. | | "지난 7일 동안 IP 1.2.3.4에 대한 Cloudflare 활동을 보여주세요." | "의심스러운 Cloudflare 활동을 찾아주세요." | 명시적인 로그 소스와 제한된 시간 창이 결합된 이름이 지정된 지표(IP 주소)는 지표 기반 조사에 이상적인 표현입니다. |