Nucleus:13 is Proof the System Works

On November 9, 2021, Forescout announced the discovery of several new security flaws in the Nucleus Networking stack, which they named the NUCLEUS:13. You can find their announcement at https://www.forescout.com/research-labs/nucleus-13/, along with Siemens’ advisory to their customers at https://cert-portal.siemens.com/productcert/pdf/ssa-044112.pdf.

While Siemens Embedded always strives to avoid software defects, they inevitably occur, and when that software is used to enable secure devices, these defects may cause security issues for our customers as well as their customers. No matter how diligent a software provider like Siemens Embedded is, there will always be ways to exploit software defects. The history of computing devices shows a past full of security vulnerability exploitations including industrial espionage, ransomware, and the theft of personal data. While security vulnerabilities are a significant problem, they are just a subset of the kinds of defects that software providers need to consider.

Fortunately, the Common Vulnerability and Exposures (CVE) process exists to help both software providers and application developers publicize newly discovered security flaws (such as NUCLEUS:13). Following this process informs people about the problem, gives software providers such as Siemens Embedded an opportunity to fix the underlying issues and make those fixes available at the same time that the issues become public knowledge. Our customers can then quickly integrate those fixes into their devices and eliminate any potential infiltration by malicious actors using those exploits in the future.

A guide to the general CVE reporting process can be found in the white paper “A Guide to Minimizing Device Security Vulnerabilities <A guide to minimizing device security vulnerabilities | Siemens Digital Industries Software>, but for this blog let’s focus on the NUCLEUS:13 reports as an example to show the optimal path to follow when these issues are discovered:

1. A researcher (in this case, at Forescout) sees one or more issues that might be security vulnerabilities in a product (in this case, the networking stack included in Nucleus ReadyStart). Often, the researcher will find more than one issue either in related areas of the affected software, or in this case, as a result of further testing; the researcher found 13 issues.
2. The researcher reached out to the software supplier; in this case, working through Siemens ProductCERT (https://new.siemens.com/global/en/products/services/cert.html) which is an expert security team who works with both external researchers and all product teams within Siemens to handle security exploits.
3. Siemens ProductCERT made sure that CVE identifiers were assigned to each issue, and let Siemens Embedded know about the issues.
4. Normally, a researcher who finds a CVE wants to give the impacted company time to resolve the issues found before a public announcement is made. In this case, we had more than sufficient time between when Forescout found the vulnerability and when it was announced, so Siemens Embedded was able to fix all the issues in multiple versions of Nucleus and have those updates available (and the customer advisory linked above) at the same time Forescout’s announcement was made.

Almost all software exploits that you’ve heard about in the past several years have gone through a similar path. The exploits are found not by bad actors or “black-hat” hackers, but by researchers focused on security who are trying to make sure that the Internet of Things is as secure as possible while enabling the life changing technologies it enables. Some of them are large, security focused companies like Forescout, while some are individual engineers or graduate students trying to understand how security works and stumble onto a flaw (https://warroom.rsmus.com/beginners-guide-cve-process/ for an example). As a result, most of the time an issue is identified, the CVE mechanism makes sure it’s publicized and that available fixes become known, and that people who might depend on that software can be made aware that they have something to worry about. In this case, and in many other cases over the past several years, the system worked as intended. An issue was found, the right people were notified that they had an issue to fix, the issues were fixed, and by the time the information about the security flaw was made public, the fixes were made public as well. This is something to be celebrated, not feared, and Siemens Embedded embraces the CVE process even when it impacts us directly as it did here. I don’t know if all publicity is good publicity, but I do know that we should take a moment and congratulate the system when it works as designed.