iDeras Security Target Document Version: v1.3 Document Date:18 October 2013 Company Infosys Gateway SdnBhd Unit 808, 8th Floor, Block E, PusatDaganganPhileo, Damansara 1, No. 9, Jalan 16/11, Off JalanDamansara 46350 Petaling Jaya, Selangor. MALAYSIA. iDeras Security Target Document Revision History Version Date Prepared By Description d1 03 Oct 2012 Infosys Initial draft. d2 09 January 2013 Infosys Updating info based on EOR d3 14 August 2013 Infosys Updating info based on EOR v1 06 September 2013 Infosys Final v1.1 06 September 2013 Infosys Updated based upon Peer Review v1.2 20 September 2013 Infosys Updated based upon Peer Review v1.3 18 October 2013 Infosys Update based upon Peer Review and comments from MyCB iDeras Security Target Page | 3 Table of Contents 1 Document Overview........................................................................................................................5 2 Security Target Introduction ............................................................................................................5 2.1 Security Target Reference ........................................................................................................5 2.2 TOE Reference .........................................................................................................................5 2.3 Terminology and Acronyms......................................................................................................6 2.4 Reference ................................................................................................................................6 2.5 TOE Overview ..........................................................................................................................7 2.5.1 Usage and major security features of the TOE ..................................................................7 2.5.2 TOE Type..........................................................................................................................7 2.5.3 Non-TOE hardware/software/firmware required by the TOE............................................8 2.6 TOE Description .......................................................................................................................9 2.6.1 Physical Scope of TOE.......................................................................................................9 2.6.2 Logical Scope of TOE.......................................................................................................11 2.6.3 Product features not included in scope...........................................................................13 3 Conformance Claims......................................................................................................................13 4 TOE Security Problem Definition....................................................................................................14 4.1 Assumption............................................................................................................................14 4.2 Threats...................................................................................................................................14 4.3 Organizational Security Policies.............................................................................................. 15 5 Security Objectives ........................................................................................................................16 5.1 Security Objectives for the TOE .............................................................................................. 16 5.2 Security Objectives for the Operational Environment............................................................. 16 6 Extended Components...................................................................................................................18 6.1 Extended Security Functional Requirement (SFR) ...................................................................18 6.1.1 Class FAU: Security Audit................................................................................................ 19 6.1.2 Class FPT: Protection of the TSF......................................................................................19 6.2 Extended Security Assurance Requirement (SAR) ...................................................................19 7 TOE Security Functional Requirements ..........................................................................................20 7.1 Conventions...........................................................................................................................20 7.2 Security Functional Requirements..........................................................................................21 7.2.1 Class FAU: Security Audit................................................................................................ 22 iDeras Security Target Page | 4 7.2.2 Class FDP: User Data Protection......................................................................................24 7.2.3 Class FIA: Identification and Authentication....................................................................26 7.2.4 Class FMT: Security Management...................................................................................27 7.2.5 Class FPT: Protection of the TSF......................................................................................30 7.3 Security Assurance Requirements ..........................................................................................31 8 TOE Summary Specifications..........................................................................................................32 8.1 Identification and Authentication...........................................................................................32 8.2 User Data Protection..............................................................................................................33 8.3 Security Management............................................................................................................33 8.4 Security Audit.........................................................................................................................34 8.5 Protection of the TSF..............................................................................................................35 9 Rationale .......................................................................................................................................36 9.1 Protection Profile Conformance Claim Rationale....................................................................36 9.2 Security Objectives Rationale .................................................................................................36 9.2.1 Rationale for Security Objectives Mapped to Threats......................................................36 9.2.2 Rationale Security Objectives Mapped to OSP Rationale.................................................38 9.2.3 Rationale Security Objectives Mapped to Assumptions...................................................39 9.3 Extended Security Functional Requirement Rationale ............................................................40 9.4 Extended Security Assurance Requirement Rationale............................................................. 40 9.5 Security Functional Requirements Rationale ..........................................................................41 9.5.1 Rationale for SFR Mapped to Security Objectives for TOE ...............................................41 9.5.2 SFR Dependency Rationale ............................................................................................. 44 9.6 Security Assurance Requirements Rationale...........................................................................45 iDeras Security Target Page | 5 1 Document Overview This document is the Security Target (ST) for the iDeras Unified Threat Management (UTM). The ST is designed to meet the requirements of the CC ASE Class for EAL2, and provides a baseline for the subsequent phases of Target of Evaluation (TOE) evaluation works. This ST contains the following sections:  Security Target Introduction: Provides an overview of the TOE security functions and describes the physical and logical scope for the TOE;  Conformance Claims: provides the ST claims of conformance to CC packages;  TOE Security Problem Definition: Describes the threats, organizational security policies, and assumptions that pertain to the TOE and the TOE environment;  Security Objectives: Identifies the security objectives that are satisfied by the TOE and the TOE environment;  Security Requirements: Presents the Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) met by the TOE; and  TOE Summary Specification: Describes the security functions provided by the TOE to satisfy the security requirements and objectives; and  Rationale: Presents the rationale for the security objectives, requirements, and the TOE summary specifications as to their consistency, completeness, and suitability. 2 Security Target Introduction 2.1 Security Target Reference Security Target Title : iDeras Security Target Security Target Version : v1.3 Security Target Date : 18 October 2013 2.2 TOE Reference TOE Name : iDeras Unified Threat Management (UTM) Hardware Appliance version : ID-1208 (Type: 2U), ID-2016 (Type: 4U) Software Version : 5.02 TOE Initial : iDeras iDeras Security Target Page | 6 2.3 Terminology and Acronyms TOE Target of Evaluation TSF TOE Security Functionality CLI Command Line Interface LAN Local Area Network TLS Transport Layer Security SSH Secure Shell Webconfig Web interface for TOE administration purpose IP Internet Protocol NTP Network Time Protocol OSP Organizational Security Policy 2.4 Reference CCPart1 Common Criteria for Information Technology Security Evaluation Part 1: Introduction and General Model, Version 3.1 Revision 4, September 2012, CCMB- 2012-09-001 CCPart2 Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, Version 3.1 Revision 4, September 2012, CCMB-2012-09- 002 CCPart3 Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, Version 3.1 Revision 4, September 2012, CCMB-2012-09- 003 CEM Common Methodology for Information Technology Security Evaluation (CEM): Version 3.1 Revision 4, September 2012, CCMB-2012-09-004 iDeras Security Target Page | 7 2.5 TOE Overview 2.5.1 Usage and major security features of the TOE The iDeras product is a Unified Threat Management (UTM) or hybrid solution consists of firewall packet filtering technology, offering server hosting services, network security with management features and gateway security management inside a single appliance. IDeras developed in Series of boxes comes in two models, which is ID-1208 (Type: 2U) and ID-2016 (Type: 4U), developed by Malaysian Local Company, Infosys Sdn Bhd. iDeras can be uses as hosting server, where iDeras pre-equipped with MySQL database feature, web server hosting and RAID support features. The network management features has the capabilities of recognizing hardware and software network configuration within the existing enterprise network, managing domains, directories, files, remote printing services and messaging (email hosting) services. The gateway features are to manage enterprise network traffic flow with supporting security features of Intrusion Detection/Prevention, Firewall packet filtering, Anti-Malware, Content- Filtration and many more. However, for this evaluation, only parts of gateway function will be the TOE. Refer to Section TOE Description for more details. The major security features of the TOE included in the evaluation are Identification and Authentication, User Data Protection, Security Audit, Security Management and Protection of the TSF. 2.5.2 TOE Type The TOE is an application-level firewall that performed network packets filtering, network packets inspection, network load controls, and content filtering within network packets that are flows in the enterprise network traffics that travels in (incoming network packets) and out (outgoing network packets) of the organization’s internal networks. Application-level firewall with pre-equipped additional features as per described in TOE Overview, are known as Unified Threat Management (UTM). iDeras Security Target Page | 8 2.5.3 Non-TOE hardware/software/firmware required by the TOE The TOE comes with a hardware appliance and operating system that is required to run the TOE as following: Table 1: Non-TOE Hardware and Software Specification Model Specification Details ID-2016 CPU Speed Dual Intel Xeon E5645 2.4Ghx 6 Core Memory 32GB Triple-Channel DDR3 1333 MHz ECC Storage 5x3.5’ removable HDD Trays Max capacity 8TB RAID 0,1,5 Support 1x8GB CompactFlash Interface 16x1 GbE Ports (Copper) 2x1 GbE Ports (Fiber) 2xUSB 2.0 ports Power supply 500W/each redundant power supply Form Factor 2U Rack mount Operating System CentOS5 Appliance Type: 4U ID-1208 CPU Speed 2.0GHz~3GHz, Intel i3 ~i7, 2~8 Core Memory Dual Channel DDR3 (2GB~16GB) 8GB Compact Flash For OS Restore & Redundancy Storage Standard: Dual 500GB ~ 2TB SATA Raid: 250GB ~ 1TB Mirrored Interface 6x1 GbE Ports (Copper) 2xUSB 2.0 ports Power supply ~90W Form Factor 1U Rack mount Operating System CentOS5 Appliance Type: 2U iDeras Security Target Page | 9 2.6 TOE Description 2.6.1 Physical Scope of TOE The TOE is installed inside the model hardware appliances as stated below, is consists of the following components:  ID-1208 (Type: 2U) and ID-2016 (Type: 4U): Hardware appliance includes the physical port connections on the outside of the appliance rack. Refer Table 1 for more details. Refer Figure 1 and Figure 2 for the physical presentation of hardware appliance.  CentOS5  iDERAS User Guide Figure 1: ID-1208 Model Figure 2: ID-2016 Model iDeras Security Target Page | 10 Figure 3: Typical TOE deployment All hardware appliance and operating system are not part of the scope of evaluation. The TOE is deployed with objectives of providing network perimeter security, in which controls of data/information transfer between two networks, one considered to be “external” to the assets that are to be protected by the TOE and the second considered to be “internal”. The TOE must be placed in a secure physical area where only authorized administrators are granted physical access to the TOE. External interface are consider to external network to the LAN network (Internal), normally known as Internet Gateway provided through ISP (Internet Service Provider) network router configurations. Whereas for Internal Network are known as Local Area Network (LAN) that shall be segregated based on organization security policies enforced and implemented by TOE Administrator, authorized to applied to the TOE, accordingly. TOE administrator could administer TOE through 2 interfaces. Refer following Figure 3 for illustration of typical TOE deployment: a) Console Interface – Access through Command Line Interface (CLI) over SSH using RJ-45 cable. b) Internal LAN Interface –Access through Web Interface (Webconfig) over TLS/HTTPS in an internal network located in the same physical secure location. iDeras TOE is installed inside the iDeras hardware appliance Internal Network External Network / Internet Internal LAN Interface using TLS/SSH Router Administrator (Webconfig/CLI access) iDeras Security Target Page | 11 2.6.2 Logical Scope of TOE The logical scope of TOE is described based on several security functional requirements. 2.6.2.1 Identification and Authentication TOE administrator can access TOE by providing username and password in the Webconfig interface and CLI interface. By default, administrator can use a built-in administrative account known as “admin” used for authenticating through Webconfig. TOE Administrator will be granted role based on built-in Groups, access to services (UTM/Firewall) and pages within Webconfig. Password for each administrator account is governed by password policy. TOE Administrator are able to modify the existing configurable settings as per required by the organizational security policies implemented/enforced. However, several built-in features could not be modified by TOE Administrator. For more details, refer to Section TOE Summary Specification and Guidance Documentation. 2.6.2.2 User Data Protection TOE has the capabilities of protecting the internal network (organization network, enterprise network or etc) from external network intrusions using information flow controls between internal and external network. The TOE will check the inbound and outbound IP network protocols, contents and ports; before allowing or rejecting the IP network and packets. TOE Administrator can configure packet filter rules and policies based on the subject and information security attributes. By default, all external (Internet) traffic will be blocked. TOE Administrator can configure any services, ports and protocols that are accessible between Internet and Internal networks. For more details, refer to Section TOE Summary Specification and Guidance Documentation. 2.6.2.3 Security Management TOE features can be managed through Webconfig and CLI by TOE Administrator. User of TOE, whom are assigned with TOE Administrator roles is configurable using built-in feature by assigning to administrator account “admin”. TOE Administrator could enable, disable and modify the behaviour of services controlled by TOE, packet filtering rules, user attribute values, network settings, time-of-day web access, NTP Time Server, backup and restore configurations setting, restart and shutdown functions, password policies and related functions of TOE. For more details, refer to Section TOE Summary Specification and Guidance Documentation. 2.6.2.4 Security Audit The TOE will generate audit records for selected security events in several log files and categories. Each audited event will be recorded along with date and time of event, account user who performed the event, event name, system filename related to event and other event details. Audit records can be viewed by TOE Administrator and cannot be edited. TOE Administrator could select and filter the logs for easy viewing. TOE will create a new log file to store the audit records if the size limit is reached for a single log file. Limitation of the log storage is based on the internal hard disk equipped within the TOE appliance. Kindly refer to Section 2.5.3 on the information about TOE storage capacity. For more details, refer to Section TOE Summary Specification and Guidance Documentation. iDeras Security Target Page | 12 2.6.2.5 Protection of the TSF The security audit functions will generate audit records of events along with date and time of event. To ensure a reliable date and time, TOE enforce the time stamps to be taken from a reliable source from the environment. TOE prevents modification of date and time manually. For more details, refer to Section TOE Summary Specification. iDeras Security Target Page | 13 2.6.3 Product features not included in scope Product features that are not part of the evaluation scope as following:  Domain &LDAP and its related functionalities  SSL Certificates, encryption and digital signatures  Multi-WAN  DHCP Server  Local DNS Server  OpenVPN  PPTP Server  Proxy Server  IPsec VPN  OpenVPN  PPTP VPN  Antimalware  Bandwidth and QoS  Intrusion Protection  Content Filter  Web Proxy  Windows Networking including Windows domain group and user  File and Print  Mail  Mail Scanning  Web Server  Database  Language  Mail Notification  Disk Usage  Processes  Certificate Manager  Reports (excepts Logs) 3 Conformance Claims The following conformance claims are made for the TOE and ST: CCv3.1 conformant The ST and the TOE are Common Criteria conformant to Common Criteria version 3.1 Revision 4. Part 2 conformant The ST is Common Criteria Part 2 extended Part 3 conformant The ST is Common Criteria Part 3 conformant Package conformant The ST is package conformant to the package Evaluation Assurance Level EAL2. Protection Profile conformance None iDeras Security Target Page | 14 4 TOE Security Problem Definition 4.1 Assumption The assumptions are made to ensure the security of the TOE and its deployed environment. Table 2: Assumptions A.PHY The TOE and its environment are physically secure and managed by authorized TOE Administrator. A.FLOW Data and information could not flows through between internal and external networks and vice versa, unless it passes through the TOE. A.ADMIN Authorized TOE Administrators is non-hostile and follows guidance documentation accordingly; however, TOE Administrators is not free from human error and mistakes. A.TIMEBACK The TOE environment will provide reliable time stamps and backup storage enough for TOE supporting operational environments. A.MGMT The TOE shall be managed from a network that is physically separated from the internal and external networks. Remote management of the TOE is only permitted in the event that secure and trusted connections can be established to the management network (i.e. through a trusted VPN or trusted Virtual LAN). A.CONN Authorized TOE Administrators will access the TOE using a secure connection. A.USER Unauthorized user who is not authorized TOE Administrators cannot access the TOE remotely from the internal or external networks or trusted networks. 4.2 Threats Assets that are protected by the TOE are sensitive data, stored in the TOE and internal network including critical TOE configuration data (configuration files, packet filtering rule-base and others), audit records, administrator credentials, TOE data and TOE security functions. Threat agents are entities that can adversely act on the assets. The threat agents identified are an unauthorized person and an authorized administrator (a person that has been successfully authenticated and authorized as an administrator). Threats may be addressed either by the TOE or by its intended environment. Table 3: Threats T.ACCESSLOG An unauthorized person successfully accesses the TOE data or security functions without being detected. T.AUDIT An unauthorized person or authorized administrator may intentionally or unintentionally delete audit records to destroy evidence of adverse events executed. iDeras Security Target Page | 15 T.EXPLOIT An unauthorized person may send impermissible information through the TOE that result in the exploitation of resources on the internal network. T.REMOTE An unauthorized person or unauthorized external IT entities may be able to view, modify, and/or delete security related information that is sent between a remotely located authorized TOE Administrator desktop and the TOE. T.CONFIG An unauthorized person may read, modify, or destroy TOE configuration data. T.NOAUTH An unauthorized person may attempt to bypass the TOE access controls, in accordance to modify current existing security configurations, provided by the TOE. T.SPOOF An unauthorized person may carry out network spoofing activities, in which, information flows through the TOE into a connected network by using a spoofed source address. 4.3 Organizational Security Policies The Organizational Security Policies (OSP) is imposed by an organization to secure the TOE and its environment. Table 4: Organizational Security Policy P.ROLE Only authorized individuals are assigned by the organization have access to the TOE. P.PASSWORD Authorized TOE Administrator shall use/create password with combination of special character, number and alphabet with minimum lengths of 12in mitigating password guessing activities. iDeras Security Target Page | 16 5 Security Objectives Security objectives are formed to address the security problem definition defined in earlier section. The security implementation in TOE and its environment will meet these objectives. 5.1 Security Objectives for the TOE The security objectives for the TOE as following: Table 5: Security Objectives for the TOE O.ACCESSLOG TOE shall record a readable log of security events. O.AUDIT TOE shall prevent an unauthorized person or authorized TOE Administrator to modify or deletes audit records of security events executed. The TOE shall ensure the integrity of audit and system data by protecting itself from unauthorized modifications and access to its functions and data. O.EXPLOIT TOE shall mediate the information flow in internal network and between internal and external network. O.CONFIG TOE shall prevent unauthorized person to access TOE functions and configuration data. Only authorized TOE Administrator shall have access to TOE management interface. O.NOAUTH The TOE must protect itself against attempts by unauthorized users to bypass, deactivate, or tamper with TOE security functionality. 5.2 Security Objectives for the Operational Environment The security objectives for the TOE operational environment as following: Table 6: Security Objectives for the Operational Environment OE.PHY The TOE and its environment shall be physically secure. OE.FLOW The TOE shall be deployed so that information cannot flow through internal and external networks unless it passes through the TOE. OE.ADMIN Authorized TOE Administrators shall be non-hostile and follow guidance; however, TOE Administrators is not free from human error or mistakes. OE.TIMEBACK The TOE environment shall provide reliable time stamps and backup storage. OE.MGMT The TOE shall be managed from a network that is physically separated from the internal and external networks. Remote management of the TOE is only permitted in the event that a secure and trusted connection can be established to the management network (i.e. through a trusted VPN, enforced with HTTPS). iDeras Security Target Page | 17 OE.CONN Authorized administrators shall access the TOE using a secure connection provided by the environment to prevent eavesdropping. OE.USER Unauthorized user who is not authorized administrators cannot access the TOE remotely from the internal or external networks. iDeras Security Target Page | 18 6 Extended Components This section defines the extended Security Functional Requirements (SFRs) and extended Security Assurance Requirements (SARs) applicable for the TOE. These requirements are presented following the conventions identified in Section 9.1 Conventions. 6.1 Extended Security Functional Requirement (SFR) Table 7: Extended SFR Component Extended Component Extended Component Name Rationale Class FAU : Security Audit FAU_GEN.3 Simplified Audit Data Generation FAU class contains families of functional requirements that are related to monitor security- relevant events, and act as a deterrent against security violations. This component is a member of FAU_GEN, an existing CC Part 2 family. This extended requirement for the FAU class has been included in this ST because TSF audit function does not log start and stop of auditing function; hence FAU_GEN.1.1 (a) is not applicable. This component is also created to simplify the requirement of FAU_GEN.1. Class FPT : Protection of the TSF FPT_STM.2 Reliable time stamps by operational environment FPT class contains families of functional requirements that relate to the integrity and management of the mechanisms that constitute the TSF and to the integrity of TSF data. This component is a member of FPT_STM, an existing CC Part 2 family. This extended requirement for the FPT class has been included in this ST because the operational environment is providing reliable time stamps for TSF functions that is not covered in FPT_STM.1 . iDeras Security Target Page | 19 6.1.1 Class FAU: Security Audit FAU_GEN.3 Simplified Audit Data Generation Hierarchical No other component Dependencies FPT_STM.2 Reliable time stamps by operational environment FAU_GEN.3.1 The TSF shall be able to generate an audit record of the following auditable events: [assignment: defined auditable events]. FAU_GEN.3.2 The TSF shall record within each audit record at least the following information: a) Date and time of the event b) [assignment: other information about the event]. 6.1.2 Class FPT: Protection of the TSF FPT_STM.2 Reliable time stamps by operational environment Hierarchical No other component Dependencies No other dependencies FPT_STM.2.1 The operational environment shall be able to provide reliable time stamps for the TSF functions. 6.2 Extended Security Assurance Requirement (SAR) There are no extended SAR components defined for this evaluation. iDeras Security Target Page | 20 7 TOE Security Functional Requirements This section provides the security functional and assurance requirements that must be satisfied by a compliant TOE. These requirements consist of functional components from Part 2 of the CC, extended requirements, and an Evaluation Assurance Level (EAL) that contains assurance components from Part 3 of the CC. 7.1 Conventions Part 2 of the Common Criteria defines an approved set of operations that may be applied to the statement of security functional requirements. Following are the operations and the document conventions as used within this ST to depict their application: Assignment The assignment operation provides the ability to specify an identified parameter within a requirement. Assignments are depicted using bolded text and are surrounded by square brackets as follows [assignment]. Selection The selection operation allows the specification of one or more items from a list. Selections are depicted using bold italics text and are surrounded by square brackets as follows [selection]. Refinement The refinement operation allows the addition of extra detail to a requirement. Refinements are indicated using bolded text, for additions, and strike-through, for deletions. Iteration The iteration operation allows a component to be used more than once with varying operations. Iterations are depicted by placing an acronym at the end of the component identifier as follows: FCS_COP.1 (SWP). iDeras Security Target Page | 21 7.2 Security Functional Requirements This section contains the security functional requirements (SFRs) for the TOE. The summary of SFRs is listed in following table. Table 8: Security Functional Requirements Component Component Name Class FAU : Security Audit FAU_GEN.3 Simplified Audit Data Generation FAU_SAR.1 Audit review FAU_SAR.3 Selectable audit review FAU_STG.1 Protected audit trail storage FAU_STG.4 Prevention of audit data loss Class FDP : User Data Protection FDP_IFC.1 Subset Information Flow Control FDP_IFF.1 Simple Security Attributes Class FIA : Identification and Authentication FIA_ATD.1 User attributes definition FIA_UAU.2 User authentication before any action FIA_UID.2 User identification before any action FIA_SOS.1 Verification of secrets Class FMT : Security Management FMT_MOF.1 Management of security functions behavior FMT_MTD.1 Management of TSF data FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security roles FMT_MSA.1 Management of security attributes FMT_MSA.3 Static attribute initialisation iDeras Security Target Page | 22 Class FPT : Protection of the TSF FPT_STM.2 Reliable time stamps by operational environment 7.2.1 Class FAU: Security Audit FAU_GEN.3Simplified Audit Data Generation Hierarchical No other components. Dependencies FPT_STM.2 Reliable time stamps by operational environment FAU_GEN.3.1 The TSF shall be able to generate an audit record of the following auditable events:[ a) Successful/failure authentication to iDeras web portal; b) Web portal page accessed by user; c) Reset user password] FAU_GEN.3.2 The TSF shall record within each audit record at least the following information: a)Date and time of the event; b)[Username; c) Event; d) Filename; e) Event details] Application notes None FAU_SAR.1 Audit review Hierarchical No other components. Dependencies FAU_GEN.1 Audit data generation FAU_SAR.1.1 The TSF shall provide [administrator] with the capability to read [all audit trail data] from the audit records. FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret the information. Application notes None iDeras Security Target Page | 23 FAU_SAR.3 Selectable audit review Hierarchical No other components. Dependencies FAU_SAR.1 Audit review FAU_SAR.3.1 The TSF shall provide the ability to apply [select log file and/or filter] of audit data based on [ a) log file related to event b) filter log using any key words inserted in filter field ] Application notes None FAU_STG.1 Protected audit trail storage Hierarchical No other components. Dependencies FAU_GEN.1 Audit data generation FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorised deletion. FAU_STG.1.2 The TSF shall be able to [prevent] unauthorised modifications to the stored audit records in the audit trail. Application notes None FAU_STG.4Prevention of audit data loss Hierarchical FAU_STG.3 Action in case of possible audit data loss Dependencies FAU_STG.1 Protected audit trail storage FAU_STG.4.1 The TSF shall [create a new log file to store the audit records if the size limit is reached for a log file] if the audit trail is full. Application notes None iDeras Security Target Page | 24 7.2.2 Class FDP: User Data Protection FDP_IFC.1 Subset Information Flow Control Hierarchical No other components. Dependencies FDP_IFF.1 Simple security attributes FDP_IFC.1.1 The TSF shall enforce the [Unauthenticated Information Flow Control SFP] on [a) subjects: unauthenticated external IT entities that send and receive information through the TOE to one another; b) information: traffic sent through the TOE from one subject to another; c) operation: allow/reject information]. Application notes None FDP_IFF.1 Simple Security Attributes Hierarchical No other components. Dependencies FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation FDP_IFF.1.1 The TSF shall enforce the [Unauthenticated Information Flow Control SFP] based on the following types of subject and information security attributes: [ a) subject security attributes:  Presumed address b) information security attributes:  Presumed address of source subject;  Presumed address of destination subject;  Presumed port of source subject;  Presumed port of destination subject;  TOE interface on which traffic arrives and departs;  Transport layer protocol information;  Service]. FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [ a) Subject on an internal network can cause information to flow through the TOE to another connected network if: iDeras Security Target Page | 25  all the information security attribute values are unambiguously permitted by the information flow security policy rules, where such rules may be composed from all possible combinations of the values of the information flow security attributes, created by the administrator;  the presumed address of the source subject, in the information, translates to an internal network address; and  the presumed address of the destination subject, in the information, translates to an address on the other connected network. b) Subjects on the external network can cause information to flow through the TOE to another connected network if:  all the information security attribute values are unambiguously permitted by the information flow security policy rules, where such rules may be composed from all possible combinations of the values of the information flow security attributes, created by the administrator;  the presumed address of the source subject, in the information, translates to an external network address; and  the presumed address of the destination subject, in the information, translates to an address on the other connected network]. FDP_IFF.1.3 The TSF shall enforce the [none]. FDP_IFF.1.4 The TSF shall explicitly authorise an information flow based on the following rules: [none]. FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on the following rules: [ a) Reject requests for access or services where the information arrives on an external TOE interface, and the presumed address of the source subject is an external IT entity on an internal network; b) Reject requests for access or services where the information arrives on an internal TOE interface, and the presumed address of the source subject is an external IT entity on the external network; c) Reject requests for access of services where the information arrives on either an internal or external TOE interface, and the presumed address of the source subject is an external IT entity on a broadcast network; d) Reject requests for access or services where the information arrives on either an internal or external TOE interface, and the presumed address of the source subject is an external IT entity on the loopback network; iDeras Security Target Page | 26 e) Reject requests in which the subject specifies the route in which information shall flow en route to the receiving subject; and f) For application protocols supported by the TOE (e.g., DNS24, HTTP25, SMTP26, and POP327), the TOE shall deny any access or service requests that do not conform to its associated published protocol specification (e.g., RFC28). This shall be accomplished through protocol filtering that are designed for that purpose]. Application notes None 7.2.3 Class FIA: Identification and Authentication FIA_ATD.1 Subset Information Flow Control Hierarchical No other components. Dependencies No dependencies. FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: [ a) Username b) Password c) Role based on Built-in Groups d) Services e) Access page]. Application notes None FIA_UAU.2 User authentication before any action Hierarchical FIA_UAU.1 Timing of authentication Dependencies FIA_UID.1 Timing of identification FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. Application notes None FIA_UID.2 User identification before any action Hierarchical FIA_UID.1 Timing of identification iDeras Security Target Page | 27 Dependencies No dependencies. FIA_UID.2.1 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. Application notes None FIA_SOS.1 Verification of secrets Hierarchical No other components. Dependencies No dependencies. FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet [ a) Minimum Password length configurable value b) Minimum Password age configurable value c) Maximum Password age configurable value d) Password history size configurable value e) Starts with a letter or number f) Must not contain characters | ;]. Application notes (a) until (c) value are configurable by administrator. (d) and (e) value are build-in value and not configurable by administrator. 7.2.4 Class FMT: Security Management FMT_MOF.1 Management of security functions behavior Hierarchical No other components. Dependencies FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_MOF.1.1 The TSF shall restrict the ability to [enable, disable, modify the behaviour of] the functions [ a) start-up and shutdown services in System.Resources.Services Module; b) create, delete, modify, and view information flow security policy rules that permit or deny information flows in Network.Firewall Module; c) create, delete, modify and view user attribute values defined in FIA_ATD.1 in Directory.Accounts.User Module, Directory.Accounts.Group Module, System.Settings.Administrators iDeras Security Target Page | 28 Module and System.Resources.Services Module; d) create, delete, modify, and view network settings in Network.Settings Module; e) Modify the protocol filter to block unwanted traffic in Gateway.Protocol_Filter.Protocol_Configuration Module; f) enable and disable the NTP Time Server inSystem.Settings.Date Module; g) backup and restore configuration settings manually in System.Backup.Backup_Settings Module; h) restart and shutdown manually TOE in System.Settings.Shutdown- Restart Module; i) Configure password policies in Directory.Setup.Password_Policies Module. ] to [administrator]. Application Note None FMT_MTD.1 Management of TSF data Hierarchical No other components. Dependencies FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_MTD.1.1 The TSF shall restrict the ability to [change_default, modify, delete,[and add]] the [user attributes defined in FIA_ATD.1.1] to [administrator]. Application Note None iDeras Security Target Page | 29 FMT_SMF.1 Specification of Management Functions Hierarchical No other components. Dependencies No dependencies. FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [functions as in FMT_MOF.1.1]. Application Note None FMT_SMR.1 Security roles Hierarchical No other components. Dependencies No dependencies. FMT_SMR.1.1 The TSF shall maintain the roles [administrator]. FMT_SMR.1.2 The TSF shall be able to associate users with roles. Application Note By default, administrator account that is newly created will have limited access to the TOE. It is up to the default administrator account (username: admin) to give access to specific pages in the web-based administration portal and access to core applications on TOE. By default, administrator account can only access page to change their password and download security certificates (not part of scope). FMT_MSA.1 Management of security attributes Hierarchical No other components. Dependencies [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_MSA.1.1 The TSF shall enforce the [Unauthenticated Information Flow Control SFP] to restrict the ability to [change_default, modify, delete,[and add]] the security attributes [as in FDP_IFF.1.1] to [administrator]. Application Note None iDeras Security Target Page | 30 FMT_MSA.3 Static attribute initialisation Hierarchical No other components. Dependencies FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1 The TSF shall enforce the [Unauthenticated Information Flow Control SFP] to provide [restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2 The TSF shall allow the [administrator] to specify alternative initial values to override the default values when an object or information is created. Application Note By default, all external (Internet) traffic will be block. Administrator can configure any services and ports that can be accessible from the Internet. 7.2.5 Class FPT: Protection of the TSF FPT_STM.2 Reliable time stamps by operational environment Hierarchical No other components. Dependencies No other dependencies FPT_STM.2.1 The operational environment shall be able to provide reliable time stamps for the TSF functions. Application Note Reliable Time Stamps is required for the TOE to capture date and time events in relations to the FAU_GEN.3 and FMT_SAE.1 security functions. The TOE does not have a feature to generate time stamps independently. The date and time stamp is provided by NTP server. iDeras Security Target Page | 31 7.3 Security Assurance Requirements This ST claims compliance to the assurance requirements from the CC EAL2 assurance package. This EAL was chosen based on the security problem definition and the security objectives for the TOE. The chosen assurance level is consistent with the claimed threat environment. The following table summarized the TOE assurance requirements drawn from CC Part 3. Table 9: Security Assurance Requirements for EAL2 Assurance Class Assurance components 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 ASE: Security Target evaluation ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.2 Security objectives ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification 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 iDeras Security Target Page | 32 8 TOE Summary Specifications TOE addressed the security functional requirements as following: 8.1 Identification and Authentication TOE administrator can access and manage the TOE by providing username and password in the Webconfig login interface and CLI interface. By default, administrator can use a default built-in administrative account “admin” with password “admin” to be authenticated to Webconfig for first time. Administrator can modify the default password to a strong password according to P.PASSWORD. TOE Administrator will be granted role based on Built-in Groups, access to services and pages in Webconfig. There are 3 built-in groups: allusers, domain_admins and domain_users. Following are group definition:  allusers – Containing all users in TOE  domain_admins – Windows domain administrators  domain_users – Windows domain users By default, TOE Administrator will be in group allusers.domain_admins and domain_users groups are not part of the scope. By default, account “admin” has access to all services except Windows Networking. However, Windows Networking service can be enabled by administrator after successfully login to Webconfig. A new account created by TOE Administrator will have limited access to Webconfig pages and services. By default, a new account can only access account User Profile page to modify password and profiles. A new account user can also download security certificates in Security and Keys page (not in scope). A new account user can obtained administrator role if configured to access administrative page in Webconfig. Password for each TOE Administrator account is governed by a password policy. The policies that are configurable by administrator are:  Minimum Password Length  Minimum Password Age  Maximum Password Age  History Size Password must also starts with a letter or number and must not contain characters |; which are build-in values that are not configurable by TOE Administrator. TOE Security Functional Requirements Satisfied FIA_ATD.1 FIA_UAU.2 FIA_UID.2 FIA_SOS.1 iDeras Security Target Page | 33 8.2 User Data Protection TOE protects the internal network (organization network) from external network intrusions by using information flow control between internal and external network. The TOE will check the inbound and outbound IP packets from unauthenticated external IT entities before allowing or rejecting the network traffic in forms of IP packets. The decision to allow or reject/drop traffic will be based on packet filter rules created by administrator. Administrator could configure packet filter rules and policies based on the subject and information security attributes or criteria. The criteria are as following:  Source address of information (i.e IP address, MAC address)  Destination address of information (i.e IP address, MAC address)  Source port of information  Destination port of information  Interface that the traffic arrives and departs  Transport layer protocol information  Service used by information By default, all external (Internet) traffic will be blocked. TOE Administrator can configure any services, protocols and ports that can be accessible from the Internet. Pre-configured network traffic protocol listings are made available in TOE. TOE Administrator can block any unwanted network traffic using the ready-made protocol listings. TOE Security Functional Requirements Satisfied FDP_IFC.1 FDP_IFF.1 8.3 Security Management TOE functions can be managed through Webconfig and CLI by TOE Administrator. User of TOE has administrator roles, which can be configured by built-in administrator account “admin”. By default, administrator account that is newly created will have limited access to the TOE. It is up to the default administrator account (username: admin) to give access to specific pages in Webconfig and access to core applications on TOE. By default, administrator account can only access page to change their password and download security certificates (not part of scope). Administrator could enable, disable or modify the management functionalities of TOE as following:  start-up and shutdown services in System.Resources.Services Module;  create, delete, modify, and view information flow security policy rules that permit or deny information flows in Network.Firewall Module;  create, delete, modify and view user attribute values defined in FIA_ATD.1 in Directory.Accounts.User Module, Directory.Accounts.Group Module, System.Settings.Administrators Module and System.Resources.Services Module; iDeras Security Target Page | 34  create, delete, modify, and view network settings in Network.Settings Module;  Modify the protocol filter to block unwanted traffic in Gateway.Protocol_Filter.Protocol_Configuration Module;  enable and disable the NTP Time Server in System.Settings.Date Module;  backup and restore configuration settings manually in System.Backup.Backup_Settings Module;  restart and shutdown manually TOE in System.Settings.Shutdown-Restart Module;  Configure password policies in Directory.Setup.Password_Policies Module. By default, all external (Internet) traffic will be blocked. TOE Administrator can configure any services, protocols and ports that can be accessible from the Internet. Pre-configured network traffic protocol listings are made available in TOE. TOE Administrator can block any unwanted network traffic using the ready-made protocol listings. TOE Security Functional Requirements Satisfied FMT_MOF.1 FMT_MTD.1 FMT_SMF.1 FMT_SMR.1 FMT_MSA.1 FMT_MSA.3 8.4 Security Audit The TOE will generate audit records for selected security events in several log files. The security events that will be audited are as following:  Successful/failure authentication to iDeras web portal  Web portal page accessed by user  Reset user password Each audited events will be recorded along with date and time of event, account user who performed the event, event name, system filename related to event and other event details. Audit records can be viewed by administrator and cannot be modified. Administrator could read all audit trail data. Administrator could select and filter the logs for suitable interpretation. Administrator needs to select a log file related to the event and/or filter the content of the log. Log filtering is executed by inserting the related key words in the filter field to search the log records in log file. TOE will create a new log file to store the audit records if the size limit is reached for a log file. iDeras Security Target Page | 35 TOE Security Functional Requirements Satisfied FAU_GEN.3 FAU_SAR.1 FAU_SAR.3 FAU_STG.4 FAU_STG.1 8.5 Protection of the TSF The security audit functions will generate audit records of events along with date and time of event. To ensure a reliable date and time, TOE enforce the time stamps to be taken from a reliable source from the environment. NTP server is used as a reliable source of environment. However, NTP server itself is not part of the scope. TOE prevents manual modification of date and time to preserve integrity of date and time from NTP server. TOE Security Functional Requirements Satisfied FPT_STM.2 iDeras Security Target Page | 36 9 Rationale 9.1 Protection Profile Conformance Claim Rationale ST does not claim conformance to any Protection Profile. Hence, there are no elements to be covered in the conformance claim rationale. 9.2 Security Objectives Rationale This section explains how threat, assumptions and OSP are related to each other. The following tables show threat, assumptions and organizational policy being mapped to security objectives. 9.2.1 Rationale for Security Objectives Mapped to Threats Table 10: Rationale Security Objectives Mapped to Threats Threats Security Objectives Rationale T.ACCESSLOG An unauthorized person successfully accesses the TOE data or security functions without being detected. O.ACCESSLOG TOE shall record a readable log of security events. This security objectives counter threat because any success or failure of authentication events will be recorded in a readable log of security events. Each security events will be logged along with the username presented by unauthorized person. T.AUDIT An unauthorized person or authorized administrator may intentionally or unintentionally delete audit records to destroy evidence of adverse events executed. O.AUDIT TOE shall prevent an unauthorized person or authorized administrator to modify or deletes audit records of security events executed. The TOE shall ensure the integrity of audit and system data by protecting itself from unauthorized modifications and access to its functions and data. This security objective counter threat because it will prevent an unauthorized person or authorized administrator to modify or deletes audit records of security events executed. The objective also ensures the integrity of audit and system data by protecting itself from unauthorized modifications and access to its functions and data. T.EXPLOIT An unauthorized person may send impermissible information through the TOE that result in the exploitation of resources on the internal network. O.EXPLOIT TOE shall mediate the information flow in internal network and between internal and external network. This security objective counters threat because TOE will mediate the information flow in internal network and between internal and external network to decide whether to allow or drop information send by unauthorized person. T.REMOTE An unauthorized person or OE.MGMT The TOE shall be managed from This security objective counters threat because the deployment environment will secure the iDeras Security Target Page | 37 unauthorized external IT entity may be able to view, modify, and/or delete security related information that is sent between a remotely located authorized administrator and the TOE. a network that is physically separated from the internal and external networks. Remote management of the TOE is only permitted in the event that a secure and trusted connection can be established to the management network (i.e. through a trusted VPN, HTTPS). remote connection by administrator when remotely access the TOE. It also specifies that the TOE will be deployed in a separate network from the internal and external networks. OE.CONN Authorized administrators shall access the TOE using a secure connection provided by the environment to prevent eavesdropping. This security objective counters threat because the environment will provide a secure and encrypted connection to prevent unauthorized person or external IT entity sniff the data and modify it. T.CONFIG An unauthorized person may read, modify, or destroy security critical TOE configuration data. O.CONFIG TOE shall prevent unauthorized person to access TOE functions and configuration data. Only TOE authorized administrator shall have access to TOE management interface. This security objective counters threat because TOE will prevent unauthorized person to access TOE functions and configuration data. Only TOE authorized administrator shall have access to TOE management interface. T.NOAUTH An unauthorized person may attempt to bypass the security of the TOE so as to assess and use security functions and/or non- security functions provided by the TOE. O.NOAUTH The TOE must protect itself against attempts by unauthorized users to bypass, deactivate, or tamper with TOE security functionality. This security objective counters threat because security events are being audited and recorded in log file. Each security event will be recorded along with date and time of event, user who execute the event, filename and other event details. The audit records cannot be modified by administrator to preserve its integrity. It will also not be overwritten in the case of audit trail is full. T.SPOOF An unauthorized person may carry out spoofing in which information flow through the TOE into a connected network by using a spoofed source address. O.EXPLOIT TOE shall mediate the information flow in internal network and between internal and external network. This security objective counters threat because TOE will mediate the information flow in internal network and between internal and external network to decide whether to allow or drop information send by unauthorized person. iDeras Security Target Page | 38 9.2.2 Rationale Security Objectives Mapped to OSP Rationale Table 11: Rationale Security Objectives Mapped to OSP OSP Security Objectives Rationale P.ROLE Only authorized persons assigned by the organization have access to the TOE. OE.USER Unauthorized user who is not authorized administrators cannot access the TOE remotely from the internal or external networks. This security objective counters OSP because unauthorized user who is not authorized administrators cannot access the TOE remotely from the internal or external networks. O.CONFIG TOE shall prevent unauthorized person to access TOE functions and configuration data. Only TOE authorized administrator shall have access to TOE management interface. This security objective counters OSP because TOE will prevent unauthorized person to access TOE functions and configuration data. Only TOE authorized administrator shall have access to TOE management interface. P.PASSWORD Authorized administrator shall use password with combination of special character, number and alphabet with minimum lengths of 12 to make it hard to guess. OE.ADMIN Authorized administrators shall be non-hostile and follow guidance; however, they are not free from error. This security objective counters OSP because authorized administrator shall be non- hostile and follow guidance on creating a good password. O.NOAUTH The TOE must protect itself against attempts by unauthorized users to bypass, deactivate, or tamper with TOE security functionality. This security objective counters threat through functions of TOE that is able to enforce password protection based upon the implementation of organizational security policy, through the usage of password with combination of special character, number and alphabet with minimum lengths of 12 to make it hard to guess; whilst protecting the TOE from the attempt of unauthorized users to bypass, deactivate, or tamper with TOE security functionality. iDeras Security Target Page | 39 9.2.3 Rationale Security Objectives Mapped to Assumptions Table 12: Rationale Security Objectives Mapped to Assumptions Assumptions Security Objectives Rationale A.PHY The TOE and its environment are physically secure. OE.PHY The TOE and its environment shall be physically secure. This security objective counters assumption because the TOE and its environment shall be physically secure. A.FLOW Information cannot flow through internal and external networks unless it passes through the TOE. OE.FLOW The TOE shall be deployed so that information cannot flow through internal and external networks unless it passes through the TOE. This security objective counters assumption becauseTOE shall be deployed so that information cannot flow through internal and external networks unless it passes through the TOE. A.ADMIN Authorized administrators are non-hostile and follow guidance; however, they are not free from error. OE.ADMIN Authorized administrators shall be non-hostile and follow guidance; however, they are not free from error. This security objective counters assumption becauseauthorized administrators shall be non- hostile and follow guidance; however, they are not free from error. A.TIMEBACK The TOE environment will provide reliable time stamps and backup space. OE.TIMEBACK The TOE environment shall provide reliable time stamps and backup space. This security objective counters assumption becauseTOE environment shall provide reliable time stamps and backup space. A.MGMT The TOE shall be managed from a network that is physically separated from the internal and external networks. Remote management of the TOE is only permitted in the event that a secure and trusted connection can be established to the management network (i.e. through a trusted VPN). OE.MGMT The TOE shall be managed from a network that is physically separated from the internal and external networks. Remote management of the TOE is only permitted in the event that a secure and trusted connection can be established to the management network (i.e. through a trusted VPN, HTTPS). This security objective counters assumption because TOE shall be managed from a network that is physically separated from the internal and external networks. Remote management of the TOE is only permitted in the event that a secure and trusted connection can be established to the management network (i.e. through a trusted VPN, HTTPS). A.CONN Authorized administrators will access the TOE using a secure connection. OE.CONN Authorized administrators shall access the TOE using a secure connection provided by the environment to prevent This security objective counters assumption because authorized administrators shall access the TOE using a secure connection provided by the environment to iDeras Security Target Page | 40 eavesdropping. prevent eavesdropping. A.USER Unauthorized user who is not authorized administrators cannot access the TOE remotely from the internal or external networks. OE.USER Unauthorized user who is not authorized administrators cannot access the TOE remotely from the internal or external networks. This security objective counters assumption because unauthorized user who is not authorized administrators cannot access the TOE remotely from the internal or external networks. 9.3 Extended Security Functional Requirement Rationale Refer Section Extended Security Functional Requirement (SFR) for the rationale. 9.4 Extended Security Assurance Requirement Rationale Not applicable since there is no extended Security Assurance Requirement declared in ST. iDeras Security Target Page | 41 9.5 Security Functional Requirements Rationale This section provides the rationale of using SFRs to meet the security objectives for the TOE and justify the SFRs dependencies that have been satisfied or not satisfied. 9.5.1 Rationale for SFR Mapped to Security Objectives for TOE Table 13: Rationale for SFR Mapped to Security Objectives for TOE Security Objectives SFRs Rationale O.ACCESSLOG TOE shall record a readable log of security events. FAU_GEN.3 This SFR specify security events that are being audited and recorded in log file. Each security event will be recorded along with date and time of event, user who execute the event, filename and other event details. It traces back to this objective. FAU_SAR.1 This SFR specify that administrator will have the capability to view the audit trail data in log form. It traces back to this objective. FAU_SAR.3 This SFR specify that administrator will have the ability to select log file related to the security event. Administrator is able to filter the log for a better view. It traces back to this objective. O.AUDIT TOE shall prevent an unauthorized person or authorized administrator to modify or deletes audit records of security events executed. The TOE shall ensure the integrity of audit and system data by protecting itself from unauthorized modifications and access to its functions and data. FAU_STG.1 This SFR specify that audit records cannot be modified or deleted by administrator or unauthorized person. It traces back to this objective. FAU_STG.4 This SFR specify that if the log file reach the size limit, TOE will create a new log file to ensure that the integrity of audit records are preserved. Audit records will not be overwritten. It traces back to this objective. FPT_STM.2 This SFR specify that the environment (NTP server) will provide a reliable time stamps for TOE, thus preserving the integrity of the security event date and time that is being audited. It traces back to this objective. O.EXPLOIT TOE shall mediate the information flow in internal network and between internal and external FDP_IFC.1 This SFR identify the external IT entities in the Unauthenticated Information Flow Control SFP that send information to other entity. The SFP will either reject or allow the information flow. It traces back to this objective. iDeras Security Target Page | 42 network. FDP_IFF.1 This SFR identify the external IT entity and its security attributes as part of the information flow control SFP. TOE will permit or deny the information flow based on network packet rules configured by administrator. It traces back to this objective. O.CONFIG TOE shall prevent unauthorized person to access TOE functions and configuration data. Only TOE authorized administrator shall have access to TOE management interface. FIA_ATD.1 This SFR provide users with attributes to distinguish one user from another, for accountability purposes and to associate the role chosen in FMT_SMR.1 with a user. It traces back to this objective. FIA_UAU.2 This SFR require each person to be successfully authenticated before being allowed to perform any actions on TOE functions and configuration data at the TOE management interface. It traces back to this objective. FIA_UID.2 This SFR require each person to be successfully identified before being allowed to perform any actions on TOE functions and configuration data at the TOE management interface. It traces back to this objective. FIA_SOS.1 This SFR enforce a password policy in order to ensure that all account passwords are hard to guess. Therefore, unauthorized person will require longer duration and higher processing speed to guess/brute force the password in order to be authenticated. It traces back to this objective. FMT_MOF.1 This SFR restrict the ability to enable, disable and modify TOE functions to administrator. It traces back to this objective. FMT_MTD.1 This SFR restrict the ability to change default value, modify, delete and add user attributes in FIA_ATD.1.1 to administrator. It traces back to this objective. FMT_SMF.1 This SFR identify management functions that are available in TOE as in FMT_MOF.1.1, that are managed by administrator. It traces back to this objective. iDeras Security Target Page | 43 FMT_SMR.1 This SFR identify the roles exist in TOE, which is administrator. Each user account created must be associated to administrator role that have access to TOE management interface. It traces back to this objective. FMT_MSA.1 This SFR restrict the ability to change default value, modify, delete and add subject and information security attributes in packet filter rules, as in FDP_IFF.1.1 to administrator. It traces back to this objective. FMT_MSA.3 This SFR enforce a restrictive packet filter rules by default (during the initial start of TOE). Administrator will have access to management interface to modify the default value in packet filter rules. It traces back to this objective. O.NOAUTH The TOE must protect itself against attempts by unauthorized users to bypass, deactivate, or tamper with TOE security functionality. FAU_GEN.3 This SFR specify security events that are being audited and recorded in log file. Each security event will be recorded along with date and time of event, user who execute the event, filename and other event details. It traces back to this objective. FAU_STG.1 This SFR specify that audit records cannot be modified or deleted by administrator or unauthorized person. It traces back to this objective. FAU_STG.4 This SFR specify that if the log file reach the size limit, TOE will create a new log file to ensure that the integrity of audit records are preserved. Audit records will not be overwritten. It traces back to this objective. FIA_UAU.2 This SFR require each person to be successfully authenticated before being allowed to perform any actions on TOE functions and configuration data at the TOE management interface. It traces back to this objective. FIA_UID.2 This SFR require each person to be successfully identified before being allowed to perform any actions on TOE functions and configuration data at the TOE management interface. It traces back to this objective. iDeras Security Target Page | 44 9.5.2 SFR Dependency Rationale The following table provides a demonstration that all SFRs dependencies included in the ST have been satisfied. Table 14: SFR Dependencies SFR Dependency Dependency Met? Justification FAU_GEN.3 FPT_STM.2 Yes - FAU_SAR.1 FAU_GEN.1 No Met with FAU_GEN.3. Refer Section 8.1 for more details. FAU_SAR.3 FAU_SAR.1 Yes - FAU_STG.1 FAU_GEN.1 No Met with FAU_GEN.3. Refer Section 8.1 for more details. FAU_STG.4 FAU_STG.1 Yes - FDP_IFC.1 FDP_IFF.1 Yes - FDP_IFF.1 FDP_IFC.1 FMT_MSA.3 Yes - FIA_ATD.1 - - - FIA_UAU.2 FIA_UID.1 No FIA_UID.2 is hierarchical to FIA_UID.1. Dependency is fulfilled with FIA_UID.2. FIA_UID.2 - - - FIA_SOS.1 - - - FMT_MOF.1 FMT_SMR.1 FMT_SMF.1 Yes - FMT_MTD.1 FMT_SMR.1 FMT_SMF.1 Yes - FMT_SMF.1 - - - FMT_SMR.1 FIA_UID.1 No FIA_UID.2 is hierarchical to FIA_UID.1. iDeras Security Target Page | 45 Dependency is fulfilled with FIA_UID.2. FMT_MSA.1 FDP_ACC.1 or FDP_IFC.1 FMT_SMR.1 FMT_SMF.1 Yes - FMT_MSA.3 FMT_MSA.1 FMT_SMR.1 Yes - FPT_STM.2 - - - 9.6 Security Assurance Requirements Rationale EAL2 was chosen to provide a basic assurance. The chosen assurance level is appropriate with the threats defined for the environment. At EAL2, the TOE will have undergone an independent vulnerability analysis demonstrating resistance to penetration attackers with an attack potential of basic.