There are a lot of ways that folks distinguish between blue team roles. My focus is on investigative work and cognitive skills, so I divide those roles into the mental model shown in this diagram. 1/
The primary characteristic that distinguish these investigative roles is their common place in the incident identification and response process. You might be familiar with that process acronym of PICERL, but it appears in many forms: csrc.nist.gov/publications/d…. 2/
In the diagram, the functional portion of the PICERL process is at the top. Each role is listed below that with where it typically fits in relative to those phases. Preparation and Lessons Learned phases are excluded since those are pre and post-investigation steps. 3/
Each role has different inputs and/or outputs that manifest at different phases of this process. For example, triage analysts engage earlier based on alerts, while responders may be engaged later based on confirmed malicious activity. 4/
Each role may also deal with specific forms of evidence more commonly than the others. For example, a forensic examiner will likely interact with disk images much more commonly than a threat hunter. These evidence forms dictate their own toolset for collection and analysis. 5/
The three roles at the top of the diagram are those that I would consider primary investigator roles: Triage, Examiner, and Responder. These folks are mostly concerned with figuring out what happened in relation to an attack. 6/
Triage analysts perform event handling by monitoring alerting queues for IDS output that indicates the presence of anomalous behaviors or relationships on a network. They investigate the alerts to determine if something malicious happened. 7/
Triage:
- Input: IDS Alerts
- Output: Disposition of events
- Evidence: All sources. Heavy reliance on bulk collected events.
8/
Forensic examiner analysts collect and analyze evidence from hosts based on some suspicion of wrongdoing. They build timelines from malicious events that transpired on individual systems. 9/
Incident response analysts work with confirmed malicious activity to identify the scope of an incident. From there, responders work to contain the intrusion and eradicate the attacker. 11/
Responders:
- Input: Reports of likely compromise
- Output: Timeline of relevant events, containment, eradication, and recovery guidance
- Evidence: All sources
12/
The three roles at the bottom of the diagram are what I consider investigation supporting roles: Threat Hunter, Intel Analyst, and Reverse Engineer. Their work enhances the broader investigation effort by providing context that aids the primary roles. 13/
Threat hunters fill in gaps left by automated signature-based detection tools. They perform the human-centric process of proactively searching through networks for evidence of attacks that evade existing security monitoring tools. 14/
Threat Hunters:
- Input: Data
- Output: Identification of suspicious activity or confirmed malicious activity
- Evidence: All sources. Primarily relying on bulk collected events.
15/
Reverse Engineers focus on breaking down and understanding the function and capabilities of suspicious files and malware. 16/
Reverse Engineers:
- Input: Files
- Output: File disposition and capabilities
- Evidence: Host and network events. Files themselves in various forms.
17/
Intel Analysts focus on identifying the characteristics of attackers involved in a breach, including their infrastructure and capabilities. 18/
These are simplifications for the purpose of brevity, and obviously, some folks wear many hats. One person can be a triager, examiner, and responder all in one. Some responders do a little malware RE, some triage analysts will perform threat hunting, and so on. 20/
One of the things I try to do with my research is focus much more on common investigative skills more so than individual roles where they manifest. Those roles are often more of an artifact of places and time than what's happening in folks' heads. 21/
My research generally shows that the primary investigator roles share the same cognitive skills in terms of the investigation process itself. The major difference is the familiarity with specific evidence sources. 22/
There are obviously other skills that matter here beyond the investigative ones -- responders usually need to be decent communicators, for instance. But, the roles are still primarily investigative in function. 23/
The supporting roles are a bit more specialized and unique when compared to other roles. There are some additional things happening cognitively. 24/
Some call upon additional skills, like how RE often requires the ability to understand code at a very basic level using static analysis. That and the things that come with it are not something found so much in the other roles. 25/
Some supporting roles require an increased level of skills that are used a lot already elsewhere. For example, threat hunters rely heavily on anomaly detection and pattern matching. All the other analysts do as well, but it's more prevalent in hunting. 26/
All this to say, this is the mental model I use to help ask, answer, and differentiate some of my research questions. It's also a teaching tool to help new folks understand the relationship of these roles. 27/
There are many ways to represent relationships between roles, but this is where I've stacked it up based on my research. However, it's still just a model... helpful for understanding things, but reductionist and rarely perfect. 28/28
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Y'all remember my Golden Ticket charity fundraiser from last year where you could win free access to ALL my training? Well, good news. It's coming back in December!
I'm planning it now and want to make it even bigger. So...
Last year we raised 46K for charity, which I matched for a total impact of 92K.
This year, I'm looking for individuals or companies to partner with me by matching a portion of the money raised or kicking in funds at specific community donation goals.
One way to help is to offer to match up to $amount of donations.
Another is to offer $amount that you will contribute once the community reaches $goal.
My team will handle the logistics of it all so that it's headache-free. We'll also share with folks that you're helping out.
At it early this morning. It’s going to be a great day. #BBQ
Today, the only thing going on is this beautiful prime brisket. It has my full attention. Just over 12 pounds before trimming, probably closer to 10 now.
I’m often a salt and pepper only guy for brisket, but I’ve been digging the Meat Church rubs lately so I’m trying their Holy Cow on this one. Trimmed and rubbed down last night. On the counter now while the pit warms up.
Since I spend so much time talking to and researching SOCs and SOC analysts, I often get asked, "What the biggest difference is between high and low growth SOCs?"
The answer? Expectations.
1/
First, what do I mean by growth? I'm talking about places where analysts can grow their abilities. These are the places that take complete novices and help them achieve competence or take experienced analysts and help them specialize. Growing human ability.
2/
The organizations that support growth well are those where leadership has high (but realistic) expectations for analysts. These most often center around expecting the analyst to be able to make reliable, evidence-driven decisions confidently.
3/
Like lots of folks, I'm pretty miffed by the lack of robust virtualization support on Apple M1 hardware. I hope that gets fixed soon. But, it also got me to thinking about decision making at big vendors like Apple and others.
1/
For example, the security community (myself included) is often critical of Microsoft for some of their decision-making when it comes to usability/flexibility vs. security. Two things immediately come to mind...
2/
1. Macros. The idea that they exist, are default usable, and the UI pushes users more toward enabling them than disabling them.
2. Default logging configs. Fairly minimal with lots of sec relevant stuff left out (integrate sysmon already!).
3/
A lot of tips about good writing are rooted in the psychology of your reader. For example, if you want your reader to understand a risk (a probability), is it better to express that as a relative frequency (1 in 20) or a percentage (5%)?
1/
Typically, people understand risk better as a frequency. For example, consider the likelihood of a kid dropping out of high school. You could say that 5% of kids drop out, or that 1 in 20 does. Why is the latter more effective?
2/
First, it's something you can more easily visualize. There's some evidence you might be converting the percentage into the frequency representation in your head anyway. Weber et al (2018) talked about this here: frontiersin.org/articles/10.33…
3/
Abstractions are something analysts have to deal with in lots of forms. Abstraction is the process of taking away characteristics of something to represent it more simply. So, what does that looks like? 1/
Well, speaking broadly, let's say that I tell you I had scrambled eggs with parsley and tarragon for breakfast. You can probably picture that very clearly in your mind and it will be fairly accurate to reality. However... 2/
What if I just tell you I just had eggs? Or that I just had breakfast? Your perception of reality may differ greatly from what I actually ate. The abstraction increases opportunity for error.