NIST platform security: roots of trust, firmware and secure enclaves IR 8320A
All1 Have trusted asset tag information for each trusted platform instance. This information2 Provide configuration management and policy enforcement mechanisms for trusted3 During workload orchestration, periodically audit the asset tag of the cloud server platform4 Prototyping Stage 15 Server B launches workloads that require trusted infrastructure only on server platforms that have6 Use the “Add New Subscriptions” option on the “Notification Subscriptions” page to configure7 Review the information entered for this update job. Use the “Previous” button to navigate to other
| Ref | Title | Text | |
|---|---|---|---|
| 1 | Have trusted asset tag information for each trusted platform instance. This information | would be stored within the cloud server’s cryptographic module (as a cryptographic hash within the hardware cryptographic module) so that it could be verified and audited readily. | |
| 2 | Provide configuration management and policy enforcement mechanisms for trusted | platforms that include enforcement of asset tag restrictions. This goal builds upon stage 1, goal 1 (deploy workloads only to cloud servers with trusted platforms); it enhances stage 2, goal 1 by adding an asset tag check to the server to l | |
| 3 | During workload orchestration, periodically audit the asset tag of the cloud server platform | against asset tag policy restrictions. This goal is built upon stage 0, goal 3 (auditing platform trustworthiness), but it is specifically auditing the asset tag information against the policies for asset tag to ensure that the server’s ass | |
| 3.1 in 3 |
Solution Overview | This stage of the use case enables the creation of what are called trusted compute pools . Also known as trusted pools , they are physical or logical groupings of computing hardware in a data center that are tagged with specific and varying | |
| 3.2 in 3 |
Solution Architecture | Figure 2 provides a layered view of the solution system architecture. The indicated servers in the resource pool include a hardware module for storing sensitive keys and measurements. All of the servers depicted in the diagram are configure | |
| 4 | Prototyping Stage 1 | This section discusses stage 1 of the prototype implementation (trusted placement of workloads), which is based on the stage 0 work and adds components that orchestrate the placement of workloads to launch on trusted platforms. | |
| 4.1 in 4 |
Solution Overview | Figure 3 shows the operation of the stage 1 solution. It assumes that Server A and Server B are two servers within the same cloud. Figure 3: Stage 1 Solution Overview There are six generic steps performed in the operation of the stage 1 p | |
| 5 | Server B launches workloads that require trusted infrastructure only on server platforms that have | been attested to be trusted. 6. Each server platform gets audited periodically based on its measurement values. 4.2 Solution Architecture The stage 1 architecture is identical to the stage 0 architecture (see Figure 2 ), with additional m | |
| 5.1 in 5 |
Solution Overview | Stage 2 adds the monitoring of measurements in a governance, risk, and compliance dashboard. One chart that might appear in such a dashboard could reflect the relative size of the pools of trusted and untrusted cloud servers. This could be | |
| 6 | Use the “Add New Subscriptions” option on the “Notification Subscriptions” page to configure | event subscriptions. From the “Add New Subscription” page, as shown in Figure 15 , choose the types of events and resources (event sources) for which notifications need to be sent. You can choose “Security” as the resource to receive any tr | |
| 7 | Review the information entered for this update job. Use the “Previous” button to navigate to other | tabs in this wizard to change any data, if needed. When ready, click “Start” to start or schedule the update job. 8. To know the status of a scheduled task, choose the “Jobs” option under the “Provisioning” menu. This lists all running or s |
11 of 11.