Security Framework
11: Security Configuration and Management
submit the manufacturer identifier, and provide a cryptographic binding between manufacturer identifier and the credential. This process should be repeatable for future changes of ownership.
There may be multiple identifiers present on a single endpoint for several reasons. One reason is that the endpoint is managed by multiple entities, as would be the case for predictive maintenance scenarios. Each component builder embeds an identifier, but some endpoints may comprise multiple subcomponents, each with its own identifier, resulting in multiple identifiers associated to the endpoint entity before the owner / operator initiates the enrollment phase to issue his own identifier. The system builder may also add an identifier during system assembly. These identifiers all have a lifecycle independent of the owner / operator identifier.
Throughout the enrollment phase, an audit trail should be created to track the steps as they are executed. The audit data should be retained for a time defined by policy. The audit trail data integrity should be assured and attestable, and treated as confidential.
11.7.2 CREDENTIAL MANAGEMENT PHASE
After the enrollment phase, the credential management phase comprises a number of steps broken down into two categories( see Figure 11-6). The first category comprises the steps required to generate credentials, bind them to an entity, and issue them to the entity to which the credential should be issued. The second category comprises the steps for storing credentials, and end-of-life as well as extending the useful life of the credential.
The first category of steps for credential management brings the entity into the state where the credentials are in place and ready to use. Credential generation includes any steps required to create the credential itself, or to enable or direct the entity to create the credential. Then, during credential binding, the credential, or the means to create it, is associated to the identity assigned to the entity. Finally, during credential issuance, the credential, or the means or directive to create it, is delivered to the entity using a secured and auditable process. The specific process depends on the organizational policy for the environment.
For example, with a HRoT such as TPM in place, a key pair credential should not be generated externally and delivered to the entity. Rather it should be created inside the HRoT and only the public key be reported externally for binding.
The second category of steps for credential management addresses the normal day-to-day usage of the credentials and the edge conditions within its lifecycle. Credential storage must be implemented to the level required by the organization policy based on the level of authorization for a particular endpoint. The higher the level of authorization required, the more stringent the credential storage requirements must be. The level of authorization should be enforced in the communications policy so that endpoints that do not have strong enough credential storage are not allowed to connect to the endpoint.
Entities should be categorized into categories of criticality. Each level of criticality should be associated with a level of authentication that defines the level of trust to place in a successful authentication. The level of authentication also defines what controls must be in place to minimize the risk of false attestation, or impersonation. For example, in very low criticality
IIC: PUB: G4: V1.0: PB: 20160926- 116-