Vulnerability Disclosure Programs Need to Get Organized
Article By : Ann R. Thryft
Vulnerabilities that create potential security holes in Internet of things (IoT) and industrial control system (ICS) products just keep growing. More than 600 were disclosed in the first half of this year, according to Claroty’s latest ICS Risk & Vulnerability Report. Most are high or critical severity, can be easily and remotely exploited, and make the […]
Vulnerabilities that create potential security holes in Internet of things (IoT) and industrial control system (ICS) products just keep growing.
More than 600 were disclosed in the first half of this year, according to Claroty’s latest ICS Risk & Vulnerability Report. Most are high or critical severity, can be easily and remotely exploited, and make the affected component completely unusable. One quarter have no fix, or can be only partly remediated.
An example of the potential wreckage that could be caused by unknown vulnerabilities lurking in the software supply chain is the recently named BadAlloc cluster in RTOS and supporting libraries from multiple suppliers. These can be exploited for denial-of-service attacks or remote code execution.
Millions of IoT and operational technology (OT) devices — as well as consumer systems like cars, and medical devices — are potentially affected. Yet OEM and asset owner users alike didn’t know these flaws existed until Microsoft disclosed them in April.
Yet most product vulnerabilities are now discovered not by the affected vendor, but by outside sources like third-party researchers. That’s why vulnerability disclosure programs (VDPs) exist. As Bugcrowd’s 2021 Ultimate Guide to Vulnerability Disclosure explains, VDPs have been set up to provide “a mechanism for identifying and remediating vulnerabilities discovered outside the typical software development cycle.” They’re usually run by federal entities, industry organizations, and some large product vendors.
No consistency across programs
In response to a September 2020 binding operational directive from the Cybersecurity and Infrastructure Security Agency (CISA), federal agencies are posting their vulnerability disclosure policies — confusingly, also indicated by the acronym “VDP.” In July, CISA announced its VDP Platform. Provided by Bugcrowd and EnDyna, it will serve civilian federal agencies as a centrally managed site where security researchers and others can report vulnerabilities in agency websites.
But most VDPs govern vulnerabilities in products, not processes or configurations. Unfortunately, there’s very little consistency among them. “These programs are all over the map: even U.S. federal agencies do their own thing,” Ron Brash, director of cyber security insights for Verve Industrial Protection, told EE Times. “None of them are set up for maximum efficiency.” Even those with good mechanisms, such as the NIST and ISO/IEC programs, have disparities between those mechanisms: what’s reported and how, enforcement, and how the required changes are made by a given group.
Brash also faulted a lack of transparency in reporting. The U.S. government hasn’t developed the code for the COTS-type products it generally purchases, so federal agencies don’t have real ownership and must act as traffic cops, he said. “The persons who should be doing the ‘policing’ don’t have the knowledge to truly understand the issues at hand, or their impact; can’t effectively remediate vulnerabilities due to budgets, approvals, an inadequate EoL platform, or the inability to provoke a vendor into providing a fix; and don’t have the means to apply consequences or force improvements.”
Ownership is also lacking for a given advisory, and for synchronization of what’s done about it across government programs and vendor portals. “It’s all best effort,” said Brash. “The large vendors often take ownership, but their multiple business units might all do it differently. Since each product can combine multiple products, the number of vendors multiplies even more.”
CVE reporting system has limitations
CISA sponsors the two most central U.S. VDPs: the National Vulnerability Database (NVD), hosted by the National Institute of Standards and Technology (NIST), and the slightly older Common Vulnerabilities and Exposures (CVE) program, run by MITRE, which details publicly known vulnerabilities. CISA also hosts the ICS-CERT advisories, which include exploits and issues.
“Even if we ignore the whole disclosure process and research aspects, the [CVE reporting] system is arcane and complex,” said Brash. “Most asset owners don’t have the knowledge required to adequately understand OT/ICS security advisories, or to act on them. So, they become paralyzed by the sheer amount of information.” This complexity becomes clear watching Brash’s YouTube presentation, a 101 for deciphering them.
The CVE system doesn’t include everything: a growing number of vulnerabilities don’t appear there. According to Risk Based Security, 2,158 vulnerabilities were published in July, 670 of them without a CVE ID.
“CVEs are limited to vulnerabilities affecting a wide array of software that many companies may use,” independent security researcher John Jackson, founder of ethical hacking group Sakura Samurai, told EE Times. “[But] a vulnerability could be specific to logic in software or on a server that only one company owns.”
Federal VDPs target mostly federal agencies, said Brash. Little is available for commercial companies: a few industries have their own regulators, such as the North American Electric Reliability Corporation (NERC) for electric utilities. Although federal agency policies and procedures could be mirrored for use in private industry, those can change with every presidential election, he pointed out.
“Some open-source community projects are managing vulnerability disclosures fairly well,” said Brash. “For instance, some parts of the Linux kernel are well managed; others not so much, and that’s not even considering the overall Linux ecosystem. And when compared to other free and open-source software projects, or even various proprietary products, they too have highly variable security practices.”
Reporting, disclosure problems
The lack of consistency across programs, especially in reporting, can put third-party researchers in a bind, not to mention the potential legal issues caused by the Computer Fraud and Abuse Act (CFAA).
“A lot of VDPs require hackers to not discuss their findings, yet the programs don’t pay them, or give them any incentive to even hack,” said Jackson. “In addition, they are usually poorly managed or mismanaged by non-security personnel, and that makes collaboration difficult. VDPs using Bugcrowd are a good start because they let hackers collaborate effectively and triagers can take a look at the vulnerability first to confirm it. Still, this doesn’t mitigate the need for regular security.”
A 2016 report from the NTIA Awareness and Adoption Group said, “The vast majority of researchers (92%) generally engage in some form of coordinated vulnerability disclosure. The threat of legal action was cited by 60% of researchers as a reason they might not work with a vendor to disclose. Only 15% of researchers expected a bounty in return for disclosure, but 70% expected regular communication about the bug.”
According to Bugcrowd’s 2021 Ultimate Guide, 87% of organizations with their own VDP reported getting a critical vulnerability from it. But while 99% say they consider joining their VDP with a bug bounty program, only 79% say they actually pay researchers for “impactful findings.”
Because the problem becomes especially complicated with vulnerabilities in embedded, IoT products, the disclosure process should be standardized, said Brash. There must also be “a stick to enforce it,” on both the asset owner end and the OEM product developer end. He envisions a registry for embedded IoT products like the ones for car recalls. “I believe it should be on the vendor’s and system integrator’s plate to make sure an asset owner is at least informed of a vulnerability in their asset. Like with a car recall, the owner can then decide to accept the risk, get it fixed, or buy a different product.”
This article was originally published on EE Times.
Ann R. Thryft has written about manufacturing- and electronics-related technologies for Design News, Test & Measurement World, EDN, RTC Magazine, COTS Journal, Nikkei Electronics Asia, Computer Design, and Electronic Buyers’ News. She’s introduced readers to several emerging trends: industrial cybersecurity for operational technology, industrial-strength metals 3D printing, RFID, software-defined radio, early mobile phone architectures, open network server and switch/router architectures, and set-top box system design. At EBN Ann won two independently judged Editorial Excellence awards for Best Technology Feature. Currently, she is the industrial control & automation designline editor at EE Times. She holds a BA in Cultural Anthropology from Stanford University and a Certified Business Communicator certificate from the Business Marketing Association (formerly B/PAA).