Australasian Information Security Evaluation Program Certification Report Certificate Number: 2008/47 11 August 2008 Version 1.0 Commonwealth of Australia 2008. Reproduction is authorised provided that the report is copied in its entirety. 11 August 2008 Version 1.0 Page i Amendment Record Version Date Description 0.1 09/07/2008 Internal release for review 0.2 01/08/2008 Extended review. 1.0 11/08/2008 Public release. 11 August 2008 Version 1.0 Page ii Executive Summary 1 SafeNet ProtectDrive v8.1.1 is a software product that is designed to provide protection of sensitive information on laptops and workstations. SafeNet ProtectDrive v8.1.1 is the Target of Evaluation (TOE). 2 This report describes the findings of the IT security evaluation of SafeNet Inc’s SafeNet ProtectDrive v8.1.1, to the Common Criteria (CC) evaluation assurance level EAL 4. The report concludes that the product has met the target assurance level of EAL 4 and that the evaluation was conducted in accordance with the relevant criteria and the requirements of the Australasian Information Security Evaluation Program (AISEP). The evaluation was performed by Logica and was completed in June 2008. 3 With regard to the secure operation of the TOE, the Australasian Certification Authority (ACA) recommends that: a) only use the TOE in its evaluated configuration (the default installation), ensuring that the assumptions concerning the TOE security environment are fulfilled; b) apply encryption to all fixed media storage partitions; c) configure the protected device BIOS to only boot from fixed media and apply a supervisor password to the BIOS; d) enforce access controls over syskey.bin; e) ensure TOE users are also removed from the preboot user database when the user’s Windows account is disabled or removed; f) if a TOE deployment is being managed from ActiveDirectory: i) on the PDSettings\Authentication tab, disable Add Users to ProtectDrive on Successful Windows Logon – this will prevent users being added to the preboot user database that are not managed from ActiveDirectory; and ii) optionally, the administrator may also disable Allow Local User Access on the PDSettings\Authentication tab – this will, however, prevent local recovery functionality if a network connection is not available; iii) be aware of: 1. the hierarchy of various objects: policies set for an individual computer object will override default policies configured on the user objects; and 11 August 2008 Version 1.0 Page iii 2. changes made to a logged on users access rights will not be enforced until that user logs off and on again; g) restrict Windows user passwords to 20 characters; and h) a list of tested removable storage media devices is provided in the supported devices section of the release notes. 4 This report includes information about the underlying security policies and architecture of the TOE, and information regarding the conduct of the evaluation. 5 It is the responsibility of the user to ensure that the TOE meets their requirements. For this reason, it is recommended that a prospective user of the TOE refer to the Security Target at Ref [1], and read this Certification Report prior to deciding whether to purchase the product. 11 August 2008 Version 1.0 Page iv Table of Contents CHAPTER 1 - INTRODUCTION ........................................................................................................1 1.1 OVERVIEW ................................................................................................................................1 1.2 PURPOSE....................................................................................................................................1 1.3 IDENTIFICATION ........................................................................................................................1 CHAPTER 2 - TARGET OF EVALUATION.....................................................................................2 2.1 OVERVIEW ................................................................................................................................2 2.2 DESCRIPTION OF THE TOE ........................................................................................................2 2.3 SECURITY POLICY .....................................................................................................................3 2.4 TOE ARCHITECTURE.................................................................................................................5 2.5 CLARIFICATION OF SCOPE .........................................................................................................6 2.5.1 Evaluated Functionality....................................................................................................6 2.5.2 Non-evaluated Functionality ............................................................................................6 2.6 USAGE.......................................................................................................................................7 2.6.1 Evaluated Configuration ..................................................................................................7 2.6.2 Delivery procedures .........................................................................................................7 2.6.3 Evaluated Product Identification and Verification...........................................................8 2.6.4 Determining the Evaluated Configuration........................................................................8 2.6.5 Documentation..................................................................................................................8 2.6.6 Secure Usage....................................................................................................................8 CHAPTER 3 - EVALUATION ...........................................................................................................10 3.1 OVERVIEW ..............................................................................................................................10 3.2 EVALUATION PROCEDURES.....................................................................................................10 3.3 FUNCTIONAL TESTING.............................................................................................................10 3.4 PENETRATION TESTING ...........................................................................................................12 CHAPTER 4 - CERTIFICATION......................................................................................................12 4.1 OVERVIEW ..............................................................................................................................12 4.2 CERTIFICATION RESULT ..........................................................................................................12 4.3 ASSURANCE LEVEL INFORMATION..........................................................................................12 4.4 RECOMMENDATIONS ...............................................................................................................13 ANNEX A - REFERENCES AND ABBREVIATIONS....................................................................16 A.1 REFERENCES ...........................................................................................................................16 A.2 ABBREVIATIONS......................................................................................................................17 11 August 2008 Version 1.0 Page v Chapter 1 - Introduction 1.1 Overview 6 This chapter contains information about the purpose of this document and how to identify the Target of Evaluation (TOE). 1.2 Purpose 7 The purpose of this Certification Report is to: a) report the certification of results of the IT security evaluation of the TOE, SafeNet ProtectDrive v8.1.1, against the requirements of the Common Criteria (CC) evaluation assurance level EAL 4; and b) provide a source of detailed security information about the TOE for any interested parties. 8 This report should be read in conjunction with the TOE’s Security Target (Ref [1]) which provides a full description of the security requirements and specifications that were used as the basis of the evaluation. 1.3 Identification 9 Table 1 provides identification details for the evaluation. For details of all components included in the evaluated configuration refer to section 2.6.1 Evaluated Configuration. Table 1: Identification Information Item Identifier Evaluation Scheme Australasian Information Security Evaluation Program TOE SafeNet ProtectDrive v8.1.1 Software Version V8.1.1 Security Target Security Target for SafeNet ProtectDrive v8.1.1 dated August 2008 Evaluation Level EAL 4 Evaluation Technical Report Evaluation Technical Report for SafeNet ProtectDrive v8.1.1 dated May 2008 Criteria CC Version 2.3, August 2005. Methodology CCMB-2005-08-004. Conformance CC Part 2 Conformant 11 August 2008 Version 1.0 Page 1 CC Part 3 Conformant Sponsor SafeNet Inc Developer SafeNet Inc Evaluation Facility Logica Chapter 2 - Target of Evaluation 2.1 Overview 10 This chapter contains information about the Target of Evaluation (TOE), including: a description of functionality provided; its architecture components; the scope of evaluation; security policies; and its secure usage. 2.2 Description of the TOE 11 The TOE is called SafeNet ProtectDrive v8.1.1 developed by SafeNet Inc. Its primary role is to provide protection through: encryption of storage devices; pre-boot authentication control; and access control over I/O devices (serial, parallel, floppy drives, CD/DVD drives and removable storage media) that may be attached to the machine on which it is operating. 12 The TOE is a software PC security product that protects the confidentiality of stored information (data at rest) by encrypting the information as it written to the computer’s fixed and removable storage media. 13 The TOE is intended to be installed on machines using Microsoft Windows operating systems. The two operating systems within the scope of the TOE are Windows XP Professional SP2 and Windows 2000 Professional SP4. Additional components are provided to manage the TOE configuration from a Windows Active Directory service. 14 The TOE also provides identification and authentication services at boot that integrate with the underlying Windows identification and authentication services to control a user’s ability to power on a protected device. 15 The main components that comprise the TOE are: • a preboot application that extends the computer BIOS (VX BIOS); • a preboot identification and authentication module (VROM); 11 August 2008 Version 1.0 Page 2 • a transparent encryption driver (TED); • an ActiveDirectory Management Console snap-in; and • a Local Management Console. 16 The VX BIOS controls access to the device during startup and loads the VROM module. 17 The VROM provides a user identification and authentication interface. This interface allows both user name/password and hardware token/PIN to be used. This module can be configured to provide one time authentication (with administrator intervention) via challenge/response strings. 18 The VROM can be configured to block user input in the case of multiple failed authentication attempts – the time period for the lockout and the number of failed attempts that trigger the lockout can be configured by the TOE administrator. 19 On successful user identification and authentication the PC continues its boot sequence. When Windows is successfully loaded, the Windows GINA is replaced by a custom GINA (PDGINA) which can be configured for single sign-on (by using the authentication credentials obtained by the VROM). 20 The TED is loaded as a background service that intercepts input/output (I/O) calls to provide real time encryption and decryption of data as appropriate. The TED also provides administrator configurable access control over some of the PC’s I/O devices and interfaces via the enforcement of read and write permissions (users may have full read/write, read only, or no access to a device). 21 The TOE can be managed locally (via Local Management Console) or remotely (via ActiveDirectory Management Console). This is configurable both during and after the TOE installation. 2.3 Security Policy 22 The TOE Security Policy (TSP) is a set of rules that defines how the information within the TOE is managed and protected. The TSP is defined in the Security Target (Ref [1]). 23 A summary of the TOE security policy is as follows: a) A user has no direct access to objects protected by the TOE, all access to protected objects is performed indirectly via the TOE; b) Users can perform one of two operations on protected objects via the TOE: read from and write to; and c) Access to protected objects (via the TOE) is granted only after a user has authenticated to the TOE. 11 August 2008 Version 1.0 Page 3 24 Three sets of policy govern operations within the TOE: 1 Identification and Authentication Policy: • The TOE Security Function (TSF) retrieves and updates attributes for each user from the same data store that contains the rules; some of these attributes may be changed by Administrators via the Secure Administration TSF; • The TSF requires users to authenticate prior to making any requests; • The TSF handles failed user authentications, based on administrator configured parameters; • The TSF permits one time only user authentication with administrator intervention; • The TSF permits multiple methods of authentication by users; and • The TSF requires users to be identified prior to making any requests. 2 Default System Policy and Default User Policy: • The TSF only accepts actions from a subject acting on behalf of an authenticated and authorised user; • The TSF only accesses object stores that the user making the request is authorised to access; • The TSF reads encrypted objects from an object store using a key for that object store known only to the TSF; • The TSF writes encrypted objects to an object store using a key for that object store known only to the TSF; • The TSF will encrypt an object store using a specified algorithm when required by an administrator; • The TSF will decrypt an object store when required by an administrator; and • The TSF will encrypt a removable object store as requested by an authorised user, using an algorithm preset by an administrator. 3 The following security policy set governs the configuration of the TOE: • The TSF permits only administrative users to configure the rules; 11 August 2008 Version 1.0 Page 4 • The TSF specifies most of the values that administrators can select in configuring the TOE; and • The TSF permits administrators to set what is displayed at startup if the TOE is installed on a system that can run multiple operating systems. 2.4 TOE Architecture 25 The TOE consists of the following major architectural components: a) User Interface Sub-system; b) Remote Administrator Interface Sub-system; c) Local Administrator Interface Sub-system; d) Data Protection / Service Daemons Sub-system; and e) Local Data Store Object (and optional Remote Data Store Object). 26 The Developer’s Architectural Design identifies the 2 modes of the TOE: a) Pre boot; and b) Post boot. 27 The preboot mode of operation provides the preboot authentication and authentication failure lockout functionality. This mode also provides functionality to allow one time authentication in the case of new user introduction to the preboot environment or forgotten password/PIN. These functions generate a random challenge that requires an administrator to generate a valid response (using a supplied administrative tool). 28 In post boot mode, the TOE: a) transparently (not visible to the user) encrypts and decrypts protected fixed media as required; b) provides read and write access control over various classes of I/O device (removable media, floppy disk drive, CD/DVD drive, serial and parallel ports) based on administrator set permissions; c) transparently encrypts and decrypts protected removable storage media as required in accordance with administrator set user permissions; d) synchronises the local data store with the remote data store (if configured for remote configuration) – the data stores contain the 11 August 2008 Version 1.0 Page 5 TOE user names and permissions and the TOE configuration settings; and e) provides authenticated users with Windows administrator rights access to the administrative interface (if configured for local management) to change the TOE settings (grant/deny user permissions, set default encryption algorithm, set allowed encryption algorithms, configure user recovery options, add new users to preboot authentication database). 2.5 Clarification of Scope 29 The scope of the evaluation was limited to those claims made in the Security Target (Ref [1]). 2.5.1 Evaluated Functionality 30 The TOE provides the following evaluated security functionality: a) Cryptographic Support; b) User Data Protection; c) Identification and Authentication; and d) Security Management. 2.5.2 Non-evaluated Functionality 31 Potential users of the TOE are advised that some functions and services have not been evaluated as part of the evaluation. Potential users of the TOE should carefully consider their requirements for using functions and services outside of the evaluated configuration; Australian Government users should refer to Australian Government Information and Technology Security Manual (ACSI 33) (Ref [1]) for policy relating to using an evaluated product in an un-evaluated configuration. New Zealand Government users should consult the Government Communications Security Bureau (GCSB). 32 The functions and services that have not been included as part of the evaluation are provided below: a) Multiple boot partitions; b) Operating systems other than Windows XP Professional or Windows2000 Professional; and c) Single DES CBC and IDEA encryption algorithms; and d) Server edition components. 11 August 2008 Version 1.0 Page 6 2.6 Usage 2.6.1 Evaluated Configuration 33 This section describes the configurations of the TOE that were included within scope of the evaluation. The assurance gained via evaluation applies specifically to the TOE in these defined evaluated configuration(s). Australian Government users should refer to ACSI 33 (Ref [1]) to ensure that configuration(s) meet the minimum Australian Government policy requirements. New Zealand Government users should consult the Government Communications Security Bureau (GCSB). 34 The TOE consists of SafeNet ProtectDrive v8.1.1. The 2 operating systems within the scope of the TOE for installing on client machines are Windows XP Professional SP2 (Build 5.1.2600) and Windows 2000 Professional SP4 (Build 5.00.2195). 35 Note: The default options install the TOE in an evaluated configuration. 2.6.2 Delivery procedures 36 When placing an order for the TOE the following process must be followed by a customer to receive the TOE in a secure manner: a) Submit a purchase order to a SafeNet sales representative; b) SafeNet delivers ProtectDrive v8.1.1 to the customer in tamper- evident shrink-wrapped packaging along with a shipping check- list that identifies the TOE serial number, the original customer purchase order number, and the vendor sales order number. The product is shipped using either a courier or postal service; and a) A license key required to operate the TOE is emailed to the customer. 37 The customer should check that the shrink-wrapped packaging is intact and shows no sign of tampering to confirm secure delivery of the TOE. 38 Purchasers can verify that they have received the evaluated product by doing the following: a) Confirm that the purchase order number and sales order number are consistent with the shipping check-list as well as with the customer’s records; and b) Confirm that the CD delivered is labelled as SafeNet ProtectDrive version 8.1.1. 39 If during delivery of the TOE there is any deviation in the above procedure, it is recommended that the customer contact the vendor for further advice. 11 August 2008 Version 1.0 Page 7 2.6.3 Evaluated Product Identification and Verification 40 The certificate and signature details for the TOE installation are: a) Filesize: 12,937,728 bytes - note this is the actual file size obtained from the file properties (i.e. not the size on disk or size reported by Windows explorer); b) Certificate Serial Number: 46 27 a8 714b 22 b4 61 bd e6 7a de 02 e6 e2 ea; c) Certificate Thumbprint (SHA1):ea bb a2 cc1e 61 86 9a f8 d1 e1 f0 0b a9 14 20 2a 4e 9f 80; d) Message Digest (SHA1): 04 14 20 5c 4d 4d e8 f7 5f ad b2 1a 08 ce 67 2f 19 d3 50 cb 1b 05; and e) Alternatively: Using the Microsoft File Checksum Integrity Verifier utility(http://support.microsoft.com/kb/841290). 2.6.4 Determining the Evaluated Configuration 41 The evaluated TOE configuration used for testing was an out of the box installation with the default settings (as per the Administration Guide (Ref [3]). An administrator can determine the evaluated configuration by physically verifying the settings against the default settings (as per the Administration Guide (Ref [3]). 2.6.5 Documentation 42 It is important that the TOE is used in accordance with guidance documentation in order to ensure the secure usage. The following documentation is provided with the TOE: a) ProtectDrive Enterprise Version Administrator’s Guide Chapter 5, Deploying ProtectDrive (Ref [3]); and b) ProtectDrive Enterprise Version Administrator’s Guide Appendix E, Additional Guidance Regarding Security (Ref [4]). 43 There are a number of configuration options available during the installation of the TOE. 44 The default options install the TOE in an evaluated configuration. 2.6.6 Secure Usage 45 The evaluation of the TOE accounted for certain assumptions about its operational environment. These assumptions must hold in order to ensure the security objectives of the TOE are met. 46 The following assumptions were made: 11 August 2008 Version 1.0 Page 8 a) Administrators: i) are trusted not to compromise security; ii) are trusted not to abuse their authority; iii) are competent to manage the TOE and security of the information it protects; iv) follow the policies and procedures defined in the TOE documentation for the secure administration of the TOE; and v) follow password management policies to ensure users comply with password policies; b) Authorised users: i) cooperate with those responsible for managing the TOE to maintain TOE security; ii) can be trusted and are not considered to be hostile; and iii) are fallible and can make errors or act in ways that may compromise security; c) If the computer containing information protected by the TOE is connected to a network and an authorised user is authenticated to the TOE, then information protected by the TOE may be accessible from the network. To prevent compromise of protected information from a network connection the network must protect information to at least the same degree as that provided by the TOE; d) It is assumed that: i) if the computer, on which the TOE is installed, is connected to a network that the network operates under the same security policy constraints as the TOE; ii) if the computer, on which the TOE is installed, is a part of a network domain then the domain operates under the same security policy constraints at the TOE; and iii) unauthorised physical tampering with the computer, on which the TOE is active, is clearly evident to users. e.g. the equipment is fitted with tamper evident seals (or similar devices) that provide a clear indication if the equipment has been physically tampered with. 47 The TOE is not designed to comply with any specific organisations security policies. 11 August 2008 Version 1.0 Page 9 Chapter 3 - Evaluation 3.1 Overview 48 This chapter contains information about the procedures used in conducting the evaluation and the testing conducted as part of the evaluation. 3.2 Evaluation Procedures 49 The criteria against which the Target of Evaluation (TOE) has been evaluated are contained in the Common Criteria for Information Technology Security Evaluation (Refs [5], [6], [7]). The methodology used is described in the Common Methodology for Information Technology Security Evaluation (CEM) (Ref [8]). The evaluation was also carried out in accordance with the operational procedures of the Australasian Information Security Evaluation Program (AISEP) (Refs [9], [10], [11], [12]). In addition, the conditions outlined in the Arrangement on the Recognition of Common Criteria Certificates in the field of Information Technology Security (Ref [13]) were also upheld. 3.3 Functional Testing 50 To gain confidence that the developer’s testing was sufficient to ensure the correct operation of the TOE, the evaluators analysed the evidence of the developer’s testing effort. This analysis included examining: test coverage; test plans and procedures; and expected and actual results. The evaluators drew upon this evidence to perform a sample of the developer tests in order to verify that the test results were consistent with those recorded by the developers. 51 In addition, a number of independent tests were conducted by the evaluators. These were split into the following 3 categories: a) Identification and Authentication i) Confirm that a valid user with the associated valid password can be authenticated by the TOE. Also confirm that a valid user with a valid hardware token and PIN are authenticated. ii) Confirm that a valid user presenting an invalid password is not authenticated by the TOE. Also confirm that a valid user with valid hardware token and invalid PIN are rejected. iii) Confirm that an invalid user is not authenticated by the TOE. iv) Confirm that a delay is invoked after a thresh-hold of failed authentication attempts is exceeded – this will be tested against multiple failed attempts against one user and also against multiple failed attempts with a series of user ids (valid and invalid). 11 August 2008 Version 1.0 Page 10 v) Confirm that the delay introduced by the TOE is consistent with that specified in (Ref [1]). vi) Confirm the operation of the password fallback/password recovery functionality. b) Secure Administration i) Confirm that a user without administrator rights cannot change the TOE configuration via the Windows Management Instrumentation (WMI – includes the AD snapin and the local management console). ii) Determine if a user without administrator rights cannot change the TOE configuration via the supplied command line utilities. iii) Confirm that a user with administrator rights can change the configuration of the TOE (including add/change rights/remove users, change encryption algorithms, encrypt and decrypt fixed storage media) using the WMI or command line utilities. c) Data Protection i) Confirm that the data at rest is obfuscated. ii) Verify the correctness of encryption algorithms used (this was performed during the DEA visit under the supervision of the evaluators using NIST standard test vectors comprising sets of known plaintext, known key, expected cipher text). iii) Confirm that an authenticated user can read from and write to the protected storage media. iv) Confirm that an authenticated user can access removable storage and IO devices in accordance with the defined access permissions for that user. This will be performed by: a. allowing read/write access; b. allowing read/blocking writes; c. blocking read/allowing writes; and d. blocking read/write access. v) These tests will be repeated for each of the objects that can be controlled i.e. CD/DVD drive, serial port, parallel port, removable media, floppy diskettes. vi) Attempt to recover information from a protected device/medium. 11 August 2008 Version 1.0 Page 11 3.4 Penetration Testing 52 The evaluators examined the developer’s vulnerability analysis to verify that, for every identified vulnerability, a rationale was given why the vulnerability is not exploitable in the intended environment of the TOE. Based on the evaluators examination of the developer’s vulnerability analysis, the evaluators developed penetration tests to: a) disprove the developer’s vulnerability analysis; and b) determine the susceptibility of the TOE to vulnerabilities identified by the developer. 53 After the completion of testing, the evaluators were able to determine that the TOE, in its intended environment, has demonstrated resistance to low attack potential penetration attackers. Chapter 4 - Certification 4.1 Overview 54 This chapter contains information about the result of the certification, an overview of the assurance provided by the level chosen, and recommendations made by the certifiers. 4.2 Certification Result 55 After due consideration of the conduct of the evaluation as witnessed by the certifiers, and of the Evaluation Technical Report (Ref [14]), the Australasian Certification Authority certifies the evaluation of SafeNet ProtectDrive v8.1.1 performed by the Australasian Information Security Evaluation Facility, Logica. 56 Logica has found that SafeNet ProtectDrive v8.1.1 upholds the claims made in the Security Target (Ref [1]) and has met the requirements of the Common Criteria (CC) evaluation assurance level EAL 4. 57 Certification is not a guarantee of freedom from security vulnerabilities. 4.3 Assurance Level Information 58 EAL4 provides assurance by an analysis of the security functions, using a functional and complete interface specification, guidance documentation, the high-level and low-level design of the TOE, and a subset of the implementation, to understand the security behaviour. Assurance is additionally gained though an informal model of the TOE security policy. 59 The analysis is supported by independent testing of the TOE security functions, evidence of developer testing based on the functional 11 August 2008 Version 1.0 Page 12 specification and high-level design, selective independent confirmation of the developer test results, strength of function analysis, evidence of a developer search for obvious vulnerabilities, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a low attack potential. 60 EAL4 also provides assurance though the use of development environment controls and additional TOE configuration management including automation, and evidence of secure delivery procedures. 4.4 Recommendations 61 Not all of the evaluated functionality present in the TOE may be suitable for Australian and New Zealand Government users. For further guidance, Australian Government users should refer to ACSI 33 (Ref [1]) and New Zealand Government users should consult the Government Communications Security Bureau (GCSB). 62 In addition to ensuring that the assumptions concerning the operational environment are fulfilled and the guidance document is followed (Refs [3], [4]), the ACA also recommends that users and administrators: a) Configure Hardware. i. Commercial off the shelf (COTS) tools are available that allow an attacker to boot into an environment where the TOE is not running. This would allow an attacker access to any unencrypted media on the protected device. To reduce the impact and likelihood of success for this type of attack, it is recommended that: 1. TOE administrators apply encryption to all fixed media storage partitions to reduce the impact of this type of attack; and 2. TOE administrators configure the protected device BIOS to only boot from fixed media and apply a supervisor password to the BIOS. b) Enforce access controls over syskey.bin. i. An organisation deploying the TOE must ensure that the file syskey.bin is included in the applicable key management plans and access to any copies of the file must be restricted (physically and logically). This file can optionally be encrypted using the TOE utilities to facilitate storage on a shared folder during remote installations; and ii. The TOE may be installed on multiple hosts using the same syskey.bin/syskey.ske. This advantages of this approach are to 11 August 2008 Version 1.0 Page 13 reduce the key management effort (by reducing the amount of key material to manage) and to allow sharing of encrypted removable media between hosts (see Controlling Removable Storage Media below). The risk with this approach is that all hosts installed using a single syskey.bin will affected in the event of this file being compromised. c) Disable/Remove TOE Users. i. TOE administrators ensure that TOE users are also removed from the preboot user database when the user’s Windows account is disabled or removed. d) Manage TOE users from a server. i. If a TOE deployment is being managed from ActiveDirectory, the following settings should be applied: 1. On the PDSettings\Authentication tab, disable Add Users to ProtectDrive on Successful Windows Logon – this will prevent users being added to the preboot user database that are not managed from ActiveDirectory; and 2. Optionally, the administrator may also disable Allow Local User Access on the PDSettings\Authentication tab – this will, however, prevent local recovery functionality if a network connection is not available. ii. When managing users from ActiveDirectory – be aware of the hierarchy of the various objects: policies set for an individual computer object will override default policies configured on the user objects; and iii. Changes made to a logged on user’s access rights will not be enforced until that user logs off and on again (even if periodic configuration updates are set in ActiveDirectory). The local management console will display the new rights and permissions for the user when the configuration update is applied, but the user will need to logoff and logon again before those configuration changes are enforced. e) Control Removable Storage Media. i. Only devices listed in the supported devices section of the release notes (available on the installation CD delivered to the customer) are used within the environment, or configure the TOE to deny access to unencrypted media – dependent on a risk assessment. f) Restrict Windows User Passwords to 20 Characters. 11 August 2008 Version 1.0 Page 14 i. ProtectDrive only allows a maximum of 20 character passwords. Therefore to ensure synchronisation with Windows allow a maximum password length of 20 characters for users; This advice is repeated in the Administrator Guide and release notes for v8.2.1 of ProtectDrive but due to the timing of the discovery, is not present in the guidance for v8.1.1 (the TOE). g) Use only in its evaluated configuration. i. Ensure that the assumptions concerning the TOE security environment, and organisational security policies (Ref [1]) are fulfilled. 11 August 2008 Version 1.0 Page 15 Annex A - References and Abbreviations A.1 References [1] Security Target for SafeNet ProtectDrive v8.1.1 dated August 2008 [2] Australian Government Information and Communications Technology Security Manual (ACSI 33), March 2005, Defence Signals Directorate, (available at www.dsd.gov.au). [3] ProtectDrive Enterprise Version Administrator’s Guide Chapter 5, Deploying ProtectDrive User Documentation. [4] ProtectDrive Enterprise Version Administrator’s Guide Appendix E, Additional Guidance Regarding Security [5] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model (CC), Version 2.3, August 2005, CCMB- 2005-08-001 [6] Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Requirements (CC), Version 2.3, August 2005, CCMB-2005-08-002 [7] Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Requirements (CC), Version 2.3, August 2005, CCMB-2005-08-003 [8] Common Methodology for Information Technology Security Evaluation (CEM), Version 1.0, August 2005, CCMB-2005-08-004 [9] AISEP Publication No. 1 – Program Policy, AP 1, Version 3.1, 29 September 2006, Defence Signals Directorate. [10] AISEP Publication No. 2 – Certifier Guidance, AP 2. Version 3.0, 21 February 2006, Defence Signals Directorate. [11] AISEP Publication No. 3 – Evaluator Guidance, AP 3. Version 3.1, 29 September 2006, Defence Signals Directorate [12] AISEP Publication No. 4 – Sponsor and Consumer Guidance, AP 4. Version 3.1, 29 September 2006, Defence Signals Directorate [13] Arrangement on the Recognition of Common Criteria Certificates in the field of Information Technology Security, May 2000 [14] Evaluator Technical Report for SafeNet ProtectDrive v8.1.1 dated 20 June 2008, Logica 11 August 2008 Version 1.0 Page 16 A.2 Abbreviations AISEF Australasian Information Security Evaluation Facility AISEP Australasian Information Security Evaluation Program CC Common Criteria CEM Common Evaluation Methodology DSD Defence Signals Directorate EAL Evaluation Assurance Level ETR Evaluation Technical Report GCSB Government Communications Security Bureau PP Protection Profile SFP Security Function Policy SFR Security Functional Requirements ST Security Target TOE Target of Evaluation TSF TOE Security Functions TSP TOE Security Policy 11 August 2008 Version 1.0 Page 17