How Can the NERC CIP Standards Be Improved?

By Jay Abshier and Phil Marasco

Many people familiar with the North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) standards have been voicing the belief that the standards are flawed. Most of those criticisms can be summarized by two general statements: 1) Compliance is focused on documentation, and 2) A utility can be 100%-compliant with NERC CIP and still be very vulnerable.

First Flaw: Compliance is Focused on Documentation

This statement can be challenged by references to specific requirements in the CIP standards that require access controls, monitoring and other technical actions. But compliance checks are focused entirely on producing documentation that the requirements have been met. There are no requirements that the auditor or assessor verify the documentation by actually logging onto a firewall to review its rules or log onto devices to verify their configurations.

Protests that verification of the documentation is in the spirit of the standards ignores the fact that what counts is how the standard is written, not its intended meaning. As a result, assessments of CIP compliance are often done by individuals or companies that do not have extensive cyber security expertise and, following the letter of the standards, focus only on whether documentation can be produced. This feeds into the notion that a piece of paper or text document is more important than the result of a test or actual control validation. The U.S. federal government is dealing with this phenomenon right now while trying to overhaul its Federal Information Security Management Act (FISMA) standards.

Second Flaw: You Can Be Compliant and Still be Vulnerable

The existing requirements in the CIP Standards are actually pretty good. But, they do not address common methods of successfully attacking a protected network. For example, a preferred method of attack is to compromise a device on the outside that has connectivity to a device on the inside. Once compromised, the hacker can then get to the inside device and possibly give himself accounts on the internal systems that make his return much easier. CIP standards place the primary emphasis on how the perimeter is defined and protected, rather than actually monitoring internal systems. Because of this, too many organizations think "defense in depth" is doubling the number of firewalls instead of monitoring or validating the control's effectiveness by actually analyzing the traffic or the systems.

Suggestions to Improve the Standards

First, we recommend that section C (Measures) of each standard be modified to include more than a mere review of submitted documentation. Second, we recommend that specific cyber security principles that can delay, if not prevent, common methods of attack be added to the existing requirements.

Currently, the measures for determining compliance are primarily based on the existence of documentation. Unfortunately, standards that require that the auditing authority check the veracity of the documentation will increase the cost and time required for audits and compliance checks to unrealistic levels. Finding an acceptable compromise between the two extremes is necessary.

One solution might be to add a measure that requires that the auditing authority perform spot checks on randomly selected requirements. If a significant number of these spot checks identify required documentation that does not match the actual implementation, then the number of documentation checks performed should increase. Also, if there are significant discrepancies between the documentation and the implementation, perhaps requiring the entity being audited to pay for the increased costs should be considered.

It is understandable that standards should avoid being too detailed and prescriptive. First, detailed standards run the risk of implicitly endorsing a specific technical solution and second, prescriptive standards become obsolete more quickly than standards that are generic. However, there are several widely accepted cyber security principles that could be endorsed, if not required, that are not likely to become obsolete and do not prescribe specific technical solutions. As an example, we will look at the first line of cyber defense―the perimeter.

Recommendations for Improved Cyber Security Protections

The key elements of perimeter security that are examined are the demilitarized zone (DMZ), connection principles, data transfer, interactive remote access and monitoring.

DMZ: A firewall with a DMZ between the process control network (PCN) and the plant information network (PIN) is essential for effective cyber security. Non-firewall demarcation devices do not provide the rule granularity required, nor do they support a DMZ. The DMZ allows management and security tools, such as backup/recovery, intrusion detection systems (IDS) and anti-virus, to be segregated from both the PCN and the PIN. But its primary purpose is to provide a termination point for connections between the PCN and PIN. Forcing connections to terminate in the DMZ introduces a second obstacle between a hacker or malware in the PIN and the critical process control functions in the PCN. This can be termed as the "One Level, One Jump" rule.

Ideally, for example, if Active Directory (AD) type domains are used, the PCN, the DMZ and the PIN will be on separate domains that have limited trust between them. For example, the DMZ may trust the PCN, and the PIN may trust the DMZ, but not vice versa. Account credentials used in the PIN must not be the same as those used in the DMZ or the PCN, and different authorities must be used to authenticate the accounts. This more effectively implements the controls intended to be created by the implementation of electronic security perimeters (ESP). Much of the effectiveness of an ESP is reduced if it permits authentication across the ESP, based on common credentials that are used both inside and outside the ESP.

Connection Principles: As mentioned above, connections should not be allowed to traverse from the PCN to the PIN, but be forced to terminate at a device in the DMZ (One Level, One Jump). Also, the direction of the connection is important. Devices in the PIN should not be allowed to open connections in the DMZ, and devices in the DMZ should not be allowed to open connections in the PCN. The reverse is preferred―only allow outbound connection requests.

Also, where possible, the connections should not be left open. Some applications, such as historians, require continuous connections. If this is the case in your environment, then the importance of keeping the devices segregated and hardened with the latest security patches is elevated, and they must be constantly monitored in real time.

Data Transfer: The basic rules for data transfer are the same as those for connections. Data and files should be pushed "up" from the PCN and pulled "down" from the PIN. Also, an anti-virus solution that scans files prior to its being written to disk is essential, which typically rules out any database-to-database transfers. The data transfer solution must use ports and services that are unlikely to be vulnerable. Solutions that require NetBIOS, Windows management instrumentation (WMI), etc. to be opened across the firewall should be avoided. Ideally, the ports used should be configurable, and a client/server model using account authentication is best.

Interactive Remote Access: Ideally, interactive remote access should be avoided. But in the real world it is likely to be required. If required, the first key principle is to require strong two-factor authentication to a device in the DMZ with a non-shared, unique (and therefore traceable) account. The second key principle is to ensure that the user's local PIN-based machine does not interact in any way with the PCN environment (in violation of the One Level, One Jump rule). The device establishing the second session from the DMZ to the PCN should enforce this. The third key principle is to leave interactive remote access accounts disabled until needed.

Monitoring: The monitoring solutions implemented in the DMZ should employ real-time monitoring. This does not mean that someone must be constantly watching a dashboard, but that the solution is able to detect anomalous behavior and alert someone who can quickly get to the dashboard to investigate. Also, monitoring solutions should be capable of terminating suspicious, anomalous communications. While this may occasionally cause inconvenience, it should not impede productivity, since time critical process activity is usually not required between the PIN and PCN.

Summary

There are some specific principles that NERC CIP standards can require that will greatly improve cyber security. In summary, these are:

Firewall and DMZ

1. A DMZ with a firewall should be required between the PIN and the PCN.
2. Require different account credentials in the PIN, DMZ and PCN.

Connections

1. Connections should not go from the PCN to the PIN, but should terminate in the DMZ, and then a second connection is established from the DMZ to the PIN.
2. Connection requests should only be allowed outbound from the PCN.
3. Connections should not be left open (should not be persistent).

Data and File Transfer

1. Data should be pushed from the PCN up and pulled down from the PIN.
2. A client/server model with unique, authenticated accounts should be used.
3. Avoid using services, such as NetBIOS, which effectively extend the authentication mechanisms and credentials across the perimeter.

Interactive Remote Access

1. Require two-factor authentication.
2. Isolate the user's local desktop from the PCN.
3. Leave interactive remote access accounts disabled until needed.
4. Enforce One Level, One Jump.

Monitoring

1. Monitor the DMZ in real time.
2. Automatically alert on suspicious or anomalous communications in the PIN.
3. Automatically terminate suspicious or anomalous communications in the DMZ.

And finally, verification of compliance with the CIP Standards should involve more than the existence of documentation. The documentation should be checked for validity―at least on a spot-check basis with detailed follow-up if required.

Jay Abshier, CISSP, is a security consultant at Sentigy
Phil Marasco, CISSP, is a security consultant at Securicon.