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 goes over changes to the NERC CIP standards and challenges facing the industry as they wrestle with compliance in a changing threat landscape.
Part 3 in this 4 part series goes over gaps in the controls catalog in NERC CIP Version 5 that could help beef up security in the electric sector. See Part 1 and Part 2.
Scope
By far, biggest thing missing in NERC CIP Version 5 is a sense of scope. To be clear, there is no linear relationship to an increase of scoped assets to an increase in security for the grid. There are engineering and resiliency studies, threat assessments, sector and regional interdependency assessments, and much more to consider before any change in scope is undertaken.
The scope gap I’m speaking of is one of expectations. As pointed out numerous times in Part 2 of this series, the NERC CIP standards only apply to Bulk Electric System (BES) assets. Even at that, the controls contained within the standards do not apply to all BES assets equally. For example, many of the controls that are mandatory are conditional and based upon whether or not a given device can accommodate the requirement.
Many electric utilities also participate in natural gas, water, waste water, and other critical infrastructure sectors. There is a danger in focusing too much energy on one specific regulation that covers such a small, albeit vital, segment of a given business operation. However, that is exactly what has occurred.
Frequently, utility security budgets are aligned solely to the NERC CIP standards given the heavy administrative overhead of compliance. There is often nothing left over to cover securing the remaining areas of the business. With small, integrated utilities in the municipal and co-op spaces, this affect is amplified even more. Utilities are not alone in this regard and you can see this alignment in most regulated industries – even the federal government through the FISMA C&A process – until the proverbial paper tiger is slain.
The NERC CIP standards have their place, and it is an important one. That place is defined through the Federal Power Act and FERC orders, which established administrative law on the scoping of the NERC CIP standards – such as Order 672, Order 706, and Order 773. This is a narrow scope which is reduced further through the High/Medium/Low Impact weighting system in Version 5 of the NERC CIP standards.
In short, don’t expect this iteration of the standards to do much more than the previous versions have.
Policy
In what appears to be a bit of a disagreement between FERC and NERC, CIP-003-5 has removed any requirement to document exceptions to a utility’s security policy. The documented reasoning behind this is a statement from FERC saying that no regulated utility may exempt themselves from the NERC CIP standards.
The removal of this requirement incentivizes a regression in a utility’s security program maturity. Effectively, utilities are now encouraged to maintain multiple security programs and policies as opposed to building a holistic approach. There is to be one policy with slate of internal standards and procedures for assets, personnel, etc., in scope for NERC CIP, and something else – if anything – for other areas of the utility.
The removal of this requirement sends a message that any non-regulated actions taken by a utility do not really matter. Non-compliance security dollars are hard to come by. State PUCs – let alone county and city councils – aren’t yet mature enough themselves to understand what is necessary and reasonable to recoup for security investments and maintenance in a rate case. Even then, it is a rare circumstance that CIP-related capital or O&M are specifically called out or approved in a rate case.
Software Assurance
While there are requirements in CIP-007-5 around the ability to “deter, detect, or prevent” malicious code, these largely revolve around code being introduced at run time. There are requirements around monitoring, assessing, and applying software patches as well. Missing entirely are requirements around secure coding practices, source and binary code management, and other commonly accepted assurance controls.
When a utility learns of a breach or other type of compromise, what measures are in place to ensure that code running on critical or support systems is trusted? This is a difficult question to answer and can most certainly move beyond the point of being able to prescribe specific actions through regulation. Completely punting on this for the next four or more years because it is difficult, however, is a miss.
I’ve heard arguments that CIP-010-1 R1 change management requirements fall into this category. Unfortunately, this is an inventory list only that includes things like product name and version for some, but not all software installed on a given asset. There are no requirements to cryptographically hash or otherwise prove that a given version of a file or firmware installed is the same as what is documented as being installed beyond matching the version number. A utility would be wise, however, to latch onto this requirement from a budget authorization standpoint as justification for implementing such controls.
Process Assurance
Similar to code assurance, there is nothing in the standards that cover process integrity. I’ve avoided talking about Stuxnet so far in this series, primarily because it’s far too overused. Nothing in NERC CIP Version 5 would indicate an awareness of Stuxnet – let alone impart an ability to prevent copycat attacks operating on embedded systems such as PLCs.
As you may have read in part 2, there is this language in CIP-007-5:
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.
This is a problematic statement as it implies there is a universal understanding as to what “no updateable software” means and how to determine if “its executing code cannot be altered”. Most embedded systems are often lumped into this category by default without validation by engineers or negative testing regimes.
This is another case where the change management controls in CIP-010-1 would not provide value beyond an inventory. Configuration items are not scoped to CIP-010-1 change management controls and CIP-005-5’s “malicious communication detection” requirements are limited only to perimeter access points.
Under this scenario, in an environment where utilities are not even getting rate relief for major infrastructure upgrades, a utility would have to spend discretionary funds to implement basic defensive layers. They would not be able to justify these expenses to a utility commission as a regulatory requirement. Barring that, they’re left to hoping that the conditional scoping embedded throughout the standards has left them with enough layers of defense to preclude introduction of malicious instructions – not necessarily “code” – to the system.
Communication Assurance
Simply put, there is none. The word “encryption” makes its way into Version 5 of the standards, but only in the context of interactive remote access into an Electronic Security Perimeter. Language around machine-to-machine communications is again omitted.
Encryption alone is not a guarantee of non-repudiated communications. Authentication, access control, and other end node security mechanisms all play a part. Version 5 finds the ever popular “ports and services” phrase as the only criteria for whether or not a specific communication is authorized.
Authentication and other more robust access control requirements are saved for human interactive use of system resources. If an adversary has a foothold on the network, either through purloined credentials, undefended malware, or via an authorized communications path, there are no requirements to make sure they cannot remote send a valid yet malicious command to a system.
Summary
This sounds like a scathing review of NERC CIP Version 5 and, in many ways, it is. However, it appears that this version of the standards is directly in line with what has been asked by FERC. That is, to bring to a close all outstanding issues in Order 706. Keeping that in mind, it appears that the job is largely done. It’s time to move on and put Order 706 to bed.
The CIP standards were largely content complete in 2006. Version 5, assuming FERC approves them without delay, will go into effect in 2015. They will remain so until the next iteration or replacement of the CIP standards. From Version 1 to Version 5, very little has changed beyond scoping.
Part 4, the final post in the series, will outline a number of steps that can be taken to move the issue of security regulation in the sector off of this costly war of words and onto a more productive path.
Image by Whatknot