Do We Need to Pay to Receive Patches for Network Devices?

Matt Light of Deloitte Advisory and I ran a very successful workshop at EnergySec’s Summit on September 14. The title of the workshop was “Implicit Requirements in CIP Version 5”. One of the points I made was regarding software that has run past its end of life, for which the vendor is no longer offering patches. I believe such software doesn’t fall under the patch management requirement, CIP-007 R2, since there are no publicly available patches to apply.

I based this opinion on an email an auditor had sent me in response to my question whether machines running end-of-life software could be “compliant” under CIP v5, given that no more patches are publicly available. I discussed the question and the auditor’s response in this post. In brief, the auditor said “Patching is not an issue.  If (a software product) is past end-of-life, no patches are available, therefore there are none to assess for applicability.”

I got a couple of good responses to this post, which I discussed in a second post. That post dealt with two questions, one of which was whether the fact that a vendor is offering post-end-of-life software support (which presumably includes non-public patches) to certain organizations means that entities must subscribe to this service if they still have that software installed on machines that are subject to CIP v5. The auditor replied “In my view (and I cannot guarantee all auditors will take the same stance), there is nothing in the CIP standards requiring an entity to subscribe to post-end-of-life for-fee support.  There are no more…patches publicly available from a vendor that routinely makes its patches publicly available for supported systems.  I would not demand that an entity pay (significant) dollars for continued, limited security support.  But if they did, then they are expected to monitor for and install any applicable patches that might be released under the support agreement.”

I discussed both questions and the auditor’s answers with the workshop attendees. At this point, one of the attendees raised the question of annual maintenance fees for network devices, including routers and switches. They stated that these fees could amount to a lot of money for their organization, and implied that they weren’t currently paying them. The problem is that some major networking vendors release patches only for devices that are covered by a current maintenance contract. Since the auditor had said he wasn’t going to require entities to pay for extended software support, would he say the same thing about network vendor maintenance fees?

I ran this by the auditor, who said “The difference is that some major network vendors use a paid maintenance and support model, while some major software vendors do not - i.e. (the vendor) doesn’t normally require maintenance in order to receive…patches.  (The software in question) is past end of life and is an unsupported product.  The (network devices in question) are not at end of life and are still supported.  (The networking vendor) is still publishing updates to the general user community. (In contrast, in our supposition, the software vendor isn’t providing support or patches for their end-of-life product) Obtaining post-end of life support is not something the auditors have been expecting. Maintaining and protecting supported systems is expected. Pursuing this logic, is the entity suggesting that they are off the hook if they choose to not pay for annual support and maintenance of their SCADA/EMS?  Their generation plant DCS?  Their PACS?  That position will not be helpful at audit and especially unhelpful if they fall victim to a preventable cyberattack.”

So the answer is pretty clear that the entity needs to pay for networking device support, as long as the device has not yet reached end of life. But as always – and I said this so many times in the workshop that it became a source of amusement – you should check with your Regional Entity to confirm whether or not this is their opinion.

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.