Security Target Version 1.0 packet filter 5.1.0 Certification-ID: BSI-DSZ-CC-0991 Authors: Christian Koob, Jörg Marx, Martin Matthes Version 1.0, 03/08/2016 secunet Security Networks AG secunet(wall 2 Version 1.0, 03/08/2016 Copyright © 2016 by secunet Security Networks AG Use of customary names, trade names, trademarks etc. in this document does not give rise to any presumption that such names are to be regarded as being free within the meaning of the trademark and brand protection acts. All brand and product are trademarks or registered trademarks of their respective owners. Documentation history Version Date Change(s) Author(s) 0.91 09/04/2015 Version for packet filter 5.1.0 with Comments from evaluation facility: - Component instead module - A.SECINIT und OE.SECINIT deleted - Only SSH in environment - Rationale for T.BYPASS changed Martin Matthes 1.0 03/08/2016 - New document template added - Copyright changed Martin Matthes, Christian Koob secunet(wall Version 1.0, 03/08/2016 3 Contents Contents................................................................................................................................ 3 List of Tables......................................................................................................................... 5 1 ST INTRODUCTION...................................................................................................... 6 1.1 ST reference and TOE reference ........................................................................ 6 1.2 TOE Overview..................................................................................................... 6 1.2.1 Usage, major security features and TOE type ....................................... 6 1.2.2 Required non TOE hardware/software/firmware .................................... 8 1.3 TOE Description.................................................................................................. 9 1.3.1 Physical scope of the TOE .................................................................... 9 1.3.2 Logical scope of the TOE ...................................................................... 9 1.3.2.1 Audit Data.............................................................................................. 9 1.3.2.2 Information Flow Protection ................................................................... 9 1.3.2.3 Management ........................................................................................10 1.3.2.4 Components.........................................................................................10 2 CONFORMANCE CLAIM .............................................................................................11 2.1 CC Conformance Claim .....................................................................................11 2.2 PP and security requirement package claim.......................................................11 2.3 CC Conformance Claim Rationale......................................................................11 3 SECURITY PROBLEM DEFINITION ............................................................................12 3.1 Assets................................................................................................................12 3.2 Subjects .............................................................................................................13 3.3 External entities..................................................................................................13 3.4 Assumptions ......................................................................................................14 3.5 Threats...............................................................................................................15 3.6 Organisational security policies ..........................................................................15 4 STATEMENT OF SECURITY OBJECTIVES ................................................................16 4.1 Security Objectives for the TOE .........................................................................16 4.2 Security Objectives for the Operational Environment..........................................17 4.3 Security Objectives Rationale.............................................................................18 4.3.1 Countering the threats ..........................................................................19 4.3.2 Covering the OSPs...............................................................................19 secunet(wall 4 Version 1.0, 03/08/2016 4.3.3 Covering the assumptions ....................................................................19 5 STATEMENT OF SECURITY REQUIREMENTS..........................................................20 5.1 Security functional requirements for the TOE .....................................................20 5.1.1 Security Audit .......................................................................................21 5.1.1.1 FAU_GEN.1 Audit data generation.......................................................21 5.1.2 User data protection (FDP)...................................................................21 5.1.2.1 FDP_IFC.1 Subset information flow control ..........................................21 5.1.2.2 FDP_IFF.1 Simple security attributes ...................................................22 5.1.3 User identification (UID)........................................................................23 5.1.3.1 FIA_UID.1 Timing of identification ........................................................23 5.1.4 Security management (FMT) ................................................................25 5.1.4.1 FMT_MSA.1 Management of security attributes ...................................25 5.1.4.2 FMT_MSA.3 Static attribute initialization ..............................................25 5.1.4.3 FMT_SMF.1 Specification of management functions............................26 5.1.4.4 FMT_SMR.1 Security roles...................................................................26 5.2 Extended Components definition........................................................................26 5.3 Security assurance requirements for the TOE....................................................27 5.4 Security Requirements Rationale .......................................................................28 5.4.1 TOE functional requirements rationale..................................................28 5.4.2 Fulfilling the SFR dependencies ...........................................................29 5.4.3 Security assurance requirements rationale...........................................29 6 TOE SUMMARY SPECIFICATION...............................................................................30 6.1 TOE security functionality...................................................................................30 6.1.1 SF1 Information Flow Protection...........................................................30 6.1.2 SF2 Security Audit................................................................................30 6.1.3 SF3 Management.................................................................................31 7 GLOSSARY AND ACRONYMS....................................................................................32 8 REFERENCES.............................................................................................................33 secunet(wall Version 1.0, 03/08/2016 5 List of Tables Table 1: Scope of TOE delivery............................................................................................. 9 Table 2: secunet wall packet filter components ....................................................................10 Table 3: Assets ....................................................................................................................12 Table 4: External entities......................................................................................................13 Table 5: Assumptions...........................................................................................................14 Table 6: Threats ...................................................................................................................15 Table 7: Security Objectives for the TOE..............................................................................16 Table 8: Security Objectives for the environment of the TOE................................................17 Table 9: Security Objective Rationale...................................................................................18 Table 10: Security Functional Requirements for the TOE.....................................................20 Table 11: Chosen Evaluation Assurance Requirements.......................................................27 Table 12: Coverage of Security Objective for the TOE by SFR.............................................28 Table 13: Fulfilling the SFR dependencies ...........................................................................29 List of Figures - secunet(wall 6 Version 1.0, 03/08/2016 1 ST INTRODUCTION 1.1 ST reference and TOE reference Title: secunet wall packet filter Security Target Sponsor: secunet Security Networks AG Editor(s): Christian Koob, Jörg Marx, Martin Matthes, secunet Security Networks-AG Version Number: 1.0 Date: 08.03.2016 CC Version: Version 3.1, Revision 4 Assurance Level: EAL4+, that is EAL4 augmented by ALC_FLR.2 Certification-ID: BSI-DSZ-CC-0991 Keywords: Firewall, Packet Filter, Network Security, Information flow control TOE name: secunet wall packet filter TOE version: Version 5.1.0 1.2 TOE Overview 1.2.1 Usage, major security features and TOE type This Security Target defines the security objectives and requirements for the secunet wall packet filter (TOE), a software component of secunet Security Networks AG. secunet wall packet filter provides packet filter functionality. secunet wall packet filter allows the integration of packet filter capability into firewall or VPN components which are parts of secunet wall or SINA product family. Thus the secunet wall packet filter is delivered to an application developer. The application developer integrates the secunet wall packet filter into an application in order to build a network component. The administrator of this application is defined as TOE end-user. When IP networks with different levels of security are interconnected, this is usually done by introducing special network components at the border of the networks. These components provide firewall functionality and separate the two or more networks from each other on different levels of the network stack. Data flow from one to another network can be allowed by a rule based policy enforced by these network components. The secunet wall packet filter consists of software on machines to implement packet filter functionality for the network components; i. e. the secunet wall packet filter is part of the network components. The secunet wall packet filter relies on information available at OSI layer 3 and layer 4 for policy enforcement. The functionality for packet filtering is part of the operating system (Linux). The secunet wall packet filter supports IPv4 [4]. secunet(wall Version 1.0, 03/08/2016 7 The TOE major security features are:  The TOE enforces the Packet Filter information flow policy. This policy ensures that the TOE will only forward data from and to the internal network if the information flow policy allows it.  The TOE collects audit data and sends it to a memory buffer in order to identify attempts to violate a policy.  The TOE is capable of performing management functions such as modification of networks filter traffic rules and configuration data.  The TOE verifies the identification information of an administrator provided by the environment (application) before any management function can be performed. The following security services are not part of the TOE and are thus to be provided by the IT environment (application):  The environment allows the Identification and Authentication of an administrator  Sending of audit data to a dedicated machine in the protected network The generation of networks filter traffic rules (policy) and configuration data takes place in the IT environment. The IT environment provides NTP service and Syslog service. After start-up of a network component that comprise the TOE and a secure initialisation process the initial TOE configuration data is read via I/O-control interface in the TOE system start-up process. The configuration data is the human readable content of the configuration file. The configuration data comprise IP address- and network interface definition, static routes and other system parameters. If no configuration data is available on start-up the TOE will not start-up automatically. secunet(wall 8 Version 1.0, 03/08/2016 1.2.2 Required non TOE hardware/software/firmware The TOE has the following minimal requirements concerning the physical machine they run on:  Intel i686 compatible CPU  PCI bus system  256 MB RAM  two 1000Mbit Ethernet Interfaces  storage entity (further requirements depend on the application)  USB Controller or Compact Flash Adapter The hardware must be compatible with the Linux operating system used for the application. The physical connections are:  power supply  network interfaces  PS/2- or USB-attached keyboard  VGA graphics adapter secunet(wall Version 1.0, 03/08/2016 9 1.3 TOE Description 1.3.1 Physical scope of the TOE The TOE consists of several components that are all running in Kernel-Space on the Linux operating system. These components are the following kernel parts: packet filter, management and audit mechanism. All other parts of the system are considered to be environment of the TOE. The TOE is delivered to an application developer. The TOE delivery includes the software secunet wall packet filter and documentation. This documentation contains information for the application developer and the TOE end-user. See the following table. The software component is electronically signed. Delivered TOE parts Version Remarks secunet wall packet filter CD-ROM Version 5.1.0 secunet wall packet filter Software documentation Version 1.0 Delivered as PDF on secunet wall packet filter CD-ROM Table 1: Scope of TOE delivery 1.3.2 Logical scope of the TOE 1.3.2.1 Audit Data The TOE collects audit data and sends it to a memory buffer in order to identify attempts to violate a policy. This allows the authorized administrator to inspect the current state of a network component. The TOE generates audit records for  start-up and shutdown of the audit functions  datagrams received or sent through a network components network interfaces if they match configured patterns 1.3.2.2 Information Flow Protection The TOE enforces the Packet Filter information flow policy. This policy ensures that the TOE will only forward data from and to the internal network if the information flow policy allows it. Therefore the TOE implements the information flow control (as routers) on the network layer (IP) and transport layer (TCP/UDP/ICMP). In order to apply the packet filter rules the network components take the information from the IP and TCP/UDP/ICMP-Header (where applicable). secunet(wall 10 Version 1.0, 03/08/2016 1.3.2.3 Management The TSF is capable of performing the following management functions:  Modification of network traffic filter rules  Modification of configuration data The TOE verifies the identification information of an administrator provided by the environment (application) before any management function can be performed. The TOE is initialized with a strict packet filter rule set, i. e. everything is dropped. 1.3.2.4 Components The secunet wall packet filter consists of several components. Table 2 shows which components are parts of the TOE and part of the IT environment. - IT environment TOE Kernel - Packet filter Audit mechanism Management User Space Secure transport mechanism for configuration data and audit data. Management (Configuration Tool) - Table 2: secunet wall packet filter components secunet(wall Version 1.0, 03/08/2016 11 2 CONFORMANCE CLAIM 2.1 CC Conformance Claim This Security Target and the TOE claim conformance to part 2 and part 3 of Common Criteria ([1] and [2]): Common Criteria Part 2 conformant Common Criteria Part 3 conformant 2.2 PP and security requirement package claim This Security Target does neither claim conformance to a Protection Profile nor to a security requirement package. 2.3 CC Conformance Claim Rationale As this Security Target does neither claim conformance to a Protection Profile nor to a security requirement package a conformance claim rationale is not necessary. secunet(wall 12 Version 1.0, 03/08/2016 3 SECURITY PROBLEM DEFINITION This chapter introduces the security problem definition of the TOE. This comprises:  The assets which have to be protected by the TOE.  The subjects which are interacting with the TOE.  The assumptions which have to be made about the environment of the TOE.  The threats which exist against the assets of the TOE  The organisational security policies the TOE has to comply to. 3.1 Assets The following assets need to be protected by the TOE and its environment: Asset Description TSF Data (Information Flow) Audit data transmitted from the network components to the management machine. Configuration data transmitted from the management machine to the network components. TSF Data (On the TOE) TSF data stored on the TOE which are necessary for its own operation. This includes packet filter rules or configuration data. Resources The resources in the connected networks that the TOE components are supposed to protect. The resources are outside the TOE components. Table 3: Assets secunet(wall Version 1.0, 03/08/2016 13 3.2 Subjects No active entity in the TOE that performs operations on objects is defined. 3.3 External entities The following external entities may interact with the TOE: External entity Description Administrator The administrator of a network component is an entity that has complete trust with respect to all policies implemented by the TSF. He is in charge of installing and configuring the TOE as well as performing the management functions of the TOE. User Any entity (human or IT) outside the TOE that interacts (or may interact) with the TOE. A goal of a user may be to access or modify sensitive information by sending IP packets to or receiving from the components of the TOE. This includes attacks from the protected networks behind the network components as well as attacks from outside those networks. Attackers with an Enhanced-Basic attack potential are assumed. Table 4: External entities secunet(wall 14 Version 1.0, 03/08/2016 3.4 Assumptions The following assumptions need to be made about the IT environment of the TOE to allow the secure operation of the TOE. Assumption Description A.ENV The TOE is used in a controlled environment. Specifi- cally it is assumed: That only the administrator gains physical access to the TOE, That the administrator handles the authentication se- crets (see A.I&A) with care, specifically that he will keep them secret and can use it in a way that nobody else can read it. A.NOEVIL The administrator of the TOE is non hostile, well trained and knows the documentation of the TOE. The administrator is responsible for the secure opera- tion of the TOE and its environment. A.INFLOW No information can flow between the internal and ex- ternal networks unless it passes through the TOE. A.CONFW The network components (TOE and application) are configured in a secure manner. Specifically it is as- sumed that no incoming connections are accepted except protected data (SSH, [3]) from the management machine. A.TSP The IT environment provides reliable timestamps (NTP server). A.PROT The data flow between the management machine and the network components is protected by cryptographic transforms (SSH authorization and SSH transport pro- tection as defined in [3]). A.AUDIT The IT environment provides a Syslog server and a means to present a readable view of the audit data. A.I&A The environment allows the Identification and Authenti- cation of an administrator. Table 5: Assumptions secunet(wall Version 1.0, 03/08/2016 15 3.5 Threats The following threats have to be countered by the TOE. Hereby attackers with an enhanced-basic attack potential are assumed. Threat Description T.BYPASS A user might attempt to bypass the security functions of the TOE in order to gain unauthorized access to resources in the protected networks. E. g., a user might send non-permissible data through the TOE in order to gain access to resources in protected networks by sending IP packets to circumvent filters. This attack may happen from outside the protected network. T.WEAKNESS A user might gain access to the TOE in order to read, modify or destroy TSF data by sending IP packets to the TOE and exploiting a weakness of the protocol used. This attack may happen from outside and inside the protected network. A user might also try to access sensitive data of the TOE via its management interface. Table 6: Threats 3.6 Organisational security policies The TOE does not enforce organisational security policies. secunet(wall 16 Version 1.0, 03/08/2016 4 STATEMENT OF SECURITY OBJECTIVES This chapter describes the security objectives for the TOE (in chapter 4.1), the security objectives for the operational environment of the TOE (in chapter 4.2) and contains the security objectives rationale. 4.1 Security Objectives for the TOE The following security objectives have to be met by the TOE Policy Description O.MANAGEMENT The TOE verifies the identification information of an administrator provided by the environment (application) before any management function can be performed. The TOE must provide the necessary management functions in order to modify the con- figuration data or the traffic filter rules. O.FILTER The TOE must filter the incoming and the outgoing data traffic of all data between all connected networks according to the rule sets. O.AUDIT The TOE must provide an audit trail of security-related events. Table 7: Security Objectives for the TOE secunet(wall Version 1.0, 03/08/2016 17 4.2 Security Objectives for the Operational Environment The following security objectives have to be met by the operational environment of the TOE. Policy Description OE.ENV The TOE is used in a controlled environment. Specifically it is assumed:  That only the administrator gains physical access to the TOE,  That the administrator handles the authentication secrets (see A.I&A) with care, specifically that he will keep them secret and can use it in a way that nobody else can read it. OE.NOEVIL The administrator of the TOE shall be non hostile, well trained and has to know the documentation of the TOE. The administrator is responsible for the secure operation of the TOE and its environ- ment. OE.INFLOW The administrator must assure that the packet filter components provide the only con- nection for the different networks. OE.CONFW The network components (TOE and application) must be configured to accept only protected data (SSH, [3]) from the management machine. OE.TSP The IT environment provides reliable timestamps (NTP server). OE.PROT The data flow between the management machine and the network components is pro- tected by cryptographic transforms (SSH authorization and SSH transport protection as defined in [3]). OE.AUDIT The IT environment provides a Syslog server and a means to present a readable view of the audit data. OE.I&A The environment allows the Identification and Authentication of an administrator. Table 8: Security Objectives for the environment of the TOE secunet(wall 18 Version 1.0, 03/08/2016 4.3 Security Objectives Rationale The following table provides an overview for security objectives coverage. The following chapters provide a more detailed explanation of this mapping. OE.ENV OE.NOEVIL OE.INFLOW OE.CONFW OE.TSP OE.PROT OE.AUDIT OE.I&A O.FILTER O.AUDIT O.MANAGEMENT A.ENV X A.NOEVIL X A.INFLOW X A.CONFW X A.TSP X A.PROT X A.AUDIT X A.I&A X T.BYPASS X X X X T.WEAKNESS X X X X X Table 9: Security Objective Rationale secunet(wall Version 1.0, 03/08/2016 19 4.3.1 Countering the threats The threat T.BYPASSSS which describes that an attacker may bypass the security functions of the TOE in order to gain unauthorized access to resources in the protected networks is countered by a combination of the objectives OE.PROT, OE.ENV, OE.INFLOW and O.FILTER. The environmental objectives OE.ENV and OE.INFLOW ensure that a user can neither interfere with the initial setup or the physical setup of the management machine or network components nor routes around the management machine or network components. Thus, all data pass through the TOE. O.FILTER ensures that this data is always checked and filtered according to the policy. The environmental objective OE.PROT ensures that data flow between the management machine and the network components is protected by cryptographic transforms, i.e. that sessions of users already authenticated cannot be taken over. The threat T.WEAKNESS which describes that an attacker may try to exploit a weakness of the protocol used in order to read, modify or destroy security sensitive data on the TOE is countered by a combination of the objectives OE.I&A, O.AUDIT, OE.AUDIT, OE.CONFW and O.MANAGEMENT. O.AUDIT and OE.AUDIT ensure detection of attempts to compromise the TOE. O.MANAGEMENT and OE.I&A ensure that only the authorized administrator is able to manage the TSF data and removes the aspect of the threat where an attacker could try to access sensitive data of the TOE via its management interface. The environmental objective OE.CONFW ensures that no service beside SSH run on the network components. 4.3.2 Covering the OSPs The TOE does not enforce organizational security policies. 4.3.3 Covering the assumptions The assumption A.ENV is covered by OE.ENV as directly follows. The assumption A.NOEVIL is covered by OE.NOEVIL as directly follows. The assumption A.INFLOW is covered by OE.INFLOW as directly follows. The assumption A.CONFW is covered by OE.CONFW as directly follows. The assumption A.TSP is covered by OE.TSP as directly follows. The assumption A.PROT is covered by OE.PROT as directly follows. The assumption A.AUDIT is covered by OE.AUDIT as directly follows. The assumption A.I&A is covered by OE.I&A as directly follows. secunet(wall 20 Version 1.0, 03/08/2016 5 STATEMENT OF SECURITY REQUIREMENTS This chapter defines the security functional requirements (see chapter 5.1) and the security assurance requirements for the TOE (see chapter 5.3). No extended components are defined in this Security Target (see chapter 5.2). 5.1 Security functional requirements for the TOE The TOE satisfies the SFRs delineated in the following table. The rest of this chapter contains a description of each component and any related dependencies. Security audit (FAU) FAU_GEN.1 Audit data generation User data protection (FDP) FDP_IFC.1 Subset information flow control FDP_IFF.1 Simple security attributes User identification (FIA) FIA_UID.1 Timing of identification Security management (FMT) FMT_MSA.1 Management of security attributes FMT_MSA.3 Static attribute initialisation FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles Table 10: Security Functional Requirements for the TOE secunet(wall Version 1.0, 03/08/2016 21 5.1.1 Security Audit 5.1.1.1 FAU_GEN.1 Audit data generation FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and shutdown of the audit functions; b) All auditable events for the [not specified] level of audit; and c) [starting of network components; IP datagrams matching log filters in packet filter rules] FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: a) Date and time of event, type of event, subject identity (if applicable), and the outcome (suc- cess or failure) of the event; b) and For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [no other audit relevant information] Hierarchical to: No other components Dependencies FPT_STM.1 Reliable time stamps 5.1.2 User data protection (FDP) 5.1.2.1 FDP_IFC.1 Subset information flow control FDP_IFC.1.1 The TSF shall enforce the [Packet Filter SFP] on [Subjects: users (external entities) that send and/or receive information through the TOE to one another; Information: data sent from one subject through the TOE to one another; Operation: pass the data]. secunet(wall 22 Version 1.0, 03/08/2016 Hierarchical to: No other components. Dependencies: FDP_IFF.1 Simple security attributes Application Note: The Packet Filter SFP is given in FDP_IFF. The subject definition in FDP_IFC.1.1 belongs to a former CC version. Thus the subjects are identical to the users defined in the external entities definition in chap. 3.3. 5.1.2.2 FDP_IFF.1 Simple security attributes FDP_IFF.1.1 The TSF shall enforce the [Packet Filter SFP] based on the following types of subject and information security attributes: [Subjects: users (external entities) that send and/or receive information through the TOE to one another; Subject security attributes: none; Information: data sent from one subject through the TOE to one another; Information security attributes: source address of subject, destination address of subject, transport layer protocol, interface on which the traffic arrives and departs, port, time]. FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [Subjects on a network connected to the TOE can cause information to flow through the TOE to a subject on another connected network only if all the information security attribute values are permitted by all information policy rules]. FDP_IFF.1.3 The TSF shall enforce the [reassembly of fragmented IP datagrams before inspection]. FDP_IFF.1.4 The TSF shall explicitly authorise an information flow based on the following rules: [none]. secunet(wall Version 1.0, 03/08/2016 23 FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on the following rules:  [The TOE shall reject requests of access or services where the information arrives on a network interface and the source address of the requesting subject does not belong to the network associated with the interface (spoofed packets);  The TSF shall drop IP datagrams with the source routing option;  The TOE shall reject fragmented IP datagrams which cannot be reassembled completely within a bounded interval]. Hierarchical to: No other components. Dependencies: FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation Application Note: The subject definition in FDP_IFF.1.1 belongs to a former CC version. Thus the subjects are identical to the users defined in the external entities definition in chap. 3.3. 5.1.3 User identification (UID) 5.1.3.1 FIA_UID.1 Timing of identification FIA_UID.1.1 The TSF shall allow [the following TSF-mediated actions] on behalf of the user to be performed before the user is identified.  all actions except for administrative actions as specified by FMT_SMF.1 FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. secunet(wall 24 Version 1.0, 03/08/2016 Hierarchical to: No other components. Dependencies: No dependencies. Refinement: The TOE verifies the identification information of an administrator provided by the environment (see OE.I&A) before any management function can be performed. Application Note: The “user” in FIA_UID.1.2 is identical to the administrator defined in the external entities definition in chap. 3.3. secunet(wall Version 1.0, 03/08/2016 25 5.1.4 Security management (FMT) 5.1.4.1 FMT_MSA.1 Management of security attributes FMT_MSA.1.1 The TSF shall enforce the [Packet Filter SFP] to restrict the ability to [modify, [no other operations]] the security attributes [network traffic filter rules and configuration data] to [the role administrator]. Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management 5.1.4.2 FMT_MSA.3 Static attribute initialization FMT_MSA.3.1 The TSF shall enforce the [Packet Filter SFP] to provide [restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2 The TSF shall allow the [no roles] to specify alternative initial values to override the default values when an object or information is created. Hierarchical to: No other components. Dependencies: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles secunet(wall 26 Version 1.0, 03/08/2016 5.1.4.3 FMT_SMF.1 Specification of management functions FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [  Modification of network traffic filter rules,  Modification of configuration data]. Hierarchical to: No other components. Dependencies: No dependencies. 5.1.4.4 FMT_SMR.1 Security roles FMT_SMR.1.1 The TSF shall maintain the roles [administrator]. FMT_SMR.1.2 The TSF shall be able to associate users with roles. Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification 5.2 Extended Components definition No extended components are defined in this Security Target. secunet(wall Version 1.0, 03/08/2016 27 5.3 Security assurance requirements for the TOE The following table lists the chosen evaluation assurance components for the TOE. Assurance Class Assurance Components ADV ADV_ARC.1, ADV_FSP.4, ADV_IMP.1, ADV_TDS.3 AGD AGD_OPE.1, AGD_PRE.1 ALC ALC_CMC.4, ALC_CMS.4, ALC_DEL.1, ALC_DVS.1 ALC_FLR.2, ALC_LCD.1, ALC_TAT.1 ATE ATE_COV.2, ATE_DPT.1, ATE_FUN.1, ATE_IND.2 Table 11: Chosen Evaluation Assurance Requirements These assurance components represent EAL 4 augmented by the component marked in bold text. The complete text for these requirements can be found in [2]. secunet(wall 28 Version 1.0, 03/08/2016 5.4 Security Requirements Rationale 5.4.1 TOE functional requirements rationale O.FILTER O.AUDIT O.MANAGEMENT FAU_GEN.1 X FIA_UID.1 X FDP_IFC.1 X FDP_IFF.1 X FMT_MSA.1 X FMT_MSA.3 X FMT_SMF.1 X FMT_SMR.1 X Table 12: Coverage of Security Objective for the TOE by SFR The security objective O.FILTER is met by a combination of FDP_IFC.1, FDP_IFF.1 and FMT_MSA.3. FDP_IFC.1 and FDP_IFF.1 describe the information flow controls and information flow control policy. Together, the SFRs describe how the packet filter information flow policies apply. FMT_MSA.3 defines that the TOE has to provide restrictive default values for the Packet Filter SFP (information flow policy) attributes. The SFRs are therefore sufficient to satisfy the objective O.FILTER and mutually supportive. The security objective O.AUDIT is met by FAU_GEN.1. FAU_GEN.1 describes when and what kind of audit data is generated. The security objective O.MANAGEMENT is met by FMT_SMF.1, FMT_MSA.1, FIA_UID.1 and FMT_SMR.1. FMT_SMF.1 describes the minimum set of management functionality, which has to be available. FMT_MSA.1 defines, which roles are allowed to administer the security attributes of the TOE. FIA_UID.1 requires each user to be identified before allowing any relevant actions on behalf of that user. Further the objective requires that the TOE will at least maintain the role administrator. This is defined in FMT_SMR.1, which defines the role. secunet(wall Version 1.0, 03/08/2016 29 5.4.2 Fulfilling the SFR dependencies The following table shows that all dependencies are met. SFR Dependencies Fulfilled by FAU_GEN.1 FPT_STM.1 FPT_STM.1 is satisfied in the IT environment (see OE.TSP). FIA_UID.1 No dependencies. - FDP_IFC.1 FDP_IFF.1 FDP_IFF.1 FDP_IFF.1 FDP_IFC.1 FDP_IFC.1 FMT_MSA.3 FMT_MSA.3 FMT_MSA.1 [FDP_ACC.1or FDP_IFC.1] FDP_IFC.1 FMT_SMR.1 FMT_SMR.1 FMT_SMF.1 FMT_SMF.1 FMT_MSA.3 FMT_MSA.1 FMT_MSA.1 FMT_SMR.1 FMT_SMR.1 FMT_SMF.1 No dependencies. - FMT_SMR.1 FIA_UID.1 FIA_UID.1 Table 13: Fulfilling the SFR dependencies 5.4.3 Security assurance requirements rationale The TOE claims compliance to EAL4 level of assurance augmented by ALC_FLR.2. As described in [2], the level EAL4 indicates that the product is methodically designed, tested, and reviewed. The assurance requirements for life cycle support have been augmented by ALC_FLR.2 (flaw reporting procedures) to account for regular bug fixes for the TOE. This is considered appropriate for attackers with Enhanced-Basic attack potential. The Security assurance requirements are chosen because of the evaluation level EAL4 according to [2]. secunet(wall 30 Version 1.0, 03/08/2016 6 TOE SUMMARY SPECIFICATION 6.1 TOE security functionality 6.1.1 SF1 Information Flow Protection SF1.1 meets FDP_IFC.1, SF1.1, SF1.2 and SF1.3 meet FDP_IFF.1: SF1.1: The TSF implements the information flow control (as routers) on the network layer (IP) and transport layer (TCP/UDP/ICMP). In order to define packet filter rules the TSF provides packet filter criteria and packet filter actions. The packet filter criteria are:  source address  destination address  transport layer protocol  interface on which traffic arrives and departs  port  time The packet filter actions are:  accept (= permit)  reject 1 (= deny)  drop In order to apply the packet filter rules the network components take the information from the IP and TCP/UDP/ICMP-Header (where applicable). SF1.2: The TSF reassembles IP datagrams before further processing is performed. IP datagrams which cannot be reassembled in a predefined span of time are dropped. SF1.3: The TSF drops packets with spoofed source- or destination-IP addresses. Packets with source routing options are also dropped. 6.1.2 SF2 Security Audit SF2.1 and SF2.2 meet FAU_GEN.1: SF2.1: The TSF generates audit records for  start-up and shutdown of the audit functions  datagrams received or sent through a network components network interfaces if they match configured patterns 1 : reject = drop and signal an error secunet(wall Version 1.0, 03/08/2016 31 SF2.2: Each record includes:  Time and Date  Affected network component  Subject identity (source IP)  Type of event  Affected Interface  Direction  Action (accept, drop or reject)  Optional depending on the protocol: IP addresses and ports 6.1.3 SF3 Management SF3.1 meets FMT_SMF.1. SF3.2 meets FIA_UID.1, FMT_MSA.1 and FMT_SMR.1. SF3.3 meets FMT_MSA.3. SF3.1: The TSF is capable of performing the following management functions:  Modification of network traffic filter rules,  Modification of configuration data, SF3.2: In order to modify the security attributes network traffic filter rules and configuration data the TOE maintains the role administrator. The TOE verifies the identification information of an administrator provided by the environment (see OE.I&A) before any management function can be performed. Therefore the TOE verifies if the user id is equal to zero. SF3.3: The TOE is initialized with a strict packet filter rule set, i. e. everything is dropped. secunet(wall 32 Version 1.0, 03/08/2016 7 GLOSSARY AND ACRONYMS Definition AES Advanced Encryption Standard BSI Bundesamt für Sicherheit in der Informationstechnik LAN Local Area Network NTP Network Time Protocol PP Protection Profile SFP Security Function Policy SFR Security Functional Requirement SSH Secure Shell ST Security Target TOE Target of Evaluation TSF TOE Security Function secunet(wall Version 1.0, 03/08/2016 33 8 REFERENCES Common Criteria [1] Common Criteria for Information 2: Security Functional Components; Version 3.1, Revision 4, CCMB-2012-09-002 [2] Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Components; Version 3.1, Revision 4, CCMB-2012-09-003 Cryptography [3] RFC4253, SSH Transport Layer Protocol, http://www.ietf.org/rfc/rfc4253.txt [4] RFC 791, Internet Protocol, http://www.ietf.org/rfc/rfc791.txt Documentation [5] secunet wall packet filter, documentation