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
Valentine's Emails Laced with Gandcrab Ransomware
Kelly Sheridan, Staff Editor, Dark Reading,  2/14/2019
High Stress Levels Impacting CISOs Physically, Mentally
Jai Vijayan, Freelance writer,  2/14/2019
Mozilla, Internet Society and Others Pressure Retailers to Demand Secure IoT Products
Curtis Franklin Jr., Senior Editor at Dark Reading,  2/14/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-7629
PUBLISHED: 2019-02-18
Stack-based buffer overflow in the strip_vt102_codes function in TinTin++ 2.01.6 and WinTin++ 2.01.6 allows remote attackers to execute arbitrary code by sending a long message to the client.
CVE-2019-8919
PUBLISHED: 2019-02-18
The seadroid (aka Seafile Android Client) application through 2.2.13 for Android always uses the same Initialization Vector (IV) with Cipher Block Chaining (CBC) Mode to encrypt private data, making it easier to conduct chosen-plaintext attacks or dictionary attacks.
CVE-2019-8917
PUBLISHED: 2019-02-18
SolarWinds Orion NPM before 12.4 suffers from a SYSTEM remote code execution vulnerability in the OrionModuleEngine service. This service establishes a NetTcpBinding endpoint that allows remote, unauthenticated clients to connect and call publicly exposed methods. The InvokeActionMethod method may b...
CVE-2019-8908
PUBLISHED: 2019-02-18
An issue was discovered in WTCMS 1.0. It allows remote attackers to execute arbitrary PHP code by going to the "Setting -> Mailbox configuration -> Registration email template" screen, and uploading an image file, as demonstrated by a .php filename and the "Content-Type: image/g...
CVE-2019-8909
PUBLISHED: 2019-02-18
An issue was discovered in WTCMS 1.0. It allows remote attackers to cause a denial of service (resource consumption) via crafted dimensions for the verification code image.