Perimeter

4/10/2018
10:30 AM
Joshua Goldfarb
Joshua Goldfarb
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
50%
50%

20 Ways to Increase the Efficiency of the Incident Response Workflow

Despite all the good intentions of some great security teams, we are still living in a "cut-and-paste" incident management world.

I am a big fan of efficiency. Why do I love efficiency? Mainly because introducing efficiencies into processes saves time and money. There are other benefits as well, such as decreased chance for human error, improved accuracy, and increased productivity.

Unfortunately, in the incident response world, the overall state of inefficiency still reigns supreme. Despite the good intentions of some great security teams, we are still largely living in a "cut-and-paste" incident management world. I know quite a few talented teams in good organizations that struggle to introduce efficiencies into their incident response process.

That's not to say that there aren't a lot of people talking about introducing efficiencies into incident response. But somehow all that talk hasn't resulted in a lot of change on the ground. There are likely a number of different reasons. Part of me wonders if there is a gap in understanding where organizations end up sinking time on manual incident management tasks. Perhaps it would help to enumerate areas where organizations are likely begging for efficiencies in their incident response workflow. Here are 20:

Image Credit: DuMont Television/Rosen Studios. Public domain, via Wikimedia Commons.
Image Credit: DuMont Television/Rosen Studios. Public domain, via Wikimedia Commons.

  1. Intelligent mapping between alerts/events and tickets/work queue. A security organization may work with billions of events, tens or hundreds of thousands of alerts, and hundreds of tickets on a given day. Alerts are typically generated automatically based on logic covering one or more events. One can debate the quality and fidelity of the alerts, but the process is relatively automated. But which of the alerts makes it into a ticket that needs to be worked? Unfortunately, that process is far less well-defined and for the most part, intensely manual.
  2. Pre-emptive prioritization. It has always amazed me that we wait until our alerts get into our work queue before thinking about prioritization. That means that our teams need to comb through tens of thousands of data points that add little to no value to our security postures in order to get to the data points that do add value. Why not think about the risks and threats we face and look to prioritize at the beginning of the content development process, before a single alert finds its way to the work queue?
  3. Front-loading analytics. Why run analytics over a mass of data whose context and meaning we know very little about? Why not run analytics strategically at the beginning of the content development process to produce higher-quality alerts and more contextually aware, meaningful data to send to the work queue?
  4. User identification. We all need to identify the user when looking into an alert. So, why do we continue to do this step manually?
  5. Asset identification. See No. 4.
  6. Vet the alert. Chances are that we check the same five or 10 things when vetting most alerts. We might even follow a written procedure instructing us how to vet a given family of alerts. So why do we not automate much of this work?
  7. Understand the alert. Once we vet an alert, we need to gain at least a basic understanding of what is going on. That typically involves reviewing the alert, along with additional supporting evidence. Why not pull in that supporting evidence automatically?
  8. Extract IOCs. Chances are that if you're investigating something involving malicious code or a malicious link, you will want to extract the indicators of compromise for a variety of reasons. In 2018, don't you wish you didn't have to perform this step manually?
  9. Build the narrative. Decisions require context and understanding. So, as you build the narrative around the alert you're investigating, wouldn't you prefer to have much of the manual work done for you automatically so that you can focus on analysis and incident response?
  10. Analyze. Ah, analysis. Quite possibly your favorite part of the entire workflow. So, why are you still cutting and pasting into and out of Excel? Can't we do better than that?
  11. Identify the infection/intrusion vector. As one result of all of our analysis, we'll want to identify gaps in our security posture and close them. Chances are that once we identify any gaps, we will need to log in to one or more entirely separate system to take any action toward closing those gaps.
  12. Pivot. Once we have isolated one or more hosts that are behaving oddly, we will likely want to pivot to study what those very hosts have been up to recently. Yup, you guessed it. That likely involves cutting and pasting, along with setting up additional queries.
  13. Look for related activity. Once we have a decent understanding of what we're working with, another type of pivot that needs to happen is one that will enable us to look for similar types of activity elsewhere. I know you won't be surprised when I tell you that we are once again looking at a lot of cutting and pasting, alongside additional queries.
  14. Identify/fill gaps in alerting. In the event that we missed something important, we will need to understand why and address the gap in alerting. Of course, we will need to drive this process ourselves. Wouldn't it be nice if our tooling could suggest how we might identify something we missed more proactively in the future?
  15. Identify root cause. After any incident, it's important to understand what the root cause was. But that is a very manual process. Wouldn't it be nice to have some assistance here?
  16. Improve security posture. Say I discover a new set of malicious domains or something analogous. I might want to block it, sinkhole it, or do something else. Manually, of course.
  17. Include everything in the ticket. I once worked for a boss who said, "If it isn't written down, it didn't happen." He was absolutely right. But why does recording everything in the incident ticket have to involve so much cutting and pasting?
  18. Report. Large or serious incidents typically involve a post-incident report. If I already recorded all of the important details in my incident ticket, why do I need to redo all that work to put together a respectable report that I can be proud to share with management, executives, and other stakeholders?
  19. Communicate. Clear, concise, and timely communication can make all the difference in handling an incident. So, why do I find myself cutting and pasting into emails instead of pulling automatically from the system out of which I'm running the incident?
  20. Extract lessons learned. No security program is perfect. We can always take lessons learned from anything we work with. Wouldn't it be great to have a little help from our tooling?

Related Content:

Interop ITX 2018

Join Dark Reading LIVE for a two-day Cybersecurity Crash Course at Interop ITX. Learn from the industry’s most knowledgeable IT security experts. Check out the agenda here. Register with Promo Code DR200 and save $200.

Josh (Twitter: @ananalytical) is an experienced information security leader with broad experience building and running Security Operations Centers (SOCs). Josh is currently co-founder and chief product officer at IDRRA and also serves as security advisor to ExtraHop. Prior to ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
White House Cybersecurity Strategy at a Crossroads
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/17/2018
The Fundamental Flaw in Security Awareness Programs
Ira Winkler, CISSP, President, Secure Mentem,  7/19/2018
Number of Retailers Impacted by Breaches Doubles
Ericka Chickowski, Contributing Writer, Dark Reading,  7/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-14492
PUBLISHED: 2018-07-21
Tenda AC7 through V15.03.06.44_CN, AC9 through V15.03.05.19(6318)_CN, and AC10 through V15.03.06.23_CN devices have a Stack-based Buffer Overflow via a long limitSpeed or limitSpeedup parameter to an unspecified /goform URI.
CVE-2018-3770
PUBLISHED: 2018-07-20
A path traversal exists in markdown-pdf version <9.0.0 that allows a user to insert a malicious html code that can result in reading the local files.
CVE-2018-3771
PUBLISHED: 2018-07-20
An XSS in statics-server <= 0.0.9 can be used via injected iframe in the filename when statics-server displays directory index in the browser.
CVE-2018-5065
PUBLISHED: 2018-07-20
Adobe Acrobat and Reader 2018.011.20040 and earlier, 2017.011.30080 and earlier, and 2015.006.30418 and earlier versions have a Use-after-free vulnerability. Successful exploitation could lead to arbitrary code execution in the context of the current user.
CVE-2018-5066
PUBLISHED: 2018-07-20
Adobe Acrobat and Reader 2018.011.20040 and earlier, 2017.011.30080 and earlier, and 2015.006.30418 and earlier versions have an Out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure.