Achieve NERC CIP Compliance With Automated Security Controls
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.