LL_EACMS_Mixed_Trust Authentication_DRAFT

Lesson Learned
CIP Version 5 Transition Program
Mixed Trust Authentication Environments
Version: January 9, 2015
This document is designed to convey lessons learned from NERC’s various CIP version 5 transition activities.
It is not intended to establish new requirements under NERC’s Reliability Standards or to modify the
requirements in any existing reliability standards. Compliance will continue to be determined based on
language in the NERC Reliability Standards as they may be amended from time to time. Implementation of
this lesson learned is not a substitute for compliance with requirements in NERC’s Reliability Standards.
Purpose
The purpose of this Lesson Learned is to provide guidance related to steps entities can take to avoid mixed
trust authentication environments and their associated compliance burdens. A mixed trust authentication
environment refers to an implementation where a BES Cyber System shares an authentication mechanism
with a corporate system. While they are not prohibited by the CIP version 5 Reliability Standards, such
environments could increase an entity’s compliance burden, as discussed below.
Background
In practice, the security levels designed around the BES Cyber Systems are typically greater than what
entities design for their corporate systems. When BES Cyber Systems and corporate systems share an
authentication mechanism, such as Microsoft active directory, the resulting environment is considered to
be a mixed trust environment – i.e. one platform authenticating and/or authorizing for multiple zones
with different security levels.
Nothing in the CIP Reliability Standards prohibits an entity from implementing a mixed trust environment
and using corporate active directory servers to authenticate to an Electronic Security Perimeter or a BES
Cyber Asset. If, however, an entity chooses to use corporate active directory servers to solely perform the
access control function to an ESP or BES Cyber Systems, the servers are, by definition, Electronic Access
Control and Monitoring Systems (EACMS) associated with one or more BES Cyber Systems.
An EACMS is defined in the NERC Glossary of Terms as follow:
3353 Peachtree Road NE
Suite 600, North Tower
Atlanta, GA 30326
404-446-2560 | www.nerc.com
Electronic Access Control or Monitoring Systems (EACMS) – Cyber Assets that perform
electronic access control or electronic access monitoring of the Electronic Security
Perimeter(s) or BES Cyber Systems. This includes Intermediate Systems.
The Background section of Reliability Standard CIP-002-5.1 includes examples of typical EACMS, such as
Electronic Access points, Intermediate Systems, authentication servers (e.g., RADIUS servers, active
directory servers, certificate authorities), security event monitoring systems, and intrusion detection
systems.
All of the following requirements have one or more parts applicable to EACMSs associated with medium
impact or high impact level BES Cyber Systems:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
CIP-003-6 R1 – Security Controls Management
CIP-004-5 R2 – Training requirement for personnel with access to EACMS
CIP-004-5 R3 – Personnel Risk Assessment Procedures
CIP 004-5 R4 – Process to authorize access based on need
CIP 004-5 R5 – Process for Access Revocation
CIP 006-5 R1 – Physical Security Perimeter and associated processes and procedures
CIP 006-5 R2 – Visitor Control Program
CIP 007-5 R1 – Ports and Services
CIP-007-5 R2 – Patch Management Process and Procedures
CIP-007-5 R3 – Anti-malware protections
CIP-007-5 R4 – Logging requirements
CIP-007-5 R5 – Interactive Remote Access requirements and password requirements
CIP-009-5 R1 – Recovery Plan Documentation
CIP-009-5 R2 – Recovery Plan Testing
CIP-009-5 R3 – Recovery Plan Testing
CIP-010-2 R1 – Configuration Baseline
CIP-010-2 R2 – Configuration Baseline monitoring for High Impact BCS associated EACMS
CIP-010-2 R3 – Vulnerability Testing and Assessment Requirements
CIP-011-1 R1 – Protection of CIP classified information
CIP-011-1 R2 – Information dissemination and disposal
Approach
Based on the complexity of ensuring that all of the required protections be applied to EACMS in a mixedtrust environment, one of the participants in NERC’s Implementation Study for the CIP Version 5 Transition
Program decided to create a separate Microsoft active directory forest dedicated to CIP environments. By
taking this approach and avoiding a mixed trust environment, the entity was able to significantly reduce the
compliance burden that would have resulted from inclusion of corporate active directory forest.
The diagram below shows the segmentation of user authentication and the two separate trust
environments. First, the user authenticates to their corporate PC as normal. The user then initiates an
encrypted remote desktop session to the Intermediate System where multi-factor authentication is
enforced. Once the user is authenticated at the Intermediate System, only then is the user permitted to
access the Cyber Assets inside of the ESP.
By taking this approach, the entity was able to leverage existing controls and infrastructure in place to meet
the CIP requirements listed above while reducing the compliance burden on the corporate systems.
Figure 1: Non-mixed Trust Authentication