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
High Stress Levels Impacting CISOs Physically, Mentally
Jai Vijayan, Freelance writer,  2/14/2019
Valentine's Emails Laced with Gandcrab Ransomware
Kelly Sheridan, Staff Editor, Dark Reading,  2/14/2019
Making the Case for a Cybersecurity Moon Shot
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  2/19/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-15380
PUBLISHED: 2019-02-20
A vulnerability in the cluster service manager of Cisco HyperFlex Software could allow an unauthenticated, adjacent attacker to execute commands as the root user. The vulnerability is due to insufficient input validation. An attacker could exploit this vulnerability by connecting to the cluster serv...
CVE-2019-3474
PUBLISHED: 2019-02-20
A path traversal vulnerability in the web application component of Micro Focus Filr 3.x allows a remote attacker authenticated as a low privilege user to download arbitrary files from the Filr server. This vulnerability affects all versions of Filr 3.x prior to Security Update 6.
CVE-2019-3475
PUBLISHED: 2019-02-20
A local privilege escalation vulnerability in the famtd component of Micro Focus Filr 3.0 allows a local attacker authenticated as a low privilege user to escalate to root. This vulnerability affects all versions of Filr 3.x prior to Security Update 6.
CVE-2019-10030
PUBLISHED: 2019-02-20
A sandbox bypass vulnerability exists in Jenkins Script Security Plugin 1.52 and earlier in RejectASTTransformsCustomizer.java that allows attackers with Overall/Read permission to provide a Groovy script to an HTTP endpoint that can result in arbitrary code execution on the Jenkins master JVM.
CVE-2019-10030
PUBLISHED: 2019-02-20
A exposure of sensitive information vulnerability exists in Jenkins Cloud Foundry Plugin 2.3.1 and earlier in AbstractCloudFoundryPushDescriptor.java that allows attackers with Overall/Read access to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through anoth...