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.

Perimeter

11/30/2017
01:00 PM
Adam Shostack
Adam Shostack
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

The Critical Difference Between Vulnerabilities Equities & Threat Equities

Why the government has an obligation to share its knowledge of flaws in software and hardware to strengthen digital infrastructure in the face of growing cyberthreats.

In mid-November, Rob Joyce, the White House cybersecurity coordinator, released a set of documents about the "vulnerabilities equities process," which he noted in a recent White House blog post:

At the same time, governments must promote resilience in the digital systems architecture to reduce the possibility that rogue actors will succeed in future cyber attacks. This dual charge to governments requires them to sustain the means to hold even the most capable actor at risk by being able to discover, attribute, and disrupt their actions on the one hand, while contributing to the creation of a more resilient and robust digital infrastructure on the other. Obtaining and maintaining the necessary cyber capabilities to protect the nation creates a tension between the government’s need to sustain the means to pursue rogue actors in cyberspace through the use of cyber exploits, and its obligation to share its knowledge of flaws in software and hardware with responsible parties who can ensure digital infrastructure is upgraded and made stronger in the face of growing cyber threats. 

This is a valuable step in the right direction, and the people who've done the work have worked hard to make it happen. However, the effort doesn't go far enough, and those of us in the security industry have an urgent need to go further to achieve the important goals that Joyce lays out: improving our defenses with knowledge garnered by government offensive and defensive operations. 

This is intended as a nuanced critique: I appreciate what's been done. I appreciate that it was hard work, and that the further work will be even harder. And it needs to be done.

The heart of the issue is our tendency in security to want to call everything a "vulnerability." The simple truth is that attackers use a mix of vulnerabilities, design flaws, and deliberate design choices to gain control of computers and to trick people into disclosing things like passwords. For example, in versions of PowerPoint up to and including 2013, there was a feature where you could run a program when someone "moused over" a picture. I understand that feature is gone in the latest Windows versions of PowerPoint but still present in the Mac version. I use this and other examples just to make the issues concrete, not to critique the companies. 

This is not a vulnerability or a flaw. It's a feature that was designed in. People designed it, coded it, tested it, documented it, and shipped it. Now, can an attacker reliably "weaponize" it by shipping it with a script in a zip file, for example, by referring to a UNC path to \\example.org\very\evil.exe? I don't know. What I do know is that the process as published and described by Joyce explicitly excludes such issues. As stated in the blog post:

The following will not be considered to be part of the vulnerability evaluation process:

    • Misconfiguration or poor configuration of a device that sacrifices security in lieu of availability, ease of use or operational resiliency.
    • Misuse of available device features that enables non-standard operation.
    • Misuse of engineering and configuration tools, techniques and scripts that increase/decrease functionality of the device for possible nefarious operations.
    • Stating/discovering that a device/system has no inherent security features by design.

These issues are different from vulnerabilities. None of them is a bug to fix. I do not envy the poor liaison who gets to argue with Microsoft were this feature to be abused, nor the poor messenger who had to try to convince Facebook that their systems were being abused during the elections. However senior that messenger, it's a hard battle to get a company to change its software, especially when customers or revenue are tied to it. I fought that battle to get Autorun patched in shipped versions of Windows, and it was not easy.

However, the goal, as stated by Joyce, does not lead to a natural line between vulnerabilities, flaws, or features. If our goal is to build more resilient systems, then we need to start by looking at the issues that happen — all of them — and understanding all of them. We can't exclude the ones that, a priori, are thought to be hard to fix, nor should we let a third party decide what's hard to fix. 

The equities process should be focused on government's obligation to share its knowledge of flaws in software and hardware with responsible parties who can ensure digital infrastructure is upgraded and made stronger in the face of growing cyberthreats. Oh, wait, that's their words, not mine. And along the way, "flaws" gets defined down to vulnerabilities.

At the same time, our security engineering work needs to move from vulnerability scanning and pen tests to be comprehensive, systematic, and structured. We need to think about security design, the use of safer languages, better sandboxes, and better dependency management. We need to threat model the systems we're building so that they have fewer surprises.

That security engineering work will reduce the number of flaws and exploitable design choices. But we'll still have clever attackers, and we need the knowledge that's gained from attack and defense to flow to software engineers in a systematic way. A future threats equities process will be a part of that, and industry needs to ask for it to be sooner rather than later.

Related Content:

 

Adam is a consultant, entrepreneur, technologist, author and game designer. He's a member of the BlackHat Review Board and helped create the CVE and many other things. He currently helps organizations improve their security via Shostack & Associates, and advises startups ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Where Businesses Waste Endpoint Security Budgets
Kelly Sheridan, Staff Editor, Dark Reading,  7/15/2019
How Attackers Infiltrate the Supply Chain & What to Do About It
Shay Nahari, Head of Red-Team Services at CyberArk,  7/16/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-13961
PUBLISHED: 2019-07-18
A CSRF vulnerability was found in flatCore before 1.5, leading to the upload of arbitrary .php files via acp/core/files.upload-script.php.
CVE-2019-13962
PUBLISHED: 2019-07-18
lavc_CopyPicture in modules/codec/avcodec/video.c in VideoLAN VLC media player through 3.0.7 has a heap-based buffer over-read because it does not properly validate the width and height.
CVE-2019-10101
PUBLISHED: 2019-07-18
OECMS v4.3.R60321 and v4.3 later is affected by: Cross Site Request Forgery (CSRF). The impact is: The victim clicks on adding an administrator account. The component is: admincp.php. The attack vector is: network connectivity. The fixed version is: v4.3.
CVE-2019-10102
PUBLISHED: 2019-07-18
MailCleaner before c888fbb6aaa7c5f8400f637bcf1cbb844de46cd9 is affected by: Unauthenticated MySQL database password information disclosure. The impact is: MySQL database content disclosure (e.g. username, password). The component is: The API call in the function allowAction() in NewslettersControlle...
CVE-2019-10102
PUBLISHED: 2019-07-18
Open Information Security Foundation Suricata prior to version 4.1.3 is affected by: Denial of Service - TCP/HTTP detection bypass. The impact is: An attacker can evade a signature detection with a specialy formed sequence of network packets. The component is: detect.c (https://github.com/OISF/suric...