ST Version Date January 24, 2011 Version 1-12

Transcription

1 ST Version Date January 24, 2011 Version 1-12 SCAN S3 Security Manager Console Version 1.0 Release integrated with SCAN S3 Identity Services Infrastructure Version 1.0 and SCAN S3 Multi Authentication Version 1.0 Security Target Prepared for SCAN Associates Berhad Level 7, Menara Naluri, 161-B, Jalan Ampang, Kuala Lumpur By Teknimuda (M) Sdn Bhd Reference Number : S3-SMC-ST-V1-12

2 Table of Contents 1 SECURITY TARGET INTRODUCTION ST REFERENCE TOE REFERENCE TOE OVERVIEW Usage and Major Security Features of TOE TOE Type Non-TOE hardware/software/firmware TOE DESCRIPTION GENERAL OVERVIEW User Access Levels Scope and Boundaries of the TOE Acronyms CONFORMANCE CLAIM CC CONFORMANCE CLAIM PP CLAIM PACKAGE CLAIM CONFORMANCE RATIONALE SECURITY OBJECTIVES SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT EXTENDED COMPONENTS DEFINITION SECURITY REQUIREMENTS SECURITY FUNCTIONAL REQUIREMENTS Class FAU: Security Audit Class FDP: User Data Protection Class FIA: Identification and Authentication Class FMT: Security Management Class FTA: TOE Access SECURITY ASSURANCE REQUIREMENTS TOE SUMMARY SPECIFICATION SUMMARY SPECIFICATION RATIONALE TOE SUMMARY SPECIFICATION Security Audit User Data Protection Identification and Authentication Security Management TOE Access S3-SMC-ST January 2011 PAGE 1 of 3 SCAN Associates Bhd, 2011

3 FIGURES FIGURE 1 : SCAN S3 OVERVIEW 4 FIGURE 2 : TOE FOR 8 TABLES TABLE 1: SERVERS USED WITH SCAN S3SMC-ISI-MA APPLICATION 7 TABLE 2: REQUIREMENTS ON CLIENT MACHINE 7 TABLE 3 : SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT 15 TABLE 4 : TOE SECURITY FUNCTIONAL REQUIREMENTS 17 TABLE 5 : ADMINISTRATOR POLICY 21 TABLE 6 : TOE SECURITY ASSURANCE REQUIREMENTS: EAL1 25 TABLE 7 : MAPPING SECURITY FUNCTIONAL REQUIREMENTS TO SECURITY FUNCTIONS 26 S3-SMC-ST January 2011 PAGE 2 of 3 SCAN Associates Bhd, 2011

4 ST Version Change History Version Pages Affected Date Comments July 2010 First Issue August 2010 Second Issue Incorporate comments and feedback from clarification discussions and corrections of text as follows: a. Addition of TOE diagram b. Correction of attributes in SFRs c. Removed Security Objectives for TOE. d. Removed Security Problem Definition September September October October November November November 2010 Third Issue Incorporated alignment and corrections based on Evaluation Observation Report dated 8 September Fourth Issue Incorporated alignment and corrections based on Evaluation Observation Reports dated 17 September Further clarity provided that the SOFTCERT management is not part of the TOE. Only the assigned SOFTCERT certificate is used as-is for registration of new user ID and for user to login. Logs details listed in the TOE updated to confine to only those generatable or related to the TOE. TOE Type changed to Access Control Management. Fifth Issue Included ISI as part of TOE. Incorporated minor corrections raised in EOR3 dated 5 October Sixth Issue Incorporated minor corrections raised in EOR3 dated 20 October Seventh Issue Rephrased the TOE to include S3 SMC and S3 ISI and S3 MA. Eighth Issue Rephrased SFR statement for FMT_MSA.1 Ninth Issue Rephrased OE.AUTH & OE.TRAIN statements SCAN S3-SMC-ISI-MA ST January 2011 PAGE 1 of 30

5 November January January 2011 Tenth Issue Rename the TOE Title Eleventh Issue Fixed System and Software versioning Twelfth Issue Remove refinement for FTA_SSL and update document versioning Add note at table 4 to justify FPT_STM not included in the requirement. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 2 of 30

6 1 SECURITY TARGET INTRODUCTION 1.1 ST Reference This section provides ST control and identification information. ST Title: SCAN S3 Security Manager Console V1.0 Release integrated with SCAN S3 Identity Service Infrastructure V1.0 and SCAN S3 Multi Authentication V1.0 Security Target ST Version: 1-12 ST Date: January 24, 2011 ST Authors: CC Identification: Assurance Level: 1.2 TOE Reference A Fattah Yatim, Mohd Zahari Zakaria Common Criteria for Information Technology Security Evaluation, Version 3.1 Revision 3, July 2009 Evaluation Assurance Level 1 (EAL1) This section provides TOE control and identification information. TOE Identification: Development Tools: Java Java Servlet Java Applet JSP Eclipse Tortoise SVN SCAN S3 Security Manager Console Version 1.0 Release integrated with SCAN S3 Identity Service Infrastructure Version 1.0 and SCAN S3 Multi Authentication Version 1.0 Developer: SCAN Associates Bhd Level 7, Menara Naluri, 161-B Jalan Ampang Kuala Lumpur Malaysia SCAN S3-SMC-ISI-MA ST January 2011 PAGE 3 of 30

7 1.3 TOE Overview SCAN S3 Security Manager Console integrated with SCAN S3 Identity Service Infrastructure V1.0 and SCAN S3 Multi Authentication or for short, is the product developed by SCAN Associates Bhd to assist in designing, implementing and maintaining a coherent suite of processes and systems for effectively managing information accessibility. The simplified SCAN S3 setup is shown in the following figure: Figure 1 : SCAN S3 Overview The TOE is the SCAN S3 SMC, SCAN S3 ISI and SCAN S3 MA enclosed in the green boxes and in combination is referred to as. The SCAN S3 or SCAN Shared Security Services design principles are as follows: It is positioned as a platform and not designed to be stand alone; Completely Web Services implementation; Compliance to Malaysian Government s classified information handling handbook BlackBook ; Risk based authentication; Supports multiple authentication mechanisms; SCAN S3-SMC-ISI-MA ST January 2011 PAGE 4 of 30

8 PKI key is able to roam from system to system. The SCAN S3 or SCAN Shared Security Services comprises three components or services: a. SCAN S3 Identity Service Infrastructure or SCAN S3 ISI, b. SCAN S3 Multi Authentication or SCAN S3 MA and c. SCAN S3 Security Manager Console or SCAN S3 SMC The features of these are as follows: SCAN S3 Identity Service Infrastructure (ISI) Allows the PKI key (soft token) to roam from system to system Note that generation of PKI key is OUTSIDE of the SCAN S3. Also due to general requirement for PKI system, preferred implementation is to tie to a licensed CA for Digital Signature Act 1997 enforcement SCAN S3 Multi Authentication (MA) Supports multiple authentication mechanisms in a single system E.g. SMS token, PKI token, soft token, security question etc SCAN S3 Security Manager Console (SMC) Centralized administration of logon IDs Centralized policy configuration Centralized collection of logging of events. The SCAN S3 SMC V1.0 Release 14556, which is the first element of the TOE, is the security administration console to set up the user authorisation parameters, defining the users authentication mode as well as the workstation and risk policy. The SCAN S3 ISI V1.0 is used for roaming and will only be implemented if the client organisation requires roaming facility. Hence it is an optional implementation item. However for this ST, the SCAN S3 ISI is included. The authentication mode for a particular user will be obtained during login by the user where the SCAN S3 MA V1.0, the last element of the TOE, will obtain the necessary parameters from the SCAN S3 SMC server database. See figure 1 above. In this document the name SCAN S3 used on its own refers to the overall S3 application covering the three services mentioned above, whereas the name specifically refers to the SCAN S3 Security Manager Console, integrated with the SCAN S3 Identity Services Infrastructure and the SCAN S3 Multi Authentication, which is the TOE. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 5 of 30

9 1.3.1 Usage and Major Security Features of TOE SCAN S3 is a platform that consolidates various security services into a single enterprise-wide architecture. SCAN S3 helps to mitigate the security risks when implementing an Enterprise Application and e-services. In traditional implementations, clients or customers will need to have different accesses to different products or systems and the management of these separate application accesses can be an administrative burden. This also can lead to unnecessary exposure to security leakages if accesses to different systems that are linked or integrated are not implemented according to a consistent policy. With the multiple options or permutations available in the above implementation, the SCAN S3 SMC-ISI-MA enables the organization to manage the overall security through a single framework that enables the defining and assignment or implementation of the following security functions in one system: 1. Security Audit 2. User Data Protection 3. Identification, authentication and authorization 4. Security Management 5. TOE Access TOE Type The TOE type is Web Based Application for Access Control Management. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 6 of 30

10 1.3.3 Non-TOE hardware/software/firmware Server System Requirements Table 1: Servers Used with Application Type of Server Description Database server Application Server Preferred OS Hardware Requirements MySQL 5.0 Database Tomcat6.0 - Tomcat Application Server Enterprise Java Beans (EJB) Application server that hosts all the software and Application for the system component Centos5.0 or Windows 2003 Server SP2 Intel (R) Pentium (R) M Processor 1.60 GHz 220 MHz, 2.00 GB of RAM System and Software Requirements Table 2: Requirements on Client machine Item Minimum Requirements Operating Systems Windows XP Service Pack 2 Hardware Requirements Intel (R) Pentium (R) M Processor 1.60 GHz 220 MHz, 2.00 GB of RAM Web Browsers Mozilla Firefox [v 3.5], Internet Explorer [v 8.0], Google Chrome [v 8.0] Monitor Mouse/Pointing Device Dual Boot Systems Archive Utility Application Documentation SVGA - compatible display (256 or more colors recommended) with resolution of at least 1024 X 768 pixels Any pointing device with at least two buttons Installation of SMC application on dual-boot systems is not supported WinZip or equivalent Adobe Acrobat Reader 4 to read online PDF files. Java Requirement JRE Firmware None. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 7 of 30

11 Security Target Version TOE Description This section and subsections provide TOE description, starting with an overview of the SCAN S3 SMC-ISI-MA application features overall with further details in the subsequent sections. The SCAN S3 SMC-ISI-MA system is depicted in the following diagram with the TOE in the green dasheddashed lined box. Figure 2 : TOE For As identification, authorization and authentication are three important processes during user use login in the TOE, the he following is the description of the login process for the TOE which is only for the Staff functions with reference to Figure 2 (see also Section 1.5). Staff will login through an interface presented by an applet (Step ( 1B) which will facilitate the Identity Confirmation (Step 2A), Authorisation (Step ( 3) and Authentication (Step 4A) before confirming the Role (Step 5) and allowing the Staff to use the system according to his role (Step 6). The details of the steps are as follows: a. The login screen will be presented by the applet in the SCAN S3 SMC-ISI ISI-MA system (Path 1B). b. Upon entering the User ID, with roaming as the default option, the applet will Load the P12 certificate from the SOFTCERT database (steps 2A and 2B) (Third party CA system) which is located in the ISI server. REFERENCE ST VERSION DATE PAGE SCAN S3-SMC-ISI-MA ST January 2011 PAGE 8 of 30

12 c. The user is prompted to key in a PIN. When the correct PIN is entered, the Key Label field in the Login screen will be filled from the SOFTCERT that was decrypted by the correct PIN. This process verifies the identity of the user (Step 2A) as the correct owner of the P12 private key and certificates. d. The user will click the Submit button, following which the applet will get confirmation from the SCAN S3 SMC Database that the user is indeed registered in the SCAN S3 SMC database (Step 3) and get the authorization on what the user is allowed to do for authentication. Note the SCAN S3 SMC database is specifically for the SCAN S3 SMC environment. e. For Staff functions, the Staff is to be authenticated via the Multi Authentication service (Step 4A). This will present the digital signature (decrypted from SOFTCERT) to be verified with the certificate in the Certificate Storage (Step 4B). f. Upon successful authentication, the Staff s role will be verified through the SCAN S3 SMC database (Step 5). g. When the Staff role is obtained the Staff is able to carry out his functions in the SCAN S3 SMC environment in the red dotted box in Figure 2 (Path 6). Details on the screen buttons, i.e. Load, Submit and the fields i.e. User ID, PIN, Key Label, are illustrated in the User Manual. SOFTCERT P12 private key and certificate has been prepared and stored with the SCAN S3 ISI. Likewise the certificate for authentication in the SCAN S3 MA is also provided and stored with the SCAN S3 MA. Management and generation of P12 for identification and the certificate for authentication is not part of the TOE. 1.5 General overview is a system that provides centralized authentication and audit services for users to securely access different applications. It also provides centralized policy management services for administrators to manage policy of components. The roles which manage the functionalities within the TOE are: o o System Administrator Role that provides the administration of confined (in this TOE) to the management i.e. creation, update, delete of System Administrator ID and Log Administrator ID. Log Administrator Role which will allow the authorized administrators (Log Administrator) to view and generate audit reports User Access Levels In the documentation and system, the term Users are all registered users which includes actual end users of the SCAN S3 System as well as those with Staff or Administrator roles. Staff or Administrator is used to refer to the people registered in the system that perform the System Administrator role and the Log Administrator role in SCAN S3 SMC-ISI- MA. Hence the System Administrator role and the Log Administrator role are generally referred as Staff roles. This section describes the different users and / or user groups and the restrictions placed on the application accessibility. Users allowed to access the SCAN S3 SMC functions (in red dotted box in Figure 2) are limited to Log Administrator, System Administrator and Policy Manager. However, Policy Manager is not part of TOE scope. For the purpose of authorisation, all Users will be SCAN S3-SMC-ISI-MA ST January 2011 PAGE 9 of 30

13 compared with the SCAN S3 SMC database records to determine that the user is registered and hence authorised in the system. The use of User ID and PIN to access the soft token ensure that only identified and authorized users can access the. The term user used in the Security Functional Requirements Section 5.1 and TOE Summary Specifications Section 6 of this document therefore refers only to the System Administrator and Log Administrator roles System Administrator System administrator is one of the roles that use the application. The roles of system administrator include: Manage staff, Manage staff role, Manage user, Search user, Manage authentication method for users other than Staff roles Policy Manager (Not part of TOE scope) Log Administrator Policy manager is the second role that uses the application. The roles of policy manager include: Manage trusted configuration policy, Manage workstation policy, Manage bind workstation, Manage risk policy. Log Administrator is the last role that uses the application. The roles of log administrator include: Manage log covering o o o Manage transaction log, Manage security log, Manage error log. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 10 of 30

14 1.5.2 Scope and Boundaries of the TOE This section describes both physical and logical boundaries of the TOE Physical Boundaries The physical boundary of the Application is the physical location of the servers. The SCAN S3 SMC is a software that sits on a physical server with a database that will be central to the whole security enforcement. The database will contain registered users information and their profile, policy information and the logs. Table 1 in Section lists the base hardware and software on which the SCAN S3 SMC-ISI- MA application is implemented. The application which is the TOE comes in the form of two files to be installed or deployed: a. ISI-SecurityManagerConsole.war b. mfa.sql. There is no TOE hardware. Applications like or document management system (not part of ) will be connected to interface with the Multi Authentication (MA) server and/or the Identity Service Infrastructure (ISI) server. Application users will need to login through their application which will force the user to be authenticated through the SCAN S3 SMC database that would contain the user profile and that would generate the necessary signals to prompt the user to login with one of three authentication methods, depending on the risk level during login. After successful authentication, a set of risk policy will be enforced on the user activity (what he can do and must do and what he cannot do) depending on workstation ID (location or IP address) and workstation configuration. This is beyond the scope of the TOE but is indicated briefly here for completeness and perspective Logical scope The logical scope of the TOE are all those functions in the covering the management of the security which involves registering users and staff, defining and assigning access privileges, the functions of which are covered in the System Administrator role. The activities of the System Administrator are logged and the Log Administrator will be able to review the logged events. The security functions covered in the logical scope of the TOE are defined as follows: 1. Security Audit The security audit function ensures that all System Administrator activity pertaining to creation/update/delete of Administrator or Staff logon IDs as well as the assignment of Administrator or Staff roles is logged. This activitiy is captured in the Security Log. The Transaction Log and Error Log are also produced when the appropriate activity that trigger transaction records and error records respectively take place. The Transaction Log, Security Log and Error Log described in more detail in Section User Data Protection User data is protected by ensuring that specific Administrator roles assigned by the administrator can only access specific screens and hence the data associated with the screens. Roles not authorized to access certain screens not within their role will therefore will not even be able to see those screens. The access is governed by the Administrator SCAN S3-SMC-ISI-MA ST January 2011 PAGE 11 of 30

15 Policy. The Administrator Policy allows the Administrator with System Administrator role to create logon IDs with System Administrator or Log Administrator. 3. Identification, authentication and authorization All administrators and users must have a valid logon ID and administrator role to access the. Administrators and users must logon on to identify themselves to the application together with the prompted (one of up to three) authentication means in order for them to gain access. However, this ST and evaluated configuration only covers SOFTCERT authentication mean. 4. Security Management All administrators must have a valid logon ID and Staff role to access the SCAN S3 SMC- ISI-MA. Administrators must logon on to identify themselves to the application together with the SOFTCERT in order for them to gain access. The System Administrator can create logon IDs for both Staff role and users. For the assignment of Staff roles, the System Administrator can assign an ID with only one Staff role. The System Administrator can also set a default password for the Staff role or to reset the password for the Staff role. The Log Administrator is able to manage the three types of transaction logs listed in Section TOE Access If a login session has remained idle for 18 minutes, the application will prompt the user a reminder whether to continue or to logoff. The system will automatically log out after 20 minutes of idle and the user will have to re-login to access the application again Audit Trails As audit trails form a key part of the security function, the types of logs and details are provided here. The logging can be enabled or disabled by the Log Administrator. The Log Administrator will also be able to do housekeeping of the logs by purging or archiving records beyond a specified time window. provides 3 types of logging which captures the time, date and associated initiator of the record, i.e. user or system: 1. Transaction Log, 2. Security Log, 3. Error Log, All SCAN S3 components access logs interface to record the activities of the components. Logs management Console page will enable view and generation of logs reports. All logs are stored in the SCAN S3 SMC database. The three logs are generated by SCAN S3 events as a whole, which includes SCAN S3 SMC-ISI-MA, where applicable, Transaction Log Transaction logs records all the transaction performed by SCAN S3 services or object which are: SCAN S3-SMC-ISI-MA ST January 2011 PAGE 12 of 30

16 o Execute SCAN S3 Services ie SCAN S3 ISI Service Security Log Application would generate logs for security related events which are : o o o o All Login failures, Use of administrator accounts ie System Administrator, Log Administrator, Changes to administrator permissions or privileges, Creation/deletion/disabling/enabling of all (administration) accounts Error Log SCAN S3 uses an error log to record error information when an unexpected condition or failure is detected within the SCAN S3 code. Such unexpected conditions are: o SCAN S3 Service communication error, o Programming defects in SCAN S3 code, o SCAN S3 error log contains failure information eg exception. From the information administrator may detect or identify the cause of problems. SCAN S3 log entries contain the following details: o Id user Id/ workstation Id, o Date date and time of activities, o IP Address IP Address of the workstation/ server, o Level Client or server, o Authentication Method restricted to SOFTCERT, o Status Failure or success or error message Acronyms The following abbreviations from the Common Criteria are used in this Security Target: CC Common Criteria for Information Technology Security Evaluation EAL Evaluation Assurance Level IT Information Technology PP Protection Profile SF Security Function SFR Security Functional Requirement SFP Security Function Policy ST Security Target TOE Target of Evaluation TSF TOE Security Functions SCAN S3-SMC-ISI-MA ST January 2011 PAGE 13 of 30

17 2 CONFORMANCE CLAIM 2.1 CC Conformance Claim This TOE conforms to the following CC specifications: Common Criteria for Information Technology Security Evaluation Part 1: Introduction and General Model, Version 3.1 Revision 3, July Conform to Common Criteria for Information Technology Security Evaluation Part 2: Security Functional Requirements, Version 3.1 Revision 3, July 2009 and no extended claims. Conform to Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance Requirements, Version 3.1 Revision 3, July 2009 and no extended claims. Evaluation Assurance Level 1 (EAL1) 2.2 PP Claim There is no PP Claim related to this ST. 2.3 Package Claim There ST claims a package for EAL Conformance Rationale As there is no PP Claim, the Conformance Rationale is not applicable. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 14 of 30

18 3 SECURITY OBJECTIVES 3.1 Security Objectives for the Operational Environment The security objectives countering security threats using the security policies enforced and the assumptions for the operational environment is described in Table 3. Table 3 : Security Objectives for The Operational Environment Name Description OE.AUTH OE.TRAIN OE.ENV Trusted users must be authorized by management before an ID and user role is being assigned for them to access and use the application in a secure manner. The operational environment shall ensure that all trusted TOE users receive appropriate training before allowing them to work with the TOE and follow the available guidance strictly; The operational environment will be secure and only logical access is allowed to the server. The application server is to be located in a secure area that is free from physical access to unauthorised parties. OE.INS The delivery and installation of the system will be made by authorized and trained personnel and the acceptance of the system will be made by the client based on predefined acceptance procedures. OE.TIME The operating system will provide reliable timestamp to the TOE. Note : This satisfies the reliable time stamp (FPT_STM.1) dependency required for FAU_GEN.1. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 15 of 30

19 4 EXTENDED COMPONENTS DEFINITION There is no extended component in this ST. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 16 of 30

20 5 SECURITY REQUIREMENTS 5.1 Security Functional Requirements The SFRs for the TOE are listed in Table 4. These requirements were derived from the CC Part 2 Security Functional Requirements. Table 4 : TOE Security Functional Requirements Security Functional Class Security Functional Components Dependency and Hierarchical Relationship Security Audit FAU User Data Protection FDP Identification and Authentication FIA Security Management FMT Note 1: TOE Access FTA FAU_GEN.1 Audit Data Generation. Dependent on FPT_STM.1 FAU_GEN.2 User Identity Association FAU_SAR.1 Audit review FAU_SAR.2 Restricted audit review FAU_SAR.3 Selectable audit review FDP_ACF.1 Security attribute based access control Dependent on FAU_GEN.1 and FIA_UID.1 Dependent on FAU_GEN.1 Dependent on FAU_SAR.1 Dependent on FAU_SAR.1 Dependent on FDP_ACC.1 and FMT_MSA.3 FDP_ACC.1 Subset access control Dependent on FDP_ACF.1 FIA_UAU.1 Timing of authentication Dependent on FIA_UID.1 FIA_UID.2 User identification before Hierarchical to FIA_UID.1 any action Timing of identification FMT_MSA.1 Management of Dependent on FDP_ACC.1 or security attributes FDP_IFC.1. FMT_MSA.3 Static attribute initialization FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security roles FTA_SSL.1 TSF-initiated session locking Dependent on FMT_SMR.1 and FMT_SMF.1 Dependent on FMT_MSA.1 and FMT_SMR.1 No dependency Dependency on FIA_UID.1 is covered by FIA_UID.2 Dependency on FIA_UAU.1 FIA_UID.2 is hierarchical to FIA_UID.1. FIA_UID.2 requires that a user be successfully authenticated via a valid logon ID and PIN before being able to do anything else. Hence FIA_UID.2 supersedes the need and covers the functions of FIA_UID.1. FPT_STM.1 is a dependency of FAU_GEN.1 that has not been included. Reliable time stamps are provided by the environment (OE.TIME). Time Stamps captured in TOE is derived from the operating system. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 17 of 30

21 Note 2 : 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: assignment, selection, and iteration. 1. The refinement operation is used to add detail to a requirement, and thus further restricts a requirement. Refinement of security requirements is denoted by bold underline text in red color font for addition and strikethrough for deletion text in red color. 2. The selection operation is used to select one or more options provided by the CC in stating a requirement. Selections are denoted by italicized text in square brackets, [selection value] in red color font. 3. The assignment operation is used to assign a specific value to an unspecified parameter, such as the length of a password. Assignment is indicated by showing the value in square brackets, [assignment value] in red color font. 4. The iteration operation is used when a component is repeated with varying operations. Iteration is denoted by showing the iteration number in parenthesis following the component identifier, (iteration number) in red color font. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 18 of 30

22 5.1.1 Class FAU: Security Audit FAU_GEN.1 Audit data generation Hierarchical to: Dependencies: No other components. FPT_STM.1 Reliable time stamps FAU_GEN.1.1 FAU_GEN.1.2 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) [events listed in audit trails section for Transaction Log, section for Security Log and section for Error Log ]. 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, [events listed in audit trails section for Transaction Log, section for Security Log and section for Error Log]. FAU_GEN.2 User identity association Hierarchical to: No other components. Dependencies: FAU_GEN.1 Audit data generation FIA_UID.1 Timing of identification FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be able to associate each auditable event with the identity of the user that caused the event. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 19 of 30

23 FAU_SAR.1 Audit review FAU_SAR.1.1 FAU_SAR.1.2 Hierarchical to: No other components. Dependencies: FAU_GEN.1 Audit data generation This component will provide authorised users the capability to obtain and interpret the information. In case of human users this information needs to be in a human understandable presentation. In case of external IT entities the information needs to be unambiguously represented in an electronic fashion. The TSF shall provide [Log Administrator] with the capability to read [transaction log, security log and error log] from the audit records. The TSF shall provide the audit records in a manner suitable for the user to interpret the information. FAU_SAR.2 Restricted audit review FAU_SAR.2.1 Hierarchical to: Dependencies: No other components. FAU_SAR.1 Audit review The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access. FAU_SAR.3 Selectable audit review FAU_SAR.3.1 Hierarchical to: No other components. Dependencies: FAU_SAR.1 Audit review The TSF shall provide the ability to apply [selection and ordering] of audit data based on [date range of event captured and/or ID specified]. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 20 of 30

24 5.1.2 Class FDP: User Data Protection FDP_ACF.1 Security attribute based access control FDP_ACF.1.1 FDP_ACF.1.2 FDP_ACF.1.3 FDP_ACF.1.4 Hierarchical to: Dependencies: No other components. FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation The TSF shall enforce the [Administrator Policy] to objects based on the following: [System Administrator role and Log Administrator role]. The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [user must have a valid ID and role assigned and PIN to confirm the soft certificate ]. The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [none ]. The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [none]. FDP_ACC.1 Subset access control Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1 The TSF shall enforce the [Administrator Policy shown in the table below] on [System Administrator role and Log Administrator role ]. Table 5 : Administrator Policy Subjects/Role System Administrator Log Administrator Operation Enabled to create, delete and update user particulars in user account and assign a user role. Enabled to view logs of all activities performed by users. The logs will have details on all activities including error and debug information. Enable to search of logs by date range. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 21 of 30

25 5.1.3 Class FIA: Identification and Authentication FIA_UAU.1 Timing of authentication FIA_UAU.1.1 FIA_UAU.1.2 Hierarchical to: Dependencies: No other components. FIA_UID.1 Timing of identification The TSF shall allow [ Soft certificate login authentication] on behalf of the user to be performed before the user is authenticated. The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. FIA_UID.2 User identification before any action FIA_UID.2.1 Hierarchical to: Dependencies: FIA_UID.1 Timing of identification No dependencies. The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 22 of 30

26 5.1.4 Class FMT: Security Management FMT_MSA.1 Management of security attributes Hierarchical to: Dependencies: No other components. FDP_ACC.1 Subset access control FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_MSA.1.1 The TSF shall enforce the [Administrator Policy] to restrict the ability to [create, modify, delete] the security attributes [user ID, password, role] to [System Administrator role]. FMT_MSA.3 Static attribute initialisation Hierarchical to: Dependencies: No other components. FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1 The TSF shall enforce the [Administrator Policy] to provide [ restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2 The TSF shall allow the [System Administrator role] to specify alternative initial values to override the default values when an object or information is created. FMT_SMF.1 Specification of Management Functions Hierarchical to: Dependencies: No other components. No dependencies. FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [creation of user Ids, assigning administrator roles]. FMT_SMR.1 Security roles Hierarchical to: Dependencies: No other components. FIA_UID.1 Timing of identification FMT_SMR.1.1 The TSF shall maintain the roles [System Administrator role and Log Administrator role ]. FMT_SMR.1.2 The TSF shall be able to associate users with roles. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 23 of 30

27 5.1.5 Class FTA: TOE Access FTA_SSL.1 TSF-initiated session locking FTA_SSL.1.1 Hierarchical to: Dependencies: No other components. FIA_UAU.1 Timing of authentication The TSF shall lock an interactive session after [20 mins of user inactivity] by: a) clearing or overwriting display devices, making the current contents unreadable; b) disabling any activity of the user's data access/display devices other than unlocking the session. FTA_SSL.1.2 The TSF shall require the following events to occur prior to unlocking the session: [Re-login]. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 24 of 30

28 5.2 Security Assurance Requirements The security assurance components drawn from CC Part 3 Security Assurance Requirements EAL 1 are identified in Table 6. Table 6 : TOE Security Assurance Requirements: EAL1 Assurance Class ADV: Development AGD: Guidance documents ALC: Life-cycle support ASE: Security Target evaluation ATE: Tests AVA: Vulnerability assessment Assurance components ADV_FSP.1 Basic functional specification AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ALC_CMC.1 Labelling of the TOE ALC_CMS.1 TOE CM coverage ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.1 Security objectives for the operational environment ASE_REQ.1 Stated security requirements ASE_TSS.1 TOE summary specification ATE_IND.1 Independent testing conformance AVA_VAN.1 Vulnerability survey SCAN S3-SMC-ISI-MA ST January 2011 PAGE 25 of 30

29 6 TOE SUMMARY SPECIFICATION This Chapter presents a functional overview of the TOE; the security functions implemented by the TOE; and the Assurance Measures applied to ensure their correct implementation. 6.1 Summary Specification Rationale The TOE Summary Specification chapter describes every Security Function (SF) of the TOE, meeting the requirements of every SFR. Within the description of the SF, a rationale is provided. All the SFs are presented in Table 7; this table maps SFRs to SFs. This demonstrates that the Security Functions fulfil every SFR. Table 7 : Mapping Security Functional Requirements to Security Functions SFR SECURITY FUNCTIONS SECURITY AUDIT USER DATA PROTECTION IDENTIFICATION AND AUTHENTICATION SECURITY MANAGEMENT TOE ACCESS FAU_GEN.1 FAU_GEN.2 FAU_SAR.1 FAU_SAR.2 FAU_SAR.3 FDP_ACF.1 FDP_ACC.1 FIA_UAU.1 FIA_UID.2 FMT_MSA.1 FMT_MSA.3 FMT_SMF.1 FMT_SMR.1 FTA_SSL.1 X X X X X X X X X X X X X X SCAN S3-SMC-ISI-MA ST January 2011 PAGE 26 of 30

30 6.2 TOE Summary Specification This Section presents the security functions performed by the TOE to satisfy the identified SFRs in Section Security Audit FAU_GEN.1 Audit data generation Audit trail data as listed in section is generated for the Transaction Log, Error Log and Security Log. These would be sufficient for the Log Administrator to review and generate reports. The logging can be enabled or disabled by the Log Administrator. The Log Administrator will also be able to do housekeeping of the logs by purging or archiving records beyond a specified time window. The audit data generation function addresses this requirement. FAU_GEN.2 User Identity Association Audit trail data pertaining to Administrator activity and user login and logout are logged and associated with the respective user Ids. The audit data generation function addresses this requirement. FAU_SAR.1 Audit review Log Administrator is able to review audit records generated and follow up on any action to be taken. The audit review function addresses this requirement. FAU_SAR.2 Restricted audit review Review of audit records is restricted to Log Administrator only. The restricted audit review function addresses this requirement. FAU_SAR.3 Selectable audit review Log Administrator can select or filter audit records by date range to enable quick focus on records that may warrant attention. The selectable audit review function addresses this requirement. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 27 of 30

31 6.2.2 User Data Protection FDP_ACF.1 Security Attribute Based Access Control Access to the application functions is controlled by the user role assigned to the user. The user role must be assigned by the System Administrator upon approval through procedures outside of the application. This is controlled by the Administrator Policy. The user data protection function addresses this requirement. FDP_ACC.1 Subset Access Control Access to the application functions is controlled by the user role assigned to the user. The user role must be assigned by the System Administrator upon approval through procedures outside of the application. The user data protection function addresses this requirement Identification and Authentication FIA_UAU.1 Timing of Authentication To prevent unauthorized access to the TOE functions as well as reliable accountability for authorized administrator use of security functions, the require authorized administrators to perform authentication before they may access any of the TOE functions or data. Before authentication, the administrator will only see the login screen where he can key in his login ID, followed by the PIN to be entered to access the soft certificate. The security identification and authentication function addresses this requirement. FIA_UID.2 User Identification before any Action To prevent unauthorized access to the TOE functions as well as reliable accountability for authorized administrator (System Administrator and Log Administrator ) use of security functions, an authorized administrator has to identify and authenticate through a login interface before any action on the. When accessing the, the authorised administrator will be prompted for his/her login ID and soft certificate PIN for authentication purposes before any other action on the console. The security identification and authentication function addresses this requirement. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 28 of 30

32 6.2.4 Security Management FMT_MSA.1 Management of security attributes The administrator s assignment to a role has to be unique whereby different administrator are required for each role. Through the assignment of administrator roles by the System Administrator, the administrator is authorised and restricted to perform the appropriate functions of creation, update and delete of information within the appropriate role boundary. The functions for each role are as follows: a. System Administrator is also able to create, modify and delete Staff and User ID and Staff and User information. b. The Log Administrator is able to view and generate audit reports. The security management function addresses this requirement. FMT_MSA.3 Static attribute initialisation For initialization of, a default Login Id and soft certificate is provided to perform the creation of initial System Administrator. The System Administrator is responsible to create other administrator IDs. The default login needs to be deleted by the new System Administrator. The functions for each role are as follows: a. System Administrator is also able to create, modify and delete Staff and User ID and Staff and User information. b. The Log Administrator is able to view and generate audit reports. The security management function addresses this requirement. FMT_SMF.1 Specification of Management Functions The System Administrator is able to create and delete administrator Ids, modify administrator information and assign administrator roles as appropriate. An administrator can have only one role at a time. The functions are as follows: a. System Administrator is also able to create, modify and delete Staff and User ID and Staff and User information. b. The Log Administrator is able to view and generate audit reports. The security management function addresses this requirement. FMT_SMR.1 Security roles The System Administrator is able to assign administrator roles (System Administrator or Log Administrator as appropriate. An administrator can have only one role at a time. The security management function addresses this requirement. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 29 of 30

33 6.2.5 TOE Access FTA_SSL.1 Session locking When there is inactivity of a user session for up to 20 mins, the system will automatically prompt a reminder indicating session is almost expiring. User selects whether to end or proceed with the session. Upon ending the session, the user needs to re-login to access again. The TOE Access function addresses this requirement. SCAN S3-SMC-ISI-MA ST January 2011 PAGE 30 of 30