DbProtect AppDetective 2009.1 R2 Security Target Version 1.0 05/16/2012 Prepared for: Application Security, Inc. 350 Madison Avenue, 6th Floor New York, NY 10017 Prepared By: Science Applications International Corporation Common Criteria Testing Laboratory 6841 Benjamin Franklin Drive Columbia, MD 21046 Security Target Version 1.0, 05/16/2012 2 1. SECURITY TARGET INTRODUCTION...........................................................................................................4 1.1 SECURITY TARGET, TOE AND CC IDENTIFICATION........................................................................................4 1.2 CONFORMANCE CLAIMS.................................................................................................................................4 1.3 CONVENTIONS ................................................................................................................................................5 2. TOE DESCRIPTION ..........................................................................................................................................6 2.1 TOE OVERVIEW .............................................................................................................................................6 2.2 TOE ARCHITECTURE......................................................................................................................................8 2.2.1 Physical Boundaries ..............................................................................................................................9 2.2.2 Logical Boundaries..............................................................................................................................10 2.3 TOE DOCUMENTATION ................................................................................................................................13 3. SECURITY ENVIRONMENT.........................................................................................................................14 3.1 ORGANIZATIONAL POLICIES.........................................................................................................................14 3.2 THREATS ......................................................................................................................................................14 3.3 ASSUMPTIONS ..............................................................................................................................................14 4. SECURITY OBJECTIVES ..............................................................................................................................16 4.1 SECURITY OBJECTIVES FOR THE TOE...........................................................................................................16 4.2 SECURITY OBJECTIVES FOR THE TOE OPERATIONAL ENVIRONMENT...........................................................16 5. IT SECURITY REQUIREMENTS..................................................................................................................18 5.1 EXTENDED SECURITY FUNCTIONAL REQUIREMENTS....................................................................................18 5.1.1 DB Scan Data Review (ADP_RDR).....................................................................................................18 5.1.2 DB Scan Data Collection and Analysis (ADP_SCN)...........................................................................18 5.1.3 DB Scan Credential Protection (ADP_PRT).......................................................................................19 5.2 TOE SECURITY FUNCTIONAL REQUIREMENTS .............................................................................................19 5.2.1 DB Scan (EXP) (ADP).........................................................................................................................20 5.2.2 Security audit (FAU)............................................................................................................................20 5.2.3 Identification and authentication (FIA) ...............................................................................................21 5.2.4 Security management (FMT) ...............................................................................................................21 5.3 TOE SECURITY ASSURANCE REQUIREMENTS...............................................................................................22 5.3.1 Development (ADV).............................................................................................................................22 5.3.2 Guidance documents (AGD)................................................................................................................24 5.3.3 Life-cycle support (ALC) .....................................................................................................................25 5.3.4 Tests (ATE) ..........................................................................................................................................26 5.3.5 Vulnerability assessment (AVA)...........................................................................................................27 6. TOE SUMMARY SPECIFICATION..............................................................................................................29 6.1 DATABASE DISCOVERY AND SCANNING.......................................................................................................29 6.2 SECURITY AUDIT..........................................................................................................................................31 6.3 IDENTIFICATION AND AUTHENTICATION ......................................................................................................31 6.4 SECURITY MANAGEMENT.............................................................................................................................32 7. PROTECTION PROFILE CLAIMS...............................................................................................................34 8. RATIONALE.....................................................................................................................................................35 8.1 SECURITY OBJECTIVES RATIONALE..............................................................................................................35 8.1.1 Security Objectives Rationale for the TOE and Operational Environment .........................................35 8.2 SECURITY REQUIREMENTS RATIONALE........................................................................................................39 8.2.1 Security Functional Requirements Rationale.......................................................................................39 8.3 SECURITY ASSURANCE REQUIREMENTS RATIONALE....................................................................................41 8.4 REQUIREMENT DEPENDENCY RATIONALE....................................................................................................41 8.5 TOE SUMMARY SPECIFICATION RATIONALE................................................................................................42 Security Target Version 1.0, 05/16/2012 3 LIST OF TABLES Table 1 TOE Security Functional Components ......................................................................................................20 Table 2 EAL 2 augmented with ALC_FLR.2 Assurance Components.................................................................22 Table 3 Environment to Objective Correspondence ..............................................................................................35 Table 4 Objective to Requirement Correspondence...............................................................................................40 Table 5 Requirement Dependencies.........................................................................................................................41 Table 6 Security Functions vs. Requirements Mapping.........................................................................................42 Security Target Version 1.0, 05/16/2012 4 1. Security Target Introduction This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST conformance claims, and the ST organization. The TOE is DbProtect AppDetective 2009.1 R2 provided by Application Security, Inc. The TOE enables enterprise IT security personnel to identify and manage database vulnerabilities. With the reporting capabilities, the TOE provides a centralized console to manage security risk and extend corporate security policies at the database level. The Security Target contains the following additional sections:  Section 2 – Target of Evaluation (TOE) Description This section gives an overview of the TOE, describes the TOE in terms of its physical and logical boundaries, and states the scope of the TOE.  Section 3 – TOE Security Environment This section details the expectations of the environment and the threats that are countered by the TOE and operational environment.  Section 4 – TOE Security Objectives This section details the security objectives of the TOE and operational environment.  Section 5 – IT Security Requirements The section presents the security functional requirements (SFR) for the TOE and details the assurance requirements.  Section 6 – TOE Summary Specification The section describes the security functions represented in the TOE that satisfy the security requirements.  Section 7 – Protection Profile Claims This section presents any protection profile claims.  Section 8 – Rationale This section closes the ST with the justifications of the security objectives, requirements and TOE summary specifications as to their consistency, completeness, and suitability. 1.1 Security Target, TOE and CC Identification ST Title – DbProtect AppDetective 2009.1 R2 Security Target ST Version – Version 1.0 ST Date – 16 May 2012 TOE Identification – DbProtect AppDetective 2009.1 R2 TOE Developer – Application Security, Inc. Evaluation Sponsor – Application Security, Inc. CC Identification – Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 3, July 2009 1.2 Conformance Claims This TOE is conformant to the following CC specifications:  Common Criteria for Information Technology Security Evaluation Part 2: Security Functional Requirements, Version 3.1, Revision 3, July 2009.  Part 2 Extended  Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance Requirements, Version 3.1 Revision 3, July 2009.  Part 3 Conformant Security Target Version 1.0, 05/16/2012 5  Assurance Level Package:  EAL 2 augmented with ALC_FLR.2 1.3 Conventions The following conventions have been applied in this document:  Security Functional Requirements – Part 2 of the CC defines the approved set of operations that may be applied to functional requirements: iteration, assignment, selection, and refinement. o Iteration: allows a component to be used more than once with varying operations. In the ST, iteration is indicated by a letter placed at the end of the component. For example FDP_ACC.1a and FDP_ACC.1b indicate that the ST includes two iterations of the FDP_ACC.1 requirement, a and b. o Assignment: allows the specification of an identified parameter. Assignments are indicated using bold and are surrounded by brackets (e.g., [assignment]). Note that an assignment within a selection would be identified in italics and with embedded bold brackets (e.g., [[selected- assignment]]). o Selection: allows the specification of one or more elements from a list. Selections are indicated using bold italics and are surrounded by brackets (e.g., [selection]). o Refinement: allows the addition of details. Refinements are indicated using bold, for additions, and strike-through, for deletions (e.g., ―… all objects …‖ or ―… some big things …‖).  Other sections of the ST – Other sections of the ST use bolding to highlight text of special interest, such as captions.  Requirements that are Part 2 extended, i.e., are not included in the CC Part 2 but are explicitly defined by the ST author, are marked with an (EXP) after the requirement name. Security Target Version 1.0, 05/16/2012 6 2. TOE Description The Target of Evaluation (TOE) is DbProtect AppDetective 2009.1 R2. The TOE comprises a single management console component (the Console) and one or more database scanning engines (the Scan Engine). The Scan Engine component is based on the scanning engine incorporated in AppDetective Pro, which has been separately evaluated. Each of these components is an application designed to run in the context of a commercial operating system. Note that while the product comes with an Application Security ASAP Updater tool, the use of that tool is outside the scope of the evaluation. The primary reason is that the ASAP Updater is designed to keep the product up to date while the evaluation was conducted using a specific version of the product. Note that unlike AppDetective Pro, which is designed to be directly managed (i.e., via its own application interfaces), AppDetective is designed to be managed via its associated Console component. As such, the Console component presents the administrative interfaces while each of the AppDetective Scan Engines is responsible to perform the database scanning functions. The Scan Engine is a network-based vulnerability assessment application that reports on the security strength of database management systems (also known as database applications) within the network. The Scan Engine helps to identify vulnerable databases residing within the network by scanning for potential security vulnerabilities within those databases. The Scan Engine runs a defined set of ―jobs‖ including Discovery jobs that discover databases on the network, Pen Test jobs that run penetration tests on the discovered databases on the network, Audit jobs that identify vulnerabilities on the discovered databases on the network, and Report jobs that provide reports on the data collected by the other three types of jobs. Administrators can then take appropriate remedial actions. The Console is a GUI front-end that centralizes the management of multiple Scan Engines and access to the data collected by the Scan Engines. The Console enables access to set up and run AppDetective jobs. Access to AppDetective functions is role-based and can be limited to specific users based on role assignments within the Console. In addition to roles, the console also manages users and functionality in terms of groups and organizations. Groups are Windows Active Directory groups of zero to many userIDs that are assigned to organizations. Organizations are a defined set of network addresses that can be scanned by assigned userIDs and Groups. Both userIDs and Groups may be assigned to one or more Organizations. By assigning users specific roles it is possible to limit access to AppDetective functions and data. Organizations limit the scope of AppDetective Jobs to a defined set of network addresses and userIDs and Groups assigned to those Organizations can only run Jobs within the network scope assigned to that Organization. The product includes a number of tools that are executed directly from the underlying operating system rather than from the Console including the Configuration Manager, DbProtect Migration, ASAP Updater, and Policy Editor tools. These tools are not included in the evaluated configuration (and hence are not part of the TOE). The Configuration Manager tool provides a means for modifying various configuration parameters on the Console‘s host machine. The DbProtect Migration tool provides a means to migrate data from AppDetective Pro to DbProtect AppDetective. The ASAP Updater upgrades product components to the most current version. The Policy Editor provides an interface for managing policies that define the checks to be performed by Audit and Pen Test jobs. Access to these tools from the host cannot be controlled or monitored by the TOE and as such are excluded from the scope of evaluation. 2.1 TOE Overview The TOE consists of software applications that run in the context of a commercial operating system. AppDetective discovers network accessible database applications within an organization‘s infrastructure and scans them for potential vulnerabilities. AppDetective utilizes a library of known vulnerabilities and misconfiguration signatures. AppDetective includes modules that support scanning of the following database applications: Oracle, Microsoft SQL Server; IBM DB2; Sybase Adaptive Server Enterprise (ASE); MySQL; Lotus Domino; and Oracle Application Server. Security Target Version 1.0, 05/16/2012 7 In addition, AppDetective can generate fix scripts, customized based on scan results, which the administrator1 can review and apply to address identified vulnerabilities. However, the capabilities of fix scripts have not been assessed as part of the evaluation. AppDetective performs the following operations:  Discovery—systematically searches the network, inventorying applications and relevant application components by vendor and release.  Penetration Tests (Pen Tests)—applies a series of detailed security tests. AppDetective Pen Tests identify how an intruder or unauthorized user might gain access to application components. Pen Tests use various mechanisms to simulate how an intruder could exploit vulnerabilities to break into applications from the outside without possessing any authentication credentials.  Audits— connects to the target database application and its underlying operating system to perform an assessment of its configuration, determining susceptibility to internal misuse. AppDetective Audits require a valid user account on the target application in order to verify internal configuration settings.  Reporting—provides a reporting capability that enables the administrator to generate and view various types of report that document the results of a Pen Test or Audit, identifying potential vulnerabilities, an assessment of the risk associated with a vulnerability, and recommending actions to address a vulnerability. Pen Tests and Audits both consist of a series of security tests or checks that are grouped together in a Policy. Each security test or check targets a specific database application type and performs actions to determine if the application is susceptible to the vulnerability tested for by the check. Pen Test and Audit checks are categorized according to the type of vulnerability for which they test. The Pen Test categories are:  Denial of Services—these checks examine the target application for susceptibility to specific Denial of Service attacks  Misconfigurations—these checks examine the target application for possible misconfigurations that may leave the application susceptible to attack  Password attacks—these checks examine the target application to determine if it is vulnerable to direct password attacks, including: accounts with blank passwords; accounts with default passwords; and susceptibility to dictionary and brute-force attacks  Vulnerabilities—these checks determines if the application is susceptible to a specific published vulnerability for that application. The Audit categories are:  Access Control—these checks examine the target application for potentially inappropriate or insecure access control or privilege settings on database objects  Application Integrity—these checks determine if specific security measures (such as enabling auditing of specific events or encrypting sensitive data) have been applied in the application  Identification/Password Control—these checks examine the target application configuration to determine if it might be vulnerable to password attacks or problems associated with user accounts (e.g., by allowing short or poorly constructed passwords).  OS Integrity—these checks examine aspects of the OS supporting the database application to ensure they do not expose the application to attack (e.g., permissions on database files) and that the database 1 Note that the underlying operating system is responsible for user authentication and any user that can log in and start the TOE application is a defacto administrator. Security Target Version 1.0, 05/16/2012 8 configuration does not introduce vulnerabilities into the OS (e.g., application processes running with elevated privileges) AppDetective includes a number of built-in Audit and Pen Test Policies that represent useful collections of checks to be performed against targeted database applications. It should be noted the evaluation has not assessed the efficacy of any specific built-in policy or its compliance with any regulatory requirements implied by the policy. Rather, the evaluation has assessed the ability of the TOE to detect particular types of vulnerability to which a targeted database may be susceptible. The administrator can also create policies, based on the built-in policies supplied with the TOE. This involves the administrator copying an existing policy and adding or removing specific checks from the set associated with the original policy. The Console is an SSL-enabled web-browser accessible GUI tool that provides access to functions based on user roles and configured organizations. Roles within the console include super user, admin user, basic user, and view user; different functions are available from the console based on the user role. Super and admin users can define organizations, in terms of an IPv4 address range or set of IPv4 addresses on the network, that are hierarchically organized. The super and admin users can then assign test policies and users and/or groups to applicable organizations. The test policies are sets of Pen Tests or Audit Tests grouped for convenience and associated to appropriate organizations. The users and groups are defined in the associated Active Directory, every Console user must always be assigned to at least one organization, and serve to identify which users can access each organization. The organization hierarchy supports the definition of exclusive/isolated organizations as well as organizations that inherit IP ranges and test Policies in the ―parent‖ Organization. Users that are assigned to an organization, either directly or via a group, can access that organization and its children organizations in accordance with their assigned role. A Windows Administrator is assigned the Console super user role at system install and the super user can assign other Console roles to Active Directory Users, create Organizations and assign Users to Organizations. Organization assignments may also be made by Windows Groups within Active Directory, which are recognized by the Console. The Console depends upon the Operating System (OS) in the operational environment to authenticate users. The Console provides a login screen that captures the UserID and Password. It sends the UserID and Password to the OS for authentication. If the OS authenticates the user, then the Console GUI is displayed. The user is granted access to specific Console functions based on the role assigned to that UserID within the Console. The user is allowed to run vulnerability scans on specific IPv4 addresses and to access data from those scans based on the Organization to which that userID is assigned. Groups are a convenient means of assigning one or more users to the same Organization. A user may be assigned to multiple groups and may be assigned to multiple Organizations. When the user runs a vulnerability scan, that scan is run only against the IPv4 addresses in the ―active‖ Organization for that user, i.e., the Organization displayed on the console screen at the time. The active Organization also limits the user from accessing data except that data generated by the specific IPv4 addresses assigned to that Organization. The Console allows the user to switch from one Organization to another within the same user session. 2.2 TOE Architecture The TOE allows the authorized administrator to perform the tasks explained above (Discovery, Pen Tests, Audits) as well as examining scan results, based on function privileges. Logically, the Scan Engine operates as a single application though it is instantiated in a series of processes utilizing inter-process communication mechanisms provided by the underlying operating system to communicate with one another. Within the host, the Scan Engine executes using the host user credentials it is configured to use. The Console provides a means of centrally managing multiple Scan Engine instances. It implements a Graphical User Interface for the users to manage the TOE. Users can access the console remotely via a web browser. Sun Microsystems Java Runtime Environment (JRE) 1.6 is required for DbProtect Console applet to load into the web browser. Through the Console, users can access the functions and scan results of the Scan Engine instances to which they have been granted access. Security Target Version 1.0, 05/16/2012 9 The following figure depicts the association between the Console and the Scan Engine instances in their operating environment: The TOE relies on an external Backend Database (in the operational environment) to store the scan results from AppDetective instances as well as scan policies established via the Console. The AppDetective scan results are stored in the Backend Database, which is accessed by the Console when reporting the results. The Backend Database is in the operational Environment and is not a part of the TOE. Note that the Console and the Scan Engine depend on the underlying operating system to protect their executables and stored data images (e.g., files and registry keys), all communications between components (via an implementation of,SSL supporting HTTP and SOAP used by the TOE components), and their executing environments. The TOE also depends on the environment to ensure the Backend Database is secure. 2.2.1 Physical Boundaries The TOE includes a DbProtect Console (including the DbProtect Console Service) and one or more instances of the AppDetective Scan Engine, which operate in the context of commercial operating systems. Each TOE component utilizes functions of their host operating system to execute, store data, and to communicate (with each other, a Backend Database to store data, and target databases) on the network as well as for security as indicated above. Note that the Backend Database could be collocated with a TOE component on a common host or could be installed on a separate host. In addition to the components above, the product is bundled with the following components that are not included in the TOE boundary: ASAP Updater; Configuration Manager, DbProtect Migration, and Policy Editor tools. Furthermore the product is bundled some third party products that will be installed to support the TOE if not already present (see below). The Console implements its own interface accessible to authorized users via web browsers. TOE TOE Security Target Version 1.0, 05/16/2012 10 Each TOE application is designed to operate in the context of the following operating systems: Microsoft Windows Server 2003 and 2008 Enterprise Edition, Microsoft Windows Server 2003 and 2008 Enterprise x64 each with the latest patches. The TOE can be configured to use Microsoft SQL Server 2000 SP4, Microsoft SQL Server 2005, Microsoft SQL Server 2008 to store and retrieve scan results. Microsoft Access and Microsoft SQL Express are not supported in the evaluated configuration. Additionally, the TOE requires the following components in the operational environment (and will install them if not already present upon installation of the TOE):  Microsoft XML Core Services 4.0 SP2,  Microsoft .NET Framework 2.0 SP1,  Microsoft Visual Studio 2005 C++ Redistributable, and  TomCat Engine 5.5.20. The TOE includes Crystal Reports 9.2.0 to support its report generation and viewing function and, WinPcap Pro 4.0.2.1123 to support the Discovery operation. On the other hand, the TOE depends on WodSSH (2.4.1) in the operational environment to support the TOE’s ability to connect to target Linux/UNIX operating systems for the purpose of audits. The TOE supports its Discovery, Pen Test and Audit operations on the following database applications:  Oracle 11g, Oracle 10g , Oracle9i, and Oracle8i (note that while Oracle 8 and Oracle 7 are also supported, the Audit function does not work for those versions);  Oracle Application Server 9i and 9i Release 2;  Microsoft SQL Server Versions 6.x, 7.0, 2000, 2005, 2005 Express Edition, and 2008 and MSDE versions 1.0 and 2000 SP4;  Lotus Domino v4.5 through 7.0;  Sybase ASE 11.0, 11.5, 11.9.2, 12.0, 12.5, 15;  IBM DB2 Versions 6.1, 7.1, 8.1 and 8.2;  IBM DB2 zSeries Versions 7 and 8;  MySQL 3.20, 3.21, 3.22, 3.23, 4.0, 4.1, and 5.0. However, in order to perform audits on some database applications, the administrator needs to ensure the following components are installed and accessible in the operational environment:  IBM DB2 Server audits require the IBM DB2 runtime client;  IBM DB2 for Mainframe audits require IBM DB2 Connect;  Lotus Domino audits require the Lotus Notes client driver; and,  Sybase ASE audits require the Sybase ASE ODBC driver. 2.2.2 Logical Boundaries This section identifies: the security functions provided by DbProtect AppDetective; functions provided by the operational environment in which DbProtect AppDetective operates; and DbProtect AppDetective functions not covered by the evaluation. 2.2.2.1 Evaluated Security Functions This section addresses the following security functions provided by the TOE:  Database Discovery and Scanning  Security audit Security Target Version 1.0, 05/16/2012 11  Identification and authentication  Security management 2.2.2.1.1 Database Discovery and Scanning The TOE is a network-based, vulnerability assessment scanner, which discovers database applications within the network infrastructure and assesses their security strength. Without requiring any agents on the target systems, the TOE can perform audits and simulate attacks against discovered and targeted applications to uncover security vulnerabilities and misconfigurations. The TOE performs the following operations on database applications:  Discovery—systematically searches the network, inventorying applications and relevant application components by vendor and release  Pen Test—through a series of detailed security tests and Pen Tests, the TOE identifies how an intruder or unauthorized user might gain access to application components. Pen Tests use a black-box approach to simulate how an intruder would exploit vulnerabilities to break into a database application from the outside (this is termed “outside-in” in the product documentation).  Audit—in contrast, an Audit makes use of privileged accounts on the target database application and its underlying operating system host to determine susceptibility to internal misuse (this is termed “inside-out” in the product documentation). Audits require a valid user account in order to verify internal configuration settings.  Report—the TOE can generate reports in various formats (HTML, XML, ASCII text) that identify specific potential vulnerabilities, provide an assessment of the risk associated with a vulnerability, and recommend actions to address a vulnerability. 2.2.2.1.2 Security audit The TOE has the ability to generate audit records for the TOE security-relevant events. Section 6.1.2 specifies the TOE security events. The TOE records within each audit record at least the following information: Date, Time, Event Type, Success or Failure, User ID of the user. The TOE relies on the operational environment to protect and store the audit records, provide the ability to review the audit records, and to provide a reliable timestamp. 2.2.2.1.3 Identification and authentication The Console maintains four different roles (super user, admin user, basic user and view user). The Console requires each user to provide a username and password before he/she can access any other Console security functions. The Console will pass the provided username and password to the underlying operating system and will deny the user session if the operating system does not indicate successful authentication of the username. Note that the TOE does not authenticate users, but rather relies on its host operating system to protect it from inappropriate user access. The TOE depends upon Windows Active Directory for user information, including UserID and Windows Group. The TOE maintains UserID, Role, and Organization assignments for each user. 2.2.2.1.4 Security management The Console provides security management functions that are accessible via an SSL-enabled web browser. Each identified user is required to be authenticated using services of the operational environment (i.e., host operating system). The Console implements role-based access control features. As such, the Console restricts users access the management functions. There are four Console user types: Super User, admin user, basic user, and view user. The Console partitions access in two ways, by organization and by role. Organizations are created by super users. The admin user defines the users, policy access rights, and data partitioning within each organization. The main principle is to restrict data stored, collected, and associated with an organization to users in that organization. This applies to all jobs, reports, and discovery results. Organizations are hierarchically organized, which affects the visibility of one organization to another. The admin users can create new organizations or delete organizations within the organization that they have access. However, they are restricted from creating or deleting organizations above the organization to which they have access. Security Target Version 1.0, 05/16/2012 12 2.2.2.2 Functions Provided by the TOE Operational Environment The TOE relies on the operational environment in which it operates for the following security and other functionality:  Protect the TOE‘s stored executable image and its execution environment;  Protect TOE stored data, including audit records and scan results;  Provide a means to audit attempts to access the TOE stored executable image and stored data from the operational environment (i.e., not through the TOE‘s own interfaces);  Provide a reliable time stamp for use in audit records and scan results;  Authenticate authorized administrators and restrict the ability to manage and operate the TOE to authorized administrative users;  Provide a means for administrators to review the audit records in the audit trail; and  Provide encryption services used to encrypt database credentials and also to encrypt communication channels between the TOE components and also between the TOE Console and web browsers used to access it. Additionally, the TOE relies on its host to facilitate communication with target database applications and operating system products for the purposes of scanning and auditing.  For database applications, the TOE uses the ODBC, Oracle Instant client, DB2 client, Lotus Notes Domino C++, or TCP/IP socket APIs.  For Windows operating systems, the TOE uses the remote registry APIs, SMB file share APIs, and Windows Management Instrumentation (WMI) APIs.  For Linux/UNIX operating systems, the TOE uses telnet and SSH (via a third party WodSSH component). 2.2.2.3 Functions not Addressed by the Evaluation The TOE can generate fix scripts that the administrator can apply to correct problems identified by Pen Tests or Audits. The evaluation has not covered the efficacy of these fix scripts in actually correcting detected problems. The product provides a tool, ASAP Updater, which can be used to update the TOE and its knowledge base of application problems. However, the developer’s deployment methodology is to make only complete releases of the TOE software available to customers. Use of ASAP Updater would take the TOE out of its evaluated configuration, and so it is excluded from the evaluation. Similarly, the product includes Configuration Manager and DbProtect Migration tools. The Configuration Manager tool provides a means for modifying various configuration parameters on the Console’s host machine. The DbProtect Migration tool provides a means to migrate data from AppDetective Pro to DbProtect AppDetective. These tools are not necessary for the normal use of the TOE and have been excluded from the evaluated configuration as a result. The product also provides a Policy Editor that offers an interface for managing policies that define the checks to be performed by Audit and Pen Test jobs. Access to the Policy Editor cannot be controlled or monitored by the TOE and as such its use has not been included in the scope of evaluation, but should have no affect on the TOE itself. Rather the evaluation addresses the use of primitives found in policies however they may have been created (built- in, user created, or otherwise obtained). The TOE provides the capability for users to create their own tests and checks for Pen Tests and Audits. However, the evaluation is unable to make any comment on the efficacy of those tests and checks not provided as part of the TOE. Additionally, the following capabilities have been excluded from the scope of analysis during the evaluation: ability to log to a Check point event logging server; SCAP support; use of NMAP files in performing Discoveries; and CVE compatibility. Security Target Version 1.0, 05/16/2012 13 Finally, the DbProtect console component provides the ability to manage both the AppDetective product and the sibling AppRadar product, which was separately evaluated. While this TOE doesn’t address the integration of both products, the use of the AppRadar product with the DbProtect console in addition to the AppDetective product does not invalidate the evaluated configuration of the TOE. 2.3 TOE Documentation Application Security, Inc. offers a series of documents that describe the installation of the Console and AppDetective as well as guidance for subsequent use and administration of the applicable security features as follows:  DbProtect AppDetective 2009.1 R2 Evaluated Configuration, Version 0.9, April 6, 2012  DbProtect 2009.1R2 Administrators‘ Guide, April 17, 2009 (updated April 6, 2012)  DbProtect 2009.1R2 Installation Guide, April 7, 2009  DbProtect 2009.1R2 Users‘ Guide, April 21, 2009 (updated April 6, 2012) Security Target Version 1.0, 05/16/2012 14 3. Security Environment The TOE security environment describes the security aspects of the intended environment in which the TOE is to be used and the manner in which it is expected to be employed. The statement of the TOE security environment defines the following:  Organizational Policies that the TOE and the environment of the TOE fulfill  Threats that the TOE and the environment of the TOE counters  Assumptions made about the operational environment and the intended method of use for the TOE Furthermore, the TOE is intended to be used in environments where the relative assurance that its security functions are enforced is commensurate with EAL2 as defined in the CC. 3.1 Organizational Policies P.ACCACT Users of the TOE shall be accountable for their actions. P.DETECT Configuration and vulnerability information that might be indicative of the potential for a future intrusion of a targeted IT System (database) must be collected. P.MANAGE The TOE shall only be managed by authorized users. 3.2 Threats T.COMDIS An unauthorized user may attempt to disclose the data collected by the TOE by bypassing a TOE security mechanism. T.COMINT An unauthorized user may attempt to compromise the integrity of the data collected by the TOE by bypassing a security mechanism. T.FACCNT Unauthorized attempts to access TOE data or security functions may go undetected. T.IMPCON An unauthorized user may inappropriately change the configuration of the TOE causing potential vulnerability to go undetected. T.LOSSOF An unauthorized user may attempt to remove or destroy data collected by the TOE. T.NOHALT An unauthorized user may attempt to compromise the continuity of the collection functionality by halting execution of the TOE. T.PRIVIL A user may gain access unauthorized to TOE security functions and data. T.SCNCFG Improper security configuration settings may exist in the IT system the TOE monitors. T.SCNVUL Vulnerabilities may exist in the targeted IT System the TOE monitors. 3.3 Assumptions A.ACCESS The TOE has access to all the IT System data it needs to perform its functions. A.DYNMIC The TOE will be managed in a manner that allows it to appropriately address changes in the IT System the TOE monitors. Security Target Version 1.0, 05/16/2012 15 A.LOCATE The processing resources of the TOE will be located within controlled access facilities, which will prevent unauthorized physical and logical access. A.MANAGE There will be one or more competent individuals assigned to manage the TOE and the security of the information it contains. A.NOEVIL The authorized administrators are not careless, willfully negligent, or hostile, and will follow and abide by the instructions provided by the TOE documentation. Security Target Version 1.0, 05/16/2012 16 4. Security Objectives This section defines the security objectives for the TOE and its supporting operational environment. The security objectives are intended to counter identified threats, comply with defined organizational security policies, and address applicable assumptions. 4.1 Security Objectives for the TOE O.ACCESS The TOE must allow authorized users to access only appropriate TOE functions and data. O.AUDITS The TOE must be able to record audit records for data accesses and use of the primary TOE functions. O.EADMIN The TOE must include a set of functions that allow effective management of its functions and data. O.IDACTS The TOE must collect and store configuration and vulnerability information that might be indicative of the potential for a future intrusion of an IT System. O.IDENT The TOE must be able to identify users prior to allowing access to the TOE. O.PROTCT The TOE must protect itself from unauthorized modifications and access to its functions and data via its own interfaces. 4.2 Security Objectives for the TOE Operational Environment The following security objectives for the operational environment of the TOE must be satisfied in order for the TOE to fulfill its own security objectives. OE.AUDIT The operational environment of the TOE can audit attempts to access the TOE‘s stored executable image and stored data. OE.CREDEN Those responsible for the TOE must ensure that all access credentials are protected by the users in a manner which is consistent with IT security. OE.IDAUTH The operational environment of the TOE authenticates users prior to allowing access to TOE via its own interfaces. OE.INSTAL Those responsible for the TOE must ensure that the TOE is delivered, installed, managed, and operated in a manner which is consistent with the TOE guidance. OE.INTROP The TOE is interoperable with the IT System it monitors and scans. OE.PERSON Personnel working as authorized administrators shall be carefully selected and trained for proper operation of the TOE. OE.PHYCAL Those responsible for the TOE must ensure that those parts of the TOE critical to security policy are protected from any physical attack. Security Target Version 1.0, 05/16/2012 17 OE.PROTECT The operational environment of the TOE must protect the TOE from logical attacks including unauthorized modifications and access to stored data or TOE executables. OE.REVIEW The operational environment of the TOE provides the capability to review the audit records. OE.TIME The operational environment will provide reliable timestamps to the TOE. OE.TRANSMIT The operational environment must protect the data transmitted between the TOE components and the operational environment components. Security Target Version 1.0, 05/16/2012 18 5. IT Security Requirements The security requirements for the TOE have been drawn from Parts 2 and 3 of the Common Criteria, with the exception of some extended security functional requirements crafted to better represent the vulnerability scanning functions of the TOE. The security functional requirements have been selected to correspond to the actual security functions implemented by the TOE while the assurance requirements have been selected to offer a low to moderate level of assurance that those security functions are properly realized. 5.1 Extended Security Functional Requirements A class of ADP (named after the AppDetective Product) security functional requirements was created to address specifically the data collected and analyzed by the TOE. The audit class of FAU was initially used as a model for creating these requirements. The purpose of this class of requirements is to address the unique nature of the DB Scan data and provide for requirements about collecting, reviewing and managing the data. These requirements embody all the necessary security functions of collection, storage, and review as well as protection of security credentials entrusted to the TOE. The TOE requires the time stamp (FPT_STM.1) to record its finding. Also, ADP_RDR_EX.1 is dependant upon ADP_SCN_EX.1 since data can be reviewed only after it is collected. ADP_PRT_EX.1 has been created explicitly to ensure that the security credentials used to access target IT systems must be protected; otherwise the targets might be more vulnerable due to the TOE. It has been added to the ADP class since it is directly related to the main scanning functions of the TOE. Each is defined as follows: 5.1.1 DB Scan Data Review (ADP_RDR) Family Behavior The family of SFRs is intended to address functions related to creating and reviewing scan reports created by the TOE. Management: ADP_RDR_EX.1 The following actions could be considered for the management functions in FMT: a) Management of the reporting function. Audit: ADP_RDR_EX.1 The following actions should be auditable if ADP_RDR_EX.1 is included in the PP/ST:  Minimal: Review of scan data. 5.1.1.1 DB Scan Data Review (EXP) (ADP_RDR_EX.1) Hierarchical to: No other components Dependencies: ADP_SCN_EX.1 ADP_RDR_EX.1.1 The TSF shall provide the authorized user with the capability to create and review DB scan reports based on DB scan data analytical results produced by the TSF. ADP_RDR_EX.1.2 The TSF shall provide the DB scan reports in a manner suitable for the user to interpret the information. 5.1.2 DB Scan Data Collection and Analysis (ADP_SCN) Family Behavior The family of SFRs is intended to address functions related to scanning or collection and analysis target systems in the operational environment. Management: ADP_SCN_EX.1 Security Target Version 1.0, 05/16/2012 19 The following actions could be considered for the management functions in FMT: a) Management of the scanning or collection function. Audit: ADP_SCN_EX.1 The following actions should be auditable if ADP_SCN_EX.1 is included in the PP/ST:  Minimal: Initiation of scans. 5.1.2.1 DB Scan Data Collection and Analysis (ADP_SCN_EX.1) Hierarchical to: No other components Dependencies: FPT_STM.1 ADP_SCN_EX.1.1 The TSF shall be able to perform identification of targeted IT system resources. ADP_SCN_EX.1.2 The TSF shall be able to perform signature analysis2 of identified targeted IT system resources. ADP_SCN_EX.1.3 The TSF shall be able to collect the following information from identified targeted IT System resource(s): access control configuration, authentication configuration, accountability policy configuration, detected known vulnerabilities. 5.1.3 DB Scan Credential Protection (ADP_PRT) Family Behavior The family of SFRs is intended to address functions related to storing and protecting credentials used by the TOE to access scan targets in the operational environment. Management: ADP_PRT_EX.1 The following actions could be considered for the management functions in FMT: a) Management of the security credentials. Audit: ADP_PRT_EX.1 There are no auditable events foreseen. 5.1.3.1 DB Scan Credential Protection (EXP) (ADP_PRT_EX.1) Hierarchical to: No other components Dependencies: None ADP_PRT_EX.1.1 The TSF shall ensure that configured IT System security credentials are stored in a secure manner. 5.2 TOE Security Functional Requirements The following table describes the SFRs satisfied by the TOE. Extended requirements are marked with (EXP) to indicate that they are not drawn from the Common Criteria. Requirement Class Requirement Component ADP: DB Scan (EXP) ADP_RDR_EX.1: DB Scan Data Review (EXP) ADP_SCN_EX.1: DB Scan Data Collection and Analysis (EXP) ADP_PRT_EX.1: DB Scan Credential Protection (EXP) FAU: Security audit FAU_GEN.1: Audit data generation 2 In this context ‗signature analysis‘ is meant to indicate that the TOE is configured with specific data or parameters used to match some analytical target (e.g., a resource such as a file). Security Target Version 1.0, 05/16/2012 20 FIA: Identification and authentication FIA_ATD.1: User attribute definition FIA_UID.1: Timing of identification FMT: Security management FMT_MOF.1: Management of security functions behaviour FMT_SMF.1: Specification of Management Functions FMT_SMR.1: Security roles Table 1 TOE Security Functional Components 5.2.1 DB Scan (EXP) (ADP) 5.2.1.1 DB Scan Data Review (EXP) (ADP_RDR_EX.1) ADP_RDR_EX.1.1 The TSF shall provide the authorized user with the capability to create and review DB scan reports based on DB scan data analytical results produced by the TSF. ADP_RDR_EX.1.2 The TSF shall provide the DB scan reports in a manner suitable for the user to interpret the information. 5.2.1.2 DB Scan Data Collection and Analysis (ADP_SCN_EX.1) ADP_SCN_EX.1.1 The TSF shall be able to perform identification of targeted IT system resources. ADP_SCN_EX.1.2 The TSF shall be able to perform signature analysis of identified targeted IT system resources. ADP_SCN_EX.1.3 The TSF shall be able to collect the following information from identified targeted IT System resource(s): access control configuration, authentication configuration, accountability policy configuration, detected known vulnerabilities. 5.2.1.3 DB Scan Credential Protection (EXP) (ADP_PRT_EX.1) ADP_PRT_EX.1.1 The TSF shall ensure that configured IT System security credentials are stored in a secure manner. 5.2.2 Security audit (FAU) 5.2.2.1 Audit data generation (FAU_GEN.1) FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and shutdown of the audit functions; b) All auditable events for the [not specified] level of audit; and c) [ initiation of Discovery, Pen Test, or Audit scans, scheduling Discovery, Pen test, or Audit scans, creation and review of DB Scan reports based on DB scan data]. FAU_GEN.1.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 (if applicable), 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 included in the PP/ST, [no additional information]. Security Target Version 1.0, 05/16/2012 21 5.2.3 Identification and authentication (FIA) 5.2.3.1 User attribute definition (FIA_ATD.1) FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: [user ID, role, organization]. 5.2.3.2 Timing of identification (FIA_UID.1) FIA_UID.1.1 The TSF shall allow [no functions] 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. 5.2.4 Security management (FMT) 5.2.4.1 Management of security functions behaviour (FMT_MOF.1) FMT_MOF.1.1 The TSF shall restrict the ability to [modify the behaviour of] the functions [defined in the table below] to [the user roles defined in the table below]. Functions Super user Admin user Basic user View user Register an AppDetective Scan Engine access no access no access no access Unregister an AppDetective Scan Engine access no access no access no access Edit an AppDetective Scan Engine access no access no access no access Export credentials to a file via a Job template or Credential Profile access no access no access no access Import credentials from file via a Job template or Credential Profile access access access no access Create or modify a Credential Profile access access access no access Select a different effective Organization access access no access no access Add, edit and remove an Organization access access no access no access Add, edit and remove a User or Group access access no access no access Create, edit, delete, schedule, manage, or cancel a Job access access access no access Add, edit, or remove an application to the Discovery access access access no access Delete a Report access access access no access Create, edit, or schedule a Report access access access access View Reports, Job Results, and Job History access access access Access Add an application to the Dashboard access access access No access Edit or remove an application from the Dashboard access access no access no access Security Target Version 1.0, 05/16/2012 22 5.2.4.2 Specification of Management Functions (FMT_SMF.1) FMT_SMF.1.1 The TSF shall be capable of performing the following security management functions: [ initiation of Discovery, Pen Test, or Audit scan jobs, import, export, creation, and modification of Credential Profiles scheduling Discovery, Pen test, or Audit scan jobs, creation, removal, or modification of scan jobs, creation and review of DB Scan reports and results based on DB scan data, Add an application to the Dashboard Edit or remove an application from the Dashboard addition, removal, or modification of scan engines, creation, removal, or modification of organizations, and creation, removal, or modification (including organization and role assignments) of users]. 5.2.4.3 Security roles (FMT_SMR.1) FMT_SMR.1.1 The TSF shall maintain the roles [super user, admin user, basic user, view user]. FMT_SMR.1.2 The TSF shall be able to associate users with roles. 5.3 TOE Security Assurance Requirements The security assurance requirements for the TOE are the EAL 2 augmented with ALC_FLR.2 components as specified in Part 3 of the Common Criteria. Requirement Class Requirement Component ADV: Development ADV_ARC.1: Security architecture description ADV_FSP.2: Security-enforcing functional specification ADV_TDS.1: Basic design AGD: Guidance documents AGD_OPE.1: Operational user guidance AGD_PRE.1: Preparative procedures ALC: Life-cycle support ALC_CMC.2: Use of a CM system ALC_CMS.2: Parts of the TOE CM coverage ALC_DEL.1: Delivery procedures ALC_FLR.2: Flaw reporting procedures ATE: Tests ATE_COV.1: Evidence of coverage ATE_FUN.1: Functional testing ATE_IND.2: Independent testing - sample AVA: Vulnerability assessment AVA_VAN.2: Vulnerability analysis Table 2 EAL 2 augmented with ALC_FLR.2 Assurance Components 5.3.1 Development (ADV) 5.3.1.1 Security architecture description (ADV_ARC.1) ADV_ARC.1.1d The developer shall design and implement the TOE so that the security features of the TSF cannot be bypassed. ADV_ARC.1.2d The developer shall design and implement the TSF so that it is able to protect itself from tampering by untrusted active entities. ADV_ARC.1.3d The developer shall provide a security architecture description of the TSF. Security Target Version 1.0, 05/16/2012 23 ADV_ARC.1.1c The security architecture description shall be at a level of detail commensurate with the description of the SFR-enforcing abstractions described in the TOE design document. ADV_ARC.1.2c The security architecture description shall describe the security domains maintained by the TSF consistently with the SFRs. ADV_ARC.1.3c The security architecture description shall describe how the TSF initialisation process is secure. ADV_ARC.1.4c The security architecture description shall demonstrate that the TSF protects itself from tampering. ADV_ARC.1.5c The security architecture description shall demonstrate that the TSF prevents bypass of the SFR- enforcing functionality. ADV_ARC.1.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.3.1.2 Security-enforcing functional specification (ADV_FSP.2) ADV_FSP.2.1d The developer shall provide a functional specification. ADV_FSP.2.2d The developer shall provide a tracing from the functional specification to the SFRs. ADV_FSP.2.1c The functional specification shall completely represent the TSF. ADV_FSP.2.2c The functional specification shall describe the purpose and method of use for all TSFI. ADV_FSP.2.3c The functional specification shall identify and describe all parameters associated with each TSFI. ADV_FSP.2.4c For each SFR-enforcing TSFI, the functional specification shall describe the SFR-enforcing actions associated with the TSFI. ADV_FSP.2.5c For each SFR-enforcing TSFI, the functional specification shall describe direct error messages resulting from processing associated with the SFR-enforcing actions. ADV_FSP.2.6c The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification. ADV_FSP.2.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_FSP.2.2e The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. 5.3.1.3 Basic design (ADV_TDS.1) ADV_TDS.1.1d The developer shall provide the design of the TOE. ADV_TDS.1.2d The developer shall provide a mapping from the TSFI of the functional specification to the lowest level of decomposition available in the TOE design. ADV_TDS.1.1c The design shall describe the structure of the TOE in terms of subsystems. ADV_TDS.1.2c The design shall identify all subsystems of the TSF. Security Target Version 1.0, 05/16/2012 24 ADV_TDS.1.3c The design shall describe the behaviour of each SFR-supporting or SFR-non-interfering TSF subsystem in sufficient detail to determine that it is not SFR-enforcing. ADV_TDS.1.4c The design shall summarise the SFR-enforcing behaviour of the SFR-enforcing subsystems. ADV_TDS.1.5c The design shall provide a description of the interactions among SFR-enforcing subsystems of the TSF, and between the SFR-enforcing subsystems of the TSF and other subsystems of the TSF. ADV_TDS.1.6c The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. ADV_TDS.1.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_TDS.1.2e The evaluator shall determine that the design is an accurate and complete instantiation of all security functional requirements. 5.3.2 Guidance documents (AGD) 5.3.2.1 Operational user guidance (AGD_OPE.1) AGD_OPE.1.1d The developer shall provide operational user guidance. AGD_OPE.1.1c The operational user guidance shall describe, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings. AGD_OPE.1.2c The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure manner. AGD_OPE.1.3c The operational user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate. AGD_OPE.1.4c The operational user guidance shall, for each user role, clearly present each type of security- relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF. AGD_OPE.1.5c The operational user guidance shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation. AGD_OPE.1.6c The operational user guidance shall, for each user role, describe the security measures to be followed in order to fulfil the security objectives for the operational environment as described in the ST. AGD_OPE.1.7c The operational user guidance shall be clear and reasonable. AGD_OPE.1.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.3.2.2 Preparative procedures (AGD_PRE.1) AGD_PRE.1.1d The developer shall provide the TOE including its preparative procedures. Security Target Version 1.0, 05/16/2012 25 AGD_PRE.1.1c The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer's delivery procedures. AGD_PRE.1.2c The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST. AGD_PRE.1.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AGD_PRE.1.2e The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation. 5.3.3 Life-cycle support (ALC) 5.3.3.1 Use of a CM system (ALC_CMC.2) ALC_CMC.2.1d The developer shall provide the TOE and a reference for the TOE. ALC_CMC.2.2d The developer shall provide the CM documentation. ALC_CMC.2.3d The developer shall use a CM system. ALC_CMC.2.1c The TOE shall be labelled with its unique reference. ALC_CMC.2.2c The CM documentation shall describe the method used to uniquely identify the configuration items. ALC_CMC.2.3c The CM system shall uniquely identify all configuration items. ALC_CMC.2.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.3.3.2 Parts of the TOE CM coverage (ALC_CMS.2) ALC_CMS.2.1d The developer shall provide a configuration list for the TOE. ALC_CMS.2.1c The configuration list shall include the following: the TOE itself; the evaluation evidence required by the SARs; and the parts that comprise the TOE. ALC_CMS.2.2c The configuration list shall uniquely identify the configuration items. ALC_CMS.2.3c For each TSF relevant configuration item, the configuration list shall indicate the developer of the item. ALC_CMS.2.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.3.3.3 Delivery procedures (ALC_DEL.1) ALC_DEL.1.1d The developer shall document and provide procedures for delivery of the TOE or parts of it to the consumer. Security Target Version 1.0, 05/16/2012 26 ALC_DEL.1.2d The developer shall use the delivery procedures. ALC_DEL.1.1c The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to the consumer. ALC_DEL.1.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.3.3.4 Flaw reporting procedures (ALC_FLR.2) ALC_FLR.2.1d The developer shall document and provide flaw remediation procedures addressed to TOE developers. ALC_FLR.2.2d The developer shall establish a procedure for accepting and acting upon all reports of security flaws and requests for corrections to those flaws. ALC_FLR.2.3d The developer shall provide flaw remediation guidance addressed to TOE users. ALC_FLR.2.1c The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE. ALC_FLR.2.2c The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw. ALC_FLR.2.3c The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws. ALC_FLR.2.4c The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users. ALC_FLR.2.5c The flaw remediation procedures shall describe a means by which the developer receives from TOE users reports and enquiries of suspected security flaws in the TOE. ALC_FLR.2.6c The procedures for processing reported security flaws shall ensure that any reported flaws are remediated and the remediation procedures issued to TOE users. ALC_FLR.2.7c The procedures for processing reported security flaws shall provide safeguards that any corrections to these security flaws do not introduce any new flaws. ALC_FLR.2.8c The flaw remediation guidance shall describe a means by which TOE users report to the developer any suspected security flaws in the TOE. ALC_FLR.2.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.3.4 Tests (ATE) 5.3.4.1 Evidence of coverage (ATE_COV.1) ATE_COV.1.1d The developer shall provide evidence of the test coverage. ATE_COV.1.1c The evidence of the test coverage shall show the correspondence between the tests in the test documentation and the TSFIs in the functional specification. Security Target Version 1.0, 05/16/2012 27 ATE_COV.1.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.3.4.2 Functional testing (ATE_FUN.1) ATE_FUN.1.1d The developer shall test the TSF and document the results. ATE_FUN.1.2d The developer shall provide test documentation. ATE_FUN.1.1c The test documentation shall consist of test plans, expected test results and actual test results. ATE_FUN.1.2c The test plans shall identify the tests to be performed and describe the scenarios for performing each test. These scenarios shall include any ordering dependencies on the results of other tests. ATE_FUN.1.3c The expected test results shall show the anticipated outputs from a successful execution of the tests. ATE_FUN.1.4c The actual test results shall be consistent with the expected test results. ATE_FUN.1.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.3.4.3 Independent testing - sample (ATE_IND.2) ATE_IND.2.1d The developer shall provide the TOE for testing. ATE_IND.2.1c The TOE shall be suitable for testing. ATE_IND.2.2c The developer shall provide an equivalent set of resources to those that were used in the developer's functional testing of the TSF. ATE_IND.2.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ATE_IND.2.2e The evaluator shall execute a sample of tests in the test documentation to verify the developer test results. ATE_IND.2.3e The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified. 5.3.5 Vulnerability assessment (AVA) 5.3.5.1 Vulnerability analysis (AVA_VAN.2) AVA_VAN.2.1d The developer shall provide the TOE for testing. AVA_VAN.2.1c The TOE shall be suitable for testing. AVA_VAN.2.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AVA_VAN.2.2e The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE. Security Target Version 1.0, 05/16/2012 28 AVA_VAN.2.3e The evaluator shall perform an independent vulnerability analysis of the TOE using the guidance documentation, functional specification, TOE design and security architecture description to identify potential vulnerabilities in the TOE. AVA_VAN.2.4e The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack potential. Security Target Version 1.0, 05/16/2012 29 6. TOE Summary Specification This chapter describes the security functions:  Database Discovery and Scanning  Security Audit  Identification and Authentication  Security Management The TOE ensures that its mechanisms cannot be bypassed within its scope of control by requiring users to be identified and also authenticated by the operational environment. Once the user is authorized as valid user listed in Windows Active Directory, the user identity is then verified by TOE with its backend database. The backend database is accessed by both the Sensor (to store data) and the Console (to query data) using Microsoft ODBC. Access to the TOE functions, via TOE Console interface, will be granted based on the user identity and role / privilege assigned. That is, upon logged on, each user to limited by the TOE to perform only those functions they are allowed based on their role and organization. Protection of the TOE via other interfaces, such as those of the host OS, are assumed to be protected as summarized elsewhere in this ST. Similarly, the AppDetective Scan Engine component of the TOE will interact only with the Console Service. During AppDetective Scan Engine component registration, the DbProtect Console service identifies its network interface (MAC address) and provides steps to register the AppDetective Scan Engine component through its web based GUI interface. Each AppDetective Scan Engine component can be registered only by one Console. The AppDetective Scan Engine component will communicate only with the console with which it has been registered to communicate using SOAP over HTTP/SSL (HTTPS) on designated port. The HTTPS function is implemented in the operational environment (via the available web server front end and utilized by the TOE for both Console to Sensor communication as well as Console to web-browser communication. Additionally, the TOE employs WodSSH in the operational environment to establish Telnet or SSH, as supported by the target, connections with UNIX/Linux targets when performing audits. 6.1 Database Discovery and Scanning The TOE provides a graphical user interface (GUI) – Console service - to manage the scanning of targeted IT systems (comprising the supported database applications identified in Section 2.2.1) and the review of the analytical results it produces. The Console component of the TOE provides all the necessary management functions and communicates directly with the TOE Scan Engine components using SOAP over HTTPS and indirectly with the TOE Scan Engine components (i.e., to retrieve collected data) via a shared backend database component in the operational environment. The TOE is capable of performing various checks on targeted network accessible database applications, according to the configured job and policy. The TOE relies on the underlying operating system to provide a reliable timestamp. In addition, the TOE uses a database in the operational environment (termed the ―Backend Database‖) to store its scan results. The TOE is capable of creating and scheduling the following types of jobs:  Discovery Jobs: The Discovery process is a port scan of devices on the network performed by the TOE to discover target database applications. The administrator may specify that Discovery be performed for an IPv4 address range or for an entire network. A Discovery locates database applications on the network, identifies the database application‘s IPv4 addresses and ports used to provide network services, and saves the information for subsequent use to initiate a Pen Test or Audit. The TOE incorporates WinPcap by CACE Technologies to perform the Discovery job. WinPcap is a tool for link-layer network access in Windows environments. It provides access to the network device‘s TCP/IP stack. Additional information on WinPcap is available at http://www.cacetech.com/products/winpcap_professional.htm.  Pen Tests Jobs: A Pen Test assesses the security of a database application by running security checks against it from the network—the TOE does not need to login to the database. These checks are signature- Security Target Version 1.0, 05/16/2012 30 based where configured signatures are compared against network discernable characteristics of the target database application. The TOE can perform the following types of security checks (i.e., includes applicable signatures) as part of a Pen Test: o Denial of Services—these checks examine the database application for susceptibility to specific Denial of Service attacks. o Misconfigurations—these checks examine the database application for possible misconfigurations that may leave the database application susceptible to attack. o Password attacks—these checks examine the database application to determine if it is vulnerable to password attacks, including: accounts with blank passwords; accounts with default passwords still set; susceptibility to dictionary and brute-force attacks. o Vulnerabilities—each of these checks determines if the database is susceptible to any specific published vulnerabilities for that database application.  Audit Jobs: An Audit assesses the security of a database application by connecting to the database application using an appropriately privileged account and accessing the internal configuration. The TOE can perform the following types of security checks as part of an Audit: o Access Control—these checks examine the database application access control configuration for potentially inappropriate or insecure access control or privilege settings on database objects. o Accountability—these checks examine the database application accountability configuration to determine if specific security measures, such as enabling auditing of specific events, have been applied. o Authentication—these checks examine the database application authentication-related configuration to determine if it is vulnerable to password attacks or problems associated with user authentication. Data identifying the targeted database application is stored in the Backend Database as a part of the Discovery process and this data is used by the TOE to determine which policies are applicable and to run appropriate Audit and Pen Test scans. The data returned for successful scans is dependent on the scan; specific data collected is defined for each policy and database application in the user guidance documentation. DB Scan reports are designed to communicate vulnerabilities discovered by AppDetective. The reports present the scan results in a human readable format and can include all the information from those results. These reports can be generated in a number of formats. AppDetective comes with a set of pre-defined scans, which are defined by Policies that are used by Pen Test or Audit Jobs. The scan results stored by the TOE identify the date and time the job was run, the type of job (see above) that was run, and details specific to the type and results of the scan including identifying any network applications subject to scanning and any vulnerabilities identified for scanned network applications. The user guide should be consulted for more specific information about the range and presentation of information collected and made available to TOE users. Note that while the TOE includes a number of pre-defined policies (or signatures) to identify known vulnerabilities, it provides a limited ability for the user to extend existing policies or create new policies based on their own checks. Furthermore, no assessment has been made regarding the efficacy of the pre-defined policies nor are any user- defined policies addressed within the scope of the evaluation. As indicated above, the TOE can access some targeted IT systems using privileged accounts in order to gather specific internal configuration data. Applicable security credentials can be configured into the TOE and the TOE will store and protect those credentials using capabilities provided by its host operating system. Specifically, the TOE calls upon the Windows Data Protection API (DPAPI) to encrypt and store the credentials in its registry so that they can be recalled by the TOE when needed. The Database Discovery and Scanning function is designed to satisfy the following security functional requirements: Security Target Version 1.0, 05/16/2012 31  ADP_RDR_EX.1: The TOE provides the authorized users with the capability to view the DB Scan reports.  ADP_SCN_EX.1: The TOE can identify targeted IT systems (database applications), analyze the target using signatures in order to discover potential vulnerabilities, and collect from targets configuration data pertaining to access control, accountability, and authentication as well as information related to any identified vulnerabilities.  ADP_PRT_EX.1: The TOE uses the data protection API of its host operating system in order to securely store security credentials used to access targeted IT systems. 6.2 Security Audit The TOE provides its own audit mechanism that can generate audit records for the use of TOE‘s security functions. The TOE relies on the underlying Operating System (OS) to protect and store the audit records, provide the ability to review the audit records, and to provide a reliable timestamp. The TOE generates the following security relevant events:  initiation of Discovery, Pen Test, or Audit scans,  scheduling Discovery, Pen test, or Audit scans,  creation and review of DB Scan reports based on DB scan data, Note that the audit mechanism is always enabled and there is no capability to disable the audit. The Evaluated Configuration Guide provides instructions to configure the DbProtect Console host to create an audit record when the TOE Console starts and upon shutdown effectively showing when audit starts up and stops. However, the TOE itself always generates audit events while it is running and auditing cannot be disabled obviating any need to audit start-up and shutdown of audit which is simply not applicable. Each audit records is generated with the date and time queried from the operating system and the job type or the type of event per the list above. The outcome for each event is generally successful and implied by the event itself since the corresponding actions are made available to and can only be attempted by authorized users. In other words, the users are presented only with functions they are allowed to access and hence are prevented from attempting unauthorized functions. It should be noted that since other events, such as user authentication and access to TOE files, occur in the host OS they can be audited by the OS and reviewed using OS audit review capabilities. Furthermore, while there are no claims of audit review, the events identified above are stored in the backend database and can be queried from that database for review. However, the TOE does include a limited ability to review job history where the audited events would be evident. The Security audit function is designed to satisfy the following security functional requirements:  FAU_GEN.1: The TOE generates audit events for data accesses and use of the TOE functions. 6.3 Identification and Authentication The Console component of the TOE identifies its own users but also requires each user to be successfully authenticated before they are considered genuine and can access the functions available via the Console (i.e., TOE). The TOE maintains each user‘s identity, role, and organizations. Any authorized user (example: super user) must enter his/her unique user name and password when accessing the Console via an SSL-enabled Web Browser. If the user identity is known to the TOE (i.e., defined), the TOE passes this information to the underlying operating system and relies on the underlying operating system to authenticate the provided user identity. The TOE then uses that user identity to determine the applicable role and organizations. If the user identity is unknown to the TOE or the operating system fails to indicate successful authenticate of the user identity, the Console discontinues the attempt to create a user session. The Identification and authentication function is designed to satisfy the following security functional requirements: Security Target Version 1.0, 05/16/2012 32  FIA_ATD.1: The TOE maintains the list of security attributes belonging to individual users.  FIA_UID.1: The TOE requires each user to be identified before accessing security functions via the Console interface. 6.4 Security Management The Console implements management functions that are accessible via an SSL-enabled web-browser after being identified and authenticated as described in the previous section. The Console component (i.e., Console service) of the TOE maintains the following four security management roles: super user, admin user, basic user, and view user and is able to associate defined users with one of these roles. The Console partitions access in two ways, by organizations (assigned to each user) and by role. Organizations are created by super users or admin users. The super users and admin users can define organizations that are descendents of the organization to which they belong. The main principle is that data stored, collected, and associated with an organization is only accessible by users in that (or a parent of that) organization. Initially, when the Console is installed, there is just one organization, namely the 'root'. The user who installs the Console is automatically a super user and a member of the root organization. The super user may create new organizations and assign other users to them. The new organizations can only be created as a descendent of the root organization or its descendents. Once this organizational structure is in place, the admin user or super user can add users to these organizations. The users added to a specific organization can view only the data objects associated with their organization, with the exception of the super user and admin user. The super users and admin users are allowed to see the organizational structure and change the effective (i.e., their current) organization to another that is visible to them. This change is effective for the duration of their logon session or until changed again. Moreover, a super user or admin user is allowed to remove or add organizations under his/her organization (i.e., descendents), but he/she may not remove his/her own organization or user name. Super user, admin user and Basic user are also able to add applications to existing scan discovery. However, only Super admin user and admin user are allowed to remove application from the dashboard where discovered applications are listed. Note that a dashboard displays detailed data about application discovered on the network, recent Pen Tests and Audits performed, and any vulnerabilities detected. When a user is created, his/her role is assigned from one of: super user, admin user, basic user, or view user. These roles affect the accessible system features for the user. As discussed above, the admin users may change their effective organization for the duration of their session. However, the super-admin has other rights, such as visibility to the Scan Engine configuration page. The basic user does not have access to view organization data, create organizations, nor add/remove users. These features are simply not present on his/her user interface. Users in one organization cannot see any data collected or saved in another organization, with the exception of the super user and admin user who first explicitly changes his effective organization. The table in section 5.1.4.1 indicates the functions available to the identified roles. These functions are restricted by limiting the user interfaces to ‗see‘ only those functions that they are allowed to access. If a user is limited based on the organization hierarchy, they cannot perceive organizations that are outside their scope of access. If a user is limited to specific functions, they will be provided options only to access the functions they are allowed to use. The Security management function is designed to satisfy the following security functional requirements:  FMT_MOF.1: The TOE restricts the TOE management functions to the authorized user. (please see table in section 5.2.4.1).  FMT_SMF.1: The TOE is able to perform the following security management functions: management of the Console Access Control FSP, management of user accounts, management of AppDetective tasks and data.  FMT_SMR.1: The TOE maintains super user, admin user, and basic user and view user roles. Security Target Version 1.0, 05/16/2012 33 Security Target Version 1.0, 05/16/2012 34 7. Protection Profile Claims There are no Protection Profile claims in this Security Target. Security Target Version 1.0, 05/16/2012 35 8. Rationale This section provides the rationale for completeness and consistency of the Security Target. The rationale addresses the following areas:  Security Objectives;  Security Functional Requirements;  Security Assurance Requirements;  Requirement Dependencies; and  TOE Summary Specification. 8.1 Security Objectives Rationale This section shows that all secure usage assumptions, organizational security policies, and threats are completely covered by security objectives. In addition, each objective counters or addresses at least one assumption, organizational security policy, or threat. 8.1.1 Security Objectives Rationale for the TOE and Operational Environment This section provides evidence demonstrating the coverage of organizational policies, threats, and usage assumptions by the security objectives. P.ACCACT P.DETECT P.MANAGE T.COMDIS T.COMINT T.FACCNT T.IMPCON T.LOSSOF T.NOHALT T.PRIVIL T.SCNCFG T.SCNVUL A.ACCESS A.DYNMIC A.LOCATE A.MANAGE A.NOEVIL O.ACCESS X X X X X X X X X O.AUDITS X X O.EADMIN X O.IDACTS X X X O.IDENT X X X X X X X X O.PROTCT X X X X X OE.AUDIT X OE.CREDEN X X OE.IDAUTH X X X X X X X OE.INSTAL X X X OE.INTROP X X OE.PERSON X X X OE.PHYCAL X OE.PROTECT X X X X OE.REVIEW X X OE.TIME X OE.TRANSMIT X X Table 3 Environment to Objective Correspondence 8.1.1.1 P.ACCACT Users of the TOE shall be accountable for their actions. This Organizational Policy is satisfied by ensuring that:  O.AUDITS: The O.AUDITS objective implements this policy by requiring auditing of scan data accesses and use of the primary IDS TOE functions. Security Target Version 1.0, 05/16/2012 36  O.IDENT: The O.IDENT objective supports this policy by ensuring each user is uniquely identified.  OE.REVIEW: The OE.REVIEW objective supports this policy by ensuring the operational environment of the TOE provides the capability to review the generated TOE audit records.  OE.TIME: The OE.TIME objective supports this policy by ensuring a reliable time stamp is provided by the operational environment. 8.1.1.2 P.DETECT Configuration and vulnerability information that might be indicative of the potential for a future intrusion of a targeted IT System (database) must be collected This Organizational Policy is satisfied by ensuring that:  O.IDACTS: The O.IDACTS objective addresses this policy by requiring collection of scanned configuration and vulnerability data. 8.1.1.3 P.MANAGE The TOE shall only be managed by authorized users. This Organizational Policy is satisfied by ensuring that:  O.ACCESS: The O.ACCESS objective builds upon the O.IDENT and OE.IDAUTH objectives by only permitting authorized users to access TOE functions.  O.EADMIN: the O.EADMIN objective ensures there is a set of functions for administrators to use.  O.IDENT: The O.IDENT objective provides identification of users prior to any TOE function accesses.  OE.IDAUTH: The OE.IDAUTH environment objective in conjunction with O.IDENT provides authentication of users prior to any TOE access.  O.PROTCT: O.PROTCT objective addresses this policy by providing TOE self-protection.  OE.CREDEN: The OE.CREDEN objective requires administrators to protect all authentication data.  OE.INSTAL: The OE.INSTAL objective supports the O.PERSON objective by ensuring administrator follow all provided documentation and maintain the security policy.  OE.PERSON: The OE.PERSON objective ensures competent administrators will manage the TOE. 8.1.1.4 T.COMDIS An unauthorized user may attempt to disclose the data collected by the TOE by bypassing a security mechanism. This Threat is satisfied by ensuring that:  O.ACCESS: The O.ACCESS objective builds upon the O.IDAUTH objective by only permitting authorized users to access TOE data.  O.IDENT: The O.IDENT objective provides identification of users prior to any TOE function accesses.  OE.IDAUTH: The OE.IDAUTH environment objective in conjunction with O.IDENT provides authentication of users prior to any TOE access.  O.PROTCT: The O.PROTCT objective addresses this threat by providing TOE self-protection.  OE.TRANSMIT: The operational environment must protect the data transmitted between the TOE and operational environment components. 8.1.1.5 T.COMINT An unauthorized user may attempt to compromise the integrity of the data collected by the TOE by bypassing a security mechanism. This Threat is satisfied by ensuring that: Security Target Version 1.0, 05/16/2012 37  O.ACCESS: The O.ACCESS objective builds upon the O.IDAUTH objective by only permitting authorized users to access TOE data.  O.IDENT: The O.IDENT objective provides identification of users prior to any TOE function accesses.  OE.IDAUTH: The OE.IDAUTH environment objective in conjunction with O.IDENT provides authentication of users prior to any TOE access.  O.PROTCT: The O.PROTCT objective addresses this threat by providing TOE self-protection.  OE.TRANSMIT: The operational environment must protect the data in transmit between the TOE and operational environment components. 8.1.1.6 T.FACCNT Unauthorized attempts to access TOE data or security functions may go undetected. This Threat is satisfied by ensuring that:  O.AUDITS: The O.AUDITS objective counters this threat by requiring the TOE to audit attempts for data accesses and use of TOE functions.  OE.AUDIT: The OE.AUDIT objective ensures the operational environment of the TOE does its part in ensuring there is accountability for accessing the TOE executable and data.  OE.REVIEW: The OE.REVIEW objective supports this policy by ensuring the operational environment of the TOE provides the capability to review the generated TOE audit records. 8.1.1.7 T.IMPCON An unauthorized user may inappropriately change the configuration of the TOE causing potential vulnerability to go undetected. This Threat is satisfied by ensuring that:  O.ACCESS: The O.ACCESS objective builds upon the O.IDAUTH objective by only permitting authorized users to access TOE functions and data.  O.IDENT: The O.IDENT objective provides identification of users prior to any TOE function accesses.  OE.IDAUTH: The OE.IDAUTH environment objective in conjunction with O.IDENT provides authentication of users prior to any TOE access.  OE.INSTAL: The OE.INSTAL objective states the authorized administrators will configure the TOE properly. 8.1.1.8 T.LOSSOF An unauthorized user may attempt to remove or destroy data collected by the TOE. This Threat is satisfied by ensuring that:  O.ACCESS: The O.ACCESS objective builds upon the O.IDAUTH objective by only permitting authorized users to access TOE data.  O.IDENT: The O.IDENT objective provides identification of users prior to any TOE function accesses.  OE.IDAUTH: The OE.IDAUTH environment objective in conjunction with O.IDENT provides authentication of users prior to any TOE access.  O.PROTCT: The O.PROTCT objective addresses this threat by providing TOE self-protection. 8.1.1.9 T.NOHALT An unauthorized user may attempt to compromise the continuity of the collection functionality by halting execution of the TOE. This Threat is satisfied by ensuring that:  O.ACCESS: The O.ACCESS objective builds upon the O.IDAUTH objective by only permitting authorized users to access. Security Target Version 1.0, 05/16/2012 38  O.IDENT: The O.IDENT objective provides identification of users prior to any TOE function accesses.  OE.IDAUTH: The OE.IDAUTH environment objective in conjunction with O.IDENT provides authentication of users prior to any TOE access.  OE.PROTECT: The OE.PROTECT objective ensures that the environment provides a secure environment for the TOE. 8.1.1.10 T.PRIVIL A user may gain unauthorized access to TOE security functions and data. This Threat is satisfied by ensuring that:  O.ACCESS: The O.ACCESS objective builds upon the O.IDAUTH objective by only permitting authorized users to access TOE functions.  O.IDENT: The O.IDENT objective provides identification of users prior to any TOE function accesses.  OE.IDAUTH: The OE.IDAUTH environment objective in conjunction with O.IDENT provides authentication of users prior to any TOE access.  O.PROTCT: The O.PROTCT objective addresses this threat by providing TOE self-protection.  OE.PROTECT: The OE.PROTECT objective ensures that the environment provides a secure environment for the TOE. 8.1.1.11 T.SCNCFG Improper security configuration settings may exist in the IT system the TOE monitors. This Threat is satisfied by ensuring that:  O.ACCESS: The O.ACCESS objective builds on O.IDACTS by requiring the results of the scans to be accessible.  O.IDACTS: The O.IDACTS objective counters this threat by requiring the TOE collect and store vulnerability information that might be indicative of a configuration setting change. 8.1.1.12 T.SCNVUL Vulnerabilities may exist in the targeted IT System the TOE monitors. This Threat is satisfied by ensuring that:  O.ACCESS: The O.ACCESS objective builds on O.IDACTS by requiring the results of the scans to be accessible.  O.IDACTS: The O.IDACTS objective counters this threat by requiring the TOE collect and store configuration and vulnerability information that might be indicative of a vulnerability. 8.1.1.13 A.ACCESS The TOE has access to all the IT System data it needs to perform its functions. This Assumption is satisfied by ensuring that:  OE.INTROP: The OE.INTROP objective ensures the TOE has the needed access. 8.1.1.14 A.DYNMIC The TOE will be managed in a manner that allows it to appropriately address changes in the IT System the TOE monitors. This Assumption is satisfied by ensuring that:  OE.INTROP: The OE.INTROP objective ensures the TOE has the proper access to the IT System. Security Target Version 1.0, 05/16/2012 39  OE.PERSON: The OE.PERSON objective ensures that the TOE will managed appropriately. 8.1.1.15 A.LOCATE The processing resources of the TOE will be located within controlled access facilities, which will prevent unauthorized physical and logical access. This Assumption is satisfied by ensuring that:  OE.PHYCAL: The OE.PHYCAL provides for the physical protection of the TOE.  OE.PROTECT: The OE.PROTECT objective ensures that the environment provides protection from logical attacks. 8.1.1.16 A.MANAGE There will be one or more competent individuals assigned to manage the TOE and the security of the information it contains. This Assumption is satisfied by ensuring that:  OE.PERSON: The OE.PERSON objective ensures all authorized administrators are qualified and trained to manage the TOE. 8.1.1.17 A.NOEVIL The authorized administrators are not careless, willfully negligent, or hostile, and will follow and abide by the instructions provided by the TOE documentation. This Assumption is satisfied by ensuring that:  OE.CREDEN: The OE.CREDEN objective supports this assumption by requiring protection of all authentication data.  OE.INSTAL: The OE.INSTAL objective ensures that the TOE is properly installed and operated. 8.2 Security Requirements Rationale This section provides evidence supporting the internal consistency and completeness of the components (requirements) in the Security Target. Note that Table 4 indicates the requirements that effectively satisfy the individual objectives. 8.2.1 Security Functional Requirements Rationale All Security Functional Requirements (SFR) identified in this Security Target are fully addressed in this section and each SFR is mapped to the objective for which it is intended to satisfy. O.ACCESS O.AUDITS O.EADMIN O.IDACTS O.IDENT O.PROTCT ADP_RDR_EX.1 X X ADP_SCN_EX.1 X ADP_PRT_EX.1 X FAU_GEN.1 X FIA_ATD.1 X FIA_UID.1 X FMT_MOF.1 X X FMT_SMF.1 X Security Target Version 1.0, 05/16/2012 40 FMT_SMR.1 X Table 4 Objective to Requirement Correspondence 8.2.1.1 O.ACCESS The TOE must allow authorized users to access only appropriate TOE functions and data. This TOE Security Objective is satisfied by ensuring that:  ADP_RDR_EX.1: The TOE must provide the ability for authorized administrators to view the Scanner data collected from an IT System.  FMT_MOF.1 (EXP): Only authorized user can perform the management functionality associated with their role as identified in FMT_MOF_EX.1.  FMT_SMR.1: The TOE must be able to recognize the different administrative and user roles that exist for the TOE. 8.2.1.2 O.AUDITS The TOE must record audit records for data accesses and use of the TOE functions. This TOE Security Objective is satisfied by ensuring that:  FAU_GEN.1: Security-relevant events (TOE data accesses and use of the TOE functions) must be defined and audited for the TOE. 8.2.1.3 O.EADMIN The TOE must include a set of functions that allow effective management of its functions and data. This TOE Security Objective is satisfied by ensuring that:  ADP_RDR_EX.1: The TOE must provide the ability for authorized administrators to view the DB Scan data collected from an IT System.  FMT_SMF.1: The TOE must be capable of performing the security management functions. 8.2.1.4 O.IDACTS The TOE must collect and store configuration and vulnerability information that might be indicative of the potential for a future intrusion of an IT System. This TOE Security Objective is satisfied by ensuring that:  ADP_SCN_EX.1: The Scanner is required to collect and store vulnerability and configuration information of an IT System. 8.2.1.5 O.IDENT The TOE must be able to identify users prior to allowing access to the TOE. This TOE Security Objective is satisfied by ensuring that:  FIA_UID.1: The TOE requires each user to identify itself before allowing any other TSF-mediated actions on behalf of that user.  FIA_ATD.1: Security attributes of subjects use to enforce the authentication policy of the TOE must be defined. 8.2.1.6 O.PROTCT The TOE must protect itself from unauthorized modifications and access to its functions and data via its own interfaces. Security Target Version 1.0, 05/16/2012 41 This TOE Security Objective is satisfied by ensuring that:  ADP_PRT_EX.1: The TOE is required to protect credentials used to scan target IT Systems.  FMT_MOF.1 : Only authorized user can perform the management functionality of the TOE identified in the table in FMT_MOF.1.  8.3 Security Assurance Requirements Rationale EAL2 was selected as the assurance level because the TOE is a commercial product whose users require a low to moderate level of independently assured security. Application Security, DbProtect AppDetective is targeted for an environment with good physical access security and competent administrators. Within such environment, it is assumed that attackers will have little attack potential. As such, EAL2 is appropriate to provide the assurance necessary to counter the limited potential for attack. EAL2 is augmented with ALC_FLR.2, Flaw reporting procedures to provide instructions to users for reporting flaws, to provide internal vendor procedures for identifying, tracking and correcting product flaws. 8.4 Requirement Dependency Rationale The following table identifies the dependencies of the requirements in this ST, including the extended requirements defined in this ST. As indicated in the table, all of the dependencies are satisfied, except those identified in [bold- red-bracketed] text. ST Requirement CC Dependencies ST Dependencies ADP_PRT_EX.1 none none ADP_RDR_EX.1 ADP_SCN_EX.1 ADP_SCN_EX.1 ADP_SCN_EX.1 FPT_STM.1 [FPT_STM.1] FAU_GEN.1 FPT_STM.1 [FPT_STM.1] FIA_ATD.1 none none FIA_UID.1 none none FMT_MOF.1 FMT_SMR.1 and FMT_SMF.1 FMT_SMR.1 and FMT_SMF.1 FMT_SMF.1 none none FMT_SMR.1 FIA_UID.1 FIA_UID.1 ADV_ARC.1 ADV_FSP.1 and ADV_TDS.1 ADV_FSP.2 and ADV_TDS.1 ADV_FSP.2 ADV_TDS.1 ADV_TDS.1 ADV_TDS.1 ADV_FSP.2 ADV_FSP.2 AGD_OPE.1 ADV_FSP.1 ADV_FSP.2 AGD_PRE.1 none none ALC_CMC.2 ALC_CMS.1 ALC_CMS.2 ALC_CMS.2 none none ALC_DEL.1 none none ALC_FLR.2 none none ATE_COV.1 ADV_FSP.2 and ATE_FUN.1 ADV_FSP.2 and ATE_FUN.1 ATE_FUN.1 ATE_COV.1 ATE_COV.1 ATE_IND.2 ADV_FSP.2 and AGD_OPE.1 and AGD_PRE.1 and ATE_COV.1 and ATE_FUN.1 ADV_FSP.2 and AGD_OPE.1 and AGD_PRE.1 and ATE_COV.1 and ATE_FUN.1 AVA_VAN.2 ADV_ARC.1 and ADV_FSP.2 and ADV_TDS.1 and AGD_OPE.1 and AGD_PRE.1 ADV_ARC.1 and ADV_FSP.2 and ADV_TDS.1 and AGD_OPE.1 and AGD_PRE.1 Table 5 Requirement Dependencies The TOE relies on the environment to provide reliable time stamps per OE.TIME. As such, the missing dependency identified in the table above is satisfied with an objective for the operational environment of the TOE. Security Target Version 1.0, 05/16/2012 42 8.5 TOE Summary Specification Rationale Each subsection in Section 6, the TOE Summary Specification, describes a security function of the TOE. Each description is followed with rationale that indicates which requirements are satisfied by aspects of the corresponding security function. The set of security functions work together to satisfy all of the security functions and assurance requirements. Furthermore, all of the security functions are necessary in order for the TSF to provide the required security functionality. This Section in conjunction with Section 6, the TOE Summary Specification, provides evidence that the security functions are suitable to meet the TOE security requirements. The collection of security functions work together to provide all of the security requirements. The security functions described in the TOE summary specification are all necessary for the required security functionality in the TSF. Table 6 Security Functions vs. Requirements Mapping demonstrates the relationship between security requirements and security functions. Database Discovery and Scanning Security audit Identification and authentication Security management ADP_RDR_EX.1 X ADP_SCN_EX.1 X ADP_PRT_EX.1 X FAU_GEN.1 X FIA_ATD.1 X FIA_UID.1 X FMT_MOF.1 X FMT_SMF.1 X FMT_SMR.1 X Table 6 Security Functions vs. Requirements Mapping