Patent Application
20120266209
This invention relates generally to methods of secure operations of an electric power grid and, more specifically, to methods of operating an electric power grid using common cyber security services to ensure secure connections from control systems to devices in the electric transmission, electric distribution, and energy centric devices in electric customers' networks.
Common cyber security services have been used in other contexts, but have not been used in conjunction with the operation of an electric power grid.
This invention satisfies the need for common cyber security services to be used in conjunction with the operation of an electric power grid.
This specification defines and allocates the applicable Common Cyber Security Services (CCS) requirements and interface requirements to Edge Security Clients (ESC [aka Clients]) to be deployed throughout the Smart Grid.
The functional interface requirements are defined in terms of Request for Comments (RFCs) and standards that a Client must comply with in order to interoperate with the Central Security Services. It also specifies the functional security requirements that the Client must implement in order to provide security for communications operations between Electric Power System (EPS) Cyber Systems and EPS Cyber System Components.
The Edge Security Client is an EPS Cyber Systems Component (ECSC) capable of providing distributed enforcement of security policy at or near the perimeter of the system.
The physical environment is a key design consideration for Edge Security Client services and requirements which results in multiple classes of devices dependent on environment. The term Edge Security Client and Client are synonymous and are used interchangeably throughout this document.
The following terms used in this document were derived from North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) CIP-010-Cyber Security-BES Cyber System Categorization:
The electrical generation resources, transmission lines, distribution equipment, interconnections with neighboring systems, and associated equipment.
One or more programmable electronic devices (including hardware, software and data) organized for the collection, storage, processing, maintenance, use, sharing, communication, disposition, or display of data; which respond to a EPS condition or disturbance; or enable control and operation.
Application software designed to use EPS Cyber System Components to perform specific tasks for a particular purpose, i.e. Distribution Management System (DMS), Automated Load Control System (ALCS), Wide Area Situational Awareness System (WASAS), Analytics and Visualization (A&V), Common Cybersecurity Services (CCS), etc.
One or more EPS Cyber System Components which if rendered unavailable, degraded, compromised, or misused could, within 15 minutes, cause a disturbance to the EPS, or restrict control and operation of the EPS, or affect situational awareness of the EPS.
A set of one or more EPS Cyber Systems capable of performing one or more of the following functions for multiple (i.e., two or more) EPS generation, distribution, or transmission facilities, at multiple (i.e., two or more) locations:
An EPS Cyber Systems Component (ECSC) capable of providing distributed enforcement of security policy at or near the perimeter of the system; also referred to as the “Client”.
Personality Profile—Defines the physical and cybersecurity Assurance Levels that a “Client” as well as any specific performance, hardware, computer resources, etc. that the Client is required to meet.
The Southern California Edison, (SCE) Smart Grid is essentially a Networked System of Systems (
The smart grid requires a new layer of information technology that dynamically links most all elements of the grid and interconnected devices into a unified network. The creation of such a network enables significant benefits, but also introduces potentially significant cyber-security threats. These EPS Cyber Systems and Components consists of programmable electronic devices (including hardware, software and data) which are dependent upon networked communications to respond to EPS conditions and disturbances and enable control and operation.
This dependency upon networked communications has the potential to create vulnerabilities within the EPS and “SCE recognizes the need to increasingly safeguard the communications and computing systems installed throughout its grid network from cyber-attack.” To tackle the cybersecurity challenge, SCE has developed a Common Cybersecurity Services (CCS) Reference Design which defines the cybersecurity architecture for the CCS necessary to provide the security and integrity for communications and operation of the SCE Smart Grid EPS.
The systems depicted within the “Internal SCE Systems Domain” in
The Common Cybersecurity Services (CCS) is a collection of security controls and mechanisms distributed throughout the Smart Grid Networked System of Systems (
This specification does not attempt to define specific software or hardware requirements because the requirements specified herein may be implemented by a vendor in any number of configurations dependent on the hardware, software, and system environment.
The configurations depicted above are examples of how the flexibility of the client will allow the acquisition and integration of various Client configurations which are dependent on the environment in which they operate.
Conventional hardware can be used to implement this system.
The software implementation intended to support a subset of the capabilities defined in this specification is within the skill of the art. Therefore subsequent updates to this specification will be released.
This specification defines the security requirements for networked field devices required to support the CCS. It is assumed that the networked device will at a minimum support the Assurance Level 1 requirements specified herein.
This specification defines the Control Plane Secure Channel interface (SCI-01) and two of the Data Plane Secure Channel Interfaces (SCI-02, SCI-03) that are required to support secure communications. Additional Secure Channel Interfaces (SCI-04+) are included to support the various power industry standards (i.e., DNP3, IEC 61850, etc.) in procurement specifications.
This specification defines general requirements for the Plaintext Control Plane and Plaintext Data Plane interfaces Plaintext Channel Interfaces (PCI) required to support EPS System Applications.
The following publications listed in Table 0-0 are hereby incorporated by reference in their entirety:
This section specifies the system requirements, that is, those characteristics of the system that are conditions for its acceptance.
The following paragraphs describe the Client States and Modes. The Client States and Modes, shown in Table 3-1, are defined within the context of a device that implements the security services defined in this specification.
The Security Modes are only applicable when the Client is in the Operational Mode.
Before a Client is allowed to operate within the CCS, the Client needs to be securely initialized with the public key and other assured information of the trusted Certificate Authority (CAs), to be used in validating certificate paths (i.e. PKI root CA chain). Furthermore, a Client typically needs to be provisioned with CCS RA contact information.
The events a Client processes and the actions it performs that drive it to different security states and modes are policy driven at deployment time. The policy can change from Client to Client depending on the deployment location and/or application. This section describes an example of one policy.
Table 0-3 specifies the actions that the Client is to take based upon the incoming events “Event ▾” and the Client's current Mode “Mode ”. The actions to be taken are designated by A* in the appropriate Mode column, which provides an index which subsequently calls out specific actions that the Client is to take.
Table 0-4 identifies the incoming events that the Client is expected to respond to according to its current mode.
Table 0-5 identifies the actions that the Client is expected to take based upon its current mode and the incoming events.
The Client shall calculate and communicate a QoT designation for each associated peer Client and for each associated GDOI multicast group. The QoT designations are shown in Table 0-6. The QoT designation is communicated over DDS (QoT Update message) to the CSG and it at the same time it is communicated to locally installed EPS Applications over an IPC channel on the Client Platform. The QoT designations are used by the Client and by installed EPS Applications to determine the security trust level of data received from the remote peer client EPS Application or GDOI multicast group. QoT designation allows the local EPS Application to make real-time decisions to alter EPS management. The QoT designation is also used to inform CCS operators as to the status of the Client. The QoT calculation is policy driven. The policy driven calculation is SCE-defined for each Client or type of Client or group and takes into account the QoT Events identified in Table 0-8.
The events a Client processes and the actions it performs that drive it to different QoT designations for its peer Clients are policy driven at deployment time. The policy can change from Client to Client depending on the deployment location and/or application. This section describes an example of one policy.
The events a Client processes and the actions it performs that drive it to different QoT designations for its peer Clients are policy driven at deployment time. The policy can change from Client to Client depending on the deployment location and/or application. This section describes an example of one policy.
QoT Designations for peer Clients are calculated by a Client according to the Client's configured QoT policy. The doctrine for specific QoT policy can change from Client to Client depending on deployment location and application.
The QoT policy calculation can result in lowered QoT, raised QoT, or even termination of the SA with the peer Client.
All QoT events in the example table below can cause QoT to be re-calculated for a Peer Client.
This section is divided into sub-sections to itemize the requirements associated with each capability of the system.
EPS Cyber System Application traffic flow to and from Clients (commands and data, i.e., control loops) should not be halted or blocked by Clients due to an integrity failure. CCS Clients are designed to boost integrity, trust and non-repudiation of devices participating in EPS Cyber System Applications. Clients use integrity measurement (metrics) to prove their integrity to the Central Security Integrity Measurement Authority (IMA). The integrity evaluation done by the IMA is expressed as a Bill of Health for the Client. The BoH is a signed binary object that is bound to the PKI system and the Clients digital identity. A Client's BoH is a public certificate issued by the IMA and is widely distributed throughout CCS. Peer clients obtain the Client's BoH and make Quality of Trust decisions based directly on the Bill of Health EPS Cyber System Applications that consume data from remote Clients thus obtain security information about their peers on the network. Armed with real-time security knowledge, EPS Cyber System Applications can mark their data with security markings during processing, visualization, and storage and they can take algorithmic steps to survive in the presence of untrusted data or clients.
System Integrity considers the following integrity issues:
The functions of attestation and demonstration have been separated in time so that Clients verify each other's integrity without needing to have real-time access to the IMA.
In the context of the Trusted Network Connect (TNC) Architecture (see
The decision to make this separation was to facilitate centralization of the attestation/verification process. Verifying a device's integrity may require a lot of specialized information, i.e. hashes of bootloaders and kernels, software version numbers, hashes of configuration files, public keys for Hardware Security Modules (HSMs) (e.g. Trusted Platform Monitor (TPM) chips), and so on. The device version and model, from each vendor, will have the Client's own set of verification information and policies. It would be an excessive burden to securely distribute all of this verification information to all Edge devices. Instead, all verification information stays on the central Integrity Measurement Authority, where system administrators can manage it.
In the context of the TNC architecture the Integrity Measurement Collectors (IMCs) and Integrity Measurement Verifiers (IMVs) are complimentary architectural elements that support the Integrity Measurement Authority provided by the CCS.
The IMCs gather integrity measurements and communicate them to IMVs. Software, firmware and hardware components that make up the IMCs on the Client are expected to report status information to the IMV software components that make up the Integrity Measurement Authority which stores these measurements in the Central Security Repository.
In the context of the TNC architecture, the Clients perform the Access Requestor and TNC Client functions while the IMA performs the Policy Decision Point and TNC Server functions. Bill of Health generation by the IMA replaces the Network Access Authority function.
It is envisioned that different types of clients (i.e., Phasor Measurement Units (PMUs)), Phasor Data Concentrators (PDCs), etc.), from different vendors, in different installations, would require different ways to collect integrity related measurements.
SCE requires that for each device design, the vendor will provide the measurements needed by SCE's integrity policy for that device.
Vendors can also provide a custom IMC/IMV to measure their device's integrity in a unique way. In order to accomplish this, the vendor will have to provide a design for the IMC and IMV, as well as enough of the device design that the custom integrity measurement can be understood and evaluated.
Assurance level requirements include required integrity measurements, i.e., ‘Assurance Level 1’ requires implementing at minimum, PTS over IF-M. This IMV is already built into CCS. It is designed to verify the hashes of static files such as executables, libraries, and static configuration files; while ‘Assurance Level 3’ requires trusted boot verification (like TPM) of bootloader, kernel, all configuration files, etc.
Distributed Grid Protection Systems must continue to operate autonomously when central cybersecurity services are unreachable. Clients must prove their integrity to each other without access to a central verification point. Clients must process authorization attributes from each other without access to a central decision point. Expired authentication and authorization credentials and cryptographic keys are retained on Clients and used past the expiration date until Central Security can be reached. In EPS Cyber System Applications availability and integrity is more important than confidentiality.
Community of Interest (COI) network segmentation is an effective technique to contain a security breach to a small area. Clients can provide one or more Electronic Security Perimeter (ESP) access points. Clients may include a firewall with a Deep Packet Inspection (DPI)/Intrusion Detection System (IDS) capability and/or perform as EPS Cyber System Application gateways. Within a network segment Clients can bind application network sockets (or route application traffic) into a SA or onto a Multi-Protocol Label Switching (MPLS) VLAN.
Clients must implement on-device security kernel reference monitors that logically isolate processing according to security policy, such as with VxWorks, SE Linux, VMWare, and others commonly known in the art. The security kernel policy typically groups processing tasks with the same security needs into levels, types, groups, containers, virtual machines, etc. forming logical security perimeters within the device that help to contain security breaches. On-device security perimeters are logically extended via communications path selection (MPLS) and security association (Transport Layer Security (TLS) and IPSec). One of the benefits of extension via cryptography is the opportunity for robust access control and authentication. Logical security perimeters extended via path selection (MPLS) assume that the path is trusted and do not offer authentication or access control.
Clients must detect and report security incidents in a timely manner. That is, within SCE's security incident Observe, Orient, Decide, Act (OODA) loop. This loop is shown in
If the time span of the loop is too large or the attacker goes undetected they can cause damage to the grid before SCE can react.
Technical measures that system designers can take to assist SCE's OODA Loop are mainly techniques to slow down an attacker and give SCE more time to observe a breach:
This capability defines the requirements for filter rules, local credential administration, COI group membership, peer and group security associations, and local inspection management (integrity checking, software checking, and message integrity if non-cryptographic).
Security configuration management uses the NETCONF protocol to configure the Client.
This section defines requirements for Clients to provide local Electronic Security Perimeter and local separation of duties. Boundary enforcement covers the following:
Boundary Enforcement includes both physical and electronic security boundaries for the Clients. The establishment of security boundaries includes specifying mandatory security requirements for components that reside within a given boundary.
Any connection between Client or CSMA security domains and entities outside the security perimeters occurs through managed interfaces (e.g., proxies, gateways, routers, firewalls, guards, encrypted tunnels).
Since substation Gateway functions enforce security policies at multiple enforcement points, it is important that gateway functions can be monitored from the Grid Control Center (GCC) and that their configuration can be controlled from the GCC. All substation gateway configuration settings must be capable of being monitored from a security management function located in the GCC. All substation gateway configuration settings must be capable of being set from a security management function located in the GCC. This includes the ability to download a complete gateway policy configuration in one action.
The CCS supports policy management tools that assure the consistency of security configuration settings (e.g., Security Association Access Control Lists (ACLs)) across multiple substations and across multiple devices within a substation.
1.5.2.3 Audit & Reporting
Local audit support in the Human Machine Interface (HMI) is vendor-specified. Client audit support to Central Security (CS) Security Information and Event Management (SIEM) service is specified in section 1.5.3.9 Audit.
The goals of trusted procurement and provisioning are to increase the assurance that there is no malicious software loaded on the Client and to add the SCE Trust Anchor certificates and Client identity credential and public-private keys in a trusted manner. The Single-use Provisioning Passphrase (SPP) Process consists of: The Client authenticating itself to the CSRA using a Single-use Provisioning Passphrase (SPP). Then the Client obtains a signed identity certificate from CSRA without intervention from utility personnel. The following paragraphs describe the Client planning, procurement and provisioning processes.
The Client vendor (or a 3rd party) provides a formally released:
If the device(s) contain(s) an electronic serial number the device vendor provides a serial number or list of serial numbers to SCE personnel. SCE personnel enter the serial number data into CCS Repository for use in planning and procurement step 3.
Electronic serial numbers are assigned by the device vendor to each device and must never repeat.
In this step SCE engineers:
CCS assigns a Globally Unique Identifier (GUID) and generates an SPP for each device and stores them in the CS Repository.
In this step, SCE engineers assign TCP/IP address information to each device. This is done only if SCE is not using DHCP to provide TCP/IP address information to devices at boot time.
SCE personnel authorize a GUID or list of GUIDs for installation. CCS loads the device information into the CSRA.
SCE engineers generate a provisioning manifest of authorized device serial numbers and SPPs for installation. The file contains several items of data:
SCE follows one of several paths depending on the capabilities of the device:
This section describes the secure mechanisms used to configure Clients over the network.
This section describes the various Client and Central Security components that are involved in the NETCONF configuration process. The secure transport protocols suggested in section 2 of RFC 6241 will not be used. Instead, the messages specified in RFC 6241 section 4 will be sent over two secure authenticated DDS Topics, one that publishes the “client” Remote Procedure Call (RPC) commands from the management station and another that publishes the “server” RPC responses from the Client.
The Client needs provisioning information to attach to the Control Plane DDS before NETCONF over DDS can be used. This includes at a minimum an identity certificate, trust anchors, and the TCP/IP address of the appropriate Control Plane DDS discovery node for the DDS domain.
NETCONF requirements for a “username” will be met by adding a username to the NETCONF DDS messages.
The CSCM is a Central Security Service that performs the functions of the network manager, or “client” specified in RFC 6241. The CSCM will publish XML RPC Command documents conforming to RFC 6241 to the NETCONF RPC Command DDS Topic over the Control Plane Domain. The CSCM will subscribe to RPC responses from Clients on the NETCONF RPC Response DDS topic.
The Client performs the “server” or “device” functions specified in RFC 6241, publishing <rpc-reply> messages in the form of XML documents conforming to Configuration Model specified in RFC 6241 section 5. The Client publishes <rpc-reply> to the NETCONF RPC Response DDS topic and subscribes to <rpc> request messages from CS CM on the NETCONF RPC Command DDS topic. The Client will perform the processing defined in the following table.
NETCONF carries configuration data inside the <config> element that is specific to the Client's data model. The protocol treats the contents of that element as opaque data. The Client uses NETCONF capabilities to announce the set of data models that the Client implements. The capability definition details the operation and constraints imposed by the data model. The capability definition is vendor-specified. Commonly, the YANG (not an acronym) configuration modeling language (RFC 6020) is used and is specified as a preferred configuration language for device configuration using NETCONF.
To meet configuration trusted path requirements all configuration changes sent over NETCONF must be signed by CSCM and the signature verified by the Client before the configuration change is accepted.
It is desirable to extend the 61850 parts 6 and 7 data models to include the security configuration for Clients and then map the extensions and the rest of the 61850 parts 6 and 7 into NETCONF data sets. Currently the Client NETCONF data model covers only Client-specific configured properties.
Client side recovery shall be accomplished using NETCONF locking and recovery behaviors. This behavior is vendor-specified.
This capability defines the Client requirements for Integrity Measurement Collection as defined by the TNC Architecture.
Each Client communicates with a Central Security Integrity Measurement Authority (IMA) to prove its integrity. If the Client can prove its integrity, the IMA will give it a credential (X.509v3 Attribute Certificate) called a Bill of Health (BoH). The IMA publishes the BoH to the DDS on behalf of the Client. Before remote Clients begin communicating with their Client(s), they retrieve the Client's BoH from DDS. Peer Clients use the Client's BoH during QoT policy calculations.
This section describes the various components that are involved in the process of integrity management within the context of the CCS and the TNC architecture.
Integrity measurement means collecting information about the state of a system (i.e. Client), with the goal of determining that its configuration has not been modified from some known-good state. It usually means collecting hashes of configuration elements, and comparing them to expected values stored on the IMA.
There are many aspects of integrity that may be checked, such as:
Some of these integrity measurement methods only make sense during device boot; others may be re-measured continuously or periodically during operation, or when requested by SCE administrators.
In general, the specific mechanisms used to measure integrity are platform-specific and vendor-specific. Client device vendors are expected to analyze their platforms and create software to measure integrity as they deem appropriate. From the CCS standpoint, a Client device's specific integrity measurement scheme will be specified by SCE and the vendor.
Integrity attestation (aka remote attestation) means providing integrity measurements to a trusted central authority, i.e., the IMA.
The protocols for remote integrity attestation include the TNC family of protocols from TCG. TNC is a common set of protocols that lets a client attest its integrity to a server. During one TNC session, many different methods of integrity verification can be run (based on policy). The final integrity decision (“Healthy” or “Unhealthy”) is calculated using a configurable policy decision tree within the IMA.
The following sequence describes the high level attestation process including PTS over IF-M.
The sequence diagram in
A Client automatically begins the integrity attestation process by contacting the Integrity Measurement Authority using IKEv2. The Client and IMA communicate with each other using the TNC protocols within an IKEv2-EAP transaction. One or more IMCs may execute on the client exchanging messages with their counterpart Integrity Measurement Verifiers (IMVs) on the server.
The server side can optionally initiate further exchanges where more information is exchanged. Extra exchanges, if needed, are vendor-specified. Once an IMV has collected the required measurements, it will make action recommendations to the IMA. If the IMA does not receive all of the required measurements or receives invalid measurements, a negative decision is made.
Upon successful or unsuccessful integrity attestation, the IMA will generate the Client's Bill of Health (healthy or unhealthy), which is a credential proving this Client's integrity has been checked. See Section 1.5.3.2 for more about Bills of Health.
The IMA/TNC Server publishes the Bill of Health through DDS.
Different client implementations, from different vendors, in different installations, at different security levels, may have different measurement policies. The number, type, and implementation of measurement collectors are vendor-specified.
The integrity policy for a Client device is dependent upon the security capabilities it provides and the vendor therefore will need to define an integrity policy and the set of measurements that will execute on their Client device. Each device must provide the measurements required by the IMA integrity policy for that device.
Client vendors will supply SCE with vendor-specified integrity data that is needed by the IMA. i.e. hash databases. These are loaded into the IMA repository prior to Client deployment.
The Bill of Health is an X.509v3 Attribute Certificate. It is constructed differently from typical public key certificates in that it contains no public key and has a “holder” field specifying a Public Key Certificate (PKC). Additionally, it contains an attribute that indicates “Healthy” or “Unhealthy”.
The AC itself specifies the Bill of Health's validity period and an attribute that indicates the health status (Healthy or Unhealthy).
The BoH ACs are published to DDS by the IMA.
The mechanism chosen to bind the Bill of Health AC to the Client's identity is discussed in section 1.5.3.3 PKI Credential Management.
The following paragraphs describe the PKI architecture that will be deployed to support PKI material distribution and credential management. The terminology used in this specification is consistent with the RFCs related to PKI.
The following paragraphs describe the components of the PKI that will be provided by the CCS.
Submissions for certificate enrollment and renewal will happen between the Clients and the RA. For revocation operations, authorized SCE personnel will use the RA directly to begin the revocation process. Authorized SCE personnel also initiates a zeroize operation of the Client in the event of a compromise. The zeroize operation initiates deletion of keys and certificates associated entity credentials that have been revoked.
Certificate Profiles define the various X.509v3 certificates and constructs used within the context of the CSS PKI. The field names and attributes referenced are defined in RFC 5280 for public-key certificates and RFC 5755 for attribute certificates.
This section covers the certificate enrollment protocol that enables Clients to request certificates from certificate authorities. The protocol provides an interface to the public key certification products and services based on Cryptographic Message Syntax (CMS) and Public Key Cryptography Standards (PKCS) #10.
The protocol is request and response based. Client End Entities will generate a new public and private key and then send a Request Cert Message in PKCS#10 to the Certificate Authority, and the Certificate Authority will send the response message. In this particular PKI, Clients will need to send their requests through Registration Authorities. The CMC protocol will use HTTPS/TLS to transport protocol messages.
The certificate renewal follows the enrollment process defined in RFC 5272.
For this design, PKCS#10 Certification will be used in the PKIData portion. The process by which a certification request is constructed involves the following steps:
In the case a Client's key or certificate is compromised, the administrator will need to be able to request that the Client's certificate be revoked. The request goes to the RA, which interacts with CA to perform revocation, generate a new CRL, and push it to OCSP responder. The Client's certificate will be maintained in a certificate revocation list by the Certificate Authority.
The OCSP enables applications to determine the revocation state of an identified certificate. OCSP is used to satisfy some of the operational requirements of providing more timely revocation information than is possible with CRLs and is used to obtain additional status information. An OCSP Client issues a status request to an OCSP responder and suspends acceptance of the certificate in question until the responder provides a response.
An End Entity (Client) verifies the binding between a subject distinguished name and a subject public key, as represented in the end entity certificate, based on the public key of the trust anchor. The path validation process follows RFC 5280.
The basic validation approach for an AC verifier is as follows:
The AA signing certificate will exist as a Trust Anchor in the AC verifier's trust anchor store. This kind of certificate doesn't fall strictly into an identity or management TA type, but fits closer to the intent of an identity TA.
In the case where both public key certificates and ACs are fully validated there will be 7 2048-bit RSA public key operations, along with the overhead of other cert validation processes at each step during path validation.
The following subsections contain sequence diagrams show the interaction between End Entities, the RA and CA for enrollment, reissuance, and revocation actions.
For certificate enrollment, an SCE technician activates a vendor-defined process on a Client to begin the enrollment process. The Client generates an RSA key pair and crafts a certificate request (e.g., PKCS#10). The request message is then sent to the RA, where the PKCS#10 message is validated according to established policies (proper key type and length, correct key components, proper naming structure, correct Client ID, etc.). Once validated, it passes the request on to the CA for certificate issuance. Once issued, the certificate is returned to the RA so it may be picked up by the Client. A status response is sent back to the CS informing it of the successful issuance. At that point the CS can send a command to the Client telling it to pick up the certificate. Once contacted, the RA returns the certificate to the Client. The sequence diagram in
Certificate renewal will occur within a predetermined time period prior to the expiration of the current certificate held by the End Entity. Renewal will involve the generation of a new key pair, but the still-valid credentials must not be overwritten. The request message for renewal must be signed with the old key to provide a binding between the old, still trusted identity and the new key and certificate request. The sequence diagram in
Certificate revocation occurs in response to key compromise or in situations where the identity of the Client or person needs to change. Certificate revocation is an exchange between SCE Personnel and the RA, which would forward the revocation request to the CA after validating it. In addition, a new CRL will be generated and provided to the RA. Also the OCSP Responder's CRL will be updated so it has the latest view of revocation status from the CA.
This section covers the CCS Public Key Infrastructure (PKI) services and the Trust Anchor Management Protocol (TAMP) design and the TAM protocol.
A PKI is the most common authentication approach for obtaining a variety of assurances: assurance of integrity, assurance of domain parameter validity, assurance of public key validity, and assurance of private key possession. In a PKI, the infrastructure establishes the entity's identity and the required assurances to provide a strong foundation for security services in PKI-enabled applications and protocols, including IPsec and Transport Layer Security (TLS). The assurances are signed by trusted 3rd party credentials that are loaded into all security system participants, called TAs. Trust Anchor credentials are also managed objects.
The protocol manages trust anchors in any Client that uses digital signatures. A TA is an authoritative entity represented by a public key with associated information. Trust Anchors are used for certification path validation and verification of signed objects like firmware, timestamps, OCSP responses and keys. Trust anchors are maintained in trust anchor stores, which are sets of one or more trust anchors.
1. Apex Trust Anchor
2. Management Trust Anchor
3. Identity Trust Anchor
TAMP recognizes three formats for representing trust anchor information: Certificate [RFC5280], TBSCertificate [RFC5280], and TrustAnchorinfo [RFC5914], which are described in the following paragraphs. However the CCS PKI only use the Certificate format.
The TAMP messages are presented here for reference purposes.
All TAMP messages will be communicated over DDS using Datagram TLS (DTLS). A vendor-specified function will wait for a DDS message or for a command from the CS CM. Once a TAMP message or command is received, it is determined to be a valid TAMP message by verifying the signature and verifying the certificate chain.
When the Clients process the message, the response is then published to the TAUpdateConfirm DDS Topic and the CSG is the only subscriber to the TAUpdateConfirm topic. As each Client responds, the CSG updates the Client status in the GUI.
Certificates from the old and new trust anchors will be differentiated by a numeric designation (1) for the original and (2) for the new.
The original trust anchor would be SubCA(1) and the new one SubCA(2). The EE certs: EE(1) for original, EE(2) for new, and so forth.
The sequence diagram in
The following text describes the Rollover Process Sequence.
The sequence diagram in
Certificates from the old and new trust anchors will be differentiated by a numeric designation (1) for the original and (2) for the new.
The following text describes Updating Trust Anchors on Online Client Process Sequence.
The sequence diagram in
The following text describes Updating Trust Anchors on Offline Client Process Sequence.
IKEv2 (RFC 5996) has been chosen for authentication and authorization between two Clients. This section describes how IKEv2 is tailored to satisfy the cryptographic enforcement requirements for a Client.
The IKEv2 Child SAs are used to exchange operational data between Clients. In the case where a group of Clients exchange data over multicast SAs and are keyed by the Group Key Distribution Center (GKDC) using the Group Domain of Interpretation (GDOI) protocol, IKEv2 will still be used for authentication and authorization but GDOI will be used to supply Clients with the pre-placed keys to encrypt/decrypt data sent/received over multicast SAs.
RFC 5996 describes the normal IKEv2 protocol with Child SA creation. RFC 6023 describes a “Childless” version of the protocol where IKEv2 is used only for authentication purposes. CCS Clients shall support the childless IKEv2 mechanism. The Peer Authentication decision, peer authorization decision, and QoT calculation are performed during the Childless IKE process. This establishes Security Associations with peer Clients. At a later point in time a separate process for Child SA creation is performed. During Child SA creation an authorization decision is made based on QoT policy, and then a tunnel/transport decision is made based on configuration.
The sequence diagram in
In some cases, the Child SA created at the end of an IKEv2 exchange is not needed as another type of SA must be created for operational traffic (e.g. see 1.5.3.7 Group Multicast Communications with GDOI). In this case, the messages don't include the SA payload or traffic selector payloads which are only needed for Child SA creation. The IKEv2 Responder:Client sends a CHILDLESS_IKEV2_SUPPORTED notification payload in the IKE_SA_INIT response to indicate a Child SA won't be created. The IKEv2 Initiator:Client then knows not to send the SA and TS payloads used for Child SA creation.
The sequence diagram in
Additional verification is policy-driven, as not all Clients will support Bill of Health attestation. Bill of Health Attribute Certificates are published over DDS as they are generated. During IKE v2 setup the ACs from each peer in the SA are retrieved from DDS by the opposite peer and validated according to policy.
OCSP is used to obtain the revocation status of an X.509 digital certificate. The OCSP response is an ASN.1 encoded message that contains the revocation status of the requested certificate. The OCSP response will be used to check the revocation status of the Identity certificate.
The first option is for each CCC to request their peers OCSP response from the OCSP responder during the IKEv2 SA negotiation.
The second option is to use OCSP stapling (i.e. in-band exchange in the IKEv2 CERT payload). This option has the benefit of not having to perform a timely exchange with the OCSP responder each time a security association is established.
In order to send the OCSP responses in band each CCC must retrieve their own OCSP response from the OCSP responder at an earlier time. The CCC will check for the existence of its valid OCSP response during boot up and if it is not found the CCC will request it from the OCSP responder.
IKEv2 allows CRLs to be exchanged in-band via the CERT payload. This is the traditional means of determining revocation status. However these lists can get very large. So OCSP will be used instead. OCSP is used for in-band signaling of certificate revocation status within the IKEv2 exchange. OCSP responses are bounded and small. CERTREQ and CERT payloads contain the OCSP content.
To mitigate the risk of the OCSP Authority being inaccessible by the Client at time of connection, Clients can retrieve OCSP assertions for all configured peers (1) at boot-up, (2) when a new peer is configured, (3) when connectivity to the OCSP Authority is restored, and (4) periodically as the OCSP assertions are about to expire.
OCSP Stapling is then used for checking the revocation of X.509v3 digital certificates as described in RFC 4366 section 3.6
The IKE standard provides a great deal of leeway in defining the security policy for a trusted peer's identity, credentials, and the correlation between them, and cryptographic policy such as SA rekey. Having such security policy defined explicitly for CCS is essential to a secure implementation of IKE and IPsec. The following paragraphs describe the extensions to the standard IKEv2 in order to support CCS policy for availability, authorization.
Clients are configured by CCS with a list of authorized peers for SA establishment. Any time a Client receives an IKE initiation and before a Client initiates IKE itself, it must verify the GUID of the intended peer is in its Authorized Peer SA list. This list is pre-calculated for each Client by CCS from role and group information CCS knows about all Clients. The list must persist in the Clients configuration until it is changed by CCS.
Rekeying of SAs should be seamlessly done in the background and not affect the data channels. Latency and jitter should be mitigated. If rekeying fails, traffic over the Child SA must not stop. The old keys must continue to be used but the data processed will be marked with a lower quality of trust. This is a deviation from the specified IKEv2 protocol which will tear down the child SA if keys expired and cannot be renewed. This is a deviation from the specified IKEv2 protocol which will tear down the child SA if keys expired and cannot be renewed.
In a standard IKEv2 implementation, the expiration of the credentials used to establish an SA would require that the connection be closed and the SA re-established. However due to the priority of availability if credentials expire, it may be required (dependent upon policy) that SAs remain established anyway but the EPS Cyber System Applications are informed and use the data that is of a lower quality of trust in accordance with the policy defined by the EPS Cyber System Applications themselves.
A connection between Clients may be initiated in one of three ways:
An existing SA with a Peer Client may be disconnected in one of three ways:
The following paragraphs provide further details regarding the connection and disconnection scenarios.
An administrative user can command SA establishment between two Clients by publishing to the Client IKEv2 Authenticate Command DDS Topic to command an IKEv2 Childless authentication exchange. Then to create the child SA connection for exchanging secure operational data, the user can publish to the SA Connect Command DDS Topic. It is within the IKEv2 specification to be able to combine the authentication and child SA creation exchange into one exchange and this shall be supported in the boot-up scenario described later in this section. However here it is described as two different commands initiating two separate exchanges because while the IKEv2 authentication is required between two Client's before they can exchange data, the exact method of child SA creation may differ depending on the type of devices the Client software is residing on and what type of data may be exchanged. For example, multicast groups of Clients (e.g., a PMU and one or more PDCs) will use the GDOI protocol for creating child SAs.
The sequence diagram in
When a Client boots up, it reads its Community Of Interest (COI) configuration file contains the list of peers that the Client should automatically initiate an IKEv2 authentication and establish a child SAs with. The configuration file will specify what type of child SA creation should take place (e.g. IKEv2 child SA, GDOI).
The sequence diagram in
An administrative user can command two Clients to disconnect via the DDS interface by publishing to the SA Connection Command DDS Topic. The sequence diagram in
The sequence diagram in
This section describes the trust information exchanged within the Common Cybersecurity Service network referred to as the QoT capability. It contains important design decisions, a high level design overview, and some low level design details.
It is important that the Client software and Common Cybersecurity Service network not inhibit the transfer of critical data necessary for proper EPS operation. During a cyber-attack or cyber disaster the security of CCS Clients in certain locations may be lowered, which inversely raises the risk to EPS. In certain cases, Clients under direct attack, may not be able to connect to Central Security Services or Attribute Authorities for extended periods of time and their identity, integrity, and authorization credentials may expire. Also external security alerts may occur that need to be automatically handled by CCS Clients.
In these specific situations, instead of disallowing connections and data transfer between Clients, it is more desirable to allow the connection to be maintained even with the expired credentials or during an undesirable security event. In these cases, the EPS Cyber Systems Application must label (or “tag”) the data with a lower level of trust so that grid protection applications subscribing to that data will be able to incorporate the less trusted data appropriately. This section describes scenarios where QoT changes should be communicated, how QoT changes are communicated, and the associated security notifications regarding QoT changes.
It is important, however, that real cyber-attacks are properly identified and handled in a manner preventing unauthorized access to data. Thus it is necessary to resolve security events in a timely manner regardless of the presence of the QoT capability.
This section provides an overview of the QoT scenarios when data should be labeled, how data will be labeled, and the messages that are exchanged when data needs to be labeled.
The SCE Wide Area Situational Awareness (WASAS) Design System Design Document section 3.6.2.3 describes the levels of trust that should be used to label trust:
Quality of Trust (QoT) of data is defined in terms of these levels. If the EPS Cyber System Application doesn't have an associated QoT with one of the methods described in this document, it shall be assumed to be trusted. The EPS Cyber System Application will mark data at QoT levels according to the security policy of the Client.
The default policy of the Client will be to communicate QoT as questionable if the peer Client can still be authenticated/authorized but is using an expired key. Any expiration/revocation of credentials or tamper events will cause the peer Client QoT to be communicated as untrusted.
Labeling each data packet could be difficult to implement since all possible types of data that could be transferred in the future cannot be predicted. Thus it is more practical to mark Peer Clients with QoT values. The EPS Cyber System Applications receiving data from those Peer Clients or from hosts/applications behind those Peer Clients, are notified of the level of trust and can mark the data in storage and/or mark data packets within the constraints of their own protocols. This essentially leaves the handling of marked data up to EPS Cyber System Applications. Peer Client QoT changes are communicated up to the EPS Cyber System Applications on the Local Client.
The method of communication between the Client Software and EPS Cyber System Applications on a Client is vendor implementation specific. EPS Cyber System Application(s) needs to be notified of a peer QoT change. The Client software need only publish the information about the peer Client needed for an on-board EPS Cyber System Application to recognize that QoT changed on its data channel and the EPS Cyber System Application can mark its own data and modify its data handling algorithms appropriately.
EPS Cyber System Applications must implement a way to mark messages in a manner that the relevant applications listening on the other end can process the information.
QoT scenarios are policy-driven and defined by SCE at device deployment time.
The following is an example:
The QoT of a Client is lowered in accordance with policy. If the Client doesn't have connectivity to the CCS RA at the time of certificate expiration, it must still maintain communication with its peers but they will designate a lower QoT in accordance with policy. Also new connections with new peers are allowed but the peers will also designate a lower QoT in accordance with policy. The client should detect it is using an expired identity certificate and lower its own QoT in accordance with policy. If any other credential verification fails, the SAs with peers may be terminated/disallowed in accordance with policy.
The end result is that EPS Cyber System Applications on the client and on peer clients will be notified of the lowered QoT. The CCS administrators will be informed through QoT alerts that the Client and its peers have all lowered QoT because of the expired identity certificate.
The sequence below illustrates IKE authentication with another Client when the credentials of the Client are expired. Credentials of Client are expired upon IKE authentication with another Client:
IKE authentication with expired credentials may happen when two Clients (Client A and Client B) have already established a secure connection and the credentials on one Client (Client B) expire. In this case, Client A must know of Client B's lower QoT and notify the appropriate EPS applications. Client A can't trust Client B to notify it of the lower QoT. So Client A must detect the expired credentials on its own. When the original IKEv2 authentication exchange happens, Clients must store the credentials of their peer and detect when those credentials expire.
When a device is physically tampered and it has the ability to detect it, it must send a QoT Alert out to DDS.
The sequence below illustrates the process for changing QoT after tamper detection.
Each Client has the following responsibilities:
QoT is primarily associated with a particular Client rather than a data packet. Any data being sent from or through a Client is considered to have the same QoT as that of the sending Client. The Client receiving data is responsible for maintaining a list of QoT values of its peers and notifying resident EPS Cyber System Applications of the QoT of the peer Clients.
The Internet Security Association and Key Management Protocol (ISAKMP), GDOI, Logical Key Hierarchy (LKH) and IKEv1 standards are required and the design decisions derived from each are discussed below. The IEC 61850-90-5 specification is also required and its use of the Group Domain of Interpretation (GDOI) protocol is also analyzed.
In the near term, Group keying is used to protect the transmission of synchrophasor information according to IEC 61850-90-5 from senders to receivers. In this system the senders are Phasor Measurement Units (PMUs) and the receivers can be any interested group member (e.g. Phasor Data Concentrators (PDCs), data historians, relay supervisor, etc.).
The Group Key Distribution Center (GKDC) is the group manager and controls the following functions:
In this system there is one GKDC (not counting redundant locations).
When an IED integrated with Edge Security Services is in the “Trusted” mode (see paragraph 1.4.2) it is able to establish an IKEv2 SA with the Integrity Management Authority (IMA). Key exchange, authentication, identification, integrity, and permissions are negotiated during this SA establishment. This SA must be in place to proceed with group key management. See section 1.5.3.5 Cryptographic Enforcement with IKE.
A group is created when the first Client requests membership from the GKDC. This Client may be the PMU data sender or it may be a PMU data receiver. Both the Client and the GKDC will establish SAs with each other using IKEv1 (chosen to meet the IEC 61850-90-5 specification).
Group identifiers, multicast IP addresses, memberships and permissions are all preplanned. Note that support may be needed for Internet Group Management Protocol (IGMP3) for initiating multicast routing infrastructure support when multicast groups are started. Support for IGMP, GRE Tunnels, MPLS, and other infrastructure protocols in support of multicast is vendor specified
The diagram in
Each PMU that sends data will cause the creation of a new group. Thus for each sending PMU there exists a corresponding preplanned group. A Client may be a member of multiple groups (e.g. sending to one group, receiving on several others).
Once the Parent SA is established, two additional IKEv1 Phase 2 SAs will be established using the GDOI protocol. The first GDOI SA is for the protection of key/re-key data. This is a two-way SA between the Client and the Group Key Distribution Center (GKDC) that is used for GROUPKEY-PUSH/GROUPKEY-PULL GDOI messages. The second GDOI SA is for protection of group data. This is a one-way SA established by the Client with the multicast group.
The diagram in
The following diagrams show how the group key management documentation relates to each other.
As per IEC 61850-90-5 section 10.1.1.2.3.3 (Table 0-10):
The terms “approved”, “acceptable”, “deprecated”, “restricted” and “legacy-use” are used throughout this recommendation and are defined as follows:
As per IEC 61850-90-5 section 10.1.1.2.5:
The allowed HMAC functions are: HMAC-SHA1, HMAC-MD5, HMAC-SHA256, and HMAC-SHA3.
Additionally, the calculated HMAC value may be truncated, per RFC 2104 (HMAC). The allowed truncations are 80, 128, and 256 bits.
Therefore, the HMAC enumerated values, used in the Security Algorithm field shall be as defined in Table 0-11.
As per NIST SP 800-131A section 10 (Table 0-12):
Table 0-13 identifies the Signature Hash Algorithms for IEC 61850-90-5.
As per NIST SP 800-131A section 9 (Table 0-14):
GDOI is an ISAKMP Domain of Interpretation (DOI) for group key management to support secure group communications. GDOI is a group security association (SA) management protocol. All GDOI messages are used to create, maintain, or delete SAs for a group.
GDOI is defined as a Phase 2 protocol (i.e. an exchange on top of a Phase 1 SA) and must be protected by a Phase 1 SA. This Phase 1 protocol must provide for the following protection: peer authentication, confidentiality, message integrity. In the SCE smart grid system the Phase 1 SA will be formed using IKEv1.
This section describes the design decisions that were made based upon the RFC 3547 (GDOI).
GDOI extends ISAKMP with six new payloads (Table 0-15):
GDOI extends ISAKMP with two new exchanges:
The GDOI SA, SAK, SAT and KD payloads must be supported. The SEQ payload is required if we want to support the GROUPKEY-PUSH exchange. The POP payload is required if we want to support authentication through the use of public key cryptography.
Several items related to the GROUPKEY-PULL exchange are discussed in following paragraphs.
RFC 3547 (GDOI) section 3.1 states:
As there is currently no need for a separate Phase 2 identity, this system will use the first option. The initial IKEv2 Parent SA has an established quality of trust associated with it. This established identity will be used with the GDOI Phase 1 IKEv1 SA.
IEC 61850-90-5 section 7.2 states:
This implies that the GROUPKEY-PUSH exchange is not required. However, in order to use a hierarchical tree approach the GROUPKEY-PUSH exchange must be supported. Therefore in our system we will provide support for GROUPKEY-PUSH in anticipation of this being included in a later version of 61850-90-5.
The sequence diagram (
Table 0-15 is a key to the sequence in
RFC 3547 (GDOI) section 3.2 states:
RFC 3547 (GDOI) section 3.2.1 states:
If Perfect Forward Secrecy (PFS) is desired and the optional KE payload is used in the exchange, then both sides compute a DH secret and use it to protect the new keying material contained in KD.
PFS refers to the notion that compromise of a single key will permit access to only data protected by a single key. For PFS to exist the key used to protect transmission of data must not be used to derive any additional keys. IKEv1 can provide PFS for both keys and identities.
RFC 2409 (IKEv1) section 8 states:
RFC 3547 (GDOI) section 4.1 discusses PFS by using the GROUPKEY-PUSH message: The GROUPKEY-PUSH message is protected by the group KEK though in all cases, the GROUPKEY-PUSH message carries new key downloads, among other information. A freshly generated secret must protect the key download for the GROUPKEY-PUSH message to have PFS.
RFC 3547 (GDOI) section 3.3 states:
Group identification and Phase 1 policy will be contained in configuration files. These configuration files will be placed during provisioning or under carefully controlled conditions (i.e. re-provision).
Several items related to the GROUPKEY-PUSH exchange are discussed below.
The
RFC 3547 (GDOI) section 4.2 states:
Forward and backward access control can be supported by LKH. RFC 3547 (GDOI) section 4.2.1 discusses how forward access control may be obtained through the use of a combination of GROUPKEY-PUSH messages. Backward access control is accomplished by re-key upon a group join. Forward access control is a requirement.
Delegation of key management is not supported in this system. If connectivity to the GKDC is lost, new key members will not be able to join and existing members must keep using the same key regardless of its expiration status.
The SA payload is always followed by additional payloads that define specific security association attributes for the KEKs and/or TEKs. There may be zero or one SAK Payloads, and zero or more SAT Payloads, where either one SAK or SAT payload must be present. The maximum number of SAK/SAT payloads that may follow an SA payload is one of each.
The last field in the SAT payload is called “TEK Protocol-Specific Payload”. RFC 3547 (GDOI) section 5.4.1 defines a payload for use in this field called PROTO_IPSEC_ESP. This payload will be used for data transfer.
RFC 35447 (GDOI) section 5.5.3.1 describes the format of a LKH key payload. This payload contains two time related fields labeled “Key Creation Date” and “Key Expiration Date”. They are described as follows:
In this system a time value of zero is not valid for either of these fields.
LKH is an NSA developed protocol for the management of group keys. LKH focuses on solving two main areas of concern with respect to key management; initializing the multicast group with a common net key and rekeying the multicast group. LKH balances the costs of time, storage and number of required messages for rekey.
RFC 3547 (GDOI) was written with LKH in mind for the group key management. It is referenced in several places and there is a LKH download type for the key download payload. The LKH download type is further dived into several subtypes that allow the group key manager to:
This LKH oriented built in functionality allows a GDOI/LKH implementation to:
The storage requirement for each user and the transmissions required for key replacement are both logarithmic in the number of users, with no background transmissions required.
GDOI defines support for LKH; however IEC 61850-90-5 currently does not. The need to support legacy devices that do not support LKH is vendor-specified.
In the event that a legacy IEC 61850-90-5 compliant device is present, LKH will not be used. Instead a flat group structure will be in place. If a group member leaves data loss may occur during group tear down and re-establishment.
This section describes the design decisions that were made.
We must take into account the case where PMUs may have vastly differing processing power. By issuing key updates a specific amount of time before the key expiration date of the current key we can minimize risk of data loss during key rollover.
GROUPKEY-PUSH re-key messages will be sent out by the GKDC no later than 48 hours before the key expiration date.
In the scenario where a single group member fails to re-key that group member shall attempt to rejoin the group.
The Phase 1 ISAKMP SA is established using main mode, as aggressive mode does not support identity protection. The Phase 2 GDOI re-key and data protection SAs is established using the exchanges defined in RFC 3547 (GDOI).
Note that GROUPKEY-PUSH messages use the previously established Phase 2 GDOI re-key SA.
When an SA has only a bit of lifetime left, the Client will initiate the creation of a new SA. This applies to ISAKMP and GDOI SAs.
The Client will not rekey an SA if that SA is not the most recent of its type (GDOI or ISAKMP) for its connection. This avoids creating redundant SAs.
The PMU data packet size is 110 bytes as per section 5.5.2 of the WASAS System Design Document. The desired future reporting frequency is 120 times per second. Therefore the number of bytes per second is:
110*120=13,200 bytes per second
13,200/16[128 bits]=825 blocks per second
Table 0-18 provides a list of overflow values dependent on the size of the counter bits.
The following sections describe several group key management related use cases.
This section describes the process of adding a new group member.
The following DDS Topics are involved in the PMU Multicast Group Member Add process:
Note that the group is created when the first PMU requests to join the group.
The diagram in
This section describes the process of evicting a group member.
The following DDS Topics are involved in the PMU Multicast Group Eviction process:
The diagram in
The Control Plane communications between Central Security Services and the Clients in the field all take place over Data Distribution Service (DDS). DDS is an Object Management Group (OMG) standard. The Client uses DDS to communicate status information to the Central Security Services and receive control commands from Central Security Services.
The Control Plane Data Distribution Service is responsible for the following types of information referred to as Topics (Table 0-19).
DDS is a collection of technologies and conventions used to create a data-centric publish/subscribe global data system. The data systems are encapsulated in a domain. The domain can contain any number of participants, readers, writers, topics, and data types. Collections of a type of data are called Topics. The domain participant can instantiate readers and writers to interact with topics. Readers can distribute quality of service needs to enforce latency and filtering based on data properties. Data in DDS, often referred to as a sample, is represented by a pair of identifiers, (key, instance). The key designates a source of data, for example, a particular Client. The instance designates the unique sample.
The DDS protocol specifies both API and data interchange wire protocol. The API supports programming languages such as C, C++, and Java. The wire protocol is a collection of both the Real-Time Publish Subscribe protocol (RTPS) and the Common Data Representation (CDR) standard. RTPS allows for a variety of transports. UDP is currently the only standardized transport. DDS middleware vendors support shared memory, TCP, as well as proprietary hardware based transports. The transport mechanism is used to enable both participant discovery and data exchange. The DDS standard specifies built-in readers and writers used to publicize presence and available data. The built-in entities can be overridden to modify the discovery feature.
Application programmers interact with the global data system using a local cache. Data samples are placed in or appear in the cache, each associated with either a publisher or a subscriber. The cache is strongly typed and enforced by DDS. Data types can be arbitrarily complex using the following: structures, unions, enumerables, strings, sized numbers among others. The CDR format takes care that endianness is translated across platforms.
Once a sample is placed in the cache the data is distributed per the quality of service settings—from the writers perspective there is no guarantee that data is immediately sent to readers. The readers can read from their cache using arbitrarily complex SQL queries to filter out unwanted messages. Depending on the middleware implementation, these filters can be distributed to writers. This improves the efficiency of the system by only sending requested data to readers.
The ability to delete data is a fundamental discriminator in DDS vs. all other architectures. Other architectures are treated as conduits for data, whereas DDS is a data space.
DDS is not a message-oriented architecture. Message-oriented architectures route data from publisher to subscriber by using header information through any number of brokers. The data of the messages is opaque and ignored by the messaging architecture. Examples of such systems are the Java Messaging System (JMS) and the Advanced Message Queuing Protocol (AMQP). Because brokers are required to pass messages between participants they become a single point of failure. There is no concept of data filtering at the middleware layer—all filtering must be performed by applications.
A DDS domain is segmented to allow strict separation of domain participants. The domain scheme maps a positive integer identifier to a UDP port range. Two different domain IDs will never overlap unless they vary in port determination schemes. The domains will never exchange end-point information because those discovery points will be different.
Over the life of the system we will see the evolution of data types to support new functionality or modifications to existing functionality. To support this operation we will look to version the data at the system level. A domain, in its entirety, will be limited to using strict representations of pre-determined data. Essentially, the Interface Definition Language (IDL) derived for meeting the functional requirements of CCS will become the data standard.
Compatibility of data will be managed at an operations level. Devices with newer capabilities will be added to a new, unused domain, which can operate transparently and safely in parallel to an existing domain. CCS will contain functional bridges between domains—allowing operators to migrate as necessary. This design decision will greatly simplify Client design as all data is assumed to be strict, valid, and operational under the pre-determined semantics.
The DDS standard provides data durability and timeliness settings. The durability settings control how long data remain in the cache and the semantics for sending data to late-joiners. The timeliness settings control how often data will be sent to participants. These settings can be set programmatically by the API programmer, or as a better practice, they can be loaded from XML files outside of any executable. The QoS settings give control to the system operators by giving fine-grained control to the DDS semantics independently from the Client logic.
The DDS API provides a suite of callbacks for handling QoS failure situations. The Client must provide callbacks to handle the arrival of new participants, QoS mismatches, and latency contract failures, among others. Please refer to the OMG DDS documentation for a full list of life-cycle support.
The Client Identity Certificate is used to authenticate IPSec transport mode security associations. Authentication is bi-directional, so a Client must be provisioned with a valid signed identity certificate, private key, and valid trust anchors before it can participate on the DDS (Interface SCI-02). Publish authorization is handled at a higher layer as specified in the next section.
Certain DDS topics are signed by the publisher. The Client should check that the identities of publishers of signed topics either 1) match the identity given in the topic data (ex: a Client publishes a tamper alert about itself) or that the identity appears in a configuration file list of authorized publishers for that topic.
The following paragraphs define the requirements for generation and delivery of events, alarms, and time stamps; generation of security audit records, and protection of security audit records.
The system requirements are briefly presented, the Syslog standard is used over the DDS protocol for the overall logging system.
The Security Information Event Management (SIEM) system is used to track all events regarding the participants of the CCS network. All sessions are logged while more severe alerts will generate audits. These logs and audits will be persisted using the standard Syslog format. In this system, each Client is a sender and the SIEM is a receiver of logging information. The DDS protocol will be used to transport all logs and audits.
The logs will be transported on a low priority DDS Topic while the alerts and audits will be transported on a high priority DDS topic. The higher priority of alerts and audits will be enforced through strong QoS settings for latency guarantees and higher durability.
All required Client and CCS operational activity, alert information, and audit logs will be recorded by SIEM. Two DDS topics will be created, hereafter referred to as LOG and ALERT. The LOG topic will be used only for activity logs; the ALERT topic will be used only for alert data. Readers on either the ALERT or the LOG topic may utilize content filters to receive only desired information.
A Client would be concerned with monitoring its own internal software components and logging them to a DDS Publisher on the Client. This DDS implementation is vendor specified.
Log data contains the following information:
Several functions within a Client can generate audit messages and alerts may also generate audits. When an alert is sent out over DDS, an audit appears in the Syslog trail so it actually appears in both the LOG and ALERT DDS topic, just more quickly in the ALERT.
In
The Client will forward logs and alerts from devices. A local user interface may also be present depending on the deployment. The Client user interface will also generate log data and alerts for all local interactions, including operator log in and all state transitions, as well as Client status.
Table 0-20 shows the log levels that will be supported.
The system is able to use more of DDS's QoS options to help detect failure with both Syslog-NG messages and alerts:
Not all of the Edge devices will be able to reserve enough space for their own local interface. For these devices the user interface is separate from the actual. Given these circumstances, the Client user interface will act as a Syslog-NG host similarly to the CSG to collect log information from the device. Such devices include physical security alarm systems, weather systems, and power and cooling (HVAC or Heating, Ventilation, and Air Cooling). At the vendor's discretion the Client user interface will receive the logs by listening on UDP port 514 for incoming information.
By appending the above option in our Syslog-NG configuration file, the CSG will be able to display the date, host name, program name, facility label, logging level/priority, and the message itself using Syslog-NG's environment variables. With the exception of MSG, these variables are all automatically set by the Syslog-NG connection every time a log message is received from the pipe.
Since Syslog-NG uses UNIX time which does not count leap seconds, we may need to derive our timestamps from the Client applications instead of from UNIX.
The Client will use Common Event Expression (CEE) to specify the fields of the message.
The identification of each external interface includes a project unique identifier and designates the interfacing entities (systems, configuration items, users, etc.).
This specification defines three levels of assurance (Assurance Levels 1 to 3), Level 1 is the lowest level assurance and Level 3 is the highest. Clients are assigned an Assurance Level for physical security and as well as cybersecurity need.
The assurance requirements for a fielded device are dependent upon the security environment in which the device is deployed and the data it processes. The security environment considers the physical environment (can attackers physically access the Cyber System Component), the cyber environment (the cyber-attack risk from network(s) the device is attached to), the data requiring protection (files, databases, authorization credentials, and so on) and the purpose of the Cyber System Component (what kind of product is it? what is the intended use?). These factors along with the associated acceptable risks determine which Assurance Level the device will need to comply with.
SCE will determine the level of assurance required for a specific procurement. This determination should be based upon completing a risk assessment and mapping the identified risks to the required assurance level. SCE can then specify the assurance level required for the procurement and select appropriate technology that, at a minimum, meets the technical requirements for the required level of assurance.
In determining the appropriate level of physical protections required for a device, it is important to consider both the operating environment, the value and sensitivity of the data protected by the device, and the level of security assurance required for specific applications and transactions, based on the risks and their likelihood of occurrence of each application or transaction. The required level of physical assurance should be based upon the likely consequences of a successful physical compromise. As the consequences of physical compromise become more serious, the required level of assurance increases.
For example, SCE may conclude that a module protecting low value information and deployed in an environment with physical protections and controls, such as equipment cages, locks, cameras, and security guards, etc., requires no additional physical protections and may be implemented in software executing on a general purpose computer system (i.e. Assurance Level 1). However, in the same environment, cryptographic modules protecting high value or sensitive information, such as root keys, may require strong physical security.
When deploying EPS Cyber System Components the environment, the value of the information, and the functionality protected by the module should be considered when assessing the level of module physical security required.
In determining the appropriate level of cyber protections required for a device, it is important to consider the network or networks the device is connected to, the value and sensitivity of the data protected by the device, and the level of security assurance required for specific applications and transactions, based on the risks and their likelihood of occurrence of each application or transaction. The required level of cyber assurance should be based upon the likely consequences of a successful cyber compromise. As the consequences of a cyber-compromise become more serious, the required level of assurance increases.
The Procurement Assurance Requirements specified in Table 0-21 have been extracted from the Application Security Procurement Language defined by SANS Institute. In the following tables: Table 0-22 shows the Application Development Assurance Requirements, Table 0-23 the Development Environment Assurance Requirements, Table 0-24 the Testing Assurance Requirements, Table 0-35 the Patch and Update Assurance Requirements, Table 0-26 the Delivery Assurance Requirements, and Table 0-27 the Security Acceptance and Maintenance Assurance Requirements.
The Assurance Requirements for each of the three levels are specified in the following paragraphs.
The Assurance Level 1 Cyber and Physical Security Requirements are specified in the following table. These are the minimum requirements that all Clients must meet.
The Assurance Level 2 Cybersecurity Requirements are specified in the following table.
The Assurance Level 2 Physical Security Requirements are specified in the following table.
The Assurance Level 3 Cybersecurity Requirements are specified in the following table.
The following is a sampling of the OSs known to have been evaluated to a minimum of EAL 4.
The Assurance Level 3 Physical Security Requirements are specified in the following table.
This section contains any general information that aids in understanding this document (e.g., background information, glossary, rationale). This section includes an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of any terms and definitions needed to understand this document.
This section list all abbreviations, acronyms, and definitions used throughout the document here in the context of this document and project. Entries are in alphabetical order.
