ࡱ> @ ]bjbjFF y,,kU4656565h5,5dej7j7"777g8g8g8ddddddd$fR8iV e:g8g8:: e77e;;;:77d;:d;;{Z<_7^7 ;65;^r_4e0de)_rj;j_$j_,g8v8T;19Du9rg8g8g8 e ed-65;65An Approach to Creating Your Firewall Security Policy Presented by: Lennox Brown ϡȱ IAO Manager IS Audits To : IT Security Contacts Date : 2/15/2005 Firewall Security Policy: A firewall policy is distinct from the information security policy, in as much as it is simply a description of how the information security policy will be implemented by the firewall and associated security mechanisms. Without a firewall policy, administrators and organizations are flying blind. Without a policy to guide firewall implementation and administration, the firewall itself may become a security problem. A firewall policy dictates how the firewall should handle applications traffic such as web, email, or telnet. The policy should describe how the firewall is to be managed and updated. Creation of The Firewall Security Policy: Steps involved in creating a firewall policy are as follows: Perform risk analysis. Identification of network applications deemed necessary, Identification of vulnerabilities associated with applications, Cost-benefits analysis of methods for securing the applications, Creation of applications traffic matrix showing protection method, and Creation of firewall ruleset based on applications traffic matrix. Document the firewall Security Policy Risk Analysis Before a firewall policy can be created, some form of risk analysis must be performed on the applications that are necessary for accomplishment of the organizations mission. The results of this analysis will include a list of the applications and how those applications will be secured. This will require knowledge of the vulnerabilities associated with each application and the cost-benefits associated with the methods used for securing the applications. Risk analysis of the organizations information technology infrastructure should be weighed based on an evaluation of the following elements: threats, vulnerabilities, and countermeasures in place to mitigate vulnerabilities, and the impact if sensitive data is compromised. The goal is to understand and evaluate these elements prior to establishing a firewall policy. Ideally departmental security stakeholders should have a general picture of what security threats the departmental network face. E.g. of a typical response by departments with the associated risk ranking. Rank assigned by Depts/ITSecurity Issue/concern10Remote Access to System Resources10Internet access to System Resources10Data Exchange - securing all communications pathways to and from system Resources7Minimal or weak network data accountability mechanisms that link all network activity to a user identity6Minimal or weak Access Control (User identification and Authentication) to System Resources (preventing non authorized users from accessing materials that they are not permitted to see)4Web Surfing and downloads to/from Resources Based on the threats/concerns identified by departmental stakeholders, identify those that can be mitigated by a firewall. You are evaluating which of these security threats or concerns will the firewall(s) mitigate and rank its effectiveness? Rank assigned by Depts/ITSecurity Issue/concern10Remote Access to System Resources10Internet access to System Resources8Data Exchange - securing all communications pathways to and from system Resources8Minimal or weak network data accountability mechanisms that link all network activity to a user identity6Minimal or weak Access Control (User identification and Authentication) to System Resources (preventing non authorized users from accessing materials that they are not permitted to see)8Web Surfing and downloads to/from Resources Note: What you will find is departmental security stakeholders will have a general picture about what security threats the department network or their systems face, but lacked implementation details and specifics about the role the firewall would play in addressing security threats. So in reality departments look to the campus IT group to address most of their security concerns. Creation of applications traffic matrix Identification of network applications deemed necessary, Identification of vulnerabilities associated with applications, Cost-benefits analysis of methods for securing the applications, Creation of applications traffic matrix showing protection method, and Firewall Application Traffic Ruleset Matrix TCP/IP APPLICA-TIONSERVICE LOCATION INTERNAL HOST TYPE INTERNAL HOST SECURITY POLICYFIREWALL SECURITY POLICY (Internal) FIREWALL SECURITY POLICY (External) EXPLANATIONFinger Any Unix TCP Wrapper Permit Reject " Any PC - TCP/IP None Permit Permit FTP Any Unix No Anonymous; UserID/Password; Secure Shell (SSH) Permit Application Proxy with User Authentication " Any PC - TCP/IP Client Only; Anti-Virus Permit Application Proxy with User Authentication TFTP Any Unix Server with Diskless Clients Only Secure Mode; Permit tftp to Limited Directories Permit Only Local Domain; Reject Other Reject " Any Unix - All Other Disable Reject Reject " Any PC - TCP/IP Disable Reject Reject Telnet Any Unix Secure Shell Permit Application Proxy with User Authentication " Any PC - TCP/IP Client Only Permit Application Proxy with User Authentication " Any Router/Firewall 2 Password Layers; Token AuthenticationToken Authentication Reject  NFS Any UNIX Limit Exports; Host/Groups (Granular Access) Reject All, except by Written Authorization Reject " Any PC - TCP/IP Client Only Reject Reject NetBIOS over TCP/IP Any Windows NT/95/WFW Limit Access to Shares Permit Local Do-main Only; Reject Others Reject  Please note: The EXPLANATION is very important. This is where you provide the rationale for the particular entry. It also provides the needed documentation for the individual who maintains the firewall and provides the needed continuity in the event staff changes. If the explanation cannot fit in the allocated column, you can refer to the documentation that details the explanation. Create Firewall Rule-set The application matrix acts as the blueprint for configuring the firewall rule-set. De-pending on the firewall, this may be done through a web-style interface; in the case of a packet filter, it may be done manually. Firewall rulesets should be built to be as specific as possible with regards to the network traffic they control. Rulesets should be kept as simple as possible, so as not to accidentally introduce holes in the firewall that might allow unauthorized or unwanted traffic to traverse a firewall. The default policy for the firewall for handling inbound traffic should be to block all packets and connections unless the traffic type and connections have been specifically permitted. This approach is more secure than another approach used often: permit all connections and traffic by default and then block specific traffic and connections. The firewall ruleset should always block the following types of traffic: Inbound traffic from a non-authenticated source system with a destination address of the firewall system itself. This type of packet normally represents some type of probe or attack against the firewall. One common exception to this rule would be in the event the firewall system accepts delivery of inbound email (SMTP on port 25). In this event, the firewall must allow inbound connections to itself, but only on port 25. Inbound traffic with a source address indicating that the packet originated on a network behind the firewall. This type of packet likely represents some type of spoofing at-tempt. Inbound traffic containing ICMP (Internet Control Message Protocol) traffic. Since ICMP can be used to map the networks behind certain types of firewalls, ICMP should not be passed in from the Internet, or from any untrusted external network. Inbound or Outbound traffic from a system using a source address that falls within the address ranges set aside in RFC 1918 as being reserved for private networks. For reference purposes, RFC 1918 reserves the following address ranges for private networks: 10.0.0.0 to 10.255.255.255 (Class A, or ./8. in CIDR14 notation) 172.16.0.0 to 172.31.255.255 (Class B, or ./12. in CIDR notation) 192.168.0.0 to 192.168.255.255 (Class C, or ./16. in CIDR notation) Inbound traffic with these source addresses typically indicates the beginning of a denial-of-service attack involving the TCP SYN flag. Some firewalls include internal functionality to combat these attacks, but this particular type of network traffic should still be blocked with ruleset entries. Inbound traffic from a non-authenticated source system containing SNMP (Simple Network Management Protocol) traffic. These packets can be an indicator that an intruder is probing a network, but there are few reasons an organization or agency might want to allow inbound SNMP traffic, and it should be blocked in the vast majority of circumstances. Inbound traffic containing IP Source Routing information. Source Routing is a mechanism that allows a system to specify the routes a piece of network traffic will employ while traveling from the source system to the destination system. From a security standpoint, source routing has the potential to permit an attacker to construct a network packet that bypasses firewall controls. In modern networks, IP Source Routing is rarely used, and valid applications are even less common on the Internet. Inbound or Outbound network traffic containing a source or destination address of 127.0.0.1 (localhost). Such traffic is usually some type of attack against the firewall system itself. Inbound or Outbound network traffic containing a source or destination address of 0.0.0.0. Some operating systems interpret this address as either localhost or as a broadcast address, and these packets can be used for attack purposes. Inbound or Outbound traffic containing directed broadcast addresses. A directed broadcast is often used to initiate a broadcast propagation attack such as SMURF. Directed broadcasts allow one computer system to send out a broadcast message with a source address other than its own. In other words, a system sends out a broadcast message with a spoofed source address. Any system that responds to the directed broadcast will then send its response to the system specified by the source, rather than to the source system itself. These packets can be used to create huge storms of network traffic that has disable some of the largest sites on the Internet. See National Institute of Standards and Technology - Special Publication 800-41 Pg. 59-62 for recommendations on Port/Protocol to block. Now that we have created the Firewall Applications Traffic Ruleset Matrix and the Firewall Ruleset on which it was based on, we are now in a position to flesh out the documentation for the Firewall Security Policy. What follows is a suggested template which can be supplemented with aspects of the NIST firewall policy guidelines to adapt your particular IT environment. Firewall Security Policy Draft For XYZ University Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Firewall Policy Scope and Compliance Requirements These guidelines are intended to supplement, not replace all existing laws, regulations, agreements, and contracts that currently apply to institutional computing and networking services. Persons given access to the departments technology and information assets must sign a statement that they have read, understood, and agree to abide by this policy. Firewall Policy Enforcement Security policy enforcement will emphasize the use of security technology mechanisms to mitigate security risks wherever possible. When actual prevention is not enforceable with security tools, sanctions will be used. Perimeter Security Maintenance Perimeter security for this department will be maintained by a PIX firewall. This firewall has a redundant fail over unit to provide service continuity should the primary firewall unit fail. The PIX firewall(s) will inspects packets and sessions to determine if they should be transmitted or dropped. In effect, the firewalls will act a single point of network access where traffic can be analyzed and controlled. The PIX will provide forward authentication requests to a radius server. Access to the departments internal network will be based on parameters such as (but not limited to): Application use. User authentication, authorization, and accounting, for both incoming traffic from remote users and outgoing traffic to the Internet. IP Address and port Firewall Logon Access Enable or privileged logon access to the firewall will be restricted to a Primary firewall administrator and one designee. Enable password construction will be consistent with the strong password creation practices utilized in the department. Firewall Operational Maintenance and Responsibility Day-to-Day operation and maintenance will be the responsibility of the departments Network and Security Engineer (or assigned position). Firewall support duties for the Network and Security Engineer include: Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Act as the departmental technical lead for departmental security policy and procedure implementation, has the primary responsibility for ensuring operational continuity for the departments security policy. Perform firewall rule set changes, adds and deletions as approved by the departmental security committee. Perform firewall software maintenance and hardware upgrades to the firewall; implement feature set on PIX firewalls as approved by the security committee. Monitor firewall logs, and departmental intrusion detection system. Initiate the departments response to any possible security incident. Act as the departmental liaison for incident reporting to the campus network security division. Perform security risk management by initiating a cycle of securing, monitoring, and testing security mechanisms and procedures. Review findings will be used to update security policy, procedures, and security mechanisms on a continual basis. Launch biannual review of the departmental firewall security policy to ensure the firewall policy is current with actual firewall rule set practices. PIX Firewall Log Configuration and Maintenance The pix firewall will be configured to use system logging (syslog) to export its log messages to the System Log Server (syslog) server(s). The PIX firewalls logs will be base lined thirty (30) days to determine how best to fine-tune message traffic information. At a minimum, the firewall log will be configured to detect: Emergencies, such as system unusable messages Alerts, critical conditions, and Error message VPN sessions, Failed/unsuccessful login attempts Logon Access and configuration attempts made to the firewall The PIX firewall logs will be backed up daily and archived on a weekly basis, in accordance with current practices implemented on the syslog server. In addition, the firewall will be configured to send Simple Network Management Protocol (SNMP) Traps to the network management server. Construction of SNMP access lists and community strings will be consistent with established security practices. PIX Firewall(s) Security Services At a minimum, the departmental firewall(s) will perform the following security services: Access control between the internal network and un-trusted networks. Block unwanted traffic, as determined by firewall rule sets designed to implement the departments Security Policy while providing security that does not place an undue burden on authorized users. Hide system names, network topology, network device types, and internal user ID's from the Internet. Provide more robust authentication (RADIUS/TACACS+) than standard applications. IPSEC VPN Connectivity. Log interesting traffic to and from the departments internal network. Firewall Rule Set Management and Change Control Process The departmental security committee must approve all rule set (ACLs) changes. The departmental security committee must approve all IOS changes and upgrades. At a minimum, the following information will be included in any firewall change request. Requesters Name and POC information Requested Due Date (when change will be applied) Change impact statement. Include any supporting documentation necessary to determine why the change is necessary. The change request will be delayed until change requirement has been established and approved. Rule Change Notification requirements (who need to be alerted about the change because of potential operational impact). Change Priority Level 1 emergency change needs to go in ASAP because of possible security breach 2- Change will be applied as scheduled, upon security committee approval Firewall rule sets (ACLs) will work to achieve a best practices approach in an effort to balance security risk and operational access requirements. Recommended practices include: Anything from inside the network is allowed out. All access to the firewall itself is blocked from the Internet. Restricted internal access to the firewall. Firewall administrators must be validated by two-factor authentication, such as SECURID. Allow SMTP e-mail support. ICMP services turned off Block FTP and Telnet access to all internal servers from the Internet. Remote access services for authorized users via VPN and/or campus approved secure authentication system. Ke27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 See Appendix xx for Firewall Applications Traffic Ruleset Matrix and the Firewall Ruleset Network Connection Policy The Security Committee must approve all connections from the department network to any external networks. Only network connections that have been found to have acceptable security controls and procedures will be allowed to connect to the departmental network. Every attempt will be made to ensure that all external connections will pass through firewalls that meet the guidelines established by this policy. All connections and accounts related to external network connections shall be validated on an annual basis. When a network connection is no longer needed all accounts and system processes related to the connection should be deleted within one workweek. Trusted Networks Policy Network Trust Relationships Overview Approved and authorized network connections are considered trusted networks. Trusted networks share the similar security policy or implement security controls and procedures. Un-trusted networks do not implement common security controls, or where the level of security is unknown or unpredictable. Network segments external to the department are under the control of different organizational entities, and will be considered as unknown and possibly compromised Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 The following networks are considered trusted networks and permitted controlled access by the department firewall(s). These networks are provided data services by the departments network: The xxx Backbone Network (xxx.xxx.xxx) This network contains the XXX firewall that separates XXX from the Internet and also interconnects all of the Institute networks together through xxx switches and routers Medical researchers from multiple locations traverse the backbone to retrieve patient data. This data is captured via xxx running on Windows and UNIX hosts. The xxxxx LAN (xxx.xxx.xxx.) This network hosts the xxx, xxx and xxx. The xxx network also provides remote access connectivity via the xxx network. The xxx network interconnects doctors, transcriptionists, and other authorized users using analog, cable modems, and DSL media. Non-trusted Networks Policy All networks not specifically listed as a trusted network are non-trusted networks. Access to the departments network will be denied by the firewall(s). If complete access control cannot be managed by the firewall(s), other security technologies will be used in tandem to the departments firewalls to mitigate the security threat. Modem connections with business partners and/or remote sites are also considered un-trusted networks connections. The Network and Security Engineer may terminate unauthorized connections to departmental network without notice. An active network port or connection does not imply authorization for connectivity. To support this policy, unused and/or unknown network connections (switch ports, analog lines, etc.) will be disabled until they are properly identified, documented, and placed in or out of service. Periodic Review of Firewall Security Policies Firewall security policies will be reviewed xxxx yearly. When there are major changes to the network requirements this may warrant changes to the firewall security policy. Changes include events such as the implementation of major enterprise computing environment modifications and any occurrence of a major information security incident. When new applications are being considered, a security review committee will evaluate new services before the firewall administrators are formally notified to implement the service. Alternatively, when an application is phased out or up-graded, the firewall ruleset should be formally changed where appropriate. (This approach helps to minimize the presence of old and potentially insecure rules that are no longer needed.) Firewall installations will be audited on a regular, periodic basis. These periodic reviews can be conducted on paper by reviewing hard-copy configurations provided by appropriate systems administration staff. In other cases, periodic reviews should involve actual audits and vulnerability assessments of the firewall. PAGE  PAGE 17 69 C   TUYzdh!%Pz~ EItw %&RSZ[opyzh1B*CJOJQJphh15B*CJOJQJphh1CJOJQJh1OJQJ h1>*h1B*OJQJphh15>*B*OJQJphh15OJQJh1@6789:s  C  U    $Œ$Œ$Œ$Œ$Œ$Œ$Œ$Œ$Œ$Œ$Œ$Œ$Œ$Œ$Œ$Œ$Œ$Œ$Œ$Œ $x7$8$H$a$$ & F5x7$8$H$a$ $7$8$H$a$gd1gd1$a$gd1gd1k]] 6ST#$>UVY{$Œ$Œ$Œ$Œ$Œ$ŒŒŒlŒŒlkd$$Ifl0H(04 la$$7$8$H$Ifa$ $x7$8$H$a$ $7$8$H$a$ {|ŒŒ$$7$8$H$Ifa$lkd$$Ifl0H(04 laŒwŒŒ $7$8$H$If$$7$8$H$Ifa$lkd$$$Ifl0H(04 laAeŒwŒŒ $7$8$H$If$$7$8$H$Ifa$lkd$$Ifl0H(04 laefh"ŒwŒwŒŒ $7$8$H$If$$7$8$H$Ifa$lkdH$$Ifl0H(04 la"#%QŒuŒ $7$8$H$If$$7$8$H$Ifa$lkd$$Ifl0H(04 laQRSGHIcz$Œ$Œ$Œ$Œ$wŒwŒ$If7$8$H$ $7$8$H$a$lkdl$$Ifl0H(04 laz{~ŒŒ$$7$8$H$Ifa$lkd$$Ifl0H(04 laŒŒ$$7$8$H$Ifa$lkd$$Ifl0H(04 laŒŒ$$7$8$H$Ifa$lkd"$$Ifl0H(04 la ŒŒ$$7$8$H$Ifa$lkd$$Ifl0H(04 laFŒwŒwŒŒ $7$8$H$If$$7$8$H$Ifa$lkdF$$Ifl0H(04 laFGIuŒuŒ $7$8$H$If$$7$8$H$Ifa$lkd$$Ifl0H(04 lauvwx Z$%&$Œ$Œ$Œ}n$Œn$Œn$Œn$Œc $7$8$H$a$$ & F6x7$8$H$a$7$8$H$ $7$8$H$a$lkdj$$Ifl0H(04 la &RS[pz@8Œ@8OOOO O{OOOOOOOO $$Ifa$9;fjCH>EMOPT rst  i !!#B(ôwh1OJQJhK8B*OJQJphh15>*B*OJQJphh1B*OJQJphh\tSB*CJOJQJphh\tSh\tSB*OJQJphh\tSB*OJQJphh1B*CJOJQJphh1h15B*CJOJQJphh1B*CJOJQJph.0'O'O $$Ifa$kd$$Ifl4m֞1 '08 S 04 la'/78 O{OOOO$If89<A1(O(O $$Ifa$kd $$Ifl֞1 '08 S 04 laANT\de O{OOOO$Ifefkp1(O(O $$Ifa$kd $$Ifl֞1 '08 S 04 lapv O{OOOO$If1(O(O $$Ifa$kd $$Ifl֞1 '08 S 04 la AB O{OOOO$IfBCIN1(O(O $$Ifa$kd $$Ifl֞1 '08 S 04 laNv O{OOOO$If1(O(O $$Ifa$kd $$Ifl֞1 '08 S 04 la   O{OOOO$If 1(O(O $$Ifa$kd $$Ifl֞1 '08 S 04 la#,4<= O{OOOO$If=>FK1(O(O $$Ifa$kd$$Ifl֞1 '08 S 04 laKQ_g O{OOOO$If1(O(O $$Ifa$kd$$Ifl֞1 '08 S 04 la O{OOOO$If1(O(O $$Ifa$kd$$Ifl֞1 '08 S 04 la.DLMNO O{OOOO$If$IfOPUZ1(O(O $$Ifa$kd$$Ifl֞1 '08 S 04 laZ` O{OOOO$If1(O(O $$Ifa$kd$$Ifl֞1 '08 S 04 la O{OOOO$If1(O(O $$Ifa$kd$$Ifl֞1 '08 S 04 la&>hpq O{OOOO$Ifqrst1/@8O$@8O$ $7$8$H$a$kd$$Ifl֞1 '08 S 04 la ""n#o###c%& '(P(((*_+Q-0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*ъ0*Œ0*Œ0*Œ0*Œ0*Œ & FgdK8 & FgdK8 & FgdK8h`hgdK8 & FgdK8 & FgdK8 & FgdK8 & F gdK8gdK8 7$8$H$gdK8 $7$8$H$a$B(E(/1111112222333333333494v5w555666ϴܛܔxi[M[[ihygB*OJQJhphh1B*OJQJhphh15B*OJQJhphh1B*OJQJhph h1hK8 h1h1 hK8h1h1h15CJOJQJhyg5OJQJ^Jh1h15OJQJ^Jhyg56CJOJQJh156CJOJQJh1h1B*OJQJphh1OJQJh1EH H*OJQJQ- ..11222333333484945555666660*Œ0*Œ0*Œ0*0*F0*F0*F0*Œ0*0*0*F0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œgd1gdK8 & FgdK8 & FgdK8 & FgdK8669999::;<<I@J@z@DD9DFFLLM M.MIMeMfMOPRKRRRS"SlTpTTTUUXX'Y(YҶ~rh1B*OJQJphh15B*OJQJphh15OJQJhygB*OJQJhph$h1h15B*OJQJ^Jphh1h15OJQJ^Jh1B*OJQJhphh15B*OJQJhphh1OJQJh1OJQJhh1B*OJQJhph,69999999::::;<<;==>>?I@J@y@0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ & F & F & F & F & F & F & F & F! & F  & F7$8$H$y@z@AAB)BLBBDDD9DDDEFQFiFFFFFGH6H0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ & F* & F) & F( & F' & F& & F% & F$ & F# & F"6HIIII+J,JJKSKKK LSLLLJMKMeMfMOOP0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ7$8$H$ & F4 & F3 & F2 & F1 & F0 & F/ & F.h`h & F- & F, & F+PPPRKRRRS S0SxTyTzT{TTUUUUXX(YYY~ZZ[[*\0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ 0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ0*Œ7$8$H$(YY*\j]k]l]r]s]t]v]w]}]~]]]]]]]hyghN0JmHnHuh\tS h\tS0Jjh\tS0JUh15OJQJh1B*OJQJphh1OJQJ*\+\k]t]u]v]]]]]]0*Œ0*Œ0*0*Œ &`#$gdyggdyg #0P/ =!"#$%&00P= /!"#$%* 00&PP/ =!"#$%$$If!vh55#v#v:V l0554$$If!vh55#v#v:V l0554$$If!vh55#v#v:V l0554$$If!vh55#v#v:V l0554$$If!vh55#v#v:V l0554$$If!vh55#v#v:V l0554$$If!vh55#v#v:V l0554$$If!vh55#v#v:V l0554$$If!vh55#v#v:V l0554$$If!vh55#v#v:V l0554$$If!vh55#v#v:V l0554$$If!vh55#v#v:V l0554$$If!vh55#v#v:V l0554$$If!vh55#v#v:V l0554 $$If!vh555 5S 555#v#v#v #vS #v:V l4m0,555 5S 5/ / 4$$If!vh555 5S 555#v#v#v #vS #v:V l0,555 5S 5/ 4$$If!vh555 5S 555#v#v#v #vS #v:V l0,555 5S 54$$If!vh555 5S 555#v#v#v #vS #v:V l0,555 5S 54$$If!vh555 5S 555#v#v#v #vS #v:V l0,555 5S 54$$If!vh555 5S 555#v#v#v #vS #v:V l0,555 5S 54$$If!vh555 5S 555#v#v#v #vS #v:V l0,555 5S 5/ 4$$If!vh555 5S 555#v#v#v #vS #v:V l0,555 5S 5/ / 4$$If!vh555 5S 555#v#v#v #vS #v:V l0,555 5S 5/ 4$$If!vh555 5S 555#v#v#v #vS #v:V l0,555 5S 5/ 4$$If!vh555 5S 555#v#v#v #vS #v:V l0,555 5S 5/ 4$$If!vh555 5S 555#v#v#v #vS #v:V l0,555 5S 5/ 4$$If!vh555 5S 555#v#v#v #vS #v:V l0,555 5S 5/ 4$$If!vh555 5S 555#v#v#v #vS #v:V l0,555 5S 5/ / 4@@@ NormalCJ_HaJmH sH tH \@\ Heading 1#$$7$8$@&H$]a$ >*OJQJD@D Heading 2 @& B*phD@D Heading 3$@&5B*htH uV@V Heading 4$$x7$8$@&H$a$5B*OJQJZ@Z Heading 5$$7$8$@&H$a$5>*B*OJQJ@@@ Heading 6$@& 5OJQJH@H Heading 7$$@&a$5>*OJQJDA@D Default Paragraph FontVi@V  Table Normal :V 44 la (k(No List VOV Default 7$8$H$!B*CJ_HaJmH phsH tH T0@T 1 List Bullet $xa$5>*B*OJQJph@B@@ Body TextB*OJQJphD"D Caption hB*OJQJphHC@2H Body Text Indenthx^hTP@BT Body Text 27$8$H$] B*OJQJLQ@RL Body Text 307$8$H$]0OJQJ4 @b4 ygFooter  !.)@q. yg Page Number&U%M z z z z z v$v@z@ z@ z@ z@ z@ z@z@z@z@zZS &P"+2< DyL+TU{) ]  4  G@6789:sCU6ST# $ > U V Y { |  A e f h " # % Q R S G H I c z { ~   FGIuvwx Z$%&RS[pz'/789<ANT\defkpv ABCINv  #,4<=>FKQ_g.DLMNOPUZ`&>hpqrstnoc  P "_#Q% &&))***++++++,8,9,----.....11111112222344;55667I8J8y8z899:):L::<<<9<<<=>Q>i>>>>>?@6@AAAA+B,BBCSCCC DSDDDJEKEeEfEGGHHHJKJJJK K0KxLyLzL{LLMMMMPP(QQQ~RRSS*T+TkUtUuUvUUUUUh0@0@0@0X@0X@0X@0X@000x0005 05 05 005 05 05 05 00800000x0000 0 0 0 0 0 0 0 0 0 00 0 0 00 0 0 000 0 0 0 0 000000( 0( 0, 0( 0( 0, 0( 0( 0, 0( 0( 0, 0( 0( 0, 0( 0(0(0( 0, 0( 0( 0, 000006 0x6 06 06 000H00&0&(0&( 0&( 0&( 0&( 0&(0&( 0&(0&(0&(0&( 0&( 0&, 0&( 0&( 0&( 0&( 0&( 0&( 0&( 0&, 0&( 0&( 0&( 0&( 0&( 0&( 0&( 0&, 0&( 0&( 0&( 0&( 0&( 0&( 0&( 0&, 0&( 0&( 0&( 0&( 0&( 0&( 0&( 0&, 0&( 0&( 0&( 0&( 0&( 0&( 0&( 0&, 0&( 0&( 0&( 0&( 0&( 0&( 0&( 0&, 0&( 0&( 0&( 0&( 0&( 0&( 0&( 0&, 0&( 0&( 0&( 0&( 0&( 0&( 0&( 0&, 0&( 0&( 0&( 0&( 0&( 0&( 0&( 0&, 0&( 0&( 0&( 0&( 0&( 0&( 0&(0&(0&( 0&, 0&( 0&( 0&( 0&( 0&( 0&( 0&( 0&, 0&( 0&( 0&( 0&( 0&( 0&( 0&( 0&, 0&( 0&( 0&( 0&( 0&( 0&( 0&( 0&, 0&0x000&x0&x0&0&0&0&0& 0& 0& 0& 0&0&0&0& 0& 0& 0&x 0&  0&  0& 0& 0 0&0&0&(0&x0&x0&x0&H0&x0&(0&(0&(0&(0&(00,(0,(0,(0,(0,(0,0,( 0,( 0,! 0,(0,(0,(0,(0,(0,(0,0,(0,00,0 0,0 0,0 0,0 0, 0, 0,0 0,00,00,00,00,0" 0," 0," 0," 0,0" 0,00,00,00,0,0,# 0,$ 0,% 0,& 0,' 0,( 0,0,0,0,0,) 0,* 0,+ 0,, 0,- 0,0,0,0,0,. 0,/ 0,0 0,1 0,2 0,3 0,4 0,0,0,@0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,00rO0rO0rO0rO0rO0rO0rO0rO0@00\>00B00\>00B0 0 B(6(Y]/A^`e {e"QzFu&8AepBN =KOZqQ-6y@6HP*\]023456789:;<=>?@BCDEFGHIJKLMNOPQRSTUVWXYZ[\]_abcdf]1 !!8@0(  B S  ?kJ<llJ<DsJ<tJ<<uJ<|`J<aJ<bJ<<J)))+++UP)))+++U9*urn:schemas-microsoft-com:office:smarttagsplace=*urn:schemas-microsoft-com:office:smarttags PlaceType=*urn:schemas-microsoft-com:office:smarttags PlaceName8*urn:schemas-microsoft-com:office:smarttagsdate 1522005DayMonthYearkUUkUU$$s))))*3+=+>+++++++--DD賢ᱫ챫UUU챫U6k):ܱݒq< k l_ "  G Wa J 7  b , l- /& {b  h[ u !Yڦ*( Ge0 2 73 4t 8 zs9 (79 e`< \= = {S@Hnq03eC uiE MKWI M OPZ4Q zR c+Y 7q[ jDd<m0g MRh h %i3Bsj 5j (l-k  "gn [t  cw h{ B  hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo(^`OJQJo(hH^`OJQJ^Jo(hHopp^p`OJQJo(hH@ @ ^@ `OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHoPP^P`OJQJo(hH hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo(hh^h`CJOJQJo(q hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo( hh^h`OJQJo(6[upfPkljDd4%i{S@O!c+Y2/&,7m0gl_03eCh{J u e`<" (l-kGWaGe0zs9M\= "gn[tl-uiEhk  8B7q[5j cwh[BsjMKWI b73*((79zR=MRh4Q66K8\tSygN1# $ > U V Y { |  e f h " # % Q R H I c z { ~   FGIuvRSpz'/789<ANT\defkpv ABCINv  #,4<=>FKQ_g.DLOPUZ`&>hpqrjUU' 1yp0@a@UP@UnknownGz Times New Roman5Symbol3& z ArialO& k9?Lucida Sans Unicode;Wingdings?5 z Courier New"hzF {F  H+ H+!~4d@U@U693QH(?K8~A firewall policy is distinct from the information security policy, in as much as it is simply a description of how the inform Lennox Brown Lennox Brown6                           ! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 Oh+'0(4LXdx     A firewall policy is distinct from the information security policy, in as much as it is simply a description of how the inform fi Lennox Brownlicennenn Normal.dotn Lennox Brownlic11nMicrosoft Word 10.0@8@ @y@ H՜.+,0 hp  cϡȱs+@U A firewall policy is distinct from the information security policy, in as much as it is simply a description of how the inform Title  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefgijklmnopqrtuvwxyz{|}~Root Entry F@SData h1TablesrkWordDocumentySummaryInformation(DocumentSummaryInformation8CompObjj  FMicrosoft Word Document MSWordDocWord.Document.89q