Network Device Protection Profile (NDPP) Extended Package Stateful Traffic Filter Firewall

Transcription

1 Netwrk Device Prtectin Prfile (NDPP) Extended Package Stateful Traffic Filter Firewall Infrmatin Assurance Directrate 19 December 2011 Versin 1.0

2 Table f Cntents 1 Intrductin Cnfrmance Claims Hw T Use This Extended Package Cmpliant Targets f Evaluatin Security Prblem Descriptin Unauthrized Disclsure f Infrmatin Inapprpriate Access t Services Misuse f Services Disruptin r Denial f Services Security Objectives Address-Based Filtering Prt Based Filtering Stateful Inspectin Related Cnnectin Filtering System Mnitring TOE Administratin Security Requirements Cnventins TOE Security Functinal Requirements FFW_RUL_EXT.1 Stateful Traffic Filtering Security Audit Security Management Security Assurance Requirements AVA_VAN.1 Vulnerability survey Ratinale Security Prblem Definitin Assumptins Threats Organizatinal Security Plicies Security Prblem Definitin Crrespndence Security Objectives Security Objectives fr the TOE Security Objectives fr the Operatinal Envirnment

3 5.2.3 Security Objective Crrespndence Intrductin This Extended Package (EP) describes security requirements fr a Stateful Traffic Filter Firewall (defined t be a device that filters layers 3 and 4 (IP and TCP/UDP) netwrk traffic ptimized thrugh the use f stateful packet inspectin) is intended t prvide a minimal, baseline set f requirements that are targeted at mitigating well defined and described threats. Hwever, this EP is nt cmplete in itself, but rather extends the Security Requirements fr Netwrk Devices prtectin prfile (NDPP). This intrductin will describe the features f a cmpliant Target f Evaluatin (TOE), and will als discuss hw this EP is t be used in cnjunctin with the NDPP. 1.1 Cnfrmance Claims The Security Requirements fr Netwrk Devices Prtectin Prfile (NDPP) defines the baseline Security Functinal Requirements (SFRs) and Security Assurance Requirements (SARs) fr netwrk infrastructure devices in general. This EP serves t extend the NDPP baseline with additinal SFRs and assciated Assurance Activities specific t Stateful Traffic Filter Firewall netwrk infrastructure devices. Assurance Activities are the actins that the evaluatr perfrms in rder t determine a TOE s cmpliance t the SFRs. This EP cnfrms t Cmmn Criteria fr Infrmatin Technlgy Security Evaluatin, Versin 3.1, Revisin 3. It is CC Part 2 extended and CC Part 3 cnfrmant. 1.2 Hw T Use This Extended Package As an EP f the NDPP, it is expected that the cntent f bth this EP and the NDPP be apprpriately cmbined in the cntext f each prduct-specific Security Target. This EP has been specifically defined such that there shuld be n difficulty r ambiguity in s ding. An ST must identify the applicable versins f the NDPP (see fr the current versin) and this EP in its cnfrmance claims. 1.3 Cmpliant Targets f Evaluatin This EP is ne f a series f related EPs that define requirements fr the evaluatin f netwrk devices implementing firewall-related security features. Such prducts are generally bundary prtectin devices r sets f devices, such as dedicated firewalls, ruters, r perhaps even switches designed t cntrl the flw f infrmatin between attached netwrks. While in sme cases netwrk devices implementing firewall-related security features serve t segregate tw distinct netwrks a trusted r prtected enclave and an untrusted external netwrk such as the Internet that is nly ne f many pssible applicatins. It is cmmn fr firewalls t have multiple physical and lgical netwrk cnnectins enabling a wide range f pssible cnfiguratins and netwrk infrmatin flw plicies. This EP specifically addresses netwrk devices that perfrm netwrk layer 3 and 4 stateful traffic filtering. A Stateful Traffic Filter Firewall is a device cmpsed f hardware and sftware that is 3

4 cnnected t tw r mre distinct netwrks and has an infrastructure rle in the verall enterprise netwrk. Since this EP builds n the NDPP, cnfrmant TOEs are bligated t implement the functinality required in the NDPP alng with the additinal functinality defined in this EP in respnse t the threat envirnment discussed subsequently herein. Briefly, cmpliant TOEs will cntrl the flw f infrmatin (i.e., packets) between attached netwrks based n cnfigured rules based n netwrk layer 3 and 4 traffic attributes (i.e., addresses and prts) and derived sessin state infrmatin ptentially up t netwrk layer 7. It is intended that the set f requirements in this EP is limited in scpe in rder t prmte quicker, less cstly evaluatins that prvide sme value t end users. Future drafts f this EP are envisined, which will include ptinal functinality (e.g., transparent mde) in an appendix. Future Firewall EPs will be used t specify sets f additinal functinality (e.g., Applicatin Filtering), which can then be used by ST writers lking t specify additinal functinality. In the cntext f this EP, additinal features such as these are simply ignred fr the purpse f evaluatin except where they may have sme effect f the security requirements defined herein. Anther example f this is netwrk address translatin (NAT) r prt address translatin (PAT). While many devices that will be evaluated against this EP will have the capability t perfrm NAT r PAT, there are n requirements that specify this capability. This decisin was made based n the premise that NAT and PAT are nt primarily security mechanisms, but rather were created as a netwrk addressing cnvenience; althugh sme installatins may believe it is a means t hide their netwrk tplgy. 4

5 2 Security Prblem Descriptin Stateful Traffic Filter Firewalls address a range f security threats related t infiltratin int a prtected netwrk and exfiltratin frm a prtected netwrk. The term prtected netwrk is used here t represent an attached netwrk fr which rules are defined t cntrl access. As such, a given Stateful Traffic Filter Firewall culd ptentially have a variety f attached prtected and unprtected netwrks simultaneusly depending n its specific cnfiguratin. Als, it shuld be clear that all attached netwrks are presumed t be prtectable at the discretin f an authrized administratr. The term ingress traffic is used belw t represent traffic frm threat agents that exist utside a prtected netwrk and the term egress traffic is used belw t represent traffic frm threat agents that exist inside a prtected netwrk. Applicable threats include unauthrized disclsure f infrmatin, inapprpriate access t services, misuse f services, disruptin r denial f services, and netwrk-based recnnaissance. Hwever, relative t the data, it des nt matter where the threat agent is lcated. Example: data exfiltratin means that data was remved withut prper authrizatin t remve it. That can be a pull r a push. It can result frm intrusin frm the utside r by the actins f the insider. A site is respnsible fr develping its security plicy and cnfiguring a ruleset that the firewall will enfrce t meet their needs. Nte that this EP des nt repeat the threats identified in the NDPP, thugh they all apply given the cnfrmance and hence dependence f this EP n the NDPP. Nte als that while the NDPP cntains nly threats t the ability f the TOE t prvide its security functins, this EP addresses nly business threats t resurces in the peratinal envirnment. Tgether the threats f the NDPP and thse defined in this EP define the cmprehensive set f security threats addressed by a Stateful Traffic Filter Firewall TOE. 2.1 Unauthrized Disclsure f Infrmatin Devices n a prtected netwrk may be expsed t threats presented by devices lcated utside the prtected netwrk, which may attempt t cnduct unauthrized activities. If knwn malicius external devices are able t cmmunicate with devices n the prtected netwrk, r if devices n the prtected netwrk can establish cmmunicatins with thse external devices (e.g., as a result f a phishing episde r by inadvertent respnses t messages), then thse internal devices may be susceptible t the unauthrized disclsure f infrmatin. Frm an infiltratin perspective, Stateful Traffic Filter Firewalls serve t limit access t nly specific destinatin netwrk addresses and prts within a prtected netwrk. With these limits, general netwrk prt scanning can be prevented frm reaching prtected netwrks r machines, and access t infrmatin n a prtected netwrk can be limited t that btainable frm specifically cnfigured prts n identified netwrk ndes (e.g., web pages frm a designated crprate web server). Additinally, access can be limited t nly specific surce addresses and prts s that specific netwrks r netwrk ndes can be blcked frm accessing a prtected netwrk thereby further limiting the ptential disclsure f infrmatin. Frm an exfiltratin perspective, Stateful Traffic Filter Firewalls serve t limit hw netwrk ndes perating n a prtected netwrk can cnnect t and cmmunicate with ther netwrks limiting hw and where they can disseminate infrmatin. Specific external netwrks can be blcked altgether r 5

6 egress culd be limited t specific addresses and/r prts. Alternately, egress ptins available t netwrk ndes n a prtected netwrk can be carefully managed in rder t, fr example, ensure that utging cnnectins are ruted thrugh authrized prxies r filters t further mitigate inapprpriate disclsure f data thrugh extrusin. (T.NETWORK_DISCLOSURE) 2.2 Inapprpriate Access t Services Devices lcated utside the prtected netwrk may seek t exercise services lcated n the prtected netwrk that are intended t nly be accessed frm inside the prtected netwrk. Devices lcated utside the prtected netwrk may, likewise, ffer services that are inapprpriate fr access frm within the prtected netwrk. Frm an ingress perspective, Stateful Traffic Filter Firewalls can be cnfigured s that nly thse netwrk servers intended fr external cnsumptin are accessible and nly via the intended prts. This serves t mitigate the ptential fr netwrk entities utside a prtected netwrk t access netwrk servers r services intended nly fr cnsumptin r access inside a prtected netwrk. Frm an egress perspective, Stateful Traffic Filter Firewalls can be cnfigured s that nly specific external services (e.g., based n destinatin prt) can be accessed frm within a prtected netwrk. Fr example, access t external mail services can be blcked t enfrce crprate plicies against accessing uncntrlled servers. Nte that the effectiveness f a Stateful Traffic Filter Firewall is rather limited in this regard since external servers can ffer their services n alternate prts this is where an Applicatin Filter Firewall ffers mre reliable prtectin, fr example. (T. NETWORK_ACCESS) 2.3 Misuse f Services Devices lcated utside the prtected netwrk, while permitted t access particular public services ffered inside the prtected netwrk, may attempt t cnduct inapprpriate activities while cmmunicating with thse allwed public services. Certain services ffered frm within a prtected netwrk may als represent a risk when accessed frm utside the prtected netwrk. Frm an ingress perspective, it is generally assumed that entities perating n external netwrks are nt bund by the use plicies fr a given prtected netwrk. Nnetheless, Stateful Traffic Filter Firewalls can lg plicy vilatins that might indicate vilatin f publicized usage statements fr publicly available services. Frm an egress perspective, Stateful Traffic Filter Firewalls can be cnfigured t help enfrce and mnitr prtected netwrk use plicies. As explained in the ther threats, a Stateful Traffic Filter Firewall can serve t limit disseminatin f data, access t external servers, and even disruptin f services all f these culd be related t the use plicies f a prtected netwrk and as such are subject in sme regards t enfrcement. Additinally, Stateful Traffic Filter Firewalls can be cnfigured t lg netwrk usages that crss between prtected and external netwrks and as a result can serve t identify ptential usage plicy vilatins. 6

7 (T.NETWORK_MISUSE) 2.4 Disruptin r Denial f Services Stateful Traffic Filter Firewalls may be vulnerable t denial f services (DOS) attacks related t resurce exhaustin in the event f crdinated service request flding riginating frm utside f the prtected netwrk. Frm an ingress perspective, Stateful Traffic Filter Firewalls can be cnfigured s that nly thse netwrk servers intended fr external cnsumptin are accessible and nly via the intended prts and as a result ptential attacks can be limited t select servers and services that have been cnfigured (e.g., hardened ) fr that purpse. This serves t reduce available attack surface and mitigate the ptential fr external netwrk attacks against internal servers. Attacks against even thse servers that are externally accessible wuld be limited t the cnfigured prts reducing the pssible attack vectrs. Frm an egress perspective, Stateful Traffic Filter Firewalls can be cnfigured s that nly specific external services (e.g., based n destinatin prt) can be accessed frm within a prtected netwrk. Fr example, access t external mail servers can be blcked t reduce the chance f based attacks that might serve t intrduce viruses, malware, etc. ultimately resulting in disruptin f services n a prtected netwrk. Nte that the effectiveness f a Stateful Traffic Filter Firewall is rather limited in this regard since external servers can ffer their services n alternate prts this is where an Applicatin Filter Firewall ffers mre reliable prtectin, fr example. Hwever, lgging can serve t help identify service disruptins that have nt been prevented (e.g., by detecting the spread f viruses r btnet activity patterns). (T.NETWORK_DOS) 3 Security Objectives The Security Prblem described in Sectin 2 will be addressed primarily via Stateful Traffic Filtering capabilities. Cmpliant TOEs will prvide security functinality that addresses threats t the TOE and enfrces plicies that are impsed by law r regulatin. The fllwing subsectins prvide a descriptin f the security bjectives required t meet the threats/plicies previusly discussed. The descriptin f that security bjectives are in additin t that described in [NDPP]. Nte: in each subsectin belw particular security bjectives are identified (highlighted by O.) and they are matched with the assciated security functinal requirements (SFRs) that prvide the mechanisms t satisfy the bjectives. 3.1 Address-Based Filtering T address the issues assciated with unauthrized disclsure f infrmatin, inapprpriate access t services, misuse f services, disruptin r denial f services, and netwrk-based recnnaissance, cmpliant TOE s will implement a Stateful Traffic Filtering capability. That capability will restrict the flw f netwrk traffic between prtected netwrks and ther attached netwrks based n netwrk addresses f the netwrk ndes riginating (surce) and/r receiving (destinatin) applicable netwrk traffic as well as n established cnnectin infrmatin. 7

8 (O.ADDRESS_FILTERING FFW_RUL_EXT.1) 3.2 Prt Based Filtering T further address the issues assciated with unauthrized disclsure f infrmatin, etc., a cmpliant TOE s prt filtering capability will restrict the flw f netwrk traffic between prtected netwrks and ther attached netwrks based n the riginating (surce) and/r receiving (destinatin) prt (r service) identified in the netwrk traffic as well as n established cnnectin infrmatin. (O.PORT_FILTERING FFW_RUL_EXT.1) 3.3 Stateful Inspectin Stateful packet inspectin is used t aid in the perfrmance f packet flw thrugh the TOE. Rather than apply the ruleset against each packet that is prcessed at a TOE interface, the TOE will determine whether a packet belngs t an apprved established cnnectin. The minimum set f attributes that are used t determine whether a packet is part f an established sessin are mandated fr TCP and UDP, and the ST authr is allwed t expand the attributes cnsidered fr TCP sessins, and add the ICMP prtcl if they desire. (O.STATEFUL_INSPECTION FFW_RUL_EXT.1) 3.4 Related Cnnectin Filtering This bjective addresses the cncept f dynamic rule creatin, where due t the expected behavir f an applicatin layer prtcl, a new cnnectin r path is created due t the creatin f a cnnectin that is allwed by the ruleset. The File Transfer Prtcl is an example f such a prtcl, where a data cnnectin is created in respnse t an allwed cmmand cnnectin. (O.RELATED_CONNECTION_FILTERING FFW_RUL_EXT.1) 3.5 System Mnitring T address the issues f System Administratrs being able t mnitr the peratins f the Stateful Traffic Filtering capability this security bjective, which riginated in the NDPP, is extended as fllws. Cmpliant TOEs will implement the ability t lg the flw f netwrk traffic. Specifically, the TOE will prvide the means fr administratrs t cnfigure firewall specific firewall rules t lg when netwrk traffic is fund t match the cnfigured rule. As a result, matching a firewall rule cnfigured t lg will result in infrmative event lgs whenever a match ccurs. (O.SYSTEM_MONITORING FAU_GEN.1, FFW_RUL_EXT.1) 3.6 TOE Administratin T address the issues invlved with a trusted means f administratin f the Stateful Traffic Filtering capability this security bjective, which riginated in the NDPP, is extended as fllws. Nte that it is 8

9 assumed that use f the functins indicated belw is prtected in accrdance with the requirements in the NDPP. Cmpliant TOEs will prvide the functins necessary fr an administratr t cnfigure the firewall rules that are enfrced by the TOE. (O.TOE_ADMINISTRATION FMT_SMF.1) 9

10 4 Security Requirements This sectin specifies a Security Functinal Requirement fr the TOE, as well as specifying the assurance activities the evaluatr perfrms. 4.1 Cnventins While the SFR in this EP is extended, it is defined in a flexible manner fr use in this and ther EPs, r PPs, and as such peratins are perfrmed in the cntext f this EP. The CC defines peratins n Security Functinal Requirements: assignments, selectins, assignments within selectins and refinements. This dcument uses the fllwing fnt cnventins t identify the peratins defined by the CC: Assignment: Indicated with italicized text; Refinement made by EP authr: Indicated with bld text and strikethrughs, if necessary; Selectin: Indicated with underlined text; Assignment within a Selectin: Indicated with italicized and underlined text; and Iteratin: Indicated by appending the iteratin number in parenthesis, e.g., (1), (2), (3). 4.2 TOE Security Functinal Requirements There is ne SFR cmpnent with ten elements cntained within this EP. In additin t the Stateful Traffic Filter SFR, there are tw additins t the SFRs specified in the NDPP FAU_Gen.1 (tw audit events are added), and FMT_SMF.1 (management capability t cnfigure the firewall rules) FFW_RUL_EXT.1 Stateful Traffic Filtering FFW_RUL_EXT.1.1 The TSF shall perfrm Stateful Traffic Filtering n netwrk packets prcessed by the TOE. Applicatin Nte: This element is identifies the plicy (Stateful Traffic Filtering) that is applied t the netwrk packets that are prcessed at the TOE s interfaces. Every packet that is received at a TOE s interface either has the ruleset that expresses this plicy applied, r it is determined that the packet belngs t an established cnnectin. The remaining elements in this cmpnent prvide the details f the plicy. It is imprtant t nte that the TOE, which als includes the underlying platfrm, cannt permit netwrk packets t flw unless the ruleset cntains a rule that permits the flw, r the packet is deemed t belng t an established cnnectin that has been permitted t flw. This is principle must hld true during TOE startup, and upn failures the TOE may encunter. FFW_RUL_EXT.1.2 The TSF shall prcess the fllwing netwrk traffic prtcls: Internet Cntrl Message Prtcl versin 4 (ICMPv4) Internet Cntrl Message Prtcl versin 6 (ICMPv6) Internet Prtcl (IPv4) Internet Prtcl versin 6 (IPv6) Transmissin Cntrl Prtcl (TCP) User Datagram Prtcl (UDP) and be capable f inspecting netwrk packet header fields defined by the fllwing RFCs t the extent mandated in the ther elements f this SFR RFC 792 (ICMPv4) 10

11 RFC 4443 (ICMPv6) RFC 791 (IPv4) RFC 2460 (IPv6) RFC 793 (TCP) RFC 768 (UDP). Applicatin Nte: This element identifies the prtcls and references the prtcl definitins that serve t define t what extent the netwrk traffic can be interpreted by the TOE when imprting (receiving netwrk traffic r ingress) and exprting (sending r frming t be sent - netwrk traffic r egress). While the prtcl frmatting specified in the RFCs is still used, many RFCs define behavirs which are n lnger cnsidered safe t fllw. Fr example, RFC792 defined the Redirect ICMP type, which is nt cnsidered safe t hnr when it might cme frm an adversary; the surce quench message, which is insecure because its surce cannt be validated. FFW_RUL_EXT.1.3 The TSF shall allw the definitin f Stateful Traffic Filtering rules using the fllwing netwrk prtcl fields: ICMPv4 ICMPv6 IPv4 IPv6 TCP UDP Type Cde Type Cde Surce address Destinatin Address Transprt Layer Prtcl Surce address Destinatin Address Transprt Layer Prtcl Surce Prt Destinatin Prt Surce Prt Destinatin Prt 11

12 and distinct interface. Applicatin Nte: This element identifies the varius attributes that are applicable when cnstructing rules t be enfrced by this requirement the applicable interface is a prperty f the TOE and the rest f the identified attributes are defined in the assciated RFCs. Nte that the Transprt Layer Prtcl is the IPv4/IPv6 field that identifies the applicable prtcl, such as TCP, UDP, ICMP, r GRE. Als, Interface identified abve is the external prt where the applicable netwrk traffic was received r alternately will be sent. FFW_RUL_EXT.1.4 The TSF shall allw the fllwing peratins t be assciated with Stateful Traffic Filtering rules: permit, deny, and lg. Applicatin Nte: This element defines the peratins that can be assciated with rules used t match netwrk traffic. Nte that the data t be lgged is identified in the Security Audit requirements, Sectin FFW_RUL_EXT.1.5 The TSF shall allw the Stateful Traffic Filtering rules t be assigned t each distinct netwrk interface. Applicatin Nte: This element identifies where rules can be assigned. Specifically, a cnfrming TOE must be able t assign filtering rules specific t each f its available and identifiable distinct netwrk interfaces that handle layer 3 and 4 netwrk traffic. Identifiable means the interface is unique and identifiable within the TOE, and des nt necessarily require the interface t be visible frm the netwrk perspective (e.g., des nt need t have an IP address assigned t it). A distinct netwrk interface is ne r mre physical cnnectins that share a cmmn lgical path int the TOE. Fr example, the TOE might have a small frm-factr pluggable (SFP) prt supprting SFP mdules that expse a number f physical netwrk prts, but since a cmmn driver is used fr all external prts they can be treated as a single distinct netwrk interface. Nte that there culd be a separate ruleset fr each interface r alternately a shared ruleset that smehw assciates rules with specific interfaces. FFW_RUL_EXT.1.6 The TSF shall: a) accept a netwrk packet withut further prcessing f Stateful Traffic Filtering rules if it matches an allwed established sessin fr the fllwing prtcls: TCP, UDP, [selectin: ICMP, n ther prtcls] based n the fllwing netwrk packet attributes: 1. TCP: surce and destinatin addresses, surce and destinatin prts, sequence number, Flags; 2. UDP: surce and destinatin addresses, surce and destinatin prts; 3. [selectin: ICMP: surce and destinatin addresses, [selectin: type, cde, [assignment: list f matching attributes]], n ther prtcls]. b) Remve existing traffic flws frm the set f established traffic flws based n the fllwing: [selectin: sessin inactivity timeut, cmpletin f the expected infrmatin flw]. 12

13 Applicatin Nte: This element requires that the prtcls be identified fr which the TOE can determine and manage the state such that sessins can be established and are used t make traffic flw decisins as ppsed t fully prcessing the cnfigured rules. This element als requires that applicable attributes used t determine whether a netwrk packet matches and established sessin are identified. If ICMP is selected as a prtcl the surce and destinatin addresses are required t be cnsidered when determining if a packet belngs t an established cnnectin. The type and cde attributes may be used t prvide a mre rbust capability in determining whether an ICMP packet is what is expected in an established cnnectin flw. Fr example, ne wuld nt expect ech replies t be part f a flw if an ech request had nt been received. The pen assignment in the selectin fr ICMP attributes is left fr implementatins that may use IPv6 attributes. Item b) in this element requires specificatin f hw the firewall can determine that established infrmatin flws shuld be remved frm the set f established infrmatin flws by bserving events such as the terminatin f a TCP sessin initiated by either endpint with FIN flags in the TCP packet. If prtcls are handled differently, it is expected that the ST wuld identify thse differences. FFW_RUL_EXT.1.7 The TSF shall be able t prcess the fllwing netwrk prtcls: 1. FTP, 2. [selectin: H.323: [assignment: ther supprted prtcls], n ther prtcls], t dynamically define rules r establish sessins allwing netwrk traffic f the fllwing types: FTP: TCP data sessins in accrdance with the FTP prtcl as specified in RFC 959, [selectin: [assignment: list f additinally supprted prtcls and the types f netwrk traffic t be allwed based n thse prtcls], nne]. Applicatin Nte: This element requires the specificatin f mre cmplex prtcls that require the firewall t allw netwrk traffic flw even thugh an existing rule des nt explicitly allw the flw. Fr example, the FTP prtcl requires bth a cntrl cnnectin and a data cnnectin if a user is t transfer files. While there are well-knwn prts invlved, prt 21 (cntrl prt n FTP server) and prt 20 (data prt n server in active mde), there are randm prts > 1023 used n the client side. In passive mde, the FTP server may use a randm prt >1023 instead f prt 20. The data cnnectin is initiated by the client in passive mde, and imitated by the FTP server in active mde. Fr these types f prtcls, the establishment f a new cnnectin is allwed, even thugh the ruleset may appear t deny it (e.g., since a rule cannt predict which randm prt will be used by the client r ptentially the server, the default rule t deny may appear t apply). The TSF culd create a dynamic rule that gverns the traffic flw, r the TSF culd implicitly allw the new cnnectin t be established based n expectatins f the prtcl implementatin as specified in the RFC. It is imprtant t nte that there is n expectatin that any netwrk packets be inspected beynd layer 4 (TCP/UDP). This requirement simply requires that the ST authr specify the cnditins in which a hle 13

14 is punched int the firewall t allw expected cnnectins with unpredictable UDP/TCP prts t crrectly be established. If the ST Authr includes additinal prtcls they must identify the RFC that specifies the behavir f the prtcl, as was dne fr FTP in item 2 abve. FFW_RUL_EXT.1.8 The TSF shall enfrce the fllwing default Stateful Traffic Filtering rules n all netwrk traffic: 1. The TSF shall reject and be capable f lgging packets which are invalid fragments; 2. The TSF shall reject and be capable f lgging fragmented IP packets which cannt be re-assembled cmpletely; 3. The TSF shall reject and be capable f lgging netwrk packets where the surce address f the netwrk packet is equal t the address f the netwrk interface where the netwrk packet was received; 4. The TSF shall reject and be capable f lgging netwrk packets where the surce address f the netwrk packet des nt belng t the netwrks assciated with the netwrk interface where the netwrk packet was received; 5. The TSF shall reject and be capable f lgging netwrk packets where the surce address f the netwrk packet is defined as being n a bradcast netwrk; 6. The TSF shall reject and be capable f lgging netwrk packets where the surce address f the netwrk packet is defined as being n a multicast netwrk; 7. The TSF shall reject and be capable f lgging netwrk packets where the surce address f the netwrk packet is defined as being a lpback address; 8. The TSF shall reject and be capable f lgging netwrk packets where the surce address f the netwrk packet is a multicast; 9. The TSF shall reject and be capable f lgging netwrk packets where the surce r destinatin address f the netwrk packet is a link-lcal address; 10. The TSF shall reject and be capable f lgging netwrk packets where the surce r destinatin address f the netwrk packet is defined as being an address reserved fr future use as specified in RFC 5735 fr IPv4; 11. The TSF shall reject and be capable f lgging netwrk packets where the surce r destinatin address f the netwrk packet is defined as an unspecified address r an address reserved fr future definitin and use as specified in RFC 3513 fr IPv6; 12. The TSF shall reject and be capable f lgging netwrk packets with the IP ptins: Lse Surce Ruting, Strict Surce Ruting, r Recrd Rute specified; and 14

15 13. [selectin: [assignment: ther default rules enfrced by the TOE], n ther rules]. Applicatin Nte: This element defines the minimum default rules that are always applied. Nte that when packets might be rejected based n the rules identified abve, the TOE als needs t be capable f lgging s that related attacks might be detectable. Nte that the data t be lgged is identified in the Security Audit requirements. Item 1 and item 2 abve express hw the TOE prcesses fragmented packets. Item 1, intrduces the ntin f invalid fragments, and allws the ST authr t define what cnstitutes an invalid fragment. An acceptable implementatin culd cnsider any fragmented packet as invalid. Anther acceptable implementatin culd cnsider a fragmented packet that partially verlaps a previusly received fragment as invalid. Item 2 ensures that the ruleset is nly applied when a packet is reassembled t address the threat f fragmented packet attacks. Nte that in item 1, the lgging f an invalid fragment may nt be able t include all the fields that are expected in a packet header due t pieces missing in the invalid fragment. In item 4, the intent is that the netwrks assciated with the netwrk interface may be beynd the immediate subnet assciated with the interface. Fr example, the netwrk tplgy culd include a ruter and a subsequent subnet behind the firewall interface. Strict Reverse Path Frwarding wuld be an acceptable implementatin t determine if this is the case, where Lse RPF wuld nt be acceptable. The use f Access Cntrl Lists may be anther example f an acceptable implementatin that allws this default t be verridden. Item 13, prvides the ST authr the ability t specify additinal rules that are enfrced (either with r withut specificatin in the administratr defined ruleset). The type f rules specified here culd include things such as filtering f Christmas tree packets, filtering f nn-syn packets nt related t an existing cnnectin, and filtering f split handshake cnnectins. This element culd als be used t express behavir that allws packet flw, such as an ICMP respnse due t a hst being unreachable. FFW_RUL_EXT.1.9 When FFW_RUL_EXT.1.6 r FFW_RUL_EXT.1.7 d nt apply, the TSF shall prcess the applicable Stateful Traffic Filtering rules (as determined in accrdance with FFW_RUL_EXT.1.5) in the fllwing rder: administratrdefined. Applicatin Nte: This element requires that an administratr is able t define the rder in which cnfigured filtering rules are prcessed fr matches. FFW_RUL_EXT.1.10 When FFW_RUL_EXT.1.6 r FFW_RUL_EXT.1.7 d nt apply, the TSF shall deny packet flw if a matching rule is nt identified. Applicatin Nte: This element requires that, except when a packet is part f an established sessin, the behavir is always t deny netwrk traffic when n rules apply and n ther peratins are required, thugh they are nt necessarily prhibited. 15

16 FF W _R UL _E XT.1. 2 FFW_RUL_EXT Assurance Activities The fllwing table defines the assurance activities t be perfrmed by the evaluatrs in rder t ensure cnfrmance with FFW_RUL_EXT.1. The assurance activities are intended t address the required cntent f the TOE Summary Specificatin (TSS) f the ST, the required cntent f the TOE s peratinal guidance, and required test activities t be independently perfrmed by the evaluatrs. It is assumed the evaluatr will have tls suitable t establish sessins, mdify r create sessin packets, and perceive whether packets are getting thrugh the TOE as well as t examine the cntent f thse packets. In general, it is expected that traffic filter firewall rule cnfiguratin and lgging capabilities f the TOE can be used t reach apprpriate determinatins where applicable. The tests specified belw need t be repeated fr each distinct netwrk interface type. Given the definitin f interface type (all packets are prcessed thrugh the same lgical path within the TOE) tests are necessary t ensure all lgical paths that a packet may take thrugh the TOE adhere t the security plicy specified by this EP. The evaluatrs shall minimally create a test envirnment equivalent t the test envirnment illustrated belw. The evaluatrs must prvide Justificatin fr any differences in the test envirnment. Packet Capture Device Packet Capture Device Traffic Target TOE Traffic Generatr 4-1 FFW_RUL_EXT.1 Assurance Activities SFR Activity Assurance Activity TSS Guidance Tests TSS The evaluatr shall verify that the TSS prvide a descriptin f the TOE s initializatin/startup prcess, which clearly indicates where prcessing f netwrk packets begins t take place, and prvides a discussin that supprts the assertin that packets cannt flw during this prcess. The evaluatr shall verify that the TSS als include a narrative that identifies the cmpnents (e.g., active entity such as a prcess r task) invlved in prcessing the netwrk packets and describe the safeguards that wuld prevent packets flwing thrugh the TOE withut applying the ruleset in the event f a cmpnent failure. This culd include the failure f a cmpnent, such as a prcess being terminated, r a failure within a cmpnent, such as memry buffers full and cannt prcess packets. The peratinal guidance assciated with this requirement is assessed in the subsequent test assurance activities. Test 1: The evaluatr shall attempt t get netwrk traffic t flw thrugh the TOE while the TOE is being initialized. A steady flw f netwrk packets that wuld therwise be denied by the ruleset shuld be directed at the TOE s interfaces, with packet sniffers listening t see if any netwrk traffic is allwed thrugh. Nte: The remaining testing assciated with applicatin f the ruleset is addressed in the subsequent test assurance activities. The evaluatr shall verify that the TSS indicates that the fllwing prtcls are supprted: 16

17 FFW_RUL_EXT.1.3/FFW_RUL_EXT.1.4/FFW_RUL_EXT.1.5 SFR Activity Assurance Activity Guidance Tests TSS RFC 792 (ICMPv4) RFC 4443 (ICMPv6) RFC 791 (IPv4) RFC 2460 (IPv6) RFC 793 (TCP) RFC 768 (UDP) The evaluatr shall verify that the TSS describes hw cnfrmance with the identified RFCs has been determined by the TOE develper (e.g., third party interperability testing, prtcl cmpliance testing). The evaluatr shall verify that the peratinal guidance indicates that the fllwing prtcls are supprted: RFC 792 (ICMPv4) RFC 4443 (ICMPv6) RFC 791 (IPv4) RFC 2460 (IPv6) RFC 793 (TCP) RFC 768 (UDP) If the guidance describes ther prtcls that are prcessed by the TOE, it shuld be made clear that thse prtcls were nt cnsidered as part f the TOE evaluatin. The testing assciated with this requirement is addressed in the subsequent test assurance activities. The evaluatr shall verify that the TSS describes a stateful packet filtering plicy and the fllwing attributes are identified as being cnfigurable within stateful traffic filtering rules fr the assciated prtcls: ICMPv4 Type Cde ICMPv6 Type Cde IPv4 Surce address Destinatin Address Transprt Layer Prtcl IPv6 Surce address Destinatin Address Transprt Layer Prtcl TCP Surce Prt Destinatin Prt UDP Surce Prt Destinatin Prt The evaluatr shall verify that each rule can identify the fllwing actins: permit, deny, and lg. The evaluatr shall verify that the TSS identifies all interface types subject t the stateful packet 17

18 SFR Activity Assurance Activity filtering plicy and explains hw rules are assciated with distinct netwrk interfaces. Where interfaces can be gruped int a cmmn interface type (e.g., where the same internal lgical path is used, perhaps where a cmmn device driver is used) they can be treated cllectively as a distinct netwrk interface. Guidance Tests The evaluatrs shall verify that the peratinal guidance identifies the fllwing attributes as being cnfigurable within stateful traffic filtering rules fr the assciated prtcls: ICMPv4 Type Cde ICMPv6 Type Cde IPv4 Surce address Destinatin Address Transprt Layer Prtcl IPv6 Surce address Destinatin Address Transprt Layer Prtcl TCP Surce Prt Destinatin Prt UDP Surce Prt Destinatin Prt The evaluatr shall verify that the peratinal guidance indicates that each rule can identify the fllwing actins: permit, deny, and lg. The evaluatr shall verify that the peratinal guidance explains hw rules are assciated with distinct netwrk interfaces. The evaluatr shall verify that the peratinal guidance explains hw t determine the interface type f a distinct netwrk interface (e.g., hw t determine the device driver fr a distinct netwrk interface). Test 1: The evaluatr shall use the instructins in the peratinal guidance t test that stateful packet filter firewall rules can be created that permit, deny, and lg packets fr each f the fllwing attributes: ICMPv4 Type Cde ICMPv6 Type Cde IPv4 Surce address Destinatin Address Transprt Layer Prtcl IPv6 18

19 FFW_RUL_EXT.1.6 SFR Activity Assurance Activity TSS Guidance Tests TCP UDP Surce address Destinatin Address Transprt Layer Prtcl Surce Prt Destinatin Prt Surce Prt Destinatin Prt Test 2: Repeat the test assurance activity abve t ensure that stateful traffic filtering rules can be defined fr each distinct netwrk interface type supprted by the TOE. Nte that these test activities shuld be perfrmed in cnjunctin with thse f FFW_RUL_EXT.1.10 where the effectiveness f the rules is tested. The test activities fr FFW_RUL_EXT.1.10 define the prtcl/attribute cmbinatins required t be tested. If thse cmbinatins are cnfigured manually, that will fulfill the bjective f these test activities, but if thse cmbinatins are cnfigured therwise (e.g., using autmatin), these test activities may be necessary in rder t ensure the guidance is crrect and the full range f cnfiguratins can be achieved by a TOE administratr. The evaluatr shall verify that the TSS identifies the prtcls that supprt stateful sessin handling. The TSS shall identify TCP, UDP, and ICMP if selected by the ST authr. The evaluatr shall verify that the TSS describes hw stateful sessins are established (including handshake prcessing) and maintained. The evaluatr shall verify that fr TCP, the TSS identifies and describes the use f the fllwing attributes in sessin determinatin: surce and destinatin addresses, surce and destinatin prts, sequence number, and individual flags. The evaluatr shall verify that fr UDP, the TSS identifies and describes the fllwing attributes in sessin determinatin: surce and destinatin addresses, surce and destinatin prts. The evaluatr shall verify that fr ICMP (if selected), the TSS identifies and describes the fllwing attributes in sessin determinatin: surce and destinatin addresses, ther attributes chsen in FFW_RUL_EXT.1.6. The evaluatr shall verify that the TSS describes hw established stateful sessins are remved. The TSS shall describe hw cnnectins are remved fr each prtcl based n nrmal cmpletin and/r timeut cnditins. The TSS shall als indicate when sessin remval becmes effective (e.g., befre the next packet that might match the sessin is prcessed). The evaluatr shall verify that the peratinal guidance describes stateful sessin behavirs. Fr example, a TOE might nt lg packets that are permitted as part f an existing sessin. Test 1: The evaluatr shall cnfigure the TOE t permit and lg TCP traffic. The evaluatr shall initiate a TCP sessin. While the TCP sessin is being established, the evaluatr shall intrduce sessin establishment packets with incrrect flags t determine that the altered traffic is nt accepted as part f the sessin (i.e., a lg event is generated t shw the ruleset was applied). After a TCP sessin is successfully established, the evaluatr shall alter each f the sessin determining attributes (surce and destinatin addresses, surce and destinatin prts, sequence number, flags) ne at a time in rder t verify that the altered packets are nt accepted as part f the established sessin. Test 2: The evaluatr shall terminate the TCP sessin established per Test 1 as described in the 19

20 FFW_RUL_EXT.1.7 SFR Activity Assurance Activity TSS Guidance Tests TSS. The evaluatr shall then immediately send a packet matching the frmer sessin definitin in rder t ensure it is nt frwarded thrugh the TOE withut being subject t the ruleset. Test 3: The evaluatr shall expire (i.e., reach timeut) the TCP sessin established per Test 1 as described in the TSS. The evaluatr shall then send a packet matching the frmer sessin in rder t ensure it is nt frwarded thrugh the TOE withut being subject t the ruleset. Test 4: The evaluatr shall cnfigure the TOE t permit and lg UDP traffic. The evaluatr shall establish a UDP sessin. Once a UDP sessin is established, the evaluatr shall alter each f the sessin determining attributes (surce and destinatin addresses, surce and destinatin prts) ne at a time in rder t verify that the altered packets are nt accepted as part f the established sessin. Test 5: The evaluatr shall expire (i.e., reach timeut) the UDP sessin established per Test 4 as described in the TSS. The evaluatr shall then send a packet matching the frmer sessin in rder t ensure it is nt frwarded thrugh the TOE withut being subject t the ruleset. Test 6: If ICMP is selected, the evaluatr shall cnfigure the TOE t permit and lg ICMP traffic. The evaluatr shall establish a sessin fr ICMP as defined in the TSS. Once an ICMP sessin is established, the evaluatr shall alter each f the sessin determining attributes (surce and destinatin addresses, ther attributes chsen in FFW_RUL_EXT.1.6) ne at a time in rder t verify that the altered packets are nt accepted as part f the established sessin. Test 7: If applicable, the evaluatr shall terminate the ICMP sessin established per Test 6 as described in the TSS. The evaluatr shall then immediately send a packet matching the frmer sessin definitin in rder t ensure it is nt frwarded thrugh the TOE withut being subject t the ruleset. Test 8: The evaluatr shall expire (i.e., reach timeut) the ICMP sessin established per Test 6 as described in the TSS. The evaluatr shall then send a packet matching the frmer sessin in rder t ensure it is nt frwarded thrugh the TOE withut being subject t the ruleset. The evaluatr shall verify that the TSS identifies the prtcls that can cause the autmatic creatin f dynamic packet filtering rules. In sme cases rather than creating dynamic rules, the TOE might establish stateful sessins t supprt sme identified prtcl behavirs. The TSS shall identify FTP and ptinally ther prtcls. The evaluatr shall verify that the TSS explains the dynamic nature f sessin establishment and remval. The TSS als shall explain any lgging ramificatins. The evaluatr shall verify that fr FTP, the TSS explains hw FTP data sessins will be allwed thrugh the TOE in respnse t FTP cntrl sessins. The evaluatr shall verify that fr each f the ther prtcls selected, the TSS explains the dynamic nature f sessin establishment and remval specific t the prtcl. The evaluatr shall verify that the peratinal guidance describes dynamic sessin establishment capabilities. The evaluatr shall verify that the peratinal guidance describes the lgging f dynamic sessins cnsistent with the TSS. Test 1: The evaluatr shall define stateful traffic filtering rules t permit and lg an FTP sessin and deny and lg TCP prts abve Subsequently, the evaluatr shall establish an FTP sessin in rder t ensure that it succeeds. The evaluatr shall examine the generated lgs t verify they are cnsistent with the peratinal guidance. Test 2: Cntinuing frm Test 1, the evaluatr shall determine (e.g., using a packet sniffer) which 20

21 FF W_ RU L_E XT. 1.9 FFW_RUL_EXT.1.8 SFR Activity Assurance Activity prt abve 1024 is being used by the FTP data sessin, terminate the FTP sessin, and then verify that TCP packets cannt be sent thrugh the TOE using the same surce and destinatin addresses and prts. Test 3: Fr each additinally supprted prtcl, the evaluatr shall repeat the prcedure abve fr the prtcl. In each case the evaluatr must use the applicable RFC r standard in rder t determine what range f prts t blck in rder t ensure the dynamic rules are created and effective. TSS Guidance Tests TSS The evaluatr shall verify that the TSS identifies the fllwing as packets that will be autmatically rejected and are capable f being lgged: 1. Packets which are invalid fragments, including a descriptin f what cnstitutes an invalid fragment 2. Fragments that cannt be cmpletely re-assembled 3. Packets where the surce address is equal t the address f the netwrk interface where the netwrk packet was received 4. Packets where the surce address des nt belng t the netwrks assciated with the netwrk interface where the netwrk packet was received, including a descriptin f hw the TOE determines whether a surce address belngs t a netwrk assciated with a given netwrk interface 5. Packets where the surce address is defined as being n a bradcast netwrk 6. Packets where the surce address is defined as being n a multicast netwrk 7. Packets where the surce address is defined as being a lpback address 8. Packets where the surce address is defined as being a reserved address as specified in RFC 1918 fr IPv4, and RFC 3513 fr IPv6 9. Packets where the surce r destinatin address f the netwrk packet is a link-lcal address 10. Packets where the surce r destinatin address f the netwrk packet is defined as being an address reserved fr future use as specified in RFC 5735 fr IPv4 11. Packets where the surce r destinatin address f the netwrk packet is defined as an unspecified address r an address reserved fr future definitin and use as specified in RFC 3513 fr IPv6 12. Packets with the IP ptins: Lse Surce Ruting, Strict Surce Ruting, r Recrd Rute specified 13. Other packets defined in FFW_RUL_EXT.1.8. The evaluatr shall verify that the peratinal guidance describes packets that are discarded and ptentially lgged by default. If applicable prtcls are identified, their descriptins need t be cnsistent with the TSS. If lgging is cnfigurable, the evaluatr shall verify that applicable instructins are prvided t cnfigure auditing f autmatically rejected packets. Test 1: The evaluatr shall test each f the cnditins fr autmatic packet rejectin in turn. In each case, the TOE shuld be cnfigured t allw all netwrk traffic and the evaluatr shall generate a packet r packet fragment that is t be rejected. The evaluatr shall use packet captures t ensure that the unallwable packet r packet fragment is nt passed thrugh the TOE. Test 2: Fr each f the cases abve, the evaluatr shall use any applicable guidance t enable rejected packet lgging. In each case abve, the evaluatr shall ensure that the rejected packet r packet fragment was apprpriately lgged. The evaluatr shall verify that the TSS describes the algrithm applied t incming packets, including the prcessing f default rules, determinatin f whether a packet is part f an 21

22 FFW_RUL_EXT.1.10 SFR Activity Assurance Activity established sessin, and applicatin f administratr defined and rdered ruleset. Guidance Tests TSS Guidance Tests The evaluatr shall verify that the peratinal guidance describes hw the rder f stateful traffic filtering rules is determined and prvides the necessary instructins s that an administratr can cnfigure the rder f rule prcessing. Test 1: The evaluatr shall devise tw equal stateful traffic filtering rules with alternate peratins permit and deny. The rules shuld then be deplyed in tw distinct rders and in each case the evaluatr shall ensure that the first rule is enfrced in bth cases by generating applicable packets and using packet capture and lgs fr cnfirmatin. Test 2: The evaluatr shall repeat the prcedure abve, except that the tw rules shuld be devised where ne is a subset f the ther (e.g., a specific address vs. a netwrk segment). Again, the evaluatr shuld test bth rders t ensure that the first is enfrced regardless f the specificity f the rule. The evaluatr shall verify that the TSS describes the prcess fr applying stateful traffic filtering rules and als that the behavir (either by default, r as cnfigured by the administratr) is t deny packets when there is n rule match unless anther required cnditins allws the netwrk traffic (i.e., FFW_RUL_EXT.1.6 r FFW_RUL_EXT.1.7). The evaluatr shall verify that the peratinal guidance describes the behavir if n rules r special cnditins apply t the netwrk traffic. If the behavir is cnfigurable, the evaluatr shall verify that the peratinal guidance prvides the apprpriate instructins t cnfigure the behavir t deny packets with n matching rules. Test 1: The evaluatr shall cnfigure the TOE t permit and lg each defined ICMPv4 Type and Cde (see table 4-2 Defined Prtcl-specific Attributes). The evaluatr will generate packets matching each defined ICMPv4 Type and Cde in rder t ensure that they are permitted (i.e., by capturing the packets after passing thrugh the TOE) and lgged. Test 2: The evaluatr shall cnfigure the TOE t deny and lg each defined ICMPv4 Type and Cde (see table 4-2 Defined Prtcl-specific Attributes). The evaluatr will generate packets matching each defined ICMPv4 Type and Cde in rder t ensure that they are denied (i.e., by capturing n applicable packets passing thrugh the TOE) and lgged. Test 3: The evaluatr shall cnfigure the TOE with n ICMPv4 rules. The evaluatr will generate packets matching each defined ICMPv4 Type and Cde in rder t ensure that they are denied (i.e., by capturing n applicable packets passing thrugh the TOE). Test 4: The evaluatr shall cnfigure the TOE t permit and lg each defined ICMPv6 Type and Cde (see table 4-2 Defined Prtcl-specific Attributes). The evaluatr will generate packets matching each defined ICMPv6 Type and Cde in rder t ensure that they are permitted (i.e., by capturing the packets after passing thrugh the TOE) and lgged. Test 5: The evaluatr shall cnfigure the TOE t deny and lg each defined ICMPv6 Type and Cde (see table 4-2 Defined Prtcl-specific Attributes). The evaluatr will generate packets matching each defined ICMPv6 Type and Cde in rder t ensure that they are denied (i.e., by capturing n applicable packets passing thrugh the TOE) and lgged. Test 6: The evaluatr shall cnfigure the TOE with n ICMPv6 rules. The evaluatr will generate packets matching each defined ICMPv6 Type and Cde in rder t ensure that they are denied (i.e., by capturing n applicable packets passing thrugh the TOE). Test 7: The evaluatr shall cnfigure the TOE t permit and lg each defined IPv4 Transprt Layer Prtcl (see table 4-2 Defined Prtcl-specific Attributes) in cnjunctin with a specific 22