Time is Now to Elevate Disclosure Standards in ICS Domain

Debates concerning vulnerability disclosure have been carried out to the point of excess within IT security circles for close to two decades; but this angst has not been in vain. Real progress has been made where tangible processes exist at many companies—large and small—to report bugs to security teams, get them fixed, and even compensate some researchers who do their work now largely without the fear of being sued.

The same level of standardization and acceptance needs to be brought to the industrial control systems (ICS) and operational technology (OT) domains, where ideas such as coordinated disclosure and a nuanced understanding of how the work of external security researchers can enhance the safety and reliability of the overall ecosystem still lag.

The contribution to security—and therefore safety and reliability—delivered through coordinated vulnerability disclosure is still not clear to many ICS vendors, but it's relevant and important. The recently published Claroty Biannual ICS Risk & Vulnerability Report, for example, revealed the potential benefit in accepting reports from unaffiliated security researchers is great. One of the major takeaways from the report: more than 70% of vulnerabilities published in 2020 H1 were discovered by such researchers.

The aforementioned lag is concerning, because the stakes are extremely high in many industrial markets where physical safety is put at risk by the threat of a malicious actor armed with time, money, and capabilities. In verticals such as utilities and critical infrastructure, the damage that may be caused is not limited to the direct victim of the attack, but rather to an entire city, region, or country. In other verticals—such as medical device manufacturers or food-and-beverage companies—the actions of an attacker with capabilities against a specific ICS device may also impact thousands of people and put them at risk.

ICS Vendors Taking Steps Toward Maturity

While we shouldn't ever equate maturity with the mere existence of a secure@ email address, there are concrete steps many ICS vendors and critical infrastructure providers can take to elevate their game and demonstrate to the market their seriousness about finding and fixing critical issues in software. The trend is positive: as we can see in the Claroty vulnerability report, 21 affected vendors were named in advisories in 2020 after not having appeared on the list before.

Cultivating a risk-averse, security-aware environment should be paramount in ICS, and an effective plan of action should include recognizing the importance of the work of bug-hunters, whether independent or working for a commercial vendor. Researchers are largely motivated by improving security in the domain. The possibility of compensation and the public acknowledgement that follows may also provide notoriety in the business, as evidenced by the booming bug-bounty industry.

Vendors who have reached a level of maturity in this aspect of security understand what a long road it is to institute such a vulnerability disclosure program. The groundwork that should be completed before a contact email is made public is enormous. This groundwork includes substantial investments in the people, processes, and technology required to be able to handle what will surely be a significant number of bug reports. Your processes must be evaluated and your gaps identified and remediated. Otherwise, your company faces the prospect of an avalanche of vulnerability reports that cannot be ignored, despite a lack of capacity to handle all of them.

That said, it should be noted that the vulnerabilities exist regardless of whether they are disclosed, and creating this infrastructure will simply allow them to be reported, rather than be, for example, sold on a dark-web market to potentially malicious actors.

This also implies that maturity is also needed on the customer side during the evaluation of products from several ICS vendors. This availability and readiness of a disclosure policy and program should be considered as well. A simple example would be understanding that a vendor with many reported vulnerabilities is, unintuitively, more secure than one without a vulnerability reporting mechanism in place.

Claroty's vulnerability researchers can bear witness to these different levels of maturity. Some of the larger vendors we have submitted bug reports to have refined processes in place, with capable personnel responding to reports in a timely manner, keeping bug reporters informed along the coordinated timeline for a fix and public disclosure, and working hard to demonstrate that reliable patches are reliable and distributed to users.

Aiming for Sustainable Vulnerability Programs within ICS Domains

Less mature vendors may not have an experienced computer emergency response team or vulnerability disclosure programs in place. Sometimes, it's enough of a challenge to merely find a cybersecurity email address, and contacting a vendor becomes a months-long ping-pong match of reaching out to everyone from product support to sales to the CEO for a response. Even when communication is established, we have experienced multiple situations in which an affected vendor initially suspected our private disclosure was a blackmail attempt with a threat of public disclosure. This dynamic in the ICS domain isn't sustainable.

Some victories? Pwn2Own Miami was a prominent hacker event where research teams took aim at vulnerabilities present within ICS devices, bringing bugs to the S4 Conference in equipment from some of the largest companies in the industrial world. While there was some fame and fortune paid out to the winning teams, the bigger picture is that critical bugs in software and devices prominent across the domain were identified and remediated.

The Cybersecurity & Infrastructure Security Agency (CISA) recently announced Binding Operational Directive 20-01, which mandates that federal civilian executive branch agencies develop and publish a vulnerability disclosure policy and maintain processes to support their policies. VDE is another example of vendors coming together to take action and establish a single organization to act as a CERT and handle vulnerability reporting and public disclosures.

These are just three examples of the growing awareness and acceptance of the value of security research in the ICS domain. There's a long way to go, but organizations should take this opportunity to begin the prep work for developing and deploying a vulnerability disclosure policy, bringing it to fruition, and using it to enhance secure software development practices internally. Good will and strong working relationships with external researchers, and standardized, reliable vulnerability reporting structures improve the value of your products, enhance the security of the ICS domain, and make the overall ecosystem safer.