An Approach to Creating Your Firewall

Security Policy

Presented by: Lennox Brown – USM IAO Manager IS Audits

To : IT Security Contacts
Date : 2/15/2005

1
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
organization’s 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 organization’s information
technology infrastructure should be weighed based on an evaluation of the

2
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/IT Security Issue/concern

10 Remote Access to System Resources

10 Internet access to System Resources

10 Data Exchange - securing all communications

pathways to and from
system Resources

7 Minimal or weak network data accountability

mechanisms that link all
network activity to a user identity

6 Minimal 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)

4 Web Surfing and downloads to/from

Resources

3
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/IT Security Issue/concern

10 Remote Access to System Resources

10 Internet access to System Resources

8 Data Exchange - securing all communications

pathways to and from system Resources

8 Minimal or weak network data accountability

mechanisms that link all network activity to a
user identity

6 Minimal 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)

8 Web 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.

4
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

5
 Firewall Application Traffic Ruleset Matrix

FIREWALL EXPLANATION
TCP/IP FIREWALL SECURITY
LOCATIO INTERNAL HOST SECURITY
APPLICA- INTERNAL HOST TYPE POLICY
N SECURITY POLICY POLICY
TIONSERVICE (Internal)
(External)
Finger Any Unix TCP Wrapper Permit Reject
" Any PC - TCP/IP None Permit Permit
No Anonymous; Application Proxy
FTP Any Unix UserID/Password; Permit with User
Secure Shell (SSH) Authentication
Application Proxy
Client Only; Anti-
" Any PC - TCP/IP Permit with User
Virus
Authentication
Secure Mode; Permit Permit Only Local
Unix Server with
TFTP Any tftp to Limited Domain; Reject Reject
Diskless Clients Only
Directories Other
" Any Unix - All Other Disable Reject Reject
" Any PC - TCP/IP Disable Reject Reject
Application Proxy
Telnet Any Unix Secure Shell Permit with User
Authentication
Application Proxy
" Any PC - TCP/IP Client Only Permit with User
Authentication

2 Password Layers; Token

" Any Router/Firewall Reject
Token Authentication Authentication

NFS Any UNIX Limit Exports; Reject All, except by Reject

6
 FIREWALL EXPLANATION
TCP/IP FIREWALL SECURITY
LOCATIO INTERNAL HOST SECURITY
APPLICA- INTERNAL HOST TYPE POLICY
N SECURITY POLICY POLICY
TIONSERVICE (Internal)
(External)
Host/Groups Written
(Granular Access) Authorization
" Any PC - TCP/IP Client Only Reject Reject
Permit Local Do-
NetBIOS over
Any Windows NT/95/WFW Limit Access to Shares main Only; Reject Reject
TCP/IP
Others

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.

7
9
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 CIDR 14 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.

10
 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.

11
 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 department’s 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 department’s 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.

12
Firewall Operational Maintenance and Responsibility

Day-to-Day operation and maintenance will be the responsibility of the department’s

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 department’s 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 department’s 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 firewall’s 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.
13
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
department’s 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 department’s internal network.

Firewall Rule Set Management and Change Control Process

The departmental security committee must approve all rule set (ACL’s) 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 (ACL’s) 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
14
 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
department’s 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.

15
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 department’s 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
department’s 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.)

16
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.

17