Abstract: The present embodiments relate to implementing change data on no-master NoSQL data stores. An optimized node can be identified from a plurality of NoSQL data storage nodes and a specialized node can be connected (e.g., collocated) to the optimized node. The specialized node can maintain change data capture (CDC) data provided by client nodes in a hash map that can be used as a point of truth for coordinating CDC data across the plurality of NoSQL data storage nodes. The plurality of NoSQL data storage nodes can identify and coordinate all read/write data obtained from multiple client devices in a geographically separated large-scale (e.g., planet scale) system to identify change data in a distributed data store. The specialized data can provide read data to devices in the large-scale system to reconcile inconsistencies in change data across nodes in the large-scale system.

Abstract: Techniques in this disclosure include polling statuses of one or more assets with one or more messages signed by a device private key. The statuses can be polled by a computing device. The techniques can include receiving one or more replies from the one or more assets. A reply can be signed with an asset private key and the reply can contain an asset status. The computing device can validate the one or more replies using one or more asset public keys. The computing device can add the statuses from the validated replies to a status log.

Abstract: The present embodiments relate to implementing change data on no-master NoSQL data stores. An optimized node can be identified from a plurality of NoSQL data storage nodes and a specialized node can be connected (e.g., collocated) to the optimized node. The specialized node can maintain change data capture (CDC) data provided by client nodes in a hash map that can be used as a point of truth for coordinating CDC data across the plurality of NoSQL data storage nodes. The plurality of NoSQL data storage nodes can identify and coordinate all read/write data obtained from multiple client devices in a geographically separated large-scale (e.g., planet scale) system to identify change data in a distributed data store. The specialized data can provide read data to devices in the large-scale system to reconcile inconsistencies in change data across nodes in the large-scale system.

Abstract: Techniques disclosed herein may include receiving a request to transfer an asset. The techniques may include accessing an asset record comprising an asset type, an asset location, and a location history for the asset. The techniques may include determining whether the asset is a volatile asset using the asset type. The techniques may include determining whether the location history is a complete location history for the asset. The techniques may include determining whether the asset is an unused asset using the location history. The techniques may include determining whether the asset is listed in an inventory list using the asset location. The techniques may include approving the request based at least in part on a determination that the asset is the volatile asset, the location history is the complete location history, the asset is unused, and the asset is in the inventory list.

Abstract: Systems, methods, and other embodiments associated with secure firmware update in a bare metal cloud environment are described. In one embodiment, a trusted device for causing a component of a computing device to accept a firmware update is presented. The device includes a management interface configured to receive a command that authorizes a firmware update to the component. The device further includes a recovery device logic that is configured to generate a signal configured to cause the component to enter a recovery mode. The recovery mode configures the component to accept the firmware update. The device also includes an interface of the device that is configured to pass the signal to the component to cause the component to enter the recovery mode and accept the firmware update.

Abstract: One example embodiment is adapted for use in facilitating collection and transport of memory devices, e.g., drives, motherboards, etc., e.g., for the purposes of subsequent destruction. The example embodiment has an outer bin, also called a garage or outer enclosure, within which is placed an inner bin with wheels. Once closed and locked, the outer bin has a door that can be opened so drives or other memory devices can be inserted. The drives then fall into the inner bin and, once sufficiently filled, the inner bin be easily wheeled out from the outer bin. The inner bin has its own locking lid that is secured when transporting the inner bin with the drives, e.g., to a destruction facility or area. Other features are provided as described below. Enhanced synergistic security features include use of multi-point locking latches to secure doors and lids, metal construction of the bins, and so on. The bins are sized to facilitate efficient collection and transport of potentially sensitive data center media.

Abstract: One example embodiment is adapted for use in facilitating collection and transport of memory devices, e.g., drives, motherboards, etc., e.g., for the purposes of subsequent destruction. The example embodiment has an outer bin, also called a garage or outer enclosure, within which is placed an inner bin with wheels. Once closed and locked, the outer bin has a door that can be opened so drives or other memory devices can be inserted. The drives then fall into the inner bin and, once sufficiently filled, the inner bin be easily wheeled out from the outer bin. The inner bin has its own locking lid that is secured when transporting the inner bin with the drives, e.g., to a destruction facility or area. Other features are provided as described below. Enhanced synergistic security features include use of multi-point locking latches to secure doors and lids, metal construction of the bins, and so on. The bins are sized to facilitate efficient collection and transport of potentially sensitive data center media.

Abstract: The present embodiments relate to implementing change data on no-master NoSQL data stores. An optimized node can be identified from a plurality of NoSQL data storage nodes and a specialized node can be connected (e.g., collocated) to the optimized node. The specialized node can maintain change data capture (CDC) data provided by client nodes in a hash map that can be used as a point of truth for coordinating CDC data across the plurality of NoSQL data storage nodes. The plurality of NoSQL data storage nodes can identify and coordinate all read/write data obtained from multiple client devices in a geographically separated large-scale (e.g., planet scale) system to identify change data in a distributed data store. The specialized data can provide read data to devices in the large-scale system to reconcile inconsistencies in change data across nodes in the large-scale system.

Abstract: Techniques are disclosed for tracing memory components in asset management systems. A computing device may receive an indication that a new device has been connected to a network. The computing device receives a first set of memory specifications from the new device and a second set of memory specifications from a SoV database. The computing device then generates a memory-asset data structure that stores a third set of memory specifications, each memory specification of the third set of memory specifications being a memory specification that is in both the first set of memory specifications and the second set of memory specifications. The computing device assigns, memory specifications of the third set of memory specifications, a data privacy level that is based on a sensitivity of data stored in the component of the new device. The computing device may then transmit the memory-asset data structure.

Abstract: Techniques are disclosed for tracing memory components in asset management systems. A computing device may receive an indication that a new device has been connected to a network. The computing device receives a first set of memory specifications from the new device and a second set of memory specifications from a SoV database. The computing device then generates a memory-asset data structure that stores a third set of memory specifications, each memory specification of the third set of memory specifications being a memory specification that is in both the first set of memory specifications and the second set of memory specifications. The computing device assigns, memory specifications of the third set of memory specifications, a data privacy level that is based on a sensitivity of data stored in the component of the new device. The computing device may then transmit the memory-asset data structure.

Abstract: Technologies are provided for secure sanitization of a storage device. A storage device can be configured to support an operational mode, into which the storage device is placed by default, and in which requests to cryptographically erase the storage device are rejected. The storage device can support a separate sanitization mode in which a request to cryptographically erase the storage device will be processed. Access to the sanitization mode can be restricted to trusted sources (such as a boot firmware of a computer connected to the storage device). The storage device can be configured to reject a command to place the storage device in the sanitization mode, unless the command is received during an initialization of the storage device. In at least some embodiments, the storage device can reject data access commands while it is in the sanitization mode.

Abstract: One example embodiment is adapted for use in facilitating collection and transport of memory devices, e.g., drives, motherboards, etc., e.g., for the purposes of subsequent destruction. The example embodiment has an outer bin, also called a garage or outer enclosure, within which is placed an inner bin with wheels. Once closed and locked, the outer bin has a door that can be opened so drives or other memory devices can be inserted. The drives then fall into the inner bin and, once sufficiently filled, the inner bin be easily wheeled out from the outer bin. The inner bin has its own locking lid that is secured when transporting the inner bin with the drives, e.g., to a destruction facility or area. Other features are provided as described below. Enhanced synergistic security features include use of multi-point locking latches to secure doors and lids, metal construction of the bins, and so on. The bins are sized to facilitate efficient collection and transport of potentially sensitive data center media.

Abstract: Systems, methods, and other embodiments associated with secure firmware update in a bare metal cloud environment are described. In one embodiment, a trusted device for causing a component of a computing device to accept a firmware update is presented. The device includes a management interface configured to receive a command that authorizes a firmware update to the component. The device further includes a recovery device logic that is configured to generate a signal configured to cause the component to enter a recovery mode. The recovery mode configures the component to accept the firmware update. The device also includes an interface of the device that is configured to pass the signal to the component to cause the component to enter the recovery mode and accept the firmware update.

Abstract: Technologies are provided for secure sanitization of a storage device. A storage device can be configured to support an operational mode, into which the storage device is placed by default, and in which requests to cryptographically erase the storage device are rejected. The storage device can support a separate sanitization mode in which a request to cryptographically erase the storage device will be processed. Access to the sanitization mode can be restricted to trusted sources (such as a boot firmware of a computer connected to the storage device). The storage device can be configured to reject a command to place the storage device in the sanitization mode, unless the command is received during an initialization of the storage device. In at least some embodiments, the storage device can reject data access commands while it is in the sanitization mode.

Abstract: Technologies are provided for secure sanitization of a storage device. A storage device can be configured to support an operational mode, into which the storage device is placed by default, and in which requests to cryptographically erase the storage device are rejected. The storage device can support a separate sanitization mode in which a request to cryptographically erase the storage device will be processed. Access to the sanitization mode can be restricted to trusted sources (such as a boot firmware of a computer connected to the storage device). The storage device can be configured to reject a command to place the storage device in the sanitization mode, unless the command is received during an initialization of the storage device. In at least some embodiments, the storage device can reject data access commands while it is in the sanitization mode.

Abstract: A digital seal of a current configuration of a rack can be generated to authenticate that rack components within the rack remain unchanged during transport. At a manufacturing site, an agent can be executed so as to capture a plurality of device identifiers, which indicate what hardware or software components are present in the rack. A digital seal representing a current configuration of the rack can be generated using the device identifiers and stored at a secure location within the rack. When the rack is transported from one location to another, the digital seal of the rack travels with the rack. At a data center, the rack can be re-tested and a new measurement can be captured. The stored digital seal can be compared to the new measurement to ensure that the rack components have not been compromised during shipping.

Abstract: Technologies are provided for secure sanitization of a storage device. A storage device can be configured to support an operational mode, into which the storage device is placed by default, and in which requests to cryptographically erase the storage device are rejected. The storage device can support a separate sanitization mode in which a request to cryptographically erase the storage device will be processed. Access to the sanitization mode can be restricted to trusted sources (such as a boot firmware of a computer connected to the storage device). The storage device can be configured to reject a command to place the storage device in the sanitization mode, unless the command is received during an initialization of the storage device. In at least some embodiments, the storage device can reject data access commands while it is in the sanitization mode.