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.
I received a couple comments from people who wondered how I could be so ignorant (not their word, of course) as not to point out that, even though NERC entities might not be required by CIP to patch end of life systems, it is very bad practice not to take other steps to prevent malware from infecting them - and it's an even better practice to upgrade to a supported version.
ReplyDeleteI didn't mention that in this post because it was discussed in the first post I linked in the first paragraph. Of course, it's a terrible idea to pretend to yourself that your EOL software is as secure as your supported software, assuming you're applying patches to the latter.
Good clarification on the EOL security and the like. Many times we see fundamental architectural changes in software and hardware that prevent ongoing development, never mind the cost to support multiple operating systems or versions.. Microsoft XP operating system End of support helps with this argument. Conversely, if an operating system doesn't change, but the more current versions (with patches) are inherently more secure, it seems logical that a minimum or current version requirement would make sense. The problem comes when you have to upgrade infrastructure or entire system to get to the current version, how do we require the spend to do so?..great post!
ReplyDelete