Leave Your Enchanted Sword at the Door: Turning Your SOC into an RPG

A Snarky, Gloomy Introduction

Security tools are generally easy to learn and use. They integrate into the SOC seamlessly and work synergistically with other tools to enable security practitioners to fulfill their responsibilities effectively and efficiently.

The world within your favorite fantasy role-playing game (RPG) is far more realistic than the fantasy I just described — I promise it was more painful for me to write that than it was for you to read it. Ask any random security practitioner what their experience with security tools and vendors has been and their response will likely involve some combination of swearing, foaming at the mouth, pupil dilation and feverish pacing.

Here’s my take: As a whole, security tools have done a poor job of enabling security practitioners to do their jobs, and I think this is because we don’t have a fair, independent method of assessing a tool’s capabilities. As a result, we’re constantly chasing the latest hotness.

Our assessment of a tool is largely based on the tool’s self-categorization. What has this gotten us? Acronyms and buzz words: SIEM (security information and event management), next-generation, threat intelligence, APT (advanced persistent threats), cloud, EDR (endpoint detection and response), NDR (network detection and response), real-time, more cloud, AI, ML (machine learning) and behavioral analytics. Each term is just so full of excitement and boundless possibility, but what does it do for your SOC? How exactly does it fit into your daily operations?

Now, there’s certainly nothing inherently wrong with any of those terms. Vendors must describe the capabilities their tool has. However, the problem lies in that we only get the story told through the lens of the vendor. What’s missing is the customer’s side of the story. So how can we tell the customer’s story?

A Glimmer of Hope

Let’s talk about a high-performing team — I’m of course referring to your favorite party-based RPG (if you don’t know what I’m talking about, ask your team; there’s bound to be a gamer who can translate).

What does that team look like? Well, you have your tank who dives head first into the fight because they have a vast amount of health and can absorb plenty of damage. There’s a damage dealer who attacks from a distance because they pack a punch but will die from two hits. There’s a healer who’s buffing and healing your party while de-buffing the enemy. Finally, there’s Leeroy Jenkins running around and ruining everything.

With a little bit of strategy and planning, and “forgetting” to invite Leeroy, the described team will likely be successful because each member plays a distinct role that contributes something unique to the team and improves the effectiveness of both each individual team member and the entire team.

Great. What does this have to do with telling the customer’s story?

Role-Playing in the SOC

What roles have you defined within your SOC, and what are those roles based on?

Are they perhaps based on the tools or capabilities at your disposal? Do you have an endpoint person that uses an endpoint tool, a SIEM person drowning in events and so on?

There are two problems with that understandably common approach.

• First, you can end up stuck with a tool that you don’t like because your operations are built around it and changing is too onerous
• Second, defining your operations based on a specific tool can bias them to the tool and leave blind spots

What if instead we defined distinct roles based on general security outcomes that focus on the goal rather than the means used to get there? This approach would allow us to remain tool-agnostic and focus on our needs. We would then be able to fairly assess what our current tool stack covers and whether a new tool fulfills an unmet need.

We can split security operations into four distinct roles:

• Detect
• Hunt
• Investigate
• Intel

Each of these roles has a distinct goal that benefits the team. Let’s explore each role in a little more detail.

Detect

The Detect role is the most commonly implemented within enterprise SOCs. The goal of the Detector is to triage signature-based detections — known bad things in the network that need to be remediated. These detections are typically generated by an automated alerting mechanism and can range from commodity adware on a user’s laptop to a customized backdoor beaconing out from a sensitive server.

The Detector is responsible for triaging the detection, confirming whether it is indeed bad, and escalating as appropriate, perhaps to the Investigator for a deeper look. The Detector performs most effectively when detection signatures are finely tuned and have high fidelity.

If a significant number of detection signatures are noisy or exhibit a high false-positive rate, the Detector is more likely to become overwhelmed and their effectiveness wane.

Finely-tuned and qualified detection signatures are critical for the Detector. Signatures should be properly labeled with confidence/severity/specificity levels to inform the Detector during triage. These values need to be based on real-world performance (not purely opinion) and can fluctuate over time. Most of the effort in this role should be spent triaging detections but triaging a single detection should be efficient and should not require significant effort if the aforementioned conditions are met.

Investigate

The Investigate role, like Detect, is common in enterprise SOCs. The goal of the Investigator is to dig into leads and discover as much information about what happened as possible. These leads are typically generated by the Detectors and Hunters, however tips from other companies and law enforcement are also possible.

The Investigator is responsible for finding answers to questions such as:

• What systems and data were accessed or affected?
• What types of malware are involved?
• What systems and techniques were used for initial entry into the network?
• Does an incident need to be declared?

Listing every question that may arise is not possible, and that is exactly the point. The Investigator performs most effectively when the tools at hand enable them to ask any arbitrary question that may arise and quickly get an accurate answer.

Proper tooling, configuration of security appliances and visibility over relevant data are critical for the Investigator to perform effectively.

Intel

The Intel team is responsible for leveraging access to data and information to discover and track threats to the organization. They support other roles and teams in their prevention, detection and investigation efforts while also informing customers across the organization. The specific responsibilities that Intel could legitimately own are vast. Each organization has unique risks and needs. However, general responsibilities that Intel could own include:

• Providing information and context (think Diamond Model) during an investigation
• Informing, writing and/or curating detection signatures and hunt hypotheses
• Producing consumable, actionable reports on current trends and threats
• Curating technical and behavioral indicators from various sources such as OSINT, ISACs and paid feeds

Notice that list references both tactical and strategic deliverables. A common pitfall Intel teams can face is becoming too focused on either strategic or technical deliverables — both are critical to the organization.

Invoking the Diamond model again, the technology axis informs tactical processes, such as signature creation, while the socio-political axis informs the organization’s overall security strategy.

Established communication channels and clear requirements are critical for Intel. Deliverables produced by the Intel team should be consumable and actionable by the target audience, and feedback from the target audience should be incorporated into Intel’s processes to ensure organizational needs are met.

Hunt

The Hunt role is the least common, especially in small- to medium-sized organizations, because it can be difficult to hire for and is often poorly defined. The goal of the Hunter is to discover previously unknown threat activity through hypothesis-driven analysis and escalate as appropriate. They may, however, discover security posture issues as a by-product. The range of potential outputs unrelated to threat activity is wide, but common examples include converting a hunt into a detection signature, working with architects to remediate visibility gaps and sharing the discovery of unpatched systems.

The Hunter overlaps with the Detector in that both aim for the discovery of threats, but they differ in scope. The Detector is limited to known signatures of malicious activity, while the Hunter explores data generically outside of the bounds of known signatures. Working outside what is known requires the Hunter to accept lower fidelity methods and leverage more generic analytical approaches but enables them to produce findings that potentially wouldn’t be identified otherwise.

Rigorous analysis and tracking outcomes are critical for the Hunter. The Hunter should ensure their hunts and analysis methods are designed as efficiently and effectively as possible. Hunts may evolve over time, so specific steps, and any changes, should be documented thoroughly. Outcomes should also be documented thoroughly. A common pitfall for Hunters is to only view threat activity as a finding. Security posture issues are just as important and should be escalated and tracked just as vigorously as threat-related findings.

Wrapping Up

Your team is gathered outside the Cave of Silver Echoes, preparing to face the Winged Chimera. This boss is slow and lumbering, has a large amount of health, deals heavy damage but in a limited attack radius, and can cast a health regeneration buff. What’s your plan?

Well, running in and attacking wildly (looking at you Leeroy of the group — you know who you are) might work for about 47 seconds but that’s not a recipe for success in this situation. Someone needs to act as the tank, having tons of health and staying right by the Chimera to absorb all attacks. Someone needs to be the healer, de-buffing the Chimera and buffing the tank so they are better able to absorb those heavy hits. Someone needs to deal damage, so the battle ends at some point. They can be a mage launching fireballs or an archer raining down arrows. The specifics don’t matter — only the role.

Here’s another example, this time in the context of security.

Let’s say Intel wrote a detection signature to look for unauthorized outbound traffic from the organization’s external web servers based on their latest assessment of high-risk assets in the environment. Once in place, the detection signature identifies three external web servers that have downloaded coin miners. The Detector would triage, confirm and forward this lead over to the Investigator. While digging into this lead, the Investigator identifies an unpatched application on the servers that was exploited to cause the coin miner downloads. The Investigator would forward their findings to Intel, and Intel would then be responsible for working with the web server team to patch the vulnerability, working with the Detector and Hunter to temporarily increase monitoring of the remediated web servers to watch for reinfection, and maintaining a record of the compromise for future use.

Notice how I didn’t need to mention a specific tool to describe the different roles, how they would function and what their outcomes would be? The role is the critical piece. Organizing the SOC into the four goal-oriented roles of Detect, Hunt, Investigate and Intel allows you to define and implement effective procedures that are tool-agnostic. This in turn helps standardize how you assess tools and better determine whether they fit your needs and can help accomplish your goals.

The Customer Success team supporting Gigamon Insight uses these roles to inform our training materials, including the scenarios available in our training environment, so stock up on health potions, grab your trusty enchanted sword and get ready to vanquish the Winged Chimera! …or at least keep coin miners off your web servers.

Join us in the Gigamon Community’s newest group, Network Detection and Response to let us know your role and discuss this and other related topics.