Advisory Follow-Up – Researcher Follow Through

 I have written an unknown number of posts over the years about cybersecurity vulnerabilities and the advisories published about those vulnerabilities. Most often those posts get written, posted, and mostly forgotten. All of the response takes place at facilities that use the affected products. Every once-in-a-while, however, a researcher decides that there is more to the story that needs to be shared with the public. Here is a brief look at one of those; vulnerabilities in products from Gardyn, and further follow-up by Michael Groberman, the researcher who identified the vulnerabilities. 

Background Information  

CISA Advisory (ICSA-26-055-03) published February 24th, 2026.3 

CISA Advisory updated April 2nd, 2026. 

Groberman exploit published April 3rd, 2026. 

New Information  

Groberman has established a web site that addresses the published vulnerabilities and the various responses to issues involved. I do not imagine that every set of reported vulnerabilities deserves this level of dedication, but it is interesting to see how far a committed researcher is willing to go to share information about a problem that is reported to be corrected.  

Review – 1 Update Published – 6-7-22

 

Today, CISA’s NCCIC-ICS updated an advisory for products from Mitsubishi. CISA also updated their Known Exploited Vulnerabilities web site.

Mitsubishi Update - This update provides additional information on an advisory that was originally published on November 30^th, 2021 and most recently updated on April 26^th, 2022.

KEV Page Update - CISA announced today that they had updated their KEV website, providing information on the criteria and process used to add known exploited vulnerabilities to the KEV catalog.

For more information on the advisory update and the updated KEV information, including a Down the Rabbit Hole look at reporting control system vulnerabilities to CISA, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/1-update-published-6-7-22 - subscription required.

Researcher Vulnerability Reporting

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.

Research Companies

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.

User Perspective

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 world.

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.

Researcher Advisories

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.

Publishing Security Advisories

I had an interesting online conversation today with an ICS security researcher. He wanted to know if I had access to a Thales security advisory that I briefly described in one of my weekend ‘Public ICS Disclosures’ blog posts. He was trying to see if it described a vulnerability that he had reported. Unfortunately, Thales (and a number of other companies) only makes its security advisories available to registered customers, so I was not able to help him. In any case, the conversation got me thinking about the whole concept of publishing security advisories.

Anyone who reads this blog knows that I spend a lot of time publishing brief notifications about security vulnerabilities in industrial control systems (with admittedly a WIDE definition of what constitutes an ICS). My reason for doing this is that I want the widest possible dissemination in the user community of information about security vulnerabilities. The information that I publish in a digest-type format is the bare bones that a user might need to determine if their organization might be impacted with links to find more information. I am pretty sure that there are no blackhats out there waiting for my disclosure to provide them with a new cyber weapon.

Corporate Reporting

Can the same be said for vendor security advisories? Most of the advisories that I read are similar in outlook (if in somewhat more detail) to the information that I provide, bare bones about the vulnerabilities, but more information about mitigation measures. While I am certainly not a hacker (or even much of a coder anymore) I have not seen any security advisories that would seem to be nascent weapons platforms. The information might be enough to point a determined attacker at areas to conduct further research, but there is a long way to go from most corporate vulnerability descriptions to useable exploits.

Even so, there are some companies, like the Thales Group, that restrict access to their security advisories to just registered customers. I would guess that they have done some sort of internal risk assessment that leads them to conclude that the information that they provide would be too valuable to an attacker. I would like to think that this is because they provide more details about the vulnerability in their restricted reports. That would be a good thing because more details would allow users to make a better risk assessment of what actions they need to take to protect their systems.

Then, of course, there are those companies that do not publish security advisories of their own. While there may still be some companies out there that are taking a head-in-the-sand approach to security reporting, I suspect that it is more about the lack on internal staffing or perhaps an overly imaginative legal staff that cause many smaller companies to rely on CERTS to prepare their security advisories. This is one of the reasons that I spend so much time looking at CISA-NCCIC-ICS and CERT-VDE for advisories. While I think that this may be counterproductive in the long term, the information is still being made available to the end users, if they know where to look.

Researcher Reports

Finally, we see a significant number of instances where the independent security researcher (or research firm) publishes their report on a vulnerability. In many instances, these reports are the only public notification of the existence of the vulnerability. When that is the case, I wholeheartedly indorse the idea of researchers publishing their vulnerability reports AS LONG AS they have notified the appropriate vendor and provided them a reasonable opportunity to report and correct the vulnerability. This is especially important in cases where the researcher provides details about how they discovered the vulnerability and/or proof-of-concept exploits for the vulnerability. Those actions can make it easier for blackhat hackers to exploit the vulnerabilities in the wild.

From a user perspective I do not see a lot of benefit in the detailed reports that we see from a number of researchers. Details about how the exploit was discovered or how it could be exploited does not provide a lot of useful information for a risk assessment exercise. On the other hand, other white hat researchers can learn new techniques from such reports and vendors can gain valuable insights in how to protect their products from a close reading an understanding of such reports. This is one of the reasons that I continue to discuss such reports in my weekend summary.

Exploit Reports

For a lot of reasons, we see relatively few exploit reports for industrial control systems, but they do exist. The thing that distinguishes these from the researcher reports is that there is typically little information provided beyond the exploit code being published. This means that they provide little new information for the user risk assessment process beyond the known existence of an exploit. A technical review of the exploit by vendors or white hat researchers probably provides some benefit, but these typically exist only as an advertisement of the skill of the exploit writer.

I have been asked on occasion why I keep reporting on these exploit reports. My answer is simple, the existence of these publicly available exploits is information that owners need to have to properly assess their facility risk and determine what/when mitigation measures should be put in place. In all cases to date, I have taken these exploit reports from widely available public sources, so I can sleep well thinking that I have not unduly increased the danger of potential attacks. Again, I do not think that I have a large black hat audience waiting on my word of new exploit tools.

In any case I will be continuing to report on security advisories, researcher reports and exploits. Each weekend I look at 48 vendor sites and 30 researcher sites for new information.. As always, I continue to look for new sources of information about these resources and any suggestions from readers would be welcome.

ICS Advisory Study by Dragos

Yesterday I ran across an interesting infographic on LinkedIn that was produced by Dragos. It provided some provocative statistics about control system security advisories that were published in 2017. I am not a big fan of infographics; I prefer to look at the analysis that went into putting together the infographic. So, I asked for and received a link to the report from Dragos that actually includes the infographic.

I have generally been a fan of Dragos incident and vulnerability reporting, but I am disappointed in this report. The infographic has some tantalizing extracted information, but the full published report is little more than a series of bullet points that describes the information from the infographic. To tell the truth, I am not sure what came first, the infographic or the report.

The important information in the report is really summarized neatly by the two paragraph introduction by Reid Wightman. Unfortunately, the information supporting Reid’s comments is not very detailed and there is a total lack of specific examples that explicate the points that Reid makes. While I agree with Reid’s conclusions and almost all of the points raised in the report, it is not because of the in-depth reporting in this document. Rather I have seen what the report describes in my own perusal of ICS-CERT vulnerability reporting over the last ten years or so.

My major question about the reporting here is about the source of the data. According to the report the data is based upon the Dragos analysis of “163 vulnerability advisories

with an industrial control system (ICS) impact” that Dragos tracked in 2017. It is not clear if these were advisories produced by vendors or ICS-CERT. I am hoping that ICS-CERT advisories were the basis for the analysis, because those advisories at least have a commonality of terminology and an attempt at consistency of data presented. Furthermore, the ICS-CERT advisories for many vulnerabilities (particularly for the smaller vendors) are apparently the only real report for a large number of the advisories published by ICS-CERT.

If Dragos was relying on data from vendor vulnerability reports (and this would have certainly been a more chalenging analysis) then they have failed to acknowledge the disparity in the reporting efficacy of the different vendors. Major vendors (like Siemens, Rockwell, etc) do a much more complete job of reporting the kind of data that the Dragos’ report calls for. They should be commended for the efforts that they do take to produce useable (but still frequently flawed) vulnerability reports.

Two very important points are made in both the infographic and the report and they both deserve wide spread discussion. First, “85% of 2017 ICS-related vulnerabilities apply late in the kill chain and are not useful to gaining an initial foothold. If these vulnerabilities are exploited, it is likely the adversary has been active in the network for some time and already pivoted through various other systems”. Second, “61% of 2017 ICS-related vulnerabilities cause both a loss of view and a loss of control – likely causing severe operational impact”. What I would like to know, is what percentage of the vulnerabilities that could be useful to gain an initial foothold could lead to a loss of view and/or control. That is the type of information I was hoping to see in this Dragos report.

Do not get me wrong. Everyone in the ICS community should look at the infographic (which should certainly be shared with management outside of the immediate ICS environment) and read this report. Vendors should certainly take the reports recommendations to heart. I just wish that there had been a little more red-meat here.

ICS-CERT Publishes 2016 Vulnerabilities Review

Yesterday the DHS ICS-CERT published their 2016 Annual Vulnerability Coordination Report. This is the second such report from ICS-CERT and many of the same problems exist in this year’s report. Additionally, ICS-CERT further complicates their reporting by making changes to the way they are ‘counting tickets’ in the report so that numbers are not directly comparable to previous years. Oh, yes, they are also reporting both FY 2016 and CY 2016 data, just to throw another monkey wrench into the data analysis comparison problem.

Changes in Data Reporting

The change in the way that ICS-CERT counted tickets makes a fundamental change in the data reported. ICS-CERT explains the change:

The method used to collect and report vulnerability data changed in 2016 from that used in prior years. In 2016, ICS-CERT began reporting metrics data on vulnerability tickets closed within the FY or CY accounting periods. This prevents reported metrics changing based on work accomplished throughout the life of an open ticket. In previous year’s reporting methods, actions taken prior to ticket closure could result in additional follow-on work being required, which in turn could change the reported metrics. It is therefore important to note that some information reported in published alerts and advisories in 2016 may not be included in the FY or CY data cited herein, since the associated vulnerability ticket may still be open. Data for tickets will be included in the reporting period in which the ticket is closed.

While the change in data accounting is a legitimate attempt to make the numbers more meaningful in the long run, it does make 2016 data to the same data from earlier years. This report makes that clear at multiple points in the discussion, but they continue to provide graphics comparing the numbers all the way back to 2010. I predict that a number of agencies and organizations will not make the distinction clear when they report on ICS-CERT vulnerability data.

Two Reports Make a Difference

Figure 3 in this year’s report shows how changes in vulnerability detection may be making major changes in how future reports may look. The final two columns in the table report 2016 data including a “2 ticket anomally”. The report explains these two tickets this way:

“The increase is primarily associated with two (2) tickets closed in 2016 that contain 1,418 and 460 vulnerabilities. Because these 1,878 validated vulnerabilities were associated with a small subset of affected products, there is some concern that these outliers could bias the metrics associated with vulnerability type and Common Vulnerability Scoring System (CVSS) scores. As a result, these are included in the total number of vulnerabilities reported to ICS-CERT; however, this data is not included in other metrics treated throughout this document.”

The two advisories are not named. They were a medical system advisory for a product from CareFusion and another from Philips Medical. Lest one thinks that this is just a medical device issue, there have been two similar large-vulnerability-number advisories already published this year for control system products from Rockwell (62) and Schneider (365). In each case the vulnerabilities come from third-party software or libraries included in the control system product.

ICS-CERT reports that these types of large-scale vulnerability detections have been made possible “by using automated scanning tools”. It would seem that the use of such tools will become more widespread and will almost certainly become a prime tool for researchers working for organizations with criminal or nefarious intent. This is of particular concern since many of these identified vulnerabilities are very old (in cyber years) and many have well known exploits available.

CWE-CVSS Analysis

This year’s report takes a completely different tack in looking at the variety of vulnerabilities reported. Last year much use was made of pie charts and word descriptions of the vulnerabilities. This year ICS-CERT goes to a more formal use of Common Weakness Enumeration (CWE) numbers and replaces multiple pages of pie charts with a single histogram showing the most frequent CWE numbers reported.

ICS-CERT has, instead of giving us greater detail on the types of vulnerabilities, provided more detail on the effectiveness of those vulnerabilities via a look at a compilation of the Common Vulnerability Scoring System (CVSS) data on those vulnerabilities. This includes a table of impact score results and a histogram for access vector analysis.

What is interesting in the impact scoring table is that the NIST CVSS impact categories are not equal size portions of the 10.0 scale used. The ‘critical’ category, for instance, is only one unit wide, while the ‘low’ category is four units wide, while the ‘medium’ and ‘high’ categories are three and two units wide respectively. Thus, if we were to see a random distribution of CVSS impact scores, we would expect to see a disproportionate share in the two lower categories. Instead what we see in the report’s Table 4 is a concentration in the two smaller categories at the dangerous side of the spectrum. This is further reflected in the table’s reported ‘CVSS Statistics’; an average value of 7.8 and a mean value of 7.5. Unfortunately, ICS-CERT again fails to provide a key statistic, the standard deviation, that provides more depth to the statistics reported.

Rating the Report

ICS-CERT has a mixed history with its wide variety of annual reports that it produces. I have very little use for many of the reports that they produce because of their lack of internally consistent definitions and misleading data. This report is fortunately better than average for ICS-CERT. The information is useful for its summary of the types of vulnerability reports that ICS-CERT produced over the year in question and the limited details available from those reports.

Unfortunately, ICS-CERT is still guilty of publishing four-color glossy corporate reports that do more to confuse than to clarify. The unexplained combining of fiscal year and calendar year reporting provides no new insights into the process. The changing of definitions of what constitutes a reportable ticket makes analysis of year-to-year trends questionable, but these trends will inevitably be carefully misreported in the press and abused by politicians and activists.

I did like the addition of a start to look at the numerical data found in CVSS data. More of that should be included in next year’s report. Unfortunately, reporting that data is going to have to include some sort of statement about the consistency of that data. While the CVSS system is an attempt to provide repeatable information about vulnerabilities, it is not a physical measure. This means that there is some bias in that data, depending on who scores the vulnerability. If ICS-CERT is providing the individual scores used in the system, that bias is at least somewhat consistent. If vendors are the source of the scoring, the bias will be much less structured. The data source needs to be disclosed.

In any case, I do recommend that those with an interest in the security of industrial control systems should read this report. Just be careful on how you use the inconsistent data.