James Holler, Founder, Abidance Consulting

During World War II the allies had some major challenges. Among the strangest was that the use of English by the Americans and British had many things in common, but also had many things different. As a result, there were problems in coordination, logistics and security.

Fast forward to 2006 and remember the creation of the CIP 002-009 Standards by NERC with approval from FERC. There were, and are, many challenges of interpretive guidance as can be expected from an imperfect set of documents that catered to the lowest common denominator while simultaneously skimping on clarity for the entity players to understand.

What does CIP-002 thru CIP-009 have to do with COM-001 you might ask? Plenty…the rule in the IT world is that you have an islanded or closed network (LAN) if you cannot use telecommunication hubs (like commercial carriers or satellite) to connect multiple sister nodes (other LANs) to create what is referred to in the network world as a WAN (Wide Area Network).

Let’s take a look at the Standard and see if we can make sense of it.

Let’s look first at the purpose statement COM-001. It says: “Each Reliability Coordinator, Transmission Operator and Balancing Authority needs adequate and reliable telecommunications facilities internally and with others for the exchange of Interconnection and operating information necessary to maintain reliability”

Notice two things, “reliable telecommunications facilities internally” & “with others for the exchange of Interconnection and operating information.”

This implies that the following requirements must meet these needs to be considered “compliant.” So, let’s look a little more deeply into the requirements.

COM-001 Requirement 1 and Requirement 1.4 states:

R1 Each Reliability Coordinator, Transmission Operator and Balancing Authority shall provide adequate and reliable telecommunications facilities the exchange of Interconnection and operating information:

R1.4 Where applicable, these facilities shall be redundant and diversely routed.

On the surface these requirements appear to be straightforward, but after a number of audits by FERC and NERC staff, it is anything but.

Both of these requirements would better be defined as simply nebulous. What defines “adequate”? “Where applicable”? Who decides what is adequate and where applicable…NERC, FERC or the Registered Entity that is being audited?

The auditor is the sole determining factor in compliance or noncompliance with these requirements. If they get it wrong, as many of them do, then you don’t have a compliant facility from a reliability perspective.

What R1, when tied to R1.4, says as it relates to the purpose is that if you only have one communications trunk entering your network and then have it multiplexed out to your Primary Control Center (PCC) and your Backup Control Center (BCC), you are not in compliance.

Another problem is that of the definition of what constitutes a telecommunications facility. It means different things to a telephone company technician and to an IT technician.

FERC and NERC define these to be BOTH data and voice traffic. You cannot simply have two phone lines and expect to be compliant if you are also doing data traffic from the PCC and BCC as part of your operations. You will fail the audit on this alone and fines are more than a possibility, they are virtually guaranteed.

James Holler is founder of Abidance Consulting.

James Holler, Founder, Abidance Consulting

Complying with the NERC CIP requirements is expected to be a major expense for power producers and the like in the coming years. To date, companies have spent tens of millions of dollars to formally document and test the support for internal control assertions required by CIP and maintaining this documentation will continue to be costly beyond the first round of documentation.

Let’s take a look at some of the most important components of a good NERC CIP compliance program:

Automate The Testing & Reporting Of All Of The Technical Controls

An important concern for power producers is finding a cost-effective method of documenting, storing, and analyzing CIP control assessment work. Management is also looking to meet all the technical requirements spelled out in the requirements. In the first year, many companies have elected to use spreadsheets to tackle CIP documentation because they are familiar with the tool. Moreover, some companies prefer to use spreadsheets because the CIP requirements are still evolving.

Spreadsheets have significant limitations that will increase compliance risks. In addition, depending on spreadsheets for CIP documentation may prevent companies from improving their compliance process and risk management capabilities. In the first year of CIP compliance efforts, many internal auditors and project consultants have advised power producers to use their existing spreadsheet software to document compliance efforts. There is no way that these tools are sufficient to document all relevant accounts, account assertions, risks, controls, and deficiencies. The only way to truly document everything is to automate the process.

Use File Integrity Checks To Assure Your Systems Are In A Desired State

It is very difficult to compromise a system without altering a system file, so file integrity checkers are important. A file integrity checker computes a checksum for every guarded file and stores it. At a later time you can compute a checksum again and test the current value against the stored value to determine if the file has been modified. Some lesser quality file integrity checkers use a 32 bit CRC (Cyclic Redundancy Check). Attackers have demonstrated the ability to modify a file in ways that the CRC checksum could not detect, so stronger checksums known as cryptographic hashes are recommended.

One of the challenges in using a file integrity checker is the false positive problem. When you update files or apply system patches this changes the file. Creating the initial database of signatures is easy; keeping it up to date is much harder. However, even if you only run the checker once (when you first install the system) this can still be very valuable. If you are ever concerned that the system was compromised you can run the checker again to determine which files have or have not been modified.

The other challenge with a file integrity checker is that you have to have a pristine system when you create the first reference database, otherwise you may be creating cryptographic hashes of a compromised system while feeling warm and fuzzy that you are implementing good security. It is also very important that you store the reference database offline or an attacker may be able to compromise the system and hide their tracks by modifying the reference database.

Test System Configurations Against External & Internal Policies

Testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. Testing also provides an objective, independent view of the configurations to allow the facility to understand the risks in the implementation of the configurations. Test techniques include, but are not limited to, the process of executing a configuration with the intent of finding “bugs”.

Testing can also be stated as the process of validating and verifying that the configurations:

• meets the business and technical requirements that guided its design and development;
• works as expected; and
• can be implemented with the same characteristics.

Testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the configuration methodology adopted.

Testing can never completely identify all the defects within your configurations. Instead, it furnishes a criticism or comparison that compares the state and behavior of the configurations against principles or mechanisms by which someone might recognize a problem. These principals or mechanisms may include (but are not limited to) specifications, contracts, comparable products, past versions of the same product, inferences about intended or expected purpose, user or customer expectations, relevant standards, applicable laws, or other criteria.

A study conducted by NIST in 2002 reports that bugs cost the U.S. economy $59.5 billion annually. More than a third of this cost could be avoided if better testing was performed.

A primary purpose for testing is to detect configuration failures so that defects may be discovered and corrected. This is a non-trivial pursuit. Testing cannot establish that configurations functions properly under all conditions but can only establish that they do not function properly under specific conditions. The scope of testing often includes examination of configurations as well as execution of those configurations in various environments and conditions: does it do what it is supposed to do and do what it needs to do.

There are so many areas that can be addressed for automating that it would take dozens of pages for them all to be discussed. This blog was intended to give you a start on what you need to do if you truly want to ensure total CIP compliance.

James Holler is founder of Abidance Consulting.