Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Threat Intelligence

6/13/2019
02:00 PM
Nik Whitfield
Nik Whitfield
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

The CISO's Drive to Consolidation

Cutting back on the number of security tools you're using can save money and leave you safer. Here's how to get started.

Industry reports vary, but experts estimate that the modern CISO uses somewhere between 55 and 75 discrete security products. Vendors are often guilty of overpromising and underdelivering — the reality rarely lives up to the marketing. This puts CISOs in an ironic situation — often, the tool they bought to make their lives easier ended up causing more headaches.

This is an endemic issue, but what do you do when you have too many tools that integrate poorly, require different expertise, and provide too much data but not an overall view to the security risk level? Consolidation sounds attractive. After all, what CISO wouldn't want to reduce clutter, cut costs, and simplify procedures — but where to start?

Begin with Data Quality
CISOs know there is no perfect solution for security. Clearly, multiple security solutions are needed to cover the security controls. However, CISOs should strive to maximize the value of each investment and reduce the number of tools. To cut through the noise and data coming from tools (specifically, those that identify vulnerabilities and control failures), a great place to start is by increasing the confidence that data coming out them is complete and accurate.

By taking measures to ensure that the data is accurate, CISOs can drive remediation more efficiently and know what to fix first to get the greatest ROI on their security investments. It also leads to getting access to automated analytics and reducing the need to manually work through multiple reporting processes for different tools.

Approaching Consolidation
A key reason that CISOs have too many tools is that they have continued to buy tools and rarely decommission any; this results in in overlapping functionality but doesn't always close all gaps in coverage.

We need to consolidate/reduce the number of security tools we use, and we need to establish discipline around the process of adding new security solutions. This is not as simple as going through each of the tools and deciding if it adds value or if its function is or can be provided by another tool. Instead, we need to determine which security tools are needed by using two core fundamentals: Each security tool should align with a significant risk in the security framework, and each tool implemented should reduce risk to the company, be able to measure the reduction in risk, and be capable of sustaining that risk reduction.

Aligning with a Security Framework
By developing a security framework based on National Institute of Standards and Technology or some other standard, and then selecting a set of security controls around each category of security, a comprehensive view of your security landscape can be developed. From that view, we can take each significant area of security and begin to develop systems and processes that achieve those controls.

Only after developing these processes do we begin to select tools that help implement and control the processes. Each tool should fulfill a specific need in the security controls framework. For example, let's take the area of system vulnerability management. We shouldn't start picking our tool to scan our systems until we understand all of the controls that manage the process to patch our systems on a timely and complete basis. We should only select the appropriate tool(s) once we understand what it or they must achieve.

How to Approach Consolidation
The objective of having security systems is to lower the risk of an event that negatively affects the company (e.g., financial, reputational, or regulatory risk). We must keep this in mind when designing processes and selecting security tools. As we implement security processes and tools, we should ensure that the end solution does the following:

  • Covers the entire intended landscape across the company. For example, if we scan only 70% of the environment for system vulnerabilities, we may not adequately reduce risk to the company.
  • Provides sufficient information to act. For example, if we select a system vulnerability scanner and it provides great detail on the vulnerability and inherent risk but does not provide context to the importance to the company or context as to the owner of the system, then the tool/system is not providing sufficient information to reduce the risk sufficiently.
  • Sustains the control, meaning it should automate the control and monitoring processes. Otherwise, the risk will grow again after expending efforts and monies to remediate.

To further refine the approach to security tools, we also need to address risk. All systems and tools do not provide the same level of risk reduction. By focusing on those security domains that carry the highest risk, one can prioritize the selection and implementation of security tools.

By taking this risk-based, end-to-end, and sustainable approach to implementing security processes (and their related tools), we can begin to permanently solve areas of security that historically have remained despite all the tools and money we have thrown at them. Armed with this newly available knowledge, we can permanently solve some longstanding areas of security.

Ultimately, with enhanced data quality and automation plus the consolidation of tools, CISOs can confidently enhance their company's cyber-risk posture.

Related Content:

Nik Whitfield is the founder and CEO at Panaseer. He founded the company with the mission to make organizations cybersecurity risk-intelligent. His  team created the Panaseer Platform to automate the breadth and depth of visibility required to take control of ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.