This one is going to go into something that I work with on a day-to-day basis at my current job. Everyone knows HIPPA, Sarbanes Oxley (SOX), and PCI-DSS are common compliance frameworks that delve into the securing of information systems, but one that is often overlooked is the regulatory compliance guidelines that the energy industry is required to follow.
In the energy industry, we’re required to follow Critical Infrastructure Protection (CIP) Standards published by North American Energy Reliability Corporation (NERC).
The goal of CIP Standards:
The goal of CIP standards is actually to protect the critical infrastructure that controls many of the functions of the grid, this includes everything from the generation, transmission, and load balancing of power throughout the grid.
CIP Standards are published by NERC and enforced by regional enforcement agencies. There are currently six different regions within the United States, each managing separate portions of the grid.
There are standards other than CIP that the energy industry has to comply with, in addition to the CIP “cyber-security” standards, NERC has published various other standards that go into the Emergency Operations, Transmission, Load balancing and others that are primarily focused on procedures and policies regarding the actual management of load.
A complete list of standards can be found at:
What does CIP Encompass
Like many regulatory compliance frameworks, CIP covers everything from asset identification, access control, incident response, recovery, and information protection. As of today, there are currently 12 CIP standards that are subject to current or future enforcement in the near future.
|CIP-002||BES Cyber System Categorization|
|CIP-003||Security Management Controls|
|CIP-004||Personnel & Training|
|CIP-005||Electronic Security Perimeters (ESP)|
|CIP-006||Physical Security of BES Cyber Systems|
|CIP-007||System Security Management|
|CIP-008||Incident Reporting and Reponse Planning|
|CIP-009||Recovery Plans for BES Cyber Systems|
|CIP-010||Configuration Change Management and Vulnerability Assessments|
|CIP-013||Supply Chain Management (Future Enforcement, July 2020)|
|CIP-014||Physical Security (not Cyber-security related, I won’t be covering this one)|
Alright, for the scope of this one, I’m going to skip right ahead to CIP-005. CIP-002 is an easy one, the requirements here are pretty simple, we have to identify and classify any cyber assets, along with the impact rating they would have to the grid.
A list of all standards, along with some technical rationale behind them can be found here:
NERC specifies impact ratings. These impact ratings are based off of the projected impact a site or facility would have to the grid. There are currently three different impact ratings:
- Low – a low impact BES facility is any facility not rated medium or high impact, generally the threshold is a minimum of 75MW (MVA) to be considered an in-scope facility for NERC. Anything below that is considered “no-impact”, or out of scope for NERC.
- Medium Impact – there are different criteria for this based off of the functions you are performing. Control Centers, Generator Owners, Generator Operations, Transmission Owners, and Transmission Operators each have their own criteria for medium impact.
- High Impact – again with medium impact, each function has their own criteria, if you’re interested in this, read CIP-002-5.1a for more information.
The impact rating of the facilities dictates what standards you are subject to. I will be focusing on a Medium Impact Control Center since these actually happen to be some of the most common facilities out there, there are medium impact Generation Facilities, as well as Medium-Impact Tran mission Facilities, but we’ll be focusing on the control center.
I mentioned the term “BES”, all this means is bulk-electric system. A system that is part of one or more interconnect.
Control Center Criteria
There are different Criteria for Control Centers that dictate your impact. See the below table:
|Description||Resulting Impact Rating|
|Each Control Center or backup Control Center used to perform the functional obligations of the Reliability Coordinator.||High|
|Each Control Center or backup Control Center used to perform the functional obligations of the Balancing Authority: 1) for generation equal to or greater than an aggregate of 3000 MW in a single interconnection, or 2) for one or more of the assets that meet criterion 2.3, 2.6, or 2.9.||High|
|Each Control Center or backup Control Center used to perform the functional obligations of the Transmission Operator for one or more of the assets that meet criterion 2.2, 2.4, 2.5, 2.7, 2.8, 2.9, or 2.10.||High|
|Each Control Center or backup Control Center used to perform the functional obligations of the Generator Operator for one or more of the assets that meet criterion 2.1, 2.3, 2.6, or 2.9.||High|
|Each Control Center or backup Control Center, not already included in High Impact Rating (H) above, used to perform the functional obligations of the Generator Operator for an aggregate highest rated net Real Power capability of the preceding 12 calendar months equal to or exceeding 1500 MW in a single Interconnection.||Medium|
|Each Control Center or backup Control Center used to perform the functional obligations of the Transmission Operator not included in High Impact Rating (H), above.||Medium|
|Each Control Center or backup Control Center, not already included in High Impact Rating (H) above, used to perform the functional obligations of the Balancing Authority for generation equal to or greater than an aggregate of 1500 MW in a single Interconnection.||Medium|
|Control Centers and backup Control Centers not included in the above criteria.||Low|
Our theoretical control center will fall under the criteria where we are operating in excess of 1500MW in a single interconnection. We are therefor a Medium-Impact control center.
CIP-005 dictates standards that must be followed to secure BES cyber assets that have external-routable connectivity (ERC). As a medium impact control center, here is a table of the requirements we are subject to under CIP-005.
Requirement 1 – Electronic Security Perimeters
|1.1||All applicable Cyber Assets connected to a network via a routable protocol shall reside within a defined ESP|
|1.2||All External Routable Connectivity must be through an identified Electronic Access Point (EAP).|
|1.3||Require inbound and outbound access permissions, including the reason for granting access, and deny all other access by default|
|1.4||Where technically feasible, perform authentication when establishing Dial-up Connectivity with applicable Cyber Assets|
|1.5||Have one or more methods for detecting known or suspected|
malicious communications for both inbound and outbound communications
This requirement is one of the easier ones to understand. It simply requires us to have a network that is protected by one or more firewall to secure communications.
Part 1.1 requires us know that these networks exist, have drawings, assets sheets, or other documentation that specifies what assets reside in this network.
It also requires that we have written policies and procedures for establishing these ESPs, along with methods to verify that assets do not exist outside of an ESP.
Part 1.2 requires us to identify any paths that can be used for inbound or outbound communications, these are reffered to as Electronic Access Points, or an EAP.
A common misunderstanding here is that an EAP is a device itself, it is not. An EAP is an interface on a device. Most commonly we will use next-generation firewalls, and an interface on those will be specified as the EAP.
Part 1.3 requires us to have documentation and authorization related to the configured firewalls on our EAP. It also requires that we have a deny-by-default rule in place, which is normally default without us even configured it.
Documentation can be a spreadsheet or really anything detailing the configured firewall rules, along with who configured and who authorized them.
If you utilize the implicit deny instead of an explicit deny, be prepared to supply vendor documentation stating that this is the normal operation. In any event, it’s really just easier to configure an explicit deny-all in both directions.
In an audit, not only will you be asked for the documentation of authorized access lists, but you’ll also be asked for the running configuration to validate that they align with the authorized access lists.
Part 1.4 requires us to use authentication of some form, not specific on what, when Dial-Up is used. In the real world, Dial-Up might be used on remote facilities in remote locations where no broadband or fiber connectivity exists.
Since we’re in a control center, we’re going to assume we’re in a populated area with established fiber and broadband infrastructures and as such our method of complying with this will be to enforce this via our policy.
Our policy will prohibit the use of dial-up communications all together. Of course, auditors will want to know how we verify and validate there is no dial up communication and this will be performed during our periodic walk-throughs and inventories of our system.
Part 1.5 is why we use Next-Generation firewalls. This part of the requirement requires us to have a method to detect, or block known malicious communications.
We all know what these are, these are our Intrusion Detection and Prevention systems. One of the things that’s interesting about this policy is that it’s really up to us whether we block these communications, we’re only required to detect them.
And that’s probably a good thing, any IPS is subject to false positives and when we’re dealing with real-time control of critical infrastructure, we don’t really want the potential for an outage because an update to an IPS signature blocked that communication on us.
Auditors are going to want to see a drawing here that specifies where the IDS inspection point is. They may also want running configurations showing that the IDS is configured and that traffic is configured to be inspected.
Later on we’ll talk about Anti-malware definition updates in CIP-007, IDS signatures are viewed the same as anti-malware definitions and we’ll have to document a method for testing and deployment of these signatures regularly.
There is no specified time period on how often we have to update these. Testing is more along the lines of ensuring that the update does not block authorized communications, not so much that it actually catches malicious traffic.
Requirement 2 – Interactive Remote Access Management
|2.1||Utilize an Intermediate System such that the Cyber Asset initiating|
Interactive Remote Access does not directly access an applicable Cyber Asset.
|2.2||For all Interactive Remote Access sessions, utilize encryption that|
terminates at an Intermediate System
|2.3||Require multi-factor authentication for all Interactive Remote Access sessions|
This is where things start to get interesting, but this still isn’t the full face of the vagueness of CIP standards.
What is Interactive Remote Access?
Well, NERC’s definition lacks on this one. They specify a few criteria for it, but this can be summed as user-initiated communications to an asset within the ESP.
There are few key things things to understand about interactive remote access:
- Interactive Remote Access is intended for support personnel maintaining the BES cyber system, not for actually monitoring or controlling BES assets.
- Interactive Remote Access does not include machine-to-machine communications such as replication, heartbeats, etc.
Okay, this one might be a little confusing based off of the wording. Essentially what they are requiring us to have is a bastion server that does not reside within our ESP.
Typically implementations of this include a bastion server, otherwise referred to as a “jump-host” in a managed DMZ. There is no requirement that the server cannot be dual-homed. When I say this I mean that the server can have an interface in the DMZ, as well as an interface in the ESP.
If this is your desired implementation, then you would also be required to document that interface as an EAP.
Also keep in mind that if this was the choice, you would also have to have a method for IDS inspection at this EAP.
Diagram of a Dual-Homed Jump-host implementation:
It’s much easier to have this system in the managed DMZ where it is required to route through the firewall prior to initiating a connection with a device in the ESP.
Here’s a diagram of a normal jump-host residing in a managed DMZ where it has to route back through the firewall to initiate a connection to a device within the ESP:
It is never acceptable to have port-forwards or any type of static NAT for direct access to a device in the ESP. There must always be what is referred to as a “protocol-break”. No outside interactive sessions can communicate directly to a device within the ESP.
Auditors will likely want proof that the device is not dual homed, if the device is dual homed they will want documentation that IDS inspection is occurring, as well as that it is a documented EAP.
In addition to the above, they’re going to want a list of all assets that are currently accessible from this system. They will also want a list of installed applications to ensure that there are no applications that can directly control power from the jump-host.
There’s actually a lot more that they’ll want since this device is classified as an EACMS. It’ll fall into scope for just about every CIP requirement we are subject to.
This is where things get a little tricky. Not only are we required to have some sort of jump-host, but we’re also required to have encryption for this system that terminates at the system itself.
That means that if you have a client-based VPN such as Pulse-Secure, Forticlient, AnyConnect, or GlobalProtect that the encryption it provides will not suffice. The encryption must terminate at the jump host itself.
With the requirement for encryption throws out many options off the bat, we can’t have a telnet gateway or any system which doesn’t provide end-to-end encryption.
Alright, so we know a lot of things provide encryption by themselves. Remote Desktop does, and often times that’s used. There is some difficulty here though because you also have to have some forethought and remember that Part 2.3 requires us to enforce MFA.
Now, there’s no perfect way to do this and everyone’s setup will be different, however, one of the most widely used solutions and possibly my favorite is a product from ManageEngine known as Password Manager Pro.
I want to be clear that I do not endorse this software, but that it does seem to meet the CIP standards.
This one is a little more difficult to prove to auditors, network documentation will help, but they’ll probably want to see this actual system in action. They might want to see packet captures to verify the traffic is encrypted.
This is one of the standards that I definitely think is a requirement for any system that gives you access to a system remotely, not just for the BES. I think this one is best practice for any company still using client VPNs to provide access to internal resources.
We’re required here to enforce multi-factor authentication for access to the jump-host. We should already know what MFA is, and for this one the only real options for us are:
- Something the user has (OTP token, Smart Card)
- Something the user knows (Username/Password/PIN)
I’m not sure about you, but I simply don’t trust any of the commercially available bio-metric systems out there that could support this. I do know that if you did implement this it would likely meet requirements, but you have to think about the false acceptance rate here and how easy most systems are to spoof.
There is some gray area on what you can use here, but remember that it has to be compatible with the solution you use. If you’re using Password Manager Pro, here are some of the most common ways of enforcing MFA:
- Duo Authentication
- RSA SecurID
- Smart Cards
Again, a demo for this one is going to be the easiest way of demonstrating compliance. This is especially true if the auditor is unfamiliar with Multi-Factor authentication mechanisms.
You may also be required to show proof that all users with access to that system have MFA enforced, as well as any local emergency accounts.
There is some gray area here as if the account doesn’t have access to devices within the ESP, it might not be required to have MFA enforced. This would be useful for emergency maintenance accounts used to troubleshoot the system. Don’t follow this one as if it’s the gospel itself, every auditor and audit team is different and you don’t want to be hit with a potential non-compliance (PNC) for something as simple as this.
Okay, so we’ve covered what CIP standards are and the scope of CIP standards. Now that you’ve got a good understanding of CIP-005, our next session will jump to CIP-007.
- Malicious Code Prevention (Antimalware)
- Security Patch Management
- Logical and Physical Port Security
- Security Event Monitoring (SIEM)
- System Access Control (Account Management, Authentication)