Interested in linking to "How Can the NERC CIP Standards Be Improved?"?
You may use the Headline, Deck, Byline and URL of this article on your Web site. To link to this article, select and copy the HTML code below and paste it on your own Web site.
Many people familiar with the North American Electric Reliability Corporation (NERC) and its Critical Infrastructure Protection (CIP) standards have been voicing the belief that the standards are flawed. Most of these criticisms can be summarized by two general statements: 1) Compliance is focused on documentation and 2) A utility can be 100% compliant with the NERC CIP standards and still be very vulnerable.
The criticism that compliance is focused on documentation can be challenged by references to specific requirements in the standards that require access controls and monitoring. However, compliance checks are focused entirely on review of documentation. There are no requirements that the auditor or assessor verify the documentation by verifying device configuration or the quality of the implementation.
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 the notion that a piece of paper is more important than the result of a test or an actual control validation.
It is also true that you can be compliant and still 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. 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 controls' effectiveness.
We recommend that section C of each standard (Measures) be modified to include more than just a review of submitted documentation. We also 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, requiring that the auditing authority check the veracity of the documentation will increase the cost and time required for audits 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 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 auditing costs should be considered.
Standards should avoid being too detailed and prescriptive. Detailed standards run the risk of implicitly endorsing a specific tool, and 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.
The key elements of perimeter security 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 the segregation of management and security tools, such as backup/recovery, IDS and anti-virus 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 is 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. The DMZ may trust the PCN, and the PIN may trust the DMZ, but not vice versa. Do not use the same account credentials in the PIN as those used in the DMZ or the PCN, and use different authorities for authentication. This more effectively implements the purpose of an electronic security perimeter (ESP). Much of the effectiveness of an ESP is reduced if it permits authentication across the ESP by a single authority and account.
Connection Principles: Do not allow connections to traverse from the PCN to the PIN, but terminate them at a device in the DMZ (one level, one jump). The direction of the connection also is important. Do not allow devices in the PIN to open connections in the DMZ, or devices in the DMZ to open connections in the PCN. Allow only outbound connection requests.
Also, where possible, do not leave the connections open. Some applications, such as historians, require continuous connections. This elevates the importance of keeping these devices segregated and hardened with the latest security patches, and they must be constantly monitored.
Data Transfer: The basic rules for data transfer are the same as those for connections. Files should be pushed "up" from the PCN and pulled "down" from the PIN. Also, an anti-virus solution that scans files prior to their being written to disk is essential. The data transfer solution must use ports and services that are unlikely to be vulnerable. Avoid solutions that require NetBIOS, windows management instrumentation (WMI), etc. to be opened across the firewall. Ideally, the ports used should be configurable and a client/server model using account authentication is best.
Interactive Remote Access: Ideally, avoid interactive remote access. However, in the real world, it is likely to be required. First, require strong two-factor authentication to a device in the DMZ with a non-shared and unique account. Second ensure that the user's local PIN-based machine does not interact in any way with the PCN environment. The device establishing the second session from the DMZ to the PCN should enforce this. Third, leave interactive remote access accounts disabled until needed.
Monitoring: Monitor the DMZ in real time. This does not mean that someone must be constantly watching a dashboard, but that solutions are 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 or 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.
There are some specific principles that NERC CIP standards can require that will greatly improve cyber security.
Firewall and DMZ:
Data and File Transfer:
Interactive Remote Access:
And, finally, verification of compliance with the CIP Standards should involve more than confirming the existence of documentation. The documentation should be checked for validity—at least on a spot-check basis—with detailed follow up if required.