TRACENETWORK CORPORATION M yBOX Firewall, EAL3 ST v… · Tracenetwork Corporation Sdn Bhd Page 2...

TRACENETWORK CORPORATION

MV

yBOX Firewall, ersion 3.1

Security Target Version 2.4

1 3 August 2010

MyBOX Firewall Security Target

Tracenetwork Corporation Sdn Bhd

DOCUMENT HISTORY

Version Number Version Date Change Details

1.0 9 July 2008 Initial release submission to CyberSecurity Malaysia

1.1 28 July 2008 Minor adjustment on page 6 Section 1.2 Addition of Section 6. TOE Summary Specification

1.2 Draft September 2008 Major update to address EOR ver.1 1.3 Draft September 2008 Include the assurance reference for Intrusion

Prevention System and Remove assurance reference for Date/Time

1.3 23 September 2008 Released for Evaluation 1. 4 Draft 15 October 2008 Major update to address EOR ver.2 1.5 20 October 2008 Minor update to address evaluator comments 1.6 25 November 2008 Minor update to address evaluator comments1.7 5 February 2009 Major update to update to address evaluator

comments 1.8 27 February 2009 Major updates to address EOR #3 1.9 13 March, 2009 Major update to address latest finding and

EOR#4 2.0 14 August, 2009 Minor changes to resolve EOR#6 incorporate

with comments from consultant on SFR 2.1 19 August, 2009 Minor changes incorporate comments from

consultant and evaluator 2.2 23 March, 2010 Minor changes incorporate comments from

Lead Evaluator 2.3 14 May 2010 Changes requested by the CB.



Table of Contents

1 Document Preamble ......................................................................................... 4 1.1 Document Overview .................................................................................. 4 1.2 Document conventions ............................................................................. 4 1.3 Terminology ............................................................................................. 4 1.4 References................................................................................................ 5

2 Security Target introduction ............................................................................. 6 2.1 ST and TOE Reference ............................................................................... 6 2.2 TOE Overview ........................................................................................... 6

2.2.1 Usage and major security features of the TOE ..................................... 6 2.2.2 TOE Type ............................................................................................ 7 2.2.3 Hardware, software and firmware required by the TOE ........................ 7

2.3 TOE Description ........................................................................................ 7 2.3.1 Physical scope of the TOE ................................................................... 7 2.3.2 Logical scope of the TOE ..................................................................... 9

3 CONFORMANCE CLAIMS ................................................................................. 12 3.1 Common Criteria Claims ......................................................................... 12

4 TOE SECURITY PROBLEM DEFINITION .............................................................. 13 4.1 Assumption ............................................................................................ 13 4.2 Threats ................................................................................................... 13

4.2.1 Threats addressed by the TOE ........................................................... 13 4.3 Organizational Security Policies .............................................................. 14

5 TOE SECURITY OBJECTIVES ............................................................................. 15 5.1 Security Objective for the TOE................................................................. 15 5.2 Security Objective for the Environment ................................................... 16

5.2.1 Security objectives for the environment ............................................. 16 6 Extended components definition .................................................................... 17 7 IT SECURITY REQUIREMENTS ........................................................................... 18

7.1 Overview ................................................................................................ 18 7.2 TOE Security Functional Requirements .................................................... 19

7.2.1 Security Audit (FAU) .......................................................................... 19 7.2.2 User Data Protection (FDP) ................................................................ 23 7.2.3 Identification and Authentication (FIA) ............................................... 25 7.2.4 Security Management (FMT) .............................................................. 27 7.2.5 Protection of the TSF (FPT) ................................................................ 28

7.3 TOE Security Assurance Requirement ...................................................... 29 8 TOE SUMMARY SPECIFICATION ....................................................................... 30

8.1 TOE Security Functions ........................................................................... 30 8.1.1 Identification and Authentication ...................................................... 30 8.1.2 Information Flow Control .................................................................. 30 8.1.3 Security Management ........................................................................ 31 8.1.4 Audit logging and audit management ............................................... 33

9 RATIONALE .................................................................................................... 35 9.1 COnformance claims rationale ................................................................ 35 9.2 Security Objectives Rationale .................................................................. 35

9.2.1 Security objectives rationale .............................................................. 36 9.2.2 Security objectives for the environment ............................................. 39

9.3 Security requirements rationale .............................................................. 40 9.3.1 Tracing of SFR to security objectives ................................................. 40 9.3.2 SFR dependency rationale ................................................................. 43 9.3.3 SAR justification ................................................................................ 44



1 Document Preamble

1.1 DOCUMENT OVERVIEW

This document is the Security Target for the MyBOX Firewall version 3.1. The ST is designed to meet the requirements of the CC ASE Class for EAL3, and provides a baseline for the subsequent TOE evaluation. 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.

1.2 DOCUMENT CONVENTIONS

The following conventions have been applied in this document: Security Functional Requirements – Part 2 of the CC defines the approved set of operations that may be applied to functional requirements: 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. 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]. 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]. 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).

1.3 TERMINOLOGY

Table 1 Terminology

Acronym Meaning

CC Common Criteria

DMZ Demilitarized Zone

EAL Evaluation Assurance Level



FIPS PUB Federal Information Processing Standards Publication

FTP File Transfer Protocol

HTTP HyperText Transfer Protocol

HTTPS Secure HTTP

GUI Graphical User Interface

IP Internet Protocol

NAT Network Address Translation

NTP Network Time Protocol

PP Protection Profile

SAR Security Assurance Requirements

SFR Security Functional Requirements

SSH Secure Shell

ST Security Target

TOE Target of Evaluation

TSC TSF Scope of Control

TSF TOE Security Function

TSP TOE Security Policy

TSS TOE Summary Specification

1.4 REFERENCES

- Common Criteria Part 1 Version 3.1 Revision 3 - Common Criteria Part 2 Version 3.1 Revision 3 - Common Criteria Part 3 Version 3.1 Revision 3 - Common Methodology for Information Technology Security Evaluation

(CEM) version 3.1 Revision 3



2 Security Target introduction

2.1 ST AND TOE REFERENCE

ST Title MyBOX Firewall, version 3.1 Security Target

ST Version 2.4, 13 August 2010

TOE Identification

MyBOX Firewall, version 3.1

CC Identification Common Criteria for Information Technology Security Evaluation, Version 3.1 Revision 3

Assurance Level EAL3 ST Author Tracenetwork Corporation Sdn. Bhd.

Keyword Firewall, Traffic Filter, Packet Filtering

2.2 TOE OVERVIEW

2.2.1 Usage and major security features of the TOE

MyBOX Firewall is a perimeter firewall product for securing data communication and protecting network connectivity. The firewall service includes the packet filtering control The MyBOX Firewall is intended for use by organizations that need controlled, protected and audited access to services, both from inside or outside their organization’s network, by allowing, denying and/or redirecting the flow of data through the firewall. The MyBOX Firewall comprises a firewall engine, its operating system and data repository platform, IDP modules, antivirus module, application proxy content filtering, and security management software. The firewall engine, audit event recording, and the security management system are included in the scope of the TOE. The IDP module, antivirus module and application proxy content filtering are outside of the scope of the evaluation. MyBOX Firewall operates as a single firewall MyBOX Firewall consists of a hardware box and runs on a custom firewall operating system MyBOXOS which is a hardened Linux kernel file system and MyBOX’s proprietary software. It also provides secure audit logging (internal log server), network traffic reporting, security management interfaces; GUI, console and secure remote access login via FTP and SSH to support the management and operation of the MyBOX Firewall. The security features within the scope of the ST include:

- Identification and Authentication of authorized administrator accessing the management interface

- Information flow control for IP packet filtering - Security management and protection functions to support the security services - Audit management



2.2.2 TOE Type

The TOE is a firewall product (See Sect. A.4.2.2. of CC Part 1) and includes the normal packet filtering firewall functionality support by identification and authentication of administrators, audit record generation and processing, and management of the security of the device.

2.2.3 Hardware, software and firmware required by the TOE

The TOE requires the underlying PC hardware, the operating system and the network connectivity to function correctly. The PC Hardware includes in the minimum and Intel-based platform (i386 or i686), memory of at least 512MB RAM (1.0GB RAM recommended), minimum of 200Mb of hard disk space for system files only, exclusive the log files, and an Intel-based Ethernet card (recommended) with the minimum of 2 NICs and optional 1 NIC for management console or DMZ. The operating system is MyBOXOS, a MyBOX proprietary hardened Linux kernel file system and MyBOX’s proprietary software. The network connectivity is needed to connect the protected network to an unprotected network through the TOE. The network connectivity must be so configured that the only point of connectivity between the protected and unprotected network is the TOE and all other access paths between the two networks are disabled. The TOE requires access to an NTP service to provide accurate time for the TOE Audit logs.

2.3 TOE DESCRIPTION

2.3.1 Physical scope of the TOE

MyBOX Firewall is software and operating system combination that is housed on hardware appliances (the hardware is out of the evaluation scope). The TOE is delivered to customers a pre-configured hardware appliance as described in Table 2.

Table 2 Pre-configured TOE on a hardware appliance

Model Ethernet Ports Console LCD Control Panel Form Factor

MyBOX 100 4 x 10/100/1000 Mbps

Yes No 1U rack mount

The TOE is deployed to provide network perimeter security, in which they control the transfer of data 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.



Figure 1: Example of MyBox installation

Figure 1 shows an example of typical MyBOX Firewall protecting an internal perimeter network. The TOE are designed to be deployed and used in an environment that is configured and controlled in accordance with administrator guidance that is supplied with the product.



2.3.2 Logical scope of the TOE

The logical scope of the TOE is defined by the security functionality as summarized in and discussed in more details below.

Table 3 Summary of the TOE security features

Security Function TOE Scope Description

Identification and Authentication

MyBOX Firewall administrative interfaces can be accessed and managed only after a human user had been successfully identified (IP and MAC Address) and authenticated (Role based password)

Information Flow Control

The TOE controls the flow of IP traffic between logical network interfaces by matching information contained in the header of IP packets according to specified security policies. Depending upon the rule and the results of the match, the TOE will pass, drop, or reject the packet will also log the specific details of the packet.

Security Management The TOE provides a GUI to administer the MyBOX Firewall interfaces and manage functions related to security policies, data collection, analysis and reaction.

Security Audit

The MyBOX Firewall generates audit records of IP traffic through the appliance and stores them in an audit trail on the MyBOX Firewall appliance. TOE supports remote syslog server as a backup store to prevent audit data loss.



Identification and Authentication The TOE provides Identification and Authentication function to support enforced the access control based on defined IP and MAC Address and password to allow only authorized administrators to carry out administrative tasks through the administrative interface with the specific roles. After installation phase, administrators can access the management functions via web-GUI (HTTPS) by the default password for administrator. The administrator would then change the default passwords and also to configure the TOE. The TOE uses two important elements to identify and authenticate each administrator before granting the access:

1. IP and MAC Address from which the administrator attempts access (available internally and externally). The IP and MAC Address must be configured at TOE access control management interface prior to administrators gaining access to the TOE (This does not apply to the console interface where there is no IP address),

2. The Interface on which the request arrives, and 3. Password for the fixed administrator account name.

The TOE is built with five types of account name as described in Table 4.

Table 4 Administrative accounts and their descriptions

Account Name

Access Interface Type

Description

Look Web-GUI (HTTPS) This account gives Read-Only privilege on the firewall.

Admin Web-GUI (HTTPS) This account gives full privilege to manage the firewall.

Console

Console Interface

This account gives privilege to manage a subset of the firewall functions.

SSH SSH Interface

This account gives privilege to manage a subset of the firewall functions.

FTP FTP Interface This account gives privilege only to upload and download specific files; to/from the firewall’s specific folders: Backup, Log, and Update.

Each Account Name has its own designated password. The TOE does not allow the creation of new Account Name but the TOE does not limit how many new administrator users can be created which is uniquely identified by its IP and MAC Address where the new administrator user is accessing the TOE from. Information Flow Control The packet filtering engine of the TOE controls the flow of IP traffic between physical and logical network interfaces by matching information contained in the header of IP packets according to a set of rule-base specified by firewall’s authorized administrator (only HTTPS admin has full privilege to add, delete or edit the rule-base). The rule-base is be based on transport layer protocol (example TCP, UDP), source port, destination port, and the interface on which the packet arrives.



Depending upon the rule and the results of the match, the firewall either passes or drops the packet. All networks inside (or behind) the firewall can be protected by the TOE from those outside of the firewall, and similarly traffic from inside to the outside can be regulated. TOE can also provide protection between networks connecting to the different internal network logical interfaces of the TOE. To avoid bypass of the TOE security policy, all traffic between each network attached to the TOE must flow through the MyBOX. Security Management The MyBox Security Management provides a web management server (Web-GUI) that provides a trusted interface for administrative functions, and a GUI to facilitate administrator access and managing functions related to audit event collection, review and protection Connection to this Web-GUI is via HTTPS. Audit Management The TOE provides a means to generate audit records of security relevant events relating to the IP traffic through the firewall and firewall security policy changes. The TOE also provides a means for the authorized administrator to define the criteria used for the selection of the IP traffic events to be audited. The TOE provides remote Syslog server as a backup store to prevent audit data loss. Any log generated by the TOE will be dump in the internal audit logs and also in Syslog Server



3 CONFORMANCE CLAIMS

3.1 COMMON CRITERIA 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 3. - Part 2 conformant. The ST is Common Criteria Part 3 conformant. - Part 3 conformant. The ST is Common Criteria Part 3 conformant. - Package conformant. The ST is package conformant to the package

Evaluation Assurance Level EAL3 - Protection Profile conformance. The ST does claims conformance to the

following Protection Profiles: None



4 TOE SECURITY PROBLEM DEFINITION

Assets that are protected by the TOE are sensitive data stored in the internal network including critical TOE configuration data (configuration files, packet filtering rule-base etc), audit records, admin 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).

4.1 ASSUMPTION

Table 5 lists the assumptions for the TOE security environment. Table 5 Assumptions

No. Assumption Assumption Description

1 A.PHYSEC The TOE is physically located within controlled and secured access facilities, which will prevent unauthorized physical access or modification.

2 A.SINGEN Information cannot flow among the internal and external networks unless it passes through the TOE to maintain integrity and confidentiality of information

3 A.NOTNEG Authorized administrator is not being negligent in performing TOE configurations.

4 A.SUPPORT The TOE Environment will provide the following services to support the TOE: Email server for audit alerts, NTP server for time updates, Syslog server for Audit log backup.

5 A.MGT 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).

4.2 THREATS

Threats may be addressed either by the TOE or by its intended environment

4.2.1 Threats addressed by the TOE

The TOE address the following threats as listed in Table 6 below :

Table 6 Threats addressed by TOE

No Threat Name Threat Description

1. T.EXT_NETWORK An unauthorized person on the external network reads, modifies or deletes data on the internal network.



No Threat Name Threat Description

2. T.INT_NETWORK An person on the internal network reads, modifies or deletes data on the external network contrary to the internal network access policy.

3. T.UNAUTH An unauthorized person successfully reads, modifies, or destroys critical TOE configuration data.

4. T.SHTDWN_AUDIT An unauthorized person successfully violates the availability of audit records by shutting down the audit generation functionality. If shut down, no further audit records will be generated.

5. T.PASS-UNDETECT An unauthorized person successfully accesses the TOE data or security functions without being detected.

6. T.DEL_AUDIT An unauthorized person (intentionally) or authorized administrator (accidentally) violates the integrity of audit records by deleting internal audit records.

4.3 ORGANIZATIONAL SECURITY POLICIES

Table 7 Organizational Security Policy for the TOE

No. Policy Name Threat Description

1 P.ROLE Only authorized persons assigned by the organization have access to TOE functions and data.

2 P.PASSWORD User must use combination of special character, number and alphabet with 12 minimum lengths for their password to make it difficult to guess.



5 TOE SECURITY OBJECTIVES

5.1 SECURITY OBJECTIVE FOR THE TOE

Table 8 Security Objectives for the TOE

No. Objective Name

Objective Description

1 O.MEDIATE The TOE protects the data on the internal network and enforces internal network policy by ensuring that all IP datagrams travelling between internal and external networks are assessed, and acted on, based on administrator defined traffic flow rules. Threats : T.EXT_NETWORK, T.INT_NETWORK

2 O.IDAUTH The TOE protects its packet filtering rulebase against any attempts to bypass authentication. The TOE also must uniquely identify all administrators and authenticate them to a role, before granting an access to TOE functions. Threats : T.UNAUTH

3 O.ATTEMP The TOE must provide a facility to monitor all connection attempts between the networks. Threats : T.PASS-UNDETECT

4 O.AUDREC The TOE must provide a means to record a readable audit trail of security-related events, with accurate dates and times, and a means to search and sort the audit trail based on relevant attributes. The TOE must provide an interface to store audit trail to internal audit trail and also remote Syslog server. The TOE must appropriately handle potential audit and data storage flow. Threats : T.PASS-UNDETECT, T.SHTDWN_AUDIT, T.DEL_AUDIT

5 O.SECFUN The TOE must provide functionality that enables an authorized administrator to use the TOE security functions, and must ensure that only authorized administrators are able to access such functionality. Threats : T.UNAUTH, T.SHTDWN_AUDIT OSP : P.ROLE



5.2 SECURITY OBJECTIVE FOR THE ENVIRONMENT

5.2.1 Security objectives for the environment

Table 9 Security Objectives for the environment

No. Objective Name

Description

1 OE.PHYSEC The TOE hardware, software and its operating environment are physically secure from unauthorized access or modification.

2 OE.SINGEN Information cannot flow among the internal and external networks unless it passes through the TOE to maintain integrity and confidentiality of information data.

3 OE.STR_PW The environment of TOE protects its authentication credentials and packet filtering rule-base by ensuring that strong admin passwords are used to prevent them from being easily guessed.

4 OE.SUPPORT The administrators will ensure that the following services to support the TOE exist in the IT Environment: Email server for audit alerts, NTP server for time updates, Syslog server for Audit log backup.

5 OE.MGT The administrators shall configure a management network that connects to one of the TOEs spare interfaces. Management via Ethernet shall all be performed from this network. Management of the TOE via the console interface must be used only in a situation where the other interfaces are in operable as the TOE does not audit events on the Console interface.

6 OE.TRUSTED The owners of the TOE and protected data must ensure that all administrators are appropriately trained, experienced and are not hostile. They must also ensure that administrators only have access to those functions that are required for them to perform their required tasks.



6 Extended components definition

There are no extended components applicable to the TOE, hence none of the requirements for the Extended Components Definition (ASE_ECD) are applicable to this ST.



7 IT SECURITY REQUIREMENTS

7.1 OVERVIEW

This section contains the security functional requirements (SFRs) for the TOE, listed in Table 10 below.

Table 10 Security Functional Requirements for the TOE

Component Component Name Class FAU : Security Audit

FAU_GEN.1 Audit data generation

FAU_GEN.2 User identity association FAU_SAR.1 Audit review

FAU_SAR.3 Selectable audit review

FAU_STG.1 Protected audit trail storage

FAU_STG.3 Action in case of possible audit data loss

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 (1) User attributes definition

FIA_ATD.1 (2) User attributes definition

FIA_UAU.2 User authentication before any action

FIA_UID.2 User identification before any action

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

Class FPT : Protection of the TSF

FPT_STM.1 Reliable time stamps



7.2 TOE SECURITY FUNCTIONAL REQUIREMENTS

7.2.1 Security Audit (FAU)

FAU_GEN.1 Audit data generation

Hierarchical to: No other components.

FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events:

a) Startup and shutdown of the audit functions b) All auditable events for the [not specified] level of

audit; and c) [Events listed in Table 11 generated on non console

interfaces].

FAU_GEN.1.2 The TSF shall record within each audit record at least the following information:

a) Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components included in the ST, [information specified in column three of Table 11].

Dependencies: FPT_STM.1 Reliable time stamps

Notes: Audit events are stored locally and sent to a SYSLOG server.

Table 11 Auditable Events

SFR Auditable Event Additional Audit Record Contents

FAU_SAR.1 Reading of information from the audit records.

FAU_STG.3 Actions taken due to exceeding of a threshold

FAU_STG.4 Actions taken due to the audit storage failure

FDP_IFF.1 All decisions on request for information flow.

FIA_UAU.2 Any use of the authentication mechanism.

FIA_UID.2 All use of the identification mechanism.

FMT_MOF.1 All modifications in the behaviour of the functions in the TSF .

FMT_MTD.1 All modifications to the values of TSF data

FMT_SMF.1 Use of the management functions

FMT_SMR.1 Modifications to the group of users that are

The IP and MAC address being associated with the authorized



SFR Auditable Event Additional Audit Record Contents

part of the authorized administrator role.

administrator role.

FPT_STM.1 Changes to the time.



FAU_GEN.2 User identity association


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.

Dependencies: FAU_GEN.1 Audit data generation FIA_UID.1 Timing of identification

Notes: None

FAU_SAR.1 Audit review


FAU_SAR.1.1 The TSF shall provide [Admin and Look] 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

Dependencies: FAU_GEN.1 Audit data generation

Notes: None

FAU_SAR.3 Selectable audit review


FAU_SAR.3.1 The TSF shall provide the ability to apply [searches and sorting] of audit data based on: a) [source IP address; b) ranges of dates; c) ranges of times; d) destination IP address; and e) protocols].

Dependencies: FAU_SAR.1 Audit review

Notes: None

FAU_STG.1 Protected audit trail storage


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.

Dependencies: FAU_GEN.1 Audit data generation

Notes: None

FAU_STG.3 Action in case of possible audit data loss


FAU_STG.3.1 The TSF shall [generate an email as alarm to the authorised



administrator] if the audit trail exceeds [80% of used storage]

Dependencies: FAU_STG.1 Protected audit trail storage

Notes: None

FAU_STG.4 Prevention of audit data loss

Hierarchical to: FAU_STG.3 Action in case of possible audit data loss

FAU_STG.4.1 The TSF shall [overwrite the oldest stored audit records] and [generate an alarm to the authorized administrator] if the audit trail is full.

Dependencies: FAU_STG.1 Protected audit trail storage

Notes: None



7.2.2 User Data Protection (FDP)

FDP_IFC.1 Subset information flow control


FDP_IFC.1.1

The TSF shall enforce the [unauthenticated SFP] on [ a) Subject : 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) Operations: pass information].

Dependencies: FDP_IFF.1 Simple Security Attributes

Notes: None

FDP_IFF.1 Simple Security Attributes


FDP_IFF.1.1 The TSF shall enforce the [unauthenticated 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; - TOE interface on which traffic arrives; - Transport layer protocol information; - Service; and - time/date of service request.

c) Operations: send or receive information].

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) [Subjects on an internal network can cause information to flow

through the TOE to a subject on 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 authorized administrator; and

- 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 authorized administrator; and

- 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 [following rule: The TOE shall allow the administrator to hide selected IP addresses on internal networks from subjects and objects on the external network by translating between IP addresses on internal networks and IP addresses on external networks including valid Internet IP addresses].

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 be able to explicitly deny an information flow based on the following rules: a) [The TOE shall drop requests for access or services where the information arrives on an external TOE interface, and the presumed address of the source subject is an entity on an internal network; b) The TOE shall drop requests for access or services where the information arrives on an internal TOE interface, and the presumed address of the source subject is an entity on the external network; c) The TOE shall drop request for access or services where the information arrives on either internal or external TOE interface, and the presumed address of the source subject is an entity on a broadcast network; d) The TOE shall drop request for access or services where the information arrives on either internal or external TOE interface, and the presumed address of the source subject is an entity on the loopback network.]

Dependencies: FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialization

Notes: None



7.2.3 Identification and Authentication (FIA)

FIA_ATD.1(1) User attributes definition


FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users:[IP and MAC address association with the administrator roles]

Dependencies: No dependencies

Notes: None

FIA_ATD.1(2) User attributes definition


FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to inbuilt roles:

a) access profile, which identifies the group of access privileges accorded to the role;

b) authentication data; and c) account status]


Notes: None

FIA_UAU.2 User authentication before any action

Hierarchical to: FIA_UAU.1 Timing of authentication

FIA_UAU.2.1 The TSF shall require each administrator accessing an administration interface to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.

Dependencies: FIA_UID.1 Timing of identification

Notes: Authentication is based on the administrator role. The roles are based on privilege level and interface that the administrator uses to connect to the TOE. The password is not associated with the IP and MAC Address from FIA_UID.2.

FIA_UID.2 User identification before any action

Hierarchical to: FIA_UID.1 Timing of identification

FIA_UID.2.1 The TSF shall require each administrator using a non-console administration interface to be successfully identified before allowing any other TSF-mediated actions on behalf of that administrator.


Notes: Users are identified by their IP and MAC Address. They do not have individual passwords.



7.2.4 Security Management (FMT)

FMT_MOF.1 Management of security functions behavior


FMT_MOF.1.1 The TSF shall restrict the ability to [enable, disable] the functions: [ a) Audit (local and syslog); b) NAT; c) Email alert; and d) NTP time retrieval] to [Admin].

Dependencies: FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles

Notes: None

FMT_MTD.1 Management of TSF data


FMT_MTD.1.1 The TSF shall restrict the ability to [Operations defined in Table 12] the [TSF Data defined in Table ] to [roles defined in Table 12].

Dependencies: FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions

Notes: None

Table 12 FMT_MTD.1 permitted operations

TSF Data Operation(s) Role information flow security policy rules that permit or deny information flows;

create, delete, and modify Admin

information flow security policy rules that permit or deny information flows

Query Admin, Look

IP Address to role association

Create, delete and modify Admin, SSH, Console

IP Address to role association

Query Admin, SSH, Console, Look

MAC Address to IP Address

Create, delete and modify Admin

MAC Address to IP Address

Query Admin, Look

time and date Modify Admin audit trail Archive, create, delete

[individual records] and empty [entire log]

Admin

user attribute values, information flow security policy rules

Backup, Recover FTP



FMT_SMF.1 Specification of Management Functions


FMT_SMF.1.1 The TSF shall be capable of performing the following security management functions: [ a) Create, delete, modify, and view information flow security

policy rules that permit or deny information flows; b) Create, delete, modify, and view user attribute values; c) Modify and set the time and date; d) Archive, create, delete, empty, and review the audit trail; e) Backup of user attribute values, information flow security

policy rules, and audit trail data, where the backup capability shall be supported by automated tools;

f) Recover to the state following the last backup; g) Uploading and downloading file using FTP; e) Enable/disable NAT; f) Enable/disable Syslog backup; g) Enable/disable Email alert; and h) Enable/disable NTP time retrieval].

Dependencies: No dependencies.

Notes: None

FMT_SMR.1 Security roles


FMT_SMR.1.1 The TSF shall maintain the roles: [ a) look; b) admin; c) SSH; d) console; and e) FTP].

FMT_SMR.1.2 The TSF shall be able to associate users with roles

Dependencies: FIA_UID.1 Timing of identification

Notes: Admin and look are accessed over the Ethernet interface.

7.2.5 Protection of the TSF (FPT)

FPT_STM.1 Reliable time stamps


FPT_STM.1.1 The TOE shall be able to provide reliable time stamps.


Notes: Note: This SFR ensures that the TOE obtains accurate time from the NTP server in the TOE environment.



7.3 TOE SECURITY ASSURANCE REQUIREMENT

This ST claims compliance to the assurance requirements from the CC EAL3 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. Table 13 summarized the TOE assurance requirements drawn from Part 3 of the CC. The security assurance requirements represent EAL 3.

Table 13 TOE Assurance Components for EAL3

No Component Component Name Class ADV : Development ADV_ARC.1 Security architecture description

ADV_FSP.3 Functional specification with complete summary

ADV_TDS.2 Basic modular design

Class AGD : Guidance Document

AGD_OPE.1 Operational user guidance

AGD_PRE.1 Preparative procedures

Class ALC : Life Cycle Support

ALC_CMC.3 Authorisation controls

ALC_CMS.3 Implementation representation CM coverage

ALC_DEL.1 Delivery procedures

ALC_DVS.1 Development security

ALC_LCD.1 Life-cycle definition

Class 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

Class ATE : Test ATE_COV.2 Analysis of coverage

ATE_FUN.1 Functional testing

ATE_IND.2 Independent testing – sample

ATE_DPT.1 Testing: basic design

Class AVA : Vulnerability Assessment

AVA_VAN.2 Vulnerability analysis



8 TOE SUMMARY SPECIFICATION

8.1 TOE SECURITY FUNCTIONS

This section provides the TOE summary specification, a high-level definition of the security functions claimed to meet the functional and assurance requirements.

8.1.1 Identification and Authentication

The TOE requires that administrators are identified and authenticated prior to gaining access to the administration interface. No users are authenticated to have traffic pass from the outside network to the inside network, and vice versa. Administrators are identified to the TOE by their IP and MAC address. Once identified as coming from an known IP/MAC combination, the administrator is required to provide the password associated with the interface and privileges that they require. Administrators are authenticated as being permitted to use a role by possessing the password for that role. The TOE does not identify users on the console interface, even though they are required to enter a password to authenticate as the console user. As such, audit logs are not generated on this interface and the console should only be used to recover the TOE from an inoperable state. There are five roles in the TOE each with their own password. The TOE maintains the IP and MAC address for each administrator authorized to access the TOE and associates this user with the roles within the TOE they are permitted to assume. The TOE maintains the access profile, which identifies the group of access privileges accorded to the role, the authentication data (i.e. password) and whether the account is enabled or disabled (account status). Functional Requirement Satisfied:

- FIA_UID.2: The TOE ensures that the administrator is identified before granting an access to the administration interfaces of the TOE.

- FIA_UAU.2: The TOE ensures that the administrator is authenticated to a role before granting an access to the TOE.

- FIA_ATD.1(1): The TOE provides users with attributes to distinguish one user from another, for accountability purposes and to associate the administrator role(s).

- FIA_ATD.1(2): The TOE associates the password, account status and permissions (not modifiable) with each role.

8.1.2 Information Flow Control

The TOE provides a traffic filtering (packet level) firewall. The TOE ensures that all information flows requested of the TOE by external entities for transfer to other entities are assessed against the defined rule base and match a rule. Based on the match the TOE take one, and only one, of the following actions for each IP packet involved in an operation:



a) Accept (or Pass) the IP packet flow between the subject and the object b) Reject the IP packet flow between the subject and the object, notifying the subject c) Drop the IP packet flow between the subject and the object, without notifying the subject. The TOE shall enforce the security policy on each individual IP packets for every send or receive request that will traverse the firewall (i.e. internal to external, external to internal, internal or external to management). The administrator can configure rules to pass, reject and drop traffic based on the following attributes: a) subject security attributes:

i. presumed address; b) information security attributes:

i. presumed address of source subject; ii. presumed address of destination subject; iii. transport layer protocol; iv. TOE interface on which traffic arrives and departs; v. service; and vi. schedule, defined by days of the week and start/stop time.

The TOE provides restrictive default values for information flow security rules that are used to enforce the SFP, and allows the admin to override the default values when an object or information is created. In addition to administrator defined rules, the TOE shall explicitly drop packets that arrive on the interfaces as follows: a) A packet with a presumed internal IP address arriving on an external interface b) A packet with a presumed external IP address arriving on an internal interface c) A packet with a broadcast IP address arriving on an internal or external interface d) A packet with a loopback IP address arriving on an internal or external interface The TOE shall provide Network Address Translation to allow the admin to hide selected IP addresses on internal networks from subjects and objects on the external network by translating between IP addresses on internal networks and IP addresses on external networks including valid Internet IP addresses. Functional Requirement Satisfied: FDP_IFC.1, FDP_IFF.1

- FDP_IFC.1: This component identifies the attributes of the users sending and receiving the information, as well as the attributes for the information itself. Then the policy is defined by saying under what conditions information is permitted to flow

- FDP_IFF.1: This component identifies the entities involved in the UNAUTHENTICATED information flow control SFP (i.e., users sending information to other users and vice versa). The users of these services must be authenticated at the TOE.

8.1.3 Security Management

The MyBox Security Management provides a web management server (Web-GUI) that provides a trusted interface for administrative functions, a log server to store and manage (filter, sort, archive) the log records, and facilitates administrator access and managing functions related to system data collection, analysis and reaction. Examples of administrative functions: configuring settings for access control,



authentication, MyBOX configuration files backup and sending of email notification to administrator. Connection to this Web-GUI is via Ethernet. Specifically, the TOE provides the following security management functions via various management interfaces: a) Create, delete, modify, and view information flow security policy rules that permit

or deny information flows; b) Create, delete, modify, and view user attribute values; c) Modify and set the time and date; d) Archive, create, delete, empty, and review the audit trail; e) Backup of user attribute values, information flow security policy rules, and audit

trail data, where the backup capability shall be supported by automated tools; f) Recover to the state following the last backup; g) Uploading and downloading file using FTP; h) Enable/disable Syslog backup; i) Enable/disable Email alert; and h) Enable/disable NTP time retrieval. In order to provide control of the administration functions the TOE shall maintain the roles: a) look; b) admin; c) SSH; d) console; and e) FTP. The TOE links roles with IP and MAC address combinations to ensure that the configuration of the TOE is appropriately audited. To ensure the TOE is fully functional, the TOE restricts the ability to enable and diable specific functions to the admin role. Specifically the ability to enable and disable the following functions is restricted. a) NAT b) Syslog backup; c) Email alert; and d) NTP time retrieval] The TOE also restricts the ability to manage specific TSF data to specific roles. These restrictions are described in Table 12. Functional Requirement Satisfied:.

- FMT_MOF.1: The TOE ensures the TSF restricts the ability of the TOE operation management and multiple authentication function to the administrator.

- FMT_MTD.1: The TOE ensures only administrator has ability to change default, query, modify or delete specific TSF data.

- FMT_SMF.1: The TOE provides functions to allow administrators to security manage the TOE.

- FMT_SMR.1: The TOE maintains appropriate security roles.



8.1.4 Audit logging and audit management

The TOE shall provide the capability to generate audit records for each attempt to receive or send an IP packet through a defined product network interface. The TOE generates an audit log of the following events: a) start-up and shutdown of the audit functions; and b) all remaining auditable events specified in Table 11. For each audit event entry, the TOE records, where applicable, at least the following information: a) Date and time of the event (maintained by use of a NTP server); b) Type of event; c) Subjects’ identities; d) Outcome (success or failure) of the event; and e) For each audit event type, based on the auditable event definitions of the

functional components included in the ST, the information specified in column four of Table 11.

The TOE provides a means for the authorized administrator to read all audit data in a manner that permits interpretation, and allows the administrator to perform searching and ordering of the audit data using the following categories: a) Presumed subject address; b) ranges of dates; c) ranges of times; and d) ranges of addresses. The TOE protects audit data from unauthorized modification or deletion. The TOE prevents new audit data loss by deleting old logs when the audit trail is full and sends an alarm to the administrator when the audit log is 80% full. The TOE shall provide the capability for an administrator to display audit records from a current or a specified audit log file in accordance with one or more of the following selection criteria: a) audit records being recorded in real time to the current log file b) audit records with specified actions c) audit records logged after, before or between specified dates and/or times The TOE shall provide the capability to generate E-mail alert and GUI alerts corresponding to audit events. The TOE maintains an internal audit log and exports events to a syslog server simultaneously. Functional Requirement Satisfied:

- FAU_GEN.1: This component ensures TSF is able to generate an audit record on the such events as specified in FAU_GEN.1.1

- FAU_GEN.2: This component ensures that data must be associated with user doing the action

- FAU_SAR.1: This component ensures that the audit trail is understandable. - FAU_SAR.3: This component ensures that a variety of searches and sorts can

be performed on the audit trail. - FAU_STG.1 This component ensures that the TSF will protect the Audit log

from unauthorized tampering.



- FAU_STG.3: This component ensures the TSF will protect the audit trail in case of possible audit data loss. The TSF will generate an alert to the administrator if certain threshold on the audit trail is exceeded.

- FAU_STG.4: This component ensures the administrator will be able to take care of the audit trail if it should become full. But this component also ensures that no other auditable events as defined in FAU_GEN.1 occur. Thus the authorized administrator is permitted to perform potentially auditable actions though these events will not be recorded until the audit trail is restored to a non-full status.

- FPT_STM.1: This component ensures that all event that have been recorded with reliable time stamp in audit trail. This timestamp is obtained from an NTP server and used to timestamp audit logs.



9 RATIONALE

9.1 CONFORMANCE CLAIMS RATIONALE

The Conformance Claim of this 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

Table 14 summarizes the tracings from Security Objectives to Threats, Assumptions and Policies. The tracings are further explained in the rationale in Table 15, Table 16 and Table 17. Table 14 Mappings of Security Objectives for Environment to Threats/Assumptions/Policy

T.E

XT

_NET

WO

RK

T.IN

T_N

ET

WO

RK

T.U

NA

UT

H

T.S

HT

DW

N_A

UD

IT

T.P

ASS-U

ND

ET

EC

T

T.D

EL_A

UD

IT

P.P

ASSW

OR

D

P.R

OLE

A.P

HY

SEC

A.S

ING

EN

A.N

OT

NEG

A.S

UPPO

RT

A.M

GT

O.MEDIATE X X O.IDAUTH X O.ATTEMP X O.AUDREC X X O.SECFUN X X X X OE.PHYSEC X OE.SINGEN X OE.STR_PW X OE.SUPPORT X OE.MGT X OE.TRUSTED X X



9.2.1 Security objectives rationale

Table 15 Rationale to demonstrate that all threats are countered

Threat Rationale

T.EXT_NETWORK T.EXT_NETWORK -> O.MEDIATE The threat of an unauthorized person on the external network violating the integrity and confidentiality of internal data is mitigated by : O.MEDIATE: The TOE protects the data on the internal network and enforces internal network policy by ensuring that all IP datagrams travelling between internal and external networks are assessed, and acted on, based on administrator defined traffic flow rules.

T.INT_NETWORK T.EXT_NETWORK -> O.MEDIATE The threat of a person on the internal network violating the organizations security policy by accessing information on the external network is mitigated by : O.MEDIATE: The TOE enforces the policy on the internal network by ensuring that all datagrams between internal and external network are mediated by the TOE.

T.UNAUTH T.UNAUTH -> O.IDAUTH, and O.SECFUN The threat of unauthorized access to read, modifies, or destroys TOE critical configuration data is mitigated by implementing mechanisms of: O.IDAUTH: requiring identification and authentication of administrators before allowing access to TOE management functions. O.SECFUN: The TOE ensures that only authorized administrators are able to access TOE security functions.

T.SHTDWN_AUDIT T.SHTDWN_AUDIT -> O.SECFUN The threat of an unauthorized person violating the authenticity of audit records by shutting down the audit functionality is mitigated by : O.SECFUN: The TOE protects its audit records by ensuring that only administrators can enable or disable security functionality including the audit functionality.



Threat Rationale

T.PASS-UNDETECT T.PASS-UNDETECT -> O.ATTEMP and O.AUDREC The threat of unauthorized user successfully access the TOE data or security functions and may go undetected is mitigated by implementing mechanisms of : O.ATTEMP: The TOE provides a mechanism to monitoring successful and unsuccessful attempts at connections. O.AUDREC: The TOE preserves audit trails with accurate dates and times of security-related events.

T.DEL_AUDIT T.DEL_AUDIT -> O.SECFUN and O.AUDREC The threat of an unauthorized person violating the authenticity of audit records by intentionally deleting audit records is mitigated by implementing mechanisms of : O.AUDREC: The TOE must provide a means to record a readable audit trail of security-related events, and must provide an interface to store audit trail to internal audit trail and also remote Syslog server. O.SECFUN: The TOE provides only authorized administrators access TOE security functions.

Table 16 Rationale to demonstrate that all Organization Security Policies are enforced

OSP Rationale

P.ROLE P.ROLE -> O.SECFUN, OE.TRUSTED Authorized person assigned by the organization may have access to only appropriate TOE functions and data. O.SECFUN: The TOE provides only authorized administrators access TOE security functions. OE.TRUSTED requires that the organization define the persons responsible for administering the TOE and ensures that the privilege level is commensurate with their responsibilities.

P.PASSWORD P.PASSWORD -> OE.STR_PW User must use combination of special character, number and alphabet with 12 minimum lengths for their password to make it difficult to guess.



9.2.2 Security objectives for the environment

Table 17 Rationale to demonstrate that all assumptions are upheld

Assumption Rationale A.PHYSEC A.PHYSEC –> OE.PHYSEC

This objective for the operating environment ensures that the assumption is upheld that the TOE is physically secured and located within a secure controlled access facility, which will prevent unauthorized physical access or modification. The TOE security objective presented to address this assumption is: OE.PHYSEC

A.SIGNEN A.SIGNEN –> OE.SINGEN This objective for the operating environment ensures that the assumption is upheld that the TOE will be the gateway of information flow between the internal and external networks. The TOE security objective presented to address this assumption is: OE.SINGEN

A.NOTNEG A.NOTNEG -> OE.TRUSTED This objective ensures that administrators are trusted, trained and have appropriate privileges to perform their tasks. This will ensure that administrators are not negligent.

A.SUPPORT A.SUPPORT -> OE.SUPPORT This objective ensures that administrators provide the correct operating environment for the TOE.

A.MGT A.MGT -> OE.MGT This objective ensures that administrators use interfaces that are auditable unless there is no other option. This objective also ensures that management traffic is protected if remote management is required for use.



9.3 SECURITY REQUIREMENTS RATIONALE

9.3.1 Tracing of SFR to security objectives

The functional and assurance requirements presented in this ST are mutually supportive and their combinations meet the stated security objectives. The security requirements were derived according to the general model presented in Part 1 of the Common Criteria. Table 18 illustrates the mapping between the security requirements and the security objectives. Table 19 gives the rationale for mapping of security requirements and security objectives. Together these tables demonstrate the completeness and sufficiency of the requirements.

Table 18 Mapping of Security Functional Requirements and TOE Security Objectives

O

.MED

IAT

O.ID

AU

TH

O.A

TTEM

P

O.A

UD

REC

O.S

ECFU

N

FAU_GEN.1 X X

FAU_GEN.2 X

FAU_SAR.1 X X

FAU_SAR.3 X X

FAU_STG.1 X

FAU_STG.3 X

FAU_STG.4 X

FDP_IFC.1 X

FDP_IFF.1 X

FIA_ATD.1 (1) X X

FIA_ATD.1 (2) X X

FIA_UAU.2 X

FIA_UID.2 X

FMT_MOF.1 X

FMT_MTD.1 X

FMT_SMF.1 X

FMT_SMR.1 X X

FPT_STM.1 X



Table 19 Rationale for Mapping of Security Functional Requirements and TOE Security Objectives Objective Rationale O.MEDIAT

O.MEDIAT is fully met by the following SFRs: FDP_IFF.1 and FDP_IFC.1 define the traffic flow rules and assess all traffic passing through the TOE based on those rules. The TOE will pass, reject or drop packets based in accordance with the rules. The TOE provides explicit deny rules to prevent external network subjects from assuming internal network IP Addresses and vice versa.

O.IDAUTH

O.IDAUTH is fully met by the following SFRs: FIA_UID.2 requires that all administrative users are identified before being granted access to the management interfaces. FIA_UAU.2 requires that all administrative roles are authenticated before being granted access to the management interfaces. FMT_SMR.1 defines the management roles in the TOE. FIA_ATD.1 (1) links administrative users to roles, by maintaining a mapping of IP/MAC Addresses to TOE Roles. FIA_ATD.1 (2) Provides attributes on the TOE Roles to ensure their secure use.

O.ATTEMP

O.ATTEMP is fully met by the following SFRs: FAU_GEN.1 generates audit records for all connection attempts. The records include the presumed IP address for both the source and destination of the traffic. This SFR ensures that audit logs are replicated on a syslog server, to prevent issues with the TOE audit logs hampering an investigation. FAU_SAR.1 provides administrators a method to review TOE internal logs. FAU_SAR.3 provides administrators with the ability to sort internal audit logs to allow for faster analysis.

O.AUDREC

O.AUDREC is fully met by the following SFRs: FAU_GEN.1 generates audit records for all security related events. The records include the presumed IP address for both the source and destination of the traffic, and other key details including date and time. This SFR ensures that audit logs are replicated on a syslog server, to prevent issues with the TOE audit logs hampering an investigation.



FAU_GEN.2 generates audits records which include the identity of the user that caused the event. FAU_SAR.1 provides administrators a method to review TOE internal logs. FAU_SAR.3 provides administrators with the ability to sort internal audit logs to allow for faster analysis. FAU_STG.1 ensures that only authorized administrators can delete the audit records and that no modifications of the records is possible. FAU_STG.3 provides an alarm (email) to the administrator, alerting the fact that the internal audit log nearing exhaustion. FAU_STG.4 provides for prevention of not auditing new records by overwriting the oldest records until the internal log is cleared. FPT_STM.1 uses NTP to provide accurate date and time for the audit log.

O.SECFUN

O.SECFUN is fully met by the following SFRs: FMT_SMF.1 provides the administrator with all functionality required to administer the TOE. FMT_MOF.1 and FMT_MTD.1 provide restrictions on which roles can modify security attributes and functions to ensure that admin roles can be appropriately separated. FMT_SMR.1, FIA_ATD.1 (1), FIA_ATD.1 (2) all support the management SFRs by providing appropriate roles, mapping administrators to roles and ensuring that the roles have appropriate attributes.



9.3.2 SFR dependency rationale

The following table provides a demonstration that all of the functional requirements of the Security Functional Requirements included within the TOE have been satisfied.

Table 20 SFR dependency rationale

SFR Dependency Justification

FAU_GEN.1 FPT_STM.1 Satisfied with FPT_STM.1

FAU_GEN.2 FAU_GEN.1,

FIA_UID.1

Satisfied with FAU_GEN.1 and FIA_UID.2(hierarchically)

FAU_SAR.1 FAU_GEN.1 Satisfied with FAU_GEN.1

FAU_SAR.3 FAU_SAR.1 Satisfied with FAU_SAR.1

FAU_STG.1 FAU_GEN.1 Satisfied with FAU_GEN.1

FAU_STG.3 FAU_STG.1 Satisfied with FAU_STG.1

FAU_STG.4 FAU_STG.1 Satisfied with FAU_STG.1

FDP_IFC.1 FDP_IFF.1 Satisfied with FDP_IFF.1

FDP_IFF.1 FDP_IFC.1,

FMT_MSA.3

Satisfied with FDP_IFC.1

Not applicable. FMT_MSA.3 requires that changeable attributes be controlled within the TSC. The TOE does not control the attributes of the information or subjects (as subjects are not authenticated). The management of flow control rules, which are TSF data, is covered by FMT_MTD.1.

FIA_UAU.2 FIA_UID.1 Not applicable. The TOE identifies users based on their presumed IP address and MAC address. The password is related to the interface that is used, and the interface that the administrator connects to determines which admin role the administrator assumes. The authentication by password provides the TOE with enough information to determine access privileges.

FIA_UID.2 None No dependencies to satisfy.

FIA_ATD.1 (both iterations)

None No dependencies to satisfy.

FMT_MOF.1 FMT_SMR.1

FMT_SMF.1

Satisfied with FMT_SMR.1 and FMT_SMF.1

FMT_MTD.1 FMT_SMR.1

FMT_SMF.1

Satisfied with FMT_SMR.1 and FMT_SMF.1

FMT_SMR.1 FIA_UID.1 Not applicable. The TOE identifies users based on their IP and MAC address. The role assumed is determined by a combination of the interface used to connect and the password provided.

FMT_SMF.1 None No dependencies to satisfy.

FPT_STM.1 None No dependencies to satisfy.



9.3.3 SAR justification

The security assurance requirements selected for the TOE is from the CC EAL3 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 security assurance requirements selected are also consistent and are a mutually supportive set of SAR because they constitute a complete EAL.

TRACENETWORK CORPORATION M yBOX Firewall, EAL3 ST v… · Tracenetwork Corporation Sdn Bhd Page 2...

Documents

Transcript of TRACENETWORK CORPORATION M yBOX Firewall, EAL3 ST v… · Tracenetwork Corporation Sdn Bhd Page 2...