Streetlight Effect Apparent in NERC CIP Requirements

This comment is in response to an article in the ReliabilityFirst Newsletter - "Virtual Systems and Zones of Authority".

I'm going to quote a bit liberally, since the original on page 7 is difficult to link to directly. But first, read this:

https://en.wikipedia.org/wiki/Streetlight_effect

"Responsible Entity personnel see their entire network as a whole, with the parts of that network subject to CIP compliance as part of a larger security picture. They can see the protections afforded to all systems, and can see how the protections applied to non-CIP assets increase the security of CIP assets as well.

CEA personnel, on the other hand, only have CIP assets within their purview. They cannot consider non-CIP assets as adding to the entity's security posture, as those assets are not under the CEA's regulatory authority. Non-CIP assets are not subject to audit by the CEA and may change at any time with no notification to the CEA.

This difference in viewpoint can lead to conflicting views of virtual systems such as virtual networks. Responsible Entity personnel see the protections applied to the non-CIP networks that might share, for example, a physical switch with CIP networks. They see the multiple layers of protection and the controls surrounding the security of these non-CIP networks.

CEA personnel, on the other hand, do not have the authority to review the security level of non-CIP assets or networks. The CEA personnel must therefore assume that any non-CIP assets or networks could be compromised and used in attacks on the in-scope CIP assets and networks. The resulting differences in the perception of risk can be a source of misunderstanding between Responsible Entity personnel and CEA personnel.

I call this difference in perspective “mixed zones of authority.” The Responsible Entity's zone of authority is all of its owned assets, both CIP and non-CIP. The CEA's zone of authority is limited to assets that are in scope for CIP.

For this reason, and others that I don't have the space to go into here, I strongly recommend that

Responsible Entities refrain from implementing Cyber Assets or networks that mix CIP in-scope and out-of-scope assets, network traffic, or data. The reason for not mixing in-scope and out-of-scope is not, as is commonly discussed, that “untrusted” configurations are implemented.

The biggest issue, in my view, is that without being able to view all aspects of the systems used for BES reliability, there is no way for the CEA to ensure that weak or high-risk configurations are not implemented."

{emphasis added in the last two paragraphs.}

That’s an interesting perspective. Once again, the crux of the argument is not whether or not virtualization adds to or subtracts from security. It’s the difficulty of auditing that drives the recommendation.

This, my friends, is a terrible basis for driving standards. It is what is known as a perverse incentive. It drives one to make decisions that, on the basis of achieving the objective, one would not otherwise make. It's a common problem in security, that one does what is visible, and easy to measure rather than closing the worst (invisible) gap. In fact, this is a problem far beyond security, it happens in all kinds of production environments with easily gathered statistics, in management, etc.

Standards should not be about making the network easy to audit, it should be about making it difficult for a bad actor to compromise reliability and security. Industry knows how (or individual entities can quickly learn how) to secure a virtual environment in shared infrastructure mode. Industry properly securing the virtual environment isn’t the sticking point. Even the Federal Government's more security-conscious entities have processes for contracting compliance in Cloud Computing. Surely an entity is capable of adequate control in its own networks.

Take a look in the PCI standard and its glossary. The concept of trusted and untrusted network is defined there as:

Trusted Network	Network of an organization that is within the organization’s ability to control or manage.
Untrusted Network	Network that is external to the networks belonging to an organization and which is out of the organization’s ability to control or manage.

There is no logical basis to assume that an entity capable of providing a compliant solution inside their ESP is simultaneously unable to or unwilling to provide security to Cyber Assets under their own control outside the ESP, simply because the auditing agency doesn’t have explicit control over this latter subset of Cyber assets. Requirements-based language may be the problem, where an objective-based standard wouldn’t have quite the same problem. For example, proof that you meet the objective of “isolation” would tend to consist of controls and measurements applied inside, outside, and on the perimeter. It doesn’t require the bright line of layer 3 “ESP” as the sole measure of compliance and it works well with security zones as a concept.

As long as Critical Infrastructure Protection is driven by compliance rather than security, the Grid will be at unnecessarily elevated risk.