ments and define configuration requirements for a specific type of enforcement device, like a firewall or VPN products. Based on standard capabilities of these var- ious devices, these documents will be used to build device-specific configurations that ultimately enforce your policy requirements.
For example, a firewall device provides access control between different networks to which it connects. At a basic level, they will provide these controls from Layer 3 and layer headers, which include source IP, destination IP, source port, and destina- tion port. Even though you might select two different firewall devices for your net- work, this information will be important as the administrator configures the device.
Keep in mind that we are not discussing or using actual features found in a specific vendor’s product or solution offerings. Instead, we are creating a logical configura- tion that will map our written security policy to the common capabilities of these devices.
While there is not a definitive correlation of logical configurations to written policies or logical configurations to specific devices, it is important that you create documents that can be easy to maintain and have focus. As a result, we recommend creating logical configurations for each group or type of devices you will be using in your environment. For our example, Example Corporation, we have created the fol- lowing five categories and will create a logical configuration for each of these groups.
■ Firewalls
■ VPN
■ Workstations
■ Servers
■ Routers
Once our logical configurations are complete, we should have a series of docu- ments that accurately represent the rules, policies, configurations, and procedures that will be configured on the specific firewall and VPN devices in your organization.
Planning Your Logical Security Configuration
Now we are ready to start the planning phase of our logical configuration process. It is recommended you complete the following four steps before starting the actual writing of your logical security configuration documents.
50 Chapter 2 • Using Your Policies to Create Firewall and VPN Configurations
1. Identifying network assets.
2. Profiling your network assets.
3. Creating security areas.
4. Assigning network assets to security areas.
Keep in mind, once you capture some of this information, it can be leveraged in each of the logical configuration documents we identified in the previous step.
Identifying Network Assets
One of the first steps is to identify the network assets we are trying to protect and provide secure access to or from. It is important to understand what devices and ser- vices are on the networks you are protecting.The more information you capture about your assets, the more informed you will be when you have to make decisions.
This information will be useful when you create your logical security policies and for ongoing management and auditing of your systems and configurations.
Since you will be collecting a lot of information, we highly recommend you take some time before starting this process to determine what method or system you can use to help organize this information. While outside the context of this book, it is common for customers to use a network inventory system and other network scanning tools to locate and profile each device. Open source projects like Open Computer and Software Inventory Next Generation (OCSng—
http://ocsinventory.sourceforge.net/) and NMap (http://insecure.org/nmap/) are two places to start. Even though we recommend long-term using network inventory solutions like these, it is not required to continue. A simple spreadsheet like the fol- lowing (see Table 2.1) can also be used.
Table 2.1Example Corporation
Device Location POC Notes
Web server Corporate HQ Joe Smith Public Web server Mail server Corporate HQ Joe Smith Public Mail server Exchange server Corporate HQ Joe Smith Internal Exchange
server
Web server Corporate HQ Joe Smith Internal Web server File server Corporate HQ Joe Smith Internal File/CIFS
server
Continued
Table 2.1 continued Example Corporation
Device Location POC Notes
Domain server Corporate HQ Joe Smith Domain controller, DHCP, P-DNS Domain server Corporate HQ Joe Smith BDC, S-DNS User network Corporate HQ Bob Green All corporate
workstations IT network Corporate HQ Bob Green All IT workstations Conference Corporate HQ Bob Green All conference rooms
network Internet router Corporate HQ Bob Green Internet router
NOTE
Remember, at this point you are identifying assets and not their com- plete configurations or services. In the next step, Profiling Your Network Assets, you will capture the configurations of each of these devices. In addition, we are not covering the switching and routing infrastructure devices and their security aspects. A common best practice is to limit their remote access and centralize their authentication and logging.
Profiling Your Network Assets
In this step, you will profile each of the network assets you identified in the identifi- cation step in the previous section.The network asset profile is a report on the var- ious attributes that are important to you and your organization.
First, we need to determine what information we are going to collect about our network assets. It is recommended you identify as much information as possible and clearly mark which attributes are required and which are optional. For our example, we are going to use the following attributes for Example Corporation (see Table 2.2 and Table 2.3):
52 Chapter 2 • Using Your Policies to Create Firewall and VPN Configurations
Table 2.2Attributes for Example Corporation Device Name:
Device Type:
IP Address:
DNS Name:
Physical Location:
Services:
Access Requirements:
Table 2.3 Defined Attributes for Example Corporation
Device Name: Web server
Device Type: Server, Red Hat Enterprise Server 3.0
IP Address: 10.1.1.10
DNS Name: webserver1.example.com
Physical Location: Server farm
Services: Apache, SSH, mySQL
Access Requirements: Internet hosts, internal employees
For each of your network assets, you should collect similar information and record it in your asset management system or in a spreadsheet similar to the pre- ceding template. While the device administrator might be able to provide it for you, it is recommended you verify the information yourself and use various security tools to verify which services are available.
NOTE
Profiling your assets is an important process and one that is often done with the aid of tools and management systems.
As you plan and implement your written security policies, understanding and using a concept of “security areas” will be very beneficial.They will have impact from the beginning network architecture and design phases through the ongoing, daily man- agement and maintenance of your security systems. In this section, we discuss what
security areas are and how they will be used as you design your logical security con- figurations of your firewall and VPN solutions.
What Are Security Areas?
Security areas are logical and sometimes physical groupings of network assets and resources that share a common set of security attributes. At first you might ask, what is the difference between security areas and VLANs? Don’t VLANs create a separate logical and physical separation between systems? The quick answer is yes and yes.
While different in many ways, VLANs and security areas are commonly used with one another but don’t have to be per se. Based on the requirements of a given security area, a network administrator might create a VLAN that will be used by the systems that are assigned to a security area or not.The main difference is, security areas are created by analyzing and grouping devices together based on the security attributes and not just on the physical separation. For example, what if your written security policy states that all hosts that belong to a “special group” are allowed to talk to one another but are required to pass through a firewall access policy first? Just defining a VLAN will not allow us to enforce our policy when these hosts commu- nicate with one another. Using the concept of security area provides an abstraction that will help ensure our written policy can be enforced and ultimately help us in our actual design and configurations.
Implied Security Areas
If you are like many security professionals today, early in our careers we were intro- duced to implied security areas when we were asked to help protect our networks from the Internet.The Internet connections were assigned to an implied interface known as “untrusted,” while our networks connected to an interface known as
“trusted.”These are two examples of implied security areas. Another example is the now famous “DMZ.” As pictured in Figure 2.1, an interface called the DMZ inter- face of the firewall connects to a network that provides DNS, mail and Web services for our example company. Based on the fact that these devices provide public ser- vices and are likely to be targets for attacks, we separate them from other hosts based on best security practices.
54 Chapter 2 • Using Your Policies to Create Firewall and VPN Configurations
Figure 2.1Legacy and common DMZ architecture
While much focus is put on protecting our “perimeters” from the Internet, it is not the only area that needs to be protected. It is now common security practice to view internal, traditional “trusted” networks and resources as important as pro- tecting our perimeters.
The real question behind the implied groups like “trusted” and “untrusted” is what defines and constitutes these groupings? In our opinion, this is a great question and one that could be the basis for a very long discussion. In fact, as you probably know, many firewall vendors hard-code these implied areas and assign them to default physical interfaces. Since firewalls originally were designed to protect our company resources from the Internet, it was easier to have these defaults versus introducing a more complex concept like security areas. While it is still very common to see and use these implied security areas, it is not as simple as just assigning your resources to one of these groups.
The real reason to create security areas is not because of physical groupings. It is because it allows us to understand the inter- and intra-relationships between the devices that are part of a security area. For example, it is very common to have a written security policy that requires traffic traversing between security areas be inspected for violation of a specific access policy. Based on this requirement, we must implement some access control and logging for all traffic between these two areas.
This point of inspection is known as an enforcement point (see Figure 2.2).
Figure 2.2Logical Enforcement Point Diagram
Enforcement Points
Now that we have created an abstraction between security areas and enforcement points, it is easy to convert written security policies to logical security configurations that are not limited by feature or functionality of a device. In fact, this process becomes invaluable later as we use this information to help us select the right type of device to implement between our security areas. In our previous example, our enforcement point is the intersection between our two security areas. An important point is that an enforcement point does not just imply using a firewall to apply a policy to the traffic. It allows us to understand the security requirements at a specific point in our network, which might mean using a product, products, and or features of a product to enforce our written security requirements.
Creating Security Areas
In this step, we will create security areas that are specific to your network. Before we start, however, we need to define the attributes we will use.
Security Area Attributes
Before creating your security areas, we recommend you write down and agree to a set of attributes that are important to your organization. While there is not a clearly defined group of attributes to use, some common ones include:
56 Chapter 2 • Using Your Policies to Create Firewall and VPN Configurations
■ Access rights
■ Services offered
■ Risk profile
For our discussion, we are going to use three attributes: access rights, services, and risk.
NOTE
While we are going to use these attributes, you can use your own, based on your specific environment. For example, the Federal Government has developed strict guidelines that are used to classify systems, their ser- vices, and their users.
Access rights define who and what needs access to use a resource or series of resources on an end device, such as a server. It is common for a single server to host multiple services.
In our network example, we have three servers that provide Internet-based ser- vices to the world.These services include mail, Web, and name services. Each of our servers is dedicated to one of these functions. Since all of these servers provide public services, they all require access to and from the Internet. For security pur- poses, we have decided to separate these servers onto a dedicated network and assign them to the DMZ-Server1 security area.
Assigning Network Assets to Security Areas
Now that we have created our security areas, we will need to assign our network assets to one of these areas.This step is pretty simple and straightforward. For each of our network assets, assign them to one of your security areas. Here is our example for Example Corporation (see Table 2.4):
Table 2.4Assignment of Network Assets to Security Areas
Network Asset Security Area
Web server DMZ-1
Mail server DMZ-1
DNS server DMZ-1
Continued
Table 2.4 continuedAssignment of Network Assets to Security Areas
Network Asset Security Area
Exchange server Internal-IT
Web server Internal-IT
File server Internal-IT
Domain server Internal-IT
Domain server Internal-IT
User network User-Network
IT network IT-Network
Conference network Conference-Network
Internet Untrusted
Security Area Risk Rating
An optional set we like to use and recommend is to assign a risk rating to each of your security areas. While not necessary, risk ratings are a subjective numerical rating that you assign to each particular security area.The main reason to assign this rating is to help understand the risk level between areas, and how access rights between those areas might apply. Risk ratings typically correlate to attributes like:
■ Access and availability
■ Public
■ Private
■ Data sensitivity
■ Critical, high sensitivity
■ Sensitive
■ Low, informational
■ Security and encryption
■ Encrypted
■ Clear
An example to discuss is the DMZ security area, where many companies place their Internet services and servers.The DMZ is a common location for those com- panies that host their own Web, mail, and DNS services. Access to these services is
58 Chapter 2 • Using Your Policies to Create Firewall and VPN Configurations
general not authenticated or encrypted, and the trust of the client systems is very low.Taking these attributes in consideration, most companies will not allow access to more secure areas, such as their intranet, from this security zone.
While there are not specific rules for assigning risk ratings, it is common to find customers using a 1 through 10 scale. In our example, 1 represents high risk and 10 represents low risk.This might sound counterintuitive at first; however, it allows an easy understanding for assigning access rights based on security areas. For example, a risk rating has access rights to any security area with a risk rating equal to or below its own.
Table 2.5 is an example chart illustrating security risk ratings.
Table 2.5 Example Chart Illustrating Security Risk Ratings Security Area Name Risk Rating Notes
DMZ-1 2 Internet services
VPN Network 4 VPN segment
User-Network 5 User workstations
IT-Network 4 File servers, network services
Conference-Network 1 Untrusted hosts, guest access
Untrusted 1 Internet router, firewall
Users and User Groups
Your firewall and VPN devices both might use users and user groups in their config- urations and policies. While most firewalls use location, such as source IP and or des- tination IP for their access control, VPN solutions typically grant access based on the user or user group to which an individual is assigned. In both cases, however, it is important to understand who your users are, where they access resources from, and when they will be accessing these resources.
We could dedicate a whole chapter, if not a whole book, on secure and effective user management. Since we can’t, we will have to assume our firewalls and VPNs will leverage an existing user management infrastructure. Examples include Microsoft Windows Active Directory, Kerberos, and Radius. While each has strengths and weaknesses from a technical standpoint, they all are designed to provide a centralized user management system to various client systems. We recommend leveraging one of these solutions versus using a built-in authentication service you will find in the var- ious firewall and VPN products. When building our logical security configurations
for our firewall and VPN solutions, we will need to reference and use information about our user community.
Examples of user groups include:
■ Corporate employees
■ Remote corporate employees
■ Corporate temporary employees
■ Remote temporary employees
■ Human resources
■ Executive staff
■ Executive administration
■ IT management
■ IT engineering
■ IT help desk