Risk

12/15/2017
11:00 AM
Joshua Goldfarb
Joshua Goldfarb
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
100%
0%

Is Your Security Workflow Backwards?

The pace at which information security evolves means organizations must work smarter, not harder. Here's how to stay ahead of the threats.

If you're like me, you typically make a list of items you need before you visit the supermarket. Sometimes you end up with a few more items than you planned. But in general, what you leave the supermarket with is about what you expected you would leave with. This is a fairly logical and straightforward way to approach a shopping trip, and so it is no surprise that many people shop this way.

Imagine, if you will, a different approach. What if you went to the supermarket, bought one of every item the store carried, paid for it all, searched through the items you purchased for the items you actually need, and subsequently returned the remaining items to the store? Sounds pretty inefficient and time consuming, doesn't it?

At this point, you're likely asking yourself what this supermarket-based thought exercise has to do with security. I would argue: all too much. You see, if we look at the security operations workflow of many security organizations, it more closely resembles the second supermarket example than the first.

Unfortunately, many security organizations still follow a fairly inefficient and time-consuming workflow. What do I mean by this? Let's enumerate (at a high level) how security organizations typically build their security operations workflow:

  • Sensing technologies, whether network-based, endpoint-based, or intelligence-based, are deployed around the enterprise.
  • Signature sets and detection algorithms are developed internally or leveraged from external sources.
  • An alert cannon ensues, with tens or hundreds of thousands of alerts blasted to the organization's unified work queue on a daily basis.
  • Analysts try to sift through the pile of alerts, looking for those of the highest fidelity, highest priority, and of the utmost urgency.
  • In a time-consuming process, the vast majority of alerts are "returned to the supermarket" (closed as false positives).
  • Rinse and repeat each day.

It may be a bit unnerving and uncomfortable to see this workflow presented so starkly and bluntly. Those who know me know I am a fan of directness, and sometimes it is the best way to get the message across. If you've worked in security operations and incident response for a little while, you know all too well the pain and somewhat illogical nature of the cycle of alert fatigue I've described above.

So what can organizations do to end the absurdity and work in a more logical and efficient manner? They can start by turning their entire security operations workflow on its head. I'll explain.

If we look at the second supermarket example and compare it with the security operations workflow enumerated above, there is a common thread that runs through them both. Instead of prioritizing at the beginning of the workflow, which would allow us to focus, define, and reduce the data set we subsequently need to work with, we prioritize at the end. Of course, the supermarket example illustrates the absurdity of this approach quite clearly. This is something that is much harder for most of us to see when we look at our respective security operations workflows.

So how can organizations prioritize at the beginning of the workflow, and what does that modified workflow look like? Here's an example:

  • Identify and prioritize risks and threats to the organization.
  • Identify assets and prioritize their criticality.
  • Identify where sensitive, critical, and proprietary data resides.
  • Develop targeted, precise, and incisive alert logic to identify activities of concern based on the results of the above three bullet points.
  • Give each resulting alert a priority and criticality score based on the threat it poses to the organization and the criticality of the assets and data it affects.
  • Send the prioritized alerts with associated background information regarding the assets and data they are associated with to the unified work queue.
  • Review the alerts in descending order, from highest priority to lowest.

As I hope you can see, the workflow enumerated here is far more efficient than the one I enumerated earlier. Of course, it takes a bit of an up-front investment in time to prioritize at the beginning of the workflow rather than the end. But this investment pays large dividends: analysts can focus on investigation, analysis, and response, rather than spending their time sifting through piles of false positives and noise.

In addition to allowing an organization to run security operations better and more efficiently, this approach also saves money. How so? Here are a few of the ways:

  • Expensive analyst resources are focused on the highest-value work, which increases team productivity with no additional labor cost.
  • Technology is acquired strategically, efficiently, and precisely — exactly where operational needs dictate and nowhere else.
  • Hardware resources can be optimized to fit the streamlined workflow of the organization, effectively doing more with less.

I don't know too many organizations that have an endless supply of time and money. The pace at which information security evolves means organizations must work smarter rather than harder. Attacking and optimizing the security operations workflow is one of the best ways an organization can improve its security posture.

Related Content:

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
WebAuthn, FIDO2 Infuse Browsers, Platforms with Strong Authentication
John Fontana, Standards & Identity Analyst, Yubico,  9/19/2018
Turn the NIST Cybersecurity Framework into Reality: 5 Steps
Mukul Kumar & Anupam Sahai, CISO & VP of Cyber Practice and VP Product Management, Cavirin Systems,  9/20/2018
NSS Labs Files Antitrust Suit Against Symantec, CrowdStrike, ESET, AMTSO
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Are you sure this is how we get our data into the cloud?
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-17437
PUBLISHED: 2018-09-24
Memory leak in the H5O_dtype_decode_helper() function in H5Odtype.c in the HDF HDF5 through 1.10.3 library allows attackers to cause a denial of service (memory consumption) via a crafted HDF5 file.
CVE-2018-17438
PUBLISHED: 2018-09-24
A SIGFPE signal is raised in the function H5D__select_io() of H5Dselect.c in the HDF HDF5 through 1.10.3 library during an attempted parse of a crafted HDF file, because of incorrect protection against division by zero. It could allow a remote denial of service attack.
CVE-2018-17439
PUBLISHED: 2018-09-24
An issue was discovered in the HDF HDF5 1.10.3 library. There is a stack-based buffer overflow in the function H5S_extent_get_dims() in H5S.c. Specifically, this issue occurs while converting an HDF5 file to a GIF file.
CVE-2018-17432
PUBLISHED: 2018-09-24
A NULL pointer dereference in H5O_sdspace_encode() in H5Osdspace.c in the HDF HDF5 through 1.10.3 library allows attackers to cause a denial of service via a crafted HDF5 file.
CVE-2018-17433
PUBLISHED: 2018-09-24
A heap-based buffer overflow in ReadGifImageDesc() in gifread.c in the HDF HDF5 through 1.10.3 library allows attackers to cause a denial of service via a crafted HDF5 file. This issue was triggered while converting a GIF file to an HDF file.