Embed Size (px)
Citation preview
October 2015 Issue No: 1.1
Security Procedures
Cisco AnyConnect v3.1
Security Procedures
Cisco AnyConnect v3.1
Issue No: 1.1 October 2015
This document describes the manner in which this product should be implemented to ensure it complies with the requirements of the CPA Security Characteristics that it was assessed against. The intended audience for this document is HMG implementers, and as such they should have access to the documents referenced within. If you do not have access to these documents but believe that you have an HMG focused business need, please contact CESG Enquiries.
Document History
Version Date Comment
1.0 July 2014 First issue
1.1 October 2015 First public release
Page 1
Cisco AnyConnect v3.1
About this document These Security Procedures provide guidance in the secure operation of Cisco AnyConnect Secure Mobility Client v3.1 (in relation to acting as an IPsec VPN software client). This document is intended for System Designers, Risk Managers and Accreditors. CESG recommends you establish whether any departmental or local standards, which may be more rigorous than national policy, should be followed in preference to those given in these Security Procedures. The Security Procedures come from a detailed technical assessment carried out under the CPA scheme. They do not
replace the need for tailored technical or legal advice on specific systems or issues. CESG and its advisors accept no liability whatsoever for any expense, liability, loss, claim or proceedings arising from reliance placed on this guidance.
Related documents The documents listed in the References section are also relevant to the secure deployment of this product. For detailed information about device operation, refer to the Cisco AnyConnect v3.1 product documentation.
Points of contact For additional hard copies of this document and general queries, please contact CESG using the following details. CESG Enquiries
Hubble Road Cheltenham GL51 0EX United Kingdom
[email protected] Tel: 01242-709141
CESG welcomes feedback and encourage readers to inform CESG of their experience, good or bad in this document. Please email: [email protected]
Page 2
Cisco AnyConnect v3.1
Contents:
Chapter 1 - Outline Description ................................................................................ 3
Product Summary ..................................................................................................... 3 Certification ............................................................................................................... 3 Components ............................................................................................................. 3 Document Scope ...................................................................................................... 4
Document Terminology and Audience ...................................................................... 4
Chapter 2 - Security Functionality ........................................................................... 5
AnyCSMC v3.1 ......................................................................................................... 5 Administration and Other Products ........................................................................... 5
Chapter 3 - Secure Operation ................................................................................... 6
Introduction ............................................................................................................... 6 Pre-installation .......................................................................................................... 6
Installation ................................................................................................................ 7 Cryptographic Configuration and Operation ............................................................. 8 User Authentication .................................................................................................. 9 Interface Configuration ............................................................................................. 9
Maintenance and Updates ...................................................................................... 10 System Logs ........................................................................................................... 10
Chapter 4 - Security Incidents ................................................................................ 12
Incident Management ............................................................................................. 12
Chapter 5 - Disposal and Destruction .................................................................... 13
Erasure of Key Material .......................................................................................... 13
Routine Disposal of Product and Platform .............................................................. 13 Emergency Destruction of Equipment .................................................................... 13
Page 3
Cisco AnyConnect v3.1
Chapter 1 - Outline Description
Product Summary
1. The Cisco AnyConnect Secure Mobility Client (AnyCSMC) v3.1 (AnyC) product implements the IPsec protocol in order to provide a secure VPN endpoint on a device such as a laptop.
2. AnyC is designed to be used in conjunction with a member of the Cisco Adaptive Security Appliances (ASA) product family, each of which provides a VPN security gateway capability. (In fact, AnyC will operate with any device that provides a suitable VPN security gateway capability, but for the purposes of this document any such device must have been certified to CPA Foundation Grade.)
3. AnyCSMC v3.1 runs on the Microsoft Windows and Apple OS X operating systems.
4. AnyC supports the PSN IPsec profiles. These PSN profiles are specified in the CPA Security Characteristic (SC) IPsec VPN for Remote Working - Software Client (reference [a] Section 1.6). A hybrid profile is defined in the Cisco guidance (reference [b]). This hybrid profile is sufficiently secure to allow a connection to be made between an old range Cisco ASA gateway (a model that has an id without an X suffix) and a Cisco AnyConnect client that meets the requirement of the CPA SC.
5. AnyC is used to establish an IPsec VPN tunnel across an untrusted network from a client endpoint (a remote laptop) to a security gateway located at the boundary of an organisation’s enterprise network. This is illustrated in reference [a] Section 1.3.
Certification
6. AnyC has undergone a CPA evaluation and has been certified as meeting the Foundation Grade requirements, as described in reference [a], when installed on:
Microsoft Windows 7, 8 and 8.1, running on any suitable hardware
Apple OS X 10.6, 10.7, 10.8 and 10.9, running on any suitable hardware
7. Later versions of AnyC that are installed on a platform that conforms to the CPA certification, as defined in para 6, are automatically covered by this certification until the certificate expires or is revoked, as stated on the product’s certificate and on the CPA website www.cesg.gov.uk/servicecatalogue/CPA.
8. The evaluation was performed in conjunction with the CPA evaluation of the Cisco ASA 5500 and 5500-X v9.1(2) product family, see that product family’s Security Procedures (reference [c]).
Components
9. AnyC is a software product that relies on the underlying mobile platform (i.e. laptop) operating system (o/s) to provide certain facilities; in particular, an entropy Application Programming Interface (API) that the product can use to seed its Pseudo-Random Number Generator (PRNG) functionality.
Page 4
Cisco AnyConnect v3.1
10. At its simplest level, AnyC comprises a GUI component and a VPN “driver” agent. The GUI component can be run from a standard account without platform administrative privileges; the driver/agent component runs automatically as a system-level service.
Document Scope
11. This document provides high-level outline guidance only. It defines security procedures in terms of what should be done (e.g. “configure the product to support an IPsec profile specified in reference [a] Section 1.6”), but not in terms of how to actually carry out the procedure. (The procedures do not include instructions such as “include the following lines in the product’s XML configuration file: ...”)
12. For details of how to configure the product in accordance with this document, the reader is referred to Cisco AnyC administration guidance documentation, collectively listed under reference [b].
13. Reference is also made in this document to following the guidance given in relevant HMG publications; no attempt is made to summarise the content of such publications.
14. Cisco can be consulted for further advice and guidance on all of the recommendations, references and terminology contained in this document.
15. AnyC also supports the establishment of a VPN tunnel using the SSL/TLS protocols (rather than IPsec). However, such use of the SSL/TLS protocols is outside the scope of both this document and of the AnyC CPA evaluation.
Document Terminology and Audience
16. It is assumed that readers (System Designers, Risk Managers and Accreditors) have access to all the references, and that:
AnyC is to be deployed as part of an IT system (the “relevant” IT system) which is, or will be, accredited against security requirements that are specified in a RMADS (Risk Management and Accreditation Documentation Set)
The Design will include a specification of the highest classification of data that the product and its underlying platform device are permitted to handle (when deployed as part of the relevant IT system)
17. Throughout this Security Procedures document:
The “relevant IT system” is defined above
A reference given as, for example, [a, 1.6] means a reference to [a], Section 1.6
Page 5
Cisco AnyConnect v3.1
Chapter 2 - Security Functionality
AnyCSMC v3.1
18. Reference [a, 1.7] provides a generic high level breakdown of an IPsec software VPN client’s components. In essence, the client provides a “Black interface” to the untrusted network and a “Red interface” to the underlying o/s. Any traffic received at the Black interface that is not encrypted and authenticated under a (previously established) IPsec session is dropped; other traffic received at the Black interface is decrypted and passed to the Red interface for further processing by the o/s. Conversely, traffic received at the Red interface for onward transmission to the untrusted network is encrypted and transmitted through the IPsec tunnel.
19. Apart from implementing the above cryptographic functions, the product implements relatively few general and administrative (or management) security functions, see [a, 3.1]. This is because the product is largely administered (or managed) by a user who is able to adopt the “authorised administrator” role on the underlying platform. This point is discussed further in the following section.
Administration and Other Products
20. Due to the product running as a client on an underlying platform, anyone who administers the platform can also administer the product (e.g. change its configuration, or remove it entirely from the platform). Such users are trusted not to abuse their administrative privileges.
21. Once the product is installed on its platform, a “standard user” or a “standard account” (i.e. a user/account on the underlying platform who/which does not have platform administrative privileges) can start the product and direct it to establish a VPN tunnel with a specified security gateway, but cannot administer it (provided that the product and the platform are deployed in accordance with the guidance in this document. Apart from such guidance, general recommendations for the secure operation of an underlying platform are outside the scope of this document).
22. The product’s configuration is defined by a XML file that is installed on the underlying platform. This XML file can be created manually (using any text editor), or with the AnyConnect Profile Editor (which provides a GUI-based means of creating the file). The Profile Editor is an integral part of the Cisco Adaptive Security Device Manager (ASDM) software product (which can be installed on e.g. a laptop running Windows); the AnyC Profile Editor can also be supplied as a stand-alone Windows application.
23. However the XML file is produced, it can be pre-packaged with the product (prior to installation of both). When the product and the XML file are installed, they must be installed with appropriate permissions so that a standard user/account can run (but not modify) the product, but cannot access the XML file.
Page 6
Cisco AnyConnect v3.1
Chapter 3 - Secure Operation
Introduction
24. The rest of this document contains recommendations that outline the configuration of, and security operating procedures for the product.
25. These recommendations must be followed unless there is a strong business requirement not to do so. Any such deviations (and associated risks) should be discussed with the relevant Accreditor.
Pre-installation
26. This section deals with topics that should be addressed during the relevant IT system design stage, including requirements placed on the operational environment.
27. The product must be installed on a platform that conforms to the CPA certification, as defined in para 6. The operating system must be installed on the hardware, not run from bootable media.
28. Before the product is installed in its underlying platform, that platform must be configured in line with good IT practice and the requirements of this document, including:
If the platform’s o/s supports signature verification of applications, services and drivers then that feature of the o/s must be enabled (see the “Maintenance and Updates” section below)
If the platform’s o/s supports Address Space Layout Randomisation (ASLR), then that feature of the o/s must be enabled
The product and its XML configuration file must be installed with appropriate (platform o/s) permissions (see para 23)
The platform must be configured to drop all requests to UDP port 500 (i.e. all attempts to initiate an IKE session with the product)
The platform must be configured to authenticate a user attempting to login to it, and (if possible) to enforce separate accounts for device management, account administration and user access (see the “User Authentication” section below)
If the platform’s o/s supports capturing details of an application’s events of interest in an event log then that facility must be utilised (see the “System Logs” section below)
29. Preparations must be made to provide each user of the product and its underlying platform device with instructions for physically protecting that device in its operational environment. Each user must also be instructed to ensure that the product is not connected continuously to a security gateway for more than 24 hours at a time.
Page 7
Cisco AnyConnect v3.1
30. Use the product only with VPN security gateway(s) that have been certified to CPA Foundation Grade. Such gateway(s) must be deployed and configured to be consistent with the deployment and configuration of the product that is specified in this document (particularly with regard to IPsec profiles and split tunnelling); the gateway(s) must also be configured to force renegotiation of an IKE Security Association that has been established with the product within 24 hours of its establishment or previous renegotiation.
31. Preparations must be made to operate the product and associated security gateway(s) in conjunction with a non-public PKI system. The product must be operated with X.509 certificates that are chained to a trusted, non-public, certificate authority which enables revocation of certificates to prevent the issue of fraudulent certificates. The relevant Design should identify what are acceptable, trusted, non-public certificate authorities, and should also state whether the product’s underlying platform (which is where certificates relating to these authorities are actually stored) is permitted to trust any other certificate authorities and, if so, which ones.
32. All IPsec VPN client certificates used in the relevant IT system should be re-issued every two years and the previous certificates revoked. Re-issuing and revoking security gateway certificates used in the relevant IT system should be covered in the relevant Syops.
33. Preparations must be made to securely provision the above X.509 certificates to the product’s underlying platform (and to any other IPsec VPN software clients) and to the VPN security gateway(s) that are part of the relevant IT system.
Installation
34. The product must be installed and configured in accordance with this document. The product must be AnyCSMC v3.1 or a later version (see para 54); and the product’s software image or installation file must be acquired and verified as described in the “Maintenance and Updates” section below.
35. A suitable XML configuration file (see paras 22 and 23) must also be installed. If the file was acquired at the same time as the product then it may need to be amended (in order that the requirements of this document are met); otherwise it will have to be created from scratch.
36. The installation and (initial) configuration of the product is not a fully automated process, but comprehensive installation and configuration instructions are provided in [b].
37. Subsequent configuration of the product (and its underlying platform) should ideally be done locally (i.e. by an authorised administrator who is physically using the platform’s Human Computer Interface (HCI), such as its mouse or touch screen). Remote administration of the product (and its underlying platform) is discussed in the “Interface Configuration” section below.
Page 8
Cisco AnyConnect v3.1
Cryptographic Configuration and Operation
38. The product must be configured to use X.509 certificates to mutually authenticate all connection attempts on its (Black) network interface. Certificate verification must include full certificate chain verification, i.e. “strict” certificate checking must be enabled.
39. All IPsec VPN client certificates used in the relevant IT system must be re-issued at least every two years and the previous certificates revoked. Re-issuing and revoking security gateway certificates used in the relevant IT system should be covered in the relevant Syops.
40. By design, the product does not implement a CRL check. If required by the relevant Syops, a CRL check can, in effect, be implemented by adopting the procedural measures described in [b]. Two types of procedure are described:
install a copy of the revoked certificate onto the product’s underlying platform and mark it as untrusted, i.e. for Microsoft Windows, install it in the “Untrusted Publishers” folder, and for Apple OS X, flag it as “Never Trust” in the Keychain
change the gateway’s DNS name, then install an amended AnyConnect Connection Profile onto the underlying platform (this Profile to include the gateway’s new DNS name)
41. For both procedures, it is also necessary to install a new certificate onto the gateway to which the product is intended to connect. This certificate (which replaces the now revoked certificate) must include the gateway’s DNS name (first procedure) or new DNS name (second procedure) in the Subject Name field.
42. Various methods can be used to install a revoked certificate or an amended connection profile onto the product’s underlying platform. These methods are described in [b] and may be broadly divided into two types:
In-band, i.e. the requisite file is ‘pushed’ onto the platform when the product is connected to its (uncompromised) gateway and an IPsec tunnel is established. This type of method is applicable to use in non-emergency situations, e.g. when it is known in advance that a gateway is going to be decommissioned, or its certificate replaced as a matter of routine
Out-of-band, i.e. the requisite file is installed onto the platform without the product having to establish an IPsec tunnel to a gateway. This type of method is applicable for use in an emergency, e.g. if a gateway is stolen, or its certificate is otherwise compromised. Examples of such methods range from using MDM (Mobile Device Management) software to manual installation at some suitable location e.g. at a user’s base office
43. The product - and its associated security gateway(s) - must be configured to use an approved IPsec profile. An approved IPsec profile is as defined in [a, 1.6], together with a “hybrid” profile that is described in [b].
44. Comprehensive cryptographic configuration instructions are provided in [b]. See also para 31 above re the need to operate the product in conjunction with a suitable PKI system.
Page 9
Cisco AnyConnect v3.1
User Authentication
45. The product’s underlying platform must be configured so that any user attempting a local login to the platform (via its HCI) must supply a valid username and password.
46. The underlying platform for AnyCSMC v3.1 must be configured so that any user attempting a remote login to the platform must supply a valid username and password. Before the username/password data is transmitted to the platform from a remote computer, the communications route between the platform and the remote computer must be such that the confidentiality and integrity of data subsequently transmitted between the product and the remote computer is protected (see para 49).
47. The product’s underlying platform must (if possible) be configured to enforce separate accounts for device management, account administration and user access. In other words, it must be possible (if the platform supports such a facility) to identify each user who logs on to the platform, and - unless the relevant Syops indicates that it is unnecessary to do so - each user account should be associated with either the authorised administrator role or the standard user role.
48. Comprehensive instructions covering the above topics are provided in [b], and further general guidance on user authentication is given in CESG IA Implementation Guide No. 3 (IG 3), User Authentication Systems (reference [f]).
Interface Configuration
49. Following initial installation and configuration of the product, the product and its underlying platform must be configured such that the only means of managing (i.e. administering) them via the (Black) network interface (as opposed to via the platform’s HCI) is by an authorised administrator accessing them through a secure communications route (i.e. a route where each section between the platform and the administrator’s computer is either physically secure or is protected by a cryptographic protocol such as IPsec or SSHv2).
50. In general, the requirement of para 49 means that the product and its associated security gateway(s) must be configured to disable split tunnelling, i.e. once an IPsec VPN tunnel has been established between the product’s underlying platform and a security gateway (which actually controls whether split tunnelling is enabled or disabled) then all traffic to and from the platform (apart from loopback traffic) must be routed through the tunnel. (The product can be configured so that it starts automatically whenever the platform is powered on, as opposed to being started manually at some point by a standard user.)
51. However, the relevant Design/SyopsRMADS may permit split tunnelling to be enabled; two possible scenarios where this may be desirable are:
An underlying platform needs to use a locally networked printer; this can be achieved by enabling “Local LAN Access” in the product’s profile (but then communications between the platform and any device on that LAN will not be routed through the VPN tunnel)
An authorised administrator wishes to use Windows Remote Desktop Protocol (RDP) to access a (Windows) platform from a remote machine, in
Page 10
Cisco AnyConnect v3.1
order to manually establish a VPN session from that platform to a security gateway, and to subsequently inspect the status of the running product
52. All ports (logical and physical), protocols and services that could potentially be provided by the product and its underlying platform should be disabled if they are not needed in the relevant IT system.
53. Comprehensive instructions covering the above topics (in respect of the product) are provided in [b]. With regard to the underlying platform device, configuration instructions should be provided in the device’s administration documentation supplied by the manufacturer.
Maintenance and Updates
54. The product must be updated to the latest version - i.e. v3.1 or later - as soon as possible after an updated version is made available by Cisco. (An updated version is a whole new image or installation file - possibly packaged with an updated XML configuration file, see paras 22 and 23 - as opposed to one or more patches to be applied to the currently installed version.)
55. The authenticity of an updated version of the product must be confirmed cryptographically prior to, or immediately after, the software being installed on its underlying platform, as outlined in the following paragraphs.
56. Software installer files are made available to customers via Cisco’s web site, from where they can be downloaded to the product’s underlying platform and run. Cisco also publishes a cryptographic checksum - a hash value - for each such file, so customers can independently compute a downloaded file’s hash and compare it with the published value, in order to verify that the file is authentic. Alternatively, because the executable files are signed by Cisco, then (after the installation) these signatures can be checked using the platform o/s (if the o/s provides such a facility).
57. If an updated XML configuration file is downloaded with the updated product then the authenticity of the XML file must also be checked, and possibly the file must be amended (in order that the requirements of this document are met); otherwise the current XML configuration file may have to be amended (if it is no longer compatible with the updated product).
58. Comprehensive instructions covering maintenance and updates are provided in [b].
System Logs
59. If the product’s underlying platform o/s supports event logging then this must be enabled. The information to be included in the log messages, as specified in the relevant Design and Syops, must be detailed enough to facilitate forensic operations during any security incident investigation, but must not include any sensitive data such as passwords and keys.
Page 11
Cisco AnyConnect v3.1
60. Sufficient storage space must be allocated on the underlying platform to ensure that log messages are not dropped or overwritten before they have been backed up to auxiliary storage, or they have been inspected and removed by an authorised administrator (who has judged that the messages need not be retained).
61. An authorised administrator must regularly monitor the free storage space available for new log messages, and take action (as indicated in the previous paragraph) if the free space drops below the value(s) specified in the relevant Syops.
62. An authorised administrator must also regularly inspect the log file(s) for unexpected messages. If any such messages are found then this should be treated as a security incident (see Chapter 4). The underlying platform must be configured so that access to the log files is restricted to authorised administrators only.
63. Comprehensive instructions covering the above topics are provided in [b], general guidance on protective monitoring is given in CESG Good Practice Guide No. 13 (GPG 13), Protective Monitoring for HMG ICT Systems (reference [g]), and general guidance on forensic readiness is given in CESG Good Practice Guide No. 18 (GPG 18), Forensic Readiness (reference [h]).
Page 12
Cisco AnyConnect v3.1
Chapter 4 - Security Incidents
Incident Management
64. In the event of a security incident that does or could result in the compromise of information protected by the product (e.g. unexpected log messages, see para 62), the local IT security incident management policy should:
Ensure that the Department Security Officer (DSO) is informed
State whether the product should be immediately withdrawn from service (pending further investigation of the incident)
State whether the product’s certificate should be revoked
65. Any security incident should be managed in accordance with the local accredited security incident management procedures and policies.
66. CESG should be contacted if a compromise occurs that is suspected to have resulted from a failure of the product. General guidance on managing security incidents is given in CESG Good Practice Guide No. 24 (GPG 24), Security Incident Management (reference [i]).
Page 13
Cisco AnyConnect v3.1
Chapter 5 - Disposal and Destruction
Erasure of Key Material
67. Specific procedures for the handling of long-term secrets held in the product’s underlying platform device (i.e. all private and symmetric cryptographic keys held in its persistent storage) should be specified, and should be in accordance with the highest classification of data to be handled by the device.
68. These procedures should cover the erasure of long-term secrets; in particular, long-term secrets relating to the product.
69. Any certificate related to an erased key must be revoked within the relevant PKI to ensure that other cryptographic devices are prevented from communicating with the product.
Routine Disposal of Product and Platform
70. Before routine disposal of the product’s underlying platform device, all private and symmetric cryptographic keys held in the device’s persistent storage must be erased, and certificates stored in the device must be revoked, as described above.
71. Before un-installation of the product from the device (where the device itself will continue in use as part of some IT system), the requirements of para 70 must be satisfied with respect to keys and certificates relating to the product.
72. Final disposal and possible destruction of the device must be done in accordance with the relevant local procedures.
73. General guidance on the disposal and destruction of IT equipment (including erasure of data) is given in HMG IA Standard No. 5 (IS5), Secure Sanitisation (reference [j]).
Emergency Destruction of Equipment
74. The product and its underlying platform device are not expected to be deployed in locations that warrant emergency destruction procedures; however, if they are so deployed, then such procedures should be specified in the relevant Syops.
Page 14
Cisco AnyConnect v3.1
References
Unless stated otherwise, these documents are available from the CESG website. Users who do not have access should contact CESG Enquiries to enquire about obtaining documents. [a] CPA Security Characteristic, IPsec VPN for Remote Working - Software Client,
CESG, 2749741, Version 2.3, April 2013 (available from www.cesg.gov.uk/servicecatalogue/CPA)
[b] Cisco AnyC documentation (available from www.cisco.com), including: Cisco AnyConnect Secure Mobility Client Administrator Guide, Release 3.1, Cisco, 25 November 2012
Guide to configuring a Virtual Private Network using Cisco AnyConnect Secure Mobility Client to conform to Commercial Product Assurance Security Procedures, Cisco
[c] CESG Security Procedures for Cisco ASA 5500 v9.1(2) Product Family.
[d] HMG IA Standard No.s. 1 & 2, Information Risk Management – latest issue available from the CESG website.
[e] HMG Security Policy Framework, Cabinet Office, latest version (available from http://www.cabinetoffice.gov.uk/spf.aspx)
[f] CESG IA Implementation Guide No. 3, User Authentication Systems – latest issue available from the CESG website.
[g] CESG Good Practice Guide No. 13, Protective Monitoring for HMG ICT Systems – latest issue available from the CESG website.
[h] CESG Good Practice Guide No. 18, Forensic Readiness – latest issue available from the CESG website.
[i] CESG Good Practice Guide No. 24, Security Incident Management – latest issue available from the CESG website.
[j] HMG IA Standard No. 5, Secure Sanitisation – latest issue available from the CESG website.
Page 15
Cisco AnyConnect v3.1
Glossary
AnyC AnyCSMC v3.1
AnyCSMC AnyConnect Secure Mobility Client (Cisco)
API Application Programming Interface
ASA Adaptive Security Appliances (Cisco)
ASDM Adaptive Security Device Manager (Cisco)
CPA Commercial Product Assurance
CRL Certificate Revocation List
DSO Department Security Officer
GPG Good Practice Guide (CESG)
GUI Graphical User Interface
HCI Human Computer Interface
HMG Her Majesty’s Government
IA Information Assurance
IKE Internet Key Exchange
IPsec Internet Protocol Security
IT Information Technology
LAN Local Area Network
MDM Mobile Device Management
o/s operating system
PIN Personal Identification Number
PKI Public Key Infrastructure
PRIME PSN end-state IPsec profile
PRNG Pseudo-Random Number Generator
PSN Public Services Network (UK)
RDP Remote Desktop Protocol (Windows)
SC Security Characteristic
SSH Secure Shell
SSL Secure Sockets Layer
TLS Transport Layer Security
UDP User Datagram Protocol
UK United Kingdom
VPN Virtual Private Network
WAP Wireless Access Point
Page 16
Cisco AnyConnect v3.1
X.509 A standard that covers the components of a PKI. An X.509 certificate is a digital item of data that binds (the value of) a public key to (the name of) an entity such as an individual person or an organisation.
XML eXtensible Markup Language
CESG provided advice and assistance on information security in support of UK Government. Unless otherwise stated, all material published on this website has been produced by CESG and is considered general guidance only. It is not intended to cover all scenarios or to be tailored to particular organisations or individuals. It is not a substitute for seeking appropriate tailored advice.
CESG Enquiries Hubble Road Cheltenham Gloucestershire GL51 0EX Tel: +44 (0)1242 709141 Email: [email protected] © Crown Copyright 2015
