Post on 03-Jul-2020
NCSC-1844117881-472
Page 1
CPA SECURITY CHARACTERISTIC
ENTERPRISE MANAGEMENT OF DATA AT REST ENCRYPTION
Version 1.1
© Crown Copyright 2018 – All Rights Reserved
Page 2
About this document This document describes the features, testing and deployment requirements necessary to meet CPA certification for Enterprise Management of Data at Rest Encryption security products. It is intended for vendors, system architects, developers, evaluation and technical staff operating within the security arena.
Section 1 is suitable for all readers. It outlines the purpose of the security product and defines the scope of the Security Characteristic.
Section 2 and Section 3 describe the specific mitigations required to prevent or hinder attacks for this product. Some technical knowledge is assumed.
For more information about CPA certification, refer to The Process for Performing CPA Foundation Grade Evaluations1.
Document History The CPA Authority may review, amend, update, replace or issue new Scheme Documents as may be required from time to time. Soft copy location: NCSC-1844117881-472
Version Date Description
0.0 November 2012 Draft for external review
0.1 December 2012 New document template and SC Library related updates
1.0 January 2013 Updates following external review
1.1 October 2018 Amended to reflect formation of NCSC
This document is derived from the following SC Maps.
SC Map Map version
Enterprise Management of Data-at-Rest Encryption 1.0
Common Libraries 2.0.4
Crypt Libraries 2.0.4
Network Device Libraries 2.0.4
Physical Protection Libraries 2.0.4
Contact NCSC This document is authorised by: Deputy Technical Director (Assurance), NCSC. For queries about this document please contact:
CPA Administration Team NCSC, A2i, Hubble Road Cheltenham Gloucestershire GL51 0EX, UK
Email: cpa@ncsc.gov.uk Tel: +44 (0)1242 221 491
1 www.ncsc.gov.uk/scheme/commercial-product-assurance-cpa
Page 3
Contents
Section 1 Overview ................................................................................................................ 4
1.1 Introduction .................................................................................................................................................. 4
1.2 Product description...................................................................................................................................... 4
1.3 Typical use cases ........................................................................................................................................ 4
1.4 Expected operating environment ................................................................................................................ 4
1.5 Compatibility ................................................................................................................................................ 5
1.6 Interoperability ............................................................................................................................................. 5
1.7 Variants ....................................................................................................................................................... 5
1.7.1 Use of Remote Recovery ................................................................................................................. 6
1.8 High level functional components ............................................................................................................... 6
1.9 Future enhancements ................................................................................................................................. 7
Section 2 Security Characteristic Format ............................................................................ 8
2.1 Requirement categories .............................................................................................................................. 8
2.2 Understanding mitigations........................................................................................................................... 8
Section 3 Requirements ...................................................................................................... 10
3.1 Development Mitigations ..................................................................................................................... 10
3.2 Verification Mitigations ......................................................................................................................... 15
3.3 Deployment Mitigations........................................................................................................................ 17
Appendix A Summary of changes to mitigations .................................................................. 22
Appendix B References ............................................................................................................ 23
Appendix C Glossary ................................................................................................................ 24
Page 4
Section 1 Overview
1.1 Introduction This document is a CPA Security Characteristic. It describes requirements for assured Enterprise Management of Data at Rest Encryption products for evaluation and certification under NCSC’s Commercial Product Assurance (CPA) scheme.
1.2 Product description “Enterprise Management of Data at Rest Encryption” in the context of this Security Characteristic refers to a product that enables the remote management of a fleet of products that are all protected using at least one of the following three data at rest encryption Security Characteristics:
• CPA Security Characteristic for Software Full Disk Encryption [c]
• CPA Security Characteristic for Hardware Media Encryption [d]
• CPA Security Characteristic for Software Media Encryption [e]
Specifically, a product that provides Enterprise Management of Data at Rest Encryption allows the remote administration of the following aspects of a data at rest encryption product: policy management, user account management, device encryption key management, device recovery and device purging.
1.3 Typical use cases A product that implements Enterprise Management of Data at Rest Encryption enables an administrator to centrally manage of a number of CPA-approved data at rest encryption products, in terms of:
• Policy management (e.g. password lengths and formats)
• User account management (add/remove/modify)
• Device recovery:
o Encryption key management (including escrow)
o Remote recovery (if implemented - see Variants section)
• Purge protected data
1.4 Expected operating environment A product that provides Enterprise Management of Data at Rest Encryption comprises client and management software. The client software is located on a device protected by CPA-approved data at rest encryption, either as part of the product or as separately installed software. The management software is installed on a separate host machine, physically located within an appropriately secure environment, appropriate for the maximum classification of data stored on the managed machines. The management software communicates with client software on the managed devices over a trusted enterprise network – see Figure 1.
Enterprise Management of Data at Rest Encryption
Page 5
Figure 1: Network Setup for Enterprise Management of Data at Rest Encryption
The management software provides the user interface to enable the administration of the data at rest encryption products installed on remote computers/devices using messages sent over the network. These messages are received by Enterprise Management client software on the remote device, which then interacts with the host data at rest encryption product to implement the administration function received from the management software.
The management software tracks details about each of the managed devices, storing the information in a database, which may or may not be located on the same host machine as the management software.
The managed devices may be located in a number of environments, ranging from secure offices to mobile working environments such as employee residences and other potentially insecure offsite environments.
1.5 Compatibility This Security Characteristic places no explicit requirements on compatibility.
1.6 Interoperability A product meeting this Security Characteristic is expected to be able to interoperate with products meeting at least one of the following Security Characteristics:
• Software Full Disk Encryption [c]
• Hardware Media Encryption [d]
• Software Media Encryption [e]
Note: A managed product may or may not be from the same developer as the enterprise manager product.
It is strongly recommended that the Enterprise Management of Data at Rest Encryption product makes use of an RFC compliant messaging protocol between the management software and the client software on the remote devices being managed, although in this version of the Security Characteristic the protocol selected is left to the developer’s discretion.
1.7 Variants This Security Characteristic has the following variant type and associated variants:
• Variant Type: Recovery Mechanism:
o Local Recovery - The system does not support Remote Recovery.
Enterprise Management of Data at Rest Encryption
Page 6
o Remote Recovery - The system actively allows the administrator to remotely recover a managed computer/device, through communication with that device over the network.
1.7.1 Use of Remote Recovery
Ideally, device recovery should always be carried out through the administrator having direct physical access to that protected device (e.g. the administrator logs in, in person, to reset a user password).
Although Remote Recovery (if supported by the product) can provide a more enterprise-oriented recovery mechanism, its use significantly increases the risk of compromise from social engineering attacks or attackers intercepting recovery codes.
Conceptually, there are several types of Remote Recovery mechanisms, of which two common techniques include:
• Challenge-Response -The user obtains a “Challenge” code from the data at rest encryption product on the protected device, which he/she presents to their support team to validate possession of the device. Once the support team are sure the user is legitimate, they use the product to generate a “Response” code, which is provided to the user to regain access to the device.
• Recovery Passphrase - A predetermined, one-time-use value that is used to unlock a device in the event of lost credentials.
1.8 High level functional components The following diagram illustrates the various high level functional components within this product. Components asterisked* represent those relating to specific mitigations listed in Section 3. These are used to structure the Security Characteristic, and to give context to each mitigation.
Figure 2: Functional components of an Enterprise Management of Data at Rest Encryption product
The functional components in Figure 2 are described as follows.
• Client Software* - Logically located with the data at rest encryption product that protects the managed device. It may comprise a separate software package, as may be the case for a disk protected by an SFDE product, or be a logical component within the embedded code of a hardware media encryption device.
• Managed Device* - Computer/device protected by the managed data at rest encryption product.
• Management Database* - Contains configuration, key escrow and recovery information for the devices remotely managed by the deployment.
Enterprise Management of Data at Rest Encryption
Page 7
• Management Software* - General tracking of the managed devices, details being stored in the Management Database.
• Management Software >> Access Control* - The restriction of access control to one or more administrators, which may be implemented by the software and/or the operating system.
• Management Software >> Logging* - Logging of events to aid detection of potential vulnerabilities or unexpected behaviour.
• Management Software >> PRNG* - Handles the creation of encryption keys and device recovery data.
1.9 Future enhancements NCSC welcomes feedback and suggestions on possible enhancements to this Security Characteristic.
One possible future enhancement may be to extend the Security Characteristic to cover management of additional device platform types, such as smart phones
Page 8
Section 2 Security Characteristic Format
2.1 Requirement categories All CPA Security Characteristics contain a list of mitigations that describe the specific measures required to prevent or hinder attacks. The mitigations are grouped into three requirement categories; design, verification and deployment, and appear in section 3 of this document in that order.
• Development mitigations (indicated by the DEV prefix) are measures integrated into the development of the product during its implementation. Development mitigations are checked by an evaluation team during a CPA evaluation.
• Verification mitigations (indicated by the VER prefix) are specific measures that an evaluator must test (or observe) during a CPA evaluation.
• Deployment mitigations (indicated by the DEP prefix) are specific measures that describe the deployment and operational control of the product. These are used by system administrators and users to ensure the product is securely deployed and used in practice, and form the basis of the Security Operating Procedures which are produced as part of the CPA evaluation.
Within each of the above categories, the mitigations are further grouped into the functional areas to which they relate (as outlined in the High level functional components diagram). The functional area for a designated group of mitigations is prefixed by double chevron characters (‘>>’).
For example, mitigations within a section that begins:
Development>>Management
- concern Development mitigations relating to the Management functional area of the product.
Note: Mitigations that apply to the whole product (rather than a functional area within it) are listed at the start of each section. These sections do not contain double chevron characters.
2.2 Understanding mitigations Each of the mitigations listed in Section 3 of this document contain the following elements:
• The name of the mitigation. This will include a mitigation prefix (DEV, VER or DEP) and a unique reference number.
• A description of the threat (or threats) that the mitigation is designed to prevent or hinder. Threats are formatted in italic text.
• The explicit requirement (or group of requirements) that must be carried out. Requirements for foundation grade are formatted in green text. Requirements for augmented grade are formatted in maroon text.
In addition, certain mitigations may also contain additional explanatory text to clarify each of the foundation/augmented grade requirements, as illustrated in the following diagram.
Page 9
Figure 3: Components of a typical mitigation
Name of themitigation
Threat that thismitigation counters
Requirements neededFor Foundation Grade
Requirements neededFor Augmented Grade
Explanatory commentfor Foundation
Grade requirement
Explanatory commentFor Augmented
Grade requirement
If the product requires more than 12 options to be checked by an administrator
to comply with these Security Characteristics, the developer must supply a tool
which helps the administrator to achieve this requirement.
DEV.M267: Provide an automated configuration tool to enforce required settings This mitigation is required to counter exploitation of an accidental misconfiguration
At Foundation Grade the product is required to be provided with a configuration
tool, or other method, for an administrator to initially set it up into a suitable
configuration.
If the product requires more than 12 options to be changed or set by an
administrator to comply with these Security Characteristics, the developer must
supply a tool or policy template which helps the administrator to achieve this in
fewer steps.
At Augmented Grade the product is required to provide a tool, or other method,
for an administrator to verify that their configuration confirms to CPA
Augmented.
Page 10
Section 3 Requirements
This section lists the Development, Verification and Deployment mitigations for the Enterprise Management of Data at Rest Encryption Security Characteristic.
3.1 Development Mitigations
DEV.M147: Encrypt device's encryption key during escrow process This mitigation is required to counter recovery of a device's encryption key from network traffic during
escrow process
At Foundation Grade the product is required to encrypt the device's encryption key during the
escrow process. Escrow data containing recovery details (such as a DEK) must be encrypted by an escrow key
using AES in CBC mode (or another mode of at least the same strength).
An AES escrow key should be ephemeral and must have size and entropy at least as large as that
of the associated DEK.
DEV.M417: Authenticate command / configuration messages This mitigation is required to counter acting upon fraudulent commands from spoofed or tampered command / configuration messages
This mitigation is required to counter performing a man-in-the-middle attack on configuration
messages during provisioning process
This mitigation is required to counter spoofing a remote purge command This mitigation is required to counter spoofing a user account deletion message to the client software
At Foundation Grade the product is required to authenticate command and configuration
messages.
The protocol for exchanging command and configuration messages must incorporate an
authentication mechanism, such as digital signing, that enables the recipient to confirm the authenticity and validity of that message.
DEV.1 - Development >> Client Software
DEV.1.M41: Crash reporting This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the product is required to ensure crashes are logged. Where it is possible that sensitive data may end up in the crash data, this must be handled as red
data and must only be available to an administrator. Crash data from both the product and the
underlying operating system must be considered.
DEV.1.M42: Heap hardening This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the product should use the memory management provided by the operating
system. Products should not implement their own heap.
DEV.1.M43: Stack protection This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the product is required to be compiled with support for stack protection including all libraries, where the tool chain supports it.
If more recent versions of the tool chain support it for the target platform then they should be
used in preference to a legacy tool chain.
DEV.1.M46: User least privilege This mitigation is required to counter taking advantage of existing user privilege
At Foundation Grade the product is required to operate correctly from a standard account without
elevated privileges.
Page 11
DEV.1.M159: Update product This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the product should support the use of software updates.
DEV.1.M321: Data Execution Prevention This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the product is required to support Data Execution Prevention (DEP) when
enabled on its hosting platform and must not opt out of DEP.
If the product is to be specifically deployed on a platform that does not support either Software DEP or Hardware-enforced DEP, there is no requirement for DEP compatibility.
DEV.1.M340: Address Space Layout Randomisation This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the product is required to be compiled with full support for ASLR, including
all libraries used.
If the product is to be specifically deployed on an operating system that does not support ASLR,
there is no requirement for ASLR compatibility. Note: ASLR may be disabled for specific aspects of the product, provided there is justification of
why this is required.
DEV.1.M349: Sanitise temporary variables This mitigation is required to counter reading non-sanitised sensitive data from memory
At Foundation Grade the product is required to sanitise temporary variables containing sensitive
information as soon as no longer required.
A secure erase must consist of at least one complete overwrite.
DEV.1.M355: Secure software delivery This mitigation is required to counter installing compromised software using the update process
At Foundation Grade the product should be distributed via a cryptographically protected mechanism, such that the authenticity of software can be ensured.
DEV.2 - Development >> Management Software
DEV.2.M41: Crash reporting This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the product is required to ensure crashes are logged. Where it is possible that sensitive data may end up in the crash data, this must be handled as red
data and must only be available to an administrator. Crash data from both the product and the
underlying operating system must be considered.
DEV.2.M42: Heap hardening This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the product should use the memory management provided by the operating
system. Products should not implement their own heap.
DEV.2.M43: Stack protection This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the product is required to be compiled with support for stack protection including all libraries, where the tool chain supports it.
If more recent versions of the tool chain support it for the target platform then they should be
used in preference to a legacy tool chain.
DEV.2.M46: User least privilege This mitigation is required to counter taking advantage of existing user privilege
At Foundation Grade the product is required to operate correctly from a standard account without
elevated privileges.
Page 12
DEV.2.M159: Update product This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the product should support the use of software updates.
DEV.2.M267: Provide an automated configuration tool to enforce required
settings This mitigation is required to counter exploitation of an accidental misconfiguration
At Foundation Grade the product is required to be provided with a configuration tool, or other method, for an administrator to initially set it up into a suitable configuration.
If the product requires more than 12 options to be changed or set by an administrator to comply
with these Security Characteristics, the developer must supply a tool or policy template which
helps the administrator to achieve this in fewer steps.
DEV.2.M321: Data Execution Prevention This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the product is required to support Data Execution Prevention (DEP) when enabled on its hosting platform and must not opt out of DEP.
If the product is to be specifically deployed on a platform that does not support either Software
DEP or Hardware-enforced DEP, there is no requirement for DEP compatibility.
DEV.2.M340: Address Space Layout Randomisation This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the product is required to be compiled with full support for ASLR, including
all libraries used. If the product is to be specifically deployed on an operating system that does not support ASLR,
there is no requirement for ASLR compatibility.
Note: ASLR may be disabled for specific aspects of the product, provided there is justification of
why this is required.
DEV.2.M349: Sanitise temporary variables This mitigation is required to counter reading non-sanitised sensitive data from memory
At Foundation Grade the product is required to sanitise temporary variables containing sensitive information as soon as no longer required.
A secure erase must consist of at least one complete overwrite.
DEV.2.M353: Ensure product security configuration can only be altered by an
authenticated system administrator This mitigation is required to counter unauthorised alteration of product's configuration
At Foundation Grade the product is required to ensure that only authenticated administrators are able to change the product's security enforcing settings.
DEV.2.M355: Secure software delivery This mitigation is required to counter installing compromised software using the update process
At Foundation Grade the product should be distributed via a cryptographically protected
mechanism, such that the authenticity of software can be ensured.
DEV.2.M491: Encrypt authentication data during remote configuration This mitigation is required to counter obtaining configuration data from network
At Foundation Grade the product is required to encrypt messages containing user login data.
Configuration messages containing sensitive details (such as usernames, passphrases, passphrase hashes and token data) must be encrypted using AES in CBC mode (or another mode of at least
the same strength).
The AES key should be ephemeral and must have size and entropy at least as large as that of the
associated DEK.
Page 13
DEV.2.M498: Administration of managed device credentials This mitigation is required to counter exploitation of administered end user credentials
At Foundation Grade the product is required to administer passphrase policy on managed
computers/devices according to the Authentication Deployment requirements in the relevant CPA
Data at Rest Encryption Security Characteristics (Foundation Grade).
DEV.2.M499: (Remote Recovery ONLY) One Remote Recovery value per device
This mitigation is required to counter exploitation of weak Remote Recovery value generation
At Foundation Grade the product is required to assign a single Remote Recovery value for use
with no more than one device.
i.e. Prohibit two or more devices from sharing the same generated Remote Recovery value.
DEV.2.M612: Sanitise logged data This mitigation is required to counter supplying a malicious script through logged data
At Foundation Grade the product is required to ensure logged data is sanitised prior to display. The method and content of sanitisation will change depending on the content in the logs and
where the logs are displayed. For example, output to a HTML viewer for the logs will need to be
encoded whereas logging output to a text file may not need to be sanitised.
Note: This requirement is only applicable if the product actually incorporates a log viewer.
DEV.2.M627: Protect access to logs This mitigation is required to counter modification of logging generation This mitigation is required to counter sanitisation of illegitimate access from logs
At Foundation Grade the product is required to ensure that all log entries are time stamped.
Timestamps must be accurate and the deployment must take measures to ensure this.
Such measures could be NTP synchronisation or a manual process.
At Foundation Grade the product is required to ensure that only an authenticated administrator
can manage logs.
At Foundation Grade the product is required to not overwrite logs without alerting the administrator.
DEV.2.M802: Export logs This mitigation is required to counter modification of locally stored logs
At Foundation Grade the product is required to provide ability to automatically transfer logs to
external device.
This functionality could be provided by a host operating system, where available.
DEV.2.1 - Development >> Management Software >> Logging
DEV.2.1.M446: (Remote Recovery ONLY) Log all Remote Recovery requests This mitigation is required to counter a successful social engineering attack on the helpdesk
At Foundation Grade the product is required to log all recovery requests.
The product must log all recovery requests. This allows administrators to monitor helpdesk use
and identify potentially compromised machines.
Page 14
DEV.2.2 - Development >> Management Software >> PRNG
DEV.2.2.M138: State the Security Strength required for random numbers This mitigation is required to counter prediction of randomly generated values due to a weak entropy source
At Foundation Grade the product is required to employ an entropy source of sufficient Security
Strength for all random number generation required in the operation of the product.
The developer must state the Security Strength required of their entropy source based on analysis of all random numbers used in the product, including any generated keys. At this grade, the
Security Strength is likely to be 128 bits for products that do not use elliptic curve cryptography.
For elliptic curve-based asymmetric mechanisms it is likely to be 256 bits, and for finite field
based asymmetric mechanisms it is likely to be 192 bits.
DEV.2.2.M140: Smooth output of entropy source with approved PRNG This mitigation is required to counter prediction of randomly generated values due to a weak PRNG
At Foundation Grade the product is required to employ a PRNG of sufficient Security Strength for all random number generation required in the operation of the product.
For more details on a suitable PRNG, please see the Process for Performing Foundation Grade
Evaluations.
DEV.2.2.M141: Reseed PRNG as required This mitigation is required to counter prediction of randomly generated values due to a weak PRNG
At Foundation Grade the product is required to follow an approved reseeding methodology.
DEV.2.2.M290: Employ an approved entropy source This mitigation is required to counter prediction of randomly generated values due to a weak entropy
source
At Foundation Grade the product is required to generate random bits using an entropy source whose entropy generation capability is understood.
The developer must provide a detailed description of the entropy source used, giving evidence
that it can generate sufficient entropy for use in the device, including an estimate of entropy per
bit.
If a hardware noise source is used, then the manufacturer's name, the part numbers and details
of how this source is integrated into the product must be supplied. If a software entropy source is
employed, the API calls used must be provided. Where appropriate, details must be given of how the output of multiple entropy sources are combined.
DEV.2.2.M444: (Remote Recovery ONLY) Sufficient entropy in Remote
Recovery information This mitigation is required to counter exploitation of weak Remote Recovery value generation
At Foundation Grade the product is required to ensure Remote Recovery information contains
entropy at least equal in amount to that of the size of the device's associated encryption key.
Page 15
3.2 Verification Mitigations
VER.M443: (Remote Recovery ONLY) Validate Remote Recovery implementation
This mitigation is required to counter exploitation of a weak Remote Recovery algorithm This mitigation is required to counter exploitation of weak Remote Recovery values
This mitigation is required to counter replay attacks on Remote Recovery information
At Foundation Grade the evaluator will perform validation work on the Remote Recovery
mechanism. The mechanism must be checked to ensure that it is cryptographically sound. The evaluator must
check the following to ensure that the technique does not weaken the security of the product:
a) An exhaustive attack on the recovery information requires at least as much effort as an
exhaustive attack on the protected device's encryption key b) For Challenge-Response implementations, the data at rest encryption product must
successfully validate both parts in full to allow access to the protected device.
If the product fails this validation work then it can still pass the evaluation, but its suitability for use must first be discussed with NCSC.
VER.1 - Verify >> Client Software
VER.1.M80: Protocol robustness testing This mitigation is required to counter discovery of a vulnerability in the implementation of the protocol
stack
At Foundation Grade the evaluator will perform testing using commercial fuzzing tools.
Fuzz testing is described in more detail in the Process for Performing Foundation Grade
Evaluations.
VER.1.M341: Audit permissions on product install This mitigation is required to counter exploitation of a privileged local service
At Foundation Grade the evaluator will audit any system permissions and ACLs set or altered by
the product during installation to ensure that no changes are made, which would give a standard user the ability to modify any components that run with higher privileges (either product or system
provided).
VER.1.M347: Verify update mechanism This mitigation is required to counter installing compromised software using the update process
At Foundation Grade the evaluator will validate the developer's assertions regarding the suitability
and security of their update process.
The update process must provide a mechanism by which updates can be authenticated before they are applied.
The process and any configuration required must be documented within the Security Procedures.
VER.2 - Verify >> Managed Device
VER.2.M448: (Remote Recovery ONLY) Ensure that a single Remote Recovery value can only be used once
This mitigation is required to counter replay attacks on Remote Recovery information
At Foundation Grade the evaluator will check that a Remote Recovery value will no longer work
once it has been successfully used.
After a user has requested and successfully performed Remote Recovery, the information provided must no longer be able to unlock the device.
Page 16
VER.3 - Verify >> Management Software
VER.3.M4: Evaluation/Cryptocheck This mitigation is required to counter exploitation of a cryptographic algorithm implementation error
At Foundation Grade the evaluator will ensure all cryptographic algorithms employed for security
functionality have been validated as per the "Cryptographic Validation" section in the CPA
Foundation Process document.
VER.3.M80: Protocol robustness testing This mitigation is required to counter discovery of a vulnerability in the implementation of the protocol
stack
At Foundation Grade the evaluator will perform testing using commercial fuzzing tools. Fuzz testing is described in more detail in the Process for Performing Foundation Grade
Evaluations.
VER.3.M341: Audit permissions on product install This mitigation is required to counter exploitation of a privileged local service
At Foundation Grade the evaluator will audit any system permissions and ACLs set or altered by
the product during installation to ensure that no changes are made, which would give a standard
user the ability to modify any components that run with higher privileges (either product or system provided).
VER.3.M347: Verify update mechanism This mitigation is required to counter installing compromised software using the update process
At Foundation Grade the evaluator will validate the developer's assertions regarding the suitability
and security of their update process.
The update process must provide a mechanism by which updates can be authenticated before
they are applied. The process and any configuration required must be documented within the Security Procedures.
Page 17
3.3 Deployment Mitigations
DEP.M450: (Remote Recovery ONLY) Perform Remote Recovery over a secure communications channel
This mitigation is required to counter exploitation of weak Remote Recovery values This mitigation is required to counter replay attacks on Remote Recovery information
At Foundation Grade the deployment should perform Remote Recovery over an appropriately
secure channel.
In this context an "appropriately secure" channel is one that is accredited to the highest classification of all data which will ever be stored on the machine being recovered.
NCSC recognises that there may be circumstances in which Remote Recovery must happen over
an inadequately secure channel. In this case, once Remote Recovery has been performed the device must be subsequently handled as the highest protective marking of the data which has
ever been stored on it (at least until the device is re-keyed).
There may be some implementations that only allow Remote Recovery once per device (i.e. information stored on the device that is required for the recovery process is securely erased after
use). If the vendor can provide evidence to conclusively prove this then the above handling
guidance is not applicable.
DEP.M497: Disable unused Remote Recovery This mitigation is required to counter exploitation of dormant Remote Recovery mechanism
At Foundation Grade the deployment is required to ensure that if Remote Recovery is not being
used then any such facility present is disabled in any of the deployment's Enterprise Management and data at rest encryption products.
DEP.1 - Deployment >> Client Software
DEP.1.M39: Audit log review This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the deployment is required to regularly review audit logs for unexpected entries.
DEP.1.M131: Operating system verifies signatures This mitigation is required to counter installation of a malicious privileged local service
At Foundation Grade the deployment is required to enable signature verification for applications,
services and drivers in the host operating system, where supported and where the product makes
use of it.
DEP.1.M159: Update product This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the deployment is required to update to the latest version where possible.
DEP.1.M340: Address Space Layout Randomisation This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the deployment is required to enable ASLR in the host Operating System
where available.
DEP.1.M348: Administrator authorised updates This mitigation is required to counter installing compromised software using the update process
At Foundation Grade the deployment is required to confirm the source of updates before they are applied to the system.
The administrator is required to have authorised the updates before use. If an automatic process
is used, the administrator must also configure the product to authenticate updates.
The update procedure to be used by the administrator must be described within the product's security procedures.
Page 18
DEP.1.M418: Trust client during provisioning This mitigation is required to counter fooling a user into believing a machine is provisioned
This mitigation is required to counter recovery of the device's encryption key from client during escrow
process
At Foundation Grade the deployment is required to ensure the escrow of the device's recovery data (e.g. DEK) is completed before the device is connected to any untrusted network.
At Foundation Grade the deployment is required to only provision using trusted machines.
Provisioning should be performed on machines which are accountable and are unlikely to have
been compromised.
DEP.1.M422: Lock down host machine configuration This mitigation is required to counter exploitation of client software
At Foundation Grade the deployment is required to lock down the configuration of the managed computer/device hosting the client software (and the data at rest encryption software) to minimise
the impact and likelihood of a successful network attack.
The administrator must remove unnecessary services and ensure the computer/device is
protected by appropriate anti-malware products (kept uptodate by the end user).
DEP.1.M487: Deploy host machines on trusted network This mitigation is required to counter a Denial of Service attack on machine hosting management
software This mitigation is required to counter a Denial of Service attack on protected client device
This mitigation is required to counter fooling a user into believing a machine is provisioned
This mitigation is required to counter identification of a machine running client software through
network advertising This mitigation is required to counter performing a man-in-the-middle attack on configuration
messages during provisioning process
This mitigation is required to counter recovery of a device's encryption key from network traffic during
escrow process
At Foundation Grade the deployment is required to ensure that all device
administration/configuration messages occur over a trusted network.
This network must be accredited to at least the highest classification of the data stored on all
machines.
At Foundation Grade the deployment is required to perform provisioning in a controlled
environment on a trusted network.
The provisioning of a machine should take place on a network accredited to the same level as the
data which is going to be contained within the protected device.
DEP.1.M606: Control access to device management This mitigation is required to counter attacking management protocol stack
At Foundation Grade the deployment is required to restrict which network interfaces can be used for device management.
If a local console port or dedicated management interface is available, it must be possible to
configure the other network interfaces to not have management services accessible on them.
Similarly, it must also be possible to restrict which network interfaces have management services
enabled on them.
DEP.1.M800: Deploy on Managed Endpoint This mitigation is required to counter malware on endpoint
At Foundation Grade the deployment is required to configure endpoints in line with good IT
practice as part of a risk-managed accredited system.
Typically, this will include the installation and subsequent updating of a commercial antivirus product.
Page 19
DEP.2 - Deployment >> Management Database
DEP.2.M424: Physically protect host machine This mitigation is required to counter physical compromise of machine hosting management database
At Foundation Grade the deployment is required to protect the machine hosting a management
database from physical attack.
If the management software and database are located on separate machines the level of
protection applied to the database host machine must be the same as that applied to the management software host machine, described elsewhere in this Security Characteristic.
DEP.2.M493: Management database backups must be stored securely This mitigation is required to counter reading unprotected backup data
At Foundation Grade the deployment is required to ensure that any backups of the management
database have the same protection as the database itself.
DEP.3 - Deployment >> Management Software
DEP.3.M26: Physical tamper evidence This mitigation is required to counter physical compromise of device
At Foundation Grade the deployment is required to educate users to regularly check that tamper labels are intact.
At Foundation Grade the deployment is required to place tamper evident seals over access points
on product.
Use tamper evidence (e.g. stickers) to make entry to system internals detectable by physical inspection. Tamper stickers should be uniquely identifiable to prevent an attacker successfully
replacing it with a new, undamaged sticker.
At Foundation Grade the deployment is required to provide administrators with advice on the
tamper threat. Advice should include looking for possible damage to tamper evident seals.
In the event of tampering, the event should be reported as soon as possible and the product must
be removed from use immediately. Any product that shows evidence of tampering must not be returned to service.
DEP.3.M38: Use automated configuration tool This mitigation is required to counter exploitation of an accidental misconfiguration
At Foundation Grade the deployment is required to be configured using automated tools if
provided.
DEP.3.M39: Audit log review This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the deployment is required to regularly review audit logs for unexpected
entries.
DEP.3.M131: Operating system verifies signatures This mitigation is required to counter installation of a malicious privileged local service
At Foundation Grade the deployment is required to enable signature verification for applications, services and drivers in the host operating system, where supported and where the product makes
use of it.
DEP.3.M159: Update product This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the deployment is required to update to the latest version where possible.
Page 20
DEP.3.M340: Address Space Layout Randomisation This mitigation is required to counter exploitation of a software implementation/logic error
At Foundation Grade the deployment is required to enable ASLR in the host Operating System
where available.
DEP.3.M348: Administrator authorised updates This mitigation is required to counter installing compromised software using the update process
At Foundation Grade the deployment is required to confirm the source of updates before they are
applied to the system. The administrator is required to have authorised the updates before use. If an automatic process
is used, the administrator must also configure the product to authenticate updates.
The update procedure to be used by the administrator must be described within the product's
security procedures.
DEP.3.M422: Lock down host machine configuration This mitigation is required to counter exploitation of management software
At Foundation Grade the deployment is required to lock down the configuration of the machine hosting the management software to minimise the impact and likelihood of a successful network
attack.
The administrator must remove unnecessary services and ensure that the machine is protected by
appropriate anti-malware products.
DEP.3.M492: Minimise network access to management database This mitigation is required to counter exploitation of management software
At Foundation Grade the deployment is required to only allow the management software access to the management database records.
The database(s) used to store escrowed keys and recovery data should be configured such that
only the management software has read and write access to it.
DEP.3.M500: (Remote Recovery ONLY) Identify and authenticate users before providing Remote Recovery details
This mitigation is required to counter a successful social engineering attack on the helpdesk
At Foundation Grade the deployment is required to authenticate users before providing recovery
data.
When a user is locked out of their account, the helpdesk must conclusively establish their identity
before divulging any sensitive information. It is important that the helpdesk first ensures that the device in question has not been reported
lost or stolen before engaging with the user.
It is recommended that the user is required to identify himself/herself by providing the answers to a set of pre-agreed security questions to which the replies are difficult to guess or obtain. The
security question and answer pairs must not be common across multiple recovery services.
DEP.3.M606: Control access to device management This mitigation is required to counter attacking management protocol stack
At Foundation Grade the deployment is required to restrict which network interfaces can be used
for device management.
If a local console port or dedicated management interface is available, it must be possible to configure the other network interfaces to not have management services accessible on them.
Similarly, it must also be possible to restrict which network interfaces have management services
enabled on them.
Page 21
DEP.3.M625: Log all relevant actions This mitigation is required to counter modification of logging generation
At Foundation Grade the deployment is required to assess impact of log entries and follow
organisational procedures for incident resolution.
At Foundation Grade the deployment is required to configure the product to log all actions deemed of interest.
Ensure that log data is detailed enough to allow forensic investigation during any incident
management.
Sensitive data such as passwords and keys must not be written to the logs.
At Foundation Grade the deployment should where available, automatically export logs to
management/red side device.
DEP.3.1 - Deployment >> Management Software >> Access Control
DEP.3.1.M435: One administrator per account This mitigation is required to counter the unauthorised use of administrator account
At Foundation Grade the deployment is required to use one administrator account per
administrator.
i.e. Prohibit two or more administrators using the same administrator account with the product (or host operating system).
DEP.3.1.M501: Use of multiple administrator accounts This mitigation is required to counter the unauthorised use of administrator account
At Foundation Grade the deployment should configure the product for use with multiple
administrator accounts.
The use of multiple administrator accounts with the product (or host operating system) minimises
the risk of credential sharing and provides accountability after the unauthorised use of an administrator account.
DEP.3.2 - Deployment >> Management Software >> Logging
DEP.3.2.M447: (Remote Recovery ONLY) Regular review of Remote Recovery request logs
This mitigation is required to counter a successful social engineering attack on the helpdesk
At Foundation Grade the deployment is required to create a log review schedule such that
unexpected entries can be detected.
Logs must be reviewed regularly so as to identify potential compromises.
Page 22
Appendix A Summary of changes to mitigations
This document is an initial version; hence there is no previous version to compare changes with.
Page 23
Appendix B References
This document references the following resources.
Label Title Location Notes
[a] The Process for Performing Foundation Grade CPA Evaluations
www.ncsc.gov.uk/scheme/commercial-product-assurance-cpa
[b] FIPS 197, Advanced Encryption Standard NIST
[c] CPA Security Characteristic – Software Full Disk Encryption
www.ncsc.gov.uk/scheme/commercial-product-assurance-cpa
[d] CPA Security Characteristic – Hardware Media Encryption
www.ncsc.gov.uk/scheme/commercial-product-assurance-cpa
[e] CPA Security Characteristic – Software Media Encryption
www.ncsc.gov.uk/scheme/commercial-product-assurance-cpa
Page 24
Appendix C Glossary
The following definitions are used in this document.
Term Definition
AES Advanced Encryption Standard
CPA Commercial Product Assurance. A scheme run by NCSC providing certificate-based assurance of commercial security products.
Escrow The storage of a sensitive value away from the device in question.
PRNG Pseudo Random Number Generator
Provisioning Initial configuration of a product. In cryptographic products, this involves the generation and application of key material.
Recovery Passphrase A value set at time of system configuration which is used to unlock the device in the event of credential loss. This value must be complex in order not to weaken the security of the system.
Red side device A computer/device located in a trusted network location
SC Map Diagrammatic representation of a Security Characteristic (or part of one).
Security Characteristic A standard which describes necessary mitigations which must be present in a completed product, its evaluation or usage, particular to a type of security product.
SFDE Software Full Disk Encryption