Chris Jager is a freelance security consultant who is always looking for interesting projects related to NERC CIP or ICS cybersecurity. In this four-part guest post series, he’ll go over changes to the NERC CIP standards and challenges facing the industry as they wrestle with compliance in a changing threat landscape.
Part 1 is a brief overview for those new to the sector or to the history of the NERC CIP standards.
History
By late 2005, when version 1 of the NERC CIP standards was substantively complete, the era of the destructive worm had reached its peak and was nearing its end. MSBlaster, a particularly virulent worm that hit the Internet on August 11, 2003, was reported by some to have played a primary role in the Northeast blackout, which occurred three days later. By late 2004, there were numerous detailed reports proving MSBlaster was not responsible for the massive power outage, yet there are still people who claim to this day that the virus was the sole cause.
It was inevitable that the initial iteration of the first mandatory security regulations applied to the energy sector would focus on basic security standards. There were few details prescribed outside of requirements where discussions perhaps turned religious during drafting. Simply put, you were to enact a control class, define your process for managing that control, and practice your documented process.
There were other controls that could have been included by the various regulatory and quasi-regulatory bodies. Completely missing were items like encryption, software assurance, intrusion assessments, and the list goes on.
Generic viruses and worms, of course, weren’t the only threat of the day. Relatively new to many companies was this background noise that some simply called “low and slow” at the time, but you now see reported in the news as APT. For most, there weren’t enough controls on the corporate side of the house to understand what was going on, let alone have an understanding of the impact.
In March of 2006, industry voted to approve Version 1 of the NERC CIP standards. Two months later, the NERC Board of Trustees adopted the standards and ordered them filed with FERC for approval. FERC eventually did approve Version 1 of the NERC CIP standards in January of 2008 and, in doing so, issued an order that is still being addressed today.
Present
FERC Order 706, along with it subsequent variants, has fully defined the extent of changes to the NERC CIP standards since version 1. That is not to say that the changes seen encompass the entirety of the recommendations in Order 706, but that those are the only changes being addressed.
In fact, the primary changes to date have consisted solely of asset scoping. Still missing are meaningful controls around vulnerability remediation, intrusion assessment and monitoring, software assurance, and all of the other controls left out in Version 1.
In the years since the regulatory strata began enforcing the CIP standards, a curious thing has occurred. Initially, compliance was defined as compliance with the intent of a given requirement – not the letter. However, companies have been found non-compliant for simply omitting a word from a procedural document’s title when the procedure itself was compliant both with the spirit and letter of the law.
This has led to an entire cottage industry rising around the ability to exempt assets from regulatory scope. There are consulting agencies that will gladly accept payment for increasing the number of devices an asset owner can claim technical feasibility exceptions for, network isolation hardware vendors that use scope exemption as the primary benefit of purchasing their equipment, and more.
And that quiet background “low and slow” noise from yesteryear? It has become the hallmark of today’s threat landscape. With the standards failing to keep pace and industry racing to stay one step ahead of punitive regulatory sanctions, the chasm between capabilities of the attacker and attacked has grown to an almost untenable point.
Future
Earlier this year, NERC submitted Version 5 of the CIP standards to FERC for approval. While FERC has not yet ruled publicly on them, there is concern over whether the standards yet address the outstanding items in Order 706. Another concern is whether or not, five years on, a strict adherence to Order 706 is still the right focus given the changing threat landscape.
There is a case to be made that the standards might not be auditable as written. Take, for example, the following statement from the “Guidelines and Technical Basis” section of CIP-007-5 for Requirement 3.1, which deals with malware prevention:
If a specific Cyber Asset has no updateable software and its executing code cannot be altered, then that Cyber Asset is considered to have its own internal method of deterring malicious code.
Given this statement, there is nothing further to do. The asset owner is to document this and move on. Set aside, for the moment, the question of what defines a device as being “updatable” via software.
Whether or not the software is updateable is largely irrelevant. If there is a mechanism to provide input to a program running on the device, there exists the potential to introduce malicious code – be it in the form of new instructions or simply instability in operation. Auditing a device through negative testing to determine whether its code “cannot be altered” is not a trivial task. It is certainly not something FERC, NERC, or any of the Regional Entities can do.
Time will tell how NERC CIP Version 5 is handled. FERC may decide to adopt the standards and issue a new direction to NERC as to where to next development of future iterations. FERC may also decide to remand the standards back to NERC for modification if issues raised warrant that. NERC, in consultation with FERC, will also have to determine how to audit and enforce compliance given the new levels of complexity in Version 5.
Finally, industry will ultimately decide how it will choose to implement the standards. Most importantly, once Version 5 goes into effect, industry needs to decide if they now feel safe in reaching beyond the requirements at the risk of missing the letter of compliance.
Part 2 of the series will show how NERC CIP Version 5 aligns to the current threat landscape.