Vulnerability Exploitability eXchange (VEX)

CISA has a neat bit of work they recently published, entitled “Vulnerability Exploitability eXchange (VEX) – Status Justifications” (warning: opens to .pdf.).1 Product security teams that adopt VEX could assert the status of specific vulnerabilities in their products. As a result, clients’ security staff could allocate time to remediate actionable vulnerabilities instead of burning time on potential vulnerabilities that product security teams have already closed off or mitigated.

There are a number of different machine-readable status types that are envisioned, including:

  • Component_not_present
  • Vulnerable_code_not_present
  • Vulnerable_code_cannot_be_controlled_by_adversary
  • Vulnerable_code_not_in_execute_path
  • Inline_mitigations_already_exist

CISA’s publication spells out what each status entails in more depth and includes diagrams to help readers understand what is envisioned. However, those same readers need to pay attention to a key caveat, namely, “[t]his document will not address chained attacks involving future or unknown risks as it will be considered out of scope.” Put another way, VEX is used to assess known vulnerabilities and attacks. It should not be relied upon to predict potential threats based on not-yet-public attacks nor new ways of chaining known vulnerabilities. Thus, while it would be useful to ascertain if a product is vulnerable to EternalBlue, today, it would not be useful to predict or assess the exploited vulnerabilities prior to EternalBlue having been made public nor new or novel ways of exploiting the vulnerabilities underlying EternalBlue. In effect, then, VEX is meant to address the known risks associated with N-Days as opposed to risks linked with 0-Days or novel ways of exploiting N-Days.2

For VEX to best work there should be some kind of surrounding policy requirements, such as when/if a supplier falsely (as opposed to incorrectly) asserts the security properties of its product there should be some disciplinary response. This can take many forms and perhaps the easiest relies on economics and not criminal sanction: federal governments or major companies will decline to do business with a vendor found to have issued a deceptive VEX, and may have financial recourse based on contactual terms with the product’s vendor. When or if this economic solution fails then it might be time to turn to legal venues and, if existent approaches prove insufficient, potentially even introduce new legislation designed to further discipline bad actors. However, as should be apparent, there isn’t a demonstrable requirement to introduce legislation to make VEX actionable.

I think that VEX continues work under the current American administration to advance a number of good policies that are meant to better secure products and systems. VEX works hand-in-hand with SBOMs and, also, may be supported by US Executive Orders around cybersecurity.

While Canada may be ‘behind’ the United States we can see that things are potentially shifting. There is currently a consultation underway to regenerate Canada’s cybersecurity strategy and infrastructure security legislation was introduced just prior to Parliament rising for its summer break. Perhaps, in a year’s time, we’ll see stronger and bolder efforts by the Canadian government to enhance infrastructure security with some small element of that recommending the adoption of VEXes. At the very least the government won’t be able to say they lack the legislative tools or strategic direction to do so.

  1. You can access a locally hosted version if the CISA link fails. ↩︎
  2. For a nice discussion of why N-days are regularly more dangerous then 0-Days, see: “N-Days: The Overlooked Cyber Threat for Utilities.” ↩︎

Grand Visions Fizzle in Brazil

The NYT has an incredibly depressing view of the way that Brasil is moving forward; while much of it is shared by the citizens of that country the article is overly one-sided and generally lacks a comprehensive understanding of why some of the cost overruns and setbacks have happened. We read that environmental protections and efforts to work with aboriginal people’s have led to railroads being delayed: why were there such expectations of a smooth and quick development of such railroads in the first place? Perhaps because the ‘frictions’ of such development (i.e. environment and people living on the land) had been cast aside?

What is largely missing throughout the piece is the context: why were certain projects put forward and then abandoned? In the absence of such context we’re left with the impression that the setbacks are the result of poor management and bureaucracy but is this the case, or simply the projection of American values onto specific South American infrastructure decisions?


Another ‘Victory’ for the Internet of Things

Researchers have found, once again, that sensitive systems have been placed on the Internet without even the most basic of security precautions. The result?

Analyzing a database of a year’s worth of Internet scan results [H.D. Moore]’s assembled known as, as well as other data from the 2012 Internet Census, Moore discovered that thousands of devices had no authentication, weak or no encryption, default passwords, or had no automatic “log-off” functionality, leaving them pre-authenticated and ready to access. Although he was careful not to actually tamper with any of the systems he connected to, Moore says he could have in some cases switched off the ability to monitor traffic lights, disabled trucking companies’ gas pumps or faked credentials to get free fuel, sent fake alerts over public safety system alert systems, and changed environmental settings in buildings to burn out equipment or turn off refrigeration, leaving food stores to rot.

Needless to say, Moore’s findings are telling insofar as they reveal that engineers responsible for maintaining our infrastructures are often unable to secure those infrastructures from third-parties. Fortunately, it doesn’t appear that a hostile third-party has significantly taken advantage of poorly-secured and Internet-connected equipment, but it’s really only a matter until someone does attack this infrastructure to advance their own interests, or simply to reap the lulz.

Findings like Moore’s are only going to be more commonly produced as more and more systems are integrated with the Internet as part of the ‘Internet of Things’. It remains to be seen whether vulnerabilities will routinely be promptly resolved, especially with legacy equipment that enjoys significant sunk costs and limited capital for ongoing maintenance. Given the cascading nature of failures in an interconnected and digitized world, failing to secure our infrastructure means that along with natural disasters we may get to ‘enjoy’ cyber disasters that are both harder to positively identify or subsequently remedy when/if appropriately identified.


Major Critical Infrastructure Vulnerabilities Disclosed

For years, researchers have warned that the systems that run critical infrastructure have systemic and serious code-based vulnerabilities. Unfortunately, governments have tended to use such warnings as a platform to raise ‘cyber-warfare’ arguments. Many such arguments are thinly-disguised efforts to assert more substantive government surveillance and control over citizens’ rights and expressions of freedom. Few of these arguments genuinely address the concerns researchers raise.

In the face of governmental lacklustre efforts to secure infrastructure, researchers have disclosed critical vulnerabilities in many of the systems responsible for manufacturing facilities, water and waste management plants, oil and gas refineries and pipelines, and chemical production plants. What’s incredibly depressing is this:

The exploits take advantage of the fact that the Modicon Quantum PLC doesn’t require a computer that is communicating with it to authenticate itself or any commands it sends to the PLC—essentially trusting any computer that can talk to the PLC. Without such protection, an unauthorized party with network access can send the device malicious commands to seize control of it, or simply send a “stop” command to halt the system from operating.

These kinds of ‘attacks’ or ‘exploits’ are possible because the most basic security precautions are not integrated into the logic controllers running such infrastructure. On the one hand this makes sense: many PLCs and the infrastructure they are embedded in were created and deployed prior to ‘the Internet’ being what it is today. On the other, however, one has to ask: if the money spent on security theatre at airports had been invested in hardening actual PLCs and other infrastructure, where would critical infrastructure security be today?