ICS-CERT Updates Advisory and Links to FDA Guidance

Today the DHS ICS-CERT published an update for a control system security advisory initially published and quickly updated in November, 2016 for products from CA Technologies. They also provided a link to a new FDA medical-device cybersecurity guidance document.

CA Technologies Update

The update provides new information about the affected versions and the version to which the system must be updated to mitigate the reported vulnerability. The newest version of the CA Technologies security notice reports that the previously reported upgrade did not adequately address the vulnerability reported in the ICS-CERT Advisory; the latest version does mitigate the vulnerability.

The ICS-CERT advisory continues to ignore the two medium rated vulnerabilities (CVE-2016-9164 and CVE-2016-9165) that were reported by CA Technologies.

FDA Guidance

The ICS-CERT landing page provides click-through links to the FDA Voice blog-post on the publication of the final guidance document for the postmarket management of medical device cybersecurity.

The guidance document includes an interesting discussion (pgs 15-17) of risk management for cybersecurity risk with examples of how a manufacturer would use the recommended techniques in some well-defined situations. A similar discussion (pgs 18-21) addresses mitigating and reporting vulnerabilities.

The big shortcoming in the guidance is the lack of a vulnerability coordinating mechanism to ensure effective communication between cybersecurity researchers and manufacturers. While the document does recommend that manufacturers should adopt “a coordinated vulnerability disclosure policy and practice that includes acknowledging receipt of the initial vulnerability report to the vulnerability submitter” (pg 18), the FDA does not attempt to establish an organizational office to mediate disagreements between researchers and manufacturers about the existence, seriousness, or mitigation of reported vulnerabilities.

Having said that the FDA has set a pretty rigorous reporting requirement under the existing requirements of 21 CFR 806. An exception to those requirements is made when the following four criteria are met (pg 22):

• There are no known serious adverse events or deaths associated with the vulnerability;

• As soon as possible but no later than 30 days after learning of the vulnerability, the

manufacturer communicates with its customers and user community regarding the

vulnerability, identifies interim compensating controls, and develops a remediation

plan to bring the residual risk to an acceptable level;

• As soon as possible but no later than 60 days after learning of the vulnerability, the

manufacturer fixes the vulnerability, validates the change, and distributes the

deployable fix to its customers and user community such that the residual risk is

brought down to an acceptable level; and

• The manufacturer actively participates as a member of an ISAO that shares vulnerabilities and threats that impact medical devices, such as NH-ISAC (see section IX) and provides the ISAO with any customer communications upon notification of its customers.

The only problem with the reporting requirements under §806 is that they only apply when ‘corrections’ or ‘removals’ of a device are required. Neither the definition of ‘correction’ {§806.2(d)} or ‘removal’ {§806.2(j)} specifically apply to software updates or revisions. The FDA continues to assume that the undefined terms ‘repair’, ‘modification’, or

‘adjustment’ cover changes to software. That might not stand up in court.

Oh, and by the way, each page of the document includes a header that states “Contains Nonbinding Recommendations”. This is just a guidance document, not a regulation. Remember that when they hook you up to a device connected to the wall by a network cable.