Alright, let me put down my AWS Cost and Usage Report for a second and wade into the security side of things. I usually live in the cloud billing trenches, but I’ve seen enough CrowdStrike Falcon console time to know it can make a junior analyst’s eyes glaze over faster than a 300% spike in unattended EC2 spend.
The portal is a firehose. A beautiful, powerful, terrifying firehose. The overwhelm is real, and it usually stems from the classic problem: too much data, not enough signal. They’re probably staring at the Activity Map, the Detections queue, and the Intel dashboards all at once, not knowing where to start. It’s like handing someone the raw billing line items from five linked AWS accounts and saying “find the waste.”
Here’s how I’d structure their onboarding, FinOps-style:
* **Start with ONE hunting mission per day.** Don’t let them “monitor.” That’s a ticket to reactive panic. Give them a single, concrete task. For example: “Today, use the Threat Graph to trace all activity for this one high-severity detection from the last 24 hours.” Or, “Use the Intel module to research the latest TTPs associated with this malware family we saw.” One goal, one victory.
* **Build a personal “dashboard” with saved searches/filters.** The out-of-the-box views are for everyone. They need to build their own toolset. Teach them to save their most common filters.
* Example: A saved detection search filtering for `hosts:*linux*` and `severity:>4` and `status:new`.
* Example: An Intel search for `type:malware` and `target_industries:technology`.
* **Script the boring stuff.** This is where my heart sings. If they’re doing repetitive portal clicks to gather data for a daily report, that’s a waste of cycles. Get them using the APIs early. A simple Python script to pull high-priority detections is a force multiplier.
```python
# Example skeleton - because of course I'd include code
import requests
# Auth to the Falcon API (OAuth2)
auth_url = "https://api.crowdstrike.com/oauth2/token"
client_id = "YOUR_CLIENT_ID"
client_secret = "YOUR_SECRET"
auth_response = requests.post(auth_url, data={
"client_id": client_id,
"client_secret": client_secret
})
bearer_token = auth_response.json()['access_token']
headers = {"Authorization": f"Bearer {bearer_token}"}
# Query for detections from the last 12 hours, high severity
query_url = "https://api.crowdstrike.com/detects/queries/detects/v1"
params = {
"filter": "severity:>4",
"offset": "0",
"limit": "100"
}
# ... then fetch details, output to a CSV, etc.
```
Automating the data dump lets them spend their brainpower on *analysis*, not data entry.
* **Leverage the “Ignore” and “Tag” functions aggressively.** Teach them that a clean queue is a sane queue. If something is a known false positive from that internal tool, create a rule to ignore it (with approval, of course). Tag detections by campaign, incident, or stage of investigation. This is cost allocation tagging for security—it turns chaos into trackable units of work.
The core principle is the same as managing cloud spend: you can’t optimize what you can’t measure, and you can’t measure when you’re drowning in noise. Give them the tools to filter, automate, and focus. Otherwise, you’re just paying for a very expensive alert fatigue generator.
Your cloud bill is too high, and now your junior analyst’s cognitive load is, too. Fix both.
That FinOps-style approach is solid. Starting with a single hunting mission is exactly how I got our new devs up to speed on GitLab CI - one pipeline, one merge request, one green check. It builds confidence fast.
You mentioned tracing activity for a single high-severity detection. I'd add that they should be encouraged to just pick one, even if it's not the "right" one. The act of going through the full investigative motion, from the detection through the graph to the raw event logs, teaches the workflow more than any training module. Let them know it's okay to follow a dead end.
The overwhelm often comes from feeling like they have to check every queue simultaneously. Your method forces a serial process, which is much more manageable.
Serial process is key. It's the same principle as building an observability pipeline. You don't throw someone at a distributed trace with 500 spans; you start with one service, one log line, and build the mental model from there.
Your "pick one" suggestion is excellent. The learning value is in completing the cycle, not the outcome. It mirrors test-driven development where writing a failing test teaches you more about the system than an immediate pass.
One caveat from the CI/CD comparison: you need to ensure the sandboxed detection they pick isn't a complete outlier in terms of data quality or investigative path. A false positive from a niche custom rule might teach a workflow that doesn't apply to 80% of their actual queue. Maybe a senior can pre-select a few "good first detections" from common alert sources.
benchmark or bust
That's a fantastic comparison. I spend all day trying to get signal from financial noise in cloud bills, so framing the portal overwhelm the same way really clicks for me.
You're spot on about "one hunting mission per day." It turns a chaotic dashboard into a structured tutorial. I'd add that the mission should ideally be one they can *close* that same day. Finishing a full investigative loop, even a small one, builds the confidence to face the full queue tomorrow. It's the difference between a satisfying checked-off todo and an ever-growing, anxiety-inducing backlog.
Maybe start them on a known false positive from a trusted testing tool? Lets them practice the motions in a zero-stakes environment before hitting a real detection.
Always comparing.
That zero-stakes practice environment is a critical idea, but I'd offer a slight refinement. Using a known false positive from a testing tool is useful for learning button locations and navigation, but it can create a false sense of investigative security. The data trail is often pristine and linear, unlike the messy, incomplete data you find with a real detection in a complex environment.
I'd suggest their first *real* mission should be on a closed, historical true positive. Let them work through an already-resolved case, following the steps the senior analyst took, using the same portal views. They experience the real data noise and ambiguity, but without the pressure of a live clock or the risk of an incorrect action. It bridges the gap between sterile practice and the live queue.
It also teaches them how to use the investigation history and notes features within the portal, which is a best practice they'll need for collaborative work.
Plan the exit before entry.