Our team has been using Cybereason for about nine months now, and we've noticed a consistent learning curve for new analysts joining the SOC. To help standardize the onboarding, I just finished putting together an internal training module specifically for our Level 1 analysts.
The module focuses on the core workflows they'll use daily: triaging MalOps, interpreting the MalOp tree effectively, and using the Action Center for basic response. We built it around a series of realistic but contained lab scenarios using our own internal test environment. The goal is to move them from basic console navigation to making confident, documented decisions on common alert types.
I'm curious how others have approached internal training for specific EDR platforms. What did you find was the most critical foundational skill for your L1s? Did you focus more on the tool's interface initially, or on the investigative logic using the tool as a vehicle?
We're also debating whether to include a section on common pitfalls, like over-relying on automated scores without checking the underlying evidence. Any lessons learned from your own teams would be valuable as we plan the next iteration.
—HR
The investigative logic is 100% the foundation. The tool interface changes.
We built ours around the concept of "follow the evidence, not the score." A specific pitfall we included was new analysts taking the automated MalOp verdict as final. We made them document three pieces of supporting evidence from the tree before closing anything.
Critical skill for L1s? Knowing when to escalate vs. when they have enough to conclude. Our labs force a decision with incomplete data to teach that judgment call.
Benchmarks or bust.
Good that you're focusing on realistic labs, that's the only way they'll retain it. The foundational skill isn't navigation or even evidence gathering. It's teaching them the platform's specific data model, because everything else is built on that misunderstanding.
You asked about pitfalls. The biggest one I see is analysts not understanding what the tool is *actually* showing them. For example, in the MalOp tree, the relationship between a process, its parent, and any network connections isn't always chronological or causal in the way the UI suggests. If they don't get the underlying data structure, they'll misread the story. Your lab on "interpreting the tree" should first force them to explain, in plain English, what each node type represents and where that data comes from. Otherwise they're just clicking colorful boxes.
Include your pitfall about over-relying on scores, but pair it with a scenario where the automated score is low but the raw evidence is damning. Make them argue against the tool's own verdict. That's when they start to actually learn.
Been there, migrated that