4.3.1 Assets
A system designer needs to consider the type of method of recovery they want to provide for their system. This has implications for the recovery image. When recovering a system from failure, a system needs to consider the authorization logic to prevent an invalid recovery request as well as protecting any critical information that might be important for determining the cause of the failure that necessitated the recovery.
For simplicity, this section will discuss the recovery image as a single asset. In practice, a recovery image might be several independent items of code and/or data that might have different recovery rules and mechanisms.
NIST SP 800-193 Section 3.6.4 highlights the importance of preserving evidence of an attack for analysis. A recovery scheme that destroys a compromised image during the recovery process might destroy useful evidence to understand an attack. Recovery is allowed to be anywhere between a manual process to a fully automatic process. Preserving a compromised image for analysis should be considered when creating a recovery plan. During the recovery process, a corrupted image could be considered an information asset until it can be processed for any analysis required because of the corruption.
Assets:
- Recovery Image
- Corrupted Image
The recovery image needs to be protected from modifications. Depending on the recovery scheme, verifying the integrity and authenticity of the recovery image might also be required as a security objective.
Security Objectives:
- Access Control
- Integrity
- Authenticity
The corrupt image that results in the recovery operations needs to be prevented from being installed or executed. The corrupt image also needs to be protected against modification until a root cause analysis of the failure can be performed.
Security Objective: Access Control
A recovery image contains the firmware and/or data required to restore a system in the case of a failure. A factory Reset is special case of recovery that restores the system to the factory default state. An updatable recovery image allows the firmware update process to save a prior version to use in a later recovery event. This recovery image should be protected from unauthorized modifications/updates. A system can include a mix of several types of recovery methods.
There are several possible configurations for system recovery in the case of image corruption. These include, but are not limited to:
- A second copy of the current image
- A copy of the prior version before the last update
- An assigned recovery point set by an admin or software
- A factory reset image
Recovery can result in a downgrade of the current firmware/data version(s). A recovery plan needs to include the potential that a recovery could be used as part of an attack to roll back firmware to a version with vulnerabilities to exploit. A system might require authorization before allowing a recovery.
The dsPIC33A family of devices Flash protection regions can be used to manage access throughout recovery operations and can support several different recovery image types.
The Cryptographic Accelerator Module (CAM) can be used to accelerate any cryptographic operations required to verify the integrity, authenticity or authorization of the recovery process.