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 Difference Between Policies, Standards, Guidelines, and ProceduresOne 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:
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 FormatTo 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:
Common Security PoliciesEach 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:
Firewall policies (that is, the access policies on the actual firewalls) are covered later in this chapter. Note For more information about security policies and how to write effective security policies, check out the following resources:
Management-Access PolicyAs 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 PolicyRather 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 PolicyThe 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 PolicyIn 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 PolicyOne 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-party management and monitoring applications such as CiscoWorks, NetIQ Security Manager, or Kiwi Syslog Daemon. DMZ PolicyThe 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 ResponsibilitiesAs 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:
Secure Configuration RequirementsBecause 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:
Note For more information about industry-accepted hardening guides and recommendations, see the Security Configuration Guides located at http://www.nsa.gov/snac/. These are an excellent resource for using as the baseline from which to develop your own organization-specific hardening recommendations. Operational and Change-Control RequirementsThe 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 PoliciesIn 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:
Firewall Security PolicyOne 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 IntegrityTo ensure that your firewall security policy adequately addresses physical security, make sure that the following elements are components of the security policy:
Firewall Static ConfigurationTo ensure that your firewall security policy adequately addresses static configuration security, make sure that the following elements are components of the security policy:
Firewall Dynamic ConfigurationTo ensure that your firewall security policy adequately addresses dynamic configuration security, make sure that the following elements are components of the security policy:
Network Traffic through the FirewallTo 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:
This information should be used to build your ingress and egress filters, as discussed in the next section. |