ExPetr/Petya and the NERC CIP Reliability Standards

This week brought another global ransomware scare, dubbed “ExPetr” and/or “Petya”, similar to the “WannaCry” attack a few weeks ago.  By most accounts, the U.S. energy industry was largely unaffected by this round of worm-based ransomware intrusions.   There are important lessons to be learned that tie directly back to the NERC CIP Reliability Standards though, so I thought I’d provide a quick insight on it for those that do not regularly participate in NERC compliance activities.

So, in a nutshell, what’s going on?  ExPetr/Petya used a hacking tool called EternalBlue, allegedly developed by the National Security Agency, to exploit Microsoft Windows and lock up computer systems until a ransom of $300 in untraceable Bitcoin is paid.  Of course, paying the ransom is no guarantee that your system will be unlocked.  Based on the reports so far, ExPetr/Petya was allegedly introduced through a Ukrainian company called MeDoc, a legitimate financial tech company which sent out an update on June 22 to its tax preparation software to its customers with the malware embedded in it.  Once it was released, it spread through Ukraine and Russia, and then globally, including to U.S. companies like Merck and the law firm of DLA Piper. 

Unlike less sophisticated clickbait malware, which usually requires a user to enable the worm through accessing a malicious website link, this is a patch/configuration based hack that will happen when the update is added.  Microsoft released a patch for this vulnerability months ago that would close the Windows entry point, but if your IT department is not updating Windows religiously, or allows users with their own updated equipment to access computer networks, the worm can gain access and once there, spread like a wildfire.  And when you deal with hundreds or thousands of connected devices, it the odds are against you that one will slip through the cracks and not be updated. 

That brings me back to the CIP Reliability Standards.  First and foremost, CIP Reliability Standards only apply to a subset of computer systems in the electric utility industry: those systems designated as Bulk Electric System (“BES”) Cyber Systems.  Among other responsibilities, the suite of CIP Reliability Standards are designed to require entities to configure such BES Cyber Systems in a manner that (1) eliminates access through ports or other entry points to critical systems to operate the grid, (2) reduces the number of software applications on such critical systems, (3) reduces the number of users with physical or electronic access to the systems, and perhaps most relevant in this context, (4) requires regular updating of systems through detailed patch management processes, including a process to evaluate patches to ensure they come from a reputable source, that the patch works as intended in a test environment, and that the patch is installed correctly and promptly. 

Would application of the CIP Reliability Standards to all computers and associated systems (not only BES Cyber Systems) have stopped this worm?  The answer is probably, and it did seem to serve its designed purpose as to the BES Cyber Systems.  First, regular patching of Windows would have closed the vulnerability exploited by ExPetr/Petya had it been done promptly.  The patch was released by Microsoft in mid-March.  A typical CIP-based patching protocol would have permitted the entity to have approximately 30 days to locate and find a patch, another 30 days to test it in a safe non-production environment, and then another 30 days to verify and install the patch.  The full 90 days envisioned here would get you to about mid-June, so it might have been completed just in the nick of time. 

Second, a typical CIP-based patching process would also require testing, as noted above, so test installation of the MeDoc accounting patch in a safe environment may have resulted in a lock-up situation and alerted the IT user to take further action before installing it in a production environment that could affect all interconnected systems.  CIP standards require that users validate a source for patching; here it was the software company itself that released the patch; that would typically be a reputable and acceptable source.  That’s a bit scary.

Third, the CIP Reliability Standards would have likely declared an application such as an accounting/tax software as not necessary to be on a system that could affect the reliability of the BES.  By limiting and isolating the BES Cyber Systems, it protects against malicious attacks such as worms entering important systems.  Conversely, it does nothing to protect against attacks on the rest of a company’s IT, which can bring normal business operations to a grinding halt, as it did to several companies this week.

The CIP Reliability Standards are all about a “defense in depth” approach to protect our critical energy infrastructure.   There are important lessons to be learned here that validate the NERC’s program and the importance CIP Reliability Standards.   

Finally, I note that FERC had a technical conference on June 22, touching on further revisions to the reliability standards enforcement program as it nears its 10^th anniversary of mandatory applicability.   The archived stream of the conference can be viewed here for the next 3 months.