-
-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Connect RE&CT with Threat Detection/Hunting, Detection Rules, etc #291
Comments
I was seeing it from your point of view and while I am building content to share with your project and our folks. Identification is more than just a dead ringer detection (good in itself), but also scoping the incident and looking for other tactics. Because if you are using the techniques to detect, you need to validate and respond to the tactic and follow the attack flow forward and reverse. If you find execution... Did you find privilege escalation or credential actions? Did you find the delivery mechanism? Techniques can give you a mirada of things to check for with TD and never ending with TH. Because there is an inverse relationship to false positive and false negative detections which is the more you tune out false positives the more you tune in a false negative (true positive) that you can't see. By using the other Tactics as an identification / investigative task you can minimize the chances of missing something you tuned out. My approach to your project slightly changed in two distinct ways. Customization of the phases to include non-security use cases and different phase interpretations (one I know you have already discussed) and lastly, using phases as compartmentalized process. Example: "investigate - Execution" phase has all the necessary components for that phase and can be used regardless of the attack vector (email, web, host, external device, network). This makes the phases modular and reusable. So in summary, I would take a more AT&ACK Tactic approach mentioned to validating a detection vs single end to end use case approach to each detection to IR response... This way you can consolidate and reuse responses effectively independent of the TD and techniques. |
@socologize I like the concept of
and I use a similar method in thehive where I group by ATT&CK tactics. I'd be keen to speak with you more about your implementation @yugoslavskiy please correct me if I'm wrong. I get the impression that you associate ATT&CK with TH & TD but not IR? The way I have been implementing the framework for a compromised workstation playbook is by using the ATT&CK framework - especially the tactics - to guide what an analyst should look for (most IR tools use the same data sources). For example:
I agree to some degree with
A way around this would be the ability for subgroups (Initial Action, Execution etc). This would probably a drastic change for the framework but for a compromised workstation playbook (which arguably would be used the most), imo of course, this makes the most sense. |
Hello @reg-reginald! Thank you for your interest in the project!
Not really. Short answer: Both ATT&CK and RE&CT could be used for IR. I just don't see the reason why we need to copy the ATT&CK part to the RE&CT, as it could stay there and we can just use references to it; Currently, we are looking for a solution to work it out. What I've tried to say is that there are functions that both TD and IR use to achieve their goals, and the intersection is in the Identification stage. As there is already a separate framework that classifies threat behaviors and helps people to Detect threats, there is no reason to copy/paste the stuff to RE&CT. What we really need, is to identify borders and connections with the TD process, that relies on ATT&CK. That would be an optimal way in my opinion.
Could you please elaborate on this?
The compromised workstation playbook could include most of the existing Response Actions and even more. At the same time, the playbooks have a very limited scope of cases (simple ones), as most of the complex attacks require a very complex chain of Response Actions, coordination and cannot be described in one playbook (at least in the way it would be useful for a team). That's why our focus at the moment is to define atomic Response Actions and describe how to make them work in the most efficient way. Then users will compile the Playbooks for themselves, as they are quite different for each organization. |
I believe that line is, or should be, well defined. Incident Detection (Threat Detection) is the activity typically performed by the Security team (Cyber or Physical) to determine if suspicious activity is malicious/criminal (a threat) through analysis/investigation/evidence collection/review. Incident Response is the activity initiated by the Cyber/Physical Security team but performed (or should be performed) by teams other than the Security teams to contain/isolate, eradicate, and recover from the 'incident'. Security can/should oversee those activities, and provide facts/evidence of whats been discovered to guide it. In some limited cases, the Cyber team can be 'deputized/authorized' to perform limited containment activities (isolate workstations and/or single user accounts, etc). Beyond that, for me, the 'business' and/or infrastructure teams should be making the decisions (which critical servers/systems/accounts/processes to isolate/disable/shutdown etc), performing the hands on keyboard activities, and they 'should' have DR plans to be followed to recover and restore operations that their teams follow to restore the business back to normal.
This is my vote and personally I think it its the same as this.
A good hypothesis should be based on intel. If it's not based on intel its 'chasing rabbits' to me and typically doesn't find anything actually criminal. When someone hunts deer - will they more likely have a successful hunt if they pick a spot with deer feeders and wildlife cameras showing there are actual deer in the area or would they be more successful if they wanted to 'make it a challenge' and wander around in the back country hoping to cross paths with a 68 point buck? To be a successful hunter, you leverage intel to increase your chances of success. I could have made a football analogy using watching film of your opponents, but I recently went on a successful deer hunt (for me) and decided that analogy would be the one since my son wanted to wander around and try to 'stalk his deer'.. You can guess how that turned out.. lol |
I was thinking again about this issue and thought how about making atc-detect (aka DET&CT) to collect these threat detection activities which are used to prepare, detect, share and communicate in the broader area of threat detection. These steps are important during IR for the TD part / getting more context but too during threat detection outside of incident reponse. While searching for DET&CT I came across DeTT&CT Mapping your Blue Team to MITRE ATT&CK™, their Github Repo DeTTECT and their editor.
Agree. Adding every counterpart for an ATT&CK technique overloads the IR RE&CT framework.
So basically, you suggest to bring more response actions to RE&CT from the view of ATT&CK but omit having each techniques covered individually. The use of the tactic is a good way and someone would then jump to ATT&CK for detailed information what to detect exactly. Instead of
we would then add more abstract response actions like
Here it is important to have a clear way to add specific actions (listing registry keys, listing processes) vs. these generic one for ATT&CK tactic because they will overlap. I currently don't know where the line should be. And here some ideas (for DET&CT or RE&CT?) with more threat detection focused actions..
|
The context
We need to be on the same page to discuss the problem and solution of Incident Response (IR) and Threat Detection (TD) connection. Here is some information that will provide you with the required context.
Threat Hunting or Threat Detection?
There are many definitions of Threat Hunting (and while I am writing this message there would be a new one invented), but here are some most common ones:
There are many others, so it's really confusing.
You never know what people mean when they say "Threat Hunting".
And usually, the first thing I do is ask "what is your definition?".
But we are not going to focus on it.
The point here is that anyway, Threat Hunting is always about proactively detecting a threat.
Threat Hunting is a method, a function, an approach of Threat Detection.
Threat Detection is a wider area that includes all methods of detection.
This simplification helps us to be on the same page.
Where IR and TD processes intersect
The Identification Stage of the Incident Response process includes searches/lookups for malicious activity.
When there is a confirmed intrusion ongoing (an attacker is already inside the infrastructure), the Incident Response Team needs to know which hosts/assets were attacked. It could be done by searching for discovered IoC/IoA (related to the operating Threat Actor) for the entire infrastructure and developing new Detection Rules for further attacks.
At the same time, these activities (Detection Rules development, IoC/IoA lookups) are executed by the Threat Detection Team, when there is no ongoing intrusion, during the normal operations. In that case, the source of intel (IoC/IoA) is not the IR process/team but Cyber Threat Intelligence — threat research activities, threat intel feeds, etc.
But it wasn't always this way.
Historical background: TD as a part of IR
In the early to mid-2010s, there were not so many Detection Engineers and information about Threat Detection in general. That time, it was nearly impossible to find information about logs you need to collect, artifacts left by some adversary's TTPs, and any possible ways to detect malicious activity. Of course, there were some research papers on specific attack techniques detection (i.e., DNS tunneling) published, but it wasn't systematized knowledge or an established area of focus.
The only place where detection techniques were somehow collected/systematized was the DFIR area — Digital Forensics & Incident Response articles, courses, books, blogs, researches, etc.
A good example is SANS FOR572 — Advanced Network Forensics & Analysis training, where you could learn how to detect network attacks/malicious activities using networking data.
I felt like only Incident Responders supposed to know how to detect threats, and the only time for it is the ongoing incident.
Mid-2010s, time to change
With time, the global community realized that we need to shift focus from reactive to proactive detection, based not on the ongoing incident and observed IoC/IoA, but by applying general knowledge about threats and researching the TTP in advance. "Intel-Driven" aka "Threat-Based" aka "Threat-Informed" defense started getting more and more popular. MITRE published ATT&CK. This idea started being more and more clear, understood, and getting popular.
And with that — Threat Detection, Threat Simulation, and other areas also grew up quickly. There were (and still are):
And many more.
There were many signs of ongoing transformation.
The signs that proactive detection is on its way to becoming an independent, separate process of Security Operations.
And now, in 2020, nobody questions that. But still, there is some level of uncertainty.
Back to the topic: The problem
The border between Incident Response (IR) and Threat Detection (TD) is not clearly defined because TD is a relatively new area. It is being established. Or it is already established, but not for all.
If we go "the old" way (not separating TD functions from IR), we would have to develop Response Actions to lookup Indicators of Attack for every potentially malicious activity. And that is all MITRE ATT&CK techniques. And this will make RE&CT extremely comprehensive, hard to understand, hard to maintain, and less useful.
The solution
Go "the new" way. Describe connections between IR and TD processes. Leave in RE&CT only things that are not included in TD, and used exclusively by IR teams. Provide a high-level description of the things that are used by both IR and TD.
The question for the discussion
How to define that split between IR and TD?
How to not go too deep into TD stuff and focus more on IR stuff?
The current proposal and the way RE&CT has been developed so far:
Move forward with investigative searches. The lookups that will help to explain the connection between particular processes/actions on a compromised system. The searches that will help to pivot from one evidence to another.
The only question here is how to organize (develop) Response Actions like "lookups for well-known malicious/suspicious activity", i.e., persistence artifacts, ASEPs, process injections, lateral movement, etc.
We could split them by ATT&CK tactics, creating Response Action per Tactic, i.e. "Lookup for Lateral Movement artifacts".
What do you think?
The text was updated successfully, but these errors were encountered: