Written Security Policies

Chia sẻ: Tuan Bui Nghia | Ngày: | Loại File: PDF | Số trang:11

Thêm vào BST

Báo xấu

97
lượt xem 9
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Written Security Policies

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. Note For more information about security policies and how to write effective security policies, check out the following resources: • RFC 2196, Site Security Handbook http://www.ietf.org/rfc/rfc2196.txt • RFC 2504, Users' Security Handbook http://www.ietf.org/rfc/rfc2504.txt • SANS Security Policy Project http://www.sans.org/resources/policies/ • 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-party 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. 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 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.