Firewall policies and vpn configurations 2006 phần 2
- 50 trang
- file .pdf
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 30
30 Chapter 1 • Network Security Policy
■ Perform baseline network mapping and performance monitoring
■ Identify risk to resources and appropriate mitigation processes
■ Identify potential security threats, both external and internal
■ Identify needed access points from external sources
■ Public networks
■ VPN access
■ Extranets
■ Remote access services
■ Identify critical services
■ Plan your DMZ
Figure 1.1 A Basic Network with a Single Firewall
Untrusted
or
Internet
Router
Hardware
or
Software
Firewall
LAN
Figure 1.1 shows the basic configuration that would be used in a simple network sit-
uation in which there was no need to provide external services.This configuration
would typically be used to begin to protect a small business or home network. It
could also be used within an internal network to protect an inner network that had
to be divided and isolated from the main network.This situation could include
Payroll, Finance, or Development divisions that need to protect their information
and keep it away from general network use and view.
Figure 1.2 details a protection design that would allow for the implementation
and provision of services outside the protected network. In this design, it would be
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 31
Network Security Policy • Chapter 1 31
imperative that rules be enacted to not allow the untrusted host to access the
internal network. Security of the bastion host machine would be accomplished on
the machine itself, and only minimal and necessary services would be enabled or
installed on that machine. In this design, we might be providing a Web presence that
did not involve e-commerce or the necessity to dynamically update content.This
design would not be used for provision of virtual private network (VPN) connec-
tions, FTP services, or other services that required other content updates to be per-
formed regularly.
Figure 1.2 Basic Network, Single Firewall and Bastion Host (Untrusted Host)
Untrusted
or
Internet
Bastion Host (untrusted Host)
Firewall
Internal Network
Figure 1.3 shows a basic DMZ structure. In this design, the bastion host is partially
protected by the firewall. Rather than the full exposure that would result to the bas-
tion host in Figure 1.2, this setup would allow us to specify that the bastion host in
Figure 1.2 could be allowed full outbound connection, but the firewall could be
configured to allow only port 80 traffic inbound to the bastion host (assuming it was
a Web server) or others as necessary for connection from outside.This design would
allow connection from the internal network to the bastion host if necessary, and
potentially allow updating of Web server content from the internal network if
allowed by firewall rule, which could allow traffic to and from the bastion host on
specific ports as designated.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 32
32 Chapter 1 • Network Security Policy
Figure 1.3 A Basic Firewall with a DMZ
Untrusted
or
Internet
Bastion Host (untrusted Host) Firewall
Internal Network
Figure 1.4 shows a generic dual-firewall DMZ configuration. In this arrangement,
the bastion host can be protected from the outside and allowed to connect to or
from the internal network. In this arrangement, like the conditions in Figure 1.3,
flow can be controlled to and from both of the networks away from the DMZ.This
configuration and method is more likely to be used if more than one bastion host is
needed for the operations or services being provided.
Figure 1.4 A Dual Firewall with a DMZ
Untrusted
or
Internet
Outer Firewall
Bastion Host (untrusted Host)
Inner Firewall
Internal Network
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 33
Network Security Policy • Chapter 1 33
Traffic Flow Concepts
Now that we’ve had a quick tour of some generic designs, let’s look at the way net-
work communications traffic typically flows through them. Be sure to note the dif-
ferences between the levels and the flow of traffic and protections offered in each.
Figure 1.5 illustrates the flow pattern for information through a basic single-fire-
wall setup.This type of traffic control can be achieved through hardware or software
and is the basis for familiar products such as Internet Connection Sharing (ICS) and
the NAT functionality provided by digital subscriber line (DSL) and cable modems
used for connection to the Internet. Note that flow is unrestricted outbound, but
the basic configuration will drop all inbound connections that did not originate
from the internal network.
Figure 1.5 Basic Single-Firewall Flow
Untrusted
or
Internet
...Inbound
Traffic ...
Router
Hardware
Inbound stopped at or
FW unless allowed Software
by rule Firewall
LAN
--- Outbound Traffic --
Figure 1.6 reviews the traffic flow in a network containing a bastion host and a
single firewall.This network configuration does not produce a DMZ; the protection
of the bastion host is configured individually on the host and requires extreme care
in setup. Inbound traffic from the untrusted network or the bastion host is dropped
at the firewall, providing protection to the internal network. Outbound traffic from
the internal network is allowed.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 34
34 Chapter 1 • Network Security Policy
Figure 1.6 A Basic Firewall with Bastion Host Flow
Untrusted
or
Internet
Bastion Host (untrusted Host)
Firewall
Internal Network
Figure 1.7 shows the patterns of traffic as we implement a DMZ design. In this
form, inbound traffic flows through to the bastion host if allowed through the fire-
wall and is dropped if destined for the internal network.Two-way traffic is permitted
as specified between the internal network and the bastion host, and outbound traffic
from the internal network flows through the firewall and out, generally without
restriction.
Figure 1.7 A Basic Single Firewall with DMZ Flow
Untrusted
or
Internet
Firewall
Bastion Host (untrusted Host)
Internal Network
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 35
Network Security Policy • Chapter 1 35
Figure 1.8 contains a more complex path of flow for information, but provides the
most capability in these basic designs to allow for configuration and provision of ser-
vices to the outside. In this case, we have truly established a DMZ, separated and
protected from both the internal and external networks.This type of configuration is
used quite often when there is a need to provide more than one type of service to
the public or outside world, such as e-mail, Web servers, DNS, and so forth.Traffic
to the bastion host can be allowed or denied as necessary from both the external and
internal networks, and incoming traffic to the internal network can be dropped at
the external firewall. Outbound traffic from the internal network can be allowed or
restricted to the bastion host (DMZ network) or the external network.
Figure 1.8 A Dual Firewall with DMZ Flow
Untrusted
or
Internet
Outer Firewall
Bastion Host (untrusted Host)
Inner Firewall
Internal Network
As you can see, there is a great amount of flexibility in the design and function
of your protection mechanisms. In the sections that follow, we expand further on
conditions for the use of different configurations and on the planning to implement
them.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 36
36 Chapter 1 • Network Security Policy
Networks with and without DMZs
As we pursue our discussions about the creation of DMZ structures, it is appropriate
to also look at the reasoning behind the various structures of the DMZ, and when
and where we’d want to implement a DMZ or perhaps use some other alternative.
During our preview of the concepts of DMZs, we saw in Figures 1.5 to 1.8
some examples of potential design for network protection and access.Your design
may incorporate any or all of these types of configuration, depending on your orga-
nization’s needs. For instance, Figure 1.5 shows a configuration that may occur in the
case of a home network installation or perhaps with a small business environment
that is isolated from the Internet and does not share information or need to provide
services or information to outside customers or partners.This design would be suit-
able under these conditions, provided configuration is correct and monitored for
change.
Figure 1.6 illustrates a network design with a bastion host located outside the
firewall. In this design, the bastion host must be stripped of all unnecessary function-
ality and services and protected locally with appropriate file permissions and access
control mechanisms.This design would be used when an organization needs to pro-
vide minimal services to an external network, such as a Web server. Access to the
internal network from the bastion host is generally not allowed, because this host is
subject to compromise.
Figure 1.7 details the first of the actual DMZ designs and incorporates a
screened subnet. In this type of design, the firewall controls the flow of information
from network to network and provides more protection to the bastion host from
external flows.This design might be used when it is necessary to regularly update
the content of a Web server, or provide a front end for mail services or other ser-
vices that need contact from both the internal and external networks. Although
better for security purposes than Figure 1.6, this design still produces an untrusted
relationship in the bastion host in relation to the internal network.
Finally, Figure 1.8 provides a design that allows for the placement of many types
of service in the DMZ.Traffic can be very finely controlled through access at the
two firewalls, and services can be provided at multiple levels to both internal and
external networks.
In the next section, we profile some of the advantages and disadvantages of the
common approaches to DMZ architecture and provide a checklist of sorts to help
you to make a decision about the appropriate use (or not) of the DMZ for
protection.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 37
Network Security Policy • Chapter 1 37
Pros and Cons of DMZ Basic Designs
Table 1.6 details the advantages and disadvantages of the various types of basic design
discussed in the preceding section.
Table 1.6 Pros and Cons of Basic DMZ Designs
Basic Design Advantages Disadvantages Appropriate Use
Single firewall Inexpensive, fairly Much lower Home, small
easy configuration, security capabilities,office/home office
low maintenance no growth or (SOHO), small busi-
expansion potential ness without need to
provide services to
others
Single firewall Lower cost than Bastion host Small business
with bastion host more robust extremely vuln- without resources
alternatives erable to for more robust
compromise, implementation or
inconvenient to static content being
update content, provided that
loss of doesn’t require
functionality other frequent updates
than for required
services; not
scalable
Single firewall Firewall provides Single point of Networks requiring
with screened protection to both failure; some access to the bastion
subnet and internal network products limit host for updating
bastion host and bastion host, network addressing information
limiting some of to DMZ in this
the potential configuration to
breach possibilities public addresses,
of an unprotected which might not
bastion host be economic or
possible in your
network
Continued
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 38
38 Chapter 1 • Network Security Policy
Table 1.6 continued Pros and Cons of Basic DMZ Designs
Basic Design Advantages Disadvantages Appropriate Use
Dual firewall Allows for establish- Requires more Larger operations
with DMZ ment of multiple hardware and that require the
service-providing software for capability to offer
hosts in the DMZ; implementation of multiple types of
protects bastion this design; more Web access and
hosts in DMZ from configuration work services to both the
both networks, and monitoring internal and external
allows much more required networks involved
granular control
of resources and
access; removes
single point of
failure and attack
Configuring & Implementing…
Bastion Hosts
Bastion hosts must be individually secured and hardened because they are always
in a position that could be attacked or probed. This means that before place-
ment, a bastion host must be stripped of unnecessary services, fully updated with
the latest service packs, hot fixes, and updates, and isolated from other trusted
machines and networks to eliminate the possibility that its compromise would
allow connection to (and potential compromise of) the protected networks and
resources. This also means that a machine being used for this purpose should
have no user accounts relative to the protected network or directory services
structure, which could lead to enumeration of your internal network.
DMZ Design Fundamentals
DMZ design, like security design, is always a work in progress. As in security plan-
ning and analysis, we find DMZ design carries great flexibility and change potential
to keep the protection levels we put in place in an effective state.The ongoing work
is required so that the system’s security is always as high as we can make it within
the constraints of time and budget, while still allowing appropriate users and visitors
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 39
Network Security Policy • Chapter 1 39
to access the information and services we provide for their use.You will find that the
time and funds spent in the design process and preparation for the implementation
are very good investments if the process is focused and effective; this will lead to a
high level of success and a good level of protection for the network you are pro-
tecting. In this section of the chapter, we explore the fundamentals of the design
process. We incorporate the information we discussed in relation to security and
traffic flow to make decisions about how our initial design should look. Additionally,
we’ll build on that information and review some other areas of concern that could
affect the way we design our DMZ structure.
NOTE
In this section, we look at design of a DMZ from a logical point of view.
Physical design and configuration are covered in following chapters,
based on the vendor-based solution you are interested in deploying.
Why Design Is So Important
Design of the DMZ is critically important to the overall protection of your internal
network—and the success of your firewall and DMZ deployment.The DMZ design
can incorporate sections that isolate incoming VPN traffic, Web traffic, partner con-
nections, employee connections, and public access to information provided by your
organization. Design of the DMZ structure throughout the organization can protect
internal resources from internal attack. As discussed in the security section, much of
the risk of data loss, corruption, and breach exists inside the network perimeter. Our
tendency is to protect assets from external harm but to disregard the dangers that
come from our own internal equipment, policies, and employees.
These attacks or disruptions do not arise solely from disgruntled employees.
Many of the most damaging conditions occur because of inadvertent mistakes made
by well-intentioned employees. Each and all of these entry points is a potential
source of loss for your organization and ultimately can provide an attack point to
defeat your other defenses. Additionally, the design of your DMZ will allow you to
implement a multilayered approach to securing your resources that does not leave a
single point of failure in your plan.This minimizes the problems and loss of protec-
tion that can occur because of misconfiguration of rule sets or access control lists
(ACLs), and reduces the problems that can occur due to hardware configuration
errors. In the last chapters of this book, we look at how to mitigate risk through
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 40
40 Chapter 1 • Network Security Policy
testing of your network infrastructure to make sure your firewalls, routers, switches,
and hosts are thoroughly hardened so that when you do deploy your DMZ segment,
it is secure from both internal and external threats.
Designing End-to-End Security for Data
Transmission between Hosts on the Network
Proper DMZ design, in conjunction with the security policy and plan developed
previously, allows for end-to-end protection of the information being transmitted on
the network.The importance of this capability is explored more fully later in the
chapter, when we review some of the security problems inherent in the current
implementation of TCP/IPv4 and the transmission of data.The use of one or more
of the many firewall products or appliances currently available will most often afford
the opportunity to block or filter specific protocols and protect the data as it is being
transmitted.This protection may take the form of encryption and can use the avail-
able transports to protect data as well. Additionally, proper use of the technologies
available within this design can provide for the necessary functions previously
detailed in the concepts of AAA and CIA, using the multilayer approach to protec-
tion we discussed in earlier sections.This need to provide end-to-end security
requires that we are conversant with and remember basic network traffic patterns
and protocols.The next few sections further illustrate the need to design the DMZ
with this capability in mind.
Traffic Flow and Protocol Fundamentals
Another of the benefits of using a DMZ design that includes one or more firewalls
is the opportunity to control traffic flow into and out of the DMZ much more
cohesively and with much more granularity and flexibility. When the firewall
product in use (either hardware or software) is a product designed above the home-
use level, the capability usually exists to control traffic flowing in and out of the net-
work or DMZ through packet filtering based on port numbers, and allow or deny
the use of entire protocols. For instance, the rule set might include a statement that
blocks communication via ICMP, which would block protocol 1. A statement that
allowed IPSec traffic where it was desired to allow traffic using ESP or AH would be
written allowing protocol 50 for ESP or 51 for Authentication Header (AH). (For a
listing of the protocol IDs, visit www.iana.org/assignments/protocol-numbers.)
Remember that like the rule of security that follows the principle of least privilege,
we must include in our design the capability to allow only necessary traffic into and
out of the various portions of the DMZ structure.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 41
Network Security Policy • Chapter 1 41
Making Your Security Come Together
In today’s security battlefield, it almost seems impossible to win.You must identify
the best products and procedures for your organization. If you have all of the sug-
gested security solutions, but not enough staff to manage them, the solutions may
not be effective enough. Simply having the appropriate products is not going to
resolve all of your problems; you must effectively understand how to use and con-
figure the products.There is no easy solution regarding the best way to go about
securing your organization.This is why companies all over the world spend hun-
dreds of millions of dollars on consulting companies to come in and make security
decisions for them.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 42
42 Chapter 1 • Network Security Policy
Summary
We’ve covered a lot of ground in this chapter because your network infrastructure is
literally and figuratively the backbone of your network. Creating a network security
policy touches every aspect of your network, and a thorough assessment will take
time and careful effort to complete so your network is as secure as it can reasonably
be, given the organizational constraints and considerations you’ll have to deal with.
It’s often helpful to break the network infrastructure down into its systems or areas
to help ensure that you cover all the areas, including devices and media, topology,
intrusion detection and prevention, system hardening, and all the network compo-
nents such as routers, switches, and modems. Once you’ve identified all the areas,
you need to take a top-to-bottom look at how security is currently implemented
and what threats exist. By looking at issues such as information criticality and per-
forming an impact analysis, you can decide what should be included in your project
and what can reasonably be left out or delayed for a later phase if needed.
Understanding the threat environment and your network’s vulnerabilities is also
important during your planning phase.
Requirements need to be thoroughly developed because they form the founda-
tion of your project’s scope. Functional requirements should be developed first, fol-
lowed by technical, legal, and policy requirements. Be sure to build these into your
task details when you create your WBS so that all required elements will be present
and accounted for in your project plan.
In an infrastructure security project, you’ll need a wide variety of skills that span
the depth and breadth of networking knowledge. Be sure you define those skills so
you can assess your team and your organization to identify skills gaps.These will
have to be addressed before your project can proceed, and often requires hiring out-
side contractors or providing training for internal staff members. Either way, this can
affect both your budget and your schedule, so be sure you do a gap analysis between
needed and available skills prior to proceeding with your project.
The WBS defines the scope of your project, so once you’ve identified all the
work through delineating the tasks, be sure to do a scope check. If the defined scope
is smaller than the scope outlined in your WBS, you need to reconcile the differ-
ences. Also, be sure to discuss any scope changes with your project sponsor so you
start with the same expectations about project results.
Scheduling an infrastructure security project can be challenging due to all the
moving parts involved.You’ll run into scheduling conflicts, resource usage conflicts,
timing issues, and more.These should be resolved to the greatest degree possible
before starting the project, because things will only get more complicated and diffi-
cult to resolve once project work is underway. One important scheduling note is that
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 43
Network Security Policy • Chapter 1 43
with all areas of your network being poked and prodded, you’ll need to make sure
subproject teams are not working at cross-purposes and undoing work just done or
inadvertently injecting false indicators into the process through their own task work.
When it’s all said and done, you should be able to define, implement, and
manage a very useful network security policy if you follow a consistent method-
ology and make teamwork and quality topmost priorities.This is the foundation of
all other security projects; it touches on everything in your organization, so success
here will create the framework for a very secure network that will help you sleep at
night, knowing you’ve done everything possible to keep your organization’s assets
secure.
Solutions Fast Track
Defining Your Organization
■ You need to understand your organization’s business and business processes
before you can craft a network security policy.
■ Consider the IT needs and characteristics of different areas within your
company; e.g., your application developers may have differing security
requirements than members of your Human Resources area.
■ Be aware of any legal or regulatory requirements that your company needs
to comply with, such as compliance measures like SOX or HIPPAA.
Trusted Networks
■ As much as possible, you should define the difference between trusted and
untrusted networks in your environment; i.e., those networks that can safely
transmit sensitive data versus those that are at risk by internal or external
attackers.
■ The increased availability of home-based high-speed Internet access and
wireless hotspots has made it much more difficult to create a line of
demarcation between trusted and untrusted networks.
■ Even on trusted networks, your network security policy should dictate the
protection measures that should be put in place to protect your data as it
traverses the network.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 44
44 Chapter 1 • Network Security Policy
Untrusted Networks
■ Any time your data traverses a network where it is at risk of being
intercepted or manipulated by a malicious user, you need to outline the
steps that will minimize the risk of this occurring.
■ Whenever possible, business data should not be transmitted over an
untrusted network in a clear-text or other easily readable format.
■ Technologies such as Network Quarantine and Federation Services will
make an increasingly large impact on your ability to secure your network as
the line between trusted and untrusted networks continues to blur.
Frequently Asked Questions
The following Frequently Asked Questions, answered by the authors of this book,
are designed to both measure your understanding of the concepts presented in
this chapter and to assist you with real-life implementation of these concepts. To
have your questions about this chapter answered by the author, browse to
www.syngress.com/solutions and click on the “Ask the Author” form.
Q. I’ve already configured a perimeter firewall and numerous other resources for my
company, aren’t we already secure?
A. The only way to make a computer or network completely secure is to never ever
connect it to a network or plug in a floppy or USB drive. (Dropping it over-
board in the middle of the ocean helps as well.) In the modern computing envi-
ronment, the phrase that pays is “defense in depth”—configuring multiple layers
of security (within the limits of budgets and reason) so that if one layer fails,
another layer will be present to secure your resources.
Q. How can I determine which resources on my network should receive priority
when crafting our security policy?
A. In a perfect world, you would have an unlimited budget to deploy perfect secu-
rity for all aspects of your network. In reality, you only have so much money to
spend—and it’s usually not worth spending more on securing an asset than that
asset is worth. In many ways, this decision is not a technical one, but must be
made in conjunction with data owners and decision-makers in your organization
to determine which resources need to be given priority in a finite budget.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 45
Network Security Policy • Chapter 1 45
Q. What is the difference between a policy and a procedure?
A. Your network security policy should be a high-level document that can with-
stand changes in technology without needing constant revision. In addition to
your security policy, you can specify a number of procedures that detail how to
secure specific technologies or products; these procedures are much more tech-
nical in nature and can be updated as the technology they refer to changes. In
other words, your network security policy should specify the “What,” “When,”
“Where,” and “Who,” while your procedures can focus more on the specifics of
“How.”
Q. How do I respond to the CEO or other VP who insists that he or she should be
exempt from all security restrictions?
A. This is a delicate political needle to thread, but you are doing a disservice to
your organization if you do not at least make the attempt. For example, you
might point out that a network virus will do the same amount of damage
regardless of whether it originated from a secretary’s computer or the CEO’s
laptop. It’s the “weakest link” adage in action—if a certain segment of your net-
work is left unsecured, it can potentially reduce the security of the entire net-
work.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 46
398_FW_Policy_02.qxd 8/25/06 6:26 PM Page 47
Chapter 2
Using Your
Policies to Create
Firewall and VPN
Configurations
Topics in this chapter:
■ Logical Security Configurations
■ Profiling Network Assets
■ Users and User Groups
■ Security Areas
■ Security Area Risk Ratings
■ Writing Firewall and
VPN Logical Security Configurations
Summary
Solutions Fast Track
Frequently Asked Questions
47
398_FW_Policy_02.qxd 8/25/06 6:26 PM Page 48
48 Chapter 2 • Using Your Policies to Create Firewall and VPN Configurations
Introduction
As we learned in the previous chapter, securing your network starts with creating
various security policies that articulate the rules, requirements, standards, and recom-
mendations specific to your environment. As our businesses depend more and more
on networks and the resources they provide, it is increasingly important that we pro-
tect these resources from unauthorized access, attacks, and exploits against vulnerabil-
ities. As security professionals, our success is not dependant on fixing these inherent
and ongoing problems, but relies on our abilities to select, implement, and configure
solutions that protect our resources.The threats, attacks, and abuse will always be
present as long as we have networks and provide services on those networks. It all
starts with written security polices, which are our roadmaps—and the single most
important documents you can have. Whether it is an Acceptable Use Policy, Remote
User VPN Policy, or the Perimeter Access Policy, each will have a long-term impact
on the security of your network.
Unfortunately, security policies are afterthoughts in many companies. It is not
uncommon to find companies that have selected a security product, vendor, or even
a complete security solution without ever writing a security policy. As a result, the
security posture of these networks is ineffective in many respects.Their configura-
tions and rules probably do not reflect the requirements or desires of the organiza-
tion. In other situations in which security policies are not an afterthought, it is
common to find that those policies are outdated and probably had little or no
impact on the product selection or configurations of their security solutions.The
most successful organizations with respect to strong security have a commonality
between them—security policies.They review, update, and leverage best practice
security principals when selecting and configuring their security solutions.
Another area commonly overlooked is security policy sponsorship. As important
as developing the policies themselves, it is equally as important to get sponsorship for
their content and implementation.This helps drive and support the entire process
you will go through when creating, maintaining, and implementing your security
solutions. Many organizations spend the time, resources, and money to create secu-
rity policies, and fail to support them after their initial creation.Their failures are
usually not a result of their efforts or even part of the original plan. Many recom-
mendations and policies never get implemented or enforced long term because of
two key missing elements: sponsorship and acceptance.
Sponsorship is key because it provides the support by someone who has authori-
tative power in the organization to oversee your success.This entire process is largely
a team effort and without a sponsor, it will become challenging and often difficult to
complete all the steps necessary to develop and implement the organizational policies.
398_FW_Policy_02.qxd 8/25/06 6:26 PM Page 49
Using Your Policies to Create Firewall and VPN Configurations • Chapter 2 49
Equally important is the acceptance and understanding from the entire team on
the project goals and charter. While it might be impossible to always get 100 percent
from everyone on the team, everyone must agree to support the team decisions and
help enforce the policies.This is an area in which facilitation skills have a major
impact. Helping lead others to understand the positive impact the policies will have
on them personally will aid in their long-term support. If an individual or group of
people does not general accept or believe in the goals, why would they support
them? Finally, keep in mind that everyone on the team should have input and
understand his or her participation is critical to the success of the project.
This chapter discusses how to take your written security policies and convert
them into logical security configurations. Logical security configurations are used by
technical administrators to guide them through the implementation and configura-
tion of your firewall and VPN devices.You might be thinking that we have yet to
discuss a specific firewall or VPN appliance. Well, you are right! In fact, this is a mis-
take commonly made by security professionals when they go through this step. By
abstracting vendor-specific technology or features, you are able to think about the
goals of the policies versus writing policy around a vendor’s product.This step might
seem somewhat insignificant; however, it is a vital step that should not be overlooked
or skipped.The primary goal of this chapter is to create concise and clear objectives
that are specific to actual configurations of the firewall and VPN devices.
NOTE
It is important to understand these processes are not the end-all, be-all
of security policy development. They are guidelines and should be inter-
preted as such. In addition, it is easy to stray from the goals of this step,
which is to develop effective and clear running configurations for your
devices.
What Is a Logical
Security Configuration?
Once you have developed and received approval for your written security policies,
the next major step is to convert them into logical security configuration docu-
ments.You might ask, what is a logical security configuration and how is it different
from an actual configuration you will create for your firewall or VPN device? This is
30 Chapter 1 • Network Security Policy
■ Perform baseline network mapping and performance monitoring
■ Identify risk to resources and appropriate mitigation processes
■ Identify potential security threats, both external and internal
■ Identify needed access points from external sources
■ Public networks
■ VPN access
■ Extranets
■ Remote access services
■ Identify critical services
■ Plan your DMZ
Figure 1.1 A Basic Network with a Single Firewall
Untrusted
or
Internet
Router
Hardware
or
Software
Firewall
LAN
Figure 1.1 shows the basic configuration that would be used in a simple network sit-
uation in which there was no need to provide external services.This configuration
would typically be used to begin to protect a small business or home network. It
could also be used within an internal network to protect an inner network that had
to be divided and isolated from the main network.This situation could include
Payroll, Finance, or Development divisions that need to protect their information
and keep it away from general network use and view.
Figure 1.2 details a protection design that would allow for the implementation
and provision of services outside the protected network. In this design, it would be
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 31
Network Security Policy • Chapter 1 31
imperative that rules be enacted to not allow the untrusted host to access the
internal network. Security of the bastion host machine would be accomplished on
the machine itself, and only minimal and necessary services would be enabled or
installed on that machine. In this design, we might be providing a Web presence that
did not involve e-commerce or the necessity to dynamically update content.This
design would not be used for provision of virtual private network (VPN) connec-
tions, FTP services, or other services that required other content updates to be per-
formed regularly.
Figure 1.2 Basic Network, Single Firewall and Bastion Host (Untrusted Host)
Untrusted
or
Internet
Bastion Host (untrusted Host)
Firewall
Internal Network
Figure 1.3 shows a basic DMZ structure. In this design, the bastion host is partially
protected by the firewall. Rather than the full exposure that would result to the bas-
tion host in Figure 1.2, this setup would allow us to specify that the bastion host in
Figure 1.2 could be allowed full outbound connection, but the firewall could be
configured to allow only port 80 traffic inbound to the bastion host (assuming it was
a Web server) or others as necessary for connection from outside.This design would
allow connection from the internal network to the bastion host if necessary, and
potentially allow updating of Web server content from the internal network if
allowed by firewall rule, which could allow traffic to and from the bastion host on
specific ports as designated.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 32
32 Chapter 1 • Network Security Policy
Figure 1.3 A Basic Firewall with a DMZ
Untrusted
or
Internet
Bastion Host (untrusted Host) Firewall
Internal Network
Figure 1.4 shows a generic dual-firewall DMZ configuration. In this arrangement,
the bastion host can be protected from the outside and allowed to connect to or
from the internal network. In this arrangement, like the conditions in Figure 1.3,
flow can be controlled to and from both of the networks away from the DMZ.This
configuration and method is more likely to be used if more than one bastion host is
needed for the operations or services being provided.
Figure 1.4 A Dual Firewall with a DMZ
Untrusted
or
Internet
Outer Firewall
Bastion Host (untrusted Host)
Inner Firewall
Internal Network
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 33
Network Security Policy • Chapter 1 33
Traffic Flow Concepts
Now that we’ve had a quick tour of some generic designs, let’s look at the way net-
work communications traffic typically flows through them. Be sure to note the dif-
ferences between the levels and the flow of traffic and protections offered in each.
Figure 1.5 illustrates the flow pattern for information through a basic single-fire-
wall setup.This type of traffic control can be achieved through hardware or software
and is the basis for familiar products such as Internet Connection Sharing (ICS) and
the NAT functionality provided by digital subscriber line (DSL) and cable modems
used for connection to the Internet. Note that flow is unrestricted outbound, but
the basic configuration will drop all inbound connections that did not originate
from the internal network.
Figure 1.5 Basic Single-Firewall Flow
Untrusted
or
Internet
...Inbound
Traffic ...
Router
Hardware
Inbound stopped at or
FW unless allowed Software
by rule Firewall
LAN
--- Outbound Traffic --
Figure 1.6 reviews the traffic flow in a network containing a bastion host and a
single firewall.This network configuration does not produce a DMZ; the protection
of the bastion host is configured individually on the host and requires extreme care
in setup. Inbound traffic from the untrusted network or the bastion host is dropped
at the firewall, providing protection to the internal network. Outbound traffic from
the internal network is allowed.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 34
34 Chapter 1 • Network Security Policy
Figure 1.6 A Basic Firewall with Bastion Host Flow
Untrusted
or
Internet
Bastion Host (untrusted Host)
Firewall
Internal Network
Figure 1.7 shows the patterns of traffic as we implement a DMZ design. In this
form, inbound traffic flows through to the bastion host if allowed through the fire-
wall and is dropped if destined for the internal network.Two-way traffic is permitted
as specified between the internal network and the bastion host, and outbound traffic
from the internal network flows through the firewall and out, generally without
restriction.
Figure 1.7 A Basic Single Firewall with DMZ Flow
Untrusted
or
Internet
Firewall
Bastion Host (untrusted Host)
Internal Network
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 35
Network Security Policy • Chapter 1 35
Figure 1.8 contains a more complex path of flow for information, but provides the
most capability in these basic designs to allow for configuration and provision of ser-
vices to the outside. In this case, we have truly established a DMZ, separated and
protected from both the internal and external networks.This type of configuration is
used quite often when there is a need to provide more than one type of service to
the public or outside world, such as e-mail, Web servers, DNS, and so forth.Traffic
to the bastion host can be allowed or denied as necessary from both the external and
internal networks, and incoming traffic to the internal network can be dropped at
the external firewall. Outbound traffic from the internal network can be allowed or
restricted to the bastion host (DMZ network) or the external network.
Figure 1.8 A Dual Firewall with DMZ Flow
Untrusted
or
Internet
Outer Firewall
Bastion Host (untrusted Host)
Inner Firewall
Internal Network
As you can see, there is a great amount of flexibility in the design and function
of your protection mechanisms. In the sections that follow, we expand further on
conditions for the use of different configurations and on the planning to implement
them.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 36
36 Chapter 1 • Network Security Policy
Networks with and without DMZs
As we pursue our discussions about the creation of DMZ structures, it is appropriate
to also look at the reasoning behind the various structures of the DMZ, and when
and where we’d want to implement a DMZ or perhaps use some other alternative.
During our preview of the concepts of DMZs, we saw in Figures 1.5 to 1.8
some examples of potential design for network protection and access.Your design
may incorporate any or all of these types of configuration, depending on your orga-
nization’s needs. For instance, Figure 1.5 shows a configuration that may occur in the
case of a home network installation or perhaps with a small business environment
that is isolated from the Internet and does not share information or need to provide
services or information to outside customers or partners.This design would be suit-
able under these conditions, provided configuration is correct and monitored for
change.
Figure 1.6 illustrates a network design with a bastion host located outside the
firewall. In this design, the bastion host must be stripped of all unnecessary function-
ality and services and protected locally with appropriate file permissions and access
control mechanisms.This design would be used when an organization needs to pro-
vide minimal services to an external network, such as a Web server. Access to the
internal network from the bastion host is generally not allowed, because this host is
subject to compromise.
Figure 1.7 details the first of the actual DMZ designs and incorporates a
screened subnet. In this type of design, the firewall controls the flow of information
from network to network and provides more protection to the bastion host from
external flows.This design might be used when it is necessary to regularly update
the content of a Web server, or provide a front end for mail services or other ser-
vices that need contact from both the internal and external networks. Although
better for security purposes than Figure 1.6, this design still produces an untrusted
relationship in the bastion host in relation to the internal network.
Finally, Figure 1.8 provides a design that allows for the placement of many types
of service in the DMZ.Traffic can be very finely controlled through access at the
two firewalls, and services can be provided at multiple levels to both internal and
external networks.
In the next section, we profile some of the advantages and disadvantages of the
common approaches to DMZ architecture and provide a checklist of sorts to help
you to make a decision about the appropriate use (or not) of the DMZ for
protection.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 37
Network Security Policy • Chapter 1 37
Pros and Cons of DMZ Basic Designs
Table 1.6 details the advantages and disadvantages of the various types of basic design
discussed in the preceding section.
Table 1.6 Pros and Cons of Basic DMZ Designs
Basic Design Advantages Disadvantages Appropriate Use
Single firewall Inexpensive, fairly Much lower Home, small
easy configuration, security capabilities,office/home office
low maintenance no growth or (SOHO), small busi-
expansion potential ness without need to
provide services to
others
Single firewall Lower cost than Bastion host Small business
with bastion host more robust extremely vuln- without resources
alternatives erable to for more robust
compromise, implementation or
inconvenient to static content being
update content, provided that
loss of doesn’t require
functionality other frequent updates
than for required
services; not
scalable
Single firewall Firewall provides Single point of Networks requiring
with screened protection to both failure; some access to the bastion
subnet and internal network products limit host for updating
bastion host and bastion host, network addressing information
limiting some of to DMZ in this
the potential configuration to
breach possibilities public addresses,
of an unprotected which might not
bastion host be economic or
possible in your
network
Continued
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 38
38 Chapter 1 • Network Security Policy
Table 1.6 continued Pros and Cons of Basic DMZ Designs
Basic Design Advantages Disadvantages Appropriate Use
Dual firewall Allows for establish- Requires more Larger operations
with DMZ ment of multiple hardware and that require the
service-providing software for capability to offer
hosts in the DMZ; implementation of multiple types of
protects bastion this design; more Web access and
hosts in DMZ from configuration work services to both the
both networks, and monitoring internal and external
allows much more required networks involved
granular control
of resources and
access; removes
single point of
failure and attack
Configuring & Implementing…
Bastion Hosts
Bastion hosts must be individually secured and hardened because they are always
in a position that could be attacked or probed. This means that before place-
ment, a bastion host must be stripped of unnecessary services, fully updated with
the latest service packs, hot fixes, and updates, and isolated from other trusted
machines and networks to eliminate the possibility that its compromise would
allow connection to (and potential compromise of) the protected networks and
resources. This also means that a machine being used for this purpose should
have no user accounts relative to the protected network or directory services
structure, which could lead to enumeration of your internal network.
DMZ Design Fundamentals
DMZ design, like security design, is always a work in progress. As in security plan-
ning and analysis, we find DMZ design carries great flexibility and change potential
to keep the protection levels we put in place in an effective state.The ongoing work
is required so that the system’s security is always as high as we can make it within
the constraints of time and budget, while still allowing appropriate users and visitors
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 39
Network Security Policy • Chapter 1 39
to access the information and services we provide for their use.You will find that the
time and funds spent in the design process and preparation for the implementation
are very good investments if the process is focused and effective; this will lead to a
high level of success and a good level of protection for the network you are pro-
tecting. In this section of the chapter, we explore the fundamentals of the design
process. We incorporate the information we discussed in relation to security and
traffic flow to make decisions about how our initial design should look. Additionally,
we’ll build on that information and review some other areas of concern that could
affect the way we design our DMZ structure.
NOTE
In this section, we look at design of a DMZ from a logical point of view.
Physical design and configuration are covered in following chapters,
based on the vendor-based solution you are interested in deploying.
Why Design Is So Important
Design of the DMZ is critically important to the overall protection of your internal
network—and the success of your firewall and DMZ deployment.The DMZ design
can incorporate sections that isolate incoming VPN traffic, Web traffic, partner con-
nections, employee connections, and public access to information provided by your
organization. Design of the DMZ structure throughout the organization can protect
internal resources from internal attack. As discussed in the security section, much of
the risk of data loss, corruption, and breach exists inside the network perimeter. Our
tendency is to protect assets from external harm but to disregard the dangers that
come from our own internal equipment, policies, and employees.
These attacks or disruptions do not arise solely from disgruntled employees.
Many of the most damaging conditions occur because of inadvertent mistakes made
by well-intentioned employees. Each and all of these entry points is a potential
source of loss for your organization and ultimately can provide an attack point to
defeat your other defenses. Additionally, the design of your DMZ will allow you to
implement a multilayered approach to securing your resources that does not leave a
single point of failure in your plan.This minimizes the problems and loss of protec-
tion that can occur because of misconfiguration of rule sets or access control lists
(ACLs), and reduces the problems that can occur due to hardware configuration
errors. In the last chapters of this book, we look at how to mitigate risk through
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 40
40 Chapter 1 • Network Security Policy
testing of your network infrastructure to make sure your firewalls, routers, switches,
and hosts are thoroughly hardened so that when you do deploy your DMZ segment,
it is secure from both internal and external threats.
Designing End-to-End Security for Data
Transmission between Hosts on the Network
Proper DMZ design, in conjunction with the security policy and plan developed
previously, allows for end-to-end protection of the information being transmitted on
the network.The importance of this capability is explored more fully later in the
chapter, when we review some of the security problems inherent in the current
implementation of TCP/IPv4 and the transmission of data.The use of one or more
of the many firewall products or appliances currently available will most often afford
the opportunity to block or filter specific protocols and protect the data as it is being
transmitted.This protection may take the form of encryption and can use the avail-
able transports to protect data as well. Additionally, proper use of the technologies
available within this design can provide for the necessary functions previously
detailed in the concepts of AAA and CIA, using the multilayer approach to protec-
tion we discussed in earlier sections.This need to provide end-to-end security
requires that we are conversant with and remember basic network traffic patterns
and protocols.The next few sections further illustrate the need to design the DMZ
with this capability in mind.
Traffic Flow and Protocol Fundamentals
Another of the benefits of using a DMZ design that includes one or more firewalls
is the opportunity to control traffic flow into and out of the DMZ much more
cohesively and with much more granularity and flexibility. When the firewall
product in use (either hardware or software) is a product designed above the home-
use level, the capability usually exists to control traffic flowing in and out of the net-
work or DMZ through packet filtering based on port numbers, and allow or deny
the use of entire protocols. For instance, the rule set might include a statement that
blocks communication via ICMP, which would block protocol 1. A statement that
allowed IPSec traffic where it was desired to allow traffic using ESP or AH would be
written allowing protocol 50 for ESP or 51 for Authentication Header (AH). (For a
listing of the protocol IDs, visit www.iana.org/assignments/protocol-numbers.)
Remember that like the rule of security that follows the principle of least privilege,
we must include in our design the capability to allow only necessary traffic into and
out of the various portions of the DMZ structure.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 41
Network Security Policy • Chapter 1 41
Making Your Security Come Together
In today’s security battlefield, it almost seems impossible to win.You must identify
the best products and procedures for your organization. If you have all of the sug-
gested security solutions, but not enough staff to manage them, the solutions may
not be effective enough. Simply having the appropriate products is not going to
resolve all of your problems; you must effectively understand how to use and con-
figure the products.There is no easy solution regarding the best way to go about
securing your organization.This is why companies all over the world spend hun-
dreds of millions of dollars on consulting companies to come in and make security
decisions for them.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 42
42 Chapter 1 • Network Security Policy
Summary
We’ve covered a lot of ground in this chapter because your network infrastructure is
literally and figuratively the backbone of your network. Creating a network security
policy touches every aspect of your network, and a thorough assessment will take
time and careful effort to complete so your network is as secure as it can reasonably
be, given the organizational constraints and considerations you’ll have to deal with.
It’s often helpful to break the network infrastructure down into its systems or areas
to help ensure that you cover all the areas, including devices and media, topology,
intrusion detection and prevention, system hardening, and all the network compo-
nents such as routers, switches, and modems. Once you’ve identified all the areas,
you need to take a top-to-bottom look at how security is currently implemented
and what threats exist. By looking at issues such as information criticality and per-
forming an impact analysis, you can decide what should be included in your project
and what can reasonably be left out or delayed for a later phase if needed.
Understanding the threat environment and your network’s vulnerabilities is also
important during your planning phase.
Requirements need to be thoroughly developed because they form the founda-
tion of your project’s scope. Functional requirements should be developed first, fol-
lowed by technical, legal, and policy requirements. Be sure to build these into your
task details when you create your WBS so that all required elements will be present
and accounted for in your project plan.
In an infrastructure security project, you’ll need a wide variety of skills that span
the depth and breadth of networking knowledge. Be sure you define those skills so
you can assess your team and your organization to identify skills gaps.These will
have to be addressed before your project can proceed, and often requires hiring out-
side contractors or providing training for internal staff members. Either way, this can
affect both your budget and your schedule, so be sure you do a gap analysis between
needed and available skills prior to proceeding with your project.
The WBS defines the scope of your project, so once you’ve identified all the
work through delineating the tasks, be sure to do a scope check. If the defined scope
is smaller than the scope outlined in your WBS, you need to reconcile the differ-
ences. Also, be sure to discuss any scope changes with your project sponsor so you
start with the same expectations about project results.
Scheduling an infrastructure security project can be challenging due to all the
moving parts involved.You’ll run into scheduling conflicts, resource usage conflicts,
timing issues, and more.These should be resolved to the greatest degree possible
before starting the project, because things will only get more complicated and diffi-
cult to resolve once project work is underway. One important scheduling note is that
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 43
Network Security Policy • Chapter 1 43
with all areas of your network being poked and prodded, you’ll need to make sure
subproject teams are not working at cross-purposes and undoing work just done or
inadvertently injecting false indicators into the process through their own task work.
When it’s all said and done, you should be able to define, implement, and
manage a very useful network security policy if you follow a consistent method-
ology and make teamwork and quality topmost priorities.This is the foundation of
all other security projects; it touches on everything in your organization, so success
here will create the framework for a very secure network that will help you sleep at
night, knowing you’ve done everything possible to keep your organization’s assets
secure.
Solutions Fast Track
Defining Your Organization
■ You need to understand your organization’s business and business processes
before you can craft a network security policy.
■ Consider the IT needs and characteristics of different areas within your
company; e.g., your application developers may have differing security
requirements than members of your Human Resources area.
■ Be aware of any legal or regulatory requirements that your company needs
to comply with, such as compliance measures like SOX or HIPPAA.
Trusted Networks
■ As much as possible, you should define the difference between trusted and
untrusted networks in your environment; i.e., those networks that can safely
transmit sensitive data versus those that are at risk by internal or external
attackers.
■ The increased availability of home-based high-speed Internet access and
wireless hotspots has made it much more difficult to create a line of
demarcation between trusted and untrusted networks.
■ Even on trusted networks, your network security policy should dictate the
protection measures that should be put in place to protect your data as it
traverses the network.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 44
44 Chapter 1 • Network Security Policy
Untrusted Networks
■ Any time your data traverses a network where it is at risk of being
intercepted or manipulated by a malicious user, you need to outline the
steps that will minimize the risk of this occurring.
■ Whenever possible, business data should not be transmitted over an
untrusted network in a clear-text or other easily readable format.
■ Technologies such as Network Quarantine and Federation Services will
make an increasingly large impact on your ability to secure your network as
the line between trusted and untrusted networks continues to blur.
Frequently Asked Questions
The following Frequently Asked Questions, answered by the authors of this book,
are designed to both measure your understanding of the concepts presented in
this chapter and to assist you with real-life implementation of these concepts. To
have your questions about this chapter answered by the author, browse to
www.syngress.com/solutions and click on the “Ask the Author” form.
Q. I’ve already configured a perimeter firewall and numerous other resources for my
company, aren’t we already secure?
A. The only way to make a computer or network completely secure is to never ever
connect it to a network or plug in a floppy or USB drive. (Dropping it over-
board in the middle of the ocean helps as well.) In the modern computing envi-
ronment, the phrase that pays is “defense in depth”—configuring multiple layers
of security (within the limits of budgets and reason) so that if one layer fails,
another layer will be present to secure your resources.
Q. How can I determine which resources on my network should receive priority
when crafting our security policy?
A. In a perfect world, you would have an unlimited budget to deploy perfect secu-
rity for all aspects of your network. In reality, you only have so much money to
spend—and it’s usually not worth spending more on securing an asset than that
asset is worth. In many ways, this decision is not a technical one, but must be
made in conjunction with data owners and decision-makers in your organization
to determine which resources need to be given priority in a finite budget.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 45
Network Security Policy • Chapter 1 45
Q. What is the difference between a policy and a procedure?
A. Your network security policy should be a high-level document that can with-
stand changes in technology without needing constant revision. In addition to
your security policy, you can specify a number of procedures that detail how to
secure specific technologies or products; these procedures are much more tech-
nical in nature and can be updated as the technology they refer to changes. In
other words, your network security policy should specify the “What,” “When,”
“Where,” and “Who,” while your procedures can focus more on the specifics of
“How.”
Q. How do I respond to the CEO or other VP who insists that he or she should be
exempt from all security restrictions?
A. This is a delicate political needle to thread, but you are doing a disservice to
your organization if you do not at least make the attempt. For example, you
might point out that a network virus will do the same amount of damage
regardless of whether it originated from a secretary’s computer or the CEO’s
laptop. It’s the “weakest link” adage in action—if a certain segment of your net-
work is left unsecured, it can potentially reduce the security of the entire net-
work.
398_FW_Policy_01.qxd 8/25/06 10:52 AM Page 46
398_FW_Policy_02.qxd 8/25/06 6:26 PM Page 47
Chapter 2
Using Your
Policies to Create
Firewall and VPN
Configurations
Topics in this chapter:
■ Logical Security Configurations
■ Profiling Network Assets
■ Users and User Groups
■ Security Areas
■ Security Area Risk Ratings
■ Writing Firewall and
VPN Logical Security Configurations
Summary
Solutions Fast Track
Frequently Asked Questions
47
398_FW_Policy_02.qxd 8/25/06 6:26 PM Page 48
48 Chapter 2 • Using Your Policies to Create Firewall and VPN Configurations
Introduction
As we learned in the previous chapter, securing your network starts with creating
various security policies that articulate the rules, requirements, standards, and recom-
mendations specific to your environment. As our businesses depend more and more
on networks and the resources they provide, it is increasingly important that we pro-
tect these resources from unauthorized access, attacks, and exploits against vulnerabil-
ities. As security professionals, our success is not dependant on fixing these inherent
and ongoing problems, but relies on our abilities to select, implement, and configure
solutions that protect our resources.The threats, attacks, and abuse will always be
present as long as we have networks and provide services on those networks. It all
starts with written security polices, which are our roadmaps—and the single most
important documents you can have. Whether it is an Acceptable Use Policy, Remote
User VPN Policy, or the Perimeter Access Policy, each will have a long-term impact
on the security of your network.
Unfortunately, security policies are afterthoughts in many companies. It is not
uncommon to find companies that have selected a security product, vendor, or even
a complete security solution without ever writing a security policy. As a result, the
security posture of these networks is ineffective in many respects.Their configura-
tions and rules probably do not reflect the requirements or desires of the organiza-
tion. In other situations in which security policies are not an afterthought, it is
common to find that those policies are outdated and probably had little or no
impact on the product selection or configurations of their security solutions.The
most successful organizations with respect to strong security have a commonality
between them—security policies.They review, update, and leverage best practice
security principals when selecting and configuring their security solutions.
Another area commonly overlooked is security policy sponsorship. As important
as developing the policies themselves, it is equally as important to get sponsorship for
their content and implementation.This helps drive and support the entire process
you will go through when creating, maintaining, and implementing your security
solutions. Many organizations spend the time, resources, and money to create secu-
rity policies, and fail to support them after their initial creation.Their failures are
usually not a result of their efforts or even part of the original plan. Many recom-
mendations and policies never get implemented or enforced long term because of
two key missing elements: sponsorship and acceptance.
Sponsorship is key because it provides the support by someone who has authori-
tative power in the organization to oversee your success.This entire process is largely
a team effort and without a sponsor, it will become challenging and often difficult to
complete all the steps necessary to develop and implement the organizational policies.
398_FW_Policy_02.qxd 8/25/06 6:26 PM Page 49
Using Your Policies to Create Firewall and VPN Configurations • Chapter 2 49
Equally important is the acceptance and understanding from the entire team on
the project goals and charter. While it might be impossible to always get 100 percent
from everyone on the team, everyone must agree to support the team decisions and
help enforce the policies.This is an area in which facilitation skills have a major
impact. Helping lead others to understand the positive impact the policies will have
on them personally will aid in their long-term support. If an individual or group of
people does not general accept or believe in the goals, why would they support
them? Finally, keep in mind that everyone on the team should have input and
understand his or her participation is critical to the success of the project.
This chapter discusses how to take your written security policies and convert
them into logical security configurations. Logical security configurations are used by
technical administrators to guide them through the implementation and configura-
tion of your firewall and VPN devices.You might be thinking that we have yet to
discuss a specific firewall or VPN appliance. Well, you are right! In fact, this is a mis-
take commonly made by security professionals when they go through this step. By
abstracting vendor-specific technology or features, you are able to think about the
goals of the policies versus writing policy around a vendor’s product.This step might
seem somewhat insignificant; however, it is a vital step that should not be overlooked
or skipped.The primary goal of this chapter is to create concise and clear objectives
that are specific to actual configurations of the firewall and VPN devices.
NOTE
It is important to understand these processes are not the end-all, be-all
of security policy development. They are guidelines and should be inter-
preted as such. In addition, it is easy to stray from the goals of this step,
which is to develop effective and clear running configurations for your
devices.
What Is a Logical
Security Configuration?
Once you have developed and received approval for your written security policies,
the next major step is to convert them into logical security configuration docu-
ments.You might ask, what is a logical security configuration and how is it different
from an actual configuration you will create for your firewall or VPN device? This is