Tài liệu Written Security Policies ppt

Written Security Policies
Written security policies exist to provide a high-level roadmap of what needs to be done
to ensure that the organization has a well-defined and thought-out security strategy. It is a
common misconception that an organization has a security policy. In fact, an
organization's overall security policy typically consists of numerous individual security
policies, which are written to address specific objectives, devices, or issues.
The objective of a security policy is to define what needs to be protected, who is
responsible for protection, and in some cases how the protection will occur. This last
function is typically separated out into a standalone procedure document such as the
ingress-filtering, egress-filtering, or management-access policy documents discussed later
in this chapter. In a nutshell, the security policy should simply and concisely outline the
specific requirements, rules, and objectives that must be met, to provide a measurable
method of validating the security posture of the organization.
To help ensure that your security policies will do this, think of the firewall in terms of
security layers, with each layer having a specific realm of operation. Figure 10-1

illustrates this layered view of the firewall. As you can see, the firewall is separated into
four distinct components.
Figure 10-1. Firewall Security Layers


At the center is the firewall physical integrity layer, which is predominantly concerned
with the physical access to the firewall. Consequently, you want to ensure that your
security policies address issues related to gaining physical access to the device, such as
through a hard console port connection.
The next layer is the firewall static configuration, which is predominantly concerned with
access to the static configured software the firewall is running (for example, the PIX
operating system and startup configuration). At this layer, your security policy needs to

focus on defining the controls that will be required to restrict administrative access,
including performing software updates and configuring the firewall.
The third layer is the firewall dynamic configuration, which complements the static
configuration by being concerned with the dynamic configuration of the firewall through
the use of technologies such as routing protocols, Address Resolution Protocol (ARP)
commands, interface and device status, audit logs, and shun commands. The objective of
the security policy at this point is to define the requirements around what kinds of
dynamic configurations will be permitted.
Finally, you have the network traffic through the firewall layer, which is really what the
firewall exists to doprotect resources. This layer is concerned with functionality such as
ACLs and service proxy information. The security policy at this layer is responsible for
defining the requirements as they relate to traffic passing through the firewall.
Tip
When you decide to create your security policies, remember a couple of things:
• The security policy should specify security objectives, not necessarily the actual
configuration or commands that need to be run. This allows the policy to be
portable across platforms, because all firewalls typically have the same issues and
requirements, regardless of the actual commands or configuration required to
achieve the requirements.
• In working through your policies, continue to refer back to the layered structure in
Figure 10-1
to ensure that the policy addresses all potential issues. Work from the
inside (physical security) to the outside. Doing so will reduce the likelihood of
overlooking a critical security requirement.


The Difference Between Policies, Standards, Guidelines, and Procedures
One of the more confusing elements of security policies is the interaction between
policies, standards, guidelines, and procedures. First, let's define what we mean by each:
• Policy A policy is a document that outlines the requirements or rules that must be

met. Policies frequently refer to standards or guidelines as the basis for the
existence. The scope of a policy tends to be a broad, high level statement of intent.
An example of a policy is an Encryption Use Policy, which might state to the
effect of "encryption should be used in these circumstances."
• Standard A standard is a set of requirements, typically system or technology
specific, that must be adhered to by everyone. The scope of a standard tends to be
to specify the requirements about a given technology or area. An example might
be defining that the only acceptable encryption algorithms are Triple DES (3DES)
or Advanced Encryption Standard (AES).
• Guideline A guideline is similar to a standard, but it differs in that unlike a
standard, a guideline is merely a recommendation or suggestion that should
probably be followed but is not necessarily required. Guidelines and standards are
largely interchangeable in most cases.
• Procedure A procedure defines the process that is followed to meet the
requirements of a policy, standard, or guideline. The scope of a procedure is the
specific step-by-step processes and procedures that should be followed for
implementing a given standard or guideline. An example of this might be defining
the procedures required to implement 3DES or AES encryption on your firewalls.
Figure 10-2
helps to illustrate the relationship between policies, standards, and
procedures as a pyramid. Keep in mind that standards and guidelines are interchangeable
and occupy the same level in the pyramid. As you go down the pyramid, the documents
get more detailed and are more subject to change. So, policies are broad and do not
change often. Standards and guidelines are more detailed but more susceptible to change.
Procedures are extremely detailed and may frequently change as they incorporate new
standards or methods of performing the given tasks.
Figure 10-2. Policies, Standards, and Procedures Pyramid

Security Policy Format
To accomplish the goals defined previously, most security policies adhere to a particular
format or layout and share common elements. Generally speaking, most security policies
share seven sections:
• Overview The overview section provides a brief explanation of what the policy
addresses.
• Purpose The purpose section explains why the policy is needed.
• Scope The scope section defines what the policy applies to and defines who is
responsible for the policy.
• Policy The policy section is the actual policy itself.
• Enforcement The enforcement section defines how the policy should be enforced
and the repercussions of not following the policy.
• Definitions The definitions section contains the definition of any terms or concepts
used in the policy.
• Revision history The revision history section is where the changes to the policy
are documented and tracked.
Common Security Policies
Each organization has unique security requirements and therefore their own unique
security policies. However, most if not all environments require a number of common
security policies, including the following:
• Management-access policy
• Filtering policy
• Routing policy
• Remote-access/VPN policy
• Monitoring/logging policy
• Demilitarized zone (DMZ) policy
• Generally applicable policies
Firewall policies (that is, the access policies on the actual firewalls) are covered later in
this chapter.
N

ote
For more information about security policies and how to write effective security policies,
check out the following resources:
• RFC 2196, Site Security Handbook
• RFC 2504, Users' Security Handbook
• SANS Security Policy Project
• Hardening Network Infrastructure (by Wes Noonan, McGraw-Hill Osborne
Media), Chapters 2
and 13


Management-Access Policy
As the name implies, the management-access policy exists to define the permissible
methods and manner of management access to the firewall. This policy tends to address
the firewall physical integrity and firewall static configuration security layers. The
management-access policy needs to define which protocols for both remote and local
management will be allowed, as well as which users can connect to the firewall and
which permissions those users will have to perform tasks.
In addition, the management-access policy should define the requirements for
management protocols such as Network Time Protocol (NTP), syslog, TFTP, FTP,
Simple Network Management Protocol (SNMP), and any other protocols that may be
used to manage and maintain the device.
Filtering Policy
Rather than defining the actual ruleset a firewall will use, the filtering policy needs to just
and concisely define the kinds of filtering that must be used and where filtering is
applicable. This policy tends to address the firewall static configuration and in particular
the network traffic through the firewall layers. For example, a good filtering policy needs
to require both ingress and egress filtering be performed with the firewall. The filtering
policy should also define the general requirements in connecting dissimilar security level
networks and resources. For example, with a DMZ, depending on the direction of the

traffic, different filtering requirements may be necessary, and it is the role of the filtering
policy to define those requirements.
Routing Policy
The routing policy is typically not a firewall-centric document. However, with more
complex perimeter designs as well as the increasing use of firewalls within the internal
network, firewalls can easily become part of the routed infrastructure. The routing policy
should have a section that specifies including a firewall in the routed infrastructure and
defines the method in which the routing will occur. This policy tends to address the
firewall static configuration and firewall dynamic configuration layers. In most cases, the
routing policy should explicitly prohibit the firewall from sharing the internal network
routing table with any external resources. Similarly, the routing policy should define the
circumstances in which dynamic routing protocols and static routes are appropriate. The
policy should also define any protocol-specific security mechanisms that should be
configured, (for example, the use of hashing algorithms to ensure only authenticated
nodes can pass routing data).
Remote-Access/VPN Policy
In today's realm of convergence, the difference between the firewall and the VPN
concentrator have become more and more blurred. Virtually all major-market firewalls
can serve as the termination point for VPNs, and therefore the remote-access/VPN policy
needs to define the requirements for the level of encryption and authentication that a VPN
connection will require. In many cases, the VPN policy in conjunction with the
organization's encryption policy defines the overall VPN methodology that will be used.
This policy tends to address the firewall static configuration and network traffic through
the firewall layers.
The remote-access/VPN policy also needs to define the protocols that will be used: IP
Security (IPsec), Layer 2 Transport Protocol (L2TP), or Point-to-Point Transport Protocol
(PPTP). In most cases, IPsec should be used exclusively. Assuming IPsec, the remote-
access/VPN policy needs to require the use of preshared keys and extended
authentication, with the use of certificates, one-time passwords, and a full Public Key
Infrastructure (PKI) for the most secure of environments. Similarly, the remote-

access/VPN policy should define what client will be used (that is, the built-in Microsoft
VPN client, the Cisco Secure VPN Client, and so on).
Finally, the remote-access/VPN policy needs to define what kind of access and resources
will be made available to remote connections and the types of remote connections that
will be allowed. For example, if you will allow site-to-site as well as remote client VPN
connections, the remote-access/VPN policy needs to define when each type of connection
will be used.
Monitoring/Logging Policy
One of the most critical elements of ensuring that a firewall is providing the expected
level of security is to implement a firewall monitoring system. The monitoring/logging
policy defines the methods and degree of monitoring that will be performed. At a
minimum, the monitoring/logging policy should provide a mechanism for tracking the
performance of the firewall as well as the occurrence of all security-related events and
log entries. This policy tends to address the firewall static configuration layer.
The monitoring/logging policy should also define how the information should be
collected, maintained, and reported on. In many cases, this information can be used for
defining the requirements of third-
p
arty management and monitoring applications such as
CiscoWorks, NetIQ Security Manager, or Kiwi Syslog Daemon.
DMZ Policy
The DMZ policy is a wide-ranging document that defines all the elements of not only the
DMZ itself but the devices in the DMZ, too. The objective of the DMZ policy is to define
the standards and requirements of all devices and connectivity and traffic flow as it
relates to the DMZ. This policy tends to address the firewall static configuration and
network traffic through the firewall layers.
Because of the complexity of the typical DMZ environment, the DMZ policy is
potentially going to be a large, multipage document. To help ensure that the DMZ policy
remains functional and effective, typically three broad standards should be defined for all
DMZ-related devices, connectivity, and traffic flow:

• Ownership responsibilities
• Secure configuration requirements
• Operational and change-control requirements
Ownership Responsibilities
As illustrated in Chapter 8
, "Application Proxy Firewalls," the DMZ has the potential of
being the most complex network segment in your entire network, including systems and
applications for any number of different groups. Consequently, it is critical to define not
only who is responsible for any given system or application but also what those
responsibilities entail. Common requirements include the following:
• Full documentation of resources in the enterprise management system
• Appropriate name resolution for all addressable network interfaces
• Immediate access to systems in accordance with the corporate audit policy
• Full adherence to the corporate change control policy
• A 24/7 contact list that ownership groups will make available in the event that
systems need to be accessed outside of normal work hours
Secure Configuration Requirements
Because of the unique situation of DMZ systems existing in many cases to allow
unknown users to access resources, systems in the DMZ typically must be more secured
than would be a typical system on the internal network (for right or wrong, some would
contend that all systems should be as hardened as possible, regardless of their location in
the network). As a result, it is important to define configuration requirements, such as the
following:
• All systems must be patched with vendor updates in a timely fashion.
• All systems and software must be approved by the organizations IT security
group.
• All systems must be hardened in accordance with corporate hardening standards.
• All unnecessary software and services must be either disabled or uninstalled if
possible.
• Service access must be restricted through the use of ACLs and proxy servers

where possible.
• All remote administration must occur over secure channels.
• All systems must be monitored and all events must be saved to an approved log
format.
• No administration capabilities will be permitted from external sources.
• All trust relationships between systems will only be permitted if a valid business
justification and no alternative workarounds are available.
• Systems will be segmented within the DMZ.
N
ote
For more information about industry-accepted hardening guides and recommendations,
see the Security Configuration Guides located at />. These are an
excellent resource for using as the baseline from which to develop your own
organization-specific hardening recommendations.


Operational and Change-Control Requirements
The operational requirements define what must be done for day-to-day operation and
maintenance. The key elements of the operational requirements are to ensure that all
systems must adhere to the corporate change-management policy and that all
configuration changes must be authorized by the corporate IT security group.
Additionally, the operational requirements should stipulate that all adds, moves, and
changes must adhere to the corporate DMZ deployment process and procedure.
Generally Applicable Policies
In addition to firewall-specific policies, there are numerous generally applicable policies
that although not firewall specific (they have application to many devices, not just
firewalls) should nonetheless be applicable to the firewall. These include the following:
• Password policy The corporate password policy should be referred to for not only
defining administrative access to the firewall but for use in creating preshared
secrets, hashes, and community strings.

• Encryption policy The corporate encryption policy should be referred to for
defining all forms of encrypted access, including Hypertext Transfer Protocol,
Secure (HTTPS), Secure Sockets Layer (SSL), Secure Shell (SSH), and
IPsec/VPN access.
• Auditing policy The corporate auditing policy should be referred to for defining
the audit requirements of the firewall.
• Risk-assessment policy The corporate risk-assessment policy should be referred to
for defining the methodology that will be used to identify the risks associated with
all system add, moves, and changes as it relates to the firewall and network
perimeter in general.
Firewall Security Policy
One of the reasons for covering this security policy separately after the other common
security policies is that it may well contain or replace elements of any of the previously
mentioned security policies. The firewall security policy (sometimes known as the
firewall policy) should address all the firewall-specific security requirements, as defined
in the layered structure of Figure 10-1
. In doing this, the firewall policy may overlap,
include, or refer to elements from any of the previous mentioned security policies. In
addition, if any other security policies are applicable to the firewall, they should be
referenced in this document. A good checklist to ensure complete coverage of your
firewall security policy is to build a checklist based on the four layers from Figure 10-1
.
The following sections cover these four layers.
Firewall Physical Integrity
To ensure that your firewall security policy adequately addresses physical security, make
sure that the following elements are components of the security policy:
• Define who is authorized to install, uninstall, and move the firewall.
• Define who is authorized to perform hardware maintenance and to change the
physical configuration of the firewall.
• Define who is authorized to physically connect to the firewall, in particular

through the console port or physical logon console.
• Define the appropriate recovery requirements in the event of a physical failure or
evidence of tampering with the firewall.
Firewall Static Configuration
To ensure that your firewall security policy adequately addresses static configuration
security, make sure that the following elements are components of the security policy:
• Define who is authorized to login to the firewall via any connectivity method
(local or remote).
• Define the appropriate privileges and users to which the privileges are applicable.
• Define the procedures for performing configuration changes and firewall updates.
• Define the password policy (typically in conjunction with the corporate password
policy) for the firewall.
• Define the method of remote login capability, including defining the permitted
networks or systems from which remote logins will be allowed (typically in
conjunction with the management-access policy).
• Define the recovery procedures for the firewall in the event of a failure.
• Define the audit log policy for the firewall (typically in conjunction with the
corporate audit policy).
• Define the encryption requirements for the firewall (typically in conjunction with
the corporate encryption policy).
• Define the method of remote management and monitoring (that is, SNMP, syslog,
and so on) for the firewall (typically in conjunction with the management-access
policy).
Firewall Dynamic Configuration
To ensure that your firewall security policy adequately addresses dynamic configuration
security, make sure that the following elements are components of the security policy:
• Define what kinds of dynamic configuration processes and services will be
permitted to run on the firewall as well as what networks and devices will have
access to those processes and services.
• Define the routing protocols that will be allowed and the security features that will

be required.
• Define how the firewall will update and maintain the clock information (that is,
NTP).
• Define how one-time password or similar authentication or dynamic encryption
and key algorithms will be maintained.
Network Traffic through the Firewall
To ensure that your firewall security policy adequately addresses traffic through the
firewall, make sure that the following elements are components of the firewall security
policy:
• Define the method by which traffic will be permitted and denied (for example, will
traffic be permitted to specific segments and so on).
• Define the process for requesting changes and updates to the firewall ruleset.
• Define the kinds of protocols, ports, and services that will be permitted or denied
(this information may be included in more detail in a separate ingress- and egress-
filtering document).
This information should be used to build your ingress and egress filters, as discussed in
the next section.