Security Target For BorderWare 6.1.1
Reference: ST
January 2000
Version : 2.4
North America: Europe:
90 Burnhampthorpe Rd. W. 1 The Harlequin Centre
Suite 1402 Southall Lane
Mississauga Southall
Ontario Middlesex
Canada L5B 3C3 UB2 5NH U.K.
Page 2 of 2 Version 2.4
Ref.: ST 23 February 2000
DOCUMENT AUTHORISATION
DOCUMENT TITLE Security Target for BorderWare 6.1.1
Reference Version Date Description
ST 1.0 June 1999 Issue for evaluation.
ST 1.1 03 August
1999
Update to incorporate FPT_SEP and
FPT_RVM, and address EORs 2, 3,
5,6,7, and RFC/1.
ST 2.0 08November
1999
Update to reflect removal of Secure
FTP and Telnet, address CB
comments, EOR 9 and RFC5
ST 2.1 14 December
1999
Update to incorporate response to
EOR/18
ST 2.2 16 January
2000
Update to incorporate response to
EOR/19 and comments from
evaluation RFC dated 14th
January
2000
ST 2.3 19 January
2000
Update to address EOR/20
ST 2.4 23 January
2000
Update to correct definition of SOF
claims.
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 3 of 3
23 February 2000 Ref.: ST
Contents
1 INTRODUCTION TO THE SECURITY TARGET 7
1.1 Security Target Identification 7
1.2 Security Target Overview 7
1.3 CC Conformance Claim 7
2 TOE DESCRIPTION 8
2.1 Hardware and Software Requirements for Admin GUI 11
3 SECURITY ENVIRONMENT 12
3.1 Introduction 12
3.2 Threats 12
3.2.1 Threats countered by the TOE 12
3.2.2 Threats countered by the Operating Environment 13
3.3 Organisational Security Policies 13
3.4 Assumptions 13
4 SECURITY OBJECTIVES 14
4.1 TOE Security Objectives 14
4.1.1 IT Security Objectives 14
4.1.2 Non-IT Security Objectives 15
4.2 Environment Security Objectives 15
4.2.1 IT Security Objectives 15
4.2.2 Non-IT Security Objectives 15
5 IT SECURITY REQUIREMENTS 17
5.1 TOE Security Functional Requirements 17
5.1.1 Identification and Authentication 18
5.1.2 Security Management 19
5.1.3 Security Audit 21
5.1.4 Protection of the Trusted Security Functions 22
5.1.5 User Data Protection 23
5.2 TOE Security Assurance Requirements 27
5.3 Security Requirements for the IT Environment 29
5.4 Strength of Function Claim 29
6 TOE SUMMARY SPECIFICATION 30
6.1 TOE Security Functions 30
6.1.1 Identification and Authentication 30
6.1.2 Management and Security Attributes 30
Page 4 of 4 Version 2.4
Ref.: ST 23 February 2000
6.1.3 Audit 31
6.1.4 Protection of TOE Security Functions 32
6.1.5 User Data Protection 32
6.2 Assurance Measures 37
6.3 Permutational IT Security Functions 37
7 PROTECTION PROFILES CLAIMS 38
8 RATIONALE 39
8.1 Introduction 39
8.2 Security Objectives for the TOE and Environment Rationale 39
8.2.1 T.EXT_CONN 40
8.2.2 T.INT_CONN 40
8.2.3 T.SOURCE 40
8.2.4 T.CONFIG 40
8.2.5 T.UNAUTH 40
8.2.6 T.OS_FAC 41
8.2.7 TE.VIOLATE 41
8.2.8 A.PHYSICAL 41
8.2.9 A.LIMIT 41
8.3 Security Requirements Rationale 41
8.3.1 Requirements are appropriate 41
8.3.2 Security Requirement dependencies are satisfied 42
8.3.3 Security Requirements are mutually supportive 44
8.3.4 ST complies with the referenced PPs 44
8.3.5 IT security functions satisfy SFRs 44
8.3.6 IT security functions mutually supportive 47
8.3.7 Strength of Function claims are appropriate 47
8.3.8 Assurance measures satisfy assurance requirements 47
FIGURE 2-1- OVERVIEW OF BFS 10
TABLE 8-1 OBJECTIVES RATIONALE 40
TABLE 8-2 MAPPING OF OBJECTIVES TO SFRS 42
TABLE 8-3 MAPPING OF SFR DEPENDENCIES 43
TABLE 8-4 MAPPING OF IT FUNCTIONS TO SFRS 46
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 5 of 5
23 February 2000 Ref.: ST
REFERENCES
[CC] Common Criteria for Information Technology Security Evaluation,
Version 2.0, May 1998
Page 6 of 6 Version 2.4
Ref.: ST 23 February 2000
GLOSSARY AND TERMS
DMZ De-militarised Zone
DNS Domain Name Server
FTP File Transfer Protocol
GUI Graphical User Interface
IP Internet Protocol
IT Information Technology
POP Post Office Protocol
PP Protection Profile
SFP Security Function Policy
SMTP Simple Mail Transfer Protocol
SQL Structured Query Language
SSN Secure Servers Network
ST Security Target
TCP Transmission Control Protocol
TOE Target of Evaluation
TSC TSF Scope of Control
TSF TOE Security Functions
UDP User Datagram Protocol
WWW World Wide Web
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 7 of 7
23 February 2000 Ref.: ST
1 Introduction to the Security Target
1.1 Security Target Identification
Title: Security Target for BorderWare 6.1.1.
Assurance Level: EAL4, augmented with ALC_FLR.1.
1.2 Security Target Overview
The BorderWare Firewall Server (BFS) is designed to combine robust security with the
complete set of ancillary services necessary to implement an Internet connection or to
provide secure Intranet connections. The BFS incorporates a hardened operating system
further optimised for security and throughput.
The purpose-designed operating system provides a separate domain of execution for
each critical subsystem and implements kernel-level packet filtering to enhance security.
These subsystems include application level proxies and application servers. The proxies
manage connections for all well-known TCP/IP applications, which the servers provide
facilities such as DNS and mail relay. BFS provides dual Domain Name Servers, which
together with Network Address Translation ensure complete separation between Internal
and external networks. The mail relay service ensures protects e-mail servers by
allowing mail dispatch and delivery without ever permitting a connection between the
server and the untrusted network.
1.3 CC Conformance Claim
This TOE has been developed to conform to the functional components as defined in the
Common Criteria version 2.0 [CC] part 2, with the assurance level of EAL4, augmented
with ALC_FLR.1 as identified in part 3 of [CC].
Page 8 of 8 Version 2.4
Ref.: ST 23 February 2000
2 TOE Description
This TOE is an application-level firewall. It mediates information flows between clients
and servers located on internal and external networks governed by the TOE. The TOE
employs proxies to screen information flows. Proxy servers on the TOE, for inbound
services such as FTP and Telnet, require authentication at the TOE by client users before
requests for such services can be authorised. Thus, only valid requests are relayed by the
proxy server to the actual server on the internal network.
The TOE delivers three security layers:
• packet filtering;
• circuit level gateways; and
• application level gateways.
The packet filtering controls are performed at the operating system kernel level. By
default, these security policy rules deny all inbound information flows. Only an
authorised administrator has the authority to change the security policy rules.
The BFS operating system does not permit any operating system user logins. All direct
interaction with the TOE to perform configuration and administration tasks is performed
on the firewall server console or using the Admin GUI on a client connected to the
internal, protected network. The administrator is the only user who is able to directly
interact with the TOE. Interaction with the TOE is transparent to all other users.
The Administrator is able to perform basic configuration and administration of the BFS
using the firewall server console, via the “Admin menu”. Access to the console is to be
physically protected and logically controlled through password protection. Full
administration services are only provided through use of the Admin GUI at a client
workstation. Use of the Admin GUI is protected by use of a password. A
challenge/response Crypto Card authentication token (56 bit DES encryption) may be
used, but this is beyond the scope of the evaluation.
The outbound gateway provides transparent services to the user on the internal network.
Multiple Address Translation is provided for inbound traffic received at the firewall to
enable a number of IP addresses to be specified for servers within the Secure Server
Network (SSN) area, the de-militarised zone.
Transparent address translation is performed for all outbound traffic. Requests for
connections from a client on the internal network to a server on the external network are
directed by the client to the server’s actual IP address. If the TOE is configured
correctly, as the only connection between the internal and external networks, then the
appropriate proxy for the requested service will be activated by the TOE (subject to
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 9 of 9
23 February 2000 Ref.: ST
successfully passing any appropriate identification, authentication or access controls) to
handle that request. The proxy will ensure that the apparent source address of that
connection is set to that of the TOE’s external interface before any IP datagrams are
transmitted on the external network. Inbound address translation is not transparent. An
external entity must direct all traffic to an address assigned to the TOE’s external
interface. Subject to successful identification and authentication this traffic can be
relayed to an entity on the internal network. The address translation is augmented by the
separate Domain Name Servers who ensure that internal addresses are never disclosed to
an external entity by domain name lookup.
The TOE requires at least two network interfaces to function correctly and can support a
maximum of three network interface cards. If the TOE is running on a hardware
platform with two network cards these are assigned the function of internal and external
network interfaces. If an optional 3rd
network card is installed, this is assigned the
function of the SSN network interface.
The proxies included within the scope of evaluation of this product are identified in
Section 6.1.5.
When recorded, the audit trail data is stamped with the date and time information. Audit
events include:
• Every successful inbound and outbound connection;
• Every unsuccessful connection;
• Every successful and unsuccessful administrator authentication attempt.
If the audit trail becomes filled, thenthe trail will be archived and a new audit trail
initialised. If the limit of archived audit trails is reached, the oldest archive will be
deleted to allow the current audit trail to be archived. This mechanism ensures that
partition on the TOE’s disc reserved for audit information never becomes full, an event
which could lead to loss of audit information.
The BorderWare product also provides the following functionality that is not within the
scope of this evaluation:
• 3rd Party Authentication (e.g. Crypto Card for administration authentication at
remote Admin GUI or Secure inbound FTP and Telnet proxies);
• Virtual Private Network (VPN);
• User Defined Proxies;
• URL Filtering (SmartFilter);
Page 10 of 10 Version 2.4
Ref.: ST 23 February 2000
• Secure administration of the BFS from the external (unprotected) network.
Internal
Network
External
Network
Secure
Server
Network
System
Console
BorderWare
Firewall
Server
Remote
Admin
GUI
Scope of the TOE
Figure 2-1- Overview of BFS
The following table identifies the hardware requirements for an installation of the
BorderWare firewall server. For the purposes of this evaluation, equipment within the
range of specifications stated in the following table were tested on Compaq and Dell
hardware.
Hardware CPU Ram Hard Disk(s)
Compaq
Deskpro
400 MHz Celeron 64 Mbytes Memory 6 Gbyte IDE Disk
Compaq
Proliant
600 MHz PIII 128 Mbytes
Memory
9 Gbyte SCSI Disk
Dell
Dimension
466 MHz Celeron 64 Mbytes Memory 6 Gbyte IDE disk
Dell
PowerEdge
500 Mhz PIII 256 Mbytes
Memory
9 Gbyte SCSI Disk
Each of the above hardware platforms include:
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 11 of 11
23 February 2000 Ref.: ST
• CD-ROM drive;
• 3.5” diskette drive;
• monitor;
• keyboard;
• Ethernet interface cards.
2.1 Hardware and Software Requirements for Admin GUI
The Admin GUI required for remote administration of the TOE is supplied as an
application called BWClient. BWClient runs on any Win32 operating system (Windows
NT, Windows 95 and Windows 98). BWClient is a user level program and has no
special hardware or software requirements, expect that Win32 system must be equipped
with a network connection and must have TCP/IP networking installed and configured.
Certain early versions of windows were lacking certain network DLLs which are
supplied as part of the Internet Explorer package and are required by BWClient.
BWClient includes a “minimal impact” set of these DLLs and will install them (after
prompting for confirmation) if it detects that these DLLs are not present. In addition it is
recommended (but not mandatory) that NT systems should be patched to at least Service
pack 3.
A copy of BWClient is included on the TOE distribution CD Rom. It is packaged as a
standard Windows installation package and should be installed on any Win32 system
meeting the requirements outlined above.
Page 12 of 12 Version 2.4
Ref.: ST 23 February 2000
3 Security Environment
3.1 Introduction
This section provides the statement of the TOE security environment, which identifies
and explains all:
- known and presumed threats countered by either the TOE or by the security
environment;
- organisational security policies the TOE must comply with;
- assumptions about the secure usage of the TOE, including physical, personnel
and connectivity aspects.
3.2 Threats
This section identifies the threats to the IT assets against which protection is required by
the TOE or by the security environment.
3.2.1 Threats countered by the TOE
The IT assets requiring protection are the services provided by, and data accessible via,
hosts on the internal network.
The general threats to be countered are:
• attackers on the external network may gain inappropriate access to the internal
network;
• users on the internal network may inappropriately expose data or resources to
the external network.
The following specific threats are countered:
T.EXT_CONN An attacker on the external network may try to connect to
services other than those expressly intended to be available in
accordance with the security policy (e.g. an external user
attempts to use unauthenticated FTP).
T.INT_CONN An attacker on the internal network may try to connect to
services other than those expressly intended to be available.
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 13 of 13
23 February 2000 Ref.: ST
T.SOURCE An attacker on the internal/external network may attempt to
initiate a service from an unauthorised source.
T.CONFIG An attacker on the internal/external network may exploit an
insecure configuration (i.e. not in accordance with the chosen
network security policy) of the firewall.
T.UNAUTH Unauthorised changes to the configuration may be completed
without being identified.
T.OS_FAC An attacker on the internal/external network may attempt to
use operating system facilities on the firewall server.
3.2.2 Threats countered by the Operating Environment
The following is a list of threats that must be countered by technical and/or non-
technical measures in the IT environment, or must be accepted as potential security risks.
TE.VIOLATE Violation of network security policy as a result of inaction, or
action taken, by careless, wilfully negligent, or external
system administrators.
3.3 Organisational Security Policies
There are no organisational security policies or rules with which the TOE must comply.
3.4 Assumptions
The following assumptions describe security aspects of the environment in which the
TOE will be used or is intended to be used. This includes information about the
intended usage of the TOE and the environment of use of the TOE.
A.PHYSICAL The firewall must be physically protected to prevent hostile
individuals engaging in theft, implantation of devices, or
unauthorised alteration of the physical configuration of the
firewall (e.g. bypassing the firewall altogether by connecting
the internal and external networks together).
A.LIMIT The firewall will limit the access to resources and data
between an internal and external network.
Page 14 of 14 Version 2.4
Ref.: ST 23 February 2000
4 Security Objectives
4.1 TOE Security Objectives
4.1.1 IT Security Objectives
The principal IT security objective of this firewall is to reduce the vulnerabilities of an
internal network exposed to an external network by limiting the hosts and services
available. Additionally, the firewall has the objective of providing the ability to monitor
established connections and attempted connections between the two networks.
The specific IT security objectives are as follows:
O.VALID The firewall must limit the valid range of addresses expected on
each of the internal and external networks (i.e. an external host
cannot spoof an internal host).
O.HOSTILE The firewall must limit the hosts and service ports that can be
accessed from the external network.
O.PRIVATE The firewall must limit the hosts and service ports that can be
accessed from the internal network.
O.AUTH The firewall must provide authentication of the end-user prior to
establishing a through connection, in accordance with the security
policy enforced on the BFS. (The policy is to ensure no services
are allowed for inbound connections.)
O.ATTEMPT The firewall must provide a facility for monitoring successful and
unsuccessful attempts at connections between the networks.
O.ADMIN The firewall must provide a secure method of administrative control
of the firewall, ensuring that the authorised administrator, and only
the authorised administrator, can exercise such control
O.SECPROC The firewall must provide separate areas in which to process
security functions and service requests. The processing of a
security function must be completed prior to invocation of
subsequent security functions.
O.CONFIG The firewall is designed or configured solely to act as a firewall and
does not provide any operating system user services (e.g. login
shell) to any network users; only administrators have direct access.
(The firewall does, however, provide application proxy
authentication.)
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 15 of 15
23 February 2000 Ref.: ST
4.1.2 Non-IT Security Objectives
There are no non-IT security objectives to be satisfied by the TOE.
4.2 Environment Security Objectives
4.2.1 IT Security Objectives
There are no IT environment security objectives to be provided by software outside the
scope of the TOE.
4.2.2 Non-IT Security Objectives
The following non-IT environment security objectives are to be satisfied without
imposing technical requirements on the TOE. That is, they will not require the
implementation of functions in the TOE hardware and/or software. Thus, they will be
satisfied largely through application of procedural or administrative measures.
NOE.DELIV Those responsible for the firewall must ensure that it is
delivered, installed, managed and operated in a manner that
maintains the security policy.
NOE.TRAIN Those responsible for the firewall must train administrators to
establish and maintain sound security policies and practices.
NOE.AUDIT Administrators of the firewall must ensure that the audit
facilities are used and managed effectively. In particular,
audit logs should be inspected on a regular basis and
appropriate action should be taken on the detection of
breaches of security, or events that are likely to lead to a
breach in the future. Furthermore, appropriate archive action
must be taken to ensure security logs archived by the firewall
are no overwritten before they are inspected
NOE.NETWORK The firewall must be configured as the only network
connection between the internal network and the external
network.
NOE.MANAGE A firewall administrator is assigned with responsibility for
day to day management and configuration of the firewall.
Including the management of the audit trail.
Page 16 of 16 Version 2.4
Ref.: ST 23 February 2000
NOE.PHYSICAL The firewall must be physically protected so that only
administrators have access. (The firewall must only be
administered via the dedicated management port on the
firewall or using the administration GUI on the internal
network.)
NOE.REVIEW The configuration of the firewall will be reviewed on a
regular basis to ensure that the configuration continues to
meet the organisation’s security objectives in the face of:
- changes to the firewall configuration;
- changes in the security objectives;
- changes in the threats presented by the external network;
- changes in the hosts and services made available to the
external network by the internal network.
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 17 of 17
23 February 2000 Ref.: ST
5 IT Security Requirements
5.1 TOE Security Functional Requirements
The functional security requirements for this Security Target are discussed in detail
below. The following table summarises those security requirements.
Functional Components
FIA_UID.1 Timing of Identification
FIA_UAU.1 Timing of Authentication
FIA_AFL.1 Authentication Failure Handling
FMT_MSA.1 Management of Security Attributes
FMT_MSA.3 Static Attribute Definition
FMT_SMR.1 Security Roles
FMT_MTD.1 Management of the TSF Data
FAU_GEN.1 Security Audit Data Generation
FAU_ARP.1 Security Alarms
FAU_SAA.1 Security Audit Analysis
FAU_SAR.1 Security Audit Review
FAU_STG.1 Protected Audit Trail Storage
FPT_RVM.1 Non-Bypassability of the TSP
FPT_SEP.1 TSF Domain Separation
FPT_STM.1 Reliable Time Stamps
FDP_ACC.1 Subset Access Control
FDP_ACF.1 Security Attribute Based Access Control
FDP_IFC.1 Subset Information Flow Control
Page 18 of 18 Version 2.4
Ref.: ST 23 February 2000
Functional Components
FDP_IFF.1 Simple Security Attributes
Table 5-1: Functional Requirements
5.1.1 Identification and Authentication
This section addresses the requirements for functions to establish and verify a claimed
user identify. This includes identification of any actions that the TOE may complete on
the user’s behalf prior to identification or authentication.
The only type of user who can interact directly with the BFS interface (System Console
or remote Admin GUI) is an administrator. Therefore, BFS administrators are the only
users who can log into the BFS interface (identify and authenticate themselves) and
access the TSF data. As administrators are able to access all TSF data, the identification
and authentication mechanisms to the BFS interface provide a basic form of access
control.
Other, unprivileged operators, use services provided by the TOE but do not visibly
interact with the TOE. For the TOE to control requests for services by these
unprivileged users the TOE may require the user to identify, and for some services
authenticate, them for use of the service. This request will be seen as generating from a
particular IP address.
A privileged operator, the FTP administrator user (FTP account “admin”), is able to
access additional areas (e.g. where system accounting logs are stored) on the FTP server
than an unprivileged FTP user, and has privileges to create, delete and modify directories
on the server which are not available to an unprivileged FTP user. This account is
referred to as “FTP Admin”. These privileges are controlled by the BFS operating
system. This account can only be accessed from a request generated on the internal
network. It is assumed (as stated in the non-IT environment objectives) that this account
is used by those performing the administration of the BFS
FIA_UID.1 Timing of Identification
FIA_UID.1.1 The TSF shall allow [information flows, compliant with the
UNIDENTIFIED information flow FSP] on behalf of the user
to be performed before the user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified
before allowing any other TSF-mediated actions on behalf of
that user.
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 19 of 19
23 February 2000 Ref.: ST
FIA_UAU.1 Timing of Authentication
FIA_UAU.1.1 The TSF shall allow:
a) [information flow control decisions based on the
information flow control outbound and inbound proxies, and
service request policies to allow or deny traffic;
b) identification mechanisms defined in FIA_UID.1;
c) audit of failed authentication attempts,]
on behalf of the user to be performed before the user is
authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully
authenticated before allowing any other TSF-mediated actions
on behalf of that user.
Application
Note:
The “user” referred to in the SFRs above relates to both a BFS
administrative user (administrator at the BFS console or using
the Admin GUI on an internal client) and a service requested
by an indirect user (including FTP Admin), which is associated
with an individual IP address on the internal or external
network.
FIA_AFL.1 Authentication Failure Handling
FIA_AFL.1.1 The TSF shall detect when [1] unsuccessful authentication
attempts occur related to [an authentication attempt originating
from an individual IP address on the internal or external
network or an administrator].
FIA_AFL.1.2 When the defined number of unsuccessful authentication
attempts has been met or surpassed, the TSF shall [log the
unsuccessful authentication attempt].
5.1.2 Security Management
This section defines requirements for the management of security attributes that are used
to enforce the SFP.
FMT_SMR.1 Security Roles
FMT_SMR.1.1 The TSF shall maintain the roles [administrator, FTP Admin].
Page 20 of 20 Version 2.4
Ref.: ST 23 February 2000
FMT_SMR.1.2 The TSF shall be able to associate users with the role.
FMT_MSA.1 Management of Security Attributes
FMT_MSA.1.1 The TSF shall enforce the [BFS Access Control SFP] to restrict
the ability to :
• [change_default, query, modify and delete] the security
attributes [the permissions to permit or deny traffic flow];
• [query, modify, delete and [create]] the security attributes
[BFS administrator accounts and FTP Admin account;
• [query, modify, delete and [create]] the security attributes
[FTP accounts];
• [modify] the security attributes [the administrator
passwords];
• [modify] the security attributes [the FTP admin password];
• [change_default, query, modify] the security attributes
[FTP server and Web server];
to the [administrator role].
FMT_MSA.3 Static Attribute Initialisation
FMT_MSA.3.1 The TSF shall enforce the [UNIDENTIFIED,
UNAUTHENTICATED and AUTHENTICATED SFPs and
Access 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.
FMT_MTD.1 Management of the TSF Data
FMT_MTD.1.1a The TSF shall restrict the ability to:
• [query] the [audit logs];
• [query and modify] the [time];
to [administrator].
FMT_MTD.1.1b The TSF shall restrict the ability to [query, copy and delete]
the [audit logs] to [FTP administrator].
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 21 of 21
23 February 2000 Ref.: ST
5.1.3 Security Audit
This section involves recognising, recording and storing information related to security
relevant activities.
FAU_GEN.1 Security Audit Data Generation
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the
following auditable events:
a) start-up and shutdown of the audit functions;
b) All auditable events for the [not specified] level of audit;
and
c) [Every successful inbound and outbound connection;
Every unsuccessful connection;
Every successful and unsuccessful administrator
authentication attempt].
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
(source address), outcome of the event; and
b) For each audit event type, based on the auditable event
definitions of the functional components included in the
PP/ST, [required destination address, and TCP/UDP port for
network connections].
FAU_ARP.1 Security Alarms
FAU_ARP.1.1 The TSF shall take [the following actions:
a) log a record of the event in the security trail;
b) e-mail the administrator with details of the actual/potential
securityviolation]
upon detection of a potential security violation.
Page 22 of 22 Version 2.4
Ref.: ST 23 February 2000
FAU_SAA.1 Security Audit Analysis
FAU_SAA.1.1 The TSF shall be able to apply a set of rules in monitoring the
audited events and based upon these rules indicate a potential
violation in the TSP.
FAU_SAA.1.2 The TSF shall enforce the following rules for monitoring
audited events:
a) accumulation or combination of [a configurable number of
attempts to make a connection to a service which does not
have a server or proxy enabled] known to indicate a
potential security violation.
FAU_SAR.1 Security Audit Review
FAU_SAR.1.1 The TSF shall provide [administrators] with the capability to
read [all audit information] 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.
FAU_STG.1 Protected Audit Trail Storage
FAU_STG.1.1 The TSF shall protect the stored audit records from
unauthorised deletion.
FAU_STG.1.2 The TSF shall be able to [prevent] modifications to the audit
records.
5.1.4 Protection of the Trusted Security Functions
This section specifies functional requirements that relate to the integrity and
management of the mechanisms providing the TSF and the TSF data.
FPT_RVM.1 Non-Bypassability of the TSP
FPT_RVM.1.1 The TSF shall ensure that TSP enforcement functions are
invoked and succeed before each function within the TSC is
allowed to proceed.
FPT_SEP.1 TSF Domain Separation
FPT_SEP.1.1 The TSF shall maintain a security domain for its own execution
that protects it from interference and tampering by untrusted
subjects.
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 23 of 23
23 February 2000 Ref.: ST
FPT_SEP.1.2 The TSF shall enforce separation between the security domains
of subjects in the TSC.
FPT_STM.1 Reliable Time Stamps
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its
own use.
5.1.5 User Data Protection
This section specifies requirements for TOE security functions and TOE security
function policies relating to protecting user data. These are used to ensure a secure
channel for administration and the control of user traffic through the firewall.
Access to the BFS internal data is controlled by the identification and authentication of
an administrator at the BFS console. Once this has been completed, according to the
requirements specified by the FIA class of components, an administrative user is able to
access all TSF data.
Access to data stored in the FTP server is controlled according to the FTP account the
user has successfully provided the necessary authentication information. An
“anonymous” or “ftp” FTP user can only access a subset of the information that the FTP
Admin user is able to access.
FDP_ACC.1 Subset Access Control
FDP_ACC.1.1a The TSF shall enforce the [BFS Access Control SFP] on [TSF
data].
FDP_ACC.1.1b The TSF shall enforce the [FTP Access Control SFP] on [FTP
server data].
FDP_ACF.1 Security Attribute Based Access Control
FDP_ACF.1.1a The TSF shall enforce the [BFS Access Control SFP] to objects
based on [the user being an authenticated administrator].
FDP_ACF.1.1b The TSF shall enforce the [FTP Access Control SFP] to objects
based on [the ftp account the user has successfully provided the
necessary authentication information].
FDP_ACF.1.2a The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlledobjects is
allowed: [the subject invoking an operation on the object is an
administrator of the BFS].
Page 24 of 24 Version 2.4
Ref.: ST 23 February 2000
FDP_ACF.1.2b The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is
allowed:
1. [creation, modification or deletion of objects on the FTP
server may only be performed by authenticated FTP admin
users;
2. access to the admin area on the FTP server may only be
granted to authenticated FTP admin users;
3. anonymous FTP users are granted read and copy access to
the public area only on the FTP server].
FDP_ACF.1.3 The TSF has explicitly authorised access of subjects to objects
based on the following additional rules [none].
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects
based on the [subject not being an administrator of the BFS or
an FTP user].
There are three main types of information flow:
a.) AUTHENTICATED –traffic from the internal network to the BFS, providing
access to the BFS for a remote Administrator on the internal network, which
requires the source subject to be identified and authenticated as an administrator
of the BFS;
b.) UNAUTHENTICATED – outbound traffic, of which the source subject is
identified, but not authenticated. Also, inbound traffic from the external network
to the SSN, and inbound traffic from the SSN to the internal network as this is a
controlled flow from a known source;
c.) UNIDENTIFIED – outbound traffic, of which the source subject is not identified,
and inbound traffic from the external network to the SSN;
Each of these policies defines the information flows that are permissible for the types of
inbound traffic (external to internal information flows) and outbound traffic (internal to
external information flows). These policies are defined using the rules specified below.
In the specification of the SFRs below, the subsections of the requirement listed as ‘a.)’,
‘b.)’, ‘c.)’, etc. are to be read as “or” operators and the bullets within these subsections
are to be read as “and” operators.
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 25 of 25
23 February 2000 Ref.: ST
FDP_IFC.1 Subset Information Flow Control
FDP_IFC.1.1 TSF shall enforce the [information flow control SFP] on:
a) [external IT entities to send and receive information through
the TOE;
b) internal IT entities to initiate a service and to send and
receive information through the TOE].
FDP_IFF.1 Simple Security Attributes
FDP_IFF.1.1 The TSF shall enforce the [information flow control SFP]
based on the following types of subject and information
security attributes:
a) [the interface on which the request arrives;
b) the following information attributes:
• presumed address of the source subject, as appropriate;
• presumed address of the destination subject, as
appropriate;
• transport layer protocol;
• requested 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) [subjects on the internal network can cause information to
flow through the TOE to either the SSN or the external
network if:
• all information security attribute values are expressly
permitted by the information flow SFP rules;
• the request arrives on the internal interface;
• the presumed address of the destination subject
translates to an address on either the SSN or an address
that is reachable via the external network.
Page 26 of 26 Version 2.4
Ref.: ST 23 February 2000
b) subjects on the external network can cause information to
flow through the TOE to the internal network if:
• all information security attribute values are expressly
permitted by the information flow SFP rules;
• the presumed address of the source subject translates to
an external network address;
• the presumed address of the destination subject
translates to an address assigned to the external
interface of the TOE.
c) subjects on the external network can cause information to
flow through the TOE to the SSN if:
• all information security attribute values are expressly
permitted by the information flow SFP rules;
• the presumed address of the source subject translates to
an external network address;
• the presumed address of the destination subject
translates to an address assigned to the external
interface of the TOE.
d) Subjects on the SSN can cause information to flow through
the TOE to the external network if:
• all information security attribute values are expressly
permitted by the information flow SFP rules;
• the presumed address of the source subject translates to
an SSN address;
• the presumed address of the destination subject
translates to an address on the external network.
e) Subjects on the SSN can cause information to flow through
the TOE to the internal network if:
• all information security attribute values are expressly
permitted by the information flow SFP rules ;
• the presumed address of the source subject translates to
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 27 of 27
23 February 2000 Ref.: ST
an SSN address;
• the presumed address of the destination subject
translates to an address assigned to an SSN interface on
the firewall.]
FDP_IFF.1.3 The TSF shall enforce the [additional SFP rules:
a) restrict by time].
FDP_IFF.1.4 The TSF shall provide the following [notification to the user
(administrator) that the if the attributes of the permitted
information flow specified are considered to be insecure, in the
following instances:
a) defining a non-authenticated inbound proxy;
b) enabling any external to internal proxy;
c) creating a user defined external to internal proxy;
d) enabling any external to SSN proxy;
e) creating a user defined external to SSN proxy;
f) enabling any SSN to internal proxy;
g) creating a user defined SSN to internal proxy.]
FDP_IFF.1.5 The TSF shall explicitly authorise an information flow based
on the following rules [no additional rules to authorise
information flow]
FDP_IFF.1.6 The TSF shall explicitly deny an information flow based on the
following rules:
a) [there is no rule which explicitly allows it;
b) if any of the attributes identified in FDP_IFF.1.1 do not
match].
5.2 TOE Security Assurance Requirements
The assurance requirements for this Security Target, taken from Part 3 of the CC,
compose the EAL4 level of assurance, augmented with the Flaw Remediation assurance
component identified in Part 3. The assurance components are summarised in the
following table.
Page 28 of 28 Version 2.4
Ref.: ST 23 February 2000
Assurance Class Assurance Components
ACM_AUT.1 Partial CM automation
Configuration
management
ACM_CAP.4 Generation support and acceptance
procedures
ACM_SCP.2 Problem tracking CM coverage
Delivery and operation ADO_DEL.2 Detection of modification
ADO_IGS.1 Installation, generation and start-up
procedures
ADV_FSP.2 Fully defined external interfaces
ADV_HLD.2 Security enforcing high-level design
Development ADV_IMP.1 Subset of the implementation of the
TSF
ADV_LLD.1 Descriptive low-level design
ADV_RCR.1 Informal correspondence
demonstration
ADV_SPM.1 Informal TOE security policy model
Guidance documents AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
ALC_DVS.1 Identification of security measures
Life cycle support ALC_FLR.1 Basic flaw remediation
ALC_LCD.1 Developer defined life-cycle model
ALC_TAT.1 Well-defined development tools
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 29 of 29
23 February 2000 Ref.: ST
Assurance Class Assurance Components
ATE_COV.2 Analysis of coverage
Tests ATE_DPT.1 Testing: high-level design
ATE_FUN.1 Functional testing
ATE_IND.2 Independenttesting - sample
AVA_MSU.2 Validation of analysis
Vulnerability assessment AVA_SOF.1 Strength of TOE security function
evaluation
AVA_VLA.2 Independent vulnerability analysis
Table 5-2: Assurance Requirements: EAL4 Augmented by ALC_FLR.1
Further information on these assurance components can be found in [CC] Part 3.
5.3 Security Requirements for the IT Environment
There are no security requirements on the IT environment of the TOE.
5.4 Strength of Function Claim
A Strength of Function (SoF) claim of SOF-MEDIUM is made for the TOE.
Page 30 of 30 Version 2.4
Ref.: ST 23 February 2000
6 TOE Summary Specification
6.1 TOE Security Functions
This section describes the security functions provided by the TOE to meet the security
functional requirements specified for the BorderWare firewall in Section 5.1.
6.1.1 Identificationand Authentication
1. The administrator must be authenticated with the TOE before any administration
functions can be completed. Interaction with the administrator interface at the system
console requires physical access to the console and the password, or interaction with
the administrator interface at the admin GUI requires identification and the
corresponding password.
2. The only flows of information that can take place before identification of the source
of the request are those that conform to the UNIDENTIFIED information flow policy.
3. The only flows of information that can take place before authentication of an
identified source are those that conform to the UNIDENTIFIED or
UNAUTHENTICATED information flow policies.
4. Any failure of an administrator to authenticate with the TOE must result in the
generation of a record in the audit trail.
6.1.2 Management and Security Attributes
1. The rules, which specify the permissible flows of information, can be modified by an
administrator of the TOE. The administrator may provide alternative initial values to
be applied when an information flow rule is created. (The initial values for
administrator account and password cannot be modified.)
2. The TOE shall default to deny all flows of information through the TOE, all proxies
and servers are initially disabled. (Interaction with the BFS administration functions
using the BFS console by an authenticated administrator is permitted at this stage).
After the installation, the system administrator must go through each service and
enable the ones necessary for their network. The result is a completely controlled
environment in which specified services are allowed and all others are denied.
3. Access to the TSF data stored on the TOE (data required for the TOE to operate in a
secure manner) is controlled by authentication of an authorised (access to the BFS
console is permitted or identification if remote) administrator.
4. Access to the data stored on the FTP server will be permitted according to the FTP
account for which the FTP user has successfully provided identification and
authentication information. An anonymous FTP user (identified as “anonymous”)
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 31 of 31
23 February 2000 Ref.: ST
may access only the data in the “public” directory of the FTP server. An FPT admin
(identified as “admin” and authenticated) user may access all data on the FTP server.
5. The only type of direct user of the TOE is an administrator. The FTP admin user is
only able to access the data provided on the FTP server supported by the BFS.
6. In the following instances, where the attributes of the permitted information flow
specified are considered to be insecure, the TOE shall provide the Administrator with
a warning:
a) defining a non-authenticated inbound proxy;
b) enabling any external to internal proxy;
c) creating a user defined external to internal proxy;
d) enabling any external to SSN proxy;
e) creating a user defined external to SSN proxy;
f) enabling any SSN to internal proxy;
g) creating a user defined SSN to internal proxy;
h) an option of “none” is selected as the authentication option for remote
administration.
7. The administrator can query, create, delete and modify BFS administrator accounts
and reset an administrator’s password. The administrator can query, create, delete and
modify FTP admin accounts and reset an FTP admin’s password.
8. The administrator can configure and modify the FTP server for the storage of audit
trails and the Web server for remote access.
6.1.3 Audit
1. The accounting mechanisms cannot be disabled. The start-up and shutdown of audit
functions is synonymous with the start-up and shutdown of the TOE. Start-upand
shut-down of the TOE must be recorded in the audit trail.
2. It shall be possible to generate an accounting record of the following events:
• Every successful inbound and outbound connection;
• Every unsuccessful inbound and outbound connection;
• Everysuccessful and unsuccessful administrator authentication attempt.
Page 32 of 32 Version 2.4
Ref.: ST 23 February 2000
3. The following data is to be recorded for each event:
• Date and Time of the event;
• type of event;
• subject identity (source address);
• outcome of the event;
• required destination address;
• TCP/UDP port for network connections.
4. Modifications to the content of the audit trail are not permitted. Read access only is
permitted to the administrator of the BFS through a controlled interface.
5. An FTP admin user is permitted read, copy or delete access only to an archived audit
log. An FTP admin user is not permitted modify access to an audit trail while it is
stored in the admin area of the FTP server. Deletion of the audit trail from the FTP
server can only be performed by an FTP admin user.
6. A record will be generated in the security trail and an e-mail sent to the administrator
in the event of an attempt to make a connection to a service that does not have a
server or proxy enabled.
6.1.4 Protection of TOE Security Functions
1. The TOE will provide self-protection from external modification or interference of
the TSF code or data structures by untrusted subjects. Untrusted subjects cannot
bypass checks, they will always be invoked.
The functions that enforce the TOE Security Policy (TSP) will always be invoked and
completed, before any function within the TSF Scope of Control (those interactions
within the TOE that are subject to the rules of the TSP) is allowed to proceed.
The TSF will protect itself, ensuring that all other processes are executed within other
domains to those of the TSF processes and thereby are unable to modify or damage
the TSF.
2. The TOE shall provide reliable time stamps for use in determining whether an
information flow is permissible and for stamping entries in the audit trail.
6.1.5 User Data Protection
1. There are three main types of information flow that the TOE enforces:
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 33 of 33
23 February 2000 Ref.: ST
a) AUTHENTICATED – traffic from the internal network to the BFS, providing
access to the BFS for a remote Administrator on the internal network, which
requires the source subject to be identified and authenticated as an administrator of
the BFS;;
b) UNAUTHENTICATED – outbound traffic, of which the source subject is
identified, but not authenticated. Also, inbound traffic from the external network
to the SSN, and inbound traffic from the SSN to the internal network as this is a
controlled flow from a known source;
c) UNIDENTIFIED – outbound traffic, of which the source subject is not identified
or inbound traffic from the external network to the SSN.
2. When a request for a connection arrives, the BFS takes the following action:
a) Checks the port and destination address to see if they are consistent with an
enabled server or proxy;
b) If they are, then the number of current sessions are checked against the maximum
set for that service. If a number of sessions is at the maximum, then the
connection is denied. Otherwise, access rules are checked (as in ‘c.)’ below);
c) For each access rule assigned to the service, the following conditions must be met
for the particular connection request:
• The access rule session limit has not been reached;
• The current time is within any configured time slot;
• The source or destination address is allowed.
d) The firewall decides the following:
• If any rule is applicable that denies the connection, then the connection is
denied;
• If no access rules are applicable or assigned to the service, then the
connection is denied;
• Otherwise, the connection is allowed.
e) If identification and/or authentication are required for the service, the firewall
checks that the information provided matches that of the permitted sources
and/or service accounts (e.g. admin user for FTP service request).
Note 1: If no access rules are assigned to a service, then no access rules will ever be
Page 34 of 34 Version 2.4
Ref.: ST 23 February 2000
applicable, and so access will always be denied.
Note 2: Response packets will be checked against the packet filter rules but not the
access rules, which are used only to establish a connection.
3. The requested services permitted are subject to one of the three information flow
policies according to the direction (source and destination) of the request, as indicated
in the following:
1. Internal to External – UNAUTHENTICATED or UNIDENTIFIED;
• America On-Line;
• Finger;
• FTP;
• Gopher;
• Ident;
• NetShow;
• NNTP;
• Ping;
• POP Mail;
• RealAudio;
• Telnet;
• Whois
• WWW.
2. Internal to SSN – UNAUTHENTICATED or UNIDENTIFIED;
• Finger;
• FTP;
• Gopher;
• Ident;
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 35 of 35
23 February 2000 Ref.: ST
• NetShow;
• NNTP;
• Ping;
• POP Mail;
• RealAudio;
• SMTP Mail;
• Telnet;
• WWW.
3. External to SSN –UNAUTHENTICATED or UNIDENTIFIED;
• Anonymous FTP;
• Finger;
• Ident;
• NNTP;
• SMTP Mail;
• WWW.
4. SSN to External – UNAUTHENTICATED or UNIDENTIFIED.
• FTP;
• Finger;
• Ident;
• Ping;
• POP Mail;
• SMTP Mail;
• WWW.
Services provided by proxies that can be configured on the BFS server within the scope
Page 36 of 36 Version 2.4
Ref.: ST 23 February 2000
of this Security Target are specified in the table below, Table 6-1 - Information flows
provided by proxies
I-E I-SSN E-SSN SSN-E
America On-
Line
Finger Anonymous
FTP
FTP
Finger FTP Finger Finger
FTP Gopher Ident Ident
Gopher Ident NNTP Ping
Ident NetShow SMTP Mail POP Mail
NetShow NNTP WWW SMTP Mail
NNTP Ping WWW
Ping POP Mail
POP mail RealAudio
Real Audio SMTP Mail
Telnet Telnet
Whois WWW
WWW
Table 6-1 - Information flows provided by proxies
Services provided by servers that can be configured on the BFS server within the scope
of this Security Target are specified in the table below, Table 6-2 - Information flows
provided by servers
Internal External SSN
Finger Anonymous FTP Anonymous FTP
FTP Finger Finger
Ident Ident Ident
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 37 of 37
23 February 2000 Ref.: ST
Internal External SSN
Ping Ping Ping
POP Mail SMTP Mail POP Mail
SMTPMail Traceroute Response SMTP Mail
Traceroute Response WWW Traceroute Response
WWW WWW
Table 6-2 - Information flows provided by servers
6.2 Assurance Measures
Deliverables will be produced to comply with the Common Criteria Assurance
Requirements for EAL4, augmented with ALC_FLR.1.
6.3 Permutational IT Security Functions
The only permutational IT security functions that are realised in the TOE are the
administrator passwords at the system console and the administration GUI, and the ftp-
user passwords. The Strength of function claim for these mechanisms is
SOF-MEDIUM.
Page 38 of 38 Version 2.4
Ref.: ST 23 February 2000
7 Protection Profiles Claims
There are no Protection Profile Claims.
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 39 of 39
23 February 2000 Ref.: ST
8 Rationale
8.1 Introduction
This section identifies the rationale for the adequacy of the security functional
requirements and the security assurance requirements in addressing the threats and
meeting the objectives of the TOE.
8.2 Security Objectives for the TOE and Environment Rationale
The following table demonstrates how the objectives of the TOE and the TOE
environment counter the threats, policies and assumptions identified in Section 3.2.1.
Threats
Objectives/
Assumptions
T.EXT_CONN
T.INT_CONN
T.SOURCE
T.CONFIG
T.UNAUTH
T.OS_FAC
TE.VIOLATE
A.PHYSICAL
A.LIMIT
O.VALID ü ü ü ü
O.HOSTILE ü ü ü ü
O.PRIVATE ü ü ü ü
O.AUTH ü ü
O.ATTEMPT ü ü ü
O.ADMIN ü
O.SECPROC ü ü
O.CONFIG ü
NOE.DELIV ü
NOE.TRAIN ü
NOE.AUDIT ü
NOE.NETWORK ü ü
NOE.MANAGE ü
Page 40 of 40 Version 2.4
Ref.: ST 23 February 2000
Threats
Objectives/
Assumptions
T.EXT_CONN
T.INT_CONN
T.SOURCE
T.CONFIG
T.UNAUTH
T.OS_FAC
TE.VIOLATE
A.PHYSICAL
A.LIMIT
NOE.PHYSICAL ü
NOE.REVIEW ü ü
Table 8-1 Objectives Rationale
As can be seen from the table above, all threats and assumptions met by at least one
objective, either TOE or environment, as applicable. The coverage of the threats and
assumptions countered by the TOE is discussed in the subsections below.
8.2.1 T.EXT_CONN
BFS limits the hosts, address ranges (i.e., it will reject a packet received at the external
network interface with an address within the internal network address range) and service
ports available from the external network. No inbound services are permitted
connection.
8.2.2 T.INT_CONN
BFS limits the hosts, address ranges (i.e., it will reject a packet received at the internal
network interface with an address within the external network address range) and service
ports available from the internal network.
8.2.3 T.SOURCE
BFS limits the hosts and service ports available from the internal and external network,
in order to prevent exploitation of vulnerabilities in Internet services. BFS will monitor
attempts to initiate connections between the networks (internal, external and SSN).
8.2.4 T.CONFIG
BFS limits the range of addresses expected on the internal and external networks. BFS
will process security functions and service requests in separate domains to ensure the
security functions are not affected by indirect user traffic. Each process will complete
before another process requiring the same data structures/processes is invoked.
8.2.5 T.UNAUTH
BFS ensures only the administrator can amend the configuration. BFS will monitor
attempts to initiate connections between the networks (internal, external and SSN),
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 41 of 41
23 February 2000 Ref.: ST
including attempts to initiate a remote administration session.
8.2.6 T.OS_FAC
BFS does not provide any operating system services to any user of the BFS. (There is
no command line access provided). BFS will process security functions and service
requests in separate domains to ensure the security functions are not affected by indirect
user traffic.
8.2.7 TE.VIOLATE
The administrators of the BFS are trusted to install, manage and operate (including using
and managing the audit facilities) the BFS in a manner consistent with the security
policy. The administrators should be provided with the appropriate training in order to
complete this.
8.2.8 A.PHYSICAL
The BFS must be the only (physical and logical) connection between the internal,
external and SSN networks. Access to the system console must be controlled.
8.2.9 A.LIMIT
BFS limits the hosts and service ports available from the internal and external network,
to prevent exploitation of vulnerabilities in Internet services . BFS will monitor attempts
to initiate connections between the networks (internal, external and SSN). BFS limits
the address ranges (i.e., it will reject a packet received at the internal network interface
with an address within the external network address range, and vice versa) available
from the internal and external network. Service requests will be subject to
authentication checks, in accordance with the security policy enforced on the BFS.
8.3 Security Requirements Rationale
8.3.1 Requirements are appropriate
The following table identifies which SFRs satisfy the Objectives defined in Section 4.1.1
Objective Security Functional Requirement(s)
O.VALID FIA_UID.1, FDP_IFC.1, FDP_IFF.1,
FMT_MSA.3
O.HOSTILE FDP_IFC.1, FDP_IFF.1, FMT_MSA.3,
FIA_UID.1, FIA_UAU.1, FPT_STM.1
O.PRIVATE FDP_IFC.1, FDP_IFF.1, FMT_MSA.3,
FIA_UID.1, FIA_UAU.1, FPT_STM.1
Page 42 of 42 Version 2.4
Ref.: ST 23 February 2000
Objective Security Functional Requirement(s)
FIA_UID.1, FIA_UAU.1, FPT_STM.1
O.AUTH FIA_UID.1, FIA_UAU.1, FMT_MSA.3,
FDP_IFC.1, FDP_IFF.1
O.ATTEMPT FAU_GEN.1, FAU_ARP.1, FAU_SAA.1,
FAU_SAR.1, FAU_STG.1, FIA_AFL.1,
FIA_UID.1, FIA_UAU.1, FPT_STM.1
O.ADMIN FMT_SMR.1, FMT_MSA.1, FMT_MSA.3,
FMT_MTD.1, FIA_UID.1, FIA_UAU.1,
FDP_ACC.1, FDP_ACF.1
O.SECPROC FPT_RVM.1, FPT_SEP.1
O.CONFIG FDP_IFF.1, FPT_RVM.1, FPT_SEP.1
Table 8-2 Mapping of Objectives to SFRs
As it can be seen in the table above, all objectives are satisfied by at least one SFR and
all SFRs are required to meet at least one objective. Therefore, as demonstrated in Table
8-1and Table 8-2, all SFRs specified for the TOE are appropriate to counter the threats
and meet the objectives of the TOE.
8.3.2 Security Requirement dependencies are satisfied
( ) indicates an indirect dependency
[ ] indicates an optional dependency
Functional
Component
Dependencies
FIA_AFL.1 FIA_UAU.1 (FIA_UID.1)
FIA_UAU.1 FIA_UID.1
FIA_UAU.4 none
FIA_UID.1 none
FMT_MSA.1 FMT_SMR.1 [FDP_IFC.1, (FDP_IFF.1)] (FIA_UID.1,
FMT_MSA.1, FMT_MSA.3)
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 43 of 43
23 February 2000 Ref.: ST
Functional
Component
Dependencies
FMT_MSA.3 FMT_MSA.1, FMT_SMR.1 ([FDP_IFC.1,
(FDP_IFF.1)] FIA_UID.1, FMT_MSA.3)
FMT_MTD.1 FMT_SMR.1 (FIA_UID.1)
FMT_SMR.1 FIA_UID.1
FAU_GEN.1 FPT_STM.1
FAU_ARP.1 FAU_SAA.1 (FAU_GEN.1, FPT_STM.1)
FAU_SAA.1 FAU_GEN.1 (FPT_STM.1)
FAU_SAR.1 FAU_GEN.1, (FPT_STM.1)
FAU_STG.1 FAU_GEN.1 (FPT_STM.1)
FPT_RVM.1 none
FPT_SEP.1 none
FPT_STM.1 none
FDP_ACC.1 FDP_ACF.1 ([FDP_ACC.1], FIA_UID.1, FMT_MSA.1,
FMT_MSA.3, FMT_SMR.1)
FDP_ACF.1 FDP_ACC.1, FMT_MSA.3 ([FDP_ACF.1], FIA_UID.1,
FMT_MSA.1, FMT_SMR.1)
FDP_IFC.1 FDP_IFF.1 (FMT_SMR.1 [FDP_IFC.1, (FDP_IFF.1)]
FIA_UID.1, FMT_MSA.1, FMT_MSA.3)
FDP_IFF.1 FDP_IFC.1, FMT_MSA.3(FMT_SMR.1 [FDP_IFC.1,
(FDP_IFF.1)] FIA_UID.1, FMT_MSA.1)
Table 8-3 Mapping of SFR Dependencies
As demonstrated in the table above, each of the SFRs identified as dependencies have
been stated as Functional Components of the TOE. Therefore, all dependencies have
been satisfied.
Page 44 of 44 Version 2.4
Ref.: ST 23 February 2000
8.3.3 Security Requirements are mutually supportive
The only interactions between the security requirements specified for the BFS are those
which are identified in the CC Part 2 as dependencies between the SFRs. These
dependencies are documented and demonstrated to be satisfied in Section 8.3.2. These
interactions are specified in the CC Part 2, and are therefore mutually supportive
8.3.4 ST complies with the referenced PPs
This Security Target does not claim compliance with a Protection Profile.
8.3.5 IT security functions satisfy SFRs
Mapping of Section 6 IT functions to SFRs (Section 5.1).
IT Function SecurityFunctional
Requirement(s)
Coverage of SFR(s) by IT
Function
6.1.1/1 FIA_UAU.1.2 Complete
6.1.1/2 FIA_UID.1.1 Complete
6.1.1/3 FIA_UID.1.2
FIA_UAU.1.1
Complete
Parts a and b
6.1.1/4 FIA_AFL.1.1
FIA_AFL.1.2
FIA_UAU.1.1
Complete
Complete
Part c
6.1.2/1 FMT_MSA.1.1
FMT_MSA.3.2
Point 1
Complete
6.1.2/2 FMT_MSA.3.1
FDP_ACF.1.4
Complete
Partial – administrator
6.1.2/3 FMT_MSA.1.1
FDP_ACC.1.1a
FDP_ACF.1.1a
FDP_ACF.1.2a
Complete
Complete
Complete
Complete
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 45 of 45
23 February 2000 Ref.: ST
FDP_ACF.1.4 Partial – administrator
6.1.2/4 FDP_ACC.1.1b
FDP_ACF.1.1b
FDP_ACF.1.2b
FDP_ACF.1.4
Complete
Complete
Complete
Partial – FTP
6.1.2/5 FMT_SMR.1.1
FMT_SMR.1.2
Complete
Complete
6.1.2/6 FDP_IFF.1.4 Complete
6.1.2/7 FMT_MSA.1.1 Points 2, 3, 4 and 5
6.1.2/8 FMT_MSA.1.1 Point 6
6.1.3/1 FAU_GEN.1.1 Part a
6.1.3/2 FAU_GEN.1.1 Part c
6.1.3/3 FAU_GEN.1.2 Complete
6.1.3/4 FAU_STG.1.1
FAU_STG.1.2
FAU_SAR.1.1
FAU_SAR.1.2
Complete
Complete
Complete
Complete
6.1.3/5 FAU_STG.1.1
FAU_STG.1.2
FMT_MTD.1.1a
FMT_MTD.1.1b
Complete
Complete
Complete
Complete
6.1.3/6 FAU_ARP.1.1
FAU_SAA.1.1
Complete
Complete
Page 46 of 46 Version 2.4
Ref.: ST 23 February 2000
FAU_SAA.1.2 Complete
6.1.4/1 FPT_RVM.1.1
FPT_SEP.1.1
FPT_SEP.1.2
Complete
Complete
Complete
6.1.4/2 FPT_STM.1.1 Complete
6.1.5/1 FDP_IFC.1.1
FDP_IFF.1.2
Partial
Partial
6.1.5/2 FDP_IFC.1.1
FDP_IFF.1.1
FDP_IFF.1.2
FDP_IFF.1.3
FDP_IFF.1.6
Complete
Complete
Partial
Complete
Complete
6.1.5/3 FDP_IFF.1.1
FDP_IFF.1.2
Complete
Complete
Table 8-4 Mapping of IT Functions to SFRs
SFR FAU_GEN1.1 part b requires no IT Functions.
SFRs FDP_ACF.1.3 and FDP_IFF.1.5 have not been translated into IT security
functions, as they specify that no rules are required in addition to those specified in other
elements of the respective components.
The combination of the IT Functions specified in 6.1.5/1 and 6.1.5/2 fully provide the
requirements of SFRs FDP_IFC.1.1 and FDP_IFF.1.2.
Therefore, as demonstrated all Security Functional Requirements of the TOE are fully
provided by the IT security functions specified in the TOE Summary Specification.
Also demonstrated in Table 8-4, all IT Security Functions identified for the TOE in the
TOE Summary Specification are required to meet the TOE Security Functional
Requirements.
BORDERWARE TECHNOLOGIES INC
Version 2.4 Page 47 of 47
23 February 2000 Ref.: ST
8.3.6 IT security functions mutually supportive
The mutually supportive nature of the IT security functions can be derived from the
mutual support of the SFRs (demonstrated in Section 8.3.3), as each of the IT functions
can be mapped to one or more SFRs, as demonstrated on Table 8-4.
8.3.7 Strength of Function claims are appropriate
The SoF claim made by the TOE is SOF-MEDIUM, which is defined in the CC Part 1 as
“resistance to attackers possessing a moderate attack potential”.
AVA_VLA.2, one of the assurance components from which the EAL4 assurance level is
comprised, which determines that “the TOE is resistant to penetration attacks performed
by attackers possessing a low attack potential” (CC Part 3). Therefore, a SoF claim of
SOF-MEDIUM demonstrates that the functions with an associated SoF would be
suitable to resist such attackers.
This product is to be used in environments such as government departments to protect
internal networks when connecting them to external networks. The guidance for such
interconnections is to use Firewall products with ITSEC E3 or equivalent (CC EAL4)
assurance, for which a strength of SOF-MEDIUM is generally felt to be acceptable.
Therefore, the claim of SOF-MEDIUM made by BFS is viewed to be appropriate for this
use.
8.3.8 Assurance measures satisfy assurance requirements
EAL4 is defined in the CC as “methodically designed, tested and reviewed”.
Products such as BFS are intended to be used in a variety of environments, and used to
connect networks with different levels of trust in the users. The BFS is intended to be
suitable for use in UK HMG, which requires an ITSEC E3 equivalent level of assurance,
for which EAL4 assurance is suitable.
In the Internet area of IT new exploits are continually being discovered and published,
which the BFS will be expected to protect the internal network against. It is therefore
considered to be appropriate to augment the EAL4 assurance requirements for the BFS
with the ALC_FLR.1 assurance component. This will provide additional assurance that
new vulnerabilities identified and reported in the services the product supports, or in the
product itself, are addressed in a controlled and suitable manner.