BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP
Security Target
1.6
Version:
Release
Status:
2018-02-12
Last Update:
Trademarks
The following terms are trademarks of F5:Networks, Inc.
● BIG-IP
● Local Traffic Manager
● Access Policy Manager
● Application Security Manager
● TMOS Platform
Other company, product, and service names may be trademarks or service marks of others.
Legal Notice
This document is provided AS IS with no express or implied warranties. Use the information in this
document at your own risk.
This document may be reproduced or distributed in any form without prior permission provided the
copyright notice is retained on all copies. Modified versions of this document may be freely distributed
provided that they are clearly identified as such, and this copyright is included intact.
Revision History
Changes to Previous Revision
Author(s)
Date
Revision
Removed ADR_DRNG2.1 per evaluator instructions from the assurance
requirements. Version submitted to BSI along with the application for
re-certification.
Gordon McIntosh
2015-12-08
0.23
Updated the ST based on the ADF-Base Security Target.
Staffan Persson
2016-02-24
1.0
Addressed evaluator comments.
Staffan Persson
2016-11-14
1.1
Updated the ST to make it consistent with the ADF-Base ST changes.
Staffan Persson
2017-02-14
1.2
Addressed certifier comments.
Staffan Persson
2017-08-28
1.3
Addressed additional certifier comments.
Staffan Persson
2017-09-11
1.4
Updated the crypto statement table.
Staffan Persson
2017-09-25
1.5
Updated the TOE version number.
Staffan Persson
2018-02-12
1.6
Page 2 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Table of Contents
1 Introduction ................................................................................................... 10
1.1 Security Target Identification ....................................................................................... 10
1.2 TOE Identification ........................................................................................................ 10
1.3 TOE Type ...................................................................................................................... 10
1.4 TOE Overview .............................................................................................................. 10
1.4.1 Basic security functionality offered by the TOE ................................................... 10
1.5 TOE Description ........................................................................................................... 11
1.5.1 Introduction ......................................................................................................... 11
1.5.2 Architecture ........................................................................................................ 12
1.5.3 Security functionality .......................................................................................... 14
1.5.3.1 Authentication ............................................................................................ 14
1.5.3.2 Access control ............................................................................................ 15
1.5.3.3 Communications security ........................................................................... 15
1.5.3.4 Synchronization and failover ...................................................................... 17
1.5.3.5 Auditing ...................................................................................................... 17
1.5.3.6 TSF management ....................................................................................... 17
1.5.3.7 Cryptography ............................................................................................. 18
1.5.4 Operational environment support ....................................................................... 18
1.5.4.1 Physical environment ................................................................................. 18
1.5.4.2 Runtime environment ................................................................................. 18
1.5.4.3 Network environment ................................................................................. 18
1.5.4.4 Virtualized environment ............................................................................. 18
1.5.5 TOE boundaries ................................................................................................... 19
1.5.5.1 Physical boundaries .................................................................................... 19
1.5.5.2 Logical boundaries / evaluated configuration ............................................. 21
1.5.6 Security Policy Model .......................................................................................... 22
1.5.6.1 Administrator Access Control Policy ........................................................... 22
1.5.6.2 APM Connection Policy ............................................................................... 22
1.5.6.3 TSF and user data ...................................................................................... 23
2 CC Conformance Claim ................................................................................... 24
3 Security Problem Definition ............................................................................ 25
3.1 Threat Environment ..................................................................................................... 25
3.1.1 Threats countered by the TOE ............................................................................ 25
3.2 Assumptions ................................................................................................................ 26
3.2.1 Environment of use of the TOE ........................................................................... 26
3.2.1.1 Physical ...................................................................................................... 26
3.2.1.2 Personnel .................................................................................................... 26
3.2.1.3 Connectivity ............................................................................................... 26
3.3 Organizational Security Policies ................................................................................... 27
4 Security Objectives ........................................................................................ 29
4.1 Objectives for the TOE ................................................................................................. 29
4.2 Objectives for the Operational Environment ................................................................ 30
Page 3 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
4.3 Security Objectives Rationale ...................................................................................... 31
4.3.1 Coverage ............................................................................................................. 31
4.3.2 Sufficiency ........................................................................................................... 32
5 Extended Components Definition .................................................................... 35
5.1 Class FAU: Security audit ............................................................................................. 35
5.1.1 Security audit event storage (STG) ..................................................................... 35
5.1.1.1 FAU_STG_EXT.1 - External Audit Trail Storage ............................................. 35
5.2 Class FCS: Cryptographic support ................................................................................ 35
5.2.1 Cryptographic key management (CKM) .............................................................. 35
5.2.1.1 FCS_CKM_EXT.4 - Cryptographic Key Zeroization ....................................... 35
5.2.2 Explicit HTTPS specification (HTTPS) ................................................................... 36
5.2.2.1 FCS_HTTPS_EXT.1 - Explicit HTTPS specification ......................................... 36
5.2.3 Random Bit Generation (RBG) ............................................................................. 36
5.2.3.1 FCS_RBG_EXT.1 - Random Bit Generation ................................................... 36
5.2.4 Explicit SSH specification (SSH) .......................................................................... 37
5.2.4.1 FCS_SSH_EXT.1 - Explicit SSH specification ................................................ 37
5.2.5 Explicit TLS specification (TLS) ............................................................................ 38
5.2.5.1 FCS_TLS_EXT.1 - Flexible TLS ...................................................................... 38
5.3 Class FIA: Identification and Authentication ................................................................. 38
5.3.1 Password Management (PMG) ............................................................................. 38
5.3.1.1 FIA_PMG_EXT.1 - Password Management .................................................... 38
5.3.2 User Identification and Authentication (UAU) ...................................................... 39
5.3.2.1 FIA_UAU_EXT.2 - Password-based Authentication Mechanism .................... 39
5.3.3 User Identification and Authentication (UIA) ....................................................... 39
5.3.3.1 FIA_UIA_EXT.1 - User Identification and Authentication .............................. 39
5.4 Class FPT: Protection of the TSF ................................................................................... 40
5.4.1 Protection of Administrator Passwords (APW) ..................................................... 40
5.4.1.1 FPT_APW_EXT.1 - Protection of Administrator Passwords ............................ 40
5.4.2 Protection of TSF Data (for reading of all symmetric keys) (SKP) ........................ 40
5.4.2.1 FPT_SKP_EXT.1 - Protection of TSF Data (for reading of all symmetric
keys) ......................................................................................................................... 40
5.4.3 TSF Testing (TST) ................................................................................................. 41
5.4.3.1 FPT_TST_EXT.1 - TSF Testing ....................................................................... 41
5.4.4 Trusted Update (TUD) .......................................................................................... 41
5.4.4.1 FPT_TUD_EXT.1 - Trusted Update ................................................................ 41
6 Security Requirements ................................................................................... 43
6.1 TOE Security Functional Requirements ........................................................................ 43
6.1.1 Security audit ...................................................................................................... 45
6.1.1.1 Audit Data Generation (FAU_GEN.1) .......................................................... 45
6.1.1.2 User Identity Association (FAU_GEN.2) ...................................................... 48
6.1.1.3 External Audit Trail Storage (FAU_STG_EXT.1) ........................................... 48
6.1.2 Cryptographic support ........................................................................................ 48
6.1.2.1 Cryptographic Key Generation (SSH host key) (FCS_CKM.1-SSH) .............. 48
Page 4 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
6.1.2.2 Cryptographic Key Generation (for asymmetric keys) (FCS_CKM.1-RSA)
................................................................................................................................. 48
6.1.2.3 Cryptographic Key Zeroization (FCS_CKM_EXT.4) ...................................... 49
6.1.2.4 Cryptographic Operation (for cryptographic signature) (FCS_COP.1(1))
................................................................................................................................. 49
6.1.2.5 Cryptographic Operation (for cryptographic hashing) (FCS_COP.1(2)) ...... 50
6.1.2.6 Cryptographic Operation (for keyed-hash message authentication)
(FCS_COP.1(3)) ......................................................................................................... 50
6.1.2.7 Explicit: HTTPS (FCS_HTTPS_EXT.1) ........................................................... 50
6.1.2.8 Extended: Cryptographic Operation (Random Bit Generation)
(FCS_RBG_EXT.1) ..................................................................................................... 50
6.1.2.9 Explicit: SSH (FCS_SSH_EXT.1) ................................................................... 51
6.1.2.10 Traffic TLS (FCS_TLS_EXT.1) ..................................................................... 51
6.1.3 User data protection ........................................................................................... 52
6.1.3.1 Subset access control (FDP_ACC.1) ........................................................... 52
6.1.3.2 Security attribute based access control (FDP_ACF.1) ................................. 52
6.1.3.3 Subset information flow control (FDP_IFC.1-APM) ...................................... 53
6.1.3.4 Simple security attributes (FDP_IFF.1-APM) ............................................... 53
6.1.3.5 Import of user data without security attributes (FDP_ITC.1) ...................... 55
6.1.3.6 Full Residual Information Protection (FDP_RIP.2) ........................................ 55
6.1.3.7 Inter-TSF user data confidentiality transfer protection (FDP_UCT.1) .......... 55
6.1.3.8 Inter-TSF user data integrity transfer protection (FDP_UIT.1) ..................... 55
6.1.4 Identification and authentication ........................................................................ 56
6.1.4.1 Authentication failure handling (FIA_AFL.1) ............................................... 56
6.1.4.2 User attribute definition (FIA_ATD.1) ......................................................... 56
6.1.4.3 Password Management (FIA_PMG_EXT.1) .................................................. 56
6.1.4.4 Password-based Authentication Mechanism (FIA_UAU_EXT.2) ................... 56
6.1.4.5 Multiple authentication mechanisms (FIA_UAU.5-APM) ............................. 57
6.1.4.6 Traffic authentication mechanisms (FIA_UAU.5-LTM) ................................. 57
6.1.4.7 Protected authentication feedback (FIA_UAU.7) ........................................ 57
6.1.4.8 User Identification and Authentication (FIA_UIA_EXT.1) ............................. 57
6.1.5 Security management ......................................................................................... 58
6.1.5.1 Management of security attributes (FMT_MSA.1) ...................................... 58
6.1.5.2 Static attribute initialisation (FMT_MSA.3-APM) ......................................... 58
6.1.5.3 Static attribute initialisation (FMT_MSA.3-BASE) ....................................... 58
6.1.5.4 Management of TSF data (for general TSF data) (FMT_MTD.1) ................. 58
6.1.5.5 Specification of Management Functions (FMT_SMF.1) ................................ 58
6.1.5.6 Security roles (FMT_SMR.1) ....................................................................... 59
6.1.6 Protection of the TSF ........................................................................................... 59
6.1.6.1 Protection of Administrator Passwords (FPT_APW_EXT.1) .......................... 59
6.1.6.2 Failure with preservation of secure state (FPT_FLS.1) ............................... 59
6.1.6.3 Protection of TSF Data (for reading of all symmetric keys) (FPT_SKP_EXT.1)
................................................................................................................................. 59
6.1.6.4 Inter-TSF basic TSF data consistency (FPT_TDC.1) .................................... 60
6.1.6.5 TSF testing (FPT_TST_EXT.1) ...................................................................... 60
Page 5 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
6.1.6.6 Extended: Trusted Update (FPT_TUD_EXT.1) .............................................. 60
6.1.7 Resource utilisation ............................................................................................. 60
6.1.7.1 Maximum Quotas (FRU_RSA.1) .................................................................. 60
6.1.8 TOE access .......................................................................................................... 60
6.1.8.1 TSF-initiated Termination (FTA_SSL.3) ....................................................... 60
6.1.8.2 User-initiated termination (FTA_SSL.4) ...................................................... 61
6.1.8.3 Default TOE Access Banners (FTA_TAB.1) .................................................. 61
6.1.9 Trusted path/channel of the TSF .......................................................................... 61
6.1.9.1 Inter-TSF trusted channel (FTP_ITC.1) ........................................................ 61
6.1.9.2 Trusted Path (FTP_TRP.1) ........................................................................... 61
6.2 Security Functional Requirements Rationale ................................................................ 62
6.2.1 Coverage ............................................................................................................. 62
6.2.2 Sufficiency ........................................................................................................... 64
6.2.3 Security Requirements Dependency Analysis ..................................................... 65
6.2.3.1 Security Requirements Dependency Rationale ........................................... 68
6.2.4 Internal consistency and mutual support of SFRs ............................................... 69
6.3 Security Assurance Requirements ............................................................................... 70
6.3.1 Assurance Requirements ..................................................................................... 70
6.4 Security Assurance Requirements Rationale ............................................................... 71
7 TOE Summary Specification ............................................................................ 72
7.1 TOE Security Functionality ........................................................................................... 72
7.1.1 Device management ........................................................................................... 72
7.1.1.1 Security Function Management .................................................................. 72
7.1.1.2 Authentication ............................................................................................ 72
7.1.1.3 Access Control ............................................................................................ 74
7.1.1.4 Auditing ...................................................................................................... 76
7.1.1.5 Communications Security ........................................................................... 78
7.1.2 Basic Traffic Management ................................................................................... 79
7.1.2.1 Replay Detection ........................................................................................ 79
7.1.2.2 Traffic authentication .................................................................................. 79
7.1.2.3 TLS offloading ............................................................................................. 80
7.1.3 VPN traffic ........................................................................................................... 81
7.1.4 Cryptographic mechanisms ................................................................................. 82
7.1.4.1 Key Generation ........................................................................................... 83
7.1.4.2 Key Storage ................................................................................................ 84
7.1.4.3 Certificate validation .................................................................................. 84
7.1.4.4 Cryptographic primitives in the TOE ........................................................... 84
7.1.4.5 Random Number Generation ...................................................................... 85
7.1.4.6 Zeroization of Critical Security Parameters ................................................ 86
7.1.4.7 Crypto Statement ....................................................................................... 87
7.1.5 TSF Protection and Support Functions ................................................................. 92
7.1.5.1 Failover of Redundant Systems .................................................................. 92
7.1.5.2 Self-tests ..................................................................................................... 93
7.1.5.3 Update Verification ..................................................................................... 93
Page 6 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
7.1.5.4 Denial-of-Service Mitigation ........................................................................ 94
7.1.5.5 Protection of Sensitive Data ....................................................................... 94
7.1.5.6 Residual Information Protection .................................................................. 95
8 Abbreviations, Terminology and References .................................................... 96
8.1 Abbreviations ............................................................................................................... 96
8.2 Terminology ................................................................................................................. 97
8.3 References ................................................................................................................... 97
Page 7 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
List of Tables
Table 1: Supported Hardware Models ................................................................................... 20
Table 2: Mapping of security objectives to threats and policies ............................................ 31
Table 3: Mapping of security objectives for the Operational Environment to assumptions,
threats and policies ........................................................................................................ 32
Table 4: Sufficiency of objectives countering threats ........................................................... 32
Table 5: Sufficiency of objectives holding assumptions ........................................................ 33
Table 6: Sufficiency of objectives enforcing Organizational Security Policies ....................... 34
Table 7: SFRs for the TOE ..................................................................................................... 43
Table 8: Auditable Events ..................................................................................................... 46
Table 9: Mapping of security functional requirements to security objectives ....................... 62
Table 10: Security objectives for the TOE rationale .............................................................. 64
Table 11: TOE SFR dependency analysis .............................................................................. 66
Table 12: SARs ...................................................................................................................... 70
Table 13: BIG-IP User Roles ................................................................................................... 75
Table 14: Audit Logs and Their Content ................................................................................ 77
Table 15: Communications Security in BIG-IP ....................................................................... 82
Table 16: Zeroization of Critical Security Parameters ........................................................... 86
Table 17: Cryptograhic functions of TLS ............................................................................... 87
Table 18: Cryptograhic functions of SSH ............................................................................... 91
Page 8 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
List of Figures
Figure 1: Schematic example of a BIG-IP network environment ........................................... 12
Figure 2: Architectural aspects of BIG-IP ............................................................................... 13
Figure 3: Cryptographic services in TOE and underlying hardware ...................................... 83
Page 9 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
1 Introduction
1.1 Security Target Identification
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security Target
Title:
1.6
Version:
Release
Status:
2018-02-12
Date:
F5 Networks, Inc.
Sponsor:
F5 Networks, Inc.
Developer:
Security Target, Common Criteria, F5, VPN, Networking
Keywords:
1.2 TOE Identification
The TOE is BIG-IP ADC-AP Version Version 11.5.1 HF10 plus Engineering Hotfix for CVE-2017-6164
(build 10.123.180).
1.3 TOE Type
The TOE type is Networking Device. In particular the TOE is highly configurable VPN and Web
gateway. The TOE is the base configuration of a product from the BIG-IP product family, called
Application Delivery Controllers that contains the core security functionality. The TOE is designed
with the Protection Profile for Network Devices v1.1 (NDPP) in mind..
1.4 TOE Overview
The TOE is part of the BIG-IP product, which is an appliance containing both hardware and software.
The TOE is an Application Delivery Controller that provides network traffic management and VPN
capabilities.
The TOE is software only and sits on top of F5's Traffic Management Operating System (TMOS) that
runs on hardware provided by F5.
A summary of the security functionality offered by the TOE follows. Section 1.5.5 (TOE boundaries)
provides further information on the scope of the TOE and evaluated configurations, as well as on
the supported hardware platforms.
1.4.1 Basic security functionality offered by the TOE
The TOE's Traffic Management Microkernel (TMM), along with additional software, provides basic
networking functionality, with the TOE operating as a network switch and reverse proxy. This
includes the following security functions:
● Administration capabilities: A command line interface ("tmsh"), web-based GUI
("Configuration utility"), and a web-based API ("iControl API") are offered to administrators
for all relevant configuration of security functionality. This includes the authentication of
administrators by user name and password, as well as access control based on pre-defined
roles and, optionally, groups of objects ("Profiles"). "Profiles" can be defined for individual
servers and classes of servers that the TOE forwards traffic from clients to, and for traffic
Page 10 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
that matches certain characteristics, determining the kind of treatment applicable to that
traffic. Management capabilities offered by the TOE include a powerful scripting language
("iRules") and the definition of templates for certain configuration options.
● Communications security: The TOE protects remote connections to its management
interfaces with TLS and SSH as well as the creation of TLS tunnels to remote BIG-IP devices
in order to connect remote organizational networks in a protected fashion. The TOE can
also act as a TLS proxy for HTTP traffic, or alternatively offload this functionality to a crypto
processor in the operational environment.
● VPN functionality: The TOE terminates TLS-based VPN connections from remote clients, by
offering web-based access for remote users, making internal server resources available to
remote users by presenting them in a web portal; forwarding of certain application protocols,
such as remote desktop protocol (RDP) connections; and VPN tunnels that allow the routing
of network traffic between clients and an organizational network. Remote users can be
authenticated using external authentication providers.
● Traffic authentication: Network traffic can be authenticated by means of HTTP authentication
and TLS client certificate validation. Traffic can then be forwarded to destinations based
on the authentication outcome.
● Failover functionality: The TOE is configured as two redundant systems that synchronize
their configuration data. The TOE will detect failures that may occur in hard- or software
of one system and fail over to the redundant system while maintaining a secure
configuration.
● Auditing capabilities: BIG-IP implements syslog capabilities to generate audit records for
security-relevant events.
● A number of external authentication providers are supported for traffic authentication
provided by the TOE. (The evaluated configuration supports Active Directory, LDAP, and
OCSP responders.)
1.5 TOE Description
1.5.1 Introduction
Figure 1 provides a schematic example of the TOE's role and location in a networking environment.
Page 11 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Figure 1: Schematic example of a BIG-IP network environment
The F5 hardware hosting BIG-IP is depicted by the two redundant network devices in the diagram.
In this example:
● Internet connections (dark red network connection) are mediated by BIG-IP to provide web
or VPN access to resources located in an organization's internal network (yellow network
connection), for example to web-based e-commerce systems.
● Users in the organization's Intranet (orange network connection) also access resources in
the server pools to interact with the internal server pool.
● Network administrators connect to BIG-IP via a dedicated network interface (dark green
network connection) to administer the TOE.
● The TOE is set up in a redundant failover configuration, with heartbeat monitoring and
reporting via a data link between the two instances (light green connections).
1.5.2 Architecture
The TOE is implemented on top of F5's Traffic Management Operating System (TMOS) that runs on
hardware provided by F5. TMOS is a Linux operating system that runs on appliance hardware.
Neither the hardware, nor the TMOS operating system (with certain exceptions spelled out in this
Security Target, i.e. the OpenSSH, OpenSSL, PAM, and syslog implementations provided by the
TMOS operating system) are part of the TOE.
At the core of the BIG-IP is the Traffic Management Microkernel (TMM), representing the data plane
of the product when compared to traditional network device architectures. It is implemented by a
daemon running with root privileges, performing its own memory management, and having direct
access to the network hardware. TMM implements a number of sequential filters both for the
“client-side” and “server-side” network interfaces served by BIG-IP. The filters implemented in TMM
include a TCP, TLS, compression, and HTTP filter, amongst others. If the hardware (TOE environment)
provides more than one CPU, TMM runs multi-threaded (one thread per CPU). In this case,
disaggregators implemented in hardware or, depending on the underlying appliance, firmware, are
Page 12 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
responsible for de-multiplexing and multiplexing network traffic for handling by an individual TMM
thread. In addition to the actual switch hardware, F5 appliance hardware (TOE environment) also
contains a High-Speed Bridge (HSB, implemented by means of an FPGA) that performs basic traffic
filtering functionality as instructed by TMM.
Additional plug-in filters can be added to this queue by individual product packages. These plug-ins
typically have a filter component implemented in TMM, with additional and more complex logic
implemented in a counter-part implemented in a Linux-based daemon (module). The plug-in modules
relevant to this evaluation are shown in Figure 2, include:
● Local Traffic Manager (LTM): authentication of HTTP traffic and advanced traffic forwarding
directives
● Access Policy Manager (APM): TLS-based client connectivity (web-based portals, VPN traffic
tunneling, and similar)
A diagram depicting aspects of the TOE's architecture, and the boundaries of the TOE, is provided
in Figure 2.
Figure 2: Architectural aspects of BIG-IP
Section 1.5.5 describes the packages, and functions, that are available in different product offerings
in more detail.
In addition to data plane functionality implemented in TMM, the TOE comprises a number of software
pieces that run on the Linux host in order to provide:
Page 13 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
● Auditing functionality, by generating audit events using the host system's syslog capabilities.
(In addition, a concept called "high-speed logging" (HSL) allows TMM instances to send
certain log traffic directly to external audit servers.)
● Management functionality, presented to consumers both via a dedicated shell (traffic
management shell, "tmsh") that can be reached by administrators via SSH; and via a both
a web GUI and a SOAP protocol interface ("iControl API") that can be reached through a
network interface. Those management interfaces are implemented in the background by
a central management control program daemon (mcpd) that provides configuration
information to individual TOE parts and coordinates its persistent storage.
● Authentication is enforced on all administrative interfaces. Local administration is using
password authentication with an internal password repository, relying on a password policy
enforced by the TOE. Remote administrators are authenticated by the TOE using certificates
that are validated by the TOE.
● Authentication functionality that consolidates multiple external authentication providers,
including Active Directory, LDAP, and OCSP responders for traffic authentication.
Not shown in Figure 2 is also a connection to a redundant BIG-IP host for failover purposes.
Synchronization information, availability status, etc. is exchanged constantly by the machines via
a dedicated network connection between the machines.
Multiple modules in the TOE and its operational environment provide cryptographic services for
the TSF. This is further discussed in section 1.5.3.7.
1.5.3 Security functionality
This section provides an overview of the security functions implemented by the TOE.
1.5.3.1 Authentication
Administrators
The TOE identifies individual administrative users by user name and authenticates them by passwords
stored in a local configuration database; the TOE can enforce a password policy based on overall
minimum length and number of characters of different types required.
Authentication of administrators is enforced at all configuration interfaces, i.e. at the shell (tmsh,
via SSH), the Configuration utility (web-based GUI), and iControl API.
Network traffic
The Local Traffic Manager module (LTM) in BIG-IP ADC-AP supports the authentication of network
sessions ("traffic authentication") using the following mechanism:
● TLS client certificate authentication (certificates, user groups, and roles)
The Access Policy Manager (APM) module of BIG-IP ADC-AP can authenticate remote users via one
of the following means:
● LDAP servers
● Active Directory (Kerberos) servers
● OCSP servers
Page 14 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
● Additional authentication mechanisms that are not included in the evaluated configuration
include RADIUS servers, HTTP servers, RSA SecurID servers, RSA SecurID over RADIUS,
Oracle Access Manager, and TACACS+ servers
LDAP directories and Microsoft Active Directory and Domain servers are supported as authentication
backends in the evaluated configuration.
Remote clients can authenticate the TOE by validating server certificates presented by the TOE.
1.5.3.2 Access control
Administrators
BIG-IP implements role-based access control. The roles are pre-defined to grant administrators
varying degrees of control over the basic configuration of the TOE, and additional roles are introduced
for module-specific tasks. These roles can be assigned to administrative users by authorized
administrators. The list of roles is provided in Table 13.
The TOE supports external role associations. I.e., if a user is configured to be authenticated by an
external authentication service (such as, LDAP), administrators can configure the TOE to use the
groups defined in that service to match one of BIG-IP's predefined roles. This allows day-to-day
management of role assignments in the external authentication service.
In addition to roles, the TOE allows the definition of partitions. Configuration objects, such as server
pools or service profiles, can be assigned to individual partitions, as can administrative users. This
allows to restrict administrative access of individual administrators to configuration objects that
belong to the partition that has been assigned to the administrative user.
VPN traffic
The APM module in the TOE allows the definition of access control policies for authenticated
connections from remote clients, determining which resources in the internal network a user is
allowed to access, and whether access depends on the client machine reporting a successful
endpoint security check or not.
1.5.3.3 Communications security
This chapter summarizes the security functionality provided by the TOE in order to protect the
confidentiality and integrity of network connections.
Generic network traffic
BIG-IP ADC-AP's LTM allows the termination of TLS connections on behalf of internal servers or
server pools. External clients can thus connect via TLS to the TOE, which acts as a TLS server and
decrypts the traffic and then forwards it to internal servers for processing of the content. It is also
possible to (re-) encrypt traffic from the TOE to servers in the organization with TLS, with the TOE
acting as a TLS client.
Certificate validation is performed for connection to external servers. Certificate revocation checks
are using locally kept CRLs. Certificates are also validated using an external OCSP server, provided
the TOE is configured in such a way.
Page 15 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Administrative traffic
The TOE secures administrative traffic (i.e., administrators connecting to the TOE in order to configure
and maintain it). Remote access to the traffic management shell (tmsh) is secured via SSH.
Note: Access to the web-based Configuration utility and iControl API is provided via a dedicated
connection.
OpenSSH
The TOE SSH implementation is based on OpenSSH Version openssh-4.3p2; however, the TOE
OpenSSH configuration sets the implementation via the sshd_config as follows:
● Supports two types of authentication, RSA public-key and password-based.
● Packets greater than (256*1024) bytes are dropped
● The transport encryption algorithms are limited to AES-CBC-256
● The transport mechanism uses SSH_RSA as public key algorithm (ssh_rsa)
● The transport data integrity algorithm is limited to hmac-sha1
● The SSH protocol key exchange mechanism is limited to diffie-hellman-group14-sha1
Remote logging
The TOE offers the establishment of TLS sessions with external log hosts for protection of audit
records in transfer, using the mechanism described in the previous section.
VPN traffic
BIG-IP ADC-AP's APM implements VPN technology for remote access of users to resources in a local
network, providing connections that are secured against eavesdropping and undetected
manipulation. This includes:
● web-based communication ("Web Application"): the TOE provides termination of an
encrypted channel (TLS) from a client's web browser to the TOE, allowing to implement
the authentication of remote users (see above) and provision of access for users to virtual
servers located inside the organization's network. All internal web server resources are
rewritten for receipt of the client's web browser through a web portal provided by the TOE.
● web-based communication ("Application Access"): APM performs authentication and access
control for remote clients connecting via TLS, and acts as a proxy for an individual
application (such as, a remote desktop connection) located inside the organization's network
● web-based communication ("LTM Access"): APM performs authentication and access control
for remote clients connecting via TLS, and then hands client requests to LTM, which serves
as a proxy for a pool of load-balanced web server
● transparent VPN tunneling ("Network Access"): the TOE provides the termination of
TLS-based VPN connections that allow full tunneling of network traffic between remote
clients and the TOE over encrypted channels
Note: Network access requires the installation of client software on a remote PC that is responsible
for setting up the client side of the encrypted network tunnel. (Either in the form of a stand-alone
Edge client, or in the form of a browser plug-in.) This client software uses cryptographic modules
provided by a user's web browser or, in the case of the Edge client, operating system, and is
therefore not part of the TOE.
Page 16 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
1.5.3.4 Synchronization and failover
BIG-IP supports the creation of redundant system configurations by clustering multiple BIG-IP
devices, i.e., same Part Number, and configuring failover relationships. The evaluated configuration,
in particular, comprises two BIG-IP systems configured in an active/standby failover configuration,
which synchronizes configuration data between the devices, provides state and persistence
monitoring, and allows the standby device to failover if either the active device sends a corresponding
request, or the standby device detects missing heartbeats from the active device, continuing to
enforce security policies for new (and possibly active) connections mediated by the TOE. BIG-IP
uses CMI (Central Management Infrastructure), a proprietary protocol, for the incremental exchange
of configuration data and failover status between TOE instances.
1.5.3.5 Auditing
BIG-IP implements auditing functionality based on standard syslog functionality. This includes the
support of remote audit servers for capturing of audit records. Audit records are generated for all
security-relevant events, such as the use of configuration interfaces by administrators, and the
authentication of traffic.
While the TOE can store audit records locally for cases when an external log server becomes
unavailable, the evaluated configuration assumes that an external log server is used as the primary
means of archiving audit records.
1.5.3.6 TSF management
The TOE allows administrators to configure all relevant aspects of security functionality implemented
by the TSF.
For this purpose, BIG-IP offers multiple interfaces to administrators:
● Configuration utility
The Configuration utility presents a web-based GUI available to administrators via a
dedicated connection that allows administration of most aspects of the TSF. It includes a
Visual Policy Editor for the graphical representation of APM configurations.
● traffic management shell (tmsh)
tmsh is a command line interface available via SSH. It allows administration of all aspects
of the TSF.
● iControl API
The iControl API is a SOAP/XML based interface that allows programmatic access to the
TSF configuration via a dedicated connection.
Additionally, management users can write "iRules®"; scripts used to direct and manipulate the
way that the BIG-IP system manages application traffic. iRules® are written in Tools Command
Language (Tcl), an industry-standard programming language. The iRules scripts would support
additional application level traffic filtering beyond the functionality which is part of the evaluated
configuration.
By default and in the evaluated configuration, remote access to the management interfaces is only
made available on the dedicated management network port of a system.
Other security features associated with management interfaces include:
● session time-outs for Configuration utility and tmsh sessions
Page 17 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
1.5.3.7 Cryptography
The cryptography in the BIG-IP rely on cryptographic mechanisms for their effective implementation.
The cryptographic mechanisms are described in the TOE Summary Specification.
1.5.4 Operational environment support
The TOE relies on its operational environment to support some of the TOE security functions, as
well as to provide a certain degree of protection of the TOE itself.
1.5.4.1 Physical environment
Protection expected from the TOE's physical operational environment includes:
● The device hosting the TOE needs to be protected from unauthorized physical access.
● If the TOE is used to terminate TLS sessions and forward web traffic unprotected, then the
networks used to forward this traffic to its final destination need to be protected
appropriately.
1.5.4.2 Runtime environment
The TOE relies on its runtime environment, i.e. the Linux operating system and hardware hosting
the TOE, for a number of functions:
● Provision of entropy by the Cavium hardware.
● If present and configured to be used, protection of certain cryptographic key material by
a FIPS 140-2 validated cryptographic module. Note that this module was not subject to
evaluation.
● Enforcement of filtering decisions by the switch fabric and HSB.
1.5.4.3 Network environment
In addition to the support provided by the system hosting the TOE, dependencies on external
systems exist. Aspects that an organization using the TOE need to be considerate of in order to
ensure the effectiveness of the TOE include:
● External authentication providers (such as, LDAP) used by the TOE to obtain authentication
decisions need to provide these decisions in a reliable fashion.
● Time servers need to provide an accurate time to the TOE.
● Log servers need to be able to handle the amount of syslog traffic generated by the TOE,
and preserve a proper context.
1.5.4.4 Virtualized environment
The TOE can be deployed on a vCMP system as a guest. This involves defining a guest on the
underlying host system, including the assignment of CPU cores and chassis slots, as well as an IP
address for the management port. The host also manages an overall list of available VLANs that
can be assigned to the guest to operate on.
The TOE in this case is the guest running in the virtualized environment, implementing the same
functionality as described in this Security Target for stand-alone appliances. Any host functionality
and virtualization technology is not subject to this evaluation, and a cooperative environment on
the vCMP platform is assumed.
Page 18 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
1.5.5 TOE boundaries
The following sections describe the physical and logical boundaries of the TOE.
1.5.5.1 Physical boundaries
The TOE is software only as identified in Section 1.2
The evaluated configuration of BIG-IP ADC-AP represents a licensing option with the following
modules present and operational.
● Traffic Management Microkernel (TMM)
● Local Traffic Manager (LTM), and
● Access Policy Manager (APM).
The TOE is available via electronic download from F5's website. Mechanisms to allow consumers
to validate the authenticity and integrity of the download are provided.
Relevant guidance documents for the secure operation of BIG-IP that are part of the TOE are:
● Guidance Supplement: AGD_PRE and AGD_OPE, BIG-IP ADF-Base and ADC-AP Release
11.5.1
● BIG-IP Access Policy Manager Authentication Configuration Guide, Version 11.5
● BIG-IP Access Policy Manager Network Access Configuration Guide, Version 11.5
● Configuration Guide for BIG-IP Access Policy Manager, Version 11.5
● BIG-IP Local Traffic Manager: Concepts, Version 11.5.1
● BIG-IP Local Traffic Manager: Implementations 11.5.1
● BIG-IP Redundant Systems Configuration Guide, Version 11.0
● BIG-IP TMOS: Concepts, Version 11.5
● BIG-IP TMOS: Implementations, Version 11.5.1
● Traffic Management Shell (tmsh) Reference Guide, Version 11.5.1
● BIG-IP TMOS: IP Routing Administration, Version 11.5.1
● External Monitoring of BIG-IP Systems: Implementations, Version 11.5
● BIG-IP Device Service Clustering: Administration, Version 11.5
● vCMP for Appliance Models: Administration, Version 11.5
Physical boundaries between the TOE and its runtime environment are described in section 1.5.2.
In particular:
● The base Linux operating system (TMOS), other than particular applications implementing
TSF, is considered part of the runtime environment. Those parts implementing TSF and
considered part of the TOE, are as follows:
❍ openSSL
❍ openSSH
❍ PAM
❍ SYSLOG
● Hardware is considered part of the runtime environment. This also includes the bitstream
for the HSB. The following TOE and hardware appliance model combinations are covered
by this evaluation:
Page 19 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Software
VCMP?
Model
SKU
LTM+APM w/ AppMode
Y
10000
F5-BIG-LTM-10200V
F5-ADD-BIG-APM-10000
F5-ADD-BIG-MODE
LTM+APM w/ AppMode
Y
10000
F5-BIG-LTM-10200V-F
F5-ADD-BIG-APM-10000
F5-ADD-BIG-MODE
LTM+APM w/ AppMode
Y
10000
F5-BIG-LTM-10200V-S
F5-ADD-BIG-APM-10000
F5-ADD-BIG-MODE
LTM+APM w/ AppMode
Y
B4300
F5-VPR-LTM-C4480-AC
F5-VPR-LTM-B4300
F5-ADD-VPR-APM-C4400
F5-ADD-VPR-VCMP-4480
F5-ADD-BIG-MODE
LTM+APM w/ AppMode
Y
B4300N
F5-VPR-LTM-C4480-DCN
F5-VPR-LTM-B4300N
F5-ADD-VPR-APM-C4400
F5-ADD-VPR-VCMP-4480
F5-ADD-BIG-MODE
LTM+APM w/ AppMode
Y
5000
F5-BIG-LTM-5200V
F5-ADD-BIG-APM-5000
F5-ADD-BIG-MODE
LTM+APM w/ AppMode
Y
7000
F5-BIG-LTM-7200V
F5-ADD-BIG-APM-7000
F5-ADD-BIG-MODE
LTM+APM w/ AppMode
Y
7000
F5-BIG-LTM-7200V-S
F5-ADD-BIG-APM-7000
F5-ADD-BIG-MODE
LTM+APM w/ AppMode
Y
7000
F5-BIG-LTM-7200V-F
F5-ADD-BIG-APM-7000
F5-ADD-BIG-MODE
LTM+APM w/ AppMode
Y
10000
F5-BIG-LTM-10000S
F5-ADD-BIG-APM-10000
F5-ADD-BIG-MODE
LTM+APM w/ AppMode
N
B4300
F5-VPR-LTM-C4480-AC
F5-VPR-LTM-B4300
F5-ADD-VPR-APM-C4400
F5-ADD-BIG-MODE
LTM+APM w/ AppMode
N
B4300N
F5-VPR-LTM-C4480-DCN
F5-VPR-LTM-B4300N
F5-ADD-VPR-APM-C4400
F5-ADD-BIG-MODE
LTM+APM w/ AppMode
N
5000
F5-BIG-LTM-5000S
Page 20 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Software
VCMP?
Model
SKU
F5-ADD-BIG-APM-5000
F5-ADD-BIG-MODE
LTM+APM w/ AppMode
N
7000
F5-BIG-LTM-7000S
F5-ADD-BIG-APM-7000
F5-ADD-BIG-MODE
Table 1: Supported Hardware Models
The following components can be found in the operational environment of the TOE on systems
other than those hosting the TOE:
● Client software (e.g., the BIG-IP Client for TLS VPN connections, endpoint inspection software
executed on clients) is not part of the TOE.
● Authentication servers (such as LDAP), NTP and audit servers, and OCSP servers.
1.5.5.2 Logical boundaries / evaluated configuration
The security functions provided by the TOE are described above. This section discusses specific
configurations that apply to the evaluated configuration, and provides an overview of functionality
that - while present in BIG-IP - is not considered security functionality subject to this evaluation.
The following configuration specifics apply to the evaluated configuration of the TOE:
● Appliance mode is licensed. This results, amongst other effects, in root access to the
underlying system being disabled, and Always-On Management not being able to access
the host.
● A physical network port is dedicated on each device for the exchange of management
traffic with the mirrored device (configuration synchronization, failover monitoring).
● Remote role determination when using LDAP repositories is not supported.
● Local user databases for APM are not supported in the evaluated configuration.
● Dynamic routing is excluded from the evaluated configuration.
● Disabled interfaces:
❍ Shells other than tmsh are disabled. For example, bash and other user-serviceable
shells are excluded.
❍ Management of the TOE via SNMP is disabled.
❍ Management of the TOE via the appliance's LCD display is disabled.
❍ Remote (i.e., SSH) access to the Lights Out / Always On Management capabilities
of the system is disabled.
❍ Serial port console
No security claims have been made on the following functionality of BIG-IP. These functions can be
used in the evaluated configuration, but they are not part of the security functionality that has been
subject to evaluation:
● Client software for establishing connections to BIG-IP, including software performing
client-side checks for APM.
Page 21 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
● Cookies: LTM uses cookies to support a number of traffic management state information.
Cryptographic properties of these cookies (randomness of unique identifiers, encryption
of cookie parameters by BIG-IP) have not been assessed in this evaluation.
● Certificate generation for use in traffic TLS. The certificate generation mechanism in BIG-IP
is primarily provided for administrative and testing purposes. Production environments are
expected to operate their own Public Key Infrastructure and supply certificates for the
TOE's use in public-facing functionality.
● Advanced filtering capabilities in LTM.
● Antivirus and Database security services (external providers). Features are not enabled
unless configured.
● Policy Builder: provides suggestions to be inserted or removed into/from security policy
1.5.6 Security Policy Model
The security policy model for BIG-IP is defined by the security functional requirements in section
6.1. This section summarizes the subjects and objects participating in the individual policies defined
in the SFRs.
1.5.6.1 Administrator Access Control Policy
The following subjects and objects are involved in defining the administrative access to the TOE,
i.e. authentication of administrative users and access control for configuration objects that these
users can manipulate.
Subjects, and their security attributes:
● administrative users
❍ user name
❍ password
❍ role
❍ partition access - a user's partition (or "all")
❍ terminal access - whether the user can configure the TOE via the tmsh
❍ locked - whether the user's account is locked
❍ password expiration counter
❍ number of consecutive failed authentication attempts
Objects, and their security attributes:
● configuration objects
❍ object type
❍ partition
1.5.6.2 APM Connection Policy
The Access Policy Manager information flow policy is implemented based on the following subjects
and information.
Subjects, and their security attributes:
● remote users
❍ user name
Page 22 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
❍ password
❍ presumed IP address
❍ dynamic ACLs
❍ associated access policies, including route domains, static ACLs, and iRules
❍ results of client side checks
● local network IT entities
❍ virtual IP address
Information, and its security attributes:
● network traffic between subjects
❍ network protocol
❍ destination IP address
1.5.6.3 TSF and user data
TSF data:
● information representing the subjects and their security attributes identified in the policies
above
● security attributes of objects and information identified in the policies above
● remote authentication decisions and dynamic ACLs obtained from external authentication
repositories
● OCSP responses from external responders
● audit setings and records
● cryptographic keys, certificates, settings, and other critical security parameters
● failover settings and status of peer systems in the failover configuration
● service settings
● partition settings
● TOE update data
● configuration objects
1
● timeout settings
● Identification and Authentication settings
● TOE component status
● traffic authentication settings
● TOE state data
● system time
User data:
● network traffic mediated by the TSF
1
Configuration objects refer to the objects that define or store multiple types of TSF data used to configure the system
with one operation
Page 23 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
2 CC Conformance Claim
This Security Target is CC Part 2 extended and CC Part 3 conformant, with a claimed Evaluation
Assurance Level 4 (EAL4), augmented by ALC_FLR.3.
Common Criteria [CC] version 3.1 revision 4 is the basis for this conformance claim.
The ST has been developed by using applicable NIAP PP. However, the ST does not claim
conformance.
The relevant NIAP PPs that have been used are [NDPP] Protection Profile for Network Devices,
version 1.1 of 2012-06-08.
Page 24 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
3 Security Problem Definition
3.1 Threat Environment
This section describes the threat model for the TOE and identifies the individual threats that are
assumed to exist in the operational environment of the TOE. Figure 1 supports the understanding
of the attack scenarios discussed here.
The assets to be protected by the TOE are:
● Organizational data hosted on remote systems in physical and virtual network segments
connected directly or indirectly to the TOE (depicted as "server pools" in Figure 1). (The
TOE can be used to protect the assets on those systems from unauthorized exploitation
by mediating network traffic from remote users before it reaches the systems or networks
hosting those assets.)
● The TSF, in particular the availability of the TSF to legitimate users.
The threat agents having an interest in manipulating the TOE and TSF behavior to gain access
to these assets can be categorized as:
● Unauthorized third parties (“attackers”, such as malicious remote users, parties, or external
IT entities) which are unknown to the TOE and its runtime environment. Attackers are
traditionally located outside the organizational environment that the TOE is employed to
protect, but may include organizational insiders, too.
● Authorized users of the TOE (i.e., administrators) who try to manipulate configuration data
that they are not authorized to access. TOE administrators, as well as administrators of
the operational environment, are assumed to be trustworthy, trained and to follow the
instructions provided to them with respect to the secure configuration and operation of
the systems under their responsibility. Hence, only inadvertent attempts to manipulate
the safe operation of the TOE are expected from this community.
The motivation of threat agents is assumed to be commensurate with the assurance level pursued
by this evaluation, i.e., the TOE intends to resist penetration by attackers with an Enhanced-Basic
attack potential.
3.1.1 Threats countered by the TOE
T.ADMIN_ERROR
An administrator may unintentionally install or configure the TOE incorrectly, resulting in
ineffective security mechanisms.
T.RESOURCE_EXHAUSTION
An attacker causes network traffic to be mediated or otherwise handled by the TOE that
exceeds the amount of traffic the TSF can reliably handle, causing unavailability of the TSF
to legitimate users. (In particular, denying authorized administrators the possibility to
administrate the TOE.)
T.TSF_FAILURE
Security mechanisms of the TOE may fail, leading to a compromise of the TSF.
Page 25 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
T.UNDETECTED_ACTIONS
Malicious remote users or external IT entities may take actions that adversely affect the
security of the TOE. These actions may remain undetected and thus their effects cannot be
effectively mitigated.
T.UNAUTHORIZED_ACCESS
A user may gain unauthorized access to the TOE data and TOE executable code. A malicious
user, process, or external IT entity may masquerade as an authorized entity in order to gain
unauthorized access to data or TOE resources. A malicious user, process, or external IT
entity may misrepresent itself as the TOE to obtain identification and authentication data.
T.UNAUTHORIZED_UPDATE
A malicious party attempts to supply the end user with an update to the product that may
compromise the security features of the TOE.
T.USER_DATA_REUSE
User data may be inadvertently sent to a destination not intended by the original sender.
3.2 Assumptions
3.2.1 Environment of use of the TOE
3.2.1.1 Physical
A.PHYSICAL
Physical security, commensurate with the value of the TOE and the data it contains, is
assumed to be provided by the environment.
3.2.1.2 Personnel
A.TRUSTED_ADMIN
TOE Administrators are trusted to follow and apply all administrator guidance in a trusted
manner.
A.TRAINED_ADMIN
TOE Administrators are carefully trained to follow and apply all administrator guidance.
3.2.1.3 Connectivity
A.CONNECTIONS
It is assumed that the TOE is connected to distinct networks in a manner that ensures that
the TOE security policies will be enforced on all applicable network traffic flowing among
the attached networks.
Page 26 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
A.LOGSERVER
It is assumed that the environment is able to receive, store and protect the audit records
generated by the TOE and provides means for the audit analysis, including time correlation.
A.MGMTNET
The management networks used for managing the TOE, synchronizing the fail-over system
and connecting the TOE to NTP servers are private, separate physical networks that are
protected from unauthorized physical and logical access.
A.NO_GENERAL_PURPOSE
It is assumed that there are no general-purpose computing capabilities (e.g., compilers or
user applications) available on the TOE, other than those services necessary for the operation,
administration and support of the TOE.
A.PEERTRUST
Systems that are configured in a device group to synchronize configuration data between
each other for a potential failover must be trustworthy. That means that they are all under
the same administration as the TOE, identically configured and that the same assumptions
can be made about them as for the TOE.
A.KEYS
It is assumed that digital certificates, certificate revocation lists (CRLs) used for certificate
validation and private and public keys used for SSH client authentication generated externally,
meeting the corresponding standards and providing sufficient security strength through the
use of appropriate key lengths and message digest algorithms. It is also assumed that
Administrators verify the integrity and authenticity of digital certificates and key material
before importing them into the TOE, and verifying that certificates are signed using strong
hash algorithms.
A.TIME
It is assumed that a reliable time is provided by the TOE environment to the TOE.
A.LDAP
It is assumed that reliable LDAP, AD and/or OCSP services that are used by the TOE are
provided by the TOE environment.
3.3 Organizational Security Policies
P.ACCESS_BANNER
The TOE shall display an initial banner describing restrictions of use, legal agreements, or
any other appropriate information to which users consent by accessing the TOE.
P.APM-VPN
The APM module of the TOE shall offer to terminate trusted channels from remote VPN clients
to access an organization's internal network resources via public networks (VPN functionality).
Page 27 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
P.FAILOVER
The TOE shall provide failover functionality between redundant devices, maintaining a secure
state during failover.
P.LTM-TRAFFICMGMT
The LTM module shall provide authentication of HTTP traffic, and HTTPS proxy functionality.
Page 28 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
4 Security Objectives
The following sections define the security objectives for the TOE and for the TOE's operational
environment.
4.1 Objectives for the TOE
O.APM-VPN
The TOE will provide an Access Policy Manager (APM) module that allows to terminate
encrypted traffic from remote web browsers and VPN clients in order to allow them to access
content from an organization's internal network.
O.DISPLAY_BANNER
The TOE will display an advisory warning regarding use of the TOE.
O.FAILOVER
The TOE will provide failover capabilities between redundant configurations.
O.LTM-TRAFFICMGMT
The TOE will provide a Local Traffic Management (LTM) module that can authenticate HTTP
traffic, and proxy HTTPS communications by terminating them and forwarding unencrypted
traffic to internal web servers.
O.PROTECTED_COMMUNICATIONS
The TOE will provide protected communication channels for administrators, other parts of
a distributed TOE, and authorized IT entities.
O.RESIDUAL_INFORMATION_CLEARING
The TOE will ensure that any data contained in a protected resource is not available when
the resource is reallocated.
O.RESOURCE_AVAILABILITY
The TOE shall provide mechanisms that mitigate user attempts to exhaust TOE resources
(e.g., persistent storage).
O.SESSION_LOCK
The TOE shall provide mechanisms that mitigate the risk of unattended sessions being
hijacked.
O.SYSTEM_MONITORING
The TOE will provide the capability to generate audit data and send those data to an external
IT entity.
O.TOE_ADMINISTRATION
The TOE will provide mechanisms to ensure that only administrators are able to log in and
configure the TOE, and provide protections for logged-in administrators.
Page 29 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
O.TSF_SELF_TEST
The TOE will provide the capability to test some subset of its security functionality to ensure
it is operating properly.
O.VERIFIABLE_UPDATES
The TOE will provide the capability to help ensure that any updates to the TOE can be verified
by the administrator to be unaltered.
4.2 Objectives for the Operational Environment
OE.CONNECTIONS
TOE administrators will ensure that the TOE is installed in a manner that will allow the TOE
to effectively enforce its policies on network traffic flowing among attached networks.
OE.LOGSERVER
The TOE environment must be able to receive, store and protect the audit records generated
by the TOE and provides means for the audit analysis, including time correlation.
OE.MGMTNET
The management networks used for managing the TOE, synchronizing the fail-over system
and connecting the TOE to NTP servers are private, separate physical networks that are
protected from unauthorized physical and logical access.
OE.NO_GENERAL_PURPOSE
There are no general-purpose computing capabilities (e.g., compilers or user applications)
available on the TOE, other than those services necessary for the operation, administration
and support of the TOE.
OE.PEERTRUST
Systems that are configured in a device group to synchronize configuration data between
each other for a potential failover must be trustworthy. That means that they are all under
the same administration as the TOE, identically configured and that the same assumptions
can be made about them as for the TOE.
OE.KEYS
Digital certificates, certificate revocation lists (CRLs) used for certificate validation and
private and public keys used for SSH client authentication generated externally, meet the
corresponding standards and provide sufficient security strength through the use of
appropriate key lengths and message digest algorithms. Administrators must verify the
integrity and authenticity of digital certificates and key material before importing them into
the TOE, and verify that certificates are signed using strong hash algorithms.
OE.TIME
Reliable time stamp is provided by the TOE environment to the TOE.
Page 30 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
OE.LDAP
Reliable LDAP, AD and/or OCSP services that are used by the TOE are provided by the TOE
environment.
OE.PHYSICAL
Physical security, commensurate with the value of the TOE and the data it contains, is
provided by the environment.
OE.TRUSTED_ADMIN
TOE Administrators are trusted to follow and apply all administrator guidance in a trusted
manner.
OE.TRAINED_ADMIN
TOE Administrators are carefully trained to follow and apply all administrator guidance.
4.3 Security Objectives Rationale
4.3.1 Coverage
The following table provides a mapping of TOE objectives to threats and policies, showing that each
objective counters or enforces at least one threat or policy, respectively.
Threats / OSPs
Objective
P.APM-VPN
O.APM-VPN
P.ACCESS_BANNER
O.DISPLAY_BANNER
P.FAILOVER
O.FAILOVER
P.LTM-TRAFFICMGMT
O.LTM-TRAFFICMGMT
T.UNAUTHORIZED_ACCESS
O.PROTECTED_COMMUNICATIONS
T.USER_DATA_REUSE
O.RESIDUAL_INFORMATION_CLEARING
T.RESOURCE_EXHAUSTION
O.RESOURCE_AVAILABILITY
T.UNAUTHORIZED_ACCESS
O.SESSION_LOCK
T.ADMIN_ERROR
T.UNDETECTED_ACTIONS
O.SYSTEM_MONITORING
T.UNAUTHORIZED_ACCESS
O.TOE_ADMINISTRATION
T.TSF_FAILURE
O.TSF_SELF_TEST
T.UNAUTHORIZED_UPDATE
O.VERIFIABLE_UPDATES
Table 2: Mapping of security objectives to threats and policies
Page 31 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
The following table provides a mapping of the objectives for the Operational Environment to
assumptions, threats and policies, showing that each objective holds, counters or enforces at least
one assumption, threat or policy, respectively.
Assumptions / Threats / OSPs
Objective
A.CONNECTIONS
OE.CONNECTIONS
A.LOGSERVER
OE.LOGSERVER
A.MGMTNET
OE.MGMTNET
A.NO_GENERAL_PURPOSE
OE.NO_GENERAL_PURPOSE
A.PEERTRUST
OE.PEERTRUST
A.KEYS
OE.KEYS
A.TIME
OE.TIME
A.LDAP
OE.LDAP
A.PHYSICAL
OE.PHYSICAL
A.TRUSTED_ADMIN
T.ADMIN_ERROR
OE.TRUSTED_ADMIN
A.TRAINED_ADMIN
T.ADMIN_ERROR
OE.TRAINED_ADMIN
Table 3: Mapping of security objectives for the Operational Environment to assumptions,
threats and policies
4.3.2 Sufficiency
The following rationale provides justification that the security objectives are suitable to counter
each individual threat and that each security objective tracing back to a threat, when achieved,
actually contributes to the removal, diminishing or mitigation of that threat.
Rationale for security objectives
Threat
OE.TRAINED_ADMIN asks for administrators that are trained to follow all
guidance documentation, OE.TRUSTED_ADMIN asks for administrators
that can be trusted to follow all guidance documentation in the first
T.ADMIN_ERROR
place, while O.SYSTEM_MONITORING requires the TOE to implement
accountability mechanisms that would allow the review of administrator
actions, contributing to the detection of incorrect configurations.
The objective O.RESOURCE_AVAILABILITY expects that the TSF will be
able to counter user attempts to exhaust TOE resources.
T.RESOURCE_EXHAUSTION
The need for an implementation of self-tests is defined in
O.TSF_SELF_TEST, countering the threat of failed security mechanisms
leading to compromise.
T.TSF_FAILURE
Page 32 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Rationale for security objectives
Threat
O.SYSTEM_MONITORING defines the objective for auditing mechanisms
to be implemented in the TOE.
T.UNDETECTED_ACTIONS
While O.TOE_ADMINISTRATION requires access control mechanisms to
be in place for administration of the TOE, O.SESSION_LOCK and
O.PROTECTED_COMMUNICATIONS contribute to countering this threat
by requiring mitigation of session hijacking in particular, and the
implementation of protected communication channels in general.
T.UNAUTHORIZED_ACCESS
O.VERIFIABLE_UPDATES requires the implementation of TSF mechanisms
that contribute to verifying the integrity of software updates.
T.UNAUTHORIZED_UPDATE
The threat of the TSF being coerced into disclosing data held in memory
from a previous transaction to users not part of that transaction is
addressed by O.RESIDUAL_INFORMATION_CLEARING asking for a
mechanism to prevent this.
T.USER_DATA_REUSE
Table 4: Sufficiency of objectives countering threats
The following rationale provides justification that the security objectives for the environment are
suitable to cover each individual assumption, that each security objective for the environment that
traces back to an assumption about the environment of use of the TOE, when achieved, actually
contributes to the environment achieving consistency with the assumption, and that if all security
objectives for the environment that trace back to an assumption are achieved, the intended usage
is supported.
Rationale for security objectives
Assumption
This assumption is reflected in OE.PHYSICAL, which contains the same
wording.
A.PHYSICAL
OE.TRUSTED_ADMIN reflects this assumption.
A.TRUSTED_ADMIN
OE.TRAINED_ADMIN reflects this assumption.
A.TRAINED_ADMIN
OE.CONNECTIONS upholds the assumption that the operational
environment is configured in a way that allows the TOE to be the single
point of enforcement for traffic between distinctive networks.
A.CONNECTIONS
OE.LOGSERVER upholds the assumption that the operational environment
is able to receive, store and protect the audit records generated by the
TOE and provides means for the audit analysis, including time correlation.
A.LOGSERVER
OE.MGMTNET upholds the assumption that the operational environment
is configured in a way that the management networks are private,
separate physical networks that is protected from unauthorized physical
and logical access.
A.MGMTNET
A.NO_GENERAL_PURPOSE is implemented by OE.NO_GENERAL_PURPOSE,
which contains the same wording.
A.NO_GENERAL_PURPOSE
Page 33 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Rationale for security objectives
Assumption
A.PEERTRUST is implemented by OE.PEERTRUST, which contains the
same wording.
A.PEERTRUST
A.KEYS is implemented by OE.KEYS, which contains the same wording.
A.KEYS
A.TIME is implemented by OE.TIME, which contains the same wording.
A.TIME
A.LDAP is implemented by OE.LDAP, which contains the same wording.
A.LDAP
Table 5: Sufficiency of objectives holding assumptions
The following rationale provides justification that the security objectives are suitable to cover each
individual organizational security policy (OSP), that each security objective that traces back to an
OSP, when achieved, actually contributes to the implementation of the OSP, and that if all security
objectives that trace back to an OSP are achieved, the OSP is implemented.
Rationale for security objectives
OSP
The policy is implemented by O.DISPLAY_BANNER requiring the TOE to
implement such a banner.
P.ACCESS_BANNER
The policy is implemented by O.APM-VPN, which requires the TOE to
implement VPN functionality.
P.APM-VPN
O.FAILOVER implements the objective for providing failover capabilities
between redundant TOE systems.
P.FAILOVER
This OSP is enforced by O.LTM-TRAFFICMGMT, which requires the TOE
to provide a module implementing the policy's requirements.
P.LTM-TRAFFICMGMT
Table 6: Sufficiency of objectives enforcing Organizational Security Policies
Page 34 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
5 Extended Components Definition
The Security Target draws upon the extended components implicitly defined in [NDPP]. The extended
components from the PP are defined here for completeness.
5.1 Class FAU: Security audit
5.1.1 Security audit event storage (STG)
Management: FAU_STG_EXT.1
The following actions could be considered for the management functions in FMT:
a) Definition of the audit log destination system.
Audit: FAU_STG_EXT.1
There are no audit events foreseen.
5.1.1.1 FAU_STG_EXT.1 - External Audit Trail Storage
No other components.
Hierarchical to:
FAU_GEN.1 Audit data generation
Dependencies:
The TSF shall be able to [selection: transmit the generated audit data to an
external IT entity, receive and store audit data from an external IT entity]
using a trusted channel implementing the [selection: IPSec, SSH, TLS,
TLS/HTTPS] protocol.
FAU_STG_EXT.1.1
Rationale
This extended component extends FAU_STG to transmit and store the generated audit data on a
remote system via a protected channel.
5.2 Class FCS: Cryptographic support
5.2.1 Cryptographic key management (CKM)
Management: FCS_CKM_EXT.4
There are no management activities foreseen.
Audit: FCS_CKM_EXT.4
There are no audit events foreseen.
5.2.1.1 FCS_CKM_EXT.4 - Cryptographic Key Zeroization
No other components.
Hierarchical to:
[FDP_ITC.1 Import of user data without security attributes,
or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation ]
Dependencies:
Page 35 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
The TSF shall zeroize all plaintext secret and private cryptographic keys and CSPs
when no longer required.
FCS_CKM_EXT.4.1
Rationale
This is a specific implementation of FCS_CKM.4 that requires explicit deletion via overwriting with
zeros.
The zeroization applies to each intermediate storage area for plaintext key/cryptographic critical
security parameter (i.e., any storage, such as memory buffers, that is included in the path of such
data) upon the transfer of the key/cryptographic critical security parameter to another location.
5.2.2 Explicit HTTPS specification (HTTPS)
Management: FCS_HTTPS_EXT.1
There are no management activities foreseen.
Audit: FCS_HTTPS_EXT.1
There are no audit events foreseen.
5.2.2.1 FCS_HTTPS_EXT.1 - Explicit HTTPS specification
No other components.
Hierarchical to:
FCS_TLS_EXT.1 Flexible TLS
Dependencies:
The TSF shall implement the HTTPS protocol that complies with RFC 2818.
FCS_HTTPS_EXT
.1.1
The TSF shall implement HTTPS using TLS as specified in FCS_TLS_EXT.1.
FCS_HTTPS_EXT
.1.2
Rationale
This component is used to explicitly require a specific HTTPS implementation.
5.2.3 Random Bit Generation (RBG)
Management: FCS_RBG_EXT.1
There are no management activities foreseen.
Audit: FCS_RBG_EXT.1
There are no audit events foreseen.
5.2.3.1 FCS_RBG_EXT.1 - Random Bit Generation
No other components.
Hierarchical to:
No dependencies
Dependencies:
The TSF shall perform all random bit generation (RBG) services in accordance
with [selection, choose one of: NIST Special Publication 800-90 using
[selection: Hash_DRBG (any), HMAC_DRBG (any), CTR_DRBG (AES),
FCS_RBG_EXT.1.1
Dual_EC_DRBG (any)], FIPS Pub 140-2 Annex C: X9.31 Appendix 2.4 using
Page 36 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
AES] seeded by an entropy source that accumulated entropy from one or both
of [selection: a software-based noise source, a TSF-hardware-based noise
source] .
The deterministic RBG shall be seeded with a minimum of [selection, choose one
of: 128 bits, 256 bits] of entropy at least equal to the greatest bit length of the
keys and authorization factors that it will generate.
FCS_RBG_EXT.1.2
Rationale
This component defines explicit requirements for the random number generator used in the TOE.
5.2.4 Explicit SSH specification (SSH)
Management: FCS_SSH_EXT.1
There are no management activities foreseen.
Audit: FCS_SSH_EXT.1
There are no audit events foreseen.
5.2.4.1 FCS_SSH_EXT.1 - Explicit SSH specification
No other components.
Hierarchical to:
No dependencies
Dependencies:
The TSF shall implement the SSH protocol that complies with RFCs 4251, 4252,
4253, and 4254.
FCS_SSH_EXT.1.1
The TSF shall ensure that the SSH protocol implementation supports the following
authentication methods as described in RFC 4252: public key-based,
password-based.
FCS_SSH_EXT.1.2
The TSF shall ensure that, as described in RFC 4253, packets greater than
[assignment: number of bytes] bytes in an SSH transport connection are
dropped.
FCS_SSH_EXT.1.3
The TSF shall ensure that the SSH transport implementation uses the following
encryption algorithms: AES-CBC-128, AES-CBC-256, [selection:
AEAD_AES_128_GCM, AEAD_AES_256_GCM, no other algorithms].
FCS_SSH_EXT.1.4
The TSF shall ensure that the SSH transport implementation uses SSH_RSA and
[selection: PGP-SIGN-RSA, PGP-SIGN-DSS, no other public key
algorithms]as its public key algorithm(s).
FCS_SSH_EXT.1.5
The TSF shall ensure that data integrity algorithms used in SSH transport
connection is [selection: hmac-sha1, hmac-sha1-96, hmac-md5,
hmac-md5-96].
FCS_SSH_EXT.1.6
The TSF shall ensure that diffie-hellman-group14-sha1 is the only allowed key
exchange method used for the SSH protocol.
FCS_SSH_EXT.1.7
Rationale
Page 37 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
This component is used to explicitly require a specific SSH implementation.
5.2.5 Explicit TLS specification (TLS)
Management: FCS_TLS_EXT.1
The following actions could be considered for the management functions in FMT:
a) Selection of TLS versions and/or ciphersuites, if available to administrators.
Audit: FCS_TLS_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in
the PP/ST:
a) Minimal: Failure to establish a TLS session, the reason for failure, and the non-TOE endpoint
of connection (IP address).
b) Basic: Establishment/termination of a TLS session, and the non-TOE endpoint of connection
(IP address).
5.2.5.1 FCS_TLS_EXT.1 - Flexible TLS
No other components.
Hierarchical to:
No dependencies
Dependencies:
The TSF shall implement one or more of the following protocols: [selection: TLS
1.0 (RFC 2246), TLS 1.1 (RFC 4346), TLS 1.2 (RFC 5246)].
FCS_TLS_EXT.1.1
The TSF shall support the following ciphersuites: [assignment: TLS cipher suites
defined in RFC standards].
FCS_TLS_EXT.1.2
Rationale
This SFR specifies the minimal requirements for TLS. It is a more flexible implementation of the
NDPP-defined component FCS_TLS_EXT.1. BIG-IP modules implement TLS tunnel functionality for
a large number of infrastructure varieties that consumers may need to support, and hence, require
more flexibility when it comes to protocol versions and cipher suites.
5.3 Class FIA: Identification and Authentication
5.3.1 Password Management (PMG)
Management: FIA_PMG_EXT.1
The following actions could be considered for the management functions in FMT:
a) Specification of password composition.
Audit: FIA_PMG_EXT.1
There are no audit events foreseen.
5.3.1.1 FIA_PMG_EXT.1 - Password Management
No other components.
Hierarchical to:
No dependencies
Dependencies:
Page 38 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
The TSF shall provide the following password management capabilities for
administrative passwords:
FIA_PMG_EXT.1
1. Passwords shall be able to be composed of any combination of upper and
lower case letters, numbers, and the following special characters: [selection:
“!”, “@”, “#”, “$”, “%”,, “^”, “&”, “*”, “(“, “)”, [assignment: other
characters]];
2. Minimum password length shall settable by the Security Administrator, and
support passwords of 15 characters or greater;
Rationale
The NDPP-defined family PMG provides a password quality specification.
5.3.2 User Identification and Authentication (UAU)
Management: FIA_UAU_EXT.2
The following actions could be considered for the management functions in FMT:
a) Specification of password composition.
Audit: FIA_UAU_EXT.2
There are no audit events foreseen.
5.3.2.1 FIA_UAU_EXT.2 - Password-based Authentication Mechanism
No other components.
Hierarchical to:
No dependencies
Dependencies:
The TSF shall provide a local password-based authentication mechanism,
[selection: [assignment: other authentication mechanism(s)], none] to
perform administrative user authentication.
FIA_UAU_EXT.2.1
Rationale
The NDPP-defined component FIA_UAU_EXT.2 provides the specification of authentication
mechanisms while mandating at least password based authentication.
5.3.3 User Identification and Authentication (UIA)
Management: FIA_UIA_EXT.1
The following actions could be considered for the management functions in FMT:
a) Specification of the banner for FTPA_TAB.1
Audit: FIA_UIA_EXT.1
There are no audit events foreseen.
5.3.3.1 FIA_UIA_EXT.1 - User Identification and Authentication
No other components.
Hierarchical to:
FTA_TAB.1 Default TOE access banners
Dependencies:
Page 39 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
The TSF shall allow the following actions prior to requiring the non-TOE entity to
initiate the identification and authentication process:
FIA_UIA_EXT.1.1
a) Display the warning banner in accordance with FTA_TAB.1;
b) [selection: no other actions, [assignment: list of services, actions
performed by the TSF in response to non-TOE requests]].
The TSF shall require each administrative user to be successfully identified and
authenticated before allowing any other TSF-mediated actions on behalf of that
administrative user.
FIA_UIA_EXT.1.2
Rationale
The NDPP-defined component FIA_UIU_EXT.1 describes the TOE behavior before authentication.
5.4 Class FPT: Protection of the TSF
5.4.1 Protection of Administrator Passwords (APW)
Management: FPT_APW_EXT.1
There are no management activities foreseen.
Audit: FPT_APW_EXT.1
There are no audit events foreseen.
5.4.1.1 FPT_APW_EXT.1 - Protection of Administrator Passwords
No other components.
Hierarchical to:
No dependencies
Dependencies:
The TSF shall store passwords in non-plaintext form.
FPT_APW_EXT.1.1
The TSF shall prevent the reading of plaintext passwords.
FPT_APW_EXT.1.2
Rationale
The NDPP-defined component FPT_APW explicitly defines requirements for protected password
storage.
5.4.2 Protection of TSF Data (for reading of all symmetric keys)
(SKP)
Management: FPT_SKP_EXT.1
There are no management activities foreseen.
Audit: FPT_SKP_EXT.1
There are no audit events foreseen.
5.4.2.1 FPT_SKP_EXT.1 - Protection of TSF Data (for reading of all
symmetric keys)
No other components.
Hierarchical to:
Page 40 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
No dependencies
Dependencies:
The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private
keys.
FPT_SKP_EXT.1.1
Rationale
The NDPP-defined component FPT_SKP explicitly defines requirements for protection of symmetric
keys.
5.4.3 TSF Testing (TST)
Management: FPT_TST_EXT.1
There are no management activities foreseen.
Audit: FPT_TST_EXT.1
There are no audit events foreseen.
5.4.3.1 FPT_TST_EXT.1 - TSF Testing
No other components.
Hierarchical to:
No dependencies
Dependencies:
The TSF shall run a suite of self tests during initial start-up (on power on) to
demonstrate the correct operation of the TSF.
FPT_TST_EXT.1.1
Rationale
The NDPP-defined component FPT_TST_EXT explicitly defines requirements for self test of the TSF.
5.4.4 Trusted Update (TUD)
Management: FPT_TUD_EXT.1
There are no management activities foreseen.
Audit: FPT_TUD_EXT.1
There are no audit events foreseen.
5.4.4.1 FPT_TUD_EXT.1 - Trusted Update
No other components.
Hierarchical to:
No dependencies
Dependencies:
The TSF shall provide authorized administrators the ability to query the current
version of the TOE firmware/software.
FPT_TUD_EXT.1.1
The TSF shall provide authorized administrators the ability to initiate updates to
TOE firmware/software.
FPT_TUD_EXT.1.2
The TSF shall provide a means to verify firmware/software updates to the TOE
using a [selection: digital signature mechanism, published hash] prior to
installing those updates.
FPT_TUD_EXT.1.3
Page 41 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Rationale
The NDPP-defined component FPT_TUD explicitly defines requirements for update verification.
Page 42 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
6 Security Requirements
6.1 TOE Security Functional Requirements
This ST identifies assignments and selections in bold typeface. Refinements are identified in
strike-through and italyitalics. Iterations performed by the ST author are identified by adding a dash
(-) and IDENTIFIER to the SFR reference, while iterations derived from the PPs continue to carry a
sequential number in parentheses (2) added to the SFR reference.
The following table shows the SFRs for the TOE, and the operations performed on the components
according to CC part 1: iteration (Iter.), refinement (Ref.), assignment (Ass.) and selection (Sel.).
Operations
Source
Base
security
functional
component
Security functional requirement
Security
functional
group Sel.
Ass.
Ref.
Iter.
Yes
Yes
Yes
No
CC Part 2
FAU_GEN.1 Audit Data Generation
Security audit
No
No
No
No
CC Part 2
FAU_GEN.2 User Identity Association
Yes
No
No
No
ECD
FAU_STG_EXT.1 External Audit Trail
Storage
No
Yes
No
Yes
CC Part 2
FCS_CKM.1
FCS_CKM.1-SSH Cryptographic Key
Generation (SSH host key)
Cryptographic
support
Yes
Yes
Yes
Yes
CC Part 2
FCS_CKM.1
FCS_CKM.1-RSA Cryptographic Key
Generation (for asymmetric keys)
No
No
No
No
ECD
FCS_CKM_EXT.4 Cryptographic Key
Zeroization
No
Yes
No
Yes
CC Part 2
FCS_COP.1
FCS_COP.1(1) Cryptographic
Operation (for cryptographic
signature)
No
Yes
Yes
Yes
CC Part 2
FCS_COP.1
FCS_COP.1(2) Cryptographic
Operation (for cryptographic
hashing)
No
Yes
Yes
Yes
CC Part 2
FCS_COP.1
FCS_COP.1(3) Cryptographic
Operation (for keyed-hash message
authentication)
No
No
Yes
No
ECD
FCS_HTTPS_EXT.1 Explicit: HTTPS
Yes
No
Yes
No
ECD
FCS_RBG_EXT.1 Extended:
Cryptographic Operation (Random
Bit Generation)
Yes
Yes
Yes
No
ECD
FCS_SSH_EXT.1 Explicit: SSH
Yes
Yes
Yes
No
ECD
FCS_TLS_EXT.1 Traffic TLS
No
Yes
No
No
CC Part 2
FDP_ACC.1 Subset access control
User data
protection
Page 43 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Operations
Source
Base
security
functional
component
Security functional requirement
Security
functional
group Sel.
Ass.
Ref.
Iter.
No
Yes
No
No
CC Part 2
FDP_ACF.1 Security attribute based
access control
No
Yes
No
Yes
CC Part 2
FDP_IFC.1
FDP_IFC.1-APM Subset information
flow control
No
Yes
No
Yes
CC Part 2
FDP_IFF.1
FDP_IFF.1-APM Simple security
attributes
No
Yes
No
No
CC Part 2
FDP_ITC.1 Import of user data
without security attributes
Yes
No
No
No
CC Part 2
FDP_RIP.2 Full Residual Information
Protection
Yes
Yes
No
No
CC Part 2
FDP_UCT.1 Inter-TSF user data
confidentiality transfer protection
Yes
Yes
No
No
CC Part 2
FDP_UIT.1 Inter-TSF user data
integrity transfer protection
Yes
Yes
No
No
CC Part 2
FIA_AFL.1 Authentication failure
handling
Identification and
authentication
No
Yes
Yes
No
CC Part 2
FIA_ATD.1 User attribute definition
Yes
Yes
Yes
No
ECD
FIA_PMG_EXT.1 Password
Management
Yes
No
No
No
ECD
FIA_UAU_EXT.2 Password-based
Authentication Mechanism
No
Yes
Yes
Yes
CC Part 2
FIA_UAU.5
FIA_UAU.5-APM Multiple
authentication mechanisms
No
Yes
Yes
Yes
CC Part 2
FIA_UAU.5
FIA_UAU.5-LTM Traffic
authentication mechanisms
No
Yes
Yes
No
CC Part 2
FIA_UAU.7 Protected authentication
feedback
Yes
No
No
No
ECD
FIA_UIA_EXT.1 User Identification
and Authentication
Yes
Yes
No
No
CC Part 2
FMT_MSA.1 Management of security
attributes
Security
management
Yes
Yes
No
Yes
CC Part 2
FMT_MSA.3
FMT_MSA.3-APM Static attribute
initialisation
Yes
Yes
No
Yes
CC Part 2
FMT_MSA.3
FMT_MSA.3-BASE Static attribute
initialisation
Page 44 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Operations
Source
Base
security
functional
component
Security functional requirement
Security
functional
group Sel.
Ass.
Ref.
Iter.
Yes
Yes
No
No
CC Part 2
FMT_MTD.1 Management of TSF
data (for general TSF data)
No
Yes
No
No
CC Part 2
FMT_SMF.1 Specification of
Management Functions
No
Yes
No
No
CC Part 2
FMT_SMR.1 Security roles
No
No
No
No
ECD
FPT_APW_EXT.1 Protection of
Administrator Passwords
Protection of the
TSF
No
Yes
No
No
CC Part 2
FPT_FLS.1 Failure with preservation
of secure state
No
No
No
No
ECD
FPT_SKP_EXT.1 Protection of TSF
Data (for reading of all symmetric
keys)
No
Yes
Yes
No
CC Part 2
FPT_TDC.1 Inter-TSF basic TSF data
consistency
No
No
No
No
ECD
FPT_TST_EXT.1 TSF testing
Yes
No
No
No
ECD
FPT_TUD_EXT.1 Extended: Trusted
Update
Yes
Yes
No
No
CC Part 2
FRU_RSA.1 Maximum Quotas
Resource
utilisation
No
Yes
Yes
No
CC Part 2
FTA_SSL.3 TSF-initiated Termination
TOE access
No
No
Yes
No
CC Part 2
FTA_SSL.4 User-initiated termination
No
No
Yes
No
CC Part 2
FTA_TAB.1 Default TOE Access
Banners
Yes
Yes
No
No
CC Part 2
FTP_ITC.1 Inter-TSF trusted channel
Trusted
path/channel of
the TSF Yes
Yes
Yes
No
CC Part 2
FTP_TRP.1 Trusted Path
Table 7: SFRs for the TOE
6.1.1 Security audit
6.1.1.1 Audit Data Generation (FAU_GEN.1)
The TSF shall be able to generate an audit record of the following auditable events:
FAU_GEN.1.1
a) Start-up and shutdown of the audit functions;
b) All auditable events for the not specified level of audit; and
c) All administrative actions;
Page 45 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
d) Specifically defined auditable events listed in Table 8.
The TSF shall record within each audit record at least the following information:
FAU_GEN.1.2
a) Date and time of the event, type of event, subject identity (if applicable),
and the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the
functional components included in the PP/ST, information specified in
column three of Table 8.
Additional Audit Record Contents
Auditable Events
Requirement
None.
FAU_GEN.1
None.
FAU_GEN.2
None.
FAU_STG_EXT.1
None.
FCS_CKM.1-SSH
None.
FCS_CKM.1-RSA
None.
FCS_CKM_EXT.4
None.
FCS_COP.1(1)
None.
FCS_COP.1(2)
None.
FCS_COP.1(3)
Reason for failure.
Non-TOE endpoint of connection (IP
address) for both successes and failures.
Failure to establish a HTTPS session.
Establishment/Termination of a HTTPS
session.
FCS_HTTPS_EXT.1
None.
FCS_RBG_EXT.1
Reason for failure.
Non-TOE endpoint of connection (IP
address) for both successes and failures.
Failure to establish an SSH session.
Establishment/Termination of an SSH
session.
FCS_SSH_EXT.1
Reason for failure.
Non-TOE endpoint of connection (IP
address) for both successes and failures.
Failure to establish a TLS session.
Establishment/Termination of a TLS
session.
FCS_TLS_EXT.1
None.
FDP_ACC.1
No additional information.
All requests to perform an operation on an
object covered by the SFP.
FDP_ACF.1
None.
FDP_RIP.2
Identification of the user of data exchange
mechanism.
Any use of data exchange mechanisms
(truseted channel/path).
FDP_UCT.1
Identification of the user of data exchange
mechanism.
Any use of data exchange mechanisms
(truseted channel/path).
FDP_UIT.1
Page 46 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Additional Audit Record Contents
Auditable Events
Requirement
No additional information.
The reaching of the threshold for the
unsuccessful authentication attempts and
the actions (e.g. disabling of a terminal)
FIA_AFL.1
taken and the subsequent, if appropriate,
restoration to the normal state (e.g.
re-enabling of a terminal).
None.
FIA_ATD.1
None.
FIA_PMG_EXT.1
Origin of the attempt (e.g., IP address).
All use of the authentication mechanism.
FIA_UAU_EXT.2
None.
FIA_UAU.5-LTM
None.
FIA_UAU.7
Provided user identity, origin of the attempt
(e.g., IP address).
All use of the identification and
authentication mechanism.
FIA_UIA_EXT.1
None.
FMT_MSA.1
None.
FMT_MSA.3-BASE
None.
FMT_MTD.1
No additional information.
None.Use of the management functions.
FMT_SMF.1
None.
FMT_SMR.1
None.
FPT_APW_EXT.1
No additional information.
Failure of the TSF.
FPT_FLS.1
None.
FPT_SKP_EXT.1
None.
FPT_TST_EXT.1
No additional information.
Initiation of update.
FPT_TUD_EXT.1
None.
FRU_RSA.1
No additional information.
The termination of a interactive session by
the session locking mechanism.
FTA_SSL.3
No additional information.
The termination of an interactive session.
FTA_SSL.4
None.
FTA_TAB.1
Identification of the initiator and target of
failed trusted channels establishment
attempt.
Initiation of the trusted channel.
Termination of the trusted channel.
Failure of the trusted channel functions.
FTP_ITC.1
Page 47 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Additional Audit Record Contents
Auditable Events
Requirement
Identification of the claimed user identity.
Initiation of the trusted channelpath
functions.
Termination of the trusted channelpath
functions.
Failures of the trusted path functions.
FTP_TRP.1
Table 8: Auditable Events
ST Application Note: Changes / additions to the auditable events and audit record contents
derived from NDPP and FWPP have been marked in italics.
6.1.1.2 User Identity Association (FAU_GEN.2)
For audit events resulting from actions of identified users, the TSF shall be able
to associate each auditable event with the identity of the user that caused the
event.
FAU_GEN.2.1
6.1.1.3 External Audit Trail Storage (FAU_STG_EXT.1)
The TSF shall be able to transmit the generated audit data to an external
IT entity using a trusted channel implementing the TLS protocol.
FAU_STG_EXT.1.1
6.1.2 Cryptographic support
6.1.2.1 Cryptographic Key Generation (SSH host key) (FCS_CKM.1-SSH)
The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm RSA key generation using probable
primes with a specified random number generator FCS_RBG_EXT.1 and
FCS_CKM.1.1
specified cryptographic key sizes 1024-bit or higher RSA key sizes that meet
the following: FIPS 186-2, A.2.1 for Miller Rabin probabilistic primality
tests.
ST Application Note: The key is generated when the SSH server is first started.
6.1.2.2 Cryptographic Key Generation (for asymmetric keys)
(FCS_CKM.1-RSA)
The TSF shall generate asymmetric cryptographic keys used for key establishment
in accordance with a specified cryptographic key generation algorithm
FCS_CKM.1.1-
RSA
a) NIST Special Publication 800-56A, “Recommendation for Pair-Wise
Key Establishment Schemes Using Discrete Logarithm Cryptography”
for finite field-based key establishment schemes;
Page 48 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
b) NIST Special Publication 800-56A, “Recommendation for Pair-Wise
Key Establishment Schemes Using Discrete Logarithm Cryptography”
for elliptic curve-based key establishment schemes and
implementing “NIST curves” P-256 (as defined in FIPS PUB 186-3,
“Digital Signature Standard”)
c) NIST Special Publication 800-56B, “Recommendation for Pair-Wise
Key Establishment Schemes Using Integer Factorization
Cryptography” for RSA-based key establishment schemes
and specified cryptographic key sizes equivalent to, or greater than, a
symmetric key strength of 112 bits.
Application Note: Item a applies only to SSH, and items b and c only to TLS. Note that for item
c, the RSA key generation is done as part of the TOE environment.
6.1.2.3 Cryptographic Key Zeroization (FCS_CKM_EXT.4)
The TSF shall zeroize all plaintext secret and private cryptographic keys and CSPs
when no longer required.
FCS_CKM_EXT.4.1
NDPP Application Note: "Cryptographic Critical Security Parameters" are defined in FIPS 140-2
as "security-related information (e.g., secret and private cryptographic keys, and authentication
data such as passwords and PINs) whose disclosure or modification can compromise the security
of a cryptographic module."
NDPP Application Note: The zeroization indicated above applies to each intermediate storage
area for plaintext key/cryptographic critical security parameter (i.e., any storage, such as memory
buffers, that is included in the path of such data) upon the transfer of the key/cryptographic critical
security parameter to another location.
6.1.2.4 Cryptographic Operation (for cryptographic signature)
(FCS_COP.1(1))
The TSF shall perform cryptographic signature services in accordance with
a specified cryptographic algorithm
FCS_COP.1.1(1)
a) RSA Digital Signature Algorithm (rDSA)
b) Elliptic Curve Digital Signature Algorithm (ECDSA)
and cryptographic key sizes
a) (modulus) of 2048 bits or greater,
b) 256 bits or greater]
that meet the following:
a) RSA: FIPS PUB 186-3, “Digital Signature Standard”
b) ECDSA NIST curve P-256 (as defined in FIPS PUB 186-3, “Digital
Signature Standard”).
Page 49 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
6.1.2.5 Cryptographic Operation (for cryptographic hashing)
(FCS_COP.1(2))
The TSF shall perform cryptographic hashing services in accordance with a
specified cryptographic algorithm SHA-1, SHA-256, SHA-384 and cryptographic
keymessages digest sizes 160, 256, 384 bits that meet the following: FIPS
Pub 180-3, "Secure Hash Standard" [FIPSPUB180-3].
FCS_COP.1.1(2)
6.1.2.6 Cryptographic Operation (for keyed-hash message authentication)
(FCS_COP.1(3))
The TSF shall perform keyed-hash message authentication in accordance
with a specified cryptographic algorithm HMAC-SHA-1, HMAC-SHA-256,
HMAC-SHA-384 and cryptographic key size 160, 256, 384 bits, and message
FCS_COP.1.1(3)
digest sizes 160 bits that meet the following: FIPS Pub 198-1, "The Keyed-Hash
Message Authentication Code" [FIPSPUB198-1], and FIPS Pub 180-3,
"Secure Hash Standard" [FIPSPUB180-3].
ST Application Note: This SFR applies to both the hashes generated in TLS (cf. [RFC4346] section
6.3) and in SSH (cf. [RFC4253] section 6.4).
6.1.2.7 Explicit: HTTPS (FCS_HTTPS_EXT.1)
The TSF shall implement the HTTPS protocol that complies with [RFC2818].
FCS_HTTPS_EXT
.1.1
The TSF shall implement HTTPS using TLS as specified in FCS_TLS_EXT.1.
FCS_HTTPS_EXT
.1.2
6.1.2.8 Extended: Cryptographic Operation (Random Bit Generation)
(FCS_RBG_EXT.1)
The TSF shall perform all random bit generation (RBG) services in accordance
with NIST Special Publication 800-90[NIST800-90A] using CTR_DRBG
(AES) seeded by an entropy source that accumulated entropy from a
software-based noise source.
FCS_RBG_EXT.1.1
The deterministic RBG shall be seeded with a minimum of 256 bits of entropy
at least equal to the greatest bit length of the keys and authorization factors that
it will generate.
FCS_RBG_EXT.1.2
ST Application Note: The TOE actually uses entropy that is originally generated by hardware in
a crypto module provided by the underlying operational environment. However, it is acquired from
that module via a software interface and further processed by TSF software, making the selection
performed more accurate than selecting "a TSF-hardware-based noise source" as offered by NDPP.
ST Application Note:
This application note rephrases the RNG requirement using AIS20 [AIS_20].
FCS_RNG.1.1 The TSF shall provide a deterministic random number generator using the CTR_DRBG
with AES 256 bit core specified in [NIST800-90A] that implements:
a) DRG2.1: If initialized with a random seed using /dev/random as random source, the internal state
of the RNG shall have a minimum entropy of 48 bits.
b) DRG2.2: The DRNG provides forward secrecy.
Page 50 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
c) DRG2.3: The DRNG provides backward secrecy.
FCS_RNG.1.2 The TSF shall provide random numbers that meet:
a) DRG.2.4: The RNG initialized with a random seed holding 96 bits of entropy generates output
for which 2**25 strings of length 80 bits are mutually different with probability of less than 1-2**-10.
b) DRG.2.5: The test suite A and no other test suite cannot distinguish the random numbers from
output sequences of ideal RNGs.
6.1.2.9 Explicit: SSH (FCS_SSH_EXT.1)
The TSF shall implement the SSH protocol that complies with RFCs 4251, 4252,
4253, and 4254[RFC4251], [RFC4252], [RFC4253], and [RFC4254].
FCS_SSH_EXT.1.1
The TSF shall ensure that the SSH protocol implementation supports the following
authentication methods as described in [RFC4252]: public-key based,
password-based.
FCS_SSH_EXT.1.2
The TSF shall ensure that, as described in [RFC4253], packets greater than
(256*1024) bytes in an SSH transport connection are dropped.
FCS_SSH_EXT.1.3
The TSF shall ensure that the SSH transport implementation uses the following
encryption algorithms: AES-CBC-128, AES-CBC-256 no other algorithms.
FCS_SSH_EXT.1.4
The TSF shall ensure that the SSH transport implementation uses SSH_RSA and
no other public key algorithms as its public key algorithm(s).
FCS_SSH_EXT.1.5
The TSF shall ensure that data integrity algorithms used in SSH transport
connection is hmac-sha1.
FCS_SSH_EXT.1.6
The TSF shall ensure that diffie-hellman-group14-sha1 is the only allowed key
exchange method used for the SSH protocol.
FCS_SSH_EXT.1.7
6.1.2.10 Traffic TLS (FCS_TLS_EXT.1)
The TSF shall implement the following protocols: TLS 1.1 ([RFC4346]), TLS 1.2
([RFC5246]☝).
FCS_TLS_EXT.1.1
ST Application Note: While TLS 1.0 has been removed from the security claims, the user still can
select it, subject to the warnings in the guidance.
The TSF shall support the following ciphersuites:
FCS_TLS_EXT.1.2
1. TLS_RSA_WITH_AES_128_CBC_SHA
2. TLS_RSA_WITH_AES_256_CBC_SHA
3. TLS_RSA_WITH_AES_128_CBC_SHA256
4. TLS_RSA_WITH_AES_256_CBC_SHA256
5. TLS_RSA_WITH_AES_128_GCM_SHA256
6. TLS_RSA_WITH_AES_256_GCM_SHA384
7. TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
8. TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
9. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
10. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
11. TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
12. TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
Page 51 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
13. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
14. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
15. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
16. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
17. TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
18. TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
19. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
20. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
21. TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
22. TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
23. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
24. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
25. TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
26. TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
27. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
28. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
29. TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
30. TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
6.1.3 User data protection
6.1.3.1 Subset access control (FDP_ACC.1)
The TSF shall enforce the Administrator Access Control Policy on
FDP_ACC.1.1
a) subjects: administrative users
b) objects: configuration objects
c) operations among subjects and objects:
1. write (create, modify, enable, disable, delete, view)
2. update (modify, enable, disable, view)
3. enable/disable (enable, disable, view)
4. read (view)
.
6.1.3.2 Security attribute based access control (FDP_ACF.1)
The TSF shall enforce the Administrator Access Control Policy to objects
based on the following:
FDP_ACF.1.1
a) subjects: user with the following attributes:
1. role
2. partition access
b) objects: partition with the following attributes:
1. partition type common or specific
Page 52 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
.
ST Application Note: Partitions are either common or specific. Access to the common partition
is determined by the administrative role only, while access to specific partitions are determined by
the partition access right for each specific user.
The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed:
FDP_ACF.1.2
a) the operation a subject requests on an object will be performed:
1. if the object is in a partition that matches the subject's partition
access; and
2. if the type of operation matches the type of operations granted
to the subject by its role for the type of object the operation is
requested on (as defined for individual roles in the TSS in table
13).
The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules:
FDP_ACF.1.3
a) any operations requested by subjects with the Administrator role
are always performed
b) any operations requested by subjects with the User Manager role
on objects in the Common partition, other than user account objects
associated with the Administrator role, are always performed
c) read operations requested by subjects with a role other than No
Access on objects in the Common partition, are always performed
.
The TSF shall explicitly deny access of subjects to objects based on the following
additional rules: none.
FDP_ACF.1.4
6.1.3.3 Subset information flow control (FDP_IFC.1-APM)
The TSF shall enforce the APM Connection Policy on
FDP_IFC.1.1-APM
a) subjects: remote users, local network IT entities
b) information: network traffic between subjects moderated by the
TOE
c) operations: forwarding of information between remote users and
local network IT entities
.
6.1.3.4 Simple security attributes (FDP_IFF.1-APM)
The TSF shall enforce the APM Connection Policy based on the following types
of subject and information security attributes:
FDP_IFF.1.1-APM
a) remote users
1. user name
2. password
3. presumed IP address
4. dynamic ACLs
Page 53 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
5. access policies, including associated route domains, static ACLs,
and iRules
6. results of client side checks
b) local network IT entities
1. virtual IP address
c) network traffic packets
1. network protocol
2. IP address of the local network IT entity
.
The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules hold:
FDP_IFF.1.2-APM
a) forwarding of a network traffic packet between the remote user
and a local network IT entity is determined based on an access policy
that derives forwarding decisions based on an administrator-defined
combination of the following aspects:
1. result(s) of authenticating the remote user's user name by
selecting an authentication mechanism specified in
FIA_UAU.5-APM
2. route domains configured to determine the local network IT
entities (identified by their presumed IP addresses / networks)
that the remote user is permitted to communicate with
3. static ACLs associated with the access policy, and dynamic ACLs
obtained from a user repository via FPT_TDC.1, containing one
or more access control entities that specify forwarding rules
based on matching one or more of the following content types
of the network traffic packet:
i. presumed IP address / network of the remote user
ii. presumed IP address / network of the local network IT entity
iii. network and transport layer protocols
iv. HTTP URI elements as defined in RFC 2616 as defined in
[RFC2616]
4. administrator-specified rule logic (iRules)
5. results of client side checks as reported by clients
.
The TSF shall enforce the forwarding of a remote user's user name and
password to a local network IT entity only if specified in the access policy
that applies to the related network traffic packets .
FDP_IFF.1.3-APM
The TSF shall explicitly authorise an information flow based on the following rules:
no additional rules .
FDP_IFF.1.4-APM
The TSF shall explicitly deny an information flow based on the following rules:
FDP_IFF.1.5-APM
a) traffic inactivity
.
Page 54 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
ST Application Note: "Client side checks" are obtained from third-party software that is deployed
by BIG-IP to remote clients in order to, for example, check for the existence of an anti-virus solution
or a personal firewall. This software is not part of the TOE; however, if specified by administrators,
the TSF can consider results reported by this software in their access decision.
6.1.3.5 Import of user data without security attributes (FDP_ITC.1)
The TSF shall enforce the Administrator Access Control Policy when importing
user data, controlled under the SFP, from outside of the TOE.
FDP_ITC.1.1
The TSF shall ignore any security attributes associated with the user data when
imported from outside the TOE.
FDP_ITC.1.2
The TSF shall enforce the following rules when importing user data controlled
under the SFP from outside the TOE: no additional importation control rules.
FDP_ITC.1.3
ST Application Note: This SFR addresses the import of certificates for use in traffic TLS connections.
Only administrative users with the role of Administrator or Certificate Manager can import TLS
certificates.
6.1.3.6 Full Residual Information Protection (FDP_RIP.2)
The TSF shall ensure that any previous information content of a resource is made
unavailable upon the allocation of the resource to all objects.
FDP_RIP.2.1
NDPP Application Note: “Resources” in the context of this requirement are network packets
being sent through (as opposed to “to”, as is the case when a security administrator connects to
the TOE) the TOE. The concern is that once a network packet is sent, the buffer or memory area
used by the packet still contains data from that packet, and that if that buffer is re-used, those data
might remain and make their way into a new packet.
6.1.3.7 Inter-TSF user data confidentiality transfer protection (FDP_UCT.1)
The TSF shall enforce the Administrator Access Control Policy to transmit,
receive user data in a manner protected from unauthorised disclosure.
FDP_UCT.1.1
ST Application Note: This SFR applies to the SSH access.
6.1.3.8 Inter-TSF user data integrity transfer protection (FDP_UIT.1)
The TSF shall enforce the Administrator Access Control Policy to transmit,
receive user data in a manner protected from modification, deletion,
insertion, replay errors.
FDP_UIT.1.1
The TSF shall be able to determine on receipt of user data, whether modification,
deletion, insertion, replay has occurred.
FDP_UIT.1.2
ST Application Note:: This SFR applies to the SSH access.
Page 55 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
6.1.4 Identification and authentication
6.1.4.1 Authentication failure handling (FIA_AFL.1)
The TSF shall detect when an administrator configurable positive integer
within 1 - 10 unsuccessful authentication attempts occur related to
password-based authentication of an individual administrative user
account through any of the administrative interfaces.
FIA_AFL.1.1
When the defined number of unsuccessful authentication attempts has been met,
the TSF shall disable the user account.
FIA_AFL.1.2
ST Application Note: Only an administrative users with the role of Administrator can specify the
number of unsuccessful authentication attempts.
6.1.4.2 User attribute definition (FIA_ATD.1)
The TSF shall maintain the following list of security attributes belonging to
individual administrative users:
FIA_ATD.1.1
● user name
● password
● role
● partition access
● terminal access
● locked
● password expiration date.
6.1.4.3 Password Management (FIA_PMG_EXT.1)
The TSF shall provide the following password management capabilities for
administrative passwords:
FIA_PMG_EXT.1.1
a) Passwords shall be able to be composed of any combination of upper and
lower case letters, numbers, and special characters: any character from
the following:
● `~!@#$%^&*()-_+=[]{};’:”,./<>?|\
b) Minimum password length shall be settable by the Security
Administratorauthorized administrators, and support passwords of 15
characters or greater;
ST Application Note: Only an administrative users with the role of Administrator can specify the
minimum password length.
6.1.4.4 Password-based Authentication Mechanism (FIA_UAU_EXT.2)
The TSF shall provide a local password-based authentication mechanism, None
to perform administrative user authentication.
FIA_UAU_EXT.2.1
Page 56 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
6.1.4.5 Multiple authentication mechanisms (FIA_UAU.5-APM)
The TSF shall provide support of the following authentication repositories
in the operational environment:
FIA_UAU.5.1-
APM
a) Active Directory
b) LDAP
c) OCSP responders for TLS client certificate inspection
to support remote useruser authentication.
The TSF shall authenticate any user's claimed identity according to the rules
specified in an access policy as defined in FDP_IFC.1-APM.
FIA_UAU.5.2-
APM
Application Note: The TOE makes the authentication decision based on the user credentials and
the information supplied by the authentication repository.
6.1.4.6 Traffic authentication mechanisms (FIA_UAU.5-LTM)
The TSF shall provide the implementation of: TLS (client and server)
certificate validation to support remote user authentication.
FIA_UAU.5.1-LTM
The TSF shall authenticate any user's claimed identity according to the rules
defined in administrator-specified SSL Client profiles, or SSL Server
profiles that have been associated with virtual servers.
FIA_UAU.5.2-LTM
Application Note: Authentication relies on X.509 certificates that are validated according to
[RFC5280]☝. The certificates are provided the TOE environment and access is given by the LDAP
server that is part of the TOE environment. See OE.LDAP.
6.1.4.7 Protected authentication feedback (FIA_UAU.7)
The TSF shall provide only obscured feedback to the administrative user while
the authentication is in progress.
FIA_UAU.7.1
6.1.4.8 User Identification and Authentication (FIA_UIA_EXT.1)
The TSF shall allow the following actions prior to requiring the non-TOE entity to
initiate the identification and authentication process:
FIA_UIA_EXT.1.1
a) Display the warning banner in accordance with FTA_TAB.1;
b) no other actions.
The TSF shall require each administrative user to be successfully identified and
authenticated before allowing any other TSF-mediated actions on behalf on that
administrative user.
FIA_UIA_EXT.1.2
Application Note: This requirement applies to users (administrators and external IT entities) of
services available from the TOE directly, and not services available by connecting through the TOE.
Page 57 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
6.1.5 Security management
6.1.5.1 Management of security attributes (FMT_MSA.1)
The TSF shall enforce the Administrator Access Control Policy to restrict the
ability to change_default , query , modify , delete the security attributes
for the Administrator Access Control Policy to authorized administrators.
FMT_MSA.1.1
ST Application Note: Changes to the security attributes is restricted to administrative users with
the role Administrator and User Administrator.
6.1.5.2 Static attribute initialisation (FMT_MSA.3-APM)
The TSF shall enforce the APM Connection Policy to provide restrictive
default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.1-
APM
The TSF shall allow the authorized administrators to specify alternative initial
values to override the default values when an object or information is created.
FMT_MSA.3.2-
APM
6.1.5.3 Static attribute initialisation (FMT_MSA.3-BASE)
The TSF shall enforce the Administrator Access Control Policy to provide
restrictive default values for security attributes that are used to enforce the
SFP.
FMT_MSA.3.1-
BASE
The TSF shall allow the authorized administrators to specify alternative initial
values to override the default values when an object or information is created.
FMT_MSA.3.2-
BASE
6.1.5.4 Management of TSF data (for general TSF data) (FMT_MTD.1)
The TSF shall restrict the ability to manage the TSF data to the authorized
administrators.
FMT_MTD.1.1
ST Application Note: TSF data in the context of this SFR is the configuration data of the TOE. The
TSF data that can be managed depends on the role of the administrative user. See table 13.
6.1.5.5 Specification of Management Functions (FMT_SMF.1)
The TSF shall be capable of performing the following management functions:
FMT_SMF.1.1
a) Ability to administer the TOE locally and remotely;
b) Ability to update the TOE, and to verify the updates using digital
signature capability prior to installing those updates;
c) Ability to configure the cryptographic functionality;
d) Ability to configure the APM Connection Policy;
ST Application Note: The ability to administer the TOE applies to all administrator roles. The
ability to update the TOE is limited to administrative users with the role of Administrator, as described
in FPT_TUD_EXT.1. The ability to configure the cryptographic functionality is restricted to
administrative users with the Administrator role, however the Certificate Manager can also manage
certificates.
Page 58 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
6.1.5.6 Security roles (FMT_SMR.1)
The TSF shall maintain the roles: Authorized Administrator represented by
the following
FMT_SMR.1.1
● Administrator
● Resource Administrator
● User Manager
● Manager
● Certificate Manager
● iRule Manager
● Application Editor
● Operator
● Auditor
● Guest
The TSF shall be able to associate users with roles.
FMT_SMR.1.2
ST Application Note: There is an additional role "No Access" that can be assigned to users, with
the single purpose of preventing them to access the TOE. Assigning users this role is a way to
temporarily disable them from using the TOE, but still maintaining the account.
6.1.6 Protection of the TSF
6.1.6.1 Protection of Administrator Passwords (FPT_APW_EXT.1)
The TSF shall store passwords in non-plaintext form.
FPT_APW_EXT.1.1
The TSF shall prevent the reading of plaintext passwords.
FPT_APW_EXT.1.2
NDPP Application Note: The intent of the requirement is that raw password authentication data
are not stored in the clear, and that no user or administrator is able to read the plaintext password
through “normal” interfaces. An all-powerful administrator of course could directly read memory
to capture a password but is trusted not to do so.
6.1.6.2 Failure with preservation of secure state (FPT_FLS.1)
The TSF shall preserve a secure state when the following types of failures occur:
FPT_FLS.1.1
1. The active instance reports a failover condition to the standby
instance, causing the standby instance to become active.
2. The standby instance determines that the active instance is not
available anymore, causing the standby instance to become active.
6.1.6.3 Protection of TSF Data (for reading of all symmetric keys)
(FPT_SKP_EXT.1)
The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private
keys.
FPT_SKP_EXT.1.1
Page 59 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
NDPP Application Note: The intent of the requirement is that an administrator is unable to read
or view the identified keys (stored or ephemeral) through “normal” interfaces. While it is understood
that the administrator could directly read memory to view these keys, to do so is not a trivial task
and may require substantial work on the part of an administrator. Since the administrator is
considered a trusted agent, it is assumed they would not endeavor in such an activity.
6.1.6.4 Inter-TSF basic TSF data consistency (FPT_TDC.1)
The TSF shall provide the capability to consistently interpret the following TSF
data types when shared between the TSF and another trusted IT product.:
FPT_TDC.1.1
a) authentication decisions imported from an authentication provider
for traffic users in FIA_UAU.5-LTM)
b) dynamic ACLs and group memberships imported from an
authentication provider (for remote users in FIA_UAU.5-APM)
c) user name and password forwarded to local network IT entities (for
remote users in FIA_UAU.5-APM)
The TSF shall use apply dynamic ACLs only to the remote user that they
are associated with by the authentication provider when interpreting the
TSF data from another trusted IT product.
FPT_TDC.1.2
6.1.6.5 TSF testing (FPT_TST_EXT.1)
The TSF shall run a suite of self tests during initial start-up (on power on) to
demonstrate the correct operation of the TSF.
FPT_TST_EXT.1.1
6.1.6.6 Extended: Trusted Update (FPT_TUD_EXT.1)
The TSF shall provide authorized administrators the ability to query the current
version of the TOE firmware/software.
FPT_TUD_EXT.1.1
The TSF shall provide authorized administrators the ability to initiate updates to
TOE firmware/software.
FPT_TUD_EXT.1.2
The TSF shall provide a means to verify firmware/software updates to the TOE
using a digital signature mechanism prior to installing those updates.
FPT_TUD_EXT.1.3
ST Application Note: The ability to initiate updates to the TOE is limited to the administrative
users with the role of Administrator.
6.1.7 Resource utilisation
6.1.7.1 Maximum Quotas (FRU_RSA.1)
The TSF shall enforce maximum quotas of the following resources: duration of
TCP and UDP connections that subjects can use simultaneously.
FRU_RSA.1.1
6.1.8 TOE access
6.1.8.1 TSF-initiated Termination (FTA_SSL.3)
The TSF shall terminate an interactive session after a authorized administrator
configurable time interval of session inactivity.
FTA_SSL.3.1
Page 60 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
ST Application Note: The ability to configure the time interval of session inactivity is limited to
the administrative users with the role of Administrator.
6.1.8.2 User-initiated termination (FTA_SSL.4)
The TSF shall allow Administratoruser-initiated termination of the administrative
user's own interactive session.
FTA_SSL.4.1
6.1.8.3 Default TOE Access Banners (FTA_TAB.1)
Before establishing an administrative user session the TSF shall display a
authorized administrator-specified advisory notice and consent warning message
regarding unauthorizeduse of the TOE.
FTA_TAB.1.1
NDPP Application Note: This requirement is intended to apply to interactive sessions between
a human user and a TOE. IT entities establishing connections or programmatic connections (e.g.,
remote procedure calls over a network) are not required to be covered by this requirement.
ST Application Note: The ability to specify the banner is limited to the administrative users with
the role of Administrator.
6.1.9 Trusted path/channel of the TSF
6.1.9.1 Inter-TSF trusted channel (FTP_ITC.1)
The TSF shall provide a communication channel between itself and another trusted
IT product that is logically distinct from other communication channels and
provides assured identification of its end points and protection of the channel
data from modification and disclosure.
FTP_ITC.1.1
The TSF shall permit the TSF, another trusted IT product to initiate
communication via the trusted channel.
FTP_ITC.1.2
The TSF shall initiate communication via the trusted channel for HTTPS
connections to web servers and for remote authentication functions and
transmission of syslog records to syslog servers.
FTP_ITC.1.3
ST Application Note: This FTP_ITC.1 addresses trusted channels implemented by the TOE for
HTTPS connections to web servers, syslog servers and authentication servers. For connection to
web servers, the TOE can act both as a client and a server for the trusted channel.
6.1.9.2 Trusted Path (FTP_TRP.1)
The TSF shall use SSH for tmsh to provide a trusted communication path between
itself and remoteusersadministrators that is logically distinct from other
communication paths and provides assured identification of its end points and
protection of the communicated data from disclosure, and detection of
modification of the communicated data.
FTP_TRP.1.1
The TSF shall permit remote usersadministrators to initiate communication
via the trusted path.
FTP_TRP.1.2
The TSF shall require the use of the trusted path for initial useradministrator
authentication, and all remote administration actions.
FTP_TRP.1.3
Page 61 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
6.2 Security Functional Requirements Rationale
6.2.1 Coverage
The following table provides a mapping of SFR to the security objectives, showing that each security
functional requirement addresses at least one security objective.
Objectives
Security functional requirements
O.SYSTEM_MONITORING
FAU_GEN.1
O.SYSTEM_MONITORING
FAU_GEN.2
O.SYSTEM_MONITORING
FAU_STG_EXT.1
O.PROTECTED_COMMUNICATIONS
FCS_CKM.1-SSH
O.PROTECTED_COMMUNICATIONS
FCS_CKM.1-RSA
O.APM-VPN,
O.LTM-TRAFFICMGMT,
O.PROTECTED_COMMUNICATIONS
FCS_CKM_EXT.4
O.APM-VPN,
O.LTM-TRAFFICMGMT,
O.PROTECTED_COMMUNICATIONS
FCS_COP.1(1)
O.APM-VPN,
O.LTM-TRAFFICMGMT,
O.PROTECTED_COMMUNICATIONS
FCS_COP.1(2)
O.APM-VPN,
O.LTM-TRAFFICMGMT,
O.PROTECTED_COMMUNICATIONS
FCS_COP.1(3)
O.PROTECTED_COMMUNICATIONS
FCS_HTTPS_EXT.1
O.LTM-TRAFFICMGMT,
O.PROTECTED_COMMUNICATIONS
FCS_RBG_EXT.1
O.PROTECTED_COMMUNICATIONS
FCS_SSH_EXT.1
O.APM-VPN,
O.LTM-TRAFFICMGMT,
O.PROTECTED_COMMUNICATIONS
FCS_TLS_EXT.1
O.TOE_ADMINISTRATION
FDP_ACC.1
O.TOE_ADMINISTRATION
FDP_ACF.1
O.APM-VPN
FDP_IFC.1-APM
O.APM-VPN
FDP_IFF.1-APM
O.APM-VPN,
O.LTM-TRAFFICMGMT
FDP_ITC.1
O.RESIDUAL_INFORMATION_CLEARING
FDP_RIP.2
Page 62 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Objectives
Security functional requirements
O.PROTECTED_COMMUNICATIONS
FDP_UCT.1
O.PROTECTED_COMMUNICATIONS
FDP_UIT.1
O.TOE_ADMINISTRATION
FIA_AFL.1
O.TOE_ADMINISTRATION
FIA_ATD.1
O.TOE_ADMINISTRATION
FIA_PMG_EXT.1
O.TOE_ADMINISTRATION
FIA_UAU_EXT.2
O.APM-VPN
FIA_UAU.5-APM
O.LTM-TRAFFICMGMT
FIA_UAU.5-LTM
O.TOE_ADMINISTRATION
FIA_UAU.7
O.TOE_ADMINISTRATION
FIA_UIA_EXT.1
O.TOE_ADMINISTRATION
FMT_MSA.1
O.APM-VPN
FMT_MSA.3-APM
O.TOE_ADMINISTRATION
FMT_MSA.3-BASE
O.TOE_ADMINISTRATION
FMT_MTD.1
O.TOE_ADMINISTRATION
FMT_SMF.1
O.TOE_ADMINISTRATION
FMT_SMR.1
O.TOE_ADMINISTRATION
FPT_APW_EXT.1
O.FAILOVER
FPT_FLS.1
O.TOE_ADMINISTRATION
FPT_SKP_EXT.1
O.APM-VPN
FPT_TDC.1
O.TSF_SELF_TEST
FPT_TST_EXT.1
O.VERIFIABLE_UPDATES
FPT_TUD_EXT.1
O.RESOURCE_AVAILABILITY
FRU_RSA.1
O.SESSION_LOCK
FTA_SSL.3
O.SESSION_LOCK
FTA_SSL.4
O.DISPLAY_BANNER
FTA_TAB.1
O.APM-VPN,
O.LTM-TRAFFICMGMT,
O.PROTECTED_COMMUNICATIONS
FTP_ITC.1
Page 63 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Objectives
Security functional requirements
O.PROTECTED_COMMUNICATIONS
FTP_TRP.1
Table 9: Mapping of security functional requirements to security objectives
6.2.2 Sufficiency
The following rationale provides justification for each security objective for the TOE, showing that
the security functional requirements are suitable to meet and achieve the security objectives.
Rationale
Security objectives
The information flow policy for handling of network traffic is defined in
FDP_IFC.1-APM and FDP_IFF.1-APM. Entities are authenticated as required
in FIA_UAU.5-APM, using external authentication providers as defined in
O.APM-VPN
FPT_TDC.1. Particular policy management aspects are defined in
FMT_MSA.3-APM. The security of involved network communications is
addressed in FTP_ITC.1 and implemented in FCS_TLS_EXT.1.
Cryptographic support (key management and primitives) for the latter
is spelled out in FCS_CKM_EXT.4, FCS_COP.1(1), FCS_COP.1(2),
FCS_COP.1(3), FCS_RBG_EXT.1, and FDP_ITC.1.
The requirement for banners can be found in FTA_TAB.1.
O.DISPLAY_BANNER
Failover capabilities are required in FPT_FLS.1 (preservation of a secure
state if one instance of the TOE fails).
O.FAILOVER
The requirement for LTM to authenticate network traffic is reflected in
FIA_UAU.5-LTM
O.LTM-TRAFFICMGMT
In order to proxy HTTPS traffic, a requirement to implement TLS is spelled
out on a high level in FTP_ITC.1 and implemented in FCS_TLS_EXT.1.
Cryptographic support (key management and primitives) for the latter
is spelled out in FCS_CKM_EXT.4, FCS_COP.1(1), FCS_COP.1(2),
FCS_COP.1(3), FCS_RBG_EXT.1, and FDP_ITC.1.
Requirements for the provision of HTTPS (FCS_HTTPS_EXT.1), SSH
(FCS_SSH_EXT.1), and TLS FCS_TLS_EXT.1) implement FTP_ITC.1,
FTP_ITC.1, and FTP_TRP.1.
O.PROTECTED_COMMUNICATIONS
Cryptographic support for these protocols is implemented in
FCS_CKM.1-RSA, FCS_CKM_EXT.4, FCS_COP.1(1), FCS_COP.1(2),
FCS_COP.1(3), and FCS_RBG_EXT.1.
This also includes FDP_UCT.1 and FDP_UIT.1, which apply to
administrative interfaces using SSH.
This objective is addressed in FDP_RIP.2, which requires that the TOE
ensures that residual information in memory does not leak into newly
created network packets.
O.RESIDUAL_INFORMATION_CLEARING
Page 64 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Rationale
Security objectives
FRU_RSA.1 spells out resources for which the TOE is required to
implement protection against exhaustion in order to uphold its
manageability at any time.
O.RESOURCE_AVAILABILITY
This is addressed in SFRs FTA_SSL.3 requiring termination of interactive
sessions after a period of inactivity and FTA_SSL.4 by allowing users to
actively terminate (end) a session.
O.SESSION_LOCK
FAU_GEN.1 defines the types of audit records that the TOE must be able
to generate. FAU_GEN.2 requires that audit records be associated with
user identities, where possible. FAU_STG_EXT.1 requires that the TOE
O.SYSTEM_MONITORING
shall be able to send audit records to an external log server. OE.TIME
supports the generation of audit records by providing a reliable time
stamp.
Authentication of administrators is defined in FIA_UIA_EXT.1,
FIA_UAU_EXT.2, and FIA_UAU.7. This includes authentication failure
handling (FIA_AFL.1), password management capabilities
(FIA_PMG_EXT.1). User attributes needed for authentication and other
security functions are enumerated in FIA_ATD.1.
O.TOE_ADMINISTRATION
In oder to support the administration of the TSF (FMT_SMF.1), FDP_ACC.1
and FDP_ACF.1 define the "Administrator Access Control Policy" that
implements the requirement in FMT_MTD.1, with additional properties
defined in FMT_MSA.1, FMT_MSA.3-BASE, and FMT_SMR.1.
FPT_APW_EXT.1 and FPT_SKP_EXT.1 spell out specific protections for
plaintext passwords and cryptographic key material.
FPT_TST_EXT.1 spells out the self-test requirements for the TOE.
O.TSF_SELF_TEST
FPT_TUD_EXT.1 requires the TOE to implement verifiable update
capabilities.
O.VERIFIABLE_UPDATES
Table 10: Security objectives for the TOE rationale
6.2.3 Security Requirements Dependency Analysis
Dependencies within the EAL package selected for the security assurance requirements have been
considered by the authors of CC Part 3 and are not analyzed here again. The included component
on flaw remediation, ALC_FLR.3, has no dependencies on other requirements.
The security functional requirements in this Security Target do not introduce dependencies on any
security assurance requirement; neither do the security assurance requirements in this Security
Target introduce dependencies on any security functional requirement.
The following table demonstrates the dependencies of SFRs modeled in CC Part 2 and how the SFRs
for the TOE resolve those dependencies.
Page 65 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Resolution
Dependencies
Security functional
requirement
The TOE itself does not generate reliable
time stamps but relies on time stamps
provided by the TOE environment
(OE.TIME).
FPT_STM.1
FAU_GEN.1
FAU_GEN.1
FAU_GEN.1
FAU_GEN.2
FIA_UIA_EXT.1
FIA_UID.1
FAU_GEN.1
FAU_GEN.1
FAU_STG_EXT.1
The keys are not distributed since they are
used locally by the SSH host, rather than
relying on stand-alone key distribution
[FCS_CKM.2 or FCS_COP.1]
FCS_CKM.1-SSH
mechanisms defined in a dependent SFR
because the distribution of keys is inherent
to the SSH protocol the TOE is required to
support. Therefore, the dependency on
FCS_CKM.2 is not necessary.
FCS_SSH_EXT.1
FCS_CKM_EXT.4
FCS_CKM.4
The SFR has been iterated to specify the
key distribution method rather than relying
on stand-alone key distribution
[FCS_CKM.2 or FCS_COP.1]
FCS_CKM.1-RSA
mechanisms defined in a dependent SFR
because the distribution of keys is inherent
to the protocols the TOE is required to
support. Therefore, the dependency on
FCS_CKM.2 is not necessary.
FCS_COP.1(1)
FCS_CKM_EXT.4
FCS_CKM.4
FDP_ITC.1
[FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1]
FCS_CKM_EXT.4
FDP_ITC.1
FCS_CKM.1-RSA
[FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1]
FCS_COP.1(1)
FCS_CKM_EXT.4
FCS_CKM.4
Hash mechanisms do not require keys.
[FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1]
FCS_COP.1(2)
FCS_CKM_EXT.4
FCS_CKM.4
Page 66 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Resolution
Dependencies
Security functional
requirement
The TOE does not (necessarily) generate
keys used as secret for the HMAC because
the sources for the necessary keys are
[FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1]
FCS_COP.1(3)
defined by the protocols supported by the
TSF; therefore, the dependency on
FCS_CKM.1 is not necessary.
FCS_CKM_EXT.4
FCS_CKM.4
FCS_TLS_EXT.1
FCS_TLS_EXT.1
FCS_HTTPS_EXT.1
No dependencies
FCS_RBG_EXT.1
No dependencies
FCS_SSH_EXT.1
No dependencies
FCS_TLS_EXT.1
FDP_ACF.1
FDP_ACF.1
FDP_ACC.1
FDP_ACC.1
FDP_ACC.1
FDP_ACF.1
FMT_MSA.3-BASE
FMT_MSA.3
FDP_IFF.1-APM
FDP_IFF.1
FDP_IFC.1-APM
FDP_IFC.1-APM
FDP_IFC.1
FDP_IFF.1-APM
FMT_MSA.3-APM
FMT_MSA.3
FDP_ACC.1
[FDP_ACC.1 or FDP_IFC.1]
FDP_ITC.1
FMT_MSA.3-BASE
FMT_MSA.3
No dependencies
FDP_RIP.2
FTP_TRP.1
[FTP_ITC.1 or FTP_TRP.1]
FDP_UCT.1
FDP_ACC.1
[FDP_ACC.1 or FDP_IFC.1]
FDP_ACC.1
[FDP_ACC.1 or FDP_IFC.1]
FDP_UIT.1
FTP_TRP.1
[FTP_ITC.1 or FTP_TRP.1]
FIA_UIA_EXT.1
FIA_UAU.1
FIA_AFL.1
No dependencies
FIA_ATD.1
No dependencies
FIA_PMG_EXT.1
No dependencies
FIA_UAU_EXT.2
No dependencies
FIA_UAU.5-APM
No dependencies
FIA_UAU.5-LTM
FIA_UIA_EXT.1
FIA_UAU.1
FIA_UAU.7
Page 67 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Resolution
Dependencies
Security functional
requirement
FTA_TAB.1
FTA_TAB.1
FIA_UIA_EXT.1
FDP_ACC.1
[FDP_ACC.1 or FDP_IFC.1]
FMT_MSA.1
FMT_SMR.1
FMT_SMR.1
FMT_SMF.1
FMT_SMF.1
FMT_MSA.1
FMT_MSA.1
FMT_MSA.3-APM
FMT_SMR.1
FMT_SMR.1
FMT_MSA.1
FMT_MSA.1
FMT_MSA.3-BASE
FMT_SMR.1
FMT_SMR.1
FMT_SMR.1
FMT_SMR.1
FMT_MTD.1
FMT_SMF.1
FMT_SMF.1
No dependencies
FMT_SMF.1
FIA_UIA_EXT.1
FIA_UID.1
FMT_SMR.1
No dependencies
FPT_APW_EXT.1
No dependencies
FPT_FLS.1
No dependencies
FPT_SKP_EXT.1
No dependencies
FPT_TDC.1
No dependencies
FPT_TST_EXT.1
No dependencies
FPT_TUD_EXT.1
No dependencies
FRU_RSA.1
No dependencies
FTA_SSL.3
No dependencies
FTA_SSL.4
No dependencies
FTA_TAB.1
No dependencies
FTP_ITC.1
No dependencies
FTP_TRP.1
Table 11: TOE SFR dependency analysis
6.2.3.1 Security Requirements Dependency Rationale
The following provides rationale for those SFRs whose dependencies are satisifies by SFRs other
than specified.
Page 68 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
1. The dependency on FIA_UID.1 by FAU_GEN.2 is satisfied by FIA_UIA_EXT.1; this is
aacceptable because FIA_UIA_EXT.1 is a superset of FIA_UID.1; requiring not only
identification, but also authentication.
2. The dependency on FCS_CKM.4 by FCS_CKM.1-RSA, FCS_COP.1(1), FCS_COP.1(2), and
FCS_COP.1(3) is satisfied by FCS_CKM_EXT.4; this is acceptable because FCS_CKM_EXT.4
specifies the cryptographic keys more specifically (all plaintext secret and private
cryptographic keys and CSPs), the key destruction method (zeroization), and the timing of
the destruction (when no longer required). Also, the application note gives additional
guidance to the reader.
3. The dependency on FIA_UAU.1 by FIA_AFL.1, FIA_UAU.7 and FMT_SMR.1 is satisfied by
FIA_UIA_EXT.1 because FIA_UIA_EXT.1 is a superset of FIA_UID.1; requiring not only
authentication but also identification.
6.2.4 Internal consistency and mutual support of SFRs
The sufficiency rationale in section 6.2.2 has already demonstrated how the IT security requirements
work together to implement the individual objectives for the TOE and the IT environment. This
section will elaborate on the internal consistency and mutual support of the IT security requirements.
Generic requirements particular to network devices include residual information protection for
content of traffic that is being mediated (FDP_RIP.2).
The TOE implements a variety of protocols to provide secure communication channels and trusted
paths. Following NDPP, this is defined in a cascade of requirements starting with generic requirements
(FTP_ITC.1 and FTP_TRP.1. On a protocol level, this is then spelled out by FCS_HTTPS_EXT.1 for
HTTPS, and FCS_SSH_EXT.1 for SSH.
The LTM module of the TOE implements HTTP traffic authentication, as required in FIA_UAU.5-LTM.
Proxying HTTPS traffic basically requires the termination and establishment of TLS connections, as
defined in FCS_TLS_EXT.1 and, on a higher level, FTP_ITC.1.
The cryptographic support for the secure communications protocols discussed above is provided
by central cryptographic libraries that are exhaustively described in section 1.5.3.7, including how
the individual crypto SFRs work together to implement this support.
Management capabilities for administrators are defined in FMT_SMF.1, FMT_MTD.1, FMT_MSA.1,
FMT_MSA.3-BASE, and FMT_SMR.1. Administrators are subject to an access control policy (FDP_ACC.1
and FDP_ACF.1), based on authentication of individual administrators (FIA_UIA_EXT.1, FIA_UAU_EXT.2,
FIA_UAU.7, FIA_AFL.1, FIA_PMG_EXT.1), and further access restrictions (FPT_APW_EXT.1 and
FPT_SKP_EXT.1). (User attributes are defined in FIA_ATD.1.) Access to the administrative interfaces
is protected implementing the trusted paths described above, and is subject to display of an advisory
(FTA_TAB.1) and proper termination of sessions (FTA_SSL.3, and FTA_SSL.4).
The TOE implements auditing for all security-relevant mechanisms: FAU_GEN.1 defines the types
of audit records that the TOE must be able to generate. FAU_GEN.2 requires that audit records be
associated with user identities, where possible. FAU_STG_EXT.1 requires that the TOE shall be able
to send audit records to an external log server.
Underlying self-protection requirements for the TSF include prevention of exhaustion of administrative
resources (FRU_RSA.1), a set of defined self-tests (FPT_TST_EXT.1), and capabilities to verify software
updates (FPT_TUD_EXT.1).
Page 69 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Finally, the TOE provides failover capabilities between redundant systems. This is modeled in
FPT_FLS.1.
The external states for failover are as follows:
● Active – operative and handling traffic
● Standby – operative, ready and able to take over from the Active unit if it should fail
● ForcedOffline – operative (has not failed) but has been manually made unavailable
● Offline – Not a displayed state, but represents the failure of the unit
6.3 Security Assurance Requirements
6.3.1 Assurance Requirements
The security assurance requirements (SARs) for the TOE are the Evaluation Assurance Level 4
components as specified in [CC] part 3, augmented by ALC_FLR.3.
The following table shows the SARs, and the operations performed on the components according
to CC part 3: iteration (Iter.), refinement (Ref.), assignment (Ass.) and selection (Sel.).
Operations
Source
Security assurance requirement
Security
assurance class
Sel.
Ass.
Ref.
Iter.
No
No
No
No
CC Part 3
ADV_ARC.1 Security architecture description
ADV Development
No
No
No
No
CC Part 3
ADV_FSP.4 Complete functional specification
No
No
No
No
CC Part 3
ADV_IMP.1 Implementation representation of the
TSF
No
No
No
No
CC Part 3
ADV_TDS.3 Basic modular design
No
No
No
No
CC Part 3
AGD_OPE.1 Operational user guidance
AGD Guidance
documents
No
No
No
No
CC Part 3
AGD_PRE.1 Preparative procedures
No
No
No
No
CC Part 3
ALC_CMC.4 Production support, acceptance proce
dures and automation
ALC Life-cycle
support
No
No
No
No
CC Part 3
ALC_CMS.4 Problem tracking CM coverage
No
No
No
No
CC Part 3
ALC_DEL.1 Delivery procedures
No
No
No
No
CC Part 3
ALC_DVS.1 Identification of security measures
No
No
No
No
CC Part 3
ALC_FLR.3 Systematic flaw remediation
No
No
No
No
CC Part 3
ALC_LCD.1 Developer defined life-cycle model
No
No
No
No
CC Part 3
ALC_TAT.1 Well-defined development tools
No
No
No
No
CC Part 3
ASE_INT.1 ST introduction
ASE Security
Target evaluation
No
No
No
No
CC Part 3
ASE_CCL.1 Conformance claims
No
No
No
No
CC Part 3
ASE_SPD.1 Security problem definition
Page 70 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Operations
Source
Security assurance requirement
Security
assurance class
Sel.
Ass.
Ref.
Iter.
No
No
No
No
CC Part 3
ASE_OBJ.2 Security objectives
No
No
No
No
CC Part 3
ASE_ECD.1 Extended components definition
No
No
No
No
CC Part 3
ASE_REQ.2 Derived security requirements
No
No
No
No
CC Part 3
ASE_TSS.1 TOE summary specification
No
No
No
No
CC Part 3
ATE_COV.2 Analysis of coverage
ATE Tests
No
No
No
No
CC Part 3
ATE_DPT.1 Testing: basic design
No
No
No
No
CC Part 3
ATE_FUN.1 Functional testing
No
No
No
No
CC Part 3
ATE_IND.2 Independent testing - sample
No
No
No
No
CC Part 3
AVA_VAN.3 Focused vulnerability analysis
AVA Vulnerability
assessment
Table 12: SARs
6.4 Security Assurance Requirements Rationale
The basis for the justification of EAL4 augmented with ALC_FLR.3 is the threat environment
experienced by the typical consumers of the TOE. This matches the package description for EAL4
(enhanced-basic).
Page 71 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
7 TOE Summary Specification
7.1 TOE Security Functionality
7.1.1 Device management
7.1.1.1 Security Function Management
The TOE offers administrators a number of interfaces to configure and manage the TSF. This includes
the Configuration utility, tmsh, and iControl API.
Some general configuration options include the definition of an administrative IP address for the
TOE's management network interface, the configuration of failover mechanisms and the configuration
of trusted updates.
In addition to the management (network) interface, the TOE features multiple switch interfaces for
the physical connection to the networks carrying the traffic that the TSF mediates. Those switch
interfaces can be assigned VLANs, and self IP addresses (i.e., an IP address that is associated with
the TOE in that VLAN).
Configuration objects that deal with the individual traffic management functions offered by the TOE
are stored in partitions (either the Common partition, or administrator-defined partitions), facilitating
the access control mechanisms described below.
BIG-IP uses the concept of virtual servers to define destinations that BIG-IP accepts (client) traffic
for. Virtual servers are represented by an IP address and service (such as HTTP). The actual resources
that BIG-IP forwards the traffic to are referred to as nodes, represented by their IP address. Nodes
can be grouped into pools, for example for the purpose of load balancing. (A client sends an HTTP
request to BIG-IP's virtual server address, and BIG-IP will then select a node from the pool associated
with the virtual server to forward the request to.)
In order to determine the treatment of different types of traffic, such as requiring client authentication
or inspection of HTTP code at the application layer, administrators can assign profiles to virtual
servers. Profiles contain detailed instructions on how the different traffic management-related
security functions of the TOE are applied to matching traffic.
In addition to pre-defined behavior options that administrators can choose from in the TOE's
administration interfaces, such as rejecting traffic that does not come from a specific set of sender
addresses, administrators can define custom rules for traffic inspection using the TOE's iRules
scripting language, for example in order to inspect network packets for application-specific content
and determine how traffic is treated based on the results. iRules conform to Tcl grammar rules
[Tcl]☝ and are driven by a defined list of events [iRules_EVENTS]☝ that trigger the execution of
specified commands [iRules_COMMANDS]☝.
The following sections will add details on specific configuration options related to the individual
security functions discussed.
This functionality implements FMT_MSA.1 and FMT_SMF.1.
7.1.1.2 Authentication
Administrative users (i.e., all users authorized to access the TOE's administrative interfaces) are
identified by a user name and authenticated by an individual password associated with that user's
account.
Page 72 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Local user accounts are managed by administrators in the Administrator or User Manager role and
stored in the TOE's local user database. Management includes creating and deleting users, as well
as changing another user's passwords (every user can change their own password), role, or partition
the user has access to, and enabling or disabling terminal access for the user. However, User
Managers that have access to only one partition cannot change the partition access of other users,
and cannot change their own partition access or role. (More on roles and access control can be
found in section 7.1.1.3.)
This functionality implements FIA_ATD.1, FIA_UIA_EXT.1, FIA_UAU_EXT.2, FMT_MSA.1,
FMT_MSA.3-BASE.
Password policy and user lockout
The TOE can enforce a password policy for all user accounts managed locally. This includes the
definition of a minimum password length and required character types (numeric, uppercase,
lowercase, others). The minimum password length in the evaluated configuration is 15 characters.
This policy is enforced when administrators change their own passwords.
Other aspects of the authentication policy include the minimum and maximum lengths of time that
passwords can be in effect, and the number of previous passwords that BIG-IP should store to
prevent users from re-using former passwords.
The maximum duration specifies the maximum number of days a password is valid; users must
change their passwords before the maximum duration is reached. User accounts whose password
has expired, based on the administrator-defined maximum password duration, are locked and
require an administrator to reset them.
Access to the TOE for individual users can be disabled ("locked") after a configured number of failed
authentication attempts; which, in the evaluated configuration, the default is 3 with a valid range
from 1 to 10. Administrative users with the role of Administrator or User Manager have to manually
unlock accounts that have been locked by the TOE.
This functionality implements FIA_AFL.1, FIA_ATD.1 and FIA_PMG_EXT.1.
Default settings
The TOE comes with a pre-defined "admin" user with the Administrator role assigned that cannot
be deleted. A password is assigned during setup of the TOE. (The root user for the underlying OS
is disabled in the evaluated configuration.)
New users created for the TOE have the following default settings:
● user role
❍ local user accounts: No Access
❍ remote user accounts: No Access
● partition
❍ local user accounts: the partition selected by the user that is creating the account
❍ remote user accounts: Common
● partition access
❍ local user accounts: All
❍ remote user accounts: Common
● terminal access
Page 73 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
local user accounts: Disabled
❍
❍ remote user accounts: Disabled
The default setting for individual accounts can be changed at the time of account creation. The
default settings listed above for remote user accounts are those assigned to users without specific
access control settings defined in the TOE, and can be changed by administrator as part of the
remote authentication scheme definition.
This functionality implements FIA_ATD.1 and FMT_MSA.3-BASE.
Authentication Banners, Obscured Feedback, and Time-outs
For interactive user authentication at the web-based Configuration utility and the command line
tmsh via SSH, BIG-IP obscures passwords entered by users, and implements the display of
administrator-defined banners to users before they authenticate.
The TOE terminates remote (Configuration Utility or tmsh) sessions after an administrator-defined
period of inactivity. Users can also actively terminate their sessions (log out).
If a user with a local user account is logged on to the BIG-IP system, and the system's configuration
is changed from local authentication to remote authentication, the local user remains authenticated
until the user’s logon session terminates.
This functionality implements FIA_UAU.7, FIA_UIA_EXT.1, FTA_TAB.1, FTA_SSL.3, FTA_SSL.4.
7.1.1.3 Access Control
The TOE allows authorized administrators to define the type of terminal access that individual users
have, i.e. whether they have access to the tmsh via SSH or not.
Access of individual users to the web-based Configuration utility, tmsh, and iControl API is restricted
based on pre-defined roles. These roles define which type of objects a user has access to and which
type of tasks he or she can perform. The role definitions cannot be changed by TOE administrators.
The types of objects managed by the TOE are defined as part of the security policy in section 1.5.6.
Table 13 contains the definition of user roles.
The tasks that users can perform on objects, depending on their role, are grouped into hierarchical
access levels:
● write: create, modify, enable and disable, and delete an object
● update: modify, enable, and disable an object
● read: view an object
In addition to roles, the TOE implements the concept of partitions for restricting access to objects.
Objects (including users, server pools, etc.) can be created in different partitions by administrators,
and users can be assigned a partition they have access to ("partition access"). As a result, users
will only have the type of access defined by their assigned role to objects in the partition that is
defined by their partition access. (With certain exceptions documented in the tables below.) It is
possible to assign a user access to "all" partitions, in which case the user will have access to objects
in all partitions as defined by their role (referred to in the guidance documentation as "universal
access").
Note: The fact that a user account is created in a specific partition does not mean that the user
will automatically have access to other objects in that partition.
Page 74 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
The TOE comes with a pre-defined "Common" partition, which cannot be deleted. New objects
created by users are either placed in the user's partition, or - if the user has access to all partitions
- are placed in the Common partition unless the user explicitly chooses otherwise. The pre-defined
"admin" user with the Administrator role is located in the Common partition.
Even users who are located in a partition other than Common have certain access to objects in the
Common partition, as follows:
● Administrator always have access to all objects defined in the TOE.
● User Managers have write access to user account objects in the Common partition, except
those with the Administrator role assigned to them.
● Resource Administrators, Managers, Certificate Managers, Application Editors, Operators,
and Guests have read access to all objects in the Common partition.
Associated rights
Role
This role grants users complete access to all partitioned and non-partitioned objects on
the system, manage remote user accounts and change their own passwords.
Administrator
This role grants users complete access to all partitioned and non-partitioned objects on
the system, except user account objects. Additionally, users with this role can change
their own passwords.
Resource
Administrator
Users with the User Manager role that have access to all partitions can create, modify,
delete, and view all user accounts except those that are assigned the Administrator role,
or the User Manager role with different partition access. However, User Managers cannot
manage user roles for remote user accounts.
Users with the User Manager role that have access only to a single partition can create,
modify, delete, and view only those user accounts that are in that partition and that have
access to that partition only.
User accounts with the User Manager role can change their own passwords.
User Manager
This role grants users permission to create, modify, and delete virtual servers, nodes,
pools, pool members, custom profiles, custom monitors, and iRules. Users in this role can
view all objects on the system and change their own passwords.
Manager
This role grants users permission to manage device certificates and keys, as well as
perform Federal Information Processing Standard (FIPS) operations.
Certificate
Manager
This role grants users permission to create, modify, and delete iRules. Users with this role
cannot affect the way that an iRule is deployed. For example, a user with this role can
create an iRule but cannot assign it to a virtual server or move the iRule from one virtual
server to another. A user with this role can be assigned universal access to administrative
partitions.
iRule Manager
This role grants users permission to modify nodes, pools, pool members, monitors and
change their own passwords. These users can view all objects on the system.
In addition, the Application Editor has full access to the APM-related configuration objects
in BIG-IP. In particular, this includes the following authorizations with regard to management
capabilities offered by the Configuration utility:
Application Editor
● Config Utility (basic network and licensing configuration) - No access
● Traffic Summary - Read-only
● Reports (reporting on TOE users) - No access
Page 75 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Associated rights
Role
● Performance - Read-only
● Statistics - Read-only
● Local Traffic feature - Read-only access for Virtual Servers, Profiles, iRules, SNATs,
and SSL Certificates; Modification (but not creation or deletion) of Nodes, Pools, Pool
Members, and Monitors; Enabling/Disabling Nodes and Monitors
● Access Profiles - Modification (but not Creation/Deletion) and activation of access
policies with the exception of the "Max Concurrent Users" field
● AAA Servers - Full access
● ACLs - Full access
● VLAN Based Routing - Read-only access for VLAN, Self-IP, and VLAN Gateways;
Creation/Modification/Deletion of VLAN Selection Agents
● Client IP Allocation - Full access
● Network Access Resources - Full access
● Customization - Full access
● Advanced Customization - No access
● Session Variable Management - Creation/Modification/Deletion of Variable Assignment
Agent; Creation/Modification (but not Deletion) of session variables
● End User Security - Full access
● Network features - No access to ARP configuration; Read-only access to all other
features
● System features - Read-only access; can change password for users in Application
Editor role
This role grants users permission to enable or disable nodes and pool members. These
users can view all objects.
Operator
This role grants users permission to view all configuration data on the system, including
logs and archives. Users with this role cannot create, modify, or delete any data, nor can
they view SSL keys or user passwords.
Auditor
This role grants users permission to view all objects on the system in their partition and
Common partition.
Guest
This role prevents users from accessing the system.
No Access
Table 13: BIG-IP User Roles
This functionality implements FDP_ACC.1, FDP_ACF.1, FMT_MTD.1, FMT_SMR.1.
7.1.1.4 Auditing
BIG-IP uses syslog functionality to generate audit events.
BIG-IP systems generate different log types that capture different types of events. This includes:
● audit events
events related to the security and administrative functionality implemented by the TOE;
this type of audit log captures most of the events specified in this ST
● system events
Page 76 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
events related to the underlying system as well as status of TOE components, such as the
syslog-ng daemon
● local traffic events
events related to network traffic handled by the system
The TOE allows to configure syslog levels per daemon that generates the respective audit records.
The Configuration utility GUI and tmsh allow to set those log levels.
Table 14 shows the information included in the different types of audit logs.
Log type
Log content
Audit
(other)
Audit
(mcp)
Local
Traffic
System
X
X
X
X
The description of the event that caused the
system to log the message.
Description
X
A description of the configuration change that
caused the system to log the message.
Event
X
X
X
The host name of the system that logged the
event message.
Host name
X
X
X
The service that generated the event.
Service
The ID associated with the user session.
Session ID
X
The status code associated with the event.
Status code
X
X
X
X
The time and date that the system logged the
event message.
Timestamp
X
The identification number of the configuration
change.
Transaction ID
X
X
The name of the user who made the configuration
change.
User Name
Table 14: Audit Logs and Their Content
BIG-IP supports (and the evaluated configuration mandates) logging to external syslog hosts. Audit
records in transit to the remote host are protected by TLS channels as described in section 7.1.1.5.
The syslog mechanism provided by the underlying Linux system is used for the creation (and
forwarding) of audit records, and is consequently part of the TOE. In addition, BIG-IP implements
a high-speed logging mechanism for data traffic in TMM that is compatible with syslog.
This functionality implements FAU_GEN.1, FAU_GEN.2, FAU_STG_EXT.1.
Page 77 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
7.1.1.5 Communications Security
Administrator Access
Network administrators connect to the TOE remotely via a dedicated network interface to administer
the TOE. Administrators are authenticated locally by user name and password; remote authentication
(via LDAP or AD) is not supported by the TOE. The TOE implements the following trusted paths:
● SSH
Connections to the TOE's command line interface are protected using SSH version 2, using
AES with 256 bit-sizes keys, data integrity protection uses HMAC-SHA1, and RSA for
authentication. The SSH implementation monitors packet size on all channels and limits
packet size as suggested in RFC 4253 Section 6.1; the maximum packet size is (256*1024)
bytes with larger packets being silently dropped. Additionally, the SSH implementation has
hard-coded diffie-hellman-group14-sha1 key exchange, diffie-hellman-group1-sha1 key
exchange is intentionally disabled.
This functionality implements FDP_UCT.1, FDP_UIT.1, FCS_SSH_EXT.1, and FTP_TRP.1.
Further, time-outs for sessions between administrative users are implemented. Administrators can
configure time-outs for idle sessions both for Configuration utility and tmsh sessions.
This functionality implements FTA_SSL.3.
Lastly, administrators are able to actively terminate these sessions (i.e., to log out and therefore
close an authenticated session).
This functionality implements FTA_SSL.4.
Remote authentication service
The TOE supports TLS channels to AD and LDAP servers that are used for remote traffic
authentication. This includes the TOE providing a client certificate to the remote server, and
validating the server certificate that the remote server provides against a CA certificate stored
locally in BIG-IP.
Certificates are also validated using an external OCSP server, provided the TOE is configured in
such a way. This includes the TOE providing a signed request to the external OCSP server, and
validating the signed response that the remote server provides against a CA certificate stored
locally in BIG-IP.
This functionality implements FIA_UAU_EXT.2 and FTP_ITC.1.
Communication with external audit servers
The TOE supports TLS channels to audit servers for the protection of audit records sent from the
TOE to an external audit server.
This functionality implements FAU_STG_EXT.1 and FTP_ITC.1.
Page 78 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
7.1.2 Basic Traffic Management
7.1.2.1 Replay Detection
Replay detection (and rejection) is inherent to the protocols used by BIG-IP to establish
communications of a trusted nature, i.e. TLS/HTTPS and SSH. This is further discussed in [RFC4346]
and [RFC4346] for TLS and [RFC4251] for SSH.
This functionality implements FCS_SSH_EXT.1 and FCS_TLS_EXT.1.
7.1.2.2 Traffic authentication
BIG-IP implements functionality to authenticate incoming HTTP requests based on credentials
provided by clients in the requests. Authentication is performed using external authentication
providers, i.e., BIG-IP does not maintain its own user database for HTTP clients. Furthermore, BIG-IP
can validate certificates presented in TLS client and/or server sessions, which is described below
under TLS offloading.
For the case that authentication of credentials provided in traffic fails, administrators can configure
the TOE to either reject the session or retry authentication.
Administrators configure the authentication mechanisms described in this section by defining client
authentication configurations in so-called authentication profiles (for the PAM-based LDAP
authentication mechanisms described above), and SSL Profiles (SSL Client Profiles and SSL Server
Profiles) for TLS offloading. These profiles can then be associated with application-specific profiles
(such as HTTP) that provide general characteristics of the traffic that is to be subjected to the
defined authentication methods. TLS offloading, and the optional authentication of communication
partners that goes along with it, is described further in the next section.
Basic HTTP LDAP authentication
The TOE can obtain user name and password values from HTTP traffic, and use these credentials
to authenticate traffic against LDAP servers (including AD via LDAP) in the operational environment.
This implements FIA_UAU.5-APM.
TLS client certificate LDAP authentication
LTM can authenticate network traffic using data stored on a remote LDAP server. Client credentials
are based on TLS certificates, as well as defined user groups and roles.
Methods that administrators can choose from to validate the actual certificates that are used to
authenticate traffic from TLS clients include:
● Accepting any certificate that validates properly against a configured CA certificate, and
extracting a user name (DN) from the client certificate to match against the LDAP server.
● Comparison of the certificate presented by a client to the certificate stored for that user
in LDAP.
The evaluated configuration of BIG-IP also supports OCSP responders to determine the revocation
status of a certificate presented by a client.
The outcome of any of these authentication methods is either an authorization failure due to no
records matching or more than one record matching in the LDAP database, or a success based on
exactly one record matching an LDAP entry.
Page 79 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
The TOE allows administrators to specify a list of valid groups and/or roles in the "SSL client certificate
LDAP" authentication settings of LTM. If configured, the TOE will query the LDAP database for a
user's group or role memberships and determine whether it matches any of the groups or roles
specified to be valid. These groups and roles can then be used in administrator-specified iRules in
order to decide on where to direct the authenticated traffic.
This implements FIA_UAU.5-LTM.
7.1.2.3 TLS offloading
BIG-IP offers to terminate TLS traffic from clients and to servers on behalf of an organization. The
most relevant example would be BIG-IP acting as a reverse proxy for incoming TLS client traffic
that is destined for an organization's web servers. Instead of tasking individual web servers with
the additional load of terminating the TLS sessions, and having a copy of the necessary private key
reside on each of the web servers, BIG-IP takes over this task and then forwards unencrypted traffic
to the web servers via a local network that does not require encryption for the protection of the
traffic. Responses from the web servers back to the client will be encrypted by BIG-IP again. In
another scenario, LTM re-encrypts the client traffic destined for the web servers, and the decryption
serves the purpose of - for example - traffic shaping, or other optimization functions not considered
security functionality in the context of this evaluation, while under the control of BIG-IP. Before the
traffic leaves the TOE, it is re-encrypted.
Administrators can configure SSL Client and Server profiles, and associate them with virtual servers,
in order to specify that LTM will act as a TLS server in communication with clients, and as a TLS
client when communicating with servers, respectively.
Administrators can import certificates, certificate chains, and private keys to the TOE using the
Configuration utility, which can then be referenced for use as server or client certificates in profiles
for use in traffic TLS connections.
Other security-relevant configuration items available to administrators in profiles include the
identification of trusted CA certificates, cipher suites to be enabled for the communication, other
protocol details (such as whether re-negotiation is enabled and under which conditions).
Administrators can specify iRules for use in SSL Client profiles that allow the insertion of custom
headers into HTTP requests forwarded to servers containing details about the validation results,
such as the serial number of the certificate presented by the client, or whether certificate validation
was successful. This allows the receiving server to customize responses based on this information
without having to be involved in termination of the TLS tunnel itself.
When certificate-based authentication of clients (in SSL Client profiles) or servers (in SSL Server
profiles) is enabled, administrators can determine whether certificates are optional or required,
and the number of certificates that can be traversed in a certificate chain.
The evaluated version also supports OCSP responses for certificates from OCSP responders by
defining an authentication profile as described in section 7.1.2.2
The protocol versions supported by the evaluated configuration for this function are TLS 1.1 and
1.2. The ciphersuites covered by this evaluation are identified in FCS_TLS_EXT.1.
This implements FIA_UAU.5-LTM, FTP_ITC.1, FDP_ITC.1, FCS_HTTPS_EXT.1 and FCS_TLS_EXT.1.
Page 80 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
7.1.3 VPN traffic
The APM module in the TOE allows the definition of access control policies for authenticated
connections from remote clients, determining which resources in the internal network a user is
allowed to access, and whether access depends on the client machine reporting a successful
endpoint security check or not.
The TOE terminates TLS-based VPN connections from remote clients; by offering web-based access
for remote users, internal server resources are made available to these remote users by presenting
them a web portal, and forwarding certain application protocols, such as remote desktop protocol
(RDP) connections, i.e., VPN tunnels allow the secure routing of network traffic between remote
clients and an organizations internal network after the remote users are properly identified and
authenticated.
The TOE implements an information flow policy based on the following subject and information:
Subjects, and their security attributes:
● remote users
❍ user name
❍ password
❍ presumed IP address
❍ dynamic ACLs
❍ associated access policies, including route domains, static ACLs, and iRules
❍ results of client side checks
● local network IT entities
❍ virtual IP address
❍ information, and its security attributes
● network traffic between subjects
❍ network protocol
❍ destination IP address
The TOE uses the following agents to communicate to the external authentication providers:
● AD Auth agent - Used to authenticate end users against a Microsoft Active Directory
● LDAP Auth agent - Used to authenticate end users against LDAP servers
● OCSP Auth agent - Responsible for client certificate validation by using Online Certificate
Status Protocol (OCSP)
When a previously unidentified client attempts to access a network resource that is protected by
the TOE, it is subject to the application of an access policy. This access policy is configured by
administrators, and consists of agents that represent interfaces to external authentication mechanism
(e.g. LDAP, AD etc.) and its execution is handled by the TOE. If the access policy execution results
in an allow, the access is set up to enforce the policy on subsequent transactions. If the access
policy execution resulted in a deny, the access is denied and an appropriate message is sent to
the user.
The administrator can also configure Layer 7 Access Control Lists (ACLs). These lists allow
administrators to further restrict access to the protected network resource, based on Layer 7 data
(protocol, host name, or path). After the access has been established and placed in an allow state,
the TOE will enforce these ACLs on every HTTP transaction. Administrators can also configure Layer
Page 81 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
5 Access Control Lists (ACLs). These lists allow administrators to filter traffic based on Layer 4 data
(source IP and port, destination IP and port). After a session is established and set to an allow state,
the access filter will enforce ACLs on every TCP packet."
This implements FPT_TDC.1. FDP_IFC.1-APM, FDP_IFF.1-APM, FMT_MSA.3-APM and FPT_TDC.1
7.1.4 Cryptographic mechanisms
The cryptographic support functions spelled out in the SFRs are described in the following section.
The following sections provide additional information on the implementation of random number
generation and zeroization.
This implements FCS_CKM.1-SSH, FCS_CKM.1-RSA, FCS_COP.1(1), FCS_COP.1(2), and FCS_COP.1(3).
The cryptography in the BIG-IP rely on cryptographic mechanisms for their effective implementation.
The following table identifies those functions:
ST SFR
Functions
Trusted paths for TOE administration:
FTP_TRP.1
● SSH for tmsh
Trusted channels between the TOE and external entities:
FTP_ITC.1
● TLS connections to external audit servers
FTP_ITC.1
● TLS proxy functionality for web applications and clients
Table 15: Communications Security in BIG-IP
TOE-provided cryptography (FTP_ITC.1) - The cryptographic operations for the trusted channels are
implemented in the software module within the TOE boundary. The following sections describe the
claims that are made for these operations.
Page 82 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
TMM
Hardware
mcpd GUI SSH tmsh iContro
l
TOE components
Cavium
OpenSSL RNG
Entropy
TMOS
RNG
entropy
feeder
Figure 3: Cryptographic services in TOE and underlying hardware
The TOE incorporates a FIPS 140-2 validated OpenSSL library as cryptographic service provider, as
indicated in Figure 3.
Higher-level protocol stacks can use this library in order to implement trusted communications:
1. SSH session for tmsh (SSH client to SSH server on TOE)
2. The SSL stack in TMM uses the host-provided library to implement the remaining,
traffic-related TLS functionality use cases described above (also referred to as "traffic TLS").
Remote logging relies on traffic SSL.
The underlying hardware platforms of the TOE also include a proprietary crypto co-processor from
Cavium that is used to provide sufficient entropy to support RNG. The Cavium Nitrox 3 processors
are used on the Treadstone, Whitethorne, and Victoria II platforms; the Nitrox PX processor is used
on the Centaur platform.
7.1.4.1 Key Generation
The TOE can generate key pairs for the SSH server.
(The operational environment is expected to provide TLS server and client keys and certificates for
the traffic-related functions; however, the TOE generates all session keys.)
These keys are generated upon the request of an administrator by a Key Generator process that
invokes the OpenSSL library on the Linux host. OpenSSL contains a pseudo-random number generator
that has been configured to derive entropy from the Linux host via the /dev/random device. An
Entropy Feeder process is invoked on an as needed basis to derive random numbers from the
underlying Cavium hardware via TMM, and to feed those into the entropy pool used by /dev/random.
Page 83 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
The Cavium hardware implements a physical noise source by using a large number of high-jitter
free-running oscillators with output mixed in a linear feedback shift register, as documented in
[US6954770].
The following table enumerates the types of keys that the TSF can generate:
Note: The actual involvement of the TOE in the generation of TLS session keys depends on the
key exchange method defined in the chosen cipher suite (see below), as well as the role (client or
server) that the TOE acts in for a specific connection. (For administrative sessions, the TOE always
acts as a server. For traffic sessions, the TOE may act as a TLS client or server.) In particular, this
results in the TOE's dependency on entropy for session keys (secrets) as follows:
● TOE is server:
❍ RSA: the pre_master_secret for further computational work is provided by the
client, i.e., the operational environment
❍ DHE, ECDHE: the TOE (as well as the client in the operational environment) both
generate a random secret as part of computing the shared key
● TOE is client:
❍ DHE, ECDHE: the TOE (as well as the server in the operational environment) both
generate a random secret as part of computing the shared key
All static keys such as the RSA key used for key transport and the static elliptic curve Diffie-Hellman
key used for key agreement, are generated as part of the TOE environment. The ephemeral keys
are generated within the TOE using domain parameters from the TOE environment.
7.1.4.2 Key Storage
Private keys, along with certificates, are stored in the TOE's configuration files and protected by
the operational environment.
Optionally, the evaluated configuration can make use of a FIPS 140-2 Level 2 validated cryptographic
module (if present) on the underlying system for the storage of RSA private keys that are used by
either the Cavium crypto accelerator or the TMM SSL stack when the TOE acts as a TLS server
toward remote network devices
2
.
Likewise, functionality offered by the cards to synchronize the content of crypto modules in the
redundant systems comprising the TOE, including the fipscardsync utility provided with BIG-IP for
convenience, are considered to be out of scope for this evaluation.
7.1.4.3 Certificate validation
For TLS sessions, the TOE implements certificate validation using the OpenSSL crypto library.
The TOE supports validation of X.509 digital certificates according to [RFC5280]☝. The TOE performs
full certificate chain checking using Public Key Infrastructure X.509, verifies the expiration of the
certificate (assuming a reliable time provided by the NTP server), and verifies its revocation using
locally Certificate Revocation Lists
This implements FTP_ITC.1.
7.1.4.4 Cryptographic primitives in the TOE
See the tables in section 7.1.4.7.
2
Please note that the FIPS 140-2 Level 2 validated cryptographic module was not subject to evaluation
Page 84 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
7.1.4.5 Random Number Generation
The TOE uses OpenSSL version 1.0 on the Linux host to generate key material, which is considered
part of the TOE.
OpenSSL's pseudo-random number generator derives its seeds via /dev/random from the entropy
pool of the underlying Linux host. This entropy pool, in turn, is primarily seeded by a physical noise
source in the runtime environment, i.e., a Cavium crypto co-processor. This happens by means of
a helper process that pools random numbers from the Cavium chip via its published APIs, and
periodically feeds them into /dev/random.
The Cavium chip implements a physical noise source by using a large number of
high-jitterfree-running oscillators. Their output is mixed in a linear feedback shift register, and goes
through a SHA-1 hash engine in order to generate random numbers. As a result, the processor's
physical noise source is (indirectly) providing the entropy for OpenSSL's random number generator.
The design how the entropy from the CAVIUM chip feeds into /dev/random can be characterized as
follows:
● The TMM subsystem implements a driver to obtain random numbers from the CAVIUM chip.
That driver exports the CAVIUM random data to a server listening on 127.1.1.2 port 3. A
simple network request is able to obtain as many bytes as requested by the calling process.
● A daemon process implemented by F5 opens /dev/random and initializes a select() on the
file descriptor. This select is triggered by the kernel when the entropy estimator for
/dev/random shows that it runs low on entropy. If the kernel triggers the poll, the daemon
process is woken up.
● Once the daemon is woken up, it reads 512 bytes from the TMM-exported CAVIUM random
numbers and writes them into /dev/random using the IOCTL RNDADDENTROPY
. The key
now is that the IOCTL on /dev/random mixes the random data into the blocking_pool and
nonblocking_pool and updates the entropy estimator by the number of bits written divided
by 512 (i.e. the code implies that 512 bits from Cavium contain 1 bit of entropy). The
daemon goes back to sleep afterwards to wait for the next select trigger.
The design discussion shows the following properties:
● Entropy gathered from the hardware RNG is injected into the input_pool of the Linux RNG
using the mentioned IOCTL.
● The entropy estimator of the input_pool is updated by the number of bytes added to the
input_pool divided by 512. This implies that the code assumes that 512 bits of data read
from the Cavium hardware RNG contains one bit of entropy.
● Due to the frequent updates of the input_pool and corresponding update of the entropy
estimator, the input_pool is able to deliver large amounts of entropy to the blocking_pool.
This very fact can be interpreted such that (almost the entire) strength of /dev/random
rests on the entropy that is collected from the Cavium hardware RNG. In the extreme case,
no entropy from the Linux RNG original sources (HID, block devices, IRQs) are used; all
entropy /dev/random provides is derived from the Cavium hardware RNG.
● The blocking behavior of /dev/random remains untouched. On the other hand, the Cavium
hardware RNG can deliver random numbers at a very fast speed. The connection of the
Linux RNG and the Cavium hardware RNG is such that every time the Linux RNG's entropy
runs low, fresh entropy from the Cavium hardware RNG is delivered. This implies that the
threshold that would cause /dev/random to block is rarely hit, if at all.
Page 85 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
The amount of entropy produced by the noise source and provided through the Cavium chip's
random number API is in excess of 200 Mbps. Random numbers are polled from the chip once per
hour and fed into the Linux host's entropy pool. While there are other entropy sources fed by the
Linux kernel into its entropy pool, this happens at a significantly slower rate.
Due to the large number of oscillators (> 100), failure of a number of them will not degrade the
quality of the random numbers provided by the Cavium chip and used as entropy source. The
underlying Cavium hardware implements the design described in [US6954770], which provides for
independence from time, and reduces exposure to environmental conditions (like temperature
changes) to negligible amounts of risk, in particular since the TOE hardware itself will be hosted in
physically protected data centers.
This implements FCS_RBG_EXT.1.
7.1.4.6 Zeroization of Critical Security Parameters
“Cryptographic Critical Security Parameters” are defined in FIPS 140-2 as “security-related
information (e.g., secret and private cryptographic keys, and authentication data such as passwords
and PINs) whose disclosure or modification can compromise the security of a cryptographic module.”
The following table discusses how the cryptographic modules of the TOE, zeroize critical security
parameters that are not needed for operation of the TSF anymore. This also includes key material
used by the TSF that is stored outside of the crypto modules.
How?
Zeroized when?
Location
Key type
Application
These are zeroized in
OpenSSL by calling
OPENSSL_cleanse(),
which overwrites the
memory upon release
After key has been
generated.
Stack/heap
seeds,
prime
numbers,
etc.
Key generation
These are zeroized in
OpenSSL by calling
OPENSSL_cleanse(),
which overwrites the
memory upon release
After session has
ended
Stack/heap
Session
keys
SSL/TLS
Private keys are
zeroized when they
are deleted by the
Upon deletion by
administrator.
On the disk
private
keys in TLS
certificates
SSL/TLS
administrator.
Zeroization is done by
overwriting the file
once with zeroes and
deleting the file.
These are zeroized in
OpenSSL by calling
OPENSSL_cleanse(),
which overwrites the
memory upon release
After session has
ended
Stack/heap
Session
keys
SSH
SSH keys are zeroized
when using the
key-swap utility.
Upon deletion by
administrator.
On the disk
SSH keys
SSH
Page 86 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
How?
Zeroized when?
Location
Key type
Application
Zeroization is done by
overwriting the file
once with zeroes and
deleting the file.
Table 16: Zeroization of Critical Security Parameters
This implements FCS_CKM_EXT.4.
7.1.4.7 Crypto Statement
The following table shows the cryptographic function of TLS used in the TOE.
Comments
Key Size
[Bits]
Standard of
Implementation
Cryptographic
Mechanisms
Purpose
#
Algorithms used
depending on the
signature algorithm /
Modulus
length:
2048,
3072,
4096
[FIPSPUB186-3]
3
(RSA)
referring to
[RFC3447]☝ (PKCS#1
v2.1)
[FIPSPUB180-3]
4
(SHA)
RSA signature
verification
(RSASSA-PKCS1-v1_5)
using SHA-1
Authenticity
1
hash algorithm used
for signing the
certificates and the
accepted signature
Modulus
length:
2048,
3072
4096
[RFC3447]☝
(PKCS#1 v2.1)
[FIPSPUB180-3] (SHA)
RSA signature
verification
(RSASSA-PKCS1-v1_5)
using SHA-256,
SHA-384
2 algorithms / hash
algorithms by the
peers.
Server certificates
required and client
certificates optional.
secp256r1
NIST P-256
[FIPSPUB186-3]
(ECDSA),
ECDSA signature
generation and
verification using
SHA-1
3
Verification of
certificate signatures
provided for
authentication of
peers.
[FIPSPUB180-3] (SHA),
secp256r1
[FIPSPUB186-3]
(ECDSA),
ECDSA signature
generation and
verification using
SHA-256, SHA-384
4
The certificates are
not generated by the
TOE* (imported into
the TOE).
NIST P-256
[FIPSPUB180-3] (SHA),
3
Note, that [FIPSPUB186-3] is obsoleted by [FIPSPUB186-4]
4
Note, that [FIPSPUB180-3] is obsoleted by [FIPSPUB180-4]
Page 87 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Comments
Key Size
[Bits]
Standard of
Implementation
Cryptographic
Mechanisms
Purpose
#
Certificates with
signing capability.
Modulus
length:
2048,
3072,
4096
[RFC3447]☝
(PKCS#1 v2.1)
[RFC5246]☝
(TLS 1.2)
RSA signature
generation (client) and
verification (server).
(RSASSA-PKCS1-v1_5
5
)
using SHA-1
Authentication
Client
Depending on
client's certificate
if any (subject
public key info
and key usage).
5
Client cert type:
rsa_sign.
CertificateVerify:
Client provides
signature over the
whole handshake
message
Modulus
length:
2048,
3072
4096
[RFC3447]☝
(PKCS#1 v2.1)
[RFC5246]☝
(TLS 1.2)
RSA signature
generation (client) and
verification (server).
(RSASSA-PKCS1-v1_5)
using SHA-256,
SHA-384
6
Only for TLSv1.1
Modulus
length:
2048,
3072
4096
[RFC3447]☝
(PKCS#1 v2.1)
[RFC4346](TLSv1.1)
RSA signature
generation (client) and
verification (server).
(RSASSA-PKCS1-v1_5)
using MD5 / SHA-1
combination
7
Client cert Type:
ecdsa_sign.
secp256r1
NIST P-256
[FIPSPUB186-3]
(ECDSA),
ECDSA signature
generation and
verification using
SHA-1
8
The public key of the
certificate MUST use a
curve and point
format supported by
the server .
[FIPSPUB180-3] (SHA),
[RFC4492]☝
(ECC for TLS)
secp256r1
[FIPSPUB186-3]
(ECDSA),
ECDSA signature
generation and
verification using
SHA-256, SHA-384
9
NIST P-256
[FIPSPUB180-3] (SHA),
[RFC4492]☝
(ECC for TLS)
Please refer to PRF
within key derivation
below.
[RFC5246]☝
(TLSv1.2)
[RFC4346]
Generating and
verifying the PRF
contained in the
“Finished message”.
Authentication
Server (static)
6
10
(TLSv1.1)
5
implicitly EMSA-PKCS1-v1_5 encoding method is required based on block type 1 (PS= FF).
6
Static keys / parameter contained in the certificate. Server Certificate must contain the RSA key or the ECDH parameters
pub key. Key usage encipherment (RSA) and key exchange for (ECDH params). By successfully decoding the premaster
secret (RSA) or computing / agree upon the premaster secret ECDH shared secret) and producing a correct “Finished
message” with the master secret derived from the premaster secret as key , the server demonstrates that it knows the
private key corresponding to the certificate. For TLS >= 1.1 it is only historical to list the key authentication key within
the cipher since cert signing is not any longer bound to the key contained in the cipher provided for key authentication.
Page 88 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Comments
Key Size
[Bits]
Standard of
Implementation
Cryptographic
Mechanisms
Purpose
#
(TLS_RSA, TLS_ECDH)
See above, however
with RSA as signature
algorithm.
Modulus
length:
2048,
3072
4096
[RFC3447]☝
(PKCS#1 v2.1)
[FIPSPUB180-3] (SHA)
[RFC5246]☝
(TLSv1.2)
RSA signature
generation and
verification
(RSASSA-PKCS1-v1_5)
using SHA-1
(TLS_ECDHE_RSA)
Authentication
Server
(ephemeral)
11
Modulus
length:
2048,
3072
4096
[RFC3447]☝(PKCS#1
v2.1)
[FIPSPUB180-3] (SHA)
[RFC5246]☝
(TLSv1.2)
RSA signature
generation and
verification
(RSASSA-PKCS1-v1_5)
using SHA-256,
SHA-384
12
(TLS_ECDHE_RSA)
For TLS 1.1.
Modulus
length:
2048,
3072
4096
[RFC3447]☝(PKCS#1
v2.1)
[RFC4346]
(TLSv1.1)
RSA signature
generation (client) and
verification (server).
(RSASSA-PKCS1-v1_5)
using MD5 / SHA-1
combination
13
See above however
with ECDSA as
signature algorithm.
secp256r1
NIST P-256
[ANSI X9.62] (ECDSA),
[FIPSPUB180-3] (SHA),
[RFC4492]☝
(ECC for TLS)
ECDSA signature
generation and
verification using
SHA_1
(TLS_ECDHE_ECDSA)
14
secp256r1
[ANSI X9.62] (ECDSA),
ECDSA signature
generation and
verification using
SHA-256, SHA-384
15
NIST P-256
[FIPSPUB180-3]
(SHA),
[RFC4492]☝
(ECC for TLS),
(TLS_ECDHE_ECDSA)
Server certificate is
used for key
exchange.
Modulus
length:
2048,
3072
4096
[RFC3447]☝ (PKCS#1
v2.1)
[SP800-56B]
(IFC key
establishment)
RSA encryption (client)
and decryption
(server)
(RSAES-PKCS1-v1_5
7
)
(TLS_RSA)
Key
establishment:
Key transport
16
Encrypted exchange
of pre-master secret
generated at client
side.
7
implicitly EME-PKCS1-v1_5 encoding method is required based on block type 2 (PS= random data)
Page 89 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Comments
Key Size
[Bits]
Standard of
Implementation
Cryptographic
Mechanisms
Purpose
#
Server authentication
(#14)
Unauthenticated
ephemeral ECDH key
/ parameters provided
by the server in the
ServerKeyExchange.
secp256r1
NIST P-256
[RFC4492]☝
(ECC for TLS)
[TR-03111]
(ECC)
ECDHE
Key
establishment:
Key agreement
Ephemeral
17
This is the only curve
that is hard coded in
the TOE.
[SP800-56-A]
(ECC DH)
The ECDH-parameters
contained in the
certificate (static).
secp256r1
NIST P-256
[RFC4492]☝
(ECC for TLS)
[TR-03111]
(ECC)
ECDH
Static
18
Since NIST P-256 is
the only curve hard
coded in the TOE –
[SP800-56-A]
(ECC DH) only certificates with
ECDH parameters
based on NIST P-256
will work.
Server authentication
(#14)
Symmetric keys and
MAC keys for record
layer.
variable
[FIPS198-1] (HMAC)
[FIPSPUB180-3] (SHA)
PRF: HMAC with
SHA-256, 384
(default: prf_sha256
for TLSv1.2, also
prf_sha384 possible)
Key derivation
19
Pre-master secret /
(DH / ECDH shared
secret) is converted
[RFC5246]☝ (TLSv1.2)
variable
[FIPSPUB198-1]
(HMAC)
PRF: HMAC with MD5
and SHA-1 in
combination(default:
prf for TLS v1.1)
20 into the master secret,
the keys of the record
layer are generated by
expanding the master
secret using the
[RFC1321]☝, RFC6151]
(MD5)
security parameters of
the handshake
protocol.
[FIPSPUB180-3] (SHA)
[RFC4346]
( TLS v1. 1 )
Bulk data encryption /
decryption(record
layer)
|k|=128, 256
[FIPSPUB197] (AES)
[SP800-38A] (CBC)
AES in CBC mode
(AES_128_CBC,
AES_256_CBC)
Confidentiality
21
Supported by AES-NI
|k|=128, 256
[FIPSPUB197] (AES)
AES in GCM mode
Authenticated
Encryption
22
Page 90 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Comments
Key Size
[Bits]
Standard of
Implementation
Cryptographic
Mechanisms
Purpose
#
[RFC5228]☝ (AES GCM
within TLS)
(AES_128_GCM,
AES_256_GCM)
Message
authentication code
160 (SHA-1)
256 (SHA-256)
[FIPS198-1] (HMAC)
[FIPSPUB180-3] (SHA)
HMAC with
SHA-1 or SHA-256
or SHA-384
Integrity and
authenticity
23
(record layer)
384(SHA-384)
(SHA), (SHA256),
(SHA384)
See above
Cf. all lines above
FTP_ITC.1 [ST], sec.
6.1. 10.1 for HTTPS,
syslog
Trusted Channel
24
Table 17: Cryptograhic functions of TLS
The following table shows the cryptographic function of SSH used in the TOE.
Comment
Key Size
Bits
Standard of
Implementation
Cryptographic
Mechanisms
Purpose
#
Pubkeys are
exchanged
trustworthy out of
band.
Modulus
length: 1024
[RFC3447]☝ (PKCS#1
v2.1)
[FIPSPUB180-3]
(SHA-1)
RSA signature
generation &
verification
RSASSAPKCS1-v1_5
using SHA-1
Authentication
1
Authenticity is not part
of the TOE.
[RFC4253]
(SSH-TRANS)
for host authentication
(ssh-rsa)
(no certificates used,
server lists are in
general possible at the
[RFC4252], sec 7
(SSH-USERAUTH) for
user authentication
client side – however
client is not part of the
TOE ).
method: “publickey”
ST FIA_AFL.1:
Guess success
prob.
[RFC4252], sec.
(SSH-USERAUTH)
UserID & password
2
Recommendation as
of [ECG] not to change
the default setting
method; “password”
where the blocking
after 3 attempts is
configured. Min 15
characters.
No FIA_SOS claimed.
Page 91 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Comment
Key Size
Bits
Standard of
Implementation
Cryptographic
Mechanisms
Purpose
#
Hard coded in the TOE
code.
plength=
2048
[RFC4253]
(SSH-TRANS)
supported by
[RFC3526]☝ (DH
groups IKE)
DH with
DH group14-sha1
Key
establishment:
Key agreement
3
[FIPSPUB180-3]
(SHA-1)
Binary packet
protocol: encryption
|k|= 256
[FIPS197] (AES),
[SP800-38A] (CBC),
AES in CBC mode
(aes256-cbc)
Confidentiality
4
Configured per
ccmode script.
[RFC4253] (SSH using
AES with CBC mode),
Binary packet
protocol:
|k|=160
[FIPSPUB180-3] (SHA),
[RFC2104]☝ (HMAC),
HMAC-SHA-1
Integrity and
authenticity
5
message
authentication
[RFC4251] /
[RFC4253] (SSH
general / detailed
HMAC support),
[RFC4253] (SSH
detailed HMAC
support)
FCS_CKM.1 Host key
generation using
FCS_RBG_EXT.1
n/a
[FIPSPUB186-2], A.2.1
for Miller Rabin
primality tests.
RSA key generation
Key generation
6
FTP_TRP.1, section
6.1.10.2 for SSH
Trusted path
7
Table 18: Cryptograhic functions of SSH
7.1.5 TSF Protection and Support Functions
7.1.5.1 Failover of Redundant Systems
The TOE is comprised of two identically configured BIG-IP, i.e., same Part Number, systems running
on homogenous hardware in a failover configuration. As a result, failure of (services on) one device
will result in services being taken over by the redundant device.
failover requires the two devices of the evaluated configuration to be configured in a device group
as a failover group, with one device being configured as active (the preferred device) and the other
one configured as being in standby.
This involves, in principle, the following mechanisms:
1. Synchronization of configuration data between the two devices.
Page 92 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
2. Synchronization of service availability between the two devices.
3. Optionally, state and persistence mirroring for network connections, for some protocols.
Synchronization of configuration data is implemented using BIG-IP's Central Management
Infrastructure (CMI) architecture. The devices synchronize individual configuration changes, once
they are committed, via messages sent through a dedicated network connection over the
management network port. If device A becomes unavailable, device B will implement configuration
changes locally and queue them for synchronization, which will occur once device A is available
again.
State and persistence monitoring allows the TMM instances on the active and standby devices to
exchange information about the state of individual traffic connections currently being handled by
the active device via dedicated ports on network switches of the devices.
failover monitoring is performed both on the active and the standby device. A dedicated "overdog"
process on the active device monitors the hearbeat of all critical daemons on the device, and
communicates missing local hearbeats to a dedicated "switchover daemon" (sod). If the active
device determines that it cannot reliable provide all services anymore, it will co-ordinate a failover
to the standy device via CMI.
In addition, if the standby device detects missing heartbeats/communication from the active device,
the standby device will become active and start managing traffic. even in the absence of a failure
report from the active device. Regardless of whether state and persistence monitoring are enabled
or not, the TOE as a whole will maintain a secure state, i.e., the enforcement of all security policies
configured on the devices continues both for existing and new connections handled by the TOE.
State mirroring occurs at the transport layer. It does not apply to encrypted sessions.
Configuration data between the devices is exchanged over a dedicated line.
This functionality implements FPT_FLS.1.
7.1.5.2 Self-tests
The following self-test are implemented by the TOE:
1. The BIOS POST test is run at boot time
2. The OpenSSL integrity tests are run at boot for OpenSSL and for TMM SSL.
3. The sys-icheck utility is run at boot and restart to check the integrity of the RPMs
This functionality implements FPT_TST_EXT.1.
7.1.5.3 Update Verification
While the evaluated configuration of the TOE is limited to the specific version and patch level of
BIG-IP covered in this ST, the TOE nevertheless provides functionality that supports administrators
in verifying the integrity and authenticity of patches provided by F5.
The TOE is able to validate digital signatures of hotfixes provided by F5; F5 places the ISO hotfix
files (updates) and signature files on their website. The administrative guidance instructs the
customer to:
● Download the hotfix ISO and digital signature file
● Verify the ISO using that file
● Install the hotfix
This functionality implements FPT_TUD_EXT.1 and FMT_SMF.1.
Page 93 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
7.1.5.4 Denial-of-Service Mitigation
The TOE implements multiple mechanisms to both mitigate network-originated DOS attacks that
might lead to service degradation in particular, and resource exhaustion that might lead to loss of
administrative control over the TOE in particular.
On the administrative interface side, this starts with the architectural property of having a dedicated
network interface for device management traffic. TMM, as part of the dataplane that is handling
the external (non-management) network traffic mediated by the TOE, is not involved in serving
this interface, i.e. administrators can reach and configure the TOE without TMM being available on
the system. In addition, administrators can configure the maximum number of concurrent sessions
that the Configuration utility should accept.
In order to mitigate flooding attacks, administrators can define time-outs for inactive TCP and UDP
connections in traffic profiles. If a connection does not show activity past that amount of time, it
will be dropped.
When it comes to traffic processing, the TOE allocates dedicated memory to each TMM instance,
and to the base Linux system hosting the configuration and management mechanisms.
Administrators can specify quotas that activate TOE behavior to actively control the amount of
connections mediated by the device based on how much memory TMM is currently using to handle
existing connections.
This is implemented by BIG-IP's adaptive reaper mechanism. During normal operations, BIG-IP
removes expired sessions entries from TMM's connection table as described above. When an
administrator-specified "low-water mark threshold" is reached, the reaper mechanism is activated
and parses connection table entries following a defined schedule in order to remove additional
connection table entries in relation to the administrator-specified "hi-water mark threshold" as
follows:
● If the relative level (number of connections) is greater than 20 % of the difference between
lo-water and hi-water marks, the reaper mechanism will scale down the time-out for each
connection, i.e., reduce the "normal" time-out, based on that level, and terminate
connections based on that reduced time-out.
● If the relative level is greater than 50 %, the reaper will terminate connections that show
a throughput rate of less than one packet per second of traffic.
● If the relative level is greater than 90 %, the reaper will randomly select 1/4 of connections
and terminate them without sending a connection RST.
If the amount of memory used by TMM exceeds a certain percentage of the overall memory allocated
to TMM, as specified by the administrator-defined high-water mark threshold, the TOE will not
accept any new connections, but will continue to serve established connections.
This functionality implements FRU_RSA.1.
7.1.5.5 Protection of Sensitive Data
The TOE protects passwords used for the authentication of administrative users as follows:
● In storage for local user authentication
The TOE uses the underlying operating system for authentication of local user accounts.
The TOE's administrative interfaces do not offer any sort of retrieval of user passwords or
configuration files used by the underlying system.
● In transit between the TOE and authentication services
Page 94 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
See section 7.1.1.5.
● In transit between remote users and the TOE
See section 7.1.1.5.
Pre-shared keys, symmetric keys, and private keys are protected as follows:
● Pre-shared keys, such as credentials for remote servers, are stored in the TOE's configuration
files.
This functionality implements FPT_APW_EXT.1 and FPT_SKP_EXT.1.
7.1.5.6 Residual Information Protection
Per the NDPP application note for FDP_RIP.2, “Resources” in the context of the FDP_RIP.2 requirement
are network packets being sent through the TOE, therefore, the concern is that outgoing network
packets do not unknowingly contain data that contains residual information. Each outgoing packet
is comprised of data from one or more segment of physical memory; each linked with a header
that contains the start address and the number of bytes to written into a part of the outgoing packet.
When the packet is ready to be transmitted, for each segment that makes the packet, the
corresponding physical address and of bytes (obtained from the header for that piece) is sent to
the DMA driver code, which performs the DMA operations.
For any packet that is smaller than minimum payload size, the rest of the bytes that makes the
minimum size are zeroed out with memclr().
The DMA driver DMAs only set count of bytes for each piece of the outgoing packet
This functionality implements FDP_RIP.2.
Page 95 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
8 Abbreviations, Terminology and References
8.1 Abbreviations
AD
Active Directory
ADC
Application Delivery Controller
ADF
Application Delivery Firewall
CMI
Central Management Infrastructure
CRL
Certificate Revocation List
CRLDP
Certificate Revocation List Distribution Point
FPGA
Field-Programmable Gate Array
FTP
File Transfer Protocol
GUI
Graphical User Interface
HSB
High-Speed Bridge
HSL
High-Speed Logging
LTM
Local Traffic Manager
OCSP
Online Certificate Status Protocol
RTSP
Real Time Streaming Protocol
SIP
Session Initiation Protocol
SOAP
Simple Object Access Protocol
TACACS+
Terminal Access Controller Access-Control System
TLS
Transport Layer Security
TMM
Traffic Managment Microkernel
Page 96 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
TMOS
Traffic Management Operating System
vCMP
Virtual Clustered Multi-Processing
8.2 Terminology
This section contains definitions of technical terms that are used with a meaning specific to this
document. Terms defined in the [CC] are not reiterated here, unless stated otherwise.
Administrators
Administrators are administrative users of the TOE, i.e. those users defined in the TOE to be
authorized to access the configuration interfaces of the TOE. Different roles can be assigned to
administrators, including the Administrator role -- the name of the role is not to be confused
with the general reference to an administrator being an administrative user of the TOE in any
role.
User
Humans or machines interacting with the TOE via the provided user and programmatic interfaces.
The TOE deals with different types of users -- administrators in charge of configuring and
operating the TOE, traffic users who are subject to the TOE's security capabilities and functions.
8.3 References
Funktionalitätsklassen und Evaluierungsmethodologie für
deterministische Zufallszahlengeneratoren
AIS_20
3
Version
2013-05-15
Date
Common Criteria for Information Technology Security Evaluation
CC
3.1R4
Version
September 2012
Date
http://www.commoncriteriaportal.org/files/ccfiles/CC
PART1V3.1R4.pdf
Location
http://www.commoncriteriaportal.org/files/ccfiles/CC
PART2V3.1R4.pdf
Location
http://www.commoncriteriaportal.org/files/ccfiles/CC
PART3V3.1R4.pdf
Location
Guidance Supplement: AGD_PRE and AGD_OPE
ECG
1.17
Version
2014-12-15
Date
FIPS PUB 197: Specification for the ADVANCED ENCRYPTION STANDARD
(AES).
FIPS197
November 26, 2001
Date
FIPS PUB 180-3: Secure Hash Standard (SHS)
FIPSPUB180-3
October 2008
Date
Page 97 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
FIPS PUB 180-4: Secure Hash Standard (SHS)
FIPSPUB180-4
August, 2015
Date
FIPS PUB 186-2: DIGITAL SIGNATURE STANDARD (DSS)
FIPSPUB186-2
2000, January 27
Date
FIPS PUB 186-3: Digital Signature Standard
FIPSPUB186-3
June, 2009
Date
FIPS PUB 180-4: Digital Signature Standard (DSS)
FIPSPUB186-4
July, 2013
Date
Federal Information Processing Standards Publication 197: Specification
for the Advanced Encryption Standard (AES)
FIPSPUB197
November 26, 2001
Date
FIPS PUB 198-1: The Keyed-Hash Message Authentication Code (HMAC)
FIPSPUB198-1
July 2008
Date
Commands - DevCentral Wiki (registration required)
iRules_COM
MANDS 2012-03-16
Date received
https://devcentral.f5.com/wiki/iRules.Commands.ashx
Location
Events - DevCentral Wiki (registration required)
iRules_EVENTS
2012-03-16
Date received
https://devcentral.f5.com/wiki/iRules.Events.ashx
Location
Protection Profile for Network Devices
NDPP
NSA Information Assurance Directorate
Author(s)
1.1
Version
2012-06-08
Date
NIST Special Publication 800-90A: Recommendation for Random Number
Generation Using Deterministic Random Bit Generators
NIST800-90A
January 2012
Date
The MD5 Message-Digest Algorithm
RFC1321
R. Rivest
Author(s)
1992-04-01
Date
http://www.ietf.org/rfc/rfc1321.txt
Location
HMAC: Keyed-Hashing for Message Authentication
RFC2104
H. Krawczyk, M. Bellare, R. Canetti
Author(s)
1997-02-01
Date
http://www.ietf.org/rfc/rfc2104.txt
Location
RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1
RFC2616
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach,
T. Berners-Lee
Author(s)
June 1999
Date
Page 98 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
RFC 2818: HTTP Over TLS
RFC2818
E. Rescorla
Author(s)
May 2000
Date
Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography
Specifications Version 2.1
RFC3447
J. Jonsson, B. Kaliski
Author(s)
2003-02-01
Date
http://www.ietf.org/rfc/rfc3447.txt
Location
More Modular Exponential (MODP) Diffie-Hellman groups for Internet
Key Exchange (IKE)
RFC3526
T. Kivinen, M. Kojo
Author(s)
2003-05-01
Date
http://www.ietf.org/rfc/rfc3526.txt
Location
RFC 4251: The Secure Shell (SSH) Protocol Architecture
RFC4251
T. Ylonen, C. Lonvick, Ed.
Author(s)
January 2006
Date
RFC 4252: The Secure Shell (SSH) Authentication Protocol
RFC4252
T. Ylonen, C. Lonvick, Ed.
Author(s)
January 2006
Date
RFC 4253: The Secure Shell (SSH) Transport Layer Protocol
RFC4253
T. Ylonen, C. Lonvick, Ed.
Author(s)
January 2006
Date
RFC 4254: The Secure Shell (SSH) Connection Protocol
RFC4254
T. Ylonen, C. Lonvick, Ed.
Author(s)
January 2006
Date
RFC 4346: The Transport Layer Security (TLS) Protocol Version 1.1
RFC4346
T. Dierks, E. Rescorla
Author(s)
April 2006
Date
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS)
RFC4492
S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller
Author(s)
2006-05-01
Date
http://www.ietf.org/rfc/rfc4492.txt
Location
Sieve: An Email Filtering Language
RFC5228
P. Guenther, T. Showalter
Author(s)
2008-01-01
Date
http://www.ietf.org/rfc/rfc5228.txt
Location
The Transport Layer Security (TLS) Protocol Version 1.2
RFC5246
T. Dierks, E. Rescorla
Author(s)
2008-08-01
Date
http://www.ietf.org/rfc/rfc5246.txt
Location
Page 99 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target
Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile
RFC5280
D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W.
Polk
Author(s)
2008-05-01
Date
http://www.ietf.org/rfc/rfc5280.txt
Location
Tcl Reference Manual
Tcl
2012-03-16
Date received
http://tmml.sourceforge.net/doc/tcl/index.html
Location
Random Number Generator. United States Patent No. US 6,954,770
US6954770
David A. Carlson, Gregg A. Bouchard, Anand Varadharajan, Derek
S. Brasili
Author(s)
Oct. 11, 2005
Date
Page 100 of 100
Version: 1.6
Copyright © 2017 by atsec information security and F5 Networks
Last update: 2018-02-12
F5 Networks, Inc.
BIG-IP 11.5.1 HF 10 (build 10.123.180) ADC-AP Security
Target