Security Target for Oracle Internet Directory 10g (10.1.4.0.1) i May 2008 Issue 0.9 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Security Evaluations Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 ii Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Author: Peter Goatly. Contributors: David Belfrage and Adam O’Brien. Copyright © 2007, 2008, Oracle Corporation. All rights reserved.This documentation contains proprietary information of Oracle Corporation; it is protected by copyright law. Reverse engineering of the software is prohibited. If this documentation is delivered to a U.S. Government Agen- cy of the Department of Defense, then it is delivered with Restricted Rights and the following legend is applicable: RESTRICTED RIGHTS LEGEND Use, duplication or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in Technical Data and Computer Software (October 1988). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065. The information in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. Oracle Corporation does not warrant that this document is error free. Oracle is a registered trademark and Oracle Database 10g, Oracle Internet Directory 10g and PL/SQL are trademarks or registered trademarks of Oracle Corporation. Other names may be trademarks of their respective owners. Security Target for Oracle Internet Directory 10g (10.1.4.0.1) iii May 2008 Issue 0.9 Contents 1 Introduction...........................................................................1 Identification and CC Conformance ....................................................1 TOE Overview .....................................................................................2 TOE Product Components ...................................................................2 Document Overview ............................................................................2 2 TOE Description ...................................................................5 OID Architecture..................................................................................5 TOE Definition.....................................................................................7 Identification and Authentication.........................................................8 Security Attribute Maintenance .........................................................10 Access Controls..................................................................................10 Auditing..............................................................................................13 Other OID Security Features..............................................................14 3 Security Environment ........................................................17 IT Assets.............................................................................................17 Threats................................................................................................17 Organisational Security Policies ........................................................19 Assumptions.......................................................................................19 4 Security Objectives ............................................................21 TOE Security Objectives....................................................................21 Environmental Security Objectives....................................................22 iv Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 5 IT Security Requirements..................................................25 TOE Security Functional Requirements............................................25 TOE Security Assurance Requirements ............................................33 Security Requirements for the IT Environment.................................33 Minimum Strength of Function .........................................................34 6 TOE Summary Specification .............................................35 TOE Security Functionality...............................................................35 Security Mechanisms and Techniques...............................................39 Assurance Measures ..........................................................................39 7 Protection Profile Claims ..................................................43 PP Reference......................................................................................43 8 Rationale.............................................................................45 Security Objectives Rationale............................................................45 Security Requirements Rationale.......................................................48 TOE Summary Specification Rationale.............................................53 Assurance Measures Rationale ..........................................................58 PP Claims Rationale ..........................................................................58 A References .........................................................................59 B Glossary .............................................................................61 Acronyms...........................................................................................61 Terms .................................................................................................62 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 1 May 2008 Issue 0.9 C H A P T E R 1 Introduction This document is the security target for the Common Criteria evaluation of Oracle In- ternet Directory Release 10g (10.1.4.0.1). Identification and CC Conformance Title: Security Target for Oracle Internet Directory Release 10g (10.1.4.0.1). Target of Evaluation (TOE): Oracle Internet Directory (OID). Release: 10g (10.1.4.0.1). Operating System Platform: Red Hat Enterprise Linux AS Version 4 Update 5. Database Platform: Oracle Database 10g (10.1.0.5.0). CC Conformance: This Security Target conforms to CC Part 2 Extended and CC Part 3. All SFRs in the Security Target are derived from [CC], although FAU_GEN.1 and FPT_SEP.1 have been extended. ALC_FLR.3 is the only augmented assurance criterion specified. Assurance: EAL4 augmented with ALC_FLR.31 . Keywords: Oracle Internet Directory, OID, security target, EAL4. Version of the Common Criteria [CC] used to produce this document: 2.3. 1. ALC_FLR.3 provides assurance at the highest defined component level that there are flaw reme- diation procedures for the TOE by which discovered security flaws can be reported to, tracked and corrected by the developer, and by which corrective actions can be issued to TOE users in a timely fashion. 2 Security Target for Oracle Internet Directory10g (10.1.4.0.1) May 2008 Issue 0.9 TOE Overview Oracle Internet Directory is a general purpose directory service that enables fast retrieval and centralised management of information about dispersed users and network resources. It combines LDAP V3 with the high performance, scalability, robustness, and availability of the Oracle Database 10g server. The security functionality in Oracle Internet Directory includes: • user identification and authentication, with password management; • discretionary access controls - which use Access Control Items held in the direc- tory to define users’ authorisations for directory data access; and • auditing. The Lightweight Directory Access Protocol (LDAP) is a standard, extensible directory access protocol. It is a common language that LDAP clients and servers use to communicate. LDAP Version 3 is defined in [LDAP3]. TOE Product Components The Oracle product which constitutes the TOE is Oracle Internet Directory 10g (10.1.4.0.1). Oracle Internet Directory relies on Oracle Database 10g Enterprise Edition 10.1.0.5.0 for the storage of directory data and uses Oracle Net Services 10.1.0.5.0 for communication interfaces. Oracle Process Manager and Notification Server (OPMN) is installed and configured with every Oracle Application Server installation type and is used to start, monitor and stop OID’s processes in the TOE’s evaluated configuration. [ECD] defines how the TOE product must be installed in the evaluated configuration and defines the requirements for setting up the TOE environment. Document Overview This document consists of a minor update to Issue 1.0 of the Security Target for Oracle Internet Directory 10g (9.0.4.0.1), [ST904], which was used in the previous Common Criteria evaluation of Oracle Internet Directory. The changes for this update are mainly concerned with version number changes, changes to the operating system platforms, a change in the Common Criteria version used for the evaluation from 2.2 to 2.3, and changed references to information in technical publications. Change bars indicate changes since the previous issue of this document. Chapter 2 of this security target provides a high-level overview of the security features of the Oracle Internet Directory. Chapter 3 identifies the assumptions, threats, and security policies of the TOE environment. Chapter 4 describes the security objectives for the TOE and for the environment needed to address the assumptions, threats, and security policies identified in Chapter 3. Chapter 5 identifies the Security Functional Requirements (SFRs), the Security Assurance Requirements (SARs) and the security requirements for the IT environment. Chapter 6 summarises each Security Function (SF) provided by Oracle Internet Directory to meet the security requirements. Chapter Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 3 May 2008 Issue 0.9 7 covers the topic of protection profile conformance by the TOE and Chapter 8 provides the rationale for the security claims made within this security target. Annex A contains a list of references and Annex B provides a glossary of the terms. 4 Security Target for Oracle Internet Directory10g (10.1.4.0.1) May 2008 Issue 0.9 This Page Intentionally Blank Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 5 May 2008 Issue 0.9 C H A P T E R 2 TOE Description This chapter describes the product features that provide security mechanisms and contribute to the security of a system using the Oracle Internet Directory (OID) TOE. The security features of Oracle Internet Directory are explained primarily in [OIDAG, 16] and [OIDAG, 14: Using the Audit Log]. In general, these descriptions correspond to the specifications of IT security functions provided in Chapter 6 of this Security Target. The major elements of the Oracle Internet Directory security architecture are described below, and the TOE is defined in terms of this architecture. The TOE’s mechanisms for access control, identification and authentication, and accountability and auditing are summarised. Additional OID security features that are not addressed by the security functional requirements of Chapter 5 are also briefly discussed. OID Architecture The Oracle Internet Directory architectural components are described in detail in [OIDAG, 3]. Directory A directory stores and retrieves information about organisations, individuals and other resources. LDAP The Lightweight Directory Access Protocol (LDAP) is a standard, extensible directory access protocol. It is a common language that LDAP clients and servers use to com- municate. LDAP Version 3 is defined in [LDAP3]. Oracle Internet Directory Oracle Internet Directory (OID) is a general purpose directory service that enables fast retrieval and centralised management of information about dispersed users and network resources. It combines LDAP V3 with the high performance, scalability, ro- bustness, and availability of the Oracle Database 10g server. The Oracle Internet Di- rectory runs as an application on Oracle Database 10g and uses its Oracle database to hold the directory data. The figure below illustrates a typical TOE configuration by which clients using the 6 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 LDAP protocol and the directory administrator can connect to the Oracle Directory Server. The Oracle Directory Server connects to Oracle Database 10g by using Oracle Net Services. Figure 1: Oracle Internet Directory Architecture The OID components include: • The Oracle Directory Server; • Oracle Directory Replication Server; • Oracle Database 10g Server; • OID Monitor (OIDMON); • OID Control Utility (OIDCTL); • Directory Administration Tools (including Oracle Directory Manager and the command-line administration tools); • Oracle Directory Integration Platform; and • The Delegated Administration Service. OID is not a security product, but is a mechanism for managing enterprise data, includ- ing security data such as user names and passwords for the Oracle 10g product stack. Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 7 May 2008 Issue 0.9 Directory Entries In a directory, a collection of information about an object is called an entry. Each entry is uniquely identified by a distinguished name (DN), which defines exactly where in the directory’s hierarchy the entry resides. Each entry contains information stored in attributes. An object class is a group of at- tributes that define the structure of an entry. Each directory has a Directory-Specific Entry (DSE), which holds information that re- lates to the whole directory, such as the audit log. Oracle Directory Server Instance Each Oracle Directory Server instance services directory requests through a single OID dispatcher process listening at a specific TCP/IP port number. There can be more than one directory server instance on a node, each listening on a different port. One instance comprises one dispatcher process and one or more server processes. By default there is one server process for each instance. Oracle Database 10g OID runs as an Oracle Database 10g application. An Oracle database stores the direc- tory data. The database can reside on the same node as the directory server processes or on a separate node. Oracle Net Connections OID communicates with the database using Oracle Net Services, Oracle’s operating system-independent database connectivity solution. Oracle Net Services is used for all connections between the Oracle Database Server and the OID Control utility (oidctl), the directory server instance, and the OID Monitor (oidmon). LDAP Clients LDAP Clients send LDAP requests to an OID listener/dispatcher process listening for LDAP commands at its port. The following OID command-line tools can be used to send LDAP commands to the TOE in its evaluated configuration: • ldapadd, ldapaddmt, ldapbind, ldapcompare, ldapdelete, ldapmoddn, ldapmodify, ldapmodifymt and ldapsearch. TOE Definition This evaluation covers the security features of Oracle Internet Directory in its capacity as an LDAP directory service. The TOE for this evaluation of the Oracle Internet Directory is defined to be the Oracle Directory Server and the command-line directory administration tools that are essen- tial for the directory to be maintained and administered securely. These command-line tools are the tools to run the Oracle Directory Server instances (oidmon and oid- ctl), the Catalog Management Tool (catalog), the Bulk Operations Tools (bulk- load etc.), the OID Database Password Utility (oidpasswd), and the OID Database Statistics Collection Tool (oidstats). The figure below illustrates the TOE boundary. It shows clients outside of the TOE using the LDAP protocol to send messages over the network to the Oracle Directory Server. The directory administrator can run command-line directory administration tools that are in the TOE. These tools run on the machine that hosts the Oracle Direc- tory Server. 8 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 Figure 2: Oracle Internet Directory TOE Boundary Identification and Authentication Directory User Representa- tion The attributes a directory user entry can have are listed in [OIMUR, 7: User, Group and Subscriber Schema Elements]. Some of the attributes relevant to identification and authentication include: • cn - the user’s common name; and • UserPassword - the password to be used for authenticating the user to OID. User Identification In OID each user has a unique entry identified by a distinguished name (DN). The dis- tinguished name indicates exactly where the entry resides in the directory hierarchy (represented by the Directory Information Tree (DIT)). A DN for a user could look like this: cn=Alice Smith,ou=Server Technologies,c=UK,o=oracle Within a distinguished name, the lowest component is called the relative distinguished name (RDN). In the example above the RDN is cn=Alice Smith. To uniquely identify a particular entry within the overall DIT, the full DN must be used. This allows for user entries for two different Alice Smiths to exist within the same DIT. Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 9 May 2008 Issue 0.9 super user The super user is the administrator for the directory and has full access to all directory information (see [OIDAG, 7: Managing Super Users, Guest Users and Proxy Users]). The actual name and the password for the super user are held in the DSE (by default the super user’s name is orcladmin). Authentication Authentication is the process by which the directory server validates the claimed identity of the user connecting to the directory. OID implements four different levels of directory user authentication: • Anonymous; • Password-based (Simple Authentication); • Certificate-based through Secure Socket Layer (SSL); and • Indirect Authentication. For anonymous authentication, the directory user binds to the directory server without specifying a user name or password. For Password-based (simple) authentication, a user must specify a user name (DN) and password in order to connect to the directory. The password is compared to the password for the user stored in the directory and, if they match, a directory session is created. OID stores a user’s directory password in the UserPassword attribute. Passwords are stored as one-way hashed values. During authentication the client provides a password to the directory server in clear text. The directory server hashes this value using the algorithm specified in the orclCryptoScheme attribute within the DSE (this is set up during installation). If the hashed password values match, the server authenticates the user. For simple authentication passwords are not encrypted when sent over the network. To ensure that no security issues arise from this, [ECD] imposes appropriate security constraints on the TOE’s networking environment. SSL based authentication involves the exchange of certificates issued by trusted certificate authorities. This method of authentication will not be assessed during this evaluation. Indirect authentication can occur through any entity that has credentials in the directory, for example the Delegated Administration Service, or through a middle tier such as a firewall or an application. This type of authentication involves the entity connecting to the directory and then performing directory operations on an end user’s behalf. This is only allowed if the access control policy governing the end user’s directory entry allows the entity to act as a proxy for the end user. Password Policies Password policies enable an administrator to establish and enforce rules for how passwords are created, changed and used within Oracle Internet Directory. When a user attempts to bind to the directory, the directory server ensures that the password meets the requirements specified in the password policy. OID provides a password policy which includes, but is not limited to, the following: • the maximum length of time a given password is valid; • whether a user’s old password value can be used as the new one when the pass- word is being changed; 10 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 • the minimum number of characters a password must contain; • the number of numeric characters required in a password; and • the number of consecutive failed userpassword checks after which a user’s account is locked. The OID password policy is only applicable to the UserPassword attribute, except that the super user is also subject to account lockout after the specified number of consecutive failed password checks. The command-line tool ldapmodify may be used to modify the password policy. More information on password policies may be found in [OIDAG, 19] and [OIDAG, Appendix A: Password Policy Fields in Oracle Directory Manager]. By default the directory enforces the password policy limits as specified in [OIDAG, 19], however, in the evaluated configuration it is necessary that more restrictive password controls are used so that the TOE achieves a high strength of function for the password mechanism (see the Minimum Strength of Function section in Chapter 5). Guidance covering the different password controls, and instructions for modifying profiles to achieve SOF-high, are provided in the TOE’s Evaluated Configuration Document [ECD]. Security Attribute Maintenance These features provide the means for creating and maintaining the security attributes for directory users and directory entries. The mechanisms by which changes to security attributes become effective for a directory session are also included. Access Controls Access controls are used to govern access to a computer’s resources. Access control mechanisms rely on the system having correctly identified and authenticated the user first. In OID access controls use the identity of the user in order to determine the access rights that are to be enforced for that user. Access Control Lists The OID directory holds access control information to define the administrative poli- cies relating to access control. This information is stored as user-modifiable operation- al attributes called access control items (ACIs). A list of such ACI attributes is called an Access Control List (ACL). Access Control Lists (ACLs) are used to protect the directory information within OID and specify what actions can be carried out by which entities on a given resource. They ensure that a user only reads or updates the information for which they have the ap- propriate privileges. When an attempt is made to perform an operation on an object during a session, the directory server is responsible for making sure that the user has the requisite permis- sion to carry out this operation. If not, then the directory server disallows the opera- tion. Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 11 May 2008 Issue 0.9 ACI components Access control information represents the permissions that various entries or subjects have to perform operations on a given object in the directory. An Access Control Item is comprised of 3 ACI components: • The object to which access may be granted (an entry or attribute); • The entities or subjects to which access may be granted; and • The kind of access that may be granted (as listed in [OIDAG, 18: Operations: What Access Are You Granting?]). Access Control Policy Points An Access Control Policy Point (ACP) is an entry for which the orclACI attribute has been given a value. The orclACI attribute values are inherited by a subtree of entries starting with the ACP at the root of the subtree. When a hierarchy of multiple ACPs exist in a directory subtree, a subordinate entry in that subtree inherits the access policies from all of the superior ACPs. The result is an aggregate of all the policies above the entry (where the root of a subtree is considered to be the highest entry in the subtree). The orclACI attribute contains ACL directives that are prescriptive. That is, these directives apply to all entries in the subtree below the ACP where this attribute is de- fined. Entry Level Access Control The orclEntryLevelACI attribute is used for entry level access control. That is, when a policy pertains only to a specific entity. The orclEntryLevelACI at- tribute contains ACL directives that apply to only the entry with which it is associated. Default Access Policies The default access control policy grants the following to both entries and attributes: • Everyone is given access to read, search, write, and compare all attributes in an entry, and selfwrite permissions are unspecified; and • If permission to access an entry is not specified, access is determined at the next highest level at which access is specified. How ACL evaluation works When a user tries to perform an operation on a given object, the directory server de- termines whether the user has the appropriate access permission to perform that oper- ation. If the object is an entry, it evaluates the access systematically for the entry and each of its attributes. Evaluating access to an object can involve examining all the ACI directives for that object. The directory server first examines the ACI directives in the entry-level ACI, or- clEntryLevelACI. It proceeds to the nearest ACP, then considers each superior ACP in succession until the evaluation is complete. The exact steps taken during the evaluation of ACLs, the precedence rules used, and the exceptions to these rules are described in [OIDAG, 18: How ACL Evaluation Works]. Access Control Groups A group entry in OID contains a list of names. It is associated with either the groupOfNames or groupOfUniqueNames object class, which has the object class orclPrivilegeGroup as a subclass. 12 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 Membership in the group is determined by adding DNs to the multi-valued attribute member if the entry belongs to the groupOfNames object class, or uniqueMem- ber if the entry belongs to the groupOfUniqueNames object class. There are two types of access control groups: ACP groups and privilege groups. If an individual is a member of an ACP group, then the directory server simply grants to that individual the privileges associated with that ACP group. ACP groups are as- sociated with the orclACPgroup object class. A Privilege Group is a higher-level access group. This is similar to an ACP group, but it also provides for additional checking beyond a single ACP. If an ACP denies access, an attribute in the user’s entry tells the directory server whether the user being denied is in any privilege group. If so, then this user has additional rights at a higher admin- istration level, and all higher administration levels in the DIT are checked. If the di- rectory finds a higher ACP that grants to the privilege group access to the requested object, then it overrides the denials by the subordinate ACP, and grants access to the user. Privilege groups should only be used when access control at higher levels need the right to override standard controls at lower levels. Privilege Groups are associated with the orclPrivilegeGroup object class. If a user is a member of both an ACP and a Privilege group, then OID evaluates each type of group. It resolves access rights for the privilege group by looking into ACPs higher in the DIT. Managing Access Control It is possible to view and modify access control information using Oracle Directory Manager or the command-line tools. Only the command-line tools are within the scope of this evaluation. Knowledge References Knowledge references (or referrals) allow directory servers to return references to other servers as a result of a directory query (as described in [OIDAG, 3: Knowledge References and Referrals]). There are two kinds of referrals: Smart referral - these are returned to the client when the knowledge reference entry is within the scope of the search. A smart referral points the client to the server that stores the requested information. Default referral - these are returned when the base object is not in the directory, and the operation is performed in a naming context not held locally by the server (because it is on another server). A default referral typically sends the clients to a server that has more knowledge about the directory partitioning arrangement. Knowledge references are represented in the directory as a particular type of entry. They must be associated with the referral object class and the extensibleObject object class. A knowledge reference provides users with a referral containing an LDAP URL. Such URLs are entered as values for the ref attribute. There can be multiple ref attributes for any knowledge reference entry. Similarly, there can be multiple knowledge refer- ence entries in the DIT. Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 13 May 2008 Issue 0.9 Referential Integrity If this feature is enabled, then, whenever an entry in the directory is deleted or its DN is modified, the TOE also updates the groups that refer to that entry. Referential Integ- rity is described in [OIDAG, 12]. Auditing Oracle Internet Directory ensures that relevant information about operations performed by users can be recorded so that the consequences of these operations can later be linked to the user in question, and the user held accountable for his or her actions. OID does this by providing auditing options to ensure that exactly what needs to be audited, as dictated by the application or system security policy, is recorded, but nothing more. This helps to ensure that the size of audit trails remain manageable and that the important records are easily accessible. As the audit log generation is contingent upon events occurring on the server, only the OID directory server itself can create the log entries. In particular, it is not possible to add audit log entries using Oracle Directory Manager or the command-line tools. The audit log is made up of directory entries, where each entry records the audit data for one event. Audit Level To enable auditing, the attribute orclauditlevel in the DSE must be modified to the appropriate level. The value held in this attribute is called the directory’s audit level. A value of 0 for the audit level indicates that no audit log entries are to be generated. By default orclauditlevel has a value of 0, but [ECD] instructs administrators that this value must not be used when the TOE is in its evaluated configuration. Auditable Events A directory super user can request auditing of one or more actions by event type: • Super user login; • Schema element add/replace; • Schema element delete; • Unsuccessful bind; • Access violation; • Directory-specific entry (DSE) modification; • Replication login; • ACL modification; • User Password modification; • Add; • Delete; • Modify; • ModifyDN; and • User login. 14 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 Both successful and unsuccessful events are recorded in the audit log if they are selected, except: • Bind - only unsuccessful binds are audited; and • Access Violation - which is only concerned with attempted access that has been denied by an access control policy. The events from the above list which are to be audited are indicated via settings in the DSE attribute orclauditlevel. Audit Records Oracle Internet Directory auditing results in audit information being written to a direc- tory audit trail. An audit trail entry always includes the following elements when they are meaningful for the audited event: • orclsequence (used to create the name of the audit entry); • orcleventtype (the type of event that occurred); • orcleventtime (the time at which the event occurred in coordinated universal time); • orcluserdn (the identity of the user who caused the directory server to per- form the operation); • orclopresult (the outcome of the operation); • orclauditmessage (a textual message); and • objectclass (contains the preset values top and orclauditoc). Audit Analysis Audit log entries may be searched using ldapsearch commands or Oracle Directory Manager. However, audit log entries do not automatically become part of a search result even though the search filter may satisfy the query criteria. Only a search with cn=auditlog as the base of the search will retrieve audit log entries. Purging the Audit Log bulkdelete may be used to purge audit log objects under the container cn=auditlog. In order to run the bulkdelete tool, the correct password for OID’s database user must be entered. This ensures that only users who are suitably au- thorised administrators can use this tool. Other OID Security Features In addition to the security features described above, Oracle Internet Directory provides features which are related to security but do not directly address any of the functional requirements identified in this Security Target. These features provide significant se- curity capabilities to support robust and reliable directory-based applications. The features described below are not part of the evaluated configuration defined in [ECD], because this evaluation only covers the security features of Oracle Internet Di- rectory in its capacity as a provider of an LDAP directory service. Thus the TOE for this evaluation of OID is defined to be the Oracle Directory Server and the command- line directory administration tools that provide essential features by which the direc- tory can be maintained and administered securely. Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 15 May 2008 Issue 0.9 SSL OID can make sure that no data has been modified, deleted, replayed, or disclosed to unauthorised parties during transmission through the use of Secure Sockets Layer (SSL). The use of SSL by OID will not be part of the configuration for this evaluation since it is assumed that the Directory Server and the Clients used to access it are all within a secure network. Other Directory Compo- nents The following OID components are outside of the scope of this evaluation of OID: • The Directory Replication Service (Replicates LDAP data between Oracle direc- tory servers); • Directory Integration Platform (This feature allows connectivity and synchronisa- tion with other applications and directories, both Oracle-built and otherwise).; and • Server Side plug-in framework, except for use with the referential integrity fea- ture (This plug-in framework enables OID applications to make use of advanced capabilities such as external authentication of directory clients, brokered access, and synchronisation with external relational tables). Directory Administration Tools The following Directory Administration Tools are outside of the scope of this evalu- ation of OID: • Oracle Directory Manager (OID’s standalone, 100% Java on-line administration tool); • The Directory Replication Service Tools (Two tools exist to help administer the directory replication service: the OID reconciliation tool and the human interven- tion queue manipulation tool); • The Delegated Administration Service (This allows delegated administrators, such as non-technical managers, to create and manage both users and groups. It also allows end users to modify and manage their own passwords without needing to know how to run a command-line tool); and • Enterprise Manager Integration (used to start, stop, and monitor OID instances). The command-line tools which can be used to send LDAP messages to a host Oracle Directory Server. It is the Oracle Directory Service, which receives and acts upon those messages, that is the subject of this evaluation. Enterprise Users Enterprise users can be managed via entries in a directory and can be given access to multiple schemas and databases without having to create an account or schema in each database. The standard OID security functions for access control, identification and authentication, and auditing are relied on by Oracle products that implement enterprise user facilities. However, these enterprise user facilities are not part of the OID TOE and are therefore outside the scope of this evaluation. guest user and proxy user The guest user and the proxy user are special users (like the super user). In the evalu- ated configuration defined in [ECD], only the administrator is permitted to know the passwords for these users (which are held in the Directory-Specific Entry). This re- striction is placed to prevent further unidentified users gaining access to the directory, in addition to those using anonymous authentication. The directory administrator must establish Access Control Settings for the directory so that the guest user and the proxy user can only access data that anonymous users 16 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 can access. Please note that the proxy user is a particular special user. This concept is not connect- ed with the concept of a directory session in which a user can act as a proxy for another user if the access control policy governing the second user’s directory entry permits it. APIs The Oracle Internet Directory C API, Java API and PL/SQL API are outside the scope of this evaluation, which focuses on the LDAP service provided by the Oracle Direc- tory Server. Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 17 May 2008 Issue 0.9 C H A P T E R 3 Security Environment This section identifies the IT assets protected by the TOE. It also identifies the threats to those IT assets, the organisational security policies supported by the TOE, and the assumptions for secure usage of the TOE. IT Assets The IT assets requiring protection consist of the information stored within the direc- tory, the confidentiality, integrity or availability of which could be compromised. The primary IT assets are: • Directory objects and the data contained within those directory objects. The secondary IT assets, which support the protection of the primary assets are: • Directory control data used by the directory server to organise and protect the directory objects, and • Directory audit data generated by the directory server during operation. Threats The assumed threats to the TOE security, along with the threat agents which might in- stigate these threats, are specified below. Each threat statement identifies a means by which the TOE and its underlying system might be compromised. These threats will be countered by: a) technical security measures provided by the TOE, in conjunction with b) technical security measures provided by an underlying system, and c) non-technical operational security measures (personnel, procedural and physical measures) in the environment. Threat agents The threat agents are: 18 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 • Persons who are not authorised users of the underlying system (operating system and/or database system and/or network services and/or custom software); • Persons who are authorised users of the TOE; • Persons who are authorised users of the underlying system. System Users may be: a) those persons who are not directory users, or b) those persons who are directory users; • Interruptions to the operation of the TOE resulting from failures of hardware, power supplies, storage media etc, where the source of the threat may be human (e.g. suppliers of equipment) or non-human (e.g. hardware glitches and natural disasters). Threat agents can initiate the types of threats against the directory that are listed be- low. Threats countered by the TOE The threats in this section are countered by technical security measures provided by the TOE, supported by technical security measures provided by the underlying system and non-technical operational security measures in the environment. T.ACCESS Unauthorised Access to the Directory. An outsider or system user who is not (currently) an authorised directory user accesses the directory other than via anonyomous authentication. This threat includes: Impersonation - a person, who may or may not be an authorised directory user, accesses the directory by imper- sonating an authorised directory user (including an authorised user impersonating a different user who has different - possibly more privileged - access). T.DATA Unauthorised Access to Information. An authorised or anony- mous directory user accesses information contained within the directory without the permission of the directory user who has responsibility for ensuring that this data is protected. Note that this threat includes unauthorised access to directory information, residual information held in memory, or storage resources managed by the TOE, or directory control data. T.ATTACK Undetected Attack. An undetected compromise of the directory occurs as a result of an attacker (whether an authorised directory user or not) attempting to perform actions that the individual is not authorised to perform. Note that this threat is included because, whatever countermeasures are provided to address the other threats, there is still a residual threat of a violation of the security policy occuring by attackers attempting to defeat these countermeasures. T.ABUSE.USER Abuse of Privileges. An undetected compromise of the directory occurs as a result of a directory user (intentionally or otherwise) performing actions the individual is authorised to perform. Note that this threat is included because, whatever countermeasures are provided to address the other threats, there is still a residual threat of a violation of the security policy occuring, or the directory being placed at risk, as a result of actions taken by authorised directory users. For example, a directory user may grant access to a Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 19 May 2008 Issue 0.9 directory object they are responsible for to another directory user who is able to use this information to perform a fraudulent action. Note also that the above threat does not extend to highly trusted TOE users (see assumption A.MANAGE below). Threats countered only by the Operating Environ- ment T.OPERATE Insecure Operation. Compromise of the directory may occur because of improper configuration, administration, and/or op- eration of the composite system. T.CRASH Abrupt Interruptions. Abrupt interruptions to the operation of the TOE may cause security related data, such as audit data, to be lost or corrupted. Such interruptions may arise from hu- man error or from failures of software, hardware, power sup- plies, or storage media. T.PHYSICAL Physical Attack. Security-critical parts of the TOE or the un- derlying operating system and/or network services may be subjected to physical attack by unauthorised users which could compromise security. Note that the security critical parts do not include the processing resources which are covered by A.PHYSICAL below. Organisational Security Policies P.ACCESS Access to directory objects is determined by: a) the user identity and access control group memberships associated with the subject attempting the access; and b) directory access control information directives that apply to the object. Assumptions The TOE is dependent upon both technical IT and operational aspects of its environ- ment. TOE Assumptions A.TOE.CONFIG The TOE is installed, configured, and managed in accordance with [ECD] its evaluated configuration. Underlying System Assumptions A.PHYSICAL The processing resources of the TOE and the underlying system are located within controlled access facilities which prevents un- authorised physical access by outsiders, system users and direc- tory users. A.SYS.CONFIG The underlying system (operating system and/or secure network services and database server) is installed, configured, and man- aged in accordance with its secure configuration documentation. A.ACCESS The underlying system is configured such that only the approved group of individuals may obtain access to the system. 20 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 A.MANAGE There will be one or more competent individuals assigned to manage the TOE and the underlying system and the security of the information it contains who can be trusted not to abuse their privileges. A.PEER Any other IT components with which the TOE communicates are assumed to be under the same management control and operate under the same security policy. Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 21 May 2008 Issue 0.9 C H A P T E R 4 Security Objectives This section first describes the IT security objectives of the TOE and the threats and policies they address. Then the requirements on the operational environment needed to support the TOE IT objectives are presented. TOE Security Objectives This section defines the IT security objectives that are to be satisfied by the TOE in combination with the IT security environment. Table 4 in chapter 8 correlates the TOE security objectives to each of the threats and security policies, showing that each threat is countered by at least one IT security objective, and that each security policy is satisfied by at least one IT security objective. O.ACCESS.OBJECTS The TOE must prevent the unauthorised or undesired disclosure, entry, modification, or destruction of direc- tory data, directory objects, and directory control and audit data. O.ACCESS.CONTROL The TOE must allow directory users who are responsible for directory data to control the access to that data by other authorised directory users. O.ACCESS.RESIDUAL The TOE must prevent unauthorised access to residual data remaining in directory objects and resources e.g. memory or reused directory objects following the use of those objects and resources. Note that the above three objectives are concerned with the TOE providing end-users and administrators with the capability of controlling and limiting access by iden- tified individuals, or grouping of individuals, to the data or resources they are re- sponsible for, in accordance with the P.ACCESS security policy. O.I&A.TOE The TOE must provide the means of identifying and au- thenticating users of the TOE. Users who do not identify themselves are to be given sessions with the TOE that only allow access to IT assets that are authorised for ac- 22 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 cess by anonymous users. O.AUDIT The TOE must provide the means of recording security relevant events in sufficient detail to help an administra- tor of the TOE to: a) detect attempted security violations, or potential mis- configuration of the TOE security features that would leave the directory open to compromise; and b) hold individual directory users accountable for any ac- tions they perform that are relevant to the security of the directory. O.ADMIN.TOE The TOE, where necessary in conjunction with the un- derlying system, must provide functions to enable an au- thorised administrator to effectively manage the TOE and its security functions, ensuring that only authorised ad- ministrators can access such functionality. Environmental Security Objectives The following IT security objectives are to be satisfied by the environment in which the TOE is used. O.ADMIN.ENV The underlying system must provide functions to ena- ble an authorised administrator to effectively manage the TOE and its security functions, ensuring that only authorised administrators can access such functionality. In particular, to enable the effective management of the TOE’s audit functions: a) the underlying database server’s functions must include auditing of the startup and shutdown of the TOE’s data- base sessions, and b) the underlying operating system’s functions must in- clude the provision of reliable timestamps for use in au- dit records. O.FILES The underlying system must provide access control mechanisms by which all of the directory related files (including executables, run-time libraries, database files, export files, redo log files, control files, trace files and dump files) and directory related database tables may be protected from unauthorised access. O.SEP The underlying operating system must provide the means to isolate the TOE Security Functions (TSF) and assure that the TSF components cannot be tampered with. The following non-IT security objectives are to be satisfied by procedural and other measures taken within the TOE environment. O.INSTALL Those responsible for the TOE must ensure that: a) The TOE is delivered, installed, managed and op- erated in accordance with the operational docu- Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 23 May 2008 Issue 0.9 mentation of the TOE, and b) The underlying system is installed and operated in accordance with its operational documentation. If the system components are certified they should be installed and operated in accordance with the appropriate certification documentation. Note that [ECD] defines the evaluated configuration of the TOE in detail. It states requirements for the installation and configuration of the underlying system, describes how to install the TOE from its issue media and specifies actions that must be taken by the administrator to ensure the security of the evaluated configuration. Such specified actions may emphasise items already documented in the TOE’s administrator guidance documentation or may provide additional instructions to avoid potential security problems that relate to the evaluated configuration. O.PHYSICAL Those responsible for the TOE must ensure that those parts of the TOE that are critical to the security policy are protected from physical attack. O.AUDITLOG Directory administrators must ensure that audit facilities are used and managed effectively. These procedures shall apply to the directory audit trail and the audit trail for the underlying op- erating system and the database server and/or secure network services. In particular: a) Appropriate action must be taken to ensure continued au- dit logging, e.g. by regular archiving of logs before audit trail exhaustion to ensure sufficient free space; b) Audit logs must be inspected on a regular basis and ap- propriate action should be taken on the detection of breaches of security, or events that are likely to lead to a breach in the future; c) The system clocks must be protected from unauthorised modification (so that the integrity of audit timestamps is not compromised). O.RECOVERY Those responsible for the TOE must ensure that procedures are in place to ensure that, after system failure or other discontinui- ty, recovery without security compromise is obtained. O.TRUST Those responsible for the TOE must ensure that only users, who can be trusted to perform administrative duties with integrity, have privileges which allow them to: a) set or alter the audit trail configuration for the directory; b) modify the contents of the OID audit trail; c) create any user account or modify any user security at- tributes; or d) authorise use of administrative privileges. Note that one user would not normally simultaneously hold all of these privileges. Thus an audit administrator would normally be given the privileges for items a) and b) while a system administrator would be given the privileges for c) and d). 24 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 O.AUTHDATA Those responsible for the TOE must ensure that the authentica- tion data for each user account for the TOE as well as the under- lying system is held securely and not disclosed to persons not authorised to use that account. In particular: a) The media on which the authentication data for the un- derlying operating system is stored shall not be physical- ly removable from the underlying platform by unauthorised users; b) Users shall not disclose their passwords to other individ- uals; c) Passwords generated by the system administrator shall be distributed in a secure manner. O.MEDIA Those responsible for the TOE must ensure that the confiden- tiality, integrity and availability of directory data held on storage media is adequately protected. In particular: a) The on-line and off-line storage media on which direc- tory and security related data ( such as operating sys- tem backups, database backups and transaction logs, and audit trails ) must not be physically removable from the underlying platform by unauthorised users; b) The on-line and off-line storage media must be proper- ly stored and maintained, and routinely checked to en- sure the integrity and availability of the security related-data; c) The media on which directory-related files ( including database files, export files, redo log files, control files, trace files and dump files) have been stored shall be purged prior to being re-used for any non-directory purpose. Table 5 in chapter 8 illustrates how each of the above objectives counters a threat, supports a policy, or maps to a secure usage assumption. Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 25 May 2008 Issue 0.9 C H A P T E R 5 IT Security Requirements TOE Security Functional Requirements Table 1 below lists each Security Functional Requirement (SFR) included in this Se- curity Target. This table identifies which Common Criteria operations (assignment (A), selection (S), refinement (R), and/or iteration (I)) have been applied to the re- quirement relative to Part 2 of [CC]. The text for such completed operations is high- lighted with ITALICISED CAPITAL LETTERS within each requirement. SFRs in Table 1 that are extended relative to Part 2 of [CC] are indicated in this table by the presence of a “*” after the element identifier. The remainder of this section details the functional requirements for this Security Tar- get. Annex B provides definitions for various terms used in the functional require- ments. Note that the phrase “suitably authorised users”, which is used in the SFRs listed below, refers to users who are permitted by the Directory Access Control SFP to perform the operation in question. Such users may or may not be administrators (the terms “suitably authorised user” and “administrator” are covered in the Glossary in Annex B). Table 1: List of Security Functional Requirements Element Name A S R I FAU_GEN.1T.1 * Audit Data Generation X X FAU_GEN.1T.2 * Audit Data Generation X FAU_GEN.2.1 User Identity Association FAU_SAR.1.1 Audit Review X FAU_SAR.1.2 Audit Review FAU_SAR.3.1 Selectable Audit Review X X 26 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 FAU_SEL.1.1 Selective Audit X X FAU_STG.1.1 Protected Audit Trail Storage FAU_STG.1.2 Protected Audit Trail Storage X FAU_STG.4.1 Prevention of Audit Data Loss X X X FDP_ACC.1.1 Subset Access Control X FDP_ACF.1.1 Security Attribute Based Access Control X FDP_ACF.1.2 Security Attribute Based Access Control X FDP_ACF.1.3 Security Attribute Based Access Control X FDP_ACF.1.4 Security Attribute Based Access Control X FDP_RIP.2.1 Full Residual Information Protection X FIA_AFL.1.1 Authentication Failure Handling X FIA_AFL.1.2 Authentication Failure Handling X FIA_ATD.1.1 User Attribute Definition X FIA_SOS.1.1 Verification of Secrets X FIA_UAU.1.1 Timing of Authentication X FIA_UAU.1.2 Timing of Authentication FIA_UID.1.1 Timing of Identification X FIA_UID.1.2 Timing of Identification FMT_MSA.1.1 Management of Security Attributes X X FMT_MSA.3.1 Static Attribute Initialisation X X FMT_MSA.3.2 Static Attribute Initialisation X FMT_MTD.1.1 Management of TSF Data X X X FMT_REV.1.1 Revocation X X FMT_REV.1.2 Revocation X FMT_SMF.1.1 Specification of Management Functions X FMT_SMR.1.1 Security Roles X FMT_SMR.1.2 Security Roles FPT_RVM.1.1 Non-Bypassability of the TSP FPT_SEP.1T.1 * TSF Domain Separation FPT_SEP.1T.2 * TSF Domain Separation FTA_TSE.1.1 TOE Session Establishment X Element Name A S R I Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 27 May 2008 Issue 0.9 Security Audit FAU_GEN.1T.1 The TSF shall be able to generate an audit record of the following auditable events: a) All auditable events for the MINIMUM level of audit AS IDENTIFIED IN TABLE 2 BELOW; and b) ADDITIONAL EVENTS HIGHLIGHTED IN TABLE 2. Table 2: Required Auditable Events Component Event Additional Data FAU_GEN.1T None (i.e. no associated events are required to be audited) None FAU_GEN.2 None None FAU_SAR.1 None None FAU_SAR.3 None None FAU_SEL.1 All modifications to the audit configuration that occur while the audit collection functions are operating IDENTITY OF DIREC- TORY ENTRY MODI- FIED FAU_STG.1 None None FAU_STG.4 None None FDP_ACC.1 None None FDP_ACF.1 UNSUCCESSFUL requests to perform an opera- tion on an object covered by the SFP AND SUC- CESSFUL REQUESTS TO PERFORM AN OPERATION WHICH CHANGES AN OBJECT COVERED BY THE SFP OBJECT IDENTIFIER, REQUESTED ACCESS FDP_RIP.2 None None FIA_AFL.1 The reaching of the threshold for the unsuccess- ful authentication attempts and the actions taken and the subsequent, if appropriate, restoration to the normal state None FIA_ATD.1 None None FIA_SOS.1 Rejection by the TSF of any tested secret AND ACCEPTANCE BY THE TSF OF ANY TESTED SECRET WHEN AN AUTHORISED ADMINIS- TRATOR BINDS TO THE DIRECTORY None FIA_UAU.1 Unsuccessful use of the authentication mecha- nism AND SUCCESSFUL USE OF THE AUTHENTICATION MECHANISM WHEN AN AUTHORISED ADMINISTRATOR BINDS TO THE DIRECTORY None FIA_UID.1 Unsuccessful use of the user identification mech- anism, including the user identity provided, AND SUCCESSFUL USE OF THE USER IDENTIFI- CATION MECHANISM WHEN AN AUTHOR- ISED ADMINISTRATOR BINDS TO THE DIRECTORY, INCLUDING THE USER IDEN- TITY PROVIDED None 28 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 Note that the FAU_GEN.1.1 element defined in Section 3.2 of [CC] Part 2 requires that the TSF shall be able to generate an audit record for the start-up and shutdown of the audit functions. However, auditing takes place throughout the TOE’s directory session according to the value of the audit level at the start of the session. To cater for this, FAU_GEN.1 has been extended as a requirement for this TOE. This extended component has been designated as FAU_GEN.IT. The Security Requirements for the IT Environment defined later in this Chapter include the requirement FAU_GEN.1E.2 for the IT Environment to be able to generate an audit record for the start-up and shut- down of the TOE’s database session (during which any audit records generated by the TOE are stored in a database table). This requirement therefore satisfies the need for the TOE administrator to know the periods of time during which audit records could have been written to the TOE’s audit trail. FAU_GEN.1T.2 The TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and b) Foreachauditeventtype,basedontheauditableeventdefinitions of the functional components included in the SECURITY TARGET AND OTHER AUDIT RELEVANT INFORMATION AS IDENTIFIED IN TABLE 2 ABOVE. Note that FAU_GEN.1T.2 is identical to FAU_GEN.1.2 FAU_GEN.2.1 The TSF shall be able to associate each auditable event with the identity of the user that caused the event. FAU_SAR.1.1 The TSF shall provide SUITABLY AUTHORISED USERS with the capability to read ALL AUDIT INFORMATION from the audit records. FMT_MSA.1 ALL MODIFICATIONS OF THE VALUES OF SECURITY ATTRIBUTES None FMT_MSA.3 ALL MODIFICATIONS OF THE INITIAL VAL- UES OF SECURITY ATTRIBUTES None FMT_MTD.1 None None FMT_REV.1 Unsuccessful revocation of security attributes SECURITY ATTRIBUTE FMT_SMF.1 Specification of Security Management Functions. None FMT_SMR.1 Modifications to the group of users that are part of a role None FPT_RVM.1 None None FPT_SEP.1T None None FTA_TSE.1 Denial of a session establishment due to the ses- sion establishment mechanism None Table 2: Required Auditable Events Component Event Additional Data Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 29 May 2008 Issue 0.9 FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret the information. FAU_SAR.3.1 The TSF shall provide the ability to perform SEARCHES of audit data based on A FUNCTION OF ONE OR MORE ATTRIBUTE VALUES IN THE AUDIT RECORD. FAU_SEL.1.1 The TSF shall be able to include or exclude auditable events from the set of audited events based on the following attributes: a) EVENT TYPE; b) AND NO OTHER ATTRIBUTES. FAU_STG.1.1 The TSF shall protect the stored audit records from unauthorised deletion. FAU_STG.1.2 The TSF shall be able to PREVENT unauthorised modifications to the stored audit records in the audit trail. FAU_STG.4.1 The TSF shall IGNORE AUDITABLE EVENTS if the audit trail is full. Note that the assignment operation for the FAU_STG.4.1 element defined in Section 3.6 of [CC] Part 2 has effectively been completed with “and NO OTHER ACTIONS”. However, a refinement has been applied to omit these words for the sake of clarity. User Data Protection FDP_ACC.1.1 The TSF shall enforce the DIRECTORY ACCESS CONTROL SFP on: a) DIRECTORY USERS; b) DIRECTORY OBJECTS, EACH OF WHICH IS A DIRECTORY ENTRY OR AN ATTRIBUTE OF A DIRECTORY ENTRY; AND c) OPERATIONS PROVIDING THE TYPES OF ACCESS IN THE FOLLOWING LIST: COMPARE SEARCH BROWSE PROXY READ SELFWRITE WRITE ADD DELETE. Note that this SFR identifies the Directory Access Control SFP and defines its scope of control. The rules of this SFP are described in FDP_ACF.1. FDP_ACF.1.1 The TSF shall enforce the DIRECTORY ACCESS CONTROL SFP to objects based on the following: a) THE USER IDENTITY AND ACCESS CONTROL GROUP MEMBERSHIPS ASSOCIATED WITH THE SUBJECT; AND b) THE ACCESS CONTROL INFORMATION (ACI) DIRECTIVES THAT APPLY TO THE OBJECT. FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: a) WHEN A USER TRIES TO PERFORM AN OPERATION ON AN OBJECT, THE TSF SHALL EVALUATE WHETHER ACCESS IS 30 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 ALLOWED BY EXAMINING ALL OF THE ACI DIRECTIVES THAT APPLY TO THAT OBJECT. b) IF THE OBJECT IS AN ENTRY, ACCESS SHALL BE EVALUATED FOR THE ENTRY AND EACH OF ITS ATTRIBUTES. c) THE TSF SHALL EVALUATE ACCESS BY FIRST EXAMINING THE ACI DIRECTIVES IN THE ENTRY-LEVEL ACI FOR THE OBJECT. IT SHALL PROCEED TO THE NEAREST ACCESS CONTROL POINT (ACP), AND SHALL THEN CONSIDER EACH SUPERIOR ACP IN SUCCESSION UNTIL THE EVALUATION IS COMPLETE. d) DURING ACCESS EVALUATION, AN ATTRIBUTE’S STATUS IS “RESOLVED WITH PERMISSION” IF THE REQUIRED ACCESSFORTHEATTRIBUTEHASBEENGRANTEDINTHE ACI; ITS STATUS IS “RESOLVED WITH DENIAL” IF THE REQUIRED ACCESS FOR THE ATTRIBUTE HAS BEEN EXPLICITLY DENIED IN THE ACI; AND ITS STATUS IS “UNRESOLVED” IF NO APPLICABLE ACI HAS YET BEEN ENCOUNTERED FOR THE ATTRIBUTE. e) FOR A SEARCH OPERATION, THE ACCESS EVALUATION SHALL CONTINUE UNTIL ALL THE ATTRIBUTES REACH A RESOLVED STATE. ATTRIBUTES THAT ARE RESOLVED WITH DENIAL SHALL NOT BE RETURNED. f) FOR OPERATIONS OTHER THAN SEARCH, THE ACCESS EVALUATION SHALL STOP IF ACCESS TO THE ENTRY ITSELF IS DENIED OR IF ANY OF THE ATTRIBUTES REACH A RESOLVED WITH DENIAL STATE. IN THIS CASE, ACCESS IS DENIED, OTHERWISE ACCESS IS GRANTED. Note that exceptions to the normal case presented in this SFR are provided by FDP_ACF.1.3. FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: a) DURING ACCESS EVALUATION, A USER SHALL BE GRANTED ACCESS TO WRITE TO THE ATTRIBUTE OF THE USER’S ENTRY THAT HOLDS THE USER’S PASSWORD. b) IF ACCESS TO AN ENTRY IS DENIED OR IF AN ATTRIBUTE REACHES A RESOLVED WITH DENIAL STATE, THEN IF THE USER IS A MEMBER OF A PRIVILEGE GROUP OBJECT, THE ACCESS EVALUATION SHALL CONTINUE AS IF IT IS STILL UNRESOLVED. IF A STATE OF “RESOLVED WITH PERMISSION” IS REACHED THROUGH A GROUP SUBJECT SELECTOR DURING THIS CONTINUING ACCESS EVALUATION , THEN THIS RESOLUTION EFFECTIVELY OVERRIDES THE EARLIER DENIAL STATE. FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following additional rules: NONE. Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 31 May 2008 Issue 0.9 FDP_RIP.2.1 The TSF shall ensure that any previous information content of a resource is made unavailable upon the ALLOCATION OF A RESOURCE TO all objects. Identification and Authen- tication FIA_AFL.1.1 The TSF shall detect when AN ADMINISTRATOR CONFIGURABLE POSITIVE INTEGER WITHIN THE RANGE 1 TO 1063-1 unsuccessful authentication attempts occur related to A USER BINDING TO THE DIRECTORY OR COMPARING A USER’S PASSWORD WITH A PARTICULAR VALUE. Note that an administrator can set the maximum number of unsuccessful authentica- tion attempts to be any positive integer up to 1063-1, but [ECD] defines a specific val- ue to be used in the TOE’s evaluated configuration.. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met or surpassed, the TSF shall LOCK THE USER’S ACCOUNT. FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: a) USER IDENTITY; b) GROUP MEMBERSHIPS; c) AUTHENTICATION DATA. FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet REUSE, LIFETIME, AND CONTENT METRICS AS DEFINED BY A SUITABLY AUTHORISED ADMINISTRATOR. FIA_UAU.1.1 The TSF shall allow VIEWING OF PUBLICLY AVAILABLE DIRECTORY INFORMATION on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. FIA_UID.1.1 The TSF shall allow VIEWING OF PUBLICLY AVAILABLE DIRECTORY INFORMATION on behalf of the user to be performed before the user is identified. FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. Security Management FMT_MSA.1.1 The TSF shall enforce the DIRECTORY ACCESS CONTROL SFP to restrict the ability to MODIFY, DELETE, CREATE the security attributes USER IDENTITY, GROUP MEMBERSHIPS AND AUTHENTICATION DATA FOR USERS, AND ACCESS CONTROL INFORMATION FOR OBJECTS to SUITABLY AUTHORISED USERS. FMT_MSA.3.1 The TSF shall enforce the DIRECTORY ACCESS CONTROL SFP to provide RESTRICTIVE default values for security attributes that are used to enforce the SFP. Note that Section H.2 of Part 2 of [CC] states that FMT_MSA.3.1 applies only to se- curity attributes for objects. 32 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 FMT_MSA.3.2 The TSF shall allow SUITABLY AUTHORISED USERS to specify alternativeinitial values to overridethedefaultvalueswhen anobject or information is created. FMT_MTD.1.1.1The TSF shall restrict the ability to QUERY, CLEAR the AUDIT TRAIL to SUITABLY AUTHORISED USERS. FMT_MTD.1.1.2The TSF shall restrict the ability to MODIFY the SET OF AUDITED EVENTS to SUITABLY AUTHORISED ADMINISTRATORS. FMT_REV.1.1 The TSF shall restrict the ability to revoke security attributes associated with the USERS AND OBJECTS within the TSC to SUITABLY AUTHORISED USERS. FMT_REV.1.2 The TSF shall enforce the rules: a) THE REVOCATION OF A USER’S SECURITY ATTRIBUTES SHALL BE IN EFFECT WHEN THE USER NEXT BINDS FOR A DIRECTORY SESSION; b) THE REVOCATION OF AN OBJECT’S SECURITY ATTRIBUTES SHALL BE IN EFFECT WHEN A USER NEXT ATTEMPTS TO ACCESS THE OBJECT. FMT_SMF.1.1 The TSF shall be capable of performing the following security management functions: a) QUERY, CLEAR the AUDIT TRAIL. b) QUERY, MODIFY the SET OF AUDITED EVENTS. c) MODIFY, DELETE, CREATE the DIRECTORY ACCESS CONTROL SECURITY ATTRIBUTES. Note, refer to FMT_MSA.1.1 for the definition of the DIRECTORY ACCESS CONTROL SECURITY ATTRIBUTES. FMT_SMR.1.1 The TSF shall maintain the roles: a) AUTHORISED ADMINISTRATOR; b) USER. Note that an authorised administrator is a user with the necessary privileges and permissions to perform their administrative duties. The super user for a directory is such an administrator (the terms “super user” and “administrator” are covered in the Glossary in Annex B). FMT_SMR.1.2 The TSF shall be able to associate users with roles. Protection of the TOE Security Functions FPT_RVM.1.1 The TSF shall ensure that TSP enforcement functions are invoked and succeed before each function within the TSC is allowed to proceed. FPT_SEP.1T.1 The TSF shall maintain a security domain for its own execution SO THAT ITS UNDERLYING OPERATING SYSTEM CAN protect it from interference and tampering by untrusted subjects. Note that the FPT_SEP.1.1 element defined in Section 10.11 of CC Part 2 requires that the TSF shall be self-protecting so that an untrusted subject cannot modify or damage the TSF. However, it is the underlying operating system which protects the TSF against untrusted subjects modifying or damaging it during its execution. To ca- ter for this, FPT_SEP.1 has been extended as a requirement for the TOE. This extend- ed component has been designated as FPT_SEP.1T. FPT_SEP.1T.1 is underpinned by the Security Requirement for the IT Environment FPT_SEP.1E.1 which requires the Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 33 May 2008 Issue 0.9 underlying operating system to protect the TSF against untrusted subjects modifying or damaging it during its execution. FPT_SEP.1T.2 The TSF shall enforce separation between the security domains of subjects in the TSC. Note that FPT_SEP.1T.2 is identical to the FPT_SEP.1.2 element defined in section 10.11 of [CC] Part 2. TOE Access FTA_TSE.1.1 The TSF shall be able to deny session establishment based on EXPIRATION OF A USER’S AUTHENTICATION DATA. TOE Security Assurance Requirements The target assurance level is EAL4 as defined in Part 3 of the CC, augmented with ALC_FLR.3. Security Requirements for the IT Environment This section details the security requirements for the IT Environment. Support for SFRs The functional requirements for the IT Environment to support the SFRs defined in this chapter are defined below via elements which have been extended relative to Part 2 of [CC] (using refinements which have been highlighted with ITALICISED CAPI- TAL LETTERS). FAU_GEN.1E.1The DATABASE SYSTEM UNDERLYING THE TSF shall be able to generate an audit record of the following auditable event: a) start-up and shutdown of the TSF’S DATABASE SESSION. FAU_GEN.1E.2 The DATABASE SYSTEM UNDERLYING THE TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components as defined for SFR FAU_GEN.1.2 in [DPP, 5]. Note that FAU_GEN.1T.1, FAU_GEN.1T.2, FAU_GEN.1E.1 and FAU_GEN.1E.2 together meet the requirements of the FAU_GEN.1 component defined in Section 3.2 of [CC] Part 2. FPT_SEP.1E.1 The OPERATING SYSTEM UNDERLYING THE TSF DURING ITS EXECUTION SHALL PROTECT it from interference and tampering by untrusted subjects. Note that FPT_SEP.1T.1 and FPT_SEP.1E.1 together meet the requirements of the FPT_SEP.1.1 element defined in Section 10.11 of [CC] Part 2. FPT_SEP.IT.2 is not relevant to the IT environment and hence there is no equivalent requirement called FPT_SEP.1E.2. 34 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 FPT_STM.1.1 The OPERATING SYSTEM UNDERLYING THE TSF DURING ITS EXECUTION shall be able to provide reliable time stamps for USE BY THE TSF. Note that FPT_STM.1.1 satisfies the dependency of the SFR FAU_GEN.1.2 for the provision of reliable time stamps. Support for security objec- tives The underlying operating system, database server, network services and/or customer software (collectively, the system) shall support the security objectives of the TOE as follows: O.I&A.TOE The operating system and database server shall identify and authen- ticate users prior to providing access to the underlying system. O.ACCESS The system shall provide the access control mechanisms required to support O.FILES. In addition these mechanisms are required to sup- port O.AUTHDATA and O.ADMIN.TOE. O.RECOVERY & O.AUDITLOG The system shall provide backup, restore and other secure recovery mechanisms. Such mechanisms are to be ca- pable of archiving and restoring the directory audit trail. In addition to the above, the system shall provide mechanisms to ensure that the sys- tem security functions are always invoked prior to passing control to the TOE and that non-TOE activity within the system does not interfere with the operation of the TOE. Thus the system shall at least support FPT_RVM.1 and FPT_SEP.1. Also the under- lying operating system platform should perform testing to demonstrate the security as- sumptions made about the underlying abstract machine upon which the TSF relies. Note that an operating system meeting the functional and assurance requirements defined in [CAPP], or equivalent, and a database system meeting the functional and assurance requirements defined in [DPP], or equivalent, will meet the above require- ments (although conformance to [CAPP] and [DPP] is not a mandatory requirement). Minimum Strength of Function The minimum strength of function for the TOE is SOF-High. Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 35 May 2008 Issue 0.9 C H A P T E R 6 TOE Summary Specification TOE Security Functionality This section contains a high-level specification of each Security Function (SF) of the TOE that contributes to satisfaction of the Security Functional Requirements of chapter 5. The specifications cover four major areas: identification and authentication, security attribute maintenance, directory access control and auditing. Note that the phrase “userpassword check”, which is used in the SFs listed below, refers to operations of the TOE which check whether the userpassword attribute of a user entry has a particular value. These are bind operations for which a password has been supplied and compare operations which are acting on the userpassword attribute of a user entry. Table 9 in chapter 8 shows that all the SFRs are satisfied by at least one SF and that every SF is used to satisfy at least one SFR (but note that SFR FDP_ACF.1.4 is not explicitly satisfied by any particular SF because this SFR specifies null functionality). Identification and Authen- tication IA.UID Each directory user is uniquely identified via the distinguished name (DN) of the user’s directory entry. The exception to this is that there are three special users: the super user, the guest user and the proxy user, whose names are held in the root directory- specific entry. The super user is the administrative user for the directory. IA.ASESS If a connection is requested to a directory server and no username and no password are supplied, the TOE will create an anonymous directory session in which only publicly available material authorised for access by anonymous users is accessible. IA.USESS If a user requests to connect to a directory server and that user is configured for simple authentication, then if 36 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 a) the user provides a valid user identifier; and b) the user’s account is not locked; and c) the user provides a password corresponding to the stored password for that user; then the TOE will create a directory session for the user. Note that SF IA.PWDC covers the conditions under which a user’s account can be locked. In particular, if check c) fails, then IA.PWDC a) specifies the condition under which the user’s account may consequently be locked. IA.IDE A subject can only submit requests to a directory server and receive responses (information) from a directory server while the subject is establishing or has established a directory session as perIA.ASESSorIA.USESS.Duringadirectorysession,theTOE will either have access to information recording the fact that this session is anonymous or will have access to the user’s identifier. IA.PSESS If a directory session has been established as per IA.USESS and a connection is requested to the directory server from within this directory session, then if a) the connection request supplies a valid identifier for a user, but supplies no password; and b) the user for the directory session has proxy access to the new user’s entry as per the policy defined in DAC.POL; then the directory session will continue under the new user’s identifier. Note that this SF describes a process by which the directory session’s user can act as a proxy for the user specified in the new connection request. IA.CRUG The TOE will allow only suitably authorised users to create user entries and group entries in the directory. The default values of attributes of such new directory entries are as described in Chapters 8, 11 and 13 of [OIDAG]. IA.PWDC The TOE provides the following configurable controls on user passwords held in the directory: a) the number of consecutive failed userpassword checks before the user account is locked; b) the maximum length of time the same password can be used before it expires and the user’s account becomes locked; c) whether the current password can be reused when the user password attribute of a user entry is modified; d) the number of seconds a user account will remain locked after the specified number of consecutive failed userpassword checks; e) thenumberofsecondsafterwhichthecountofthenumber of consecutive failed userpassword checks is purged from the user entry; and Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 37 May 2008 Issue 0.9 f) a password complexity check performed on values supplied for the user password attribute of a user entry. None of the above list of controls applies to the three special users: the super user, the guest user and the proxy user. The exception is that the value configured for a) gives the number of consecutive failed super user login attempts before the super user account is locked. Note that the TOE provides more configurable controls on user passwords than are listed in the above SF. [OIMUR, 7: Password Policy Schema Elements] defines the full set of such controls. Note also that the TOE does not accept values to be configured for a) if they are negative or greater than 1063-1. IA.PWDCM Configurable controls on user passwords held in the directory are held in a password policy entry. A user can read or modify attributes in a password policy entry only if authorised by the Directory Access Control Policy defined in DAC.POL. Changes to a password policy entry take effect either immediately, or, at the latest, on completion of the startup of the next directory server session. Security Attribute Maintenance SAM.UATT The directory contains a set of security attributes for each directory user, including relative distinguished name, group memberships and password. SAM.EATT The directory contains a set of security attributes for each directory entry. These define the Access Control Information related to the attributes for the entry and the entry itself. The default Access Control Information established when the TOE is installed is covered in the About the Default Configuration section of Chapter 21 of [OIDAG]. SAM.CHPWD The following constraints apply when a suitably authorised user attempts to change the user password attribute of a user entry: a) if the password policy applying to the user entry includes a complexity check function, then the new password is accepted only if it meets the criteria of the complexity check; and b) if the password policy applying to the user entry specifies password reuse constraints and the user attempts to reuse a password, the TOE rejects the change if the reuse constraints are not met. SAM.MODATT A user can create, read, modify or delete security attributes for directory users and directory entries only if authorised by the Directory Access Control Policy defined in DAC.POL. SAM.UEFF A user security attribute will be effective in a directory session only if the user had that attribute at the start of the session. SAM.OEFF An object security attribute will be effective for directory access control in a directory session only if the object had that attribute when the access was attempted. 38 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 Directory Access Control DAC.OBID The TOE ensures that every object created in a directory is uniquely identified in that directory via the distinguished name (DN) of the directory entry. DAC.OBREF The TOE correctly resolves every reference to a directory object, including knowledge references via referrals. DAC.SUA Fordirectoryusers,theTOEenforcesthedirectoryaccesscontrol policy on directory users based on the following subject attributes: a) the identity of the user; and b) anyaccesscontrolgroupmembershipsassociatedwiththe user. DAC.OBA For directory users, the TOE enforces the Directory Access Control Policy defined in DAC.POL on each directory object based on the access control information (ACI) directives that apply to the object. The entries in a directory and the attributes of directory entries constitute the set of directory objects. DAC.POL When a directory user attempts to perform an operation (as listed in FDP_ACC.1.1) on a directory object, access is either granted or denied according to a set of rules (as specified in FDP_ACF.1.2, with exceptions as listed in FDP_ACF.1.3). A user is always allowed to modify the userpassword attribute of that user’s directory entry. Note that further elaboration of the Directory Access Control policy rules is provided in [OIDAG, 18], which gives a practical explanation of the rules and has examples of their use. Note also that, if the Referential Integrity feature is enabled, then, whenever an entry in the directory is deleted or its DN is modified, the TOE also updates the groups that refer to that entry. Referential Integrity is described in [OIDAG, 12]. DAC.SEP The TOE does not allow interference between concurrent directory sessions and the TOE does not perform any actions which could allow untrusted subjects to observe or modify the TOE’s internal data or code. DAC.OR When a new directory object is created, none of the information previously contained in the resource allocated to the object will be capable of being accessed by any directory user. Audit and Accountability AUD.INF When the audit level is non-zero, for every occurrence of an auditable event described in Chapter 14 of [OIDAG], the TOE will write an audit record which holds the following information: date and time of event; type of event; subject identity (which is null if the user is anonymous); and the outcome (success or failure) of the event. In addition: a) when the audit level is changed, the identity of the directory entry modified is recorded; b) when a user attempts to access a directory object, the object identifier and the requested access operation is Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 39 May 2008 Issue 0.9 recorded (provided that the operation was unsuccessful or caused a change to the object); and c) when a security attribute is modified, the attribute name is recorded. AUD.SET The TOE will allow only the super user to set the audit level to specify which types of event are auditable. AUD.ACC The TOE will allow only users authorised by the Directory Access Control Policy defined in DAC.POL to view all records in the audit log in a format suitable for the users to interpret the information. The TOE provides facilities to search for audit records based on a function of one or more attribute values in the records. AUD.DEL The TOE will allow only authorised users to delete audit records from the audit log (such users are authorised by the system administrator, who will inform them of the OID password). No other modification to the audit records is permitted. Note that the bulkdelete command line tool is used to delete audit records from the audit log. This tool requests the user to confirm that they are an authorised administrator by supplying the OID password (which is the password used when OID connects to the Oracle database that holds its directory data, see [OIMUR, 3: oidpasswd] and [OIMUR, 4: bulkdelete]). AUD.FULL If the audit log becomes full, auditable actions are not audited until space has been made available to write further audit records. Note that the TOE attempts to write audit entries to the directory for auditable actions even when the audit log is full. Under such circumstances, the writing of the audit entry will fail and messages are output to report the failure. Security Mechanisms and Techniques A password is used for authentication of TOE users. The TOE password management functions (together called the PWD mechanism) provide a Strength of Function level of SOF-high. Specific SFs supporting the claimed SOF are: • IA.USESS (SOF-High); and • IA.PWDC, SAM.UATT and SAM.CHPWD, which support IA.USESS by pro- viding password management facilities. Assurance Measures The target assurance level is EAL4 augmented with ALC_FLR.3. The following table indicates the documentation that will be supplied to support each security assurance requirement for EAL4 and also the assurance requirement for ALC_FLR.3. No other specific assurance measures are claimed. 40 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 Table 3: Oracle Internet Directory Assurance Measures Component Name Documents ACM_AUT.1 Partial CM Automation Document(s) describing the TOE’s configuration management will be provided. ACM_CAP.4 Generation Support and Acceptance Procs Document(s) describing the TOE’s configuration management will be provided. ACM_SCP.2 Problem Tracking CM Coverage Document(s) describing the TOE’s configuration management will be provided. ADO_DEL.2 Detection of Modifica- tion Document(s) describing the TOE’s delivery proce- dures will be provided. ADO_IGS.1 Installation, Genera- tion, and Startup Document(s) describing the TOE’s installation and configuration will be provided. ADV_FSP.2 Fully Defined External Interfaces Document(s) covering the TOE’s external inter- faces will be provided. ADV_HLD.2 Security Enforcing High-level Design Document(s) describing the TOE’s high level design will be provided. ADV_IMP.1 Subset of the TSF Implementation All of the TOE’s source code will be provided. ADV_LLD.1 Descriptive Low-level Design Document(s) describing the TOE’s low level design will be provided. ADV_RCR.1 Informal Correspond- ence Demonstration A demonstration of correspondence will be provided within the design documentation. ADV_SPM.1 Informal TOE Security Policy Model A document describing the TOE’s Security Policy Model will be provided. AGD_ADM.1 Administrator Guid- ance Administrator guidance document(s) will be pro- vided. AGD_USR.1 User Guidance User guidance document(s) will be provided. ALC_DVS.1 Identification of Secu- rity Measures Document(s) covering the security of the TOE’s development environment will be provided. ALC_LCD.1 Developer Defined Life Cycle Model Document(s) covering the TOE’s life cycle model will be provided. ALC_TAT.1 Well Defined Develop- ment Tools Document(s) covering the TOE’s development tools will be provided. ATE_COV.2 Analysis of Coverage Document(s) describing the TOE’s developer test- ing will be provided. ATE_DPT.1 Testing - High-level Design Document(s) describing the TOE’s developer test- ing will be provided. ATE_FUN.1 Functional Testing Document(s) describing the TOE’s developer test- ing will be provided. AVA_MSU.2 Validation of Analysis Document(s) providing guidance analysis for the TOE will be provided. AVA_SOF.1 Strength of TOE Secu- rity Functions Document(s) analysing the strength of the TOE security functions will be provided. Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 41 May 2008 Issue 0.9 AVA_VLA.2 Independent Vulnera- bility Analysis Document(s) providing vulnerability analysis for the TOE will be provided. ALC_FLR.3 Systematic Flaw Reme- diation Document(s) covering the flaw remediation proce- dures will be provided. Table 3: Oracle Internet Directory Assurance Measures Component Name Documents 42 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 This Page Intentionally Blank Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 43 May 2008 Issue 0.9 C H A P T E R 7 Protection Profile Claims PP Reference This security target does not make any claims about Protection Profile conformance. 44 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 This Page Intentionally Blank Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 45 May 2008 Issue 0.9 C H A P T E R 8 Rationale Security Objectives Rationale This section demonstrates how the identified security objectives are suitable to coun- ter the identified threats and meet the stated security policies. The threats for the TOE and the security policies are stated in Chapter 3. The TOE se- curity objectives and the environmental security objectives are stated in Chapter 4. The table below covers those threats countered by the TOE and the security policies, showing that a threat is countered by at least one TOE security objective, and that each security policy is satisfied by at least one TOE security objective. This table does not cover threats addressed purely by the environment. A YES in the table indicates that the identified TOE security objective is relevant to the identified threat or security pol- icy. Table 4: Correlation of Threats and Policies to TOE Security Objectives Threat/ Policy O.I&A. TOE O.ACCESS O.AUDIT O.ADMIN. TOE T.ACCESS YES YES YES T.DATA YES YES YES T.ATTACK YES YES YES YES T.ABUSE. USER YES YES YES YES P.ACCESS YES YES 46 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 The following table illustrates how each of the environmental security objectives counters a threat, supports a policy or maps to a secure usage assumption. T.ACCESS Rationale T.ACCESS (Unauthorised Access to the Directory) is directly countered by O.I&A.TOE which ensures the TOE can protect the resources of the directory from access by persons not authorised to use the directory. O.I&A.TOE ensures the TOE has the means of authenticating the claimed identity of any user. O.ACCESS.CON- TROL & O.ADMIN.TOE provide support by controlling access to the directory con- trol data and administrative functionality that might otherwise enable circumvention of the directory access controls. O.SEP and O.FILES together pre- vent bypass of the TOE. O.AUTHDATA ensures that authentication data is held securely to stop it being used by unauthorised users to authenticate to the TOE. T.DATA Rationale T.DATA (Unauthorised Access to Information) is directly countered by O.AC- CESS.OBJECTS. O.ACCESS.OBJECTS ensures access is controlled to information contained within specific directory objects. O.ACCESS.RESIDUAL ensures access is prevented to residual information held in memory or reused directory objects. O.I&A.TOE provides support by providing the means of identifying the user attempt- ing to access a directory object. O.ACCESS.CONTROL and O.ADMIN.TOE provide support by controlling access to directory control data and administrative functionality that might otherwise enable circumvention of directory object access controls. O.FILES prevents bypass of the TOE by users gaining direct access to files holding directory data. T.ATTACK Rationale T.ATTACK (Undetected Attack) is countered directly by O.AUDIT which ensures the TOE has the means of recording security relevant events which could be indicative of an attack aimed at defeating the TOE security features. O.I&A.TOE provides support by reliably identifying the user responsible for particular events, where the attacker is Table 5: Mapping of Environmental Security Objectives to Threats, Policy, and Secure Usage Assumptions Environmental Objective Counters Threat Supports Policy Maps to Secure Usage Assumptions O.INSTALL T.OPERATE A.TOE.CONFIG, A.SYS.CONFIG, A.MAN- AGE, A.ACCESS, A.PEER O.PHYSICAL T.PHYSICAL A.PEER, A.PHYSICAL O.AUDITLOG T.ATTACK T.ABUSE.USER A.MANAGE O.RECOVERY T.CRASH A.MANAGE O.TRUST P.ACCESS A.MANAGE, A.ACCESS O.AUTHDATA T.ACCESS P.ACCESS A.MANAGE, A.ACCESS O.MEDIA T.CRASH A.MANAGE O.ADMIN.ENV P.ACCESS A.MANAGE, A.ACCESS O.FILES T.ACCESS, T.ATTACK, T.DATA P.ACCESS A.MANAGE O.SEP T.ACCESS P.ACCESS A.MANAGE Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 47 May 2008 Issue 0.9 an authorised user of the directory. O.ACCESS.CONTROL and O.ADMIN.TOE pro- vide support by controlling access to audit configuration data which only highly trusted individuals must be allowed to view and modify. O.FILES provides support by preventing users gaining direct access to files holding directory audit data to modify evidence of an attack.O.AUDITLOG ensures that audit data is correctly managed by the administrator so that it can be used to detect attacks. T.ABUSE.USER Ration- ale T.ABUSE.USER (Abuse of Privileges) is countered directly by O.AUDIT, which ensures the TOE has the means of recording security relevant events which could be indicative of abuse of privilege by an authorised user of the directory. O.I&A.TOE provides support by reliably identifying the user responsible for par- ticular events, thus ensuring that the user can be held accountable for actions for which he or she is responsible. O.ACCESS.CONTROL and O.ADMIN.TOE pro- vide support by controlling access to audit configuration data which only highly trusted individuals must be allowed to view and modify. O.AUDITLOG ensures that audit data is correctly managed by the administrator so that it can be used to detect users abusing their privileges. T.OPERATE Rationale T.OPERATE (Insecure Operation) is countered directly by O.INSTALL, which ensures that the TOE and its underlying platform are correctly installed, managed and operated. T.PHYSICAL Rationale T.PHYSICAL (Physical Attack) is countered directly by O.PHYSICAL, which protects critical parts of the TOE from physical attack. T.CRASH Rationale T.CRASH (Abrupt Interruptions) is countered by O.MEDIA and O.RECOVERY. These ensure that suitable recovery mechanisms are in place to recover from a crash and that the media used during the crash recovery is able to maintain the con- fidentiality, integrity and availability of the TOE. P.ACCESS Rationale P.ACCESS is satisfied by O.ACCESS.OBJECTS, O.ACCESS.CONTROL, O.ADMIN.TOE & O.ADMIN.ENV, O.TRUST, O.AUTHDATA, O.FILES and O.SEP. O.ACCESS.OBJECTS ensures that the subjects using the TOE are able to control access to the objects for which they are responsible. O.ADMIN.TOE and O.ADMIN.ENV ensure that only authorised administrators can effectively man- age the TOE and its Security Functions. O.FILES, O.TRUST, O.AUTHDATA and O.SEP ensure that components of the TSF cannot be tampered with by unauthor- ised users. Assumptions Rationale This section demonstrates how the security objectives map to the TOE secure us- age assumptions. A.TOE.CONFIG is directly provided by O.INSTALL part a) because [ECD] is part of the operational documentation of the TOE. A.SYS.CONFIG is directly provided by O.INSTALL part b). A.PHYSICAL is directly provided by O.PHYSICAL. A.ACCESS is provided by O.INSTALL, O.TRUST, O.AUTHDATA, and O.AD- MIN.ENV. A.MANAGE is provided by O.TRUST, supported by O.INSTALL, O.AUDIT- 48 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 LOG, O.AUTHDATA, O.MEDIA, O.ADMIN.ENV, O.FILES, O.RECOVERY and O.SEP. A.PEER is provided by O.PHYSICAL & O.INSTALL. Since connected systems will require a physical connection to the TOE to be established they fall into the scope of O.PHYSICAL. Security Requirements Rationale Suitability of Security Requirements The table below correlates the IT security objectives to the SFRs which satisfy them (as indicated by a YES), showing that each IT security objective is satisfied by at least one SFR, and that each SFR satisfies at least one IT security objective. Table 6: Correlation of IT Security Objectives to Security Functional Requirements Requirement O.I&A.TOE O.ACCESS O.AUDIT O.ADMIN.TOE FAU_GEN.1T YES FAU_GEN.2 YES FAU_SAR.1 YES FAU_SAR.3 YES FAU_SEL.1 YES FAU_STG.1 YES FAU_STG.4 YES FDP_ACC.1 YES FDP_ACF.1 YES FDP_RIP.2 YES FIA_AFL.1 YES FIA_ATD.1 YES YES YES YES FIA_SOS.1 YES FIA_UAU.1 YES FIA_UID.1 YES YES FMT_MSA.1 YES YES YES FMT_MSA.3 YES FMT_MTD.1 YES YES FMT_REV.1 YES FMT_SMF.1 YES YES YES YES FMT_SMR.1 YES Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 49 May 2008 Issue 0.9 O.I&A.TOE Suitability O.I&A.TOE is directly provided by FIA_UID.1 and FIA_UAU.1, which provide the means of identifying and authenticating users of the TOE. FIA_AFL.1 per- forms certain actions if a specified number of consecutive unsuccessful authenti- cation attempts is made. FIA_ATD.1 provides a unique set of user attributes for each user while FMT_MSA.1 and FMT_SMF.1 specify controls over the modifi- cation of these attributes. FIA_SOS.1 provides for quality metrics to be applied when new passwords are chosen. FTA_TSE.1 controls the ability to create a direc- tory session by a user. O.ACCESS Suitability O.ACCESS is directly provided by FDP_ACC.1 which defines the access control policy and FDP_ACF.1 which specifies the access control rules. FMT_REV.1 en- forces revocation of security attributes. FDP_RIP.2 ensures prevention of access to information residing in reused storage objects when they are reallocated to another subject. FIA_ATD.1 ensures the security attributes of a user are bound to subjects created to act on his or her behalf. FIA_UID.1 ensures users are identified prior to any TSF-mediated access actions. FPT_RVM.1 ensures that the traditional refer- ence monitor is always invoked prior to access. FMT_MSA.1, FMT_MSA.3 and FMT_SMF.1 provide support for the management of security attributes to control access to directory objects. FPT_SEP.1T assures that objects one subject are ac- cessing cannot be intentionally or inadvertently accessed by another subject with- out a TSF access decision being made for the second subject. O.AUDIT Suitability O.AUDIT is directly provided by FAU_GEN.1T which generates audit records for all security relevant events. FAU_GEN.2 supports the enforcement of individual accountability by ensuring the user responsible for each event can be identified. FIA_ATD.1 provides for the storage of user security attributes. FAU_STG.1 pro- vides permanent storage for the audit trail, FAU_STG.4 provides for mechanisms to deal with full audit trails, while FMT_MTD.1.1.1 and FMT_SMF.1 provide for the protection of that audit trail. FAU_SAR.1 and FAU_SAR.3 provide functions to review the contents of the audit trail, while FAU_SEL.1 provides the ability to select which events are to be audited. O.ADMIN.TOE Suitability O.ADMIN.TOE is directly provided by FMT_SMR.1 and FMT_MTD.1, which provide essential administrative functionality which is restricted to authorised ad- ministrators. FIA_ATD.1 provides support by ensuring that the security attributes of users are associated with the subjects acting on the user’s behalf. FMT_MSA.1 FPT_RVM.1 YES FPT_SEP.1T YES FTA_TSE.1 YES Table 6: Correlation of IT Security Objectives to Security Functional Requirements Requirement O.I&A.TOE O.ACCESS O.AUDIT O.ADMIN.TOE 50 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 and FMT.SMF.1 provide administrative functionality which enforces DAC Secu- rity Function Policy to restrict the ability to modify,delete and create security at- tributes. The rationale above demonstrates the suitability of the TOE security requirements. Suitability of Security Requirements for the IT Environment The Security Requirements for the IT Environment section of Chapter 5 defines a set of SFRs for the IT environment to support the TOE SFRs, and also provides an informal description of requirements for the IT environment to support the security objectives. Most of these requirements are described informally in order not to un- duly limit the environments that can satisfy them. The Support for Security Objec- tives section in Chapter 5 gives a rationale as to why these requirements are needed. The requirements for the IT environment that are described in the Support for Security Objectives section are together sufficient to meet the objectives for the IT environment defined in Chapter 4 (which are O.ADMIN.ENV, O.FILES and O.SEP). The functional security requirements for the IT environment (defined in the Sup- port for SFRs section in Chapter 5) are traced to security objectives for the envi- ronment as follows: • FAU_GEN.1E.1, FAU_GEN.1E.2 and FPT_STM.1.1 map to O.ADMIN.ENV which includes requirements on the underlying database system and operating system for the support of auditing functions. O.ADMIN.ENV’s requirements for auditing correspond to the requirements defined in FAU_GEN.1E.1, FAU_GEN.1E.2 and FPT_STM.1.1. • FPT_SEP.1E.1 maps to O.SEP, which covers requirements for the operating system to provide separation features to protect the TOE. Dependency Analysis The table on the next page demonstrates that all dependencies of functional com- ponents are satisfied. Table 7: Functional Component Dependency Analysis Component Reference Component Dependencies Dependency Reference 1 FAU_GEN.1T FPT_STM.1 See notes 1, 2 and 3 below 2 FAU_GEN.2 FAU_GEN.1T FIA_UID.1 1 15 3 FAU_SAR.1 FAU_GEN.1T 1 4 FAU_SAR.3 FAU_SAR.1 3 5 FAU_SEL.1 FAU_GEN.1T FMT_MTD.1.1.2 1 18 6 FAU_STG.1 FAU_GEN.1T 1 7 FAU_STG.4 FAU_STG.1 6 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 51 May 2008 Issue 0.9 Note 1: The security requirement for the IT environment FPT_STM.1.1 satisfies the dependency of the SFR FAU_GEN.1T.2 for the provision of reliable timestamps (see the section on security requirements for the IT environment in chapter 5). Note 2: The nature of the extensions does not impact on the dependencies as de- fined for the CC Part 2 components from which they are derived. Note 3: The modification of FAU_GEN.1 does not impact its ability to satisfy the dependencies of FAU_GEN.2, FAU_SAR.1, FAU_SEL.1 and FAU_STG.1 - es- pecially given that collectively the TOE and IT environment meet FAU_GEN.1. 8 FDP_ACC.1 FDP_ACF.1 9 9 FDP_ACF.1 FDP_ACC.1 FMT_MSA.3 8 17 10 FDP_RIP.2 - - 11 FIA_AFL.1 FIA_UAU.1 14 12 FIA_ATD.1 - - 13 FIA_SOS.1 - - 14 FIA_UAU.1 FIA_UID.1 15 15 FIA_UID.1 - - 16 FMT_MSA.1 FDP_ACC.1 FMT_SMR.1 8 21 17 FMT_MSA.3 FMT_MSA.1 FMT_SMF.1 FMT_SMR.1 16 20 21 18 FMT_MTD.* FMT_SMF.1 FMT_SMR.1 20 21 See note 4 below 19 FMT_REV.1 FMT_SMR.1 21 20 FMT_SMF.1 - 21 FMT_SMR.1 FIA_UID.1 15 22 FPT_RVM.1 - - 23 FPT_SEP.1T - - See note 2 below 24 FTA_TSE.1 - - Table 7: Functional Component Dependency Analysis Component Reference Component Dependencies Dependency Reference 52 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 Note 4: FMT_MTD.1 has 2 iterations. Its entry in the table above indicates that all FMT_MTD.1 dependencies are satisfied by FMT_SMF.1 and FMT_SMR.1. Dependency analysis of the security assurance requirements EAL4 is a self-contained assurance package and ALC_FLR.3 has no dependencies on any other component. Demonstration of Mutual Support The dependency analysis provided in the table above demonstrates mutual support between functional components, showing that all dependencies required by Part 2 of the CC are satisfied. The following supportive dependencies exist for the TOE to prevent bypassing of and tampering with the SFRs: FIA_UID.1 and FIA_UAU.1 together with FIA_ATD.1 and FMT_MSA.1 provide support to all SFRs which rely on the identification of individual users and their security attributes, namely: FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_SMR.1, FAU_GEN.1, FAU_GEN.2, FMT_MTD.1, FMT_SMF.1, FAU_SAR.1 and FAU_SEL.1. FDP_RIP.2 supports FDP_ACC.1 and FDP_ACF.1 by preventing the bypassing of those SFRs through access to reused to storage objects. FMT_MSA.3 provides support to FDP_ACC.1 and FDP_ACF.1 by ensuring ob- jects are protected by default when newly created. FMT_MSA.1 provides support to FDP_ACC.1, FDP_ACF.1 and FMT_SMF.1 by controlling the modification of object security attributes. FMT_REV.1 provides support to FMT_MSA.1, FDP_ACC.1 and FDP_ACF.1 by enforcing revocation of object security attributes. FAU_STG.1 and FAU_STG.4 support FAU_GEN.1T by providing permanent storage for the audit trail, and dealing with the audit trail full condition. FMT_MTD.1 supports FAU_STG.1, FAU_STG.4 and FMT_SMF.1 by protecting the integrity of the audit trail. FAU_SEL.1 supports FAU_STG.4 by providing the means of limiting the events to be audited, thereby ensuring that the available space for the audit trail is not exhausted more frequently than necessary. FPT_RVM.1 and FPT_SEP.1T support FDP_ACC.1 and FDP_ACF.1 by restrict- ing access to residual data and providing separate domains. FDP.ACC.1 and FDP.ACF.1 support FAU_STG.1 and FMT_SMF.1 by prevent- ing unauthorised modifications to the audit trail. They also support FMT_MSA.1 by preventing unauthorised modifications of directory objects’ security attributes and they protect the TSF data from unauthorised modification to support FMT_MTD.1. Strength of Function Validity The PWD mechanism is the only TOE mechanism that is probabilistic or permu- tational, and has a strength of SOF-high. This strength of function is intended to provide enough protection against straight forward or intentional attack from threat agents having a high attack potential. Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 53 May 2008 Issue 0.9 Assurance Requirements Appropriate The target assurance level is EAL4, augmented with ALC_FLR.3. EAL4 is appro- priate because the TOE is designed for use with an underlying operating system and database server that have been assured to EAL4. ALC_FLR.3 has been included in addition to EAL4 to cause the evaluation of the TOE’s flaw remediation procedures which OID users need to be in place following the release of the TOE. These procedures are required to offer continuing assur- ance to users that OID provides secure storage of and access to the data which is crucial to their enterprise’s success. To meet this requirement, the flaw remediation procedures must offer: • the ability for TOE users to report potential security flaws to Oracle, • the resolution and correction of any flaws with assurance that the corrections introduce no new security flaws, and • the timely distribution of corrective actions to users. ALC_FLR.3 is the ALC_FLR component which is at an appropriate level of rigour to cover these requirements. TOE Summary Specification Rationale This section demonstrates that the TOE Security Functions and Assurance Measures are suitable to meet the TOE security requirements. TOE Security Functions Satisfy Requirements The table below demonstrates that for each SFR the TOE security functions are suitable to meet the SFR, and the combination of TOE security functions work to- gether so as to satisfy the SFR: Table 8: TOE Security Function Suitability and Binding SFR TOE Security Functions Rationale FIA_AFL.1.1 IA.PWDC IA.USESS IA.PWDC provides the configurable control governing the number of failed userpassword check attempts before a user account is locked. IA.USESS detects if this number is reached or exceeded. FIA_AFL.1.2 IA.PWDC IA.USESS IA.PWDC provides the configurable control governing the number of failed userpassword check attempts before a user account is locked. IA.USESS locks the user’s account if this number has been reached or exceeded. FIA_ATD.1.1 SAM.UATT The directory contains the required security attributes for each directory user. FIA_SOS.1.1 IA.PWDC SAM.CHPWD IA.PWDC specifies the configurable metrics user passwords have to meet. SAM.CHPWD allows users to change their own passwords within the configured metrics. 54 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 FIA_UAU.1.1 IA.ASESS IA.IDE If a user does not authenticate, IA.ASESS will allow an anonymous directory session in which only publicly available material is accessible. IA.IDE states that a directory session must be established in order to sub- mit a request to and receive information from a direc- tory server. FIA_UAU.1.2 IA.USESS IA.ASESS IA.IDE IA.IDE states that a directory session must be estab- lished in order to submit a request to and receive infor- mation from a directory server. IA.USESS and IA.ASESS state the conditions for being able to estab- lish a directory session. Authentication is required in order to perform TSF-mediated actions other than accessing publicly available material. FIA_UID.1.1 IA.ASESS IA.IDE If the user supplies no username, IA.ASESS will allow an anonymous directory session in which only publicly available material is accessible. IA.IDE states that a directory session must be established in order to sub- mit a request to and receive information from a direc- tory server. FIA_UID.1.2 IA.USESS IA.ASESS IA.UID IA.PSESS IA.IDE IA.IDE states that a directory session must be estab- lished in order to submit a request to and receive infor- mation from a directory server. If the user supplies no username, IA.ASESS will allow an anonymous direc- tory session in which only publicly available material is accessible. IA.UID, IA.USESS and IA.PSESS state the conditions for being able to establish a directory session with an identified user. Identification is required in order to perform TSF-mediated actions other than accessing publicly available material. FDP_ACC.1.1 IA.UID DAC.OBID DAC.OBREF DAC.SUA DAC.OBA IA.UID enforces that each user is uniquely identified. DAC.OBID and DAC.OBREF ensures that all objects (which are subject to DAC) can be uniquely identified. DAC.SUA and DAC.OBA state that the DAC policy for access operations extends to all subjects and objects. FDP_ACF.1.1 IA.UID DAC.OBID DAC.OBREF DAC.SUA DAC.OBA DAC.POL SAM.UATT SAM.EATT SAM.UEFF SAM.OEFF IA.UID ensures each user has a unique user identity. DAC.OBID and DAC.OBREF ensure that all objects (which are subject to DAC) can be uniquely identified. DAC.SUA and DAC.OBA state that the DAC policy for access operations extends to all subjects and objects. DAC.POL is a statement of the DAC policy. SAM.UATT and SAM.EATT cover the security attributes for users and directory objects (including the identity and group memberships for users and access control informationfor objects). SAM.OEFF and SAM.UEFF state the conditions under which the user and object security attributes are effective for a direc- tory session. Table 8: TOE Security Function Suitability and Binding SFR TOE Security Functions Rationale Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 55 May 2008 Issue 0.9 FDP_ACF.1.2 IA.UID IA.CRUG DAC.OBID DAC.OBREF DAC.POL SAM.UEFF SAM.OEFF DAC.POL fully covers the access control rules defined in FDP_ACF.1.2. DAC.OBID and DAC.OBREF ensure that all objects (which are subject to DAC) can be uniquely identified. IA.CRUG is relevant as I&A data is subject to the DAC policy. IA.UID ensures users are uniquely identified via a DN name. SAM.OEFF and SAM.UEFF state the conditions under which the user and object security attributes are effective for a directory session. FDP_ACF.1.3 DAC.POL SAM.UEFF SAM.OEFF DAC.POL specifies the rules for subjects to gain access to objects. SAM.OEFF and SAM.UEFF state the conditions under which the user and object security attributes are effective for a directory session. FDP_ACF.1.4 N/A This SFR does not mandate any functionality. It is included for compliance with the CC. FDP_RIP.2.1 DAC.OR DAC.OR satisfies FDP_RIP.2.1 directly. FMT_MSA.1. 1 IA.CRUG SAM.MODATT SAM.CHPWD IA.CRUG only allows authorised users to create user entries and group memberships in the directory. SAM.MODATT ensures an authorised user can create, read, modify or delete security attributes for directory users and directory entries. SAM.CHPWD allows authorised users to change user password attributes. FMT_MSA.3. 1 DAC.POL SAM.EATT IA.CRUG SAM.EATT states that default security attributes for directory entries are as per the Default Access Policies defined for the TOE. DAC.POL defines the access control policy. The user security attributes used to enforce directory access control are user identity and group memberships. IA.CRUG states that the default values of attributes of newly created user entries and group entries are as described in Chapters 8, 11 and 13 of [OIDAG]. FMT_MSA.3. 2 DAC.OBA DAC.POL SAM.EATT Unless access to an object has been explicitly granted, as described in DAC.OBA and DAC.POL, no access will be allowed. SAM.EATT states that default secu- rity attributes for directory entries are as per the Default Access Policies defined for the TOE, which cover how authorised users can reset the default secu- rity configuration. FMT_MTD.1. 1.1 AUD.ACC AUD.DEL AUD.DEL states that only an authorised administrator can clear the audit trail. AUD.ACC will allow only authorised users to view records in the audit log. FMT_MTD.1. 1.2 AUD.SET AUD.SET allows only the super user to access the audit level that specifies which events are auditable. FMT_REV.1.1 SAM.MODATT SAM.MODATT ensures that only a suitably author- ised user can create, read, modify or delete security attributes for directory users and directory entries and hence to effectively revoke such attributes. Table 8: TOE Security Function Suitability and Binding SFR TOE Security Functions Rationale 56 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 FMT_REV.1.2 SAM.OEFF SAM.UEFF SAM.OEFF and SAM.UEFF state the conditions under which the user and object security attributes are effective for a directory session and hence when a change to revoke such attributes becomes effective. FMT_SMF.1.1 AUD.ACC AUD.DEL AUD.SET DAC.POL IA.CRUG IA.PWDC IA.PWDCM SAM.CHPWD SAM.MODATT IA.CRUG allows only authorised users to create user entries and group memberships in the directory. SAM.MODATT and DAC.POL ensures an authorised user can create, read, modify or delete security attributes for directory users and directory entries. SAM.CHPWD allows authorised users to change user password attributes. AUD.DEL states that only an authorised administrator can clear the audit trail. AUD.ACC will allow only authorised users to view records in the audit log. AUD.SET allows only the super user to access the audit level that specifies which events are auditable. IA.PWDC and IA.PWDCM ensure that the configurable controls on user passwords (i.e. reuse, lifetime and con- tent metrics for passwords) can only be accessed and updated by suitably authorised users. FMT_SMR.1. 1 IA.UID IA.UID ensures that the TSF maintains the roles of nor- mal user and super user and states that the super user is the administrator for the directory. FMT_SMR.1. 2 IA.UID IA.UID states how directory entries for normal users and the super user are identified. FPT_RVM.1.1 IA.IDE DAC.POL IA.IDE ensures that the TOE always knows who the cur- rent user is. DAC.POL ensures that the directory access control policy enforcement functions are always invoked for this user before an access operation can proceed. FPT_SEP.1T.1 DAC.SEP DAC.SEP ensures that the interactions between different users and the TOE cannot interfere with each other. Additionally there is no way to access the TOE except through the evaluated interfaces described by the TOE security functions. FPT_SEP.1T.2 IA.IDE DAC.SEP IA.IDE ensures that the identity of the user associated with each interaction with the TOE is clear. DAC.SEP ensures that the interactions between different users and the TOE cannot interfere with each other. FTA_TSE.1.1 IA.PWDC IA.USESS IA.PWDC provides the configurable control governing the expiration of a password. IA.USESS prevents the establishment of a directory session if the user’s pass- word has expired. FAU_GEN.1T .1 AUD.INF AUD.SET AUD.SET allows the super user to set which events are to be auditable. Audit records are generated to con- tain information as defined by AUD.INF. FAU_GEN.1T .2 AUD.INF Audit records are generated to contain the required information as defined by AUD.INF. FAU_GEN.2.1 IA.UID AUD.INF IA.UID ensures that each user is uniquely identified. Audit records are generated to contain the required user identity information as defined by AUD.INF. Table 8: TOE Security Function Suitability and Binding SFR TOE Security Functions Rationale Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 57 May 2008 Issue 0.9 The table below shows that all the SFRs are satisfied by at least one SF and that every SF is used to satisfy at least one SFR (but note that SFR FDP_ACF.1.4 is not explicitly satisfied by any particular SF because this SFR specifies null functionality). FAU_SAR.1.1 AUD.ACC AUD.ACC directly satisfies FAU_SAR.1.1 FAU_SAR.1.2 AUD.ACC AUD.ACC directly satisfies FAU_SAR.1.2 FAU_SAR.3.1 AUD.ACC AUD.ACC provides facilities for searching for audit records according to their attribute values. FAU_SEL.1.1 AUD.SET AUD.SET directly satisfies FAU_SEL.1.1. FAU_STG.1.1 AUD.DEL AUD.DEL directly satisfies FAU_STG.1.1. FAU_STG.1.2 AUD.DEL F.AUD.DEL protects audit records from modification. FAU_STG.4.1 AUD.FULL AUD.FULL directly satisfies FAU_STG.4.1 Table 8: TOE Security Function Suitability and Binding SFR TOE Security Functions Rationale Table 9: Mapping of SFs to SFRs FIA FDP FMT FPT FTA FAU AFL.1.1 AFL.1.2 ATD.1.1 SOS.1.1 UAU.1.1 UAU.1.2 UID.1.1 UID.1.2 ACC.1.1 ACF.1.1 ACF.1.2 ACF.1.3 ACF.1.4 RIP.2.1 MSA.1.1 MSA.3.1 MSA.3.2 MTD.1.1.1 MTD.1.1.2 REV.1.1 REV.1.2 SMF.1.1 SMR.1.1 SMR.1.2 RVM.1.1 SEP.1T.1 SEP.1T.2 TSE.1.1 GEN.1T.1 GEN.1T.2 GEN.2.1 SAR.1.1 SAR.1.2 SAR.3.1 SEL.1.1 STG.1.1 STG.1.2 STG.4.1 IA.UID Y Y Y Y Y Y Y IA.ASESS Y Y Y Y IA.USESS Y Y Y Y Y IA.IDE Y Y Y Y Y Y IA.PSESS Y IA.CRUG Y Y Y Y IA.PWDC Y Y Y Y Y IA.PWDCM Y SAM.UATT Y Y SAM.EATT Y Y Y SAM.CHPWD Y Y Y SAM.MODATT Y Y Y SAM.UEFF Y Y Y Y SAM.OEFF Y Y Y Y DAC.OBID Y Y Y DAC.OBREF Y Y Y DAC.SUA Y Y DAC.OBA Y Y Y DAC.POL Y Y Y Y Y Y Y DAC.SEP Y Y DAC.OR Y AUD.INF Y Y Y AUD.SET Y Y Y Y 58 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 Assurance Measures Rationale Table 3 in chapter 6 shows that, for each Security Assurance Requirement, there is an appropriate assurance measure. PP Claims Rationale This security target makes no claims about Protection Profile conformance. AUD.ACC Y Y Y Y Y AUD.DEL Y Y Y Y AUD.FULL Y Table 9: Mapping of SFs to SFRs FIA FDP FMT FPT FTA FAU AFL.1.1 AFL.1.2 ATD.1.1 SOS.1.1 UAU.1.1 UAU.1.2 UID.1.1 UID.1.2 ACC.1.1 ACF.1.1 ACF.1.2 ACF.1.3 ACF.1.4 RIP.2.1 MSA.1.1 MSA.3.1 MSA.3.2 MTD.1.1.1 MTD.1.1.2 REV.1.1 REV.1.2 SMF.1.1 SMR.1.1 SMR.1.2 RVM.1.1 SEP.1T.1 SEP.1T.2 TSE.1.1 GEN.1T.1 GEN.1T.2 GEN.2.1 SAR.1.1 SAR.1.2 SAR.3.1 SEL.1.1 STG.1.1 STG.1.2 STG.4.1 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 59 May 2008 Issue 0.9 A N N E X A References [CAPP] Controlled Access Protection Profile, Version 1.d, NSA, October 1999. [CC] Common Criteria for Information Technology Security Evaluation, Version 2.3, August 2005. [DPP] Database Management System Protection Profile (DBMS PP), Issue 2.1, Oracle Corporation, May 2000. [ECD] Evaluated Configuration for Oracle Internet Directory 10g (10.1.4.0.1), Oracle Corporation. [LDAP3] Lightweight Directory Access Protocol Version 3, Request For Comments (RFC) 2251 of the Internet Engineering Task Force, December 1997, available on the World Wide Web at http://www.ietf.org/rfc.htm [OIDAG] Oracle Internet Directory Administrator’s Guide 10g (10.1.4.0.1), Part No. B15991-01, Oracle Corporation. [OIMUR] Oracle Identity Management User Reference 10g (10.1.4.0.1), Part No. B15998-01, Oracle Corporation. [ST904] Security Target for Oracle Internet Directory 10g (9.0.4), Issue 1.0, Oracle Corporation, November 2004. 60 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 This Page Intentionally Blank Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 61 May 2008 Issue 0.9 A N N E X B Glossary Acronyms ACI Access Control Item ACL Access Control List ACP Access Control Policy Point ASN.1 Abstract Syntax Notation One AVL Adelson, Velskii and Landis (a type of binary tree) BER Basic Encoding Rules (for ASN.1) DAC Directory Access Control DIB Directory Information Base DIT Directory Information Tree DN Distinguished Name DSE Directory-Specific Entry LDAP Lightweight Directory Access Protocol LDIF LDAP Data Interchange Format OID Oracle Internet Directory 62 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 RDN Relative Distinguished Name SF Security Function SFP Security Function Policy SFR Security Functional Requirement SOF Strength of Function TOE Target Of Evaluation TSC TOE Scope of Control TSF TOE Security Functions TSFI TSF Interface TSP TOE Security Policy Terms If a term described below has [CC] written after it, then this term is defined in the IT- security evaluation scheme. All other terms relate to Oracle Internet Directory (OID). [OIDAG, Glossary] covers the full set of terms for OID. The terms used in this docu- ment are described below. Access Control Group A group entry in OID contains a list of names. A user is a member of the group if the user’s DN is held in the group entry’s multi-valued attribute member or uniqueMember. There are two types of access control groups: ACP groups and privilege groups. Access Control Item (ACI) The OID directory holds access control information to define the administrative policies relating to access control. This information is stored as user-modifiable operational attributes called access control items (ACIs). Access Control List (ACL) A list of Access Control Items is called an Access Control List (ACL). Access Control Policy Point (ACP) An Access Control Policy Point (ACP) is an entry for which the orclACI at- tribute has been given a value. The orclACI attribute contains ACL directives that are prescriptive. That is, these directives apply to all entries in the subtree be- low the ACP where this attribute is defined. ACP Group If an individual is a member of an ACP group, then the directory server grants to that individual the privileges associated with that ACP group. Administrator A person who has some or all of the responsibilities of installing, configuring and maintaining a system, establishing and managing user accounts, allocating adminis- Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 63 May 2008 Issue 0.9 trative privileges and permissions to trusted system users and auditing the usage of the system. Such users would be allocated the privileges and permissions necessary to dis- charge their responsibilities. [OIDAG, Part II] describes the basic administrative du- ties for managing an Oracle directory server. The super user for a directory has privileges that enable this user to perform such administrative duties. Attribute Each entry in a directory contains information stored in attributes. Audit Log The OID audit log is made up of directory entries, where each entry records the audit data for one event. Audit Level To enable auditing, the attribute orclauditlevel in the DSE must be modified to the appropriate level. The value held in this attribute is called the directory’s audit lev- el. Authentication Authentication is the process by which the directory server validates the claimed identity of the user connecting to the directory. OID implements four different levels of directory user authentication: Anonymous, Password-based (Simple Authentication), Certificate-based through Secure Socket Layer (SSL), and Indirect Authentication. Authorised Administrator An administrator who has been granted the necessary privileges to perform his or her administrative duties. AVL Tree A binary tree representation that can be used for the entries in a directory. Binding The process of authenticating a user to a directory. Directory A directory stores and retrieves information about organisations, individuals and other resources. Directory Information Base (DIB) The complete set of all information held in a directory. The DIB consists of entries that are related to each other hierarchically in a directory information tree. Directory Information Tree (DIT) A hierarchical tree-like structure consisting of the DNs of the entries. Directory Server Instance Each Oracle Directory Server instance services directory requests through a single OID dispatcher process listening at a specific TCP/IP port number. There can be more than one directory server instance on a node, each listening on a different port. Directory Access Control (DAC) Access control on directory objects based on access control information established by directory users. Distinguished Name (DN) Each entry in a directory is uniquely identified by a distinguished name, which defines exactly where in the directory’s hierarchy the entry resides. It comprises all of the in- dividual names of the parent entries back to the root. Entry In a directory, a collection of information about an object is called an entry. Entry Level Access Control The orclEntryLevelACI attribute is used for entry level access control, for which the policy pertains only to a specific entity. 64 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 Knowledge Reference A knowledge reference (or referral) allows a directory server to return a reference to another server as a result of a directory query. LDAP Client LDAP Clients send LDAP requests to an OID listener/dispatcher process listening for LDAP commands at its port. LDAP Data Interchange Format (LDIF) The set of standards for formatting an input file for any of the LDAP command-line utilities. Lightweight Directory Access Protocol (LDAP) The Lightweight Directory Access Protocol is a standard, extensible directory access protocol. It is a common language that LDAP clients and servers use to communicate. LDAP Version 3 is defined in [LDAP3]. Object An entity within the TSC that contains or receives information and upon which sub- jects perform operations. Objects are visible through the TSFI and are composed of one or more TOE resources encapsulated with security attributes. [CC] Object Class An object class is a group of attributes that define the structure of a directory entry. Oracle Internet Directory (OID) Oracle Internet Directory is a general purpose directory service that enables fast re- trieval and centralised management of information about dispersed users and network resources. LDAP V3 is used to communicate with it and OID is an Oracle Database 10g application. Password Policy A password policy is a set of rules about how passwords can be created, changed and used within Oracle Internet Directory. Platform The combination of software and hardware underlying the TOE. Privilege Group A Privilege Group is a higher-level access control group. This is similar to an ACP group, but it also provides for additional checking beyond a single ACP. Thus, if the directory finds an ACP at a higher level in the DIT that grants the privilege group ac- cess to the requested object, then it overrides any denials by a subordinate ACP and grants the user access to the object. Referral A referral (or knowledge reference) allows a directory server to return a reference to another server as a result of a directory query. Role A predefined set of rules establishing the allowed interactions between a user and the TOE. [CC] Security Attribute Information associated with subjects, users, and/or objects which is used for the en- forcement of the TSP. [CC] Security Domain The set of objects that a subject has the ability to access. Security Function (SF) A part or parts of the TOE which have to be relied upon for enforcing a closely related subset of the rules from the TSP. [CC] Security Function Policy (SFP) The security policy enforced by a SF. [CC] Security Target for Oracle Internet Directory 10g (10.1.4.0.1) 65 May 2008 Issue 0.9 Security Functional Requirement (SFR) A security functional requirement defined in a protection profile or security target. [CC] SOF-high A level of the TOE strength of function where analysis shows that the function pro- vides adequate protection against a deliberately planned or organised breach of TOE security by attackers possessing a high attack potential. [CC] Strength of Function (SOF) A qualification of a TOE security function expressing the minimum efforts assumed necessary to defeat its expected security behaviour by directly attacking its underlying security mechanisms. [CC] Subject An entity within the TSC that causes operations to be performed. [CC] Suitably Authorised Administrator When a particular administrative operation is under consideration, a suitably author- ized administrator is an administrator who has been granted the necessary privileges to perform this operation. Suitably Authorised User When a user is attempting to perform an operation on an object, a suitably authorised user is one who is permitted by the Directory Access Control SFP to perform the op- eration on the object. This policy is described in Chapter 18 of [OIDAG]. super user The super user is the administrator for the directory (but note that it is subject to access control policies as from this release of the TOE, and hence no longer has full access to all directory information by default). The actual name and the password for the su- per user are held in the DSE (by default the super user’s name is orcladmin) System A specific IT installation, with a particular purpose and operational environment [CC] Target Of Evaluation (TOE) The product or system being evaluated. [CC] TOE resource Anything usable or consumable in the TOE. [CC] TOE Scope of Control (TSC) The set of interactions which can occur with or within a TOE and are subject to the rules of the TSP. [CC] TOE Security Functions (TSF) A set consisting of all the software of the TOE that must be relied on for the correct enforcement of the TSP. [CC] TOE Security Policy (TSP) A set of rules that regulate how assets are managed, protected and distributed within a TOE. [CC] TSF Interface (TSFI) A set of interfaces, whether interactive (man-machine interface) or programmatic (ap- plication programming interface), through which TOE resources are accessed, medi- ated by the TSF, or information is obtained from the TSF. [CC] User Any entity (human or machine) outside the TOE that interacts with the TOE. [CC] Userpassword Check This phrase refers to operations of the TOE which check whether the userpass- word attribute of a user entry has a particular value. These are bind operations for which a password has been supplied and compare operations which are acting on the userpassword attribute of a user entry. 66 Security Target for Oracle Internet Directory 10g (10.1.4.0.1) May 2008 Issue 0.9 This Page Intentionally Blank