McAfee Firewall Enterprise v8.2.0 and
McAfee Firewall Enterprise Control Center v5.2.0
Security Target
10 January 2012 Version 1.1 Prepared By: Primasec Ltd For McAfee Inc2340 Energy Park Drive St. Paul, MN 55108 USA
Page 2 of 65
Contents
1 Introduction ... 5
1.1 ST Introduction ... 5
1.2 Security Target, TOE and CC Identification ... 6
1.3 Conformance Claims ... 6
1.3.1 Common Criteria ... 6
1.3.2 Protection Profile ... 6
1.4 Conventions ... 7
1.5 Terminology & Acronyms ... 8
1.6 References ... 11
2 TOE Description ... 12
2.1 Product Type ... 12
2.2 Application Context ... 12
2.3 Physical and Logical Boundaries ... 12
2.3.1 Evaluation Application Context ... 12
2.3.2 Proxy agents to be Evaluated ... 13
2.3.3 Features not to be Evaluated ... 13
2.3.4 Physical Scope and Boundary ... 13
2.3.5 Logical Scope and Boundary ... 15
2.4 TOE Documentation ... 18
3 Security problem definition ... 19
3.1 Assumptions ... 19
3.2 Threats ... 19
3.2.1 Threats Addressed by the TOE ... 19
3.2.2 Threat to be Addressed by Operating Environment ... 20
3.3 Organisational security policies... 20
4 Security objectives ... 21
4.1 Security objectives for the TOE ... 21
4.2 Security objectives for the environment ... 22
5 Security requirements ... 23
5.1 Security functional requirements ... 23
5.1.1 FMT_SMR.1 Security roles ... 24
5.1.2 FIA_ATD.1 User attribute definition ... 24
Page 3 of 65
5.1.4 FIA_AFL.1 Authentication failure handling ... 24
5.1.5 FIA_UAU.5 Multiple authentication mechanisms ... 25
5.1.6 FIA_UAU.8 (X) Invocation of authentication mechanism ... 25
5.1.7 FIA_SOS.2 TSF Generation of secrets ... 26
5.1.8 FDP_IFC.1 Subset information flow control (1) ... 26
5.1.9 FDP_IFC.1 Subset information flow control (2) ... 27
5.1.10 FDP_IFC.1 Subset information flow control (3) ... 27
5.1.11 FDP_IFF.1 Simple security attributes (1) ... 27
5.1.12 FDP_IFF.1 Simple security attributes (2) ... 29
5.1.13 FDP_IFF.1 Simple security attributes (3) ... 31
5.1.14 FDP_UCT.1 Basic data exchange confidentiality ... 32
5.1.15 FTP_ITC.1 Inter-TSF trusted channel ... 32
5.1.16 FMT_MSA.1 Management of security attributes (1) ... 32
5.1.17 FMT_MSA.1 Management of security attributes (2) ... 33
5.1.18 FMT_MSA.1 Management of security attributes (3) ... 33
5.1.19 FMT_MSA.1 Management of security attributes (4) ... 33
5.1.20 FMT_MSA.1 Management of security attributes (5) ... 33
5.1.21 FMT_MSA.1 Management of security attributes (6) ... 33
5.1.22 FMT_MSA.3 Static attribute initialization ... 33
5.1.23 FMT_MTD.1 Management of TSF data (1) ... 33
5.1.24 FMT_MTD.1 Management of TSF data (2) ... 34
5.1.25 FMT_MTD.2 Management of limits on TSF data ... 34
5.1.26 FDP_RIP.1 Subset residual information protection ... 34
5.1.27 FCS_COP.1 Cryptographic operation (1 data encryption) ... 34
5.1.28 FCS_COP.1 Cryptographic operation (2 cryptographic signature services) ... 34
5.1.29 FCS_COP.1 Cryptographic operation (3 cryptographic hashing) ... 34
5.1.30 FCS_COP.1 Cryptographic operation (4 cryptographic key agreement)... 34
5.1.31 FCS_CKM.1 Cryptographic key generation (1) ... 35
5.1.32 FCS_CKM.1 Cryptographic key generation (2) ... 35
5.1.33 FCS_CKM.4 Cryptographic key destruction ... 35
5.1.34 FPT_STM.1 Reliable time stamps ... 35
5.1.35 FAU_GEN.1 Audit data generation ... 35
5.1.36 FAU_SAR.1 Audit review ... 36
Page 4 of 65
5.1.38 FAU_STG.1 Protected audit trail storage ... 36
5.1.39 FAU_STG.4 Prevention of audit data loss ... 37
5.1.40 FMT_MOF.1 Management of security functions behaviour (1) ... 37
5.1.41 FMT_MOF.1 Management of security functions behaviour (2) ... 37
5.2 Security assurance requirements... 37
5.3 Definition of Extended Components ... 39
6 TOE Summary Specification ... 40
6.1 Security audit (SF-FAU) ... 40
6.2 Cryptographic support (SF-FCS) ... 41
6.3 User data protection (SF-FDP) ... 43
6.4 Identification and authentication (SF-FIA) ... 47
6.5 Security management (SF-FMT)... 49
6.6 Protection of the TSF (SF-FPT) ... 50
7 Rationale ... 51
7.1 Rationale for TOE security objectives ... 51
7.2 Rationale for security objectives for the environment ... 52
7.3 Rationale for security requirements ... 53
7.4 Dependency rationale ... 59
7.5 Rationale for TOE summary specification ... 61
7.6 Rationale for security assurance requirements ... 64
Page 5 of 65
1
Introduction
1.1
ST Introduction
This section presents the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST conformance claims, and the ST organization. The TOE is McAfee Firewall Enterprise 8.2.0 and McAfee Firewall Enterprise Control Center 5.2.0.
Within this ST, “McAfee Firewall” is used to identify the combination hardware and software required to manage and operate the TOE. There are two possible configurations, reflecting two separate management options.
Configuration A comprises:
• the McAfee Firewall Enterprise software, including its SecureOS operating system, • the McAfee Firewall Admin Console client software,
• the hardware or virtual platform for running the firewall software. Configuration B comprises:
• the McAfee Firewall Enterprise software, including its SecureOS operating system, • the McAfee Firewall Enterprise Control Center (“Control Center”) Management
server software,
• the hardware or virtual platform for running the Control Center Management server software,
• the Control Center client software.
The specific firewall software version and management tool versions to be evaluated are all specified in Section 1.2.
McAfee Firewall is a firewall and access control security platform for the enterprise; McAfee Firewall configured in its operational environment delivers strong security while maintaining performance and scalability. It provides access control of communication and information flow between two or more networks, usually the Internet and internal networks, using application-level proxy and packet filtering technology. The operational environment for the McAfee Firewall software is a dedicated McAfee appliance platform or virtual appliance, supporting a typical Intel-based instruction architecture. The configured McAfee Firewall provides the highest levels of security by using SecureOS ™, an enhanced UNIX operating system that employs McAfee's patented Type Enforcement™ security technology. Type Enforcement technology protects McAfee Firewall by separating all processes and services on the firewall.
McAfee Firewall supports user identification and authentication (I&A) where "user" is defined to be a human user acting in an Administrative role, an authenticated proxy user, or an authorized IT entity. It provides the capability to pass and block information flows based on a set of rules defined by the Administrator. Additionally, it enforces security policies which restrict host-to-host connections to common Internet services such as: Telnet, File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP and HTTPS), and Simple Mail Transfer Protocol (SMTP). McAfee Firewall supports encryption for remote administration, remote proxy users and authorized IT entities (e.g. certificate server, NTP server), and generates audit data of security relevant events. McAfee Firewall also provides VPN capability to encrypt out-going traffic flowing to a geographically separated enclave and decrypt in-coming traffic from such an enclave.
Page 6 of 65 This ST contains the following additional sections:
• TOE Description (Section 2)
• Security Problem Definition (Section 3) • Security Objectives (Section 4)
• Security Requirements (Section 5) • TOE Summary Specification (Section 6) • Rationale (Section 8).
1.2
Security Target, TOE and CC Identification
ST Title –McAfee Firewall Enterprise v8.2.0 and McAfee Firewall Enterprise Control Center 5.2.0 Security Target
ST Version – 1.1
ST Date – 10 January 2012
TOE Identification – McAfee Firewall Enterprise 8.2.0 and McAfee Firewall Enterprise Control Center 5.2.0 with patch 520P01
Software: McAfee Firewall 8.2.0, together with either McAfee Firewall Enterprise
(Sidewinder) Admin Console 5.05 (Configuration A) or McAfee Firewall Enterprise Control Center 5.2.0 (Configuration B)
The TOE runs on any 64 bit hardware or virtual platform for which a license can be purchased from McAfee (see list of platforms in section 2.3.4.1).
TOE Developer – McAfee Evaluation Sponsor – McAfee
CC Identification – Common Criteria for Information Technology Security Evaluation, Version 3.1r3
1.3
Conformance Claims
1.3.1
Common Criteria
This TOE and ST are conformant to the following CC specifications: [CC_PART2] Extended
[CC_PART3] Conformant
Assurance Level: EAL 4 augmented with ALC_FLR.3
1.3.2
Protection Profile
This TOE and ST are conformant to [FWPP] (Augmented).
The TOE type is a firewall, and the TOE type in the PP is stated to be a firewall. The TOE type is therefore consistent with the PP.
The statement of security problem definition in the ST is consistent with that in the PP. All threats, assumptions and organizational security policies in the PP are included in the ST. One threat has been added to address confidentiality and integrity of network traffic in support of claims made in relation to VPNs.
Page 7 of 65 The statement of security objectives in the ST is consistent with that in the PP. The security objectives for the TOE in the ST include all those in the PP. One security objective for the TOE has been added, covering use of VPN. This does not conflict with the other objectives. One of the security objectives for the TOE has been repeated in the statement of security objectives for the environment, to reflect use of an external single-use authentication server. Some of the security objectives for the environment have been reworded for clarity, but in each case the objective is unaltered.
The statement of security requirements in the ST is consistent with that in the PP. Additional security functional requirements have been added to reflect use of VPN. These additional security functional requirements are consistent with those from the PP. An additional security functional requirement has been added to reflect use of an external authentication server. This approach was validated with the PP authors during evaluation of an earlier version of the TOE in 2007.
The security assurance requirements in the ST are hierarchical to those in the PP. The PP calls up EAL2 augmented with ALC_FLR.2, whereas the TOE uses EAL4 augmented with ALC_FLR.3.
1.4
Conventions
Since this security target is claiming compliance with a protection profile, the conventions used are intended to highlight the completion of operations made within this security target. While this security target will include the operations made by the protection profile upon the CC requirements it is not the author’s intent to highlight those operations (i.e., use bold, italics or special fonts). Therefore, keywords (e.g. selection, assignment and refinement) and formatting (e.g., special fonts) used within the protection profile to designate operations are being removed by this ST. The brackets used by the protection profile to designate operations completed by the PP are left in the requirements.
The following conventions have been applied to indicate operations that this ST is making to the requirements in the protection profile:
Security Functional Requirements – Part 2 of the CC defines the approved set of operations that may be applied to functional requirements: iteration, assignment, selection, and refinement.
o Iteration: allows a component to be used more than once with varying operations. In the ST, iteration is indicated by a number in brackets placed at the end of the component. For example FDP_ACC.1 (1) and FDP_ACC.1 (2) indicate that the ST includes two iterations of the FDP_ACC.1 requirement, 1 and 2.
o Assignment: allows the specification of an identified parameter. Assignments are indicated using bold and are surrounded by brackets (e.g., [assignment]). Note that an assignment within a selection would be identified in italics and with embedded bold brackets (e.g. [[selected-assignment]]).
o Selection: allows the specification of one or more elements from a list. Selections are indicated using bold italics and are surrounded by brackets (e.g., [selection]).
o Refinement: allows the addition of details. Refinements are indicated using bold, for additions, and strike-through, for deletions (e.g., “… all objects …” or “… some big things …”).
Page 8 of 65 Other sections of the ST – Other sections of the ST use bolding to highlight text of special interest, such as captions.
1.5
Terminology & Acronyms
In the Common Criteria, many terms are defined in Section 4 of [CCPART1]. The following terms are a subset of those definitions. They are listed here to aid the user of the Security Target.
External Entity Any entity (human or IT) outside the TOE that interacts (or may interact) with the TOE.
User Same as External Entity
Authorized User A user who may, in accordance with the SFRs, perform an operation.
Role A predefined set of rules establishing the allowed interactions between a user and the TOE.
Identity A representation (e.g., a string) uniquely identifying an authorized user, which can either be the full or abbreviated name of that user or a pseudonym. Authentication data Information used to verify the claimed identity of a
user.
In addition to the above general definitions, this Security Target provides the following specialized definitions:
Administrator – Any human user who has been identified and authenticated to act in the administrative role defined in the ST. An “authorized administrator” is an administrator who may, in accordance with the SFRs, perform an operation. A “non-administrator” is,
obviously, someone who is not an administrator.
Application-Level Proxy – A proxy server acts on behalf of the user. All requests from clients to the Internet go to the proxy server first. The proxy evaluates the request, and if allowed, re-establishes it on the outbound side to the Internet. Likewise, responses from the Internet go to the proxy server to be evaluated. The proxy then relays the message to the client. Both client and server think they are communicating with one another, but, in fact, are dealing only with the proxy. Proxy servers are available for common Internet services; for example, an HTTP proxy is used for Web access, and an FTP proxy is used for file
transfers. Such proxies are called "application-level proxies” because they are dedicated to a particular application and protocol, and are aware of the content of the packets being sent. Authenticated Proxy User – A user who has been identified and authenticated to satisfy the requirements for using a proxy according to the authenticated policy enforced by the TOE. A “proxy user” is any user, either authenticated or not, who is sending traffic through a proxy according to any security policy enforced by the TOE. A “remote proxy user” is a proxy user who is also a remote user.
Authorized IT entity – Any IT entity outside the TOE that may, in accordance with the SFRs, perform an operation on the TOE.
Page 9 of 65 Local Administration Console – This is a physically connected, generic hardware platform (part of the IT environment) running the McAfee Firewall Administration Console client (part of the TOE). Both the local administration console hardware and its network connection to the McAfee Firewall are physically protected. McAfee Firewall must be configured to accept administrative commands from the local administration console.
Local Administrator – This is an administrator who uses a local administration console to manage McAfee Firewall.
Remote Administration Console – This is also a generic hardware platform running the McAfee Firewall Administration Console client; it has a network connection to McAfee Firewall, but it is not a local administration console. McAfee Firewall must be configured to accept administrative commands from such a remote administration console.
Remote User - A user that communicates with the TOE by means of a network connection. Since administrators are users, a “remote administrator” is an administrator who is also a remote user.
Remote Administrator – This is an administrator who uses a remote administration console or Control Center to manage the McAfee Firewall.
Single-Use Authentication –Data for single-use authentication can be something the user has or knows, but not something the user is. Examples of single-use authentication data include single-use passwords, encrypted time-stamps, and/or random numbers from a secret lookup table.
The following abbreviations are used in this Security Target: AES Advanced Encryption Standard
ANSI American National Standards Institute BSD Berkley Software Distribution
CC Common Criteria for Information Technology Security Evaluation
CD Compact Disk
CPU Central Processing Unit DSA Digital Signature Algorithm EAL Evaluation Assurance Level ECB Electronic Codebook
ESP Encapsulating Security Payload
FIPS Federal Information Processing Standard
FIPS PUB Federal Information Processing Standard Publication FLR Flaw Remediation
FTP File Transfer Protocol
GHz Gigahertz
GUI Graphical User Interface HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure
Page 10 of 65 I&A Identification and Authentication
ICMP Internet Control Message Protocol IKE Internet Key Exchange
IPSEC Internet Protocol Security IT Information Technology LAN Local Area Network
MB Megabyte
MMU Memory Management Unit NAT Network Address Translation NTP Network Time Protocol
OS Operating System
OSP Organizational Security Policy
PC Personal Computer
PP Protection Profile
PRNG Pseudo Random Number Generator PS/2 Personal System/2
RAM Random Access Memory
RDSA RSA Digital Signature Algorithm RFC Request For Comment
RNG Random Number Generator SA Security Association
SAR Security Assurance Requirement SFP Security Function Policy
SFR Security Functional Requirement SHA Secure Hash Algorithm
SMTP Simple Mail Transfer Protocol SSL Secure Sockets Layer
ST Security Target
SVGA Super Video Graphics Array
TCP/IP Transmission Control Protocol/Internet Protocol TLS Transport Layer Security
TOE Target of Evaluation TSC TSF Scope of Control TSF TOE Security Functions
Page 11 of 65 TSP TOE Security Policy
URL Uniform Resource Locator
US United States
VPN Virtual Private Network
1.6
References
The following documentation was used to prepare this ST:
[CC_PART1] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction and general model, dated July 2009, version 3.1 revision 3, CCMB-2009-07-001.
[CC_PART2] Common Criteria for Information Technology Security Evaluation – Part 2: Security functional components, dated July 2009, version 3.1 revision 3, CCMB-2009-07-002.
[CC_PART3] Common Criteria for Information Technology Security Evaluation – Part 3: Security assurance components, dated July 2009, version 3.1 revision 3, CCMB-2009-07-003.
[CEM] Common Methodology for Information Technology Security Evaluation – July 2009, version 3.1 revision 3, CCMB-2009-07-004.
[FWPP] U.S. Government Protection Profile for Application-level Firewall in Basic Robustness Environments Version 1.1, July 25, 2007.
[FIPS 140-2] Security Requirements for Cryptographic Modules, Federal Information Processing Standard , May 2001 [FIPS 180-3] Secure Hash Standard (SHS), Federal Information
Processing Standard, Oct 2008
[FIPS 197] Advanced Encryption Standard, Federal Information Processing Standard, Nov 2001
[SP 800-57] Recommendation for Key Management, NIST Special Publication, March 2007
Page 12 of 65
2
TOE Description
This section provides context for the TOE evaluation by identifying the product type and describing the evaluated configuration.
2.1
Product Type
The McAfee Firewall, operating with two or more network interfaces, provides a hybrid firewall solution that supports both application-level proxy and packet filtering. The McAfee Firewall software version consists of a collection of integrated firewall applications and SecureOS, a secure operating system. This OS is an extended version of the FreeBSD UNIX operating system. It includes McAfee's patented Type Enforcement security
technology, additional network separation control, network-level packet filtering support and improved auditing facilities. SecureOS also provides the secured computing environment in which all McAfee Firewall application layer processing is done. McAfee Firewall also provides VPN capability between separated network enclaves.
In addition to the McAfee Firewall hardware or virtual platform running the firewall
application with SecureOS, the TOE also includes one of the following two configurations: Configuration A
The Admin Console client software (McAfee Firewall Enterprise (Sidewinder) Admin Console). The Admin Console is separately installed on a generic Windows platform that is part of the IT environment: it is used to manage McAfee Firewall.
Configuration B
The McAfee Firewall Enterprise Control Center (“Control Center”) Management server software, the hardware or virtual platform for running the Control Center Management server software, and the Control Center client software.
2.2
Application Context
McAfee Firewall operates in an environment where it provides a single point of connectivity between at least two networks. Typically one network is viewed as the inside of an
organization, where there is some assumption of control over access to the computing network. The other network is typically viewed as an external network, similar to the Internet, where there is no practical control over the actions of its processing entities. McAfee
Firewall's role is to limit and control all information flow between the networks.
2.3
Physical and Logical Boundaries
2.3.1
Evaluation Application Context
The following contextual assumptions apply to the TOE:
a) It shall be newly installed and configured in accordance with the directives contained in the supplied guidance documentation;
b) Physical access to the configured McAfee Firewall shall be controlled;
c) The configured McAfee Firewall shall be connected only to networks between which it controls information flow;
d) The configured McAfee Firewall shall manage traffic for at least two (2) networks, at least one of which is designated as internal and one is designated as external;
Page 13 of 65 e) The configured McAfee Firewall shall support administrative operations via a GUI
application, known as Admin Console, running on a Windows system, or via Control Center;
f) If the configured McAfee Firewall is connected to an administrative workstation either directly or remotely, the communications are encrypted using TLS and the workstation is physically protected;
g) If the configured McAfee Firewall is connected to Control Center, the
communications between the McAfee Firewall and the Control Center Management server, and between the Control Center Management server and the Control Center client are encrypted using TLS, and Control Center client and server are physically protected;
h) Only authorized administrators shall be allowed physical access to the McAfee Firewall hardware computing platform, or to the administrative workstation, or to Control Center Management Server and Client, for such purposes as starting the system.
2.3.2
Proxy agents to be Evaluated
The FTP, HTTP, HTTPS, SMTP, Telnet, and Generic proxy agents are all included within the scope of the evaluation. Other protocol-aware proxy agents and services provided by McAfee Firewall are excluded from the scope of the evaluation.
2.3.3
Features not to be Evaluated
McAfee Firewall provides additional capabilities by means of optional “add-on” features that require additional equipment and/or licensing. The following extra functionality of this type is specifically excluded from the scope of this evaluation:
a) Anti-Virus;
b) SmartFilter (URL Filtering); c) Signature based IPS;
d) Policy Acceleration Network Cards; e) SSL Termination;
f) Network analysis capability;
g) Security Reporter (optional tool to view audit).
McAfee Firewall includes functions that are explicitly excluded from the scope of the evaluation:
a) Built-in servers other than ICMP;
b) Trusted Source (reputation service for email senders);
c) Use of the command line to manage the TOE (disabled in the evaluated configuration).
2.3.4
Physical Scope and Boundary
The TOE consists of McAfee Firewall software version 8.2.0, which includes the firewall application and the SecureOS operating system, running on a dedicated McAfee appliance platform or virtual appliance.
The TOE includes the Admin Console client software (the McAfee Firewall Enterprise (Sidewinder) Admin Console version 5.05). This software is provided with every McAfee Firewall appliance, and it is also provided as a separate part of every McAfee Firewall software product distribution. The administration client software runs on a generic
Page 14 of 65 computing platform with a Windows operating system. However, the platform and Windows OS are not part of the TOE.
The TOE also includes the Control Center Management Server version 5.2.0, its dedicated McAfee hardware platform or virtual appliance, and the Control Center Client software version 5.2.0. The Control Center Client software runs on a generic computing platform with a Windows operating system. However, the client platform and Windows OS are not part of the TOE.
2.3.4.1 TOE Environment Requirements
The McAfee Firewall appliance is configured to control the flow of TCP/IP traffic between two network interfaces. McAfee offers a family of appliance models with various hardware combinations to address a wide range of customer performance needs.
In addition, a generic hardware platform is required in the IT environment to run the McAfee Firewall Admin Console software for remote or local administration, or the Control Center client software for remote administration. The evaluated configuration must include at least one administration console. The minimum configuration required for this platform is as follows:
• CPU: Intel, 3GHz • RAM: 1 GB
• OS: MS Windows 2008 Server, Windows XP Professional, Windows Vista or Windows 7
• Media:
o Minimum of 750 MB of available disk storage o CD drive
• Network: One network interface • USB port
• SVGA video and display • PS/2 or Serial Mouse • Keyboard
The McAfee Firewall is available in two virtual forms: the Multi-Firewall Edition, provided in partnership with VMware, and the Virtual Appliance. The Multi-Firewall Edition appliance models come preinstalled on the same Dell or Intel hardware used for non-virtual appliances, preloaded with either 4, 8, 16 or 32 virtual firewalls, VMware vSphere Hypervisor (ESXi) operating system, and a virtual instance of McAfee Firewall Enterprise Control Center. The Virtual Firewall is delivered as software only, and is intended to be installed on existing VMware infrastructure installed on ESXi Hypervisor.
The current McAfee Firewall Enterprise platforms are:
- McAfee appliances: S1104, S2008, S3008, S4016, S5032, S6032, 1100F, 2150F, 4150F - Virtual: VMware vSphere Hypervisor (ESXi) version 4.1
The current McAfee Firewall Enterprise Control Center platforms are: - McAfee appliances: C1015, C2050 and C3000
- Virtual: VMware vSphere Hypervisor (ESXi) version 4.1
All specific TOE or TOE Environment settings and requirements are documented in guidance supplied with the TOE.
Page 15 of 65 2.3.4.2 Hardware Security Considerations
No extraordinary security demands are placed upon the hardware platforms and peripheral equipment used by the McAfee Firewall software. This equipment is expected to meet the customary demands for reliable operation of typical Unix or Microsoft Servers as provided by standard Intel PC computing platforms. The security features assumed to be present and operational on the hardware platforms include:
• The CPU must provide a two-state processing model to support the separation of the kernel processing from the application processing.
• The CPU and /or the supporting motherboard must provide a Memory Management Unit (MMU) to support separate memory spaces for the kernel and each process.
• The system motherboard must provide a battery backup for the clock to maintain time information when the system is shut down. Also the CPU or ancillary hardware must provide a periodic timer to support the internal time management within the kernel. • If any of the network interface cards support features such as wake-on LAN, special
external command features, or special protocol processing, the hardware connections to support those features should not be connected. In the evaluated configuration, McAfee Firewall will not enable any such special features.
For those instances of the TOE that run on VMware, the virtual environment is assumed to emulate these hardware security features. Secure isolation of the virtual environments is the responsibility of the VMware environment, and is outside the scope of this ST.
2.3.5
Logical Scope and Boundary
The TOE with support from the IT environment provides the following security features: a) Security Management [SF_FMT]
b) Identification and Authentication [SF_FIA] c) User Data Protection [SF_FDP]
d) Protection of Security Functions [SF_FPT] e) Audit [SF_FAU]
f) Cryptographic support [SF_FCS] 2.3.5.1 Security Management
Management of the McAfee Firewall may be carried out using either the McAfee Firewall Admin Console or McAfee Firewall Enterprise Control Center.
An administrator can use the McAfee Firewall Admin Console client (part of the TOE) to communicate with the McAfee Firewall remotely or via a locally connected network. All administration consoles, whether they are local or remote, use the same management interface and encrypted communications.
Alternatively, an administrator can use the Control Center client, running on a Windows computer (part of the IT environment), to perform management functions on the McAfee Firewall. This interface modifies firewall configurations stored on the Control Center Management server, and these are then deployed to the specified firewalls. All communications are encrypted.
2.3.5.2 Identification and Authentication
The McAfee Firewall TOE, along with support from the IT environment, supports standard UNIX password authentication. Identification attributes are assigned to each administrative
Page 16 of 65 user and each authenticated proxy user. McAfee Firewall gathers data from the user and the associated service connection, and consults the rules to determine what form of
authentication is required for the service (including use of an external authentication server). McAfee Firewall consults its stored user information, determines the password’s validity, and enforces the result of the validity check.
McAfee Firewall provides a mechanism for managing user access following authentication failures. McAfee Firewall also strictly limits the actions it will perform on behalf of a user before the user is authenticated.
When establishing VPNs, McAfee Firewall will exchange identities and perform device-level authentication of the remote device (peer McAfee Firewall or remote VPN gateway). Device-level authentication is performed using authentication techniques specified in RFC 2409 and RFC 4306. Peers will mutually authenticate themselves to each other before establishing the secure channel.
2.3.5.3 User Data Protection
McAfee Firewall allows an administrator to define security attributes to permit or deny information flows to or through the TOE. The set of security attributes will include items such as source and destination identification, application signatures, application level commands and user authentication. The TOE Administrator uses the security attributes to construct one or more access control rules. Packets arriving at the TOE interface are compared to the security attributes in the rules. When the packet attributes “match” the rules security attributes, that packet or connection is explicity approved or disapproved; otherwise the packet is dropped and the connection disallowed. In addition to restricting access via the rules, the TOE must generate and maintain “state” information for all approved connections mediated by the TOE. The TOE utilizes the “state” information to monitor the status of an approved connection and validate incoming packets purporting to be part of an approved connection.
McAfee Firewall restricts information flows via application level commands by incorporating application proxies. Proxies understand the operation of a particular application protocol and can filter the application data portion of a packet according to Administrator defined security attributes (e.g. commands, data types, etc.). Proxies originate all proxy controlled
information flows through the TOE on behalf of the communicating end points, which are not allowed to establish a direct connection through the TOE. In the evaluated configuration, McAfee Firewall provides 4 application proxies that can be configured to require user authentication: FTP, Telnet, HTTP and HTTPS. McAfee Firewall also provides a proxy for SMTP and a generic proxy that don’t require user authentication. In the evaluated
configuration, the FTP, Telnet, HTTP and HTTPS proxies can also be configured without requiring user authentication.
McAfee Firewall uses the same security attributes discussed above to control access to its own services. McAfee Firewall supports Internet Control Message Protocol (ICMP) as an unauthenticated information flow, which can be enabled or disabled.
McAfee Firewall also allows an administrator to establish a VPN policy to control data flows with remote VPN devices. McAfee Firewall provides for authentication to and from the remote device, agreement on cryptographic keys and algorithms, secure generation and distribution of session keys, and encryption of network traffic in accordance with the policy. User data is protected by different facilities depending upon the protocol and stage of processing. While user data is within the network stack, it is part of the kernel memory
Page 17 of 65 space, and as such is protected from all user state processing elements on the system. While user data is in the control of a proxy process, it is protected by the SecureOS processing model and Type Enforcement facilities.
McAfee Firewall network stack processing ensures that there is no leakage of residual information from previous packets to new packets as they are transferred through the firewall. The memory system zeros storage blocks before they are reused to prevent residual information leakage.
2.3.5.4 Protection of Security Functions
McAfee Firewall, with its SecureOS operating system, has been designed to be highly resistant to both malicious and accidental attack. It includes system elements that provide several levels of protection for its security functions.
The lowest level of protection is provided by the computing platform Central Processing Unit (CPU). The CPU provides a two-state processing model that limits access to certain
privileged instructions to the SecureOS kernel. The SecureOS kernel provides a second layer of protection by limiting user mode access to kernel memory. SecureOS also extends the normal FreeBSD UNIX network stack processing with additional separation control to restrict inter-process communication to certain interfaces.
SecureOS includes McAfee's patented Type Enforcement facilities that enforce mandatory security policy control over all user state processing. The Type Enforcement policy data is loaded onto the system during installation and cannot be modified on an operational system. Type Enforcement ensures that critical data is accessible only via programs designed to use the data and that the impact of any failure will be confined in scope.
McAfee Firewall also provides a reliable time stamp that is used by its audit mechanism. 2.3.5.5 Audit
SecureOS supplements the normal UNIX Syslog Facilities by providing an audit device to which all processes and the kernel may write audit data. The SecureOS audit device adds security relevant information, such as the time and the identity of the generating process, to the audit data when it passes through the device within the kernel.
The Administrator can view the contents of the audit records, and delete the audit trail. McAfee Firewall provides a sort and search capability to improve audit analysis. The Administrator can configure auditable events, and can configure the TOE to take appropriate actions in the event that the audit trail is close to being exhausted. The TOE provides the Administrator with a configurable audit trail threshold to track the storage capacity of the audit trail. As soon as the threshold is met, the TOE generates an audit record and displays a message on the console. In addition to displaying the message, the Administrator may configure the TOE to prevent all auditable events except for those performed by the Administrators, or may configure the TOE to overwrite the oldest audit records in the audit trail.
2.3.5.6 Cryptographic support
McAfee Firewall establishes encrypted communications (acting as the initiator or responder) with authorized remote users and external IT entities. McAfee Firewall includes a software cryptographic module that is validated to FIPS 140-2 (Level 1) as a minimum. McAfee Firewall performs data encryption/decryption using the Advanced Encryption Standard (AES) algorithm with a minimum key size of 128 bits. McAfee Firewall also performs digital signature generation/verification, random number generation and cryptographic hashing.
Page 18 of 65 McAfee Firewall implements VPN mechanisms using cryptography and key management, using algorithms that have been validated to FIPS 140-2 (Level 1) as a minimum.
2.4
TOE Documentation
McAfee offers a series of documents that describe the installation of McAfee Firewall as well as guidance for subsequent use and administration of the applicable security features.
Page 19 of 65
3
Security problem definition
This section sets out the threats, assumptions and organisational security policies for the TOE. These are all taken from [FWPP].
3.1
Assumptions
The following conditions are assumed to exist in the operational environment. A.PHYSEC The TOE is physically secure.
A.LOWEXP The threat of malicious attacks aimed at discovering exploitable vulnerabilities is considered low.
A.GENPUR There are no general-purpose computing capabilities (e.g. the ability to execute arbitrary code or applications) and storage repository
capabilities on the TOE.
A.PUBLIC The TOE does not host public data.
A.NOEVIL Authorized administrators are non-hostile and follow all administrator guidance; however, they are capable of error.
A.SINGEN Information cannot flow among the internal and external networks unless it passes through the TOE.
A.DIRECT Human users within the physically secure boundary protecting the TOE may attempt to access the TOE from some direct connection (e.g., a console port) if the connection is part of the TOE.
A.NOREMO Human users who are not authorized administrators cannot access the TOE remotely from the internal or external networks.1
A.REMACC Authorized administrators may access the TOE remotely from the internal and external networks.
3.2
Threats
The following threats are addressed either by the TOE or the environment.
3.2.1
Threats Addressed by the TOE
The threat agents are either unauthorized persons or external IT entities not authorized to use the TOE itself.
T.NOAUTH An unauthorized person may attempt to bypass the security of the TOE so as to access and use security functions and/or non-security functions provided by the TOE.
T.REPEAT An unauthorized person may repeatedly try to guess authentication data in order to use this information to launch attacks on the TOE.
1
All assumptions in this ST are taken from [FWPP]. The assumption is interpreted to refer to direct access to TOE administrative functions, rather than to send traffic via the TOE. As such, the assumption is unnecessary, since such access is controlled via TOE identification and authentication controls, and also requires access to the management application.
Page 20 of 65 T.REPLAY An unauthorized person may use valid identification and authentication
data obtained to access functions provided by the TOE.
T.ASPOOF An unauthorized person on an external network may attempt to by-pass the information flow control policy by disguising authentication data (e.g. spoofing the source address) and masquerading as a legitimate user or entity on an internal network.
T.MEDIAT An unauthorized person may send impermissible information through the TOE, which results in the exploitation of resources on the internal network.
T.OLDINF Because of a flaw in the TOE functioning, an unauthorized person may gather residual information from a previous information flow or internal TOE data by monitoring the padding of the information flows from the TOE.
T.PROCOM An unauthorized person or unauthorized external IT entity may be able to view, modify, and/or delete security related information that is sent between a remotely located authorized administrator and the TOE. T.AUDACC Persons may not be accountable for the actions that they conduct
because the audit records are not reviewed, thus allowing an attacker to escape detection.
T.SELPRO An unauthorized person may read, modify, or destroy security critical TOE configuration data.
T.AUDFUL An unauthorized person may cause audit records to be lost or prevent future records from being recorded by taking actions to exhaust audit storage capacity, thus masking an attackers actions.
T. LOWEXP The threat of malicious attacks aimed at discovering exploitable vulnerabilities is considered low.
T.NETSEC An unauthorised person or unauthorised external I T entity may be able to view or modify private information that is sent between the TOE and another TOE or trusted IT product.
3.2.2
Threat to be Addressed by Operating Environment
The threat possibility discussed below must be countered by procedural measures and/or administrative methods.
T.TUSAGE The TOE may be inadvertently configured, used, and administered in an insecure manner by either authorized or unauthorized persons.
3.3
Organisational security policies
US Federal agencies are required to protect sensitive but unclassified information with cryptography. The following organisational security policy must be met:
P.CRYPTO AES (Advanced Encryption Standard as specified in FIPS 197)
encryption (as specified in SP 800-67) must be used to protect remote administration functions, and the associated cryptographic module must comply, at a minimum, with [FIPS 140-2] (level 1).
Page 21 of 65
4
Security objectives
4.1
Security objectives for the TOE
The following are the IT security objectives for the TOE:
O.IDAUTH The TOE must uniquely identify and authenticate the claimed identity of all users, before granting a user access to TOE functions or, for certain specified services, to a connected network.
O.SINUSE The TOE must prevent the reuse of authentication data for users attempting to authenticate to the TOE from a connected network. O.MEDIAT The TOE must mediate the flow of all information between clients and
servers located on internal and external networks governed by the TOE, and must ensure that residual information from a previous information flow is not transmitted in any way.
O.SECSTA Upon initial start-up of the TOE or recovery from an interruption in TOE service, the TOE must not compromise its resources or those of any connected network.
O.ENCRYP The TOE must protect the confidentiality of its dialogue with an authorized administrator through encryption, if the TOE allows administration to occur remotely from a connected network.
O.SELPRO The TOE must protect itself against attempts by unauthorized users to bypass, deactivate, or tamper with TOE security functions.
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.
O.ACCOUN The TOE must provide user accountability for information flows through the TOE and for authorized administrator use of security functions related to audit.
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. O.LIMEXT The TOE must provide the means for an authorized administrator to
control and limit access to TOE security functions by an authorized external IT entity.
O.EAL The TOE must be structurally tested and shown to be resistant to obvious vulnerabilities.
O.NETSEC The TOE must provide a means to maintain the confidentiality and integrity of information sent between itself and another instance of the TOE or other trusted IT product.
For a detailed mapping between threats and the IT security objectives listed above, see section 7.1 of the Rationale.
Page 22 of 65
4.2
Security objectives for the environment
All of the assumptions stated in section 3.1 are considered to be security objectives for the environment. The following are the security objectives that, in addition to those assumptions, 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.
OE.PHYSEC The TOE is physically secure.
OE.LOWEXP The threat of malicious attacks aimed at discovering exploitable vulnerabilities is considered low.
OE.GENPUR There are no general-purpose computing capabilities (e.g. the ability to execute arbitrary code or applications) and storage repository
capabilities on the TOE.
OE.PUBLIC The TOE does not host public data.
OE.NOEVIL Authorized administrators are non-hostile and follow all administrator guidance; however, they are capable of error.
OE.SINGEN Information cannot flow among the internal and external networks unless it passes through the TOE.
OE.DIRECT Human users within the physically secure boundary protecting the TOE may attempt to access the TOE from some direct connection (e.g. a console port) if the connection is part of the TOE.
OE.NOREMO Human users who are not authorized administrators cannot access the TOE remotely from the internal or external networks.
OE.REMACC Authorized administrators may access the TOE remotely from the internal and external networks.
OE.GUIDAN The TOE must be delivered, installed, administered, and operated in a manner that maintains security.
OE.ADMTRA Authorized administrators must be trained as to establishment and maintenance of security policies and practices.
OE.SINUSE The TOE must prevent the reuse of authentication data for users attempting to authenticate to the TOE from a connected network. 2
For a detailed mapping between threats, assumptions, and the security objectives listed above see section 7.1 of the Rationale.
2
This objective for the environment is included to reflect the use in this ST of an authentication server in the environment.
Page 23 of 65
5
Security requirements
This section provides functional and assurance requirements that must be satisfied by the TOE. These requirements are expressed using functional components from Part 2 of the CC, and assurance components, including Evaluation Assurance Level (EAL), taken from Part 3 of the CC.
5.1
Security functional requirements
The security functional requirements for the TOE are summarised in the table below. They are a superset of [FWPP], with additions for VPN, use of an external authentication server and key management. Extended components are indicated by (X). Additions to the PP are indicated by *.
FMT_SMR.1 Security roles
FIA_ATD.1 User attribute definition
FIA_UID.2 User identification before any action FIA_AFL.1 Authentication failure handling FIA_UAU.5 Multiple authentication mechanisms FIA_UAU.8 (x)* Invocation of authentication mechanism FIA_SOS.2* TSF generation of secrets
FDP_IFC.1 (1) Subset information flow control (1) FDP_IFC.1 (2) Subset information flow control (2) FDP_IFC.1 (3)* Subset information flow control (3) FDP_IFF.1 (1) Simple security attributes (1) FDP_IFF.1 (2) Simple security attributes (2) FDP_IFF.1 (3)* Simple security attributes (3) FDP_UCT.1* Basic data exchange confidentiality FTP_ITC.1* Inter-TSF trusted channel
FMT_MSA.1 (1) Management of security attributes (1) FMT_MSA.1 (2) Management of security attributes (2) FMT_MSA.1 (3) Management of security attributes (3) FMT_MSA.1 (4) Management of security attributes (4) FMT_MSA.1 (5) Management of security attributes (5) FMT_MSA.1 (6) Management of security attributes (6) FMT_MSA.3 Static attribute initialization
FMT_MTD.1 (1) Management of TSF data (1) FMT_MTD.1 (2) Management of TSF data (2) FMT_MTD.2 Management of limits on TSF data FDP_RIP.1 Subset residual information protection
Page 24 of 65 FCS_COP.1 (1) Cryptographic operation
FCS_COP.1 (2)* Cryptographic operation FCS_COP.1 (3)* Cryptographic operation FCS_COP.1 (4)* Cryptographic operation FCS_CKM.1 (1)* Cryptographic key generation FCS_CKM.1 (2)* Cryptographic key generation FCS_CKM.4* Cryptographic key destruction FPT_STM.1 Reliable time stamps
FAU_GEN.1 Audit data generation FAU_SAR.1 Audit review
FAU_SAR.3 Selectable audit review FAU_STG.1 Protected audit trail storage FAU_STG.4 Prevention of audit data loss
FMT_MOF.1 (1) Management of security functions behaviour (1) FMT_MOF.1 (2) Management of security functions behaviour (2)
Table 5.1
5.1.1
FMT_SMR.1 Security roles
FMT_SMR.1.1 The TSF shall maintain the role [authorized administrator]. FMT_SMR.1.2 The TSF shall be able to associate users with the authorized
administrator role.
5.1.2
FIA_ATD.1 User attribute definition
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: [
a) identity;
b) association of a human user with the authorized administrator role; c) hashed value of password
d) login specific data].
5.1.3
FIA_UID.2 User identification before any action
FIA_UID.2.1 The TSF shall require each user to identify itself before allowing any other TSF-mediated actions on behalf of that user.
5.1.4
FIA_AFL.1 Authentication failure handling
FIA_AFL.1.1 The TSF shall detect when [a non-zero number determined by the authorized administrator] of unsuccessful authentication attempts occur related to [authorized TOE administrator access or authorized TOE IT entity access].
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met or surpassed, the TSF shall [prevent the offending user from
Page 25 of 65 successfully authenticating until an authorized administrator takes some action to make authentication possible for the user in question].
5.1.5
FIA_UAU.5 Multiple authentication mechanisms
FIA_UAU.5.1 The TSF shall provide [password and single-use authentication mechanisms] to support user authentication.
FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the [following multiple authentication mechanism rules:
a) single-use authentication mechanism shall be used for authorized administrators to access the TOE remotely such that successful authentication must be achieved before allowing any other TSF-mediated actions on behalf of that authorized administrator; b) single-use authentication mechanism shall be used for authorized
external IT entities accessing the TOE such that successful authentication must be achieved before allowing any other TSF-mediated actions on behalf of that authorized external IT entity; c) single-use authentication mechanism shall be used for human users
sending or receiving information through the TOE using HTTP, HTTPS, FTP or Telnet such that successful authentication must be achieved before allowing any other TSF-mediated actions on behalf of that human user;
d) reusable password mechanism shall be used for authorized administrators to access the TOE via a directly connected terminal such that successful authentication must be achieved before allowing any other TSF-mediated actions on behalf of that authorized
administrator]. Application Notes
1. In the above list a) refers to remote administration, b) relates to VPN, c) relates to proxy users, and d) relates to local console access.
:
2. Under item c) it should be noted that the requirement for FTP, HTTP and HTTPS authentication is a configurable option in the TOE. This also applies to item c) under FIA_UAU.8.
3. The single-use authentication mechanism is provided in conjunction with the following requirement, FIA_UAU.8, which invokes a single-use authentication mechanism from the TOE operating environment. This approach is consistent with the industry view that a firewall supplier should not mandate selection of a single (possibly weak) single-use authentication product, but should allow choice of state of the art products from a range of third party vendors. The "directly connected terminal" for authorized administrator access is provided by an administration workstation connected to the TOE via a protected local area network.
5.1.6
FIA_UAU.8 (X) Invocation of authentication mechanism
FIA_UAU.8.1 (X) The TSF shall invoke the external single-use authentication server to authenticate a user’s claimed identity according to [the following rules:
Page 26 of 65 a) single-use authentication mechanism shall be used for
authorized administrators to access the TOE remotely such that successful authentication must be achieved before allowing any other TSF-mediated actions on behalf of that authorized
administrator;
b) single-use authentication mechanism shall be used for authorized external IT entities accessing the TOE such that successful authentication must be achieved before allowing any other TSF-mediated actions on behalf of that authorized external IT entity;
c) Single-use authentication mechanism shall be used for human users sending or receiving information through the TOE using HTTP, HTTPS, FTP or Telnet such that successful authentication must be achieved before allowing any other TSF-mediated actions on behalf of that human user].
5.1.7
FIA_SOS.2 TSF Generation of secrets
FIA_SOS.2.1 The TSF shall provide a mechanism to generate secrets that meet [random number generation (RNG) services in accordance ANSI X9.31 Appendix A.2.4, seeded by one or more independent software-based entropy sources].
FIA_SOS.2.2 The TSF shall be able to enforce the use of TSF generated secrets for [all applicable cryptographic services].
Requirements Overview:
5.1.8
FDP_IFC.1 Subset information flow control (1)
This Security Target includes multiple information flow control Security Function Policies (SFPs). The CC allows multiple policies to exist, each having a unique name. This is accomplished by iterating FDP_IFC.1 for each of the three named information flow control policies. The first policy identified is called the UNAUTHENTICATED SFP. The subjects under control of this policy are external IT entities on an internal or external network sending information through the TOE to other external IT entities. The second policy identified is called the AUTHENTICATED SFP. The subjects under control of this policy are human users on an internal or external network who must be authenticated at the TOE before using the services in FIA_UAU.5 and FIA_UAU.8. The third policy identified is called the VPN SFP. The subjects under control of this policy are network interfaces for the TOE or other IT products. The information flowing between subjects in all policies is traffic with attributes, defined in FDP_IFF.1.1, including source and destination addresses. The rules that define each information flow-control SFP are found in FDP_IFF.1.2.
Component FDP_IFF.1 is iterated three times to correspond to each of the three iterations of FDP_IFC.1.
Note:
FDP_IFC.1.1(1) The TSF shall enforce the [UNAUTHENTICATED SFP] on:
This first policy identified is called the UNAUTHENTICATED SFP. The subjects under control of this policy are external IT entities on an internal or external network sending information through the TOE to other external IT entities.
a) [subjects: unauthenticated external IT entities that send and receive information through the TOE to one another;
Page 27 of 65 b) information: traffic sent through the TOE from one subject to another; c) operation: pass information].
5.1.9
FDP_IFC.1 Subset information flow control (2)
Note:
FDP_IFC.1.1(2) The TSF shall enforce the [AUTHENTICATED SFP] on:
This second policy is called the AUTHENTICATED SFP. The subjects under control of this policy are human users on an internal or external network who must be authenticated to the TOE.
a) [subjects: a human user or external IT entity that sends and receives FTP, HTTP, HTTPS and Telnet information through the TOE to one another, only after the human user initiating the information flow has authenticated at the TOE per FIA_UAU.5 and FIA_UAU.8(X); b) information: FTP, HTTP, HTTPS and Telnet traffic sent through the
TOE from one subject to another;
c) operation: initiate service and pass information].
5.1.10 FDP_IFC.1 Subset information flow control (3)
Note:
FDP_IFC.1(3) The TSF shall enforce the [VPN SFP] on:[
This third policy is called the VPN SFP. The subjects under control of this policy are interfaces of the TOE or other trusted IT products on an internal or external network where private communication is required.
a) source subject: TOE or other IT product interface on which information is received;
b) destination subject: TOE or other IT product interface to which information is destined;
c) information: network packets; d) operations:
i) pass packets without modifying;
ii) send IPSEC encrypted and authenticated packets to a peer TOE or other IT product using ESP in tunnel mode;
iii) decrypt, verify authentication and pass received packets from a peer TOE or other IT product in tunnel mode using ESP].
5.1.11 FDP_IFF.1 Simple security attributes (1)
FDP_IFF.1.1(1) The TSF shall enforce the [UNAUTHENTICATED SFP] based on at least the following types of subject and information security attributes:
[a) subject security attributes: •presumed address,
•no other subject security attributes; b) information security attributes:
•presumed address of source subject; •presumed address of destination subject;
Page 28 of 65 •transport layer protocol;
•TOE interface on which traffic arrives and departs; •service (application signature);
•destination service port range].
FDP_IFF.1.2(1) The TSF shall permit an information flow between a controlled subject and another controlled subject via a controlled operation if the following rules hold:
[a) Subjects on an internal 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;
•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;
•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(1) The TSF shall enforce the [none].
FDP_IFF.1.4(1) The TSF shall explicitly authorize an information flow based on the following rules: [none].
FDP_IFF.1.5(1) The TSF shall explicitly deny an information flow based on the following rules:
[a) The TOE shall reject requests for access or services where the information arrives on an external TOE interface, and the presumed address of the source subject is an external IT entity on an internal network;
b) The TOE shall reject requests for access or services where the information arrives on an internal TOE interface, and the presumed
Page 29 of 65 address of the source subject is an external IT entity on the external network;
c) The TOE shall reject requests for access or services where the information arrives on either an internal or external TOE interface, and the presumed address of the source subject is an external IT entity on a broadcast network;
d) The TOE shall reject requests for access or services where the information arrives on either an internal or external TOE interface, and the presumed address of the source subject is an external IT entity on the loopback network;
e) The TOE shall reject requests in which the subject specifies the route in which information shall flow en route to the receiving subject; and f) For the FTP, HTTP, HTTPS and SMTP application protocols
supported by the TOE (e.g., DNS, HTTP, SMTP, and POP3), the TOE shall deny any access or service requests that do not conform to its associated published protocol specification (e.g. RFC). This shall be accomplished through protocol filtering proxies that are designed for that purpose.
Application Note
5.1.12 FDP_IFF.1 Simple security attributes (2)
: The generalized wording of the FDP_IFF.1.5f) requirement has been modified from the PP to make it clear that only HTTP, HTTPS and SMTP are included in the TOE (while DNS and POP3 application-level proxies are not included in the TOE).
FDP_IFF.1.1(2) The TSF shall enforce the [AUTHENTICATED SFP] based on at least the following types of subject and information security attributes: [a) subject security attributes:
• presumed address;
• no other subject security attributes; b) information security attributes:
• user identity;
• presumed address of source subject; • presumed address of destination subject; • transport layer protocol;
• TOE interface on which traffic arrives and departs; • service (i.e. FTP, Telnet, HTTP and HTTPS); • security-relevant service command;
• destination service port range; • application signature].
Page 30 of 65 FDP_IFF.1.2(2) The TSF shall permit an information flow between a controlled subject
and another controlled subject via a controlled operation if the following rules hold:
[a) Subjects on an internal network can cause information to flow through the TOE to another connected network if:
• the human user initiating the information flow authenticates according to FIA_UAU.5 and FIA_UAU.8;
• 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;
• 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:
• the human user initiating the information flow authenticates according to FIA_UAU.5 and FIA_UAU.8;
• 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;
• 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(2) The TSF shall enforce the [none].
FDP_IFF.1.4(2) The TSF shall explicitly authorize an information flow based on the following rules: [none].
FDP_IFF.1.5(2) The TSF shall explicitly deny an information flow based on the following rules:
[a) The TOE shall reject requests for access or services where the information arrives on an external TOE interface, and the presumed address of the source subject is an external IT entity on an internal network;
b) The TOE shall reject requests for access or services where the information arrives on an internal TOE interface, and the presumed address of the source subject is an external IT entity on the external network;
Page 31 of 65 c) The TOE shall reject requests for access or services where the
information arrives on either an internal or external TOE interface, and the presumed address of the source subject is an external IT entity on a broadcast network;
d) The TOE shall reject requests for access or services where the information arrives on either an internal or external TOE interface, and the presumed address of the source subject is an external IT entity on the loopback network;
e) The TOE shall reject requests in which the subject specifies the route in which information shall flow en route to the receiving subject; and f) The TOE shall reject Telnet, FTP, HTTP and HTTPS command
requests that do not conform to generally accepted published protocol definitions (e.g., RFCs). This must be accomplished through protocol filtering proxies designed for that purpose.
Application Note
5.1.13 FDP_IFF.1 Simple security attributes (3)
: The TOE can make no claim as to the real address of any source or destination subject, and therefore the TOE can only suppose that these addresses are accurate. Therefore, a "presumed address" is used to identify source and destination addresses.
FDP_IFF.1.1(3) The TSF shall enforce the [VPN SFP] based on the following types of subject and information security attributes:
[a) Source subject security attributes: set of source subject identifiers;
b) Destination subject security attributes: set of destination subject identifiers;
c) Information security attributes: presumed identity of source subject, identity of destination subject].
FDP_IFF.1.2(3) The TSF shall permit an information flow between a source subject and a destination subject via a controlled operation if the following rules hold: [a) the presumed identity of the source subject is in the set of
source subject identifiers;
b) the identity of the destination subject is in the set of source destination identifiers;
c) the information security attributes match the attributes in an information flow policy rule (contained in the information flow policy rule set defined by the Authorized Administrator) according to the following algorithm {rules are examined in order, once a match is found, the specified action is taken}; and d) the selected information flow policy rule specifies that the
information flow is to be permitted, and what specific operation from FDP_IFC.1 (3) is to be applied to that information flow].