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.