ELI5: How does Panther's detection engine actually work under the hood?

Alright, let's pull back the curtain on Panther's detection engine, because marketing says "real-time detection" and my middleware PTSD demands I know what that *actually* means before I pipe 10k events per second into it.

Based on tearing apart their Python-based rule definitions and observing the execution patterns, here's the ELI5 without the fluff: think of it as a highly specialized, distributed `grep` on steroids that runs your Python logic instead of regex. It's not magic; it's a pipeline.

The core flow breaks down like this:

1. **Ingestion & Normalization:** Everything (CloudTrail, Okta, your custom app logs) gets shoved into a normalized JSON schema. This is the unsung hero. If you've ever tried to correlate a GCP audit log with an Azure AD event, you know the pain. Panther maps everything to a common set of fields (`p_any_ip_addresses`, `p_any_domain_names`). This step alone saves you 200 lines of data munging per rule.

2. **Rule Evaluation Trigger:** This isn't a simple cron job. It's event-driven. A new log arrives → the system determines which rules *might* apply based on pre-filters (like `RuleFilters` in the rule definition). No point running a GCP-specific rule on a GitHub event. This is where they avoid the "scan everything, always" performance nightmare.

3. **The Actual "Under the Hood" Execution:** Here's where your Python rule code runs. They embed a Python runtime (CPython, from what I can trace). Your rule isn't interpreted line-by-line in some slow DSL; it's compiled into bytecode. The environment is intentionally sandboxed (no arbitrary `import os`). You get a decorated function with the event as a parameter. The key is they parallelize the hell out of this. Thousands of events can be evaluated against the same rule simultaneously across workers.

```python
# A simplified skeleton of what your rule logic runs inside.
def rule(event):
# Your custom logic here, operating on the normalized event.
if event.get('eventType') == 'AWS::ConsoleLogin':
if event.get('userIdentity', {}).get('userName') == 'root':
return True
return False

def title(event):
# You build the alert title dynamically.
return f"Root console login detected for [{event.get('sourceIPAddress')}]"
```

4. **Alert Deduplication & Intelligence:** This is the "detection" part, not just the "matching" part. A simple match creates an alert. But they apply severity mappings, aggregate identical alerts over a time window (so a brute-force attack doesn't spam you with 500 identical alerts), and can run them against external contexts (like a threat intel list you've uploaded). The real-time claim mostly holds here, but remember, "real-time" after normalization and queueing. Expect latency in the seconds, not milliseconds.

The horror story tangent? I once built a naive version of this myself. The queue management alone took a team of three. Panther's engine is essentially a managed, scalable version of that nightmare, with the key value being the normalized data model and the parallelized, sandboxed Python execution. It's not an AI black box; it's a well-engineered rules engine. The real "gotcha" isn't the engine—it's writing efficient rule logic that doesn't make unnecessary network calls or O(n²) operations on massive events.