Adding an Event Triage Drop to the Community Bucket
Wednesday, November 18, 2015
By failing to prepare, you are preparing to fail.
~ Benjamin Franklin
Let's also stop saying if company X looked into their alerts then they would had seen there was a security issue. We need to start providing more published information instructing others how to actually triage and build workflows to respond to those alerts. If we don’t share and publish practical information about triaging workflows then we shouldn’t be pointing out the failures of our peers.
~ Corey Harrell
As soon as you can get past the fact that I quoted myself in my own article those two quotes really show a security predicament people and companies are facing today. Companies are trying to implement or improve their security monitoring capabilities to gain better visibility about threats in their environment. Defenders are looking to gain or improve their skills and knowledge to enable them to perform security monitoring and incident response activities for companies. On the one hand, according to Ben Franklin we need to take steps to prepare ourselves and if we don’t then we will fail. This means defenders need to constantly work to improve their knowledge, skills, and workflows so they are better prepared to perform security monitoring and incident response activities. If they aren’t preparing then most likely they will fail when they are called upon to respond to a security incident. On the other hand, according to myself as a community we don’t publish and share a lot of resources that others can use to improve their knowledge, skills, and workflows related to performing security monitoring and incident response activities. Please don’t get me wrong. There is some great published information out there and there are those who regularly share information (such as Harlan and Brad Duncan) but these individuals are in the minority. This brings us to our current security predicament. We need to prepare. We lack readily available information to help us prepare. So numerous companies are failing when it comes to performing security monitoring and incident response activities.
As I was thinking about this predicament I was wondering how I can contribute to the solution instead of just complaining about the problem. I know my contribution will only be a drop in a very large bucket but it will be a drop nonetheless. This post outlines the few drops that will start appearing on jIIr.
A common activity defenders perform is event triage. Event triage is the assessment of a security event to determine if there is a security incident, its priority, and the need for escalation. A defender performs this assessment repeatedly as various technologies alert on different activity, which generates events for the defender to review. As I explored this area for my $dayjob I found that most published resources say you need to triage security events but most didn’t provide practical information about how to actually do it. My hope is I can make at least a small contribution to this area.
Objective
My purpose is to provide resources and information to those seeking to improve their knowledge, skillsets, and workflows for event triage.
Method
I will periodically publish two posts on jIIr. The first post will outline a hypothetical scenario and a link will be provided to a limited data set. The data set will contain four or less artifacts that need to be analyzed to successfully complete the scenario. When performing event triage most of the time only a subset of data needs to be examined to successfully assess the event. To encourage this line of thinking I’m limiting the dataset to at most four artifacts containing information required to solve the scenario. The datasets will be pulled from the test systems I build to improve my own skills, knowledge, and workflows. If I’m building and deleting these systems I might as well as use them to help others. I’ll try to make the datasets resemble what may be available in most environments such as operating system artifacts, logs, and IDS alerts. Accompanying the dataset may be a document briefly explaining how to perform a specific task such as generating IDS alerts by replaying a packet capture in Security Onion. The scenarios will reflect areas I have or am working on so the type of simulated incidents will be limited. Please keep in mind, similar to performing event triage for a company some of my scenarios may be false positives.
The second post will be published between one to three weeks after the first post. The second post will outline a triage process one could use to assess the security event described in the scenario. At a minimum, the process will cover: where in a network this information can be found, how to collect this information, free/open source tools to use, how to parse the artifacts in the provided dataset, and how to understand the data you are seeing. The triage process will be focused on being thorough but fast. The faster one can triage a single event the more events they can process. If I come across any other DFIR bloggers who published how they triaged the security event then this post will contain links to their websites so others can see how they approached the same problem.
Summary
My hope is this small contribution adds to the resources available to other defenders. Resources they can use to improve their workflows, skills, and knowledge. Resources they can use to better prepare themselves instead of preparing to fail.
To anyone I do help better prepare themselves, I only ask for one thing in return. For you to take a few minutes of your time to purposely share something you find useful/helpful with someone in your life. The person can be anyone you know from a co-worker to colleague to a fellow student to a complete stranger asking for help online. Take a few minutes of your life to share something with them. Losing a few minutes of our time has minimum impact on us but it can make a huge difference in the lives of others and possibly help them become better prepared for what they may face tomorrow.
God bless and Happy Hunting.
~ Benjamin Franklin
Let's also stop saying if company X looked into their alerts then they would had seen there was a security issue. We need to start providing more published information instructing others how to actually triage and build workflows to respond to those alerts. If we don’t share and publish practical information about triaging workflows then we shouldn’t be pointing out the failures of our peers.
~ Corey Harrell
As soon as you can get past the fact that I quoted myself in my own article those two quotes really show a security predicament people and companies are facing today. Companies are trying to implement or improve their security monitoring capabilities to gain better visibility about threats in their environment. Defenders are looking to gain or improve their skills and knowledge to enable them to perform security monitoring and incident response activities for companies. On the one hand, according to Ben Franklin we need to take steps to prepare ourselves and if we don’t then we will fail. This means defenders need to constantly work to improve their knowledge, skills, and workflows so they are better prepared to perform security monitoring and incident response activities. If they aren’t preparing then most likely they will fail when they are called upon to respond to a security incident. On the other hand, according to myself as a community we don’t publish and share a lot of resources that others can use to improve their knowledge, skills, and workflows related to performing security monitoring and incident response activities. Please don’t get me wrong. There is some great published information out there and there are those who regularly share information (such as Harlan and Brad Duncan) but these individuals are in the minority. This brings us to our current security predicament. We need to prepare. We lack readily available information to help us prepare. So numerous companies are failing when it comes to performing security monitoring and incident response activities.
As I was thinking about this predicament I was wondering how I can contribute to the solution instead of just complaining about the problem. I know my contribution will only be a drop in a very large bucket but it will be a drop nonetheless. This post outlines the few drops that will start appearing on jIIr.
A common activity defenders perform is event triage. Event triage is the assessment of a security event to determine if there is a security incident, its priority, and the need for escalation. A defender performs this assessment repeatedly as various technologies alert on different activity, which generates events for the defender to review. As I explored this area for my $dayjob I found that most published resources say you need to triage security events but most didn’t provide practical information about how to actually do it. My hope is I can make at least a small contribution to this area.
Objective
My purpose is to provide resources and information to those seeking to improve their knowledge, skillsets, and workflows for event triage.
Method
I will periodically publish two posts on jIIr. The first post will outline a hypothetical scenario and a link will be provided to a limited data set. The data set will contain four or less artifacts that need to be analyzed to successfully complete the scenario. When performing event triage most of the time only a subset of data needs to be examined to successfully assess the event. To encourage this line of thinking I’m limiting the dataset to at most four artifacts containing information required to solve the scenario. The datasets will be pulled from the test systems I build to improve my own skills, knowledge, and workflows. If I’m building and deleting these systems I might as well as use them to help others. I’ll try to make the datasets resemble what may be available in most environments such as operating system artifacts, logs, and IDS alerts. Accompanying the dataset may be a document briefly explaining how to perform a specific task such as generating IDS alerts by replaying a packet capture in Security Onion. The scenarios will reflect areas I have or am working on so the type of simulated incidents will be limited. Please keep in mind, similar to performing event triage for a company some of my scenarios may be false positives.
The second post will be published between one to three weeks after the first post. The second post will outline a triage process one could use to assess the security event described in the scenario. At a minimum, the process will cover: where in a network this information can be found, how to collect this information, free/open source tools to use, how to parse the artifacts in the provided dataset, and how to understand the data you are seeing. The triage process will be focused on being thorough but fast. The faster one can triage a single event the more events they can process. If I come across any other DFIR bloggers who published how they triaged the security event then this post will contain links to their websites so others can see how they approached the same problem.
Summary
My hope is this small contribution adds to the resources available to other defenders. Resources they can use to improve their workflows, skills, and knowledge. Resources they can use to better prepare themselves instead of preparing to fail.
To anyone I do help better prepare themselves, I only ask for one thing in return. For you to take a few minutes of your time to purposely share something you find useful/helpful with someone in your life. The person can be anyone you know from a co-worker to colleague to a fellow student to a complete stranger asking for help online. Take a few minutes of your life to share something with them. Losing a few minutes of our time has minimum impact on us but it can make a huge difference in the lives of others and possibly help them become better prepared for what they may face tomorrow.
God bless and Happy Hunting.
Labels:
triage
Posts
Sign me up!
I think it's great that you're doing this...I just told someone today that I'm considering either a book or series of blog posts entitled, "Investigating Windows Systems", done in a case study-style format.
@Harlan,
I just hope I'm able to find the time to create more scenarios for servers. That is a good idea for either a book or blog series. I tend to find material like this useful. Both for myself and for pointing people to it. I enjoying reading about the approaches and thought processes behind how others tackle an issue. Your idea is along these lines.
@Corey,
"I just hope I'm able to find the time to create more scenarios for servers."
I know that when I've written my books, some will say, "yeah, you're going to cover the workstation OS, but what about the server OS?" Well, the fact of the matter is that I don't have access to server OS's except through work, and well...
My point is that someone should be willing to step up and provide something...VM, access to a install CD and code...something.
"I enjoying reading about the approaches and thought processes behind how others tackle an issue. "
A lot of folks in the community say the same thing...the difference is that you're one of the very few who actually share these things. Most folks won't sit down and just write what they did during an exam.
@Corey,
Thanks for taking the time to put these scenarios together - I know its a lot of work. I am particularly interested in exactly what you described above regarding the triage workflows, tools, etc. and love the format you propose. Can't wait to see the first scenario.
I also understand what you and @Harlan are saying in terms of information sharing. Up to this point, I am guilty of being one of the idle consumers; however my role has recently changed and I hope to be in a position to contribute back.
Let me know if there is anything I can do to help with this initiative.
This is a great idea Corey. I was actually just going back through all of your older posts (wasn't around back then to read them), and this will be a great way to start putting the ideas you mentioned in to practice. (End-to-End Investigations, and Forensicator Readiness for example.)
As a current student of this field, I've found that the course work just can't fit in everything, obviously, and so posts like these from you, @Harlan Carvey, and others working in the field already, really give me insight on some things to focus on.
I'm looking forward to working on these practicals and implementing what I learn from them into my course work and my self-study down the road.