Thinking in Zones

"-->

Zoning is a process that is essential for making any security decision. Briefly, zoning is the process by which we define and isolate different subjects and objects based on their unique security requirements. Again, I use the standard terms "subjects" and "objects" because we could really be talking about anything. Zoning is most commonly thought of as a network-based solution, but truly, the concept of zoning is fundamental to all security decisions. A store pharmacy could, for instance, be classified into three zones, or three separate places where security is treated in a different manner. There is the front counter, where the customer requests the drugs and provides payment; there is the technician, who relays the request to the lab in back and returns with the drugs; and then there is the actual pharmacist, who fills prescriptions. Each of these areas has its own unique risks, vulnerabilities, and security needs that define its zones. Imagine if we simply let the customers directly into the back room to fill their own prescriptions!

In this section, we will discuss several different zoning scenarios that are possible and the advantages each has to offer. We will then work to apply the zoning process by defining subjects and objects and determining which zoning scenario fits best. Almost every security decision, technical or non-technical, involves zones, so while going through each zoning scenario, be sure to keep an open mind for how these concepts can be applied. Remember that zoning is not a network-specific concept, and that zones should be created for applications, physical areas, and even for employee interactions as a defense against social engineering.

Defining a Zone

The term "security zone" is thrown around a lot in the security world; it is used for everything from application design to security camera placement. So, how do we define a zone?

A zone is a logical grouping of resources that have a similar security profile. That is to say, it is a grouping of objects that have similar risks, trust levels, exposures, policies, or security needs. A client's computers connecting from across the Internet, for example, have a different level of security and trust than an internal DB server. Similarly, a local mail server that accepts mail directly from the Internet has a different level of exposure than an internal mail server. Thus, the two would be considered to be in two different zones.

Though there can be numerous zones within any situation, the most common scenarios involve the three zones shown in Table 5.1 the trusted (or internal) zone, the untrusted (or external) zone, and the semi-trusted zone (or DMZ). These three zones can apply to almost anything, including networking and application programming, as well as designing physical security layouts.

Table 5.1. Zone Definitions

Zone	Description	Examples
Trusted	The trusted zone is where the organization's most valuable and sensitive resources exist. This zone is under our control and governed by our policies.	Network: Internal servers and workstations Application: Trusted pieces of application code Physical: Server rooms
Semi-Trusted	The semi-trusted zone (or DMZ) is for resources that have some degree of direct exposure. This zone is still under our control and governed by our policies, but is somehow exposed or more vulnerable than a trusted zone.	Network: Externally accessible Web, mail, and DNS servers Application: Front-end code or untrusted third-party code Physical: Lobbies and waiting rooms
Untrusted	The untrusted zone is the area where we have no direct control and which is not governed by our policies.	Network: The Internet and dial-up phone lines Application: End-users or external devices Physical: Everything outside the building

Separating Zones

Having a security vulnerability or exposure is similar to having the common cold. If one object has it, all other objects near it are likely to be exposed. To protect valuable resources, we must be able to maintain high levels of security by protecting resources from zones of lesser security control. "Zoning" is the process by which we group similar objects into proper zones and separate them from other zones for added protection. The separation mechanism could be as simple as a firewall, a security control applet, or a locked door. The goal is to have some degree of control over what happens between the different zones.

Communication Between Zones

While separating zones is all well and good for security, it would not be practical to completely isolate all zones from each other and never allow them to communicate. Just because the Internet is untrusted does not mean we should simply cut off all internal access to it. However, allowing communication between zones can be extremely dangerous if the proper security measures are not taken. Fortunately, there are several conventions to safely allow access to take place between different security zones. Each convention has its own advantages and level of exposure to consider, but almost every situation can find a security solution in one of these zoning conventions.

In the following section, we will be looking at these zoning conventions. We will look at the different zoning possibilities and the levels of exposure associated with each, as shown in Figure 5.1. We will start with the least secure and least desirable scenario and progress to the most secure and desirable scenario. Each added level of security has its potential drawbacks in flexibility and functionality, so it is important to adopt the practice that provides the least exposure without making any harmful sacrifice in usefulness.

Figure 5.1. As zoning functionality increases, exposure increases.

Figure 5.2. This section includes several diagrams; this legend will help us talk about them.

Inbound Communications/Access

When we think about access security and zones, we normally think about inbound communications. These are the communications where something in an untrusted zone needs to talk to something in a trusted zone. A common example of this would be customers on the Internet accessing a page on a corporate Web server.

The inbound access zoning scenarios we will discuss include:

• High exposure Direct inbound access/communication

• Medium exposure Relayed inbound access/communication

• Medium low exposure Indirect inbound access/communication

• Low exposure Inbound traffic to an isolated DMZ

High Exposure: Direct Inbound Access/Communication

The situation depicted in Figure 5.3 is the most exposed and the most unsecure of the zoning scenarios. Here, an untrusted subject is allowed to make direct contact with a trusted object. In a casino, this would be similar to allowing the customers direct access to the vault, with perhaps one or two guards restricting this access. The trusted object is exposed to attacks from the untrusted zone. If an attack is successful, critical information and services on the trusted object will be compromised.

Figure 5.3. High exposure: direct inbound access/communication.

Medium Exposure: Relayed Inbound Access/Communication

In the scenario in Figure 5.4, we introduce a middle relay into the mix. A relay is responsible for negotiating communications with an external untrusted party, making sure they are acceptable, and then passing them on to the receiver in the trusted area. The filters in this situation limit the access from the untrusted area into the relay, which allows the relay to remain dynamic, and communicate with many parties with some level of protection. This would be similar to having casino customers request their money from the vault and using trusted employees to actually collect the cash.

Figure 5.4. Medium exposure: relayed inbound access/communication.

Here it is important to point out that, despite the fact that there is a filtering mechanism in place, communication is still taking place "directly." While a firewall or filtering code may exist between the two zones, it is only acting as a security bridge between the communicating parties. The actual channel of communication is directly connecting the two parties, exposing the trusted party to attack. A successful attack could compromise any system hosting sensitive data.

Here, the relay is exposed to attack from the untrusted area. The relay is, however, dedicated to its task and is not running extra code, applications, services, or other things that would expose it to many attacks. The communication between the relay and the internal object is also extremely restricted. Unlike the channel to the untrusted zone, the channel between the relay and the trusted zone is highly restrictive and communications must conform to a strict set of expectations. Thus, if the relay is compromised, the chances of being able to use the relay to attack the system in the internal zone are greatly reduced.

This scenario is one of the most commonly adopted for securing an email or DNS server, authentication and data access application models, and other services or functions that require real-time access to systems, applications, or services in a trusted area.

Medium Low Exposure: Indirect Inbound Access/Communication

We make another major improvement in our relay scenario when we can treat the relay as a mechanism that listens to everyone and talks to no one (see Figure 5.5). More accurately, the relay receives requests and updates from parties on the trusted and untrusted sides, but initiates no requests of its own. Thus, the relay has no direct access to any resources in the trusted zone. This would be similar to having security personnel supply the casino cashiers with funding from the vault, rather than letting the cashiers get funds directly.

Figure 5.5. Medium low exposure: indirect inbound access/communication.

A common example for this scenario is a Web server or application that replicates data from an internal source on a regular basis. The Web server may be designed to request information from customers over the Internet. When a customer enters the information, it is not directly relayed to the internal system, but rather, it is stored in a temporary location until the internal system performs a scheduled polling. This allows for customers on the Internet to update their information without exposing the internal data system to the untrusted Internet, or to the semi-trusted Web server.

Low Exposure: Inbound Traffic to an Isolated DMZ

Figure 5.6 shows the most secure approach that can be taken when hosting a service accessible from an untrusted zone. In this scenario, the semi-trusted application or server functions independently of the trusted zone. It services requests from the untrusted area without risk of compromising trusted zones. This would be similar to having the casino cashier only give out chips, with no access to the vault at all.

Figure 5.6. Low exposure: inbound traffic to an isolated DMZ.

As might be expected, our most secure solution is also the least functional. While it provides the most secure approach to hosting services and applications, it can only be used in limited situations where data updates and requests are not required to or from a trusted area. The classic use for this scenario is in an external Web server that requires no data to be polled or pushed from an inside network. Updates for Web pages are copied to a CD-ROM and installed manually on the server. If there is any statistical information on the Web server, it is copied manually via diskette and not through the network. This scenario is highly recommended for systems and applications that do not require heavy maintenance or dynamic data.

Outbound Communications/Access

Outbound communications and access are often thought of as being safe and secure. In networking, for example, many organizations put up firewalls with a simple ruleset that states: "Everything is allowed outbound; nothing is allowed inbound." In fact, there are even professional firewall devices from prominent network companies that use this as the default configuration, encouraging their customers to worry only about inbound communications.

It is true that outbound communications are less often exploited than inbound communications. This is only true, however, because hacking into a system through its outbound access does not present quite as many easy opportunities to strike. Hacking a system making outbound calls is still however quite common in the security world and is just as deadly as hacking an object accepting inbound calls.

In most forms of access, there must be data transferred in both directions. To browse a Web server, for instance, that server must send pictures, text, files, and even scripts. Sometimes this communication is obvious; sometimes it is transparent and hidden by other tools. Most modern firewalls, for example, automatically open a port for an untrusted party to send data back to a requesting client. This data can be loaded with malicious scripts, files, and miniature applications that can be used to hack a system or network.

The NIMDA worm, for example, infects Web servers and then infects the PCs of those clients browsing the server's pages. Those PCs would then spread the worm to internal systems and servers via numerous other methods. A normal network firewall would be unable to detect or prevent such activities, even if the firewall strictly forbade access from untrusted to trusted systems. Since the client is the one requesting the access and opening the channel, NIMDA simply rides back on the existing communication.

The outbound access zoning scenarios we will discuss include:

• Medium exposure Direct outbound access/communications

• Low exposure Relayed outbound access/communications

Medium Exposure: Direct Outbound Access/Communications

In the scenario shown in Figure 5.7, an internal system is communicating with an external system in an untrusted area. For instance, in a networking example, internal users would communicate (through an open firewall) to systems on the Internet for Web browsing or chatting.

Figure 5.7. Medium exposure: direct outbound access/communications.

There are two primary concerns when considering this form of direct outbound access, be it via networks, applications, or physical means:

• Possible exposure in the return path In almost all cases where outbound access is required, a small gap must be made in security to allow for the untrusted party to reply. When we open our front door to talk to a person outside, there is always the chance that the individual will attempt to force his or her way into our protected area. If we make a network communication with a partner, there is always the chance that the second half of the communication will contain an exploit or virus.

• Increased chance of exposure from internal parties When direct outbound access is allowed with external parties, there is a much greater chance for an exposure to occur from the inside. If, for example, a bit of malicious code is launched within an internal application, it can open a communication channel to untrusted areas, allowing for remote control. For example, a back door on a computer can initiate a tunneled communication to an external party to allow it to hack into the trusted network.

Low Exposure: Relayed Outbound Access/Communication

To allow access from a trusted area into an untrusted area without being openly exposed requires a relay between the subject and object. Similar to the inbound relay scenario, the relaying system or application component must be a dedicated device or code that is responsible for communicating with the external server on our behalf. A classic example of this process would be a network proxy server (application firewall) that relays all Web requests to the Internet for us.

Figure 5.8. Low exposure: relayed outbound access/communications.

The system or application performing the relay services accepts numerous requests and replies from both trusted and untrusted networks. The relay limits its own communications to the internal systems in such a way that it will only pass on normal data and will strip any unexpected, extraneous, or unauthorized data. This process helps to protect all systems, and focuses more security attention on the relay instead of the internal object.

Applying the Zoning Concepts

To apply these zoning concepts in our decision-making process, we must learn to quickly recognize where different levels of security are needed. The following six-step procedure can help in this process:

Six-Step Zoning Process

1. Identify any instance where an untrusted or less trusted object comes into contact with a trusted, valuable, or more sensitive object.

2. Determine the direction of communication that is required. Ask yourself, "Is it possible to use an outbound model, or does the communication need to be initiated by an untrusted object?"

3. Determine where it would be possible to separate the trusted object into two components: one that handles the sensitive data and the other that acts as a relay or middle entity in the transaction.

4. Decide what forms of communication need to take place between the outside, middle, and inside, and which zoning model to apply. Work through them in this order:

   1. Can you effectively and efficiently use the low-exposure models?

   2. If not, can you use the middle low- or low-exposure models?

   3. If neither model can be used, does the value of the communication and its potential risk make the high-exposure model an acceptable solution?

5. In the model that is chosen, place as many security controls between each of the components as is reasonably possible.

6. Document the reasoning, supporting data, and conclusion in this decision-making process. Keep this document for reference and to simplify the decision-making process for similar situations in the future.

Example of the Zoning Process

A baked goods engineering division has an existing server within its internal infrastructure that keeps the recipes for various types of bread. This information is kept in a secure DB on an internal network. A new initiative has been made to allow for partner bread-baking companies to access specific entries in the ever-changing DB. The board of directors has requested access to designated recipes for partner companies with a valid login and password through a secure Web browser.

Step 1. In this situation, the trusted/sensitive and untrusted objects are obvious:

Trusted/Sensitive object:	Recipe data
Untrusted object:	Bread-baking partners

Step 2. Since the bread-baking partners are going to be accessing the data as they need it and will be using a standard Web browser, we must allow them to initiate requests for information. The communications will be inbound (their Web browsers will be coming into the network to access the recipes).

Step 3. The recipes are stored in an Oracle DB; a standard bread-bakers application is being used to access the information. For external partners, we will need to create a Web server to act as the front-end. The Web server will be in a semi-secure part of the network and will get its data from the Oracle server, which will remain safely in the internal network.

Step 4. In considering the different exposure models, the low-exposure model would make it nearly impossible to handle real-time requests. By the nature of the project, partners will be accessing the data in real-time, and thus we must be able to relay the request at the same time that it is made. As such, the medium-exposure model, where the Web server will authenticate a user and then pass the request for information back to the Oracle DB, is a better choice. The Web server is the middle entity, so if it comes under attack, it does not directly contain any sensitive data.

Step 5. The Web server is on an isolated network protected by a firewall and IDS devices. The firewall allows only Web (Hypertext Transfer Protocol [HTTP] and Secure Hypertext Transfer Protocol [HTTPS]) traffic to flow from the partners into this Web server. The Web server must then pass through the firewall again to access the internal Oracle server. This communication is limited to a very strict and defined set of DB calls that allow access only to required types of information. Thus, if someone manages to attack the Web server, there should be no effect on the critical DB server.

Step 6. Document the decisions made with each step and place them in our "Security Decisions" folder for future reference.