SBOM – Excited Pixels

Trend Micro has a nice short piece on the challenges of assessing the security properties of various components of Android devices. In short, white labelling incentivizes device manufacturers to invest the least amount possible in what they’re building for the brands that will sell devices to consumers. Trend Micro included this very nice little mention on the shenanigans that firmware developers can get up to:

Firmware developers supplying the OEM might agree to provide the software at a lower cost because they can compensate the lost profit through questionable means, for example by discreetly pre-installing apps from other app developers for a fee. There is a whole market built around this bundling service with prices ranging from 1 to 10 Chinese yuan (approximately US$0.14 to US$1.37 as of this writing) per application per device. This is where the risk is: As long as the firmware, packaged apps, and update mechanisms of the device are not owned, controlled, or audited by the smartphone brand itself, a rogue supplier can hide unauthorized code therein.¹

While the authors suggest a range of policy options, from SBOMs to placing requirements on device transparency before administrators ‘trust’ devices, I’m not confident of these suggestions’ efficacy when taking a broader look at who principally uses white labelled devices. There are economics at play: should all devices have increased input costs associated with greater traceability and accountability then it will place financial pressures on the individuals in society who are most likely to be purchasing these devices. I doubt that upper-middle class individuals will be particularly affected by restricting the availability of many white labelled Android devices but such restrictions would almost certainly have disproportionate impacts on less affluent members of society or those who are, by necessity, price conscious. Should these individuals have to pay more for the computing power that they may depend on for a wide range of tasks—and in excess of how more affluent members of society use their devices?

Security has long been a property that individuals with more money can more easily ‘acquire’, and those who are less affluent have been less able to possess similar quantities or qualities of security in the services and products that they own. I understand and appreciate (and want to agree with) the Trend Micro analysts on how to alleviate some of the worse security properties associated with white labelled devices but it seems as though any such calculation needs to undertake a broader intersectional analysis. It’s possible that at the conclusion of such an analysis you still arrive at similar security-related concerns but would, also, include a number of structural social change policy prescriptions as preconditions that must be met before heightened security can be made more equitably available to more members of society.

Emphasis added. ↩︎

CISA has a neat bit of work they recently published, entitled “Vulnerability Exploitability eXchange (VEX) – Status Justifications” (warning: opens to .pdf.).¹ 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.²

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.

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