Disclaimer: MRO is committed to providing non-binding guidance to industry stakeholders on important industry topics. Subject matter experts from MRO’s organizational groups have authored some of the articles in this publication, and the opinion and views expressed in these articles are those of the author(s) and do not necessarily represent the opinions and views of MRO. The following article was written by Sharon Koller, Lead Compliance Strategist and Assurance Manager, CIP Senior Manager, American Transmission Company.

Challenging the Construct | Promoting Behaviors that Drive Security | Reducing Compliance Risk

As a CIP Senior Manager with nearly three decades of experience in the industry, I am preoccupied with achieving compliance with North American Reliability Organization (NERC) Critical Infrastructure Protection (CIP) Reliability Standards as a byproduct of sound security, reliability, and resiliency practices. In navigating this mission, and through my own experiences and personal interactions with other Registered Entities, I have routinely encountered a challenge many of us face; which is a balancing act of, or having to choose between, implementing a risk-based enterprise approach to security vs. a compliance-focused implementation that is limited to Applicable Systems within the CIP standards.

While I can appreciate  that many of us are faced with finite resources and a shortage of skilled physical and cyber security personnel, I cannot help but wonder if there is an underlying issue with the construct of the NERC Reliability Standards that redirects focus from risk-based activities to compliance activities. This article focuses on the CIP suite of standards; however, the constructs challenged here, and the concepts proposed, could be transferable to the Operations & Planning suite of standards, other sectors, or even other regulations beyond NERC to gain a unified approach.

My goal is to engage Registered Entities in a thought exercise regarding the content of the CIP Standards. This is not to be confused with the efforts of the NERC Modernization of Standards Processes and Procedures Task Force (MSPPTF); in fact the concepts within this article would complement the effort of reenvisioning the NERC Standards Development Processes.

This article explores CIP Cyber and Physical Security Reliability Standards to determine if or how they might disincentivize entities from going above and beyond in their security programs, ultimately contributing to the temptation of doing the bare minimum. If industry and regulators alike share a common mission—safe, secure, reliable, and resilient operation of the Bulk Electric System (BES)—what causes such preoccupation with compliance, audit, and violations? Why do we let this preoccupation overshadow a healthy and necessary concentration on enterprise-wide security posture? Where is the appetite to establish internal controls that achieve and maintain the security intent and spirit of the CIP standards beyond the words on the page? Is it limited resources—skill, staff, tools, budget, time? Is it fear? Is it culture? Is it the oversight and enforcement processes? Or is it the standards?

Pulling this string, what opportunity lies with revising the standards? Have we set ourselves up for success in the current approach, or do we inadvertently foster latent vulnerability? Many of the CIP Requirements foster a “set it, then forget it” mentality with another requirement to check or reperform at some periodicity, leaving entities at risk of noncompliance or exposure to security vulnerabilities—sometimes for extended periods of time—if the initial implementation was not sufficient, later changed, or in some way failed to operate as designed. If the initial process is flawed, the subsequent periodic activity may also not detect these failures or changes. Consequently, the condition and risk of exposure could persist for several cycles, compounding an entity’s vulnerability and susceptibility to security threats.

Our industry, comprised mostly of well-intended people who want to do the right thing, is faced with a body of standards that, while delivering a baseline of protection against risk, are designed to provide accountability when unexpected failures, even without impact, occur. Similarly, if an entity’s initial implementation went above and beyond the minimum requirements, and mistakes or failures occur that weaken or reverse components of a holistic enterprise-wide implementation, there can still be consequences, even if the residual controls meet compliance minimums. Some entities build in margin, and if scenarios where that margin is affected can still lead to determinations of noncompliance, let’s face it, that can feel defeating. The zero defect approach can have the unintended consequence of creating frustration and mistrust, and it can chip away at the desire to do more than the minimum compliance expectation. Over time, this cycle can disincentivize Registered Entities, bifurcate security from compliance, dilute our controls, and introduce security gaps. 

What if the standards were designed to promote behaviors that drive the implementation of sound security practices and an inherent motivation to maintain them through self-monitoring and continuous improvement? As an industry, should we be fostering a culture of greater resiliency through preparedness, response, and recovery at the security control level – and to do it in a way that benefits all of us by reducing the risk of non-compliance/penalties, reducing administrative burdens associated with oversight and enforcement, and ultimately putting the industry in a stronger position?

Redesigning the current requirement language in the CIP standards could reshape the industry’s perspectives and behaviors around security and refocus implementation efforts on the reduction of inherent risk, instead of simply reducing compliance risk.

I have an idea. What if we made each standard requirement self-healing instead of punitive? Essentially, each standard requirement would be rewritten to provide the opportunity for entities to be human, trusted to self-manage, and given a reasonable approach that compels us to be secure through a collection of preventive and detective controls and self-monitoring practices. Requirement language constructed with a parent requirement and four standard components as requirement parts – illustrated in the strawman below  – could achieve that goal.

Rx. [Parent Requirement] Meet security objective… Implement methods to include the following requirement parts: – Rx.1. Prevent the “bad thing” or outcomes, – Rx.2. Detect when preventive measures fail, – Rx.3. Correct detective failures, and – Rx.4. Test prevention and detection capabilities on some periodicity with intention to mature over time.

Entities that fail to implement these four basic components would still have to be held accountable for that failure. I realize this may appear oversimplified and acknowledge a bit of art and science will be necessary to assure the right words in the standards and requirements are used in the right context. For example, in Requirement Part Rx.1. “methods to prevent” could be “methods to protect,” depending on the security objective. Additional language is likely needed to assure complete, accurate, and timely execution. Requirement Parts Rx.2. and Rx.3. need to be time bound to assure urgency commensurate with risk. Language like “correct”, may be ambiguous, and can be interpreted as both overly broad, yet potentially limiting at the same time—so considerations need be made to be clear that “correct” is a simple way to refer to corrective or mitigating actions, which could include fixing the failed method or redesigning and implementing alternate, new, or more effective methods. The fourth component, Requirement Part Rx.4., is a safeguard and needs reasonable time bounding. All doable if we work together to enact effective change to the NERC Reliability Standards and requirements.

Reconstructing each requirement to collectively include these four components changes the violation severity outcomes and penalty spectrum. It also influences oversight activities and the manner between which regulators and entities engage. Under this construct:

• The entity would only be non-compliant with the preventive control (Rx.1.) if it were never implemented (which is effectively equivalent to a failure to implement the four basic components and having to be held accountable for that failure).
• An entity would not be non-compliant with the implemented preventive control when it fails; this is where acceptable tolerances and self-healing comes in. Instead, the entity would have the opportunity and incentive to detect and restore it to a secure position within a given timeframe.
• Certainly, a failure to implement the detection method (Rx.2.) would be a noncompliance, but of lower severity violation, and the failure to correct detected failures (Rx.3.) within the tolerance limits would be a noncompliance of yet a lower violation.
• Finally, a failure to safeguard by testing and verifying controls on the specified periodicity (Rx.4.) as an extra level of assurance would be a noncompliance, but of the lowest severity violation.

The beauty of this approach is that, if the protection is put in place, found timely when it fails, and protection is restored within the timeframes, there is no non-compliance. This may lead to an implementation that lets entities adapt protective methods to security threats, with an embedded opportunity to identify, assess, and correct the unexpected failures encountered without the risk of non-compliance. Periodic assurance activities test the operational and design effectiveness of controls, with the opportunity for observations that set the basis to mature over time.

This model builds our internal controls and assurance functions for us as a byproduct of compliance—and provides compliance evidence in the process without extra administrative burdens. This construct offers a solution that is not only able to build this in, but is deliberate in doing so. Entities that already leverage a ‘trust but verify’ approach to their internal assurance practices, with intention to learn and mindfulness to grow, are demonstrating a commitment to continuous improvement by developing best practices over time. Building an assurance program with internal independence, self-scrutiny, and transparency, can lead to strong and trusting partnerships that produce those verification records—which in turn could be leveraged by regulators who must also ‘trust but verify’ during external oversight engagements.

This approach also changes the overall conversation from an audit perspective to a controls’ effectiveness and residual risk perspective. It promotes transparency and reduces the stigma that can be born from failure. In this model, entities benefit by providing a list of failures and showcasing their ‘brag book’ that demonstrates how quickly they detected and corrected each failure and how they matured their controls over time to calibrate controls to everchanging threat landscape and maintain reduced inherent risk.

In doing so, entities would want to find gaps in their protections and would be incentivized to correct them fast. Through these actions, inherent risk is reduced, security is maintained, and punishment is removed by rewarding entities for the strength of their self-monitoring capabilities and the urgency of their response to correct failed or ineffectively designed controls. Is this not the spirit and behavior we want the NERC Reliability Standards to foster? When we promote these behaviors, we also create pride in our security programs and foster a healthy competition to keep protections in place that encourages testing ourselves, so our internal controls remain relevant, optimized and operating as designed to achieve security objectives.

I have learned I am surrounded by excellence within our industry. We are fortunate to have a role in writing the NERC standards and requirements. Through partnership, is there the possibility to collaborate to launch an effort to build a second option for the CIP suite of Standards using this model? Could this construct materialize as a parallel path for entities eager to embrace this approach and help prove its efficacy through a pilot or some other safe test method? What would preclude Registered Entities from working toward a model where zero defect is no longer a problem, and a condition would only rise to the level of non-compliance in these proposed simplified scenarios?

Hopefully, this article provokes thought amongst industry, and regulators, sparking further discussion about cracking the code on the construct of the NERC Reliability Standards and the pursuit of building self-healing requirements. Standards that shape behavior and fundamentally achieve a security posture aligned with the standards’ security objectives (self-monitoring and self-maintaining) should be resilient, yet adaptable to an ever changing security threat landscape and the end goal. How does this concept land with you? If you are interested in continuing this conversation, please join me on an upcoming monthly Compliance Monitoring and Enforcement Program (CMEP) Advisory Council call. All feedback and perspective are welcome.

As I continue to work to demonstrate these concepts through the delivery of a “Prove it! Prototype” stay tuned for the evidence that this construct is not only possible, but a true method to crack the code on Reliability Standards!

About the Author