Attacks/Breaches
1/7/2016
10:30 AM
Joshua Goldfarb
Joshua Goldfarb
Commentary
Connect Directly
Twitter
RSS
E-Mail
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 is an experienced information security analyst with over a decade of experience building, operating, and running Security Operations Centers (SOCs). Josh currently serves as VP and CTO - Emerging Technologies at FireEye. Until its acquisition by FireEye, Josh served as ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How To Build An Effective Defense Against Ransomware
A compendium of Dark Reading´s best recent coverage of ransomware attacks, as well as best practices for defending your enterprise against them.
Flash Poll
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7445
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

CVE-2015-4948
Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

CVE-2015-5660
Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

CVE-2015-6003
Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

CVE-2015-6333
Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
Tim Wilson speaks to two experts on vulnerability research – independent consultant Jeremiah Grossman and Black Duck Software’s Mike Pittenger – about the latest wave of vulnerabilities being exploited by online attackers