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

23 SFR Activity Assurance Activity surce address and specific destinatin address, specific surce address and wildcard destinatin address, wildcard surce address and specific destinatin address, and wildcard surce address and wildcard destinatin address. The evaluatr shall generate packets matching each defined IPv4 Transprt Layer Prtcl and within the cnfigured surce and destinatin addresses in rder t ensure that they are permitted (i.e., by capturing the packets after passing thrugh the TOE) and lgged. Test 8: The evaluatr shall cnfigure the TOE t permit all traffic except t deny and lg each defined IPv4 Transprt Layer Prtcl (see table 4-2 Defined Prtcl-specific Attributes) in cnjunctin with a specific surce address and specific destinatin address, specific surce address and wildcard destinatin address, wildcard surce address and specific destinatin address, and wildcard surce address and wildcard destinatin address. The evaluatr shall generate packets matching each defined IPv4 Transprt Layer Prtcl and within the cnfigured surce and destinatin addresses in rder t ensure that they are denied (i.e., by capturing n applicable packets passing thrugh the TOE) and lgged. Test 9: 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 surce address and specific destinatin address, specific surce address and wildcard destinatin address, wildcard surce address and specific destinatin address, and wildcard surce address and wildcard destinatin address. Additinally, the evaluatr shall cnfigure the TOE t deny and lg each defined IPv4 Transprt Layer Prtcl (see table 4-2 Defined Prtcl-specific Attributes) in cnjunctin with different (than thse permitted abve) cmbinatins f a specific surce address and specific destinatin address, specific surce address and wildcard destinatin address, wildcard surce address and specific destinatin address, and wildcard surce address and wildcard destinatin address. The evaluatr shall generate packets matching each defined IPv4 Transprt Layer Prtcl and utside the scpe f all surce and destinatin addresses cnfigured abve in rder t ensure that they are denied (i.e., by capturing n applicable packets passing thrugh the TOE). Test 10: The evaluatr shall cnfigure the TOE t permit and lg each defined IPv6 Transprt Layer Prtcl (see table 4-2 Defined Prtcl-specific Attributes) in cnjunctin with a specific surce address and specific destinatin address, specific surce address and wildcard destinatin address, wildcard surce address and specific destinatin address, and wildcard surce address and wildcard destinatin address. The evaluatr shall generate packets matching each defined IPv6 Transprt Layer Prtcl and within the cnfigured surce and destinatin addresses in rder t ensure that they are permitted (i.e., by capturing the packets after passing thrugh the TOE) and lgged. Test 11: The evaluatr shall cnfigure the TOE t permit all traffic except t deny and lg each defined IPv6 Transprt Layer Prtcl (see table 4-2 Defined Prtcl-specific Attributes) in cnjunctin with a specific surce address and specific destinatin address, specific surce address and wildcard destinatin address, wildcard surce address and specific destinatin address, and wildcard surce address and wildcard destinatin address. The evaluatr shall generate packets matching each defined IPv6 Transprt Layer Prtcl and within the cnfigured surce and destinatin addresses in rder t ensure that they are denied (i.e., by capturing n applicable packets passing thrugh the TOE) and lgged. Test 12: The evaluatr shall cnfigure the TOE t permit and lg each defined IPv6 Transprt Layer Prtcl (see table 4-2 Defined Prtcl-specific Attributes) in cnjunctin with a specific surce address and specific destinatin address, specific surce address and wildcard destinatin address, wildcard surce address and specific destinatin address, and wildcard surce address 23

24 SFR Activity Assurance Activity and wildcard destinatin address. Additinally, the evaluatr shall cnfigure the TOE t deny and lg each defined IPv6 Transprt Layer Prtcl (see table 4-2 Defined Prtcl-specific Attributes) in cnjunctin with different (than thse permitted abve) cmbinatins f a specific surce address and specific destinatin address, specific surce address and wildcard destinatin address, wildcard surce address and specific destinatin address, and wildcard surce address and wildcard destinatin address. The evaluatr shall generate packets matching each defined IPv6 Transprt Layer Prtcl and utside the scpe f all surce and destinatin addresses cnfigured abve in rder t ensure that they are denied (i.e., by capturing n applicable packets passing thrugh the TOE). Test 13: The evaluatr shall cnfigure the TOE t permit and lg TCP using a selected surce prt, a selected destinatin prt, and a selected surce and destinatin prt cmbinatin. The evaluatr shall generate packets matching the cnfigured surce and destinatin TCP prts in rder t ensure that they are permitted (i.e., by capturing the packets after passing thrugh the TOE) and lgged. Test 14: The evaluatr shall cnfigure the TOE t deny and lg TCP using a selected surce prt, a selected destinatin prt, and a selected surce and destinatin prt cmbinatin. The evaluatr shall generate packets matching the cnfigured surce and destinatin TCP prts in rder t ensure that they are denied (i.e., by capturing n applicable packets passing thrugh the TOE) and lgged. Test 15: The evaluatr shall cnfigure the TOE t permit and lg UDP using a selected surce prt, a selected destinatin prt, and a selected surce and destinatin prt cmbinatin. The evaluatr shall generate packets matching the cnfigured surce and destinatin UDP prts in rder t ensure that they are permitted (i.e., by capturing the packets after passing thrugh the TOE) and lgged. Test 16: The evaluatr shall cnfigure the TOE t deny and lg UDP using a selected surce prt, a selected destinatin prt, and a selected surce and destinatin prt cmbinatin. The evaluatr shall generate packets matching the cnfigured surce and destinatin UDP prts in rder t ensure that they are denied (i.e., by capturing n applicable packets passing thrugh the TOE) and lgged. The fllwing table identifies the RFC defined type, cde, and transprt layer attributes fr the applicable prtcls t be used in cnfiguring and therwise testing stateful traffic filter firewall rule definitin and enfrcement. Nte that TCP and UDP are nt included in the table since the nly required attributes defined fr thse prtcls are netwrk addresses and prts all f which are ptentially usable within a given TOE peratinal envirnment. 4-2 Defined Prtcl-specific Attributes Prtcl ICMPv4 Defined Attributes Type 0 (Ech Reply) Type 3 (Destinatin Unreachable) Type 3 cde 0 (Net Unreachable) Type 3 cde 1 (Hst Unreachable) Type 3 cde 2 (Prtcl Unreachable) Type 3 cde 3 (Prt Unreachable) Type 3 cde 4 (Fragmentatin Needed and Dn t Fragment was set) Type 3 cde 5 (Surce Rute Failure) Type 3 cde 6 (Destinatin Netwrk Unknwn) Type 3 cde 7 (Destinatin Hst Unknwn) 24

25 Prtcl ICMPv6 Defined Attributes Type 3 cde 8 (Surce Hst Islated) Type 3 cde 9 (Cmmunicatin with Destinatin Netwrk is Administratively Prhibited) Type 3 cde 10 (Cmmunicatin with Destinatin Hst is Administratively Prhibited) Type 3 cde 11 (Destinatin Netwrk Unreachable fr Type f Service) Type 3 cde 12 (Destinatin Hst Unreachable fr Type f Service) Type 3 cde 13 (Cmmunicatin Administratively Prhibited) Type 4 (Surce Quench) Type 5 (Redirect) Type 5 cde 0 (Redirect Datagram fr the Netwrk (r subnet)) Type 5 cde 1 (Redirect Datagram fr the Hst) Type 5 cde 2 (Redirect Datagram fr the Type f Service and Netwrk) Type 5 cde 3 (Redirect Datagram fr the Type f Service and Hst) Type 6 (Alternative Address fr Hst) Type 6 cde 0 (Alternate Address fr Hst) Type 8 (Ech) Type 9 (Ruter Advertisement) Type 10 (Ruter Selectin) Type 11 (Time Exceeded) Type 11 cde 0 (Time t Live exceeded in Transit) Type 11 cde 1 (Fragment Reassembly Time Exceeded) Type 12 (Parameter Prblem) Type 12 cde 0 (Pinter indicates the errr) Type 12 cde 1 (Missing a Required Optin) Type 12 cde 2 (Bad Length) Type 13 (Timestamp) Type 14 (Timestamp Reply) Type 15 (Infrmatin Request) Type 16 (Infrmatin Reply) Type 17 (Address Mask Request) Type 18 (Address Mask Reply) Type 30 (Tracerute) Type 31 (Datagram Cnversin Errr) Type 32 (Mbile Hst Redirect) Type 35 (Mbile Registratin Request) Type 36 (Mbile Registratin Reply) Type 1 (Destinatin Unreachable) Type 1 cde 0 (n rute t destinatin) Type 1 cde 1 (cmmunicatin with destinatin administratively prhibited) Type 1 cde 2 (beynd scpe f surce address) Type 1 cde 3 (address unreachable) Type 1 cde 4 (prt unreachable) Type 1 cde 5 (surce address failed ingress/egress plicy) Type 1 cde 6 (reject rute t destinatin) Type 1 cde 7 (Errr in Surce Ruting Header) Type 2 (Packet T Big) Type 3 (Time Exceeded) Type 3 cde 0 (hp limit exceeded in transit) Type 3 cde 1 (fragment reassembly time exceeded) Type 4 (Parameter Prblem) Type 4 cde 0 (errneus header field encuntered) Type 4 cde 1 (unrecgnized Next Header type encuntered) Type 4 cde 2 (unrecgnized IPv6 ptin encuntered) Type 100 (Private Experimentatin) Type 101 (Private Experimentatin) Type 128 (Ech Request) Type 129 (Ech Reply) Type 130 (Multicast Listener Query) Type 131 (Multicast Listener Reprt) Type 132 (Multicast Listener Dne) Type 133 (Ruter Slicitatin) Type 134 (Ruter Advertisement) Type 135 (Neighbr Slicitatin) Type 136 (Neighbr Advertisement) Type 137 (Redirect Message) 25

26 Prtcl IPv4 Defined Attributes Type 138 (Ruter Renumbering) Type 138 cde 0 (Ruter Renumbering Cmmand) Type 138 cde 1 (Ruter Renumbering Result) Type 138 cde 225 (Sequence Number Reset) Type 139 (ICMP Nde Infrmatin Query) Type 139 cde 0 (The data field cntains an IPv6 address which is the subject f this query) Type 139 cde 1 (The data field cntains a name which is the subject f this query r is empty, as in the case f a NOOP) Type 139 cde 2 (The Data field cntains an IPv4 address which is the Subject f this Query.) Type 140 (ICMP Nde Infrmatin Respnse) Type 140 cde 0 (A successful reply. The Reply Data field may r may nt be empty) Type 140 cde 1 (The Respnder refuses t supply the answer. The Reply Data field will be empty) Type 140 cde 2 (Qtype f the Query is unknwn t the Respnder. The Reply Data field will be empty) Type 141 (Inverse Neighbr Discvery Slicitatin Message) Type 142 (Inverse Neighbr Discvery Advertisement Message) Type 143 (Versin 2 Multicast Listener Reprt) Type 144 (Hme Agent Address Discvery Request Message) Type 145 (Hme Agent Address Discvery Reply Message) Type 146 (Mbile Prefix Slicitatin) Type 147 (Mbile Prefix Advertisement) Type 148 (Certificatin Path Slicitatin Message) Type 149 (Certificatin Path Advertisement Message) Type 150 (ICMP messages utilized by experimental mbility prtcls such as Seamby) Type 151 (Multicast Ruter Advertisement) Type 152 (Multicast Ruter Slicitatin) Type 153 (Multicast Ruter Terminatin) Type 154 (FMIPv6 Messages) Type 155 (RPL Cntrl Message) Transprt Layer Prtcl 1 - Internet Cntrl Message Transprt Layer Prtcl 2 - Internet Grup Management Transprt Layer Prtcl 3 - Gateway-t-Gateway Transprt Layer Prtcl 4 - IP in IP (encapsulatin) Transprt Layer Prtcl 5 - Stream Transprt Layer Prtcl 6 - Transmissin Cntrl Transprt Layer Prtcl 7 - UCL Transprt Layer Prtcl 8 - Exterir Gateway Prtcl Transprt Layer Prtcl 9 - any private interir gateway Transprt Layer Prtcl 10 - BBN RCC Mnitring Transprt Layer Prtcl 11 - Netwrk Vice Prtcl Transprt Layer Prtcl 12 - PUP Transprt Layer Prtcl 13 - ARGUS Transprt Layer Prtcl 14 - EMCON Transprt Layer Prtcl 15 - Crss Net Debugger Transprt Layer Prtcl 16 - Chas Transprt Layer Prtcl 17 - User Datagram Transprt Layer Prtcl 18 - Multiplexing Transprt Layer Prtcl 19 - DCN Measurement Subsystems Transprt Layer Prtcl 20 - Hst Mnitring Transprt Layer Prtcl 21 - Packet Radi Measurement Transprt Layer Prtcl 22 - XEROX NS IDP Transprt Layer Prtcl 23 - Trunk-1 Transprt Layer Prtcl 24 - Trunk-2 Transprt Layer Prtcl 25 - Leaf-1 Transprt Layer Prtcl 26 - Leaf-2 Transprt Layer Prtcl 27 - Reliable Data Prtcl Transprt Layer Prtcl 28 - Internet Reliable Transactin Transprt Layer Prtcl 29 - ISO Transprt Prtcl Class 4 Transprt Layer Prtcl 30 - Bulk Data Transfer Prtcl Transprt Layer Prtcl 31 - MFE Netwrk Services Prtcl Transprt Layer Prtcl 32 - MERIT Interndal Prtcl Transprt Layer Prtcl 33 - Sequential Exchange Prtcl Transprt Layer Prtcl 34 - Third Party Cnnect Prtcl Transprt Layer Prtcl 35 - Inter-Dmain Plicy Ruting Prtcl Transprt Layer Prtcl 36 - XTP Transprt Layer Prtcl 37 - Datagram Delivery Prtcl 26

27 Prtcl IPv6 Defined Attributes Transprt Layer Prtcl 38 - IDPR Cntrl Message Transprt Prtcl Transprt Layer Prtcl 39 - TP++ Transprt Prtcl Transprt Layer Prtcl 40 - IL Transprt Prtcl Transprt Layer Prtcl 41 - Simple Internet Prtcl Transprt Layer Prtcl 42 - Surce Demand Ruting Prtcl Transprt Layer Prtcl 43 - SIP Surce Rute Transprt Layer Prtcl 44 - SIP Fragment Transprt Layer Prtcl 45 - Inter-Dmain Ruting Prtcl Transprt Layer Prtcl 46 - Reservatin Prtcl Transprt Layer Prtcl 47 - General Ruting Encapsulatin Transprt Layer Prtcl 48 - Mbile Hst Ruting Prtcl Transprt Layer Prtcl 49 - BNA Transprt Layer Prtcl 50 - SIPP Encap Security Paylad Transprt Layer Prtcl 51 - SIPP Authenticatin Header Transprt Layer Prtcl 52 - Integrated Net Layer Security TUBA Transprt Layer Prtcl 53 - IP with Encryptin Transprt Layer Prtcl 54 - NBMA Next Hp Reslutin Prtcl Transprt Layer Prtcl 61 - any hst internal prtcl Transprt Layer Prtcl 62 - CFTP Transprt Layer Prtcl 63 - any lcal netwrk Transprt Layer Prtcl 64 - SATNET and Backrm EXPAK Transprt Layer Prtcl 65 - Kryptlan Transprt Layer Prtcl 66 - MIT Remte Virtual Disk Prtcl Transprt Layer Prtcl 67 - Internet Pluribus Packet Cre Transprt Layer Prtcl 68 - any distributed file system Transprt Layer Prtcl 69 - SATNET Mnitring Transprt Layer Prtcl 70 - VISA Prtcl Transprt Layer Prtcl 71 - Internet Packet Cre Utility Transprt Layer Prtcl 72 - Cmputer Prtcl Netwrk Executive Transprt Layer Prtcl 73 - Cmputer Prtcl Heart Beat Transprt Layer Prtcl 74 - Wang Span Netwrk Transprt Layer Prtcl 75 - Packet Vide Prtcl Transprt Layer Prtcl 76 - Backrm SATNET Mnitring Transprt Layer Prtcl 77 - SUN ND PROTOCOL-Temprary Transprt Layer Prtcl 78 - WIDEBAND Mnitring Transprt Layer Prtcl 79 - WIDEBAND EXPAK Transprt Layer Prtcl 80 - ISO Internet Prtcl Transprt Layer Prtcl 81 - VMTP Transprt Layer Prtcl 82 - SECURE-VMTP Transprt Layer Prtcl 83 - VINES Transprt Layer Prtcl 84 - TTP Transprt Layer Prtcl 85 - NSFNET-IGP Transprt Layer Prtcl 86 - Dissimilar Gateway Prtcl Transprt Layer Prtcl 87 - TCF Transprt Layer Prtcl 88 - IGRP Transprt Layer Prtcl 89 - OSPFIGP Transprt Layer Prtcl 90 - Sprite RPC Prtcl Transprt Layer Prtcl 91 - Lcus Address Reslutin Prtcl Transprt Layer Prtcl 92 - Multicast Transprt Prtcl Transprt Layer Prtcl 93 - AX.25 Frames Transprt Layer Prtcl 94 - IP-within-IP Encapsulatin Prtcl Transprt Layer Prtcl 95 - Mbile Internetwrking Cntrl Prtcl Transprt Layer Prtcl 96 - Semaphre Cmmunicatins Security Prtcl Transprt Layer Prtcl 97 - Ethernet-within-IP Encapsulatin Transprt Layer Prtcl 98 - Encapsulatin Header Transprt Layer Prtcl 99 - any private encryptin scheme Transprt Layer Prtcl GMTP Transprt Layer Prtcl 0 - IPv6 Hp-by-Hp Optin Transprt Layer Prtcl 1 - Internet Cntrl Message Transprt Layer Prtcl 2 - Internet Grup Management Transprt Layer Prtcl 3 - Gateway-t-Gateway Transprt Layer Prtcl 4 - IPv4 encapsulatin Transprt Layer Prtcl 5 - Stream Transprt Layer Prtcl 6 - Transmissin Cntrl 27

28 Prtcl Defined Attributes Transprt Layer Prtcl 7 - CBT Transprt Layer Prtcl 8 - Exterir Gateway Prtcl Transprt Layer Prtcl 9 - any private interir gateway Transprt Layer Prtcl 10 - BBN RCC Mnitring Transprt Layer Prtcl 11 - Netwrk Vice Prtcl Transprt Layer Prtcl 12 - PUP Transprt Layer Prtcl 13 - ARGUS Transprt Layer Prtcl 14 - EMCON Transprt Layer Prtcl 15 - Crss Net Debugger Transprt Layer Prtcl 16 - Chas Transprt Layer Prtcl 17 - User Datagram Transprt Layer Prtcl 18 - Multiplexing Transprt Layer Prtcl 19 - DCN Measurement Subsystems Transprt Layer Prtcl 20 - Hst Mnitring Transprt Layer Prtcl 21 - Packet Radi Measurement Transprt Layer Prtcl 22 - XEROX NS IDP Transprt Layer Prtcl 23 - Trunk-1 Transprt Layer Prtcl 24 - Trunk-2 Transprt Layer Prtcl 25 - Leaf-1 Transprt Layer Prtcl 26 - Leaf-2 Transprt Layer Prtcl 27 - Reliable Data Prtcl Transprt Layer Prtcl 28 - Internet Reliable Transactin Transprt Layer Prtcl 29 - Transprt Prtcl Class 4 Transprt Layer Prtcl 30 - Bulk Data Transfer Prtcl Transprt Layer Prtcl 31 - MFE Netwrk Services Prtcl Transprt Layer Prtcl 32 - MERIT Interndal Prtcl Transprt Layer Prtcl 33 - Datagram Cngestin Cntrl Prtcl Transprt Layer Prtcl 34 - Third Party Cnnect Prtcl Transprt Layer Prtcl 35 - Inter-Dmain Plicy Ruting Prtcl Transprt Layer Prtcl 36 - XTP Transprt Layer Prtcl 37 - Datagram Delivery Prtcl Transprt Layer Prtcl 38 - IDPR Cntrl Message Transprt Prt Transprt Layer Prtcl 39 - TP++ Transprt Prtcl Transprt Layer Prtcl 40 - IL Transprt Prtcl Transprt Layer Prtcl 41 - IPv6 encapsulatin Transprt Layer Prtcl 42 - Surce Demand Ruting Prtcl Transprt Layer Prtcl 43 Ruting Header fr IPv6 Transprt Layer Prtcl 44 Fragment Header fr IPv6 Transprt Layer Prtcl 45 - Inter-Dmain Ruting Prtcl Transprt Layer Prtcl 46 - Reservatin Prtcl Transprt Layer Prtcl 47 - General Ruting Encapsulatin Transprt Layer Prtcl 48 - Dynamic Surce Ruting Prtcl Transprt Layer Prtcl 49 - BNA Transprt Layer Prtcl 50 - Encap Security Paylad Transprt Layer Prtcl 51 - Authenticatin Header Transprt Layer Prtcl 52 - Integrated Net Layer Security Transprt Layer Prtcl 53 - IP with Encryptin Transprt Layer Prtcl 54 - NBMA Address Reslutin Prtcl Transprt Layer Prtcl 55 - Mbility Transprt Layer Prtcl 56 - Transprt Layer Security Prtcl using Kryptnet key management Transprt Layer Prtcl 57 - SKIP Transprt Layer Prtcl 58 ICMP fr IPv6 Transprt Layer Prtcl 59 N Next Header fr IPv6 Transprt Layer Prtcl 60 Destinatin Optins fr IPv6 Transprt Layer Prtcl 61 - any hst internal prtcl Transprt Layer Prtcl 62 - CFTP Transprt Layer Prtcl 63 - any lcal netwrk Transprt Layer Prtcl 64 - SATNET and Backrm EXPAK Transprt Layer Prtcl 65 - Kryptlan Transprt Layer Prtcl 66 - MIT Remte Virtual Disk Prtcl Transprt Layer Prtcl 67 - Internet Pluribus Packet Cre Transprt Layer Prtcl 68 - any distributed file system Transprt Layer Prtcl 69 - SATNET Mnitring Transprt Layer Prtcl 70 - VISA Prtcl 28

29 Prtcl Defined Attributes Transprt Layer Prtcl 71 - Internet Packet Cre Utility Transprt Layer Prtcl 72 - Cmputer Prtcl Netwrk Executive Transprt Layer Prtcl 73 - Cmputer Prtcl Heart Beat Transprt Layer Prtcl 74 - Wang Span Netwrk Transprt Layer Prtcl 75 - Packet Vide Prtcl Transprt Layer Prtcl 76 - Backrm SATNET Mnitring Transprt Layer Prtcl 77 - SUN ND PROTOCOL-Temprary Transprt Layer Prtcl 78 - WIDEBAND Mnitring Transprt Layer Prtcl 79 - WIDEBAND EXPAK Transprt Layer Prtcl 80 - ISO Internet Prtcl Transprt Layer Prtcl 81 - VMTP Transprt Layer Prtcl 82 - SECURE-VMTP Transprt Layer Prtcl 83 - VINES Transprt Layer Prtcl 84 - TTP Transprt Layer Prtcl 84 - Internet Prtcl Traffic Manager Transprt Layer Prtcl 85 - NSFNET-IGP Transprt Layer Prtcl 86 - Dissimilar Gateway Prtcl Transprt Layer Prtcl 87 - TCF Transprt Layer Prtcl 88 - EIGRP Transprt Layer Prtcl 89 - OSPFIGP Transprt Layer Prtcl 90 - Sprite RPC Prtcl Transprt Layer Prtcl 91 - Lcus Address Reslutin Prtcl Transprt Layer Prtcl 92 - Multicast Transprt Prtcl Transprt Layer Prtcl 93 - AX.25 Frames Transprt Layer Prtcl 94 - IP-within-IP Encapsulatin Prtcl Transprt Layer Prtcl 95 - Mbile Internetwrking Cntrl Pr. Transprt Layer Prtcl 96 - Semaphre Cmmunicatins Sec. Pr. Transprt Layer Prtcl 97 - Ethernet-within-IP Encapsulatin Transprt Layer Prtcl 98 - Encapsulatin Header Transprt Layer Prtcl GMTP Transprt Layer Prtcl Ipsiln Flw Management Prtcl Transprt Layer Prtcl PNNI ver IP Transprt Layer Prtcl Prtcl Independent Multicast Transprt Layer Prtcl ARIS Transprt Layer Prtcl SCPS Transprt Layer Prtcl QNX Transprt Layer Prtcl Active Netwrks Transprt Layer Prtcl Paylad Cmpressin Prtcl Transprt Layer Prtcl Sitara Netwrks Prtcl Transprt Layer Prtcl Cmpaq Peer Prtcl Transprt Layer Prtcl IPX in IP Transprt Layer Prtcl Virtual Ruter Redundancy Prtcl Transprt Layer Prtcl PGM Reliable Transprt Prtcl Transprt Layer Prtcl any 0-hp prtcl Transprt Layer Prtcl Layer Tw Tunneling Prtcl Transprt Layer Prtcl D-II Data Exchange (DDX) Transprt Layer Prtcl Interactive Agent Transfer Prtcl Transprt Layer Prtcl Schedule Transfer Prtcl Transprt Layer Prtcl SpectraLink Radi Prtcl Transprt Layer Prtcl UTI Transprt Layer Prtcl Simple Message Prtcl Transprt Layer Prtcl SM Transprt Layer Prtcl Perfrmance Transparency Prtcl Transprt Layer Prtcl ISIS ver IPv4 Transprt Layer Prtcl FIRE Transprt Layer Prtcl Cmbat Radi Transprt Prtcl Transprt Layer Prtcl Cmbat Radi User Datagram Transprt Layer Prtcl SSCOPMCE Transprt Layer Prtcl IPLT Transprt Layer Prtcl Secure Packet Shield Transprt Layer Prtcl Private IP Encapsulatin within IP Transprt Layer Prtcl Stream Cntrl Transmissin Prtcl Transprt Layer Prtcl Fibre Channel Transprt Layer Prtcl RSVP-E2E-IGNORE 29

30 FAU_GEN.1.1/FAU_GEN.1.2 Prtcl Defined Attributes Transprt Layer Prtcl Mbility Header Transprt Layer Prtcl UDPLite Transprt Layer Prtcl MPLS-in-IP Transprt Layer Prtcl MANET Prtcls Transprt Layer Prtcl Hst Identity Prtcl Transprt Layer Prtcl Shim6 Prtcl Transprt Layer Prtcl Wrapped Encapsulating Security Paylad Transprt Layer Prtcl Rbust Header Cmpressin Security Audit There are n additinal SFRs fr security audit. Hwever, there are additinal auditable events that serve t extend the FAU_GEN.1 SFR fund in the NDPP. As such, the fllwing events shuld be cmbined with thse f the NDPP in the cntext f a cnfrming Security Target. The fllwing audit events are applicable when the Firewall SFRs are claimed. 4-3 FAU_GEN.1 Audit Event and Details SFR Audit Event Additinal Details FFW_RUL_EXT.1 Applicatin f rules cnfigured with the lg peratin Indicatin f packets drpped due t t much netwrk traffic Surce and destinatin addresses Surce and destinatin prts Transprt Layer Prtcl TOE Interface TOE interface that is unable t prcess packets Assurance Activities The fllwing table defines the assurance activities t be perfrmed by the evaluatrs in rder t ensure cnfrmance with FAU_GEN FAU_GEN.1 Assurance Activities SFR Activity Assurance Activity TSS The evaluatr shall verify that the TSS describes hw the stateful traffic filter firewall rules can be cnfigured t lg netwrk traffic assciated with applicable rules. Nte that this activity shuld have been addressed with a cmbinatin f the TSS assurance activities fr FFW_RUL_EXT.1. The evaluatr shall verify that the TSS describes hw the TOE behaves when ne f its interfaces is verwhelmed by netwrk traffic. It is acceptable fr the TOE t drp packets that it cannt prcess, but under n circumstances is the TOE allwed t pass packets that d nt satisfy a rule that allws the permit peratin r belng t an allwed established sessin. It may nt always be pssible fr the TOE t audit drpped packets due t implementatin limitatins. These limitatins and circumstances in which the event f drpped packets is nt audited shall be described in the TSS. 30

31 FMT_SM F.1.1 SFR Activity Assurance Activity Guidance Tests The evaluatr shall verify that the peratinal guidance describes hw t cnfigure the stateful traffic filter firewall rules t result in applicable netwrk traffic lgging. Nte that this activity shuld have been addressed with a cmbinatin f the guidance assurance activities fr FFW_RUL_EXT.1. Test 1: The evaluatr shall test that the interfaces used t cnfigure the stateful traffic filter firewall rules fr lgging yield expected netwrk traffic lgs in assciatin with the applicable rules. A number f rule cmbinatin and rdering scenaris need t be cnfigured and tested by attempting t pass bth valid and invalid netwrk traffic matching rules design t permit, deny and lg matching netwrk traffic. Nte that this activity shuld have been addressed with a cmbinatin f the Test assurance activities fr FFW_RUL_EXT.1. Test 2: The evaluatr shall attempt t fld the TOE with netwrk packets such that the TOE will be unable t prcess all the packets. This may require the evaluatr t cnfigure the TOE t limit the bandwidth the TOE is capable t handling (e.g., use f a 10 MB interface) Security Management There are n additinal SFRs fr security management. As indicated in the NDPP, access t the rules, defaults, etc. that serve t define the firewall behavirs are restricted t the Security Administratr. N additinal rle is specifically required fr thse security management functins. The NDPP includes FMT_SMF.1 requiring the existence f specific security management functins. The fllwing security management functins are applicable when Firewall SFRs are claimed. As such, the fllwing security management functins shuld be cmbined with thse f the NDPP in the cntext f a cnfrming Security Target. 4-5 FMT_SMF.1 Security Management Functins SFR FFW_RUL_EXT.1 Security Management Functins Cnfigure Firewall rules Assurance Activities The fllwing table defines the assurance activities t be perfrmed by the evaluatrs in rder t ensure cnfrmance with FMT_SMF FMT_SMF.1 Assurance Activities SFR Activity Assurance Activity TSS The evaluatr shall verify that the TSS describes hw the stateful traffic filter firewall rules can be cnfigured. Nte that this activity shuld have been addressed with the TSS assurance activities fr FFW_RUL_EXT.1. 31

32 SFR Activity Assurance Activity Guidance Tests The evaluatr shall verify that the peratinal guidance describes hw t cnfigure the stateful traffic filter firewall rules, including hw t set any cnfigurable defaults and hw t cnfigure each f the applicable rule attributes, actins, and assciated interfaces. The evaluatr must ensure that the peratinal guidance als prvides instructin that wuld allw an administratr t ensure that cnfigured rules are prperly rdered. Nte that this activity shuld have been addressed with the Guidance assurance activities fr FFW_RUL_EXT.1. Test 1: The evaluatr shall devise tests that demnstrate that the functins used t cnfigure the stateful traffic filter firewall rules yield expected changes in the rules that they are crrectly enfrced. A number f rule cmbinatin and rdering scenaris need t be cnfigured and tested by attempting t pass bth valid and invalid netwrk traffic thrugh the TOE. Nte that this activity shuld have been addressed with a cmbinatin f the Test assurance activities fr FFW_RUL_EXT Security Assurance Requirements It is imprtant t nte that a TOE that is evaluated against this EP is inherently evaluated against the NDPP as well. The NDPP includes a number f Assurance Activities assciated with bth Security Functinal Requirements (SFRs) and SARs. Additinally, this EP includes a number f SFR-based Assurance Activities that similarly refine the SARs assciated with the EAL identified in the NDPP. The assurance activities assciated with SARs that are prescribed by the NDPP are perfrmed against the entire TOE, with the additin f the specific vulnerability testing described here AVA_VAN.1 Vulnerability survey Assurance Activity: The evaluatr shall generate netwrk packets that cycle thrugh all f the values fr attributes, Type, Cde, and Transprt Layer Prtcl, that are undefined by the RFC fr each f the prtcls, ICMPv4, ICMPv6, IPv4, and IPv6. Fr example, ICMPv4 has an eight-byte field fr Type and an eight-byte field fr the Cde. Only 21 Types are defined in the RFC (see table 4-2), but there are 256 pssible value. Each Type has a Cde assciated with it, the number f RFC defined Cdes varies based n the Type. The evaluatr is required t cnstruct packets that exercise each pssible value nt defined in the RFC (the defined values are already tested in FFW_RUL_EXT.1.10) f Type and Cde (including all pssible cmbinatins) and target each distinct interface type t determine that the TOE handles these packets apprpriately. Since nne f these packets will match a rule, r belng t an allwed sessin the packets shuld be drpped. Since there are n requirements that the firewall audit a packet being drpped under these circumstances, the evaluatr shall ensure the firewall des nt allw these packets t flw thrugh the TOE. In additin t the undefined attribute testing required abve, the evaluatr shall perfrm intelligent fuzz testing f the remaining fields in the required prtcl headers (excluding FTP). The intent f intelligent fuzzing is that a packet that is therwise crrectly cnstructed, such that it will be denied when the ruleset is applied, has randm values inserted int each f the prtcl header fields. The evaluatr 32

33 ensures a statistically significant sample size, which will vary depending n the prtcl field length, is used and is justified in their reprt. The evaluatr shuld cnsult whatever diagnstics (e.g., lgging, prcess status, interface errrs) the TOE ffers t determine if the TOE was adversely impacted by the prcessing f such packets. 33

34 5 Ratinale In this EP, the fcus in the initial sectins f the dcument is t use a narrative presentatin in an attempt t increase the verall understandability f the threats addressed by Stateful Traffic Filter Firewalls; the methds used t mitigate thse threats; and the extent f the mitigatin achieved by cmpliant TOEs. This presentatin style des nt readily lend itself t a frmalized evaluatin activity, s this sectin cntains the tabular artifacts that can be used fr the evaluatin activities assciated with this dcument. 5.1 Security Prblem Definitin Assumptins The specific cnditins listed belw are assumed t exist in the TOE s Operatinal Envirnment. These assumptins are in additin t thse defined in the NDPP and include bth practical realities in the develpment f the TOE security requirements and the essential envirnmental cnditins n the use f the TOE. 5-1 TOE Assumptins Assumptin Name A.CONNECTIONS Assumptin Definitin It is assumed that the TOE is cnnected t distinct netwrks in a manner that ensures that the TOE security plicies will be enfrced n all applicable netwrk traffic flwing amng the attached netwrks Threats The threats listed belw are addressed by Stateful Traffic Filter Firewalls. Nte that these threats are in additin t thse defined in the NDPP, all f which apply t Stateful Traffic Filter Firewalls. 5-2 Threats Threat Name T.NETWORK_DISCLOSURE Threat Definitin Sensitive infrmatin n a prtected netwrk might be disclsed resulting frm ingress- r egress-based actins. T. NETWORK_ACCESS Unauthrized access may be achieved t services n a prtected netwrk frm utside that netwrk, r alternately services utside a prtected netwrk frm inside the prtected netwrk. T.NETWORK_MISUSE T.NETWORK_DOS Organizatinal Security Plicies Access t services made available by a prtected netwrk might be used cunter t Operatinal Envirnment plicies. Attacks against services inside a prtected netwrk, r indirectly by virtue f access t malicius agents frm within a prtected netwrk, might lead t denial f services therwise available within a prtected netwrk. N rganizatinal plicies have been identified that are specific t Stateful Traffic Filter Firewalls. Hwever, all the rganizatinal security plicies in the NDPP apply t Stateful Traffic Filter Firewalls. 34

35 5.1.4 Security Prblem Definitin Crrespndence The fllwing table serves t map the threats and assumptins defined in this EP t the security bjectives als defined r identified in this EP. 5-3 Security Prblem Definitin Crrespndence Threat r Assumptin Security Objectives A.CONNECTIONS OE.CONNECTIONS T.NETWORK_DISCLOSURE O.ADDRESS_FILTERING and O.PORT_FILTERING T. NETWORK_ACCESS O.ADDRESS_FILTERING, O.RELATED_CONNECTION_FILTERING and O.PORT_FILTERING T.NETWORK_MISUSE O.ADDRESS_FILTERING, O.PORT_FILTERING and O.SYSTEM_MONITORING T.NETWORK_DOS O.ADDRESS_FILTERING, O.STATEFUL_INSPECTION and O.PORT_FILTERING 5.2 Security Objectives Security Objectives fr the TOE The fllwing table cntains security bjectives specific t Stateful Traffic Filter Firewalls. These security bjectives are in additin t thse defined in the NDPP, all f which apply t Stateful Traffic Filter Firewalls. Nte that while tw f the NDPP security bjectives (O.SYSTEM_MONITORING and O.TOE_ADMINISTRATION) have been extended in this EP, that des nt affect the crrespnding security bjective definitins. 5-4 Security Objectives fr the TOE Security Objective Name O.ADDRESS_FILTERING O.PORT_FILTERING O.STATEFUL_INSPECTION O.RELATED_CONNECTION_FILTERING Security Objective Definitin The TOE will prvide the means t filter and lg netwrk packets based n surce and destinatin addresses. The TOE will prvide the means t filter and lg netwrk packets based n surce and destinatin transprt layer prts. The TOE will determine if a netwrk packet belngs t an allwed established cnnectin befre applying the ruleset. Fr specific prtcls, the TOE will dynamically permit a netwrk packet flw in respnse t a cnnectin permitted by the ruleset Security Objectives fr the Operatinal Envirnment The fllwing table cntains security bjectives specific t the peratinal envirnments fr Stateful Traffic Filter Firewalls. These security bjectives are in additin t thse defined in the NDPP, all f which apply t the peratinal envirnments fr Stateful Traffic Filter Firewalls. 5-5 Security Objectives fr the Operatinal Envirnment Security Objective Name OE.CONNECTIONS Security Objective Definitin TOE administratrs will ensure that the TOE is installed in a manner that will allw the TOE t effectively enfrce its plicies n netwrk traffic 35

36 flwing amng attached netwrks Security Objective Crrespndence The crrespndence between the Security Functinal Requirements (SFRs) and Security Objectives identified r defined in this EP is prvided in sectin 3. 36