Attacks/Breaches

1/7/2016
10:30 AM
Joshua Goldfarb
Joshua Goldfarb
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
100%
0%

The Matrix Reloaded: Security Goals v. Operational Requirements

Building a matrix that measures people, process, and technology against security goals is a proven method for reducing risk in an organization. Here's how.

Those of us who work in the information security field have grown accustomed to a certain level of hype and noise. While I could certainly wax poetic about this topic, I’d like to take a slightly different angle. Where there is hype, there is a need to cut through that hype. With the overwhelming amount of noise in the security marketplace today, how can organizations make any sense of it?  I’d like to try and answer that very question.

In my experience, building out a matrix of operational requirements can assist greatly in the task of evaluating security products and services.  It helps organizations ensure that they improve their security posture, rather than damage or impede it.  But how can an organization build out such a matrix?  And what additional benefits does this matrix bring an organization?  Let’s take a look at those questions in additional detail.

Understand Risk

Every organization faces threats to its security.  In turn, those threats introduce some amount of risk to the organization. Each organization faces different threats, and each threat will introduce a different amount of risk. The goal of a security program should ultimately be to minimize and mitigate risk, with the understanding that risk can never be eliminated.

It therefore follows that before an organization can understand its operational needs, it must first understand the risk it faces. That understanding begins by understanding the threat landscape the organization is facing. What types of attacks do similar organizations (perhaps by industry vertical, geographic location, size, or otherwise) face?  What sensitive, confidential, and/or proprietary information are attackers after?  What are some of the ways in which attacks succeed, persist, and result in theft of coveted information?  These are just a few of the many ways in which the threat landscape can be analyzed.

Understanding the threat landscape is a start, but without being able to map it to an understanding of risk, it doesn’t do an organization much good.  How would the organization detect an intrusion or other illicit activity?  What gaps in telemetry exist that could prevent or inhibit detection or analysis?  What skill sets are lacking or in short supply?  What procedural shortcomings exist?  How can the workflow be improved or made more efficient?  There are many ways in which an organization can work towards understanding the risks it faces, of which these questions represent just a few different perspectives.

Set Goals

Understanding the risks and threats to the organization is a first step, but it is still too abstract to facilitate the buildout of a matrix of operational requirements.  What is needed is an intermediary step. This involves breaking the enumerated list of risks down into goals and priorities.

Goals and priorities are much more tangible, specific, and focused than the list of risks.  Each one describes a step along the journey to mitigating a given risk. This is a one to many relationship here. For each risk, there may be many goals and priorities required to properly address it.  Once a list of goals and priorities has been assembled, it can be used to build out the desired matrix of operational requirements.

Enter The Matrix

The goals and priorities enumerated for each risk form the building blocks for the matrix of operational requirements.  On one axis goes people, process, and technology, while on the other axis, the consolidated, de-duplicated goals and priorities.  The resulting matrix spells out what is needed operationally to ensure an adequate security posture for the organization. 

In some cases, people, process, and technology that can be leveraged to mitigate certain risks may already be in place.  In other cases, you may need to develop a specific solution. Using the matrix to identify where gaps exist allows an organization to strategically acquire the necessary people, process, and technology to address the remaining challenges.

There are two additional benefits to using this approach that the astute reader may pick up on:

●     Value is maximized: The security budget can be put to its most efficient use by acquiring the minimum number of solutions that meet the maximum number of requirements.

●     Complexity is reduced:  Acquiring fewer solutions reduces complexity.  Success is much less likely with a haphazard pile of products and services that don’t work well together and don’t meet operational requirements.

The concern organizations have for their security postures has grown considerably over the last few years.  In many cases, budget has increased along with those concerns. But -- not surprisingly -- this has resulted in a noisy, hype-filled marketplace that can be confusing to operational information security professionals.  You can cut through the hype by approaching the challenges of technology acquisition and gap analysis with a matrix of operational requirements

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
'Hidden Tunnels' Help Hackers Launch Financial Services Attacks
Kelly Sheridan, Staff Editor, Dark Reading,  6/20/2018
Inside a SamSam Ransomware Attack
Ajit Sancheti, CEO and Co-Founder, Preempt,  6/20/2018
Tesla Employee Steals, Sabotages Company Data
Jai Vijayan, Freelance writer,  6/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-12697
PUBLISHED: 2018-06-23
A NULL pointer dereference (aka SEGV on unknown address 0x000000000000) was discovered in work_stuff_copy_to_from in cplus-dem.c in GNU libiberty, as distributed in GNU Binutils 2.30. This can occur during execution of objdump.
CVE-2018-12698
PUBLISHED: 2018-06-23
demangle_template in cplus-dem.c in GNU libiberty, as distributed in GNU Binutils 2.30, allows attackers to trigger excessive memory consumption (aka OOM) during the "Create an array for saving the template argument values" XNEWVEC call. This can occur during execution of objdump.
CVE-2018-12699
PUBLISHED: 2018-06-23
finish_stab in stabs.c in GNU Binutils 2.30 allows attackers to cause a denial of service (heap-based buffer overflow) or possibly have unspecified other impact, as demonstrated by an out-of-bounds write of 8 bytes. This can occur during execution of objdump.
CVE-2018-12700
PUBLISHED: 2018-06-23
A Stack Exhaustion issue was discovered in debug_write_type in debug.c in GNU Binutils 2.30 because of DEBUG_KIND_INDIRECT infinite recursion.
CVE-2018-11560
PUBLISHED: 2018-06-23
The webService binary on Insteon HD IP Camera White 2864-222 devices has a stack-based Buffer Overflow leading to Control-Flow Hijacking via a crafted usr key, as demonstrated by a long remoteIp parameter to cgi-bin/CGIProxy.fcgi on port 34100.