I had an interesting conversation today with the lead
researcher for one of the increasing number of ICS cybersecurity companies. The
conversation was interesting, informative, and completely off the record. One
topic that did come up that I think bears some broader discussion within the
community is the vulnerability reporting processes used by such companies. Not
coordinated disclosures so much, but the public reporting of vulnerabilities by
researchers after vendors have had a chance to address the vulnerabilities.
There are a number of companies in the ICS security realm
that publish reports about vulnerabilities that they have discovered. The first
thing that we as consumers of those reports have to remember is that these
companies are not doing the vulnerability research to do this reporting. They
are doing the research to support their business model of either providing
threat identification for their customers and/or selling products that mitigate
the effect of vulnerabilities/attacks on customer processes. This means that
their reporting is as much part of their advertising as it is sharing
information with the community. The balance between advertising and information
sharing varies widely within the industry.
I told my caller today that I try to look at things, vulnerabilities
in particular, from the operator perspective. And I would like to see more
vulnerability reporting from the research community try to focus more on that
type of reporting. I do not object to the detailed technical reporting that we
see so often; with proof-of-concept code and details about how the researchers
went about pulling the vulnerability apart. That is all valuable reporting, but
it is more helpful to the research community and the response community than it
is to the owner/operators of industrial control systems in the manufacturing
Vendors and various CERTs do a better job of providing user
focused information in their advisories than the research community generally
does, but I still think that more needs to be done at even this level. CISA’s NCCIC-ICS
has the most consistent approach in this regard that I have seen. They generally
provide a brief description of the skill level needed to exploit the
vulnerability, the level of access needed and a brief description of the
consequences. Unfortunately, the terminology they use is more than a little
vague and seldom provides any useful information on how a successful attacker
would implement the exploit. The main reason for that lack of detail is that
NCCIC-ICS is not a research organization, but rather a coordination agency.
Perhaps it is time for cybersecurity companies to begin
preparing their own advisories in addition to their blog posts, white papers
and reports. These new documents would address vulnerability disclosures from
the perspective of affected owner/operators. It would include a link to more
detailed information in the more typical vulnerability research reporting, but
it would concentrate on describing the potential impact to organizations and would
include discussion of potential mitigation measures.
The advertising wonks in these companies should jump on that
mitigation measures portion of the advisory because it would provide an
opportunity to explain to their customers (and potential customers) how their
products would help to protect them from the vulnerabilities being described.
In fact, this potential advertising advantage might lead cybersecurity
organizations to provide advisories for vulnerabilities that were publicly
reported by other organizations or even equipment vendors.
The preparation of these researcher advisories should not
take up too many administrative resources. Much of each advisory could be
pre-written as part of a standard format and most of the language could be cut
and paste boiler plate; just look at the NCCIC-ICS advisories to see how much
of the language is common to each advisory. Furthermore, much of the more variable
wordage could be included in the more traditional reporting, making those
documents more valuable as well.
Go to Source of this post
Author Of this post: PJCoyle