CPA-SC Enterprise Management of Data at Rest …...The management software provides the user...

NCSC-1844117881-472

CPA SECURITY CHARACTERISTIC

ENTERPRISE MANAGEMENT OF DATA AT REST ENCRYPTION

Version 1.1

© Crown Copyright 2018 – All Rights Reserved

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: [email protected] Tel: +44 (0)1242 221 491

1 www.ncsc.gov.uk/scheme/commercial-product-assurance-cpa

mailto:[email protected]

http://www.ncsc.gov.uk/scheme/commercial-product-assurance-cpa

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

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

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.


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.


• 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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Appendix A Summary of changes to mitigations

This document is an initial version; hence there is no previous version to compare changes with.

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


[d] CPA Security Characteristic – Hardware Media Encryption


[e] CPA Security Characteristic – Software Media Encryption










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

CPA-SC Enterprise Management of Data at Rest …...The management software provides the user...

Documents

Transcript of CPA-SC Enterprise Management of Data at Rest …...The management software provides the user...