UNCLASSIFIED CPA SECURITY CHARACTERISTIC REMOTE DESKTOP. Version 1.0. Crown Copyright 2011 All Rights Reserved

Transcription

1 CPA SECURITY CHARACTERISTIC REMOTE DESKTOP Version 1.0 Crown Copyright 2011 All Rights Reserved

2 CPA Security Characteristics for CPA Security Characteristic Remote Desktop 1.0 Document History Version Date Description 0.1 Jan 2012 Initial Draft 1.0 July 2012 First Published Edition This Security Characteristic is derived from the following files File Name Version Remote Desktop 1.0 Common Libraries 1.8 Hardware Libraries 1.4 Generic Network Device 0.3 Passphrase Libraries 2.0 Soft copy location DiscoverID This document is authorised by: Deputy Technical Director (Assurance), CESG This document is issued by CESG For queries about this document please contact: CPA Administration Team CESG Hubble Road Cheltenham Gloucestershire GL51 0EX United Kingdom Tel: +44 (0) The CPA Authority may review, amend, update, replace or issue new Scheme Documents as may be required from time to time. Page ii

3 CPA Security Characteristics for CPA Security Characteristic Remote Desktop 1.0 CONTENTS REFERENCES... iv I. OVERVIEW... 1 A. Product Aims... 1 B. Typical Use Case(s)... 1 C. Expected Operating Environment... 1 D. Compatibility... 2 E. Interoperability... 2 F. Variants... 2 G. High Level Functional Components... 3 H. Future Enhancements... 3 II. SECURITY CHARACTERISTIC FORMAT... 4 III. REQUIREMENTS... 5 A. Design Mitigations... 5 B. Verification Mitigations... 9 C. Deployment Mitigations IV. GLOSSARY Page iii

4 CPA Security Characteristics for CPA Security Characteristic Remote Desktop 1.0 REFERENCES [a] The Process for Performing Foundation Grade CPA Evaluations, v1.3, August 2011, CESG Page iv

5 I. OVERVIEW 1. This document is a CPA Security Characteristic it describes requirements for a particular type of assured product for evaluation and certification under CESG s Commercial Product Assurance (CPA) scheme. A. Product Aims 2. Products which conform to this Remote Desktop Client Security Characteristic (SC) allow basic user control of machines running a remote desktop server located within another security domain. The client enables users to view and interact with the desktop environment on a potentially compromised machine, while protecting the client from compromise by the server. Client Server 3. This SC does not address denial of service or mitigate threats relating to confidentiality and integrity of the connection. 4. The assurance of the remote desktop server is not within the scope of this SC. B. Typical Use Case(s) 5. This SC focuses on the following applications: Browse Down 6. The client may be used to allow a user in a more trusted system to interact with one or more less trusted systems. An example of this would be a secure network connecting to a machine at a lower classification level which may have access to the internet. Browse Across 7. The client may be used to allow a user in a system to interact with one or more systems which may be trusted to the same degree but where segregation of the networks may be required. For example a system administrator accesses a management terminal within another network, or a user in one department connects to a machine in another department, all at the same level of protective marking. C. Expected Operating Environment Communication Protocol 8. The client should be in an environment deemed suitable for the information contained on the systems being accessed. It should be deployed as part of an architecture which considers all layers of the protocol stack. Page 1

6 9. The client and server will not typically be within the same network, and an appropriate method (such as a firewall) of permitting authorised connections between the client and server networks together is required. This should be considered as part of the overall system design. 10. This technology could be used in conjunction with other components to mitigate threats relating to confidentiality and integrity of the connection (e.g. VPN technology as part of a home working solution). This is beyond the scope of this SC. D. Compatibility 11. The device itself may be hardware or software based and could be running on any core operating system. Where the product is software based, it should be compatible with modern and up to date operating systems; however there is no requirement to support specific or multiple operating systems. 12. Implementations of Remote Desktop clients are widely available for most platforms and architectures. The architecture or platform of the server need not be the same as that of the client. E. Interoperability 13. There are currently several different protocols in use; the most popular of which are RDP, RFB, ICA and PCoIP. It is the responsibility of the vendor to state compliance with the various standards. F. Variants 14. This Security Characteristic has two variants relating to how the product is delivered. These are: Client Software - An application running on a general purpose operating system Embedded Device - A physical appliance which may include a keyboard, mouse and display system or an appliance with ports to connect additional devices such as a keyboard, mouse and monitor. Page 2

7 G. High Level Functional Components Configuration Screen Renderer Logging Keyboard / Mouse Event Handler Network Interface Management Protocol Server Comms 15. Configuration: Covers both allowing the user to alter settings such as screen size and connection properties and the ability of a system administrator to manage the functions which may impact the security of the environment such as copy / paste etc. 16. Screen Renderer: Recomposes the screen and displays it on the client. Some clients incorporate simple graphical acceleration using the hardware of the client. 17. Network Interface: Manages the communication with the server component and the management tool if present. 18. Keyboard / Mouse Event Handler: Collects keyboard and mouse events and sends them to the network interface for transmission to the server. 19. Logging: Recording events and review of logs. Specific areas logged would typically include: configuration changes and connection attempts. H. Future Enhancements 20. A future version of this SC may include requirements which enable the use of one way copy and paste functionality between security domains. 21. A future version of this SC may include requirements which permit the use of complex software compression routines or hardware graphics acceleration such as DirectX and OpenGL. 22. CESG welcomes feedback and suggestions on possible enhancements to this Security Characteristic. Page 3

8 II. SECURITY CHARACTERISTIC FORMAT 23. All CPA Security Characteristics contain a list of mitigations which are split into three categories: development, verification and deployment. Within each of these sets the mitigations can be grouped based on areas of the product (as illustrated in the High Level Functional Component Diagram above), such as bulk encryption or authentication, or they may be overarching requirements which apply to the whole product. Reference [a] describes how evaluation teams should interpret Security Characteristics. 24. The three types of mitigations are denominated as follows: DEV Development mitigations are included by the developer during the design or implementation of the product. These are validated via a review of the product s design or implementation during a CPA evaluation. VER Verification mitigations are specific items that the evaluator must test during the evaluation of the product. DEP Deployment mitigations are points that must be considered by users or administrators during the deployment of the product. These mitigations are incorporated into the Security Procedures which are published by CESG for the product. 25. Each mitigation includes: Informational text in italics, describing the threat to be mitigated. One or more specific mitigations, which describe what must be done. Optional additional explanatory text which expands upon the requirement. 26. In the mitigations listed below, the following terminology is used: Must, Mandatory and Required are used to express a mitigation that is essential. All mitigations and detailed mitigations are mandatory unless there is an explicit caveat, such as if supported by the product. Should and Strongly Recommended are used whenever a requirement is highly desirable, but is not essential. These are likely to become mandatory in future iterations of the Security Characteristic. Could and Recommended are used to express a non-mandatory requirement that may enhance security or functionality. 27. For example: DEV.M1: [A mitigation] This mitigation is required to counter [a threat] At Foundation the product must [do something]. This can be achieved by [explanatory comment]. Page 4

9 III. REQUIREMENTS A. Design Mitigations DEV.M41: Crash reporting This mitigation is required to counter using a weakness in the operating system 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.M42: Heap hardening This mitigation is required to counter using a weakness in the operating system At Foundation Grade the product is required to use the memory management provided by the operating system. Products should not implement their own heap. DEV.M43: Stack protection This mitigation is required to counter using a weakness in the operating system At Foundation Grade the product is required to be compiled with support for stack protection in 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.M46: (Client Software ONLY) 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.M109: (Embedded Device ONLY) Protection of sensitive data lines This mitigation is required to counter installation of hardware-level malware At Foundation Grade the product is required to ensure physical access to internal data lines carrying sensitive data requires breaching of the tamper protection. In this context, sensitive data is defined as key material, user data and configuration data. DEV.M159: Update product This mitigation is required to counter exploitation of a software logic error This mitigation is required to counter exploitation of a software implementation error At Foundation Grade the product should support the use of software updates. DEV.M321: Data Execution Prevention This mitigation is required to counter using a weakness in the operating system 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. Page 5

10 DEV.M326: Drop Session Initiation Requests This mitigation is required to counter remotely initiating a session At Foundation Grade the product is required to provide the capability to not respond to requests to initiate a session. When configured as such the Client must be responsible for initiating all remote desktop connections, it must not be possible to 'Dial-In' to the client to establish a remote desktop session. DEV.M340: Address Space Layout Randomisation This mitigation is required to counter using a weakness in the operating system At Foundation Grade the product is required to be compiled with full support for ASLR, including all libraries used. ASLR may be disabled for specific aspects of the product, provided there is justification of why this is required. DEV.M355: Secure software delivery This mitigation is required to counter installation of malware on host 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. Initial code for the product, and any subsequent updates, must be distributed in such a way that tampering is cryptographically detectable. The recipient of the software must be able to ensure the identity of the originator (i.e. vendor). DEV.M679: (Embedded Device ONLY) All data can be purged This mitigation is required to counter recovery of secrets from a decommissioned, redeployed or compromised device At Foundation Grade the product is required to provide the capability to delete all data during disposal or repurposing. It must be possible to reset the device to factory defaults; which includes clearing logs, before redeploying or disposing of the device. DEV.M683: No sensitive data stored on the device This mitigation is required to counter retrieving sensitive data from the device At Foundation Grade the product is required to ensure that the device does not store any data from the viewed environment. DEV.M766: (Embedded Device ONLY) Minimise presented services This mitigation is required to counter exploitation of an un-patched vulnerability At Foundation Grade the product is required to ensure all unnecessary services are not reachable. The device must ensure that only services necessary for correct operation are visible via external interfaces. For example where the device contains an embedded operating system, features from the operating system not required should not be accessible. DEV.M770: Data exchange features can be disabled by an administrator This mitigation is required to counter using interactive features to exfiltrate data At Foundation Grade the product is required to only allow client configuration relating to data exchange features to be changed by an administrator. It must be possible to disable features that allow transfer of potentially malicious or executable data such as clipboard, sound, disk, printer, serial port and plug and play device sharing on the client to prevent the browsed environment exfiltrating data. Page 6

11 DEV.M771: (Embedded Device ONLY) Control devices that can be connected to external interfaces This mitigation is required to counter a user connecting an unauthorised device At Foundation Grade the product is required to ensure a policy relating to devices used with the client can be applied. It must be possible to apply specific rules to all standard hardware interfaces of the device, for example USB ports. Rules allowing a keyboard and mouse will need to be present to allow normal use. Rules must be applied as a white list which would state which interfaces can be written to, read or executed from and may also include rules specific to particular devices which may be plugged in to a given interface. For example a rule may state deny all access to USB except to allow data to be written to a specific printer attached to USB. DEV.1 - Design >> Comms Protocol DEV.1.M678: Protocol implemented according with developer's Functional Specification This mitigation is required to counter exploitation of the protocol At Foundation Grade the product is required to implement the protocol in accordance to the developer's functional specification. The developer must provide a complete functional specification for the protocol, and must provide evidence to the evaluator that the product accurately implements this specification. DEV.2 - Design >> Logging DEV.2.M627: Protect access to logs This mitigation is required to counter sanitisation of illegitimate access from logs This mitigation is required to counter modification of the logs 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 provide the ability to automatically push logs to an external device. At Foundation Grade the product is required to ensure that all logs are time stamped. DEV.3 - Design >> Configuration DEV.3.M615: Inform administrator of account activity This mitigation is required to counter exploitation of poor management of passphrases by the administrator This mitigation is required to counter dictionary and exhaustion attacks At Foundation Grade the product should display recent authentication history. It is recommended that on login the user be notified of the date and time of the last successful login and any failed login attempts since the last successful login. If recent authentication history is displayed, it is strongly recommended that users are told what to do, preferably on the screen, if the history is not what is expected. DEV.3.M616: Anti Hammer This mitigation is required to counter dictionary and exhaustion attacks At Foundation Grade the product is required to have a mechanism for limiting the rate of login attempts. Page 7

12 DEV.3.M768: Do not take configuration instructions from the Server This mitigation is required to counter updating the client configuration from the viewed environment At Foundation Grade the product is required to only allow client configuration to be changed on the client machine or management application. Changes must be authorised by a system administrator. The method used to make the change must check the authenticity of the change request before accepting the change. DEV.4 - Design >> Screen Renderer DEV.4.M671: Configurable graphics acceleration This mitigation is required to counter the exploitation of the graphics card. At Foundation Grade the product should not use graphics acceleration. At Foundation Grade the product is required to enable complex graphics acceleration to be disabled, if implemented. Simple graphics acceleration is acceptable. For example bitmap based routines which may instruct the client to redraw a box at given coordinates. Technologies that pass through native graphics commands such as OpenGL, DirectX, GDI or GPU instructions must be able to be disabled. DEV.4.M682: (Embedded Device ONLY) Only store graphics data in volatile storage This mitigation is required to counter retrieving sensitive data from the graphics card At Foundation Grade the product is required to ensure that if data is stored on a graphics card, it is only ever in volatile storage. Page 8

13 B. Verification Mitigations VER.M326: Drop Session Initiation Requests This mitigation is required to counter remotely initiating a session At Foundation Grade the evaluator will ensure the product does not respond to requests to initiate a session. When configured as such the Client must be responsible for initiating all remote desktop connections, it must not be possible to 'Dial-In' to the client to establish a remote desktop session. VER.M341: (Client Software ONLY) 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.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.M766: (Embedded Device ONLY) Minimise presented services This mitigation is required to counter exploitation of an un-patched vulnerability At Foundation Grade the evaluator will validate the developer's assertions regarding the necessary presented services. The evaluator must ensure that only services required for correct operation of the device are available via its interfaces. VER.1 - Verify >> Comms Protocol VER.1.M570: Review protocol strength rationale This mitigation is required to counter exploitation of the protocol At Foundation Grade the evaluator will review an analysis of the protocol provided by the developer to ensure it is logical and consistent. The protocol should only allow keyboard, mouse and video data between a properly configured client and server. The developer must provide analysis of the protocol which shows this to be the case with rationale explaining why the developer took their approach for implementation. The evaluator must review the developer's analysis and rationale to ensure it is logically consistent. The evaluator is not expected to perform a detailed analysis of the protocol - but must ensure that there is a reason to believe the assertions made by the developer about the implementation of the protocol. Page 9

14 VER.2 - Verify >> Management Protocol, Comms Protocol VER.2.M80: Protocol robustness testing This mitigation is required to counter discovery of a vulnerability in the implementation of the protocol 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. Page 10

15 C. Deployment Mitigations DEP.M26: (Embedded Device ONLY) Physical tamper evidence This mitigation is required to counter physical compromise of device This mitigation is required to counter installation of hardware-level malware 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 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. 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. DEP.M39: Audit log review This mitigation is required to counter exploitation of a software logic error This mitigation is required to counter exploitation of a software implementation error At Foundation Grade the deployment is required to regularly review audit logs for unexpected entries. DEP.M46: (Client Software ONLY) User least privilege This mitigation is required to counter taking advantage of existing user privilege At Foundation Grade the deployment is required to ensure all user accounts have the fewest privileges required to enable business functionality. DEP.M50: Role based access control This mitigation is required to counter unauthorised use of management privilege At Foundation Grade the deployment is required to enforce separate accounts for client management and user access. DEP.M131: (Client Software ONLY) 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.M159: Update product This mitigation is required to counter exploitation of a software logic error This mitigation is required to counter exploitation of a software implementation error At Foundation Grade the deployment is required to update to the latest version where possible. DEP.M340: Address Space Layout Randomisation This mitigation is required to counter using a weakness in the operating system At Foundation Grade the deployment is required to enable ASLR in the host Operating System where available. Page 11

16 DEP.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 administrator is required to use the update process described within the Security Procedures. DEP.M620: (Embedded Device ONLY) Physical security controls This mitigation is required to counter compromising physical security surrounding device At Foundation Grade the deployment is required to store the device in an appropriately secured area. This applies to both operational and non-operational storage. DEP.M667: (Embedded Device ONLY) Purge all data before disposal or repurposing This mitigation is required to counter recovery of secrets from a decommissioned, redeployed or compromised device At Foundation Grade the deployment is required to delete all data during disposal or repurposing. Verify that the device has been reset to factory defaults which includes clearing logs before redeploying. Final disposal must be in accordance with IS5. DEP.M674: (Client Software ONLY) Deploy onto a managed platform This mitigation is required to counter use a known vulnerability of the host to gain additional privilege At Foundation Grade the deployment is required to ensure the operating system is patched and up to date. The environment of the client should be configured and managed according to security best practice. DEP.M681: Deployed on a trusted network This mitigation is required to counter interception and viewing of traffic This mitigation is required to counter a Denial of Service attack on client This mitigation is required to counter interception and modification of traffic At Foundation Grade the deployment is required to perform all administration activities over a trusted network. Where the deployment is concerned about the protection of traffic over an untrusted network (e.g. remote working) a VPN assured to the classification of the data is required to ensure the confidentiality of the connection. At Foundation Grade the deployment is required to ensure that all client communication messages occur over an adequately protected network. This network must be accredited to at least the highest classification of the data in transit. Where the deployment is concerned about the protection of traffic over an untrusted network (e.g. remote working) a VPN assured to the classification of the data is required to ensure the confidentiality of the connection. Page 12

17 DEP.M769: Data exchange features are disabled by an administrator This mitigation is required to counter using interactive features to exfiltrate data At Foundation Grade the deployment is required to disable data exchange features. All features except keyboard, video and mouse related traffic must be denied. The security procedures accompanying this product should provide guidance on configuration to achieve this. DEP.1 - Deploy >> Configuration DEP.1.M282: Initial passphrase is changed on first use This mitigation is required to counter use of system default passphrases At Foundation Grade the deployment is required to ensure passphrase is changed on first logon. The system must force users to use an initial passphrase once only, i.e. forces the passphrase to change on first logon. It is strongly recommended that initial passphrases have a limited lifetime between generation and first use that is as short as is practicable. DEP.1.M613: Provide guidance on passphrase management This mitigation is required to counter a social engineering attack on the administrator This mitigation is required to counter exploitation of poor management of passphrases by the administrator This mitigation is required to counter dictionary and exhaustion attacks This mitigation is required to counter poor passphrase storage At Foundation Grade the deployment is required to provide training to administrators on passphrase management. Administrators should be provided with guidance regarding the secure handling of passphrases which allow access to sensitive systems. Administrators must be taught never to disclose passphrases, even to their superiors. Administrators must also be made aware of the risks of using protectively marked devices in public or untrusted areas. Passphrases should not be entered in areas where others could see them being entered. An administrator must not use passphrases in more than one system. At Foundation Grade the deployment is required to ensure any hardcopies of passphrases are stored securely. At Foundation Grade the deployment should educate administrators about social engineering methods used by attackers. DEP.1.M614: Suitable passphrase length and complexity This mitigation is required to counter exploitation of poor management of passphrases by the administrator This mitigation is required to counter dictionary and exhaustion attacks At Foundation Grade the deployment is required to ensure passwords are at least 8 characters long. User generated passphrases are acceptable, but machine generated passphrases should be used where possible. Page 13

18 DEP.2 - Deploy >> Logging DEP.2.M625: Log all relevant actions This mitigation is required to counter modification of the logs At Foundation Grade the deployment is required to automatically export logs to management/red side device. At Foundation Grade the deployment is required to configure the product to log capture 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. Timestamps must be accurate and the deployment must take measures to ensure this. Such measures could be NTP synchronisation or a manual process. DEP.2.M626: Monitor logs for unexpected entries This mitigation is required to counter sanitisation of illegitimate access from logs This mitigation is required to counter modification of the logs At Foundation Grade the deployment is required to assess impact of entries and follow organisational procedures for incident resolution. DEP.3 - Deploy >> Screen Renderer DEP.3.M672: Control graphics acceleration This mitigation is required to counter the exploitation of the graphics card. At Foundation Grade the deployment is required to disable complex complex graphics acceleration if it is implemented. Simple graphics acceleration is acceptable. For example bitmap based routines which may instruct the client to redraw a box at given coordinates. Technologies that pass through native graphics commands such as OpenGL, DirectX, GDI or GPU instructions must not be used. The security procedures accompanying this product should provide guidance on configuration to achieve this. Page 14

19 IV. GLOSSARY 28. The following definitions are used in this document: Term CPA ICA RDP RFB PCoIP Security Characteristic VPN Zero Client Meaning Commercial Product Assurance Independent Computing Architecture, a proprietary protocol used by Citrix to share a desktop via a network connection. Remote Desktop Protocol, a proprietary protocol used by Microsoft to share a desktop via a network connection. Remote Frame Buffer, an open source protocol used by several vendors to share a desktop via a network connection. PC Over IP, a proprietary protocol specified by Teradici and licensed to several vendors for use in their hardware or software products which allow a desktop to be shared via a network connection. 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. Virtual Private Network Also known as an Ultra Thin Client. A term used to refer to a class of computer which does not contain the traditional features such as a hard disk, graphics card etc. Page 15

20 THIS PAGE IS INTENTIONALLY LEFT BLANK Page 16