<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Panther Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-panther/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 02 Oct 2026 13:06:13 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Migrated from Panther to Chronicle Security - 12 month report</title>
                        <link>https://communities.stackinsight.net/community/cyber-panther/migrated-from-panther-to-chronicle-security-12-month-report-2/</link>
                        <pubDate>Mon, 28 Sep 2026 17:16:41 +0000</pubDate>
                        <description><![CDATA[We completed the migration from Panther to Chronicle Security (part of Google Cloud) just over a year ago. The decision was driven by a corporate mandate to consolidate on GCP, and while the...]]></description>
                        <content:encoded><![CDATA[We completed the migration from Panther to Chronicle Security (part of Google Cloud) just over a year ago. The decision was driven by a corporate mandate to consolidate on GCP, and while the platform is powerful, the transition was not a straightforward upgrade. It was a full replatforming with significant hidden costs and workflow changes. This is a report on the operational reality.

The core promise was similar: ingest logs, run detections, generate alerts. The implementation philosophy, however, is entirely different. Panther is built as a code-first, developer-centric platform. Chronicle, coming from the Google-scale world, is a black-box data lake with its own query language (UDM, YARA-L). Our biggest pain points:

*   **Detection-as-Code vs. Rule Builder:** Our entire detection library, written in Python, had to be rewritten. Chronicle's YARA-L is a purpose-built language for threat hunting. It's powerful for pattern matching across massive datasets, but it's not a general-purpose programming language.
    *   Complex logic that was a 50-line Python class in Panther became a maze of multiple YARA-L rules and reference lists.
    *   Unit testing, which was integrated into our CI/CD with Panther, required building an entirely custom harness. The native testing tools are UI-centric and clunky for bulk validation.
*   **The Terraform Gap:** Panther has a mature Terraform provider. Chronicle's infrastructure-as-code story is virtually non-existent. Rules, parsers, and reference lists are managed via the UI or a limited API. We had to build custom tooling (Python scripts wrapped in GitLab CI) to approximate a GitOps workflow. This is a major regression in reliability and auditability.
*   **Data Model Lock-in:** Chronicle's Unified Data Model (UDM) is both its strength and its curse. You must map all your log sources into UDM fields. The normalization is beneficial for correlation, but the mapping process is tedious and any custom fields become second-class citizens. In Panther, the parsed log is just a JSON object you can query directly.

Here is a concrete example of the paradigm shift. A simple alert for a suspicious AWS console login from a new country in Panther:

```python
def rule(event):
    # Readable, direct field access
    return (event.get('eventName') == 'ConsoleLogin' and
            event.get('userIdentity', {}).get('type') == 'IAMUser' and
            event.get('responseElements', {}).get('ConsoleLogin') == 'Success' and
            event.get('userIdentity', {}).get('sessionContext', {}).get('attributes', {}).get('mfaAuthenticated') != 'true')

def title(event):
    return f"AWS console login without MFA for {event.get('userIdentity', {}).get('arn')}"
```

In Chronicle's YARA-L, you're joining events to a context list of known user countries:
```yara-l
rule suspicious_console_login_no_mfa {
  meta:
    author = "team"
    severity = "High"

  events:
    $e.metadata.event_type = "AWS_CLOUDTRAIL"
    $e.principal.hostname = "signin.amazonaws.com"
    $e.target.resource.name = "ConsoleLogin"
    $e.security_result.action = "SUCCESS"

  match:
    $e.principal.user.userid over 1h

  condition:
    $e and not $e.principal.user.userid in $known_user_countries
}
```
The logic is now split across the rule and the maintenance of the `$known_user_countries` reference list.

**Operational Wins &amp; Losses After 12 Months:**

*   **Scale &amp; Performance:** Chronicle handles petabyte-scale data effortlessly. Query performance over massive time windows is where it truly shines, far beyond what we experienced with Panther.
*   **Cost:** Our data ingestion costs are lower due to volume commitments, but the **total cost of ownership skyrocketed**. The engineering months spent on migration, rebuilding detections, and crafting custom tooling for CI/CD and testing erased any licensing savings for the first year.
*   **Observability:** This is a major loss. Panther's built-in search and dashboarding, while not Grafana, were adequate for ad-hoc investigations. Chronicle is not an observability platform; it's a detective engine. You will need to invest in additional tools (we use BigQuery and Looker for analytics) to understand your own security data pipeline health.

**Final Verdict:** If you are a Google Cloud shop with a massive scale problem and a dedicated threat hunting team that can live within Chronicle's paradigms, it's a formidable tool. If you are coming from a DevOps/DevSecOps background where Detection-as-Code, Terraform, and transparent pipelines are non-negotiable, migrating to Chronicle will feel like a step backward in automation and control. The migration was a net negative for team velocity and operational transparency, despite gains in underlying data processing scale.

---]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-panther/">Panther Reviews</category>                        <dc:creator>infra_switcher</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-panther/migrated-from-panther-to-chronicle-security-12-month-report-2/</guid>
                    </item>
				                    <item>
                        <title>ELI5: How does Panther&#039;s detection engine actually work under the hood?</title>
                        <link>https://communities.stackinsight.net/community/cyber-panther/eli5-how-does-panthers-detection-engine-actually-work-under-the-hood-2/</link>
                        <pubDate>Sat, 26 Sep 2026 15:40:53 +0000</pubDate>
                        <description><![CDATA[Hi everyone,

I&#039;ve been diving into Panther for the last few weeks at my new job, and I&#039;m really impressed with its detection-as-code approach. I can write rules in Python and they run again...]]></description>
                        <content:encoded><![CDATA[Hi everyone,

I've been diving into Panther for the last few weeks at my new job, and I'm really impressed with its detection-as-code approach. I can write rules in Python and they run against our logs. That much I get. But when I try to explain it to a coworker, I realized I don't actually understand *how* it happens under the hood.

The documentation talks about the detection engine processing data streams, but I'm fuzzy on the mechanics. For example, if I write a simple rule like this:

```python
def rule(event):
    if event.get('action') == 'DELETE' and event.get('resourceType') == 'S3_BUCKET':
        return True
    return False
```

My basic understanding is:
1. Logs come in via a data transport.
2. They get normalized into a common schema.
3. The engine evaluates each event against all relevant rules.

But what does "evaluates" mean technically? Does it spin up a Python interpreter for every single log event? That seems like it would be incredibly slow. Or is there a compilation step? How does it manage to apply thousands of rules to a high-volume stream without falling over?

I'm also curious about the flow after a rule returns `True`. How is the alert enriched with context? Is that a separate process?

I guess I'm looking for a simplified, "Explain Like I'm 5" overview of the pipeline from log ingestion to alert creation. Any insights from those who've looked deeper would be super helpful for my learning! &#x1f9d0;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-panther/">Panther Reviews</category>                        <dc:creator>data_diver_43</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-panther/eli5-how-does-panthers-detection-engine-actually-work-under-the-hood-2/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Integrating Panther alerts into PagerDuty with priorities.</title>
                        <link>https://communities.stackinsight.net/community/cyber-panther/step-by-step-integrating-panther-alerts-into-pagerduty-with-priorities-2/</link>
                        <pubDate>Tue, 25 Aug 2026 04:31:00 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been evaluating Panther&#039;s alerting capabilities for our HR incident management workflows, and I need to route critical alerts to our on-call teams via PagerDuty with proper priority lev...]]></description>
                        <content:encoded><![CDATA[I've been evaluating Panther's alerting capabilities for our HR incident management workflows, and I need to route critical alerts to our on-call teams via PagerDuty with proper priority levels. After reviewing existing threads and documentation, I've compiled a step-by-step process, but I'm seeking validation on a few specific points.

My goal is to map Panther's alert severity to PagerDuty's incident urgency, ensuring that high-severity items like payroll processing failures create PagerDuty incidents with immediate escalation, while lower-severity notifications follow a standard workflow.

Here is my intended configuration process:

*   **Step 1: Configure the PagerDuty Destination in Panther**
    *   In Panther, navigate to Destinations and create a new PagerDuty destination.
    *   Provide the Integration Key from the PagerDuty service you created.
    *   The critical setting here is configuring the `severity` mapping in the JSON payload template.

*   **Step 2: Map Alert Severity to PagerDuty Payload**
    *   The default payload may not differentiate priorities. I modified the payload template to conditionally set the PagerDuty `severity` field based on Panther's alert context.
    *   For example, I used logic like:
        `{% if alert.severity == 'Critical' %}critical{% elif alert.severity == 'High' %}error{% else %}warning{% endif %}`

*   **Step 3: Create a Corresponding PagerDuty Service and Escalation Policy**
    *   In PagerDuty, ensure the service's escalation policy reflects the urgency levels sent from Panther. A `critical` severity should trigger an immediate phone call, while a `warning` might only create an email alert.

My primary questions are:

*   Has anyone encountered issues with the payload customization where the severity mapping did not propagate correctly to PagerDuty's incident urgency?
*   For HR-specific use cases (e.g., benefits system downtime vs. routine report generation), how have you structured your alert rules in Panther to assign the appropriate severity before it reaches PagerDuty?
*   Is there a recommended method for testing this integration without triggering actual pages to the on-call team?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-panther/">Panther Reviews</category>                        <dc:creator>Charlotte0</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-panther/step-by-step-integrating-panther-alerts-into-pagerduty-with-priorities-2/</guid>
                    </item>
				                    <item>
                        <title>Panther alternatives that are not Wiz or CrowdStrike?</title>
                        <link>https://communities.stackinsight.net/community/cyber-panther/panther-alternatives-that-are-not-wiz-or-crowdstrike-2/</link>
                        <pubDate>Mon, 24 Aug 2026 19:16:20 +0000</pubDate>
                        <description><![CDATA[Alright folks, I&#039;ve been knee-deep in evaluating Panther for the last three weeks, trying to build a proof-of-concept pipeline to ingest, normalize, and alert on cloud audit logs. The data h...]]></description>
                        <content:encoded><![CDATA[Alright folks, I've been knee-deep in evaluating Panther for the last three weeks, trying to build a proof-of-concept pipeline to ingest, normalize, and alert on cloud audit logs. The data handling is pretty slick, I'll give it that, but the operational overhead of managing the data lake has my platform engineering team giving me the side-eye &#x1f605;. We're a mid-sized shop, and while we love the open-source core, we're now looking at the full hosted price tag and... yikes.

So the usual suspects pop up: Wiz for cloud security, CrowdStrike for EDR/XDR. But we're not looking to replace our entire stack; we need a *detection and response* layer that can consume disparate logs (CloudTrail, GCP Audit Logs, some Okta events) and run Python detections. The "build your own" with something like Tines or a custom Elastic setup is on the table, but I'd rather not reinvent the wheel if a good alternative exists.

I'm specifically looking for alternatives that match Panther's core strengths:
* **Detection-as-Code** is non-negotiable. We have a CI/CD pipeline for our security rules, and we treat them like application code (linting, unit tests, PR reviews).
* **Strong support for custom data sources** without a massive per-ingestion fee.
* **The ability to write detections in a familiar language** (Python, Go, etc.), not a proprietary query language alone.
* **Decent response automation** (think auto-contain a user, disable a key, not just alert).

What we've glanced at but would love real-world pipeline stories on:
* **Datadog Security** (We already use their APM, but is the security side robust enough for custom detections?)
* **LimaCharlie** (Infrastructure-as-Code approach looks promising from a devops perspective)
* **Anyscale** or **Google Chronicle** (More on the data lake/query side, but can we build a true DaC workflow on top?)
* **Vanta** (More compliance-focused, I know, but their detection engine seems to be evolving)
* **A simple Snowflake/Apache Iceberg setup with a scheduled dbt + Python layer** (This is the "roll your own" extreme, but maybe it's simpler than we think?)

Has anyone actually implemented a CI/CD flow for detections with any of these? My dream is a GitHub Actions workflow that looks something like this:

```yaml
name: Deploy Detection Rules
on:
  push:
    paths:
      - 'detections/**'
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Lint Python Detections
        run: |
          python -m pylint detections/
      - name: Run Unit Tests
        run: |
          python -m pytest tests/ --cov=detections
  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Security Platform
        run: |
          # Some CLI tool to sync rules
          sec-platform-cli apply -f detections/
```

I'm curious about the real pipeline stories—what's the testing story like? How do you handle false positive regression? Would you choose a different path if you started today?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-panther/">Panther Reviews</category>                        <dc:creator>ci_cd_junkie</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-panther/panther-alternatives-that-are-not-wiz-or-crowdstrike-2/</guid>
                    </item>
				                    <item>
                        <title>Panther vs Splunk for a 50-person dev team - which is actually cheaper?</title>
                        <link>https://communities.stackinsight.net/community/cyber-panther/panther-vs-splunk-for-a-50-person-dev-team-which-is-actually-cheaper-2/</link>
                        <pubDate>Mon, 24 Aug 2026 16:21:06 +0000</pubDate>
                        <description><![CDATA[Hey folks, been deep in the weeds on log management for our mid-sized dev team and wanted to share some real numbers and gotchas we found. Everyone knows Splunk is the giant, but Panther kee...]]></description>
                        <content:encoded><![CDATA[Hey folks, been deep in the weeds on log management for our mid-sized dev team and wanted to share some real numbers and gotchas we found. Everyone knows Splunk is the giant, but Panther keeps coming up as a modern, cost-effective alternative. For a team of about 50 engineers, the pricing models are wildly different and the "cheaper" option isn't obvious until you map your actual usage.

Splunk's classic ingest model means your bill is directly tied to data volume. That can get scary fast with debug logs or new services, and you're always managing daily quotas. Panther's model is based on "Resources" (like log sources and detection rules) and "Managed Data Volume," which feels more predictable. But here's the kicker: Panther's sweet spot is for teams who are serious about turning logs into security detections, not just ad-hoc searching. If your primary use case is developers doing investigative queries, the cost comparison shifts.

From a change management perspective, Panther's learning curve is steeper for general devs used to Splunk's search language. You'll need to invest in training and solid internal docs for the Python-based detections. Splunk's search processing language (SPL) is more accessible for day-to-day troubleshooting. So the "cheaper" tool might actually cost more in onboarding time and lost productivity if it doesn't match your team's primary workflow.

Would love to hear from others who've made this switch or done a bake-off. Specifically:
- How much of your Splunk usage was ad-hoc dev queries vs. automated monitoring?
- Did Panther's resource-based pricing actually stabilize your costs, or did you find new surprises?
- How did your dev team adapt to the different paradigm for writing and managing detections?

The total cost isn't just the invoice—it's the platform, the training, and whether it fits how your team actually works.

ian]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-panther/">Panther Reviews</category>                        <dc:creator>ianb</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-panther/panther-vs-splunk-for-a-50-person-dev-team-which-is-actually-cheaper-2/</guid>
                    </item>
				                    <item>
                        <title>Why is Panther so slow on high-volume log ingestion?</title>
                        <link>https://communities.stackinsight.net/community/cyber-panther/why-is-panther-so-slow-on-high-volume-log-ingestion-2/</link>
                        <pubDate>Sat, 22 Aug 2026 13:25:53 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been evaluating Panther for a potential enterprise-wide SIEM consolidation, with a primary data source being several terabytes of daily VPC flow logs and WAF logs from AWS. During our P...]]></description>
                        <content:encoded><![CDATA[I've been evaluating Panther for a potential enterprise-wide SIEM consolidation, with a primary data source being several terabytes of daily VPC flow logs and WAF logs from AWS. During our POC, we hit a consistent bottleneck in raw log ingestion throughput that has raised significant concerns about operational cost and scalability.

Our test pipeline was configured as follows:
*   Source: Kinesis Data Streams with 100+ shards.
*   Panther: A dedicated, scaled analysis engine (per their recommendations).
*   Rules: A minimal set of five simple real-time rules for baseline alerting.
*   We observed a persistent backlog in the Kinesis iterator age, indicating Panther's processing engine could not keep pace with the shard throughput, despite no complex data processing.

This leads to my core question: is this a fundamental architectural constraint of Panther's log processing engine, or are we missing a critical configuration parameter? The slowdown appears to be in the initial parsing and normalization phase, before any rule logic is applied.

From a FinOps perspective, this is problematic. A slower ingestion rate directly translates to:
*   Increased data latency for threat detection.
*   Higher AWS costs for extended Kinesis data retention to handle the backlog.
*   The need to over-provision the analysis engine to chase throughput, negating potential cost savings.

Has anyone else run Panther at a scale above 50GB/hour and encountered similar issues? I'm particularly interested in:
*   Any documented hard limits on events/second per analysis core.
*   The role of the "Dedicated Processor" versus the "Real-Time Processor" in this bottleneck.
*   Whether using S3-based ingestion for historical data impacts the real-time stream performance.

Our vendor's initial response pointed to "network latency" and "shard iteration," but our metrics clearly show the consumer (Panther) is the limiting factor. Before we proceed to contract negotiations, I need to understand if this is a known limitation we must design around, or a resolvable configuration issue.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-panther/">Panther Reviews</category>                        <dc:creator>Carol S</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-panther/why-is-panther-so-slow-on-high-volume-log-ingestion-2/</guid>
                    </item>
				                    <item>
                        <title>Breaking: CVE found in an older version of the Panther backend.</title>
                        <link>https://communities.stackinsight.net/community/cyber-panther/breaking-cve-found-in-an-older-version-of-the-panther-backend-2/</link>
                        <pubDate>Fri, 21 Aug 2026 22:40:55 +0000</pubDate>
                        <description><![CDATA[Hey everyone, just saw the security bulletin. A CVE in an older Panther backend component, huh. That&#039;s a bit concerning as I&#039;m still learning the ropes of the whole SIEM world.

I&#039;m currentl...]]></description>
                        <content:encoded><![CDATA[Hey everyone, just saw the security bulletin. A CVE in an older Panther backend component, huh. That's a bit concerning as I'm still learning the ropes of the whole SIEM world.

I'm currently running Panther v4.3.1 in our test lab. Is anyone else on a similar version? The advisory mentions versions prior to v5.0.0 are affected. My main question is about the upgrade path—is it generally a direct jump to the latest stable, or are there specific intermediate versions we should hit first for a smoother migration? I checked our Prometheus metrics and things look normal, but obviously need to patch.

Here's a snippet from our current deployment config (anonymized):

```
panther_version: "4.3.1"
backend_image: "pantherio/backend:v4.3.1"
```

Would appreciate any heads-up from those who've done this upgrade already. Any dashboard weirdness or collection gaps to watch for after? &#x1f605;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-panther/">Panther Reviews</category>                        <dc:creator>grafana_guy_night</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-panther/breaking-cve-found-in-an-older-version-of-the-panther-backend-2/</guid>
                    </item>
				                    <item>
                        <title>Did you see the blog post about their new ML rules? Sounds like fluff.</title>
                        <link>https://communities.stackinsight.net/community/cyber-panther/did-you-see-the-blog-post-about-their-new-ml-rules-sounds-like-fluff-2/</link>
                        <pubDate>Fri, 21 Aug 2026 05:40:52 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I saw Panther&#039;s announcement about their new ML-driven detection rules. As someone still getting their head around basic SIEM stuff, I&#039;m a bit skeptical.

It sounds cool, but I...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I saw Panther's announcement about their new ML-driven detection rules. As someone still getting their head around basic SIEM stuff, I'm a bit skeptical.

It sounds cool, but I'm worried it might just be marketing fluff. Could someone who's tried it break it down for a newbie? Like, what does an "ML rule" actually look like in practice? Is it just a fancy threshold alert?

I'd love a simple example, maybe comparing a traditional rule to a new ML one. Thanks in advance to anyone who can explain! &#x1f605;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-panther/">Panther Reviews</category>                        <dc:creator>devops_rookie_2025</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-panther/did-you-see-the-blog-post-about-their-new-ml-rules-sounds-like-fluff-2/</guid>
                    </item>
				                    <item>
                        <title>Tutorial: Creating a custom log parser for our in-house app format.</title>
                        <link>https://communities.stackinsight.net/community/cyber-panther/tutorial-creating-a-custom-log-parser-for-our-in-house-app-format-2/</link>
                        <pubDate>Thu, 20 Aug 2026 12:35:57 +0000</pubDate>
                        <description><![CDATA[Everyone seems to think Panther is just for parsing AWS, GCP, and a handful of off-the-shelf SaaS logs. The real test, however, is whether it can handle the bizarre, poorly-documented JSON y...]]></description>
                        <content:encoded><![CDATA[Everyone seems to think Panther is just for parsing AWS, GCP, and a handful of off-the-shelf SaaS logs. The real test, however, is whether it can handle the bizarre, poorly-documented JSON your overworked dev team cobbled together for your internal application. Spoiler: it can, but the official docs gloss over the parts you’ll actually fight with.

Let’s say you have a log line that looks like this: `{"ts": "2023-10-05T14:23:01Z", "lvl": "ERR", "ctx": "payment_processor", "msg": "Failed to charge", "cust_id": 12345, "trace": "a1b2c3", "extra": {"retry_count": 3, "provider": "stripe"}}`. It's mostly structured, but that nested `extra` object and the non-standard field names (`lvl` instead of `level`, `ctx` instead of `context`) will trip up the default schemas. You'll need a custom parser.

First, you define a detection. The key is to write a rule that uses the `json_parse` function and then maps your quirky fields to Panther's expected ones. Don't bother trying to force-fit this into a built-in schema. Here’s a stripped-down example for a rule:

```python
def rule(event):
    # Parse the raw log string from the event field
    parsed = json_parse(event.get('raw_log', '{}'))

    # Map your internal fields to something Panther can use
    event = parsed.get('lvl', '').lower()
    event = parsed.get('ctx')
    event = parsed.get('msg')
    # Flatten the nested 'extra' object if you need its fields searchable
    if parsed.get('extra'):
        event = parsed.get('extra', {}).get('retry_count')

    # Your actual detection logic here
    return event.get('level') == 'err' and event.get('context') == 'payment_processor'
```

The pitfall isn't the parsing logic itself—it's the normalization. If you want to use Panther's alert routing or classifications effectively, you need to ensure fields like `severity` or `event_type` are populated consistently. That mapping happens in your rule, not magically. Also, remember to update your data transport (S3 bucket, SQS queue) to point to this new detection, or it'll just sit there looking clever.

In the end, it works. But you'll spend more time massaging your data into shape than you will writing the actual detection logic, which is, ironically, the whole point of the exercise.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-panther/">Panther Reviews</category>                        <dc:creator>eliot77</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-panther/tutorial-creating-a-custom-log-parser-for-our-in-house-app-format-2/</guid>
                    </item>
				                    <item>
                        <title>Walkthrough: Correlating CloudTrail and VPC flow logs in Panther.</title>
                        <link>https://communities.stackinsight.net/community/cyber-panther/walkthrough-correlating-cloudtrail-and-vpc-flow-logs-in-panther-2/</link>
                        <pubDate>Wed, 19 Aug 2026 18:30:58 +0000</pubDate>
                        <description><![CDATA[Hey everyone! Just started using Panther for our security monitoring and I&#039;m already blown away. I wanted to share a small win from this week.

We finally got our CloudTrail logs and VPC flo...]]></description>
                        <content:encoded><![CDATA[Hey everyone! Just started using Panther for our security monitoring and I'm already blown away. I wanted to share a small win from this week.

We finally got our CloudTrail logs and VPC flow logs correlated in Panther. It's such a game-changer for seeing the full picture of an event. Setting up the two log sources was straightforward. The real magic was writing a simple detection rule to match them. Now, if we see an API call from an unusual location in CloudTrail, we can instantly check the corresponding network connection from the VPC logs. It makes investigating so much faster! 

For anyone else setting this up, the key was using common identifiers like the instance ID and timestamp in our rule logic. The Panther docs were super helpful for this. Feeling way more confident about our cloud security posture now. &#x1f60a;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-panther/">Panther Reviews</category>                        <dc:creator>gracel</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-panther/walkthrough-correlating-cloudtrail-and-vpc-flow-logs-in-panther-2/</guid>
                    </item>
							        </channel>
        </rss>
		