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 -