Perimeter Considerations

Next, we consider how policy can be implemented in our perimeter architecture. If good policy already exists, we simply need to assess our perimeter technology, asking the question, "Is it possible for us to implement our policy with the technology we have?" Now that we have a firm foundation in what policy is and we are sensitive to unenforceable policy, let's go back to the notion of active policy enforcement. We will discuss how to map our architecture to our policy, and how the limitations of technology sometimes force us to modify our policy.

Real-world Operations and Policy

All too often we have to bend policy to match our architecture. This doesn't have to be the guiding principle, however. As we close out this chapter, let's cover some of the technologies and consider their implications for our policy position. Because perimeters examine and log packets, running a perimeter involves privacy issues. In addition, as email bounces or gets sent back to us, we might see a user's private thoughts. Our policy needs to prepare us for these situations in which limitations in our technology throw us information we might not expect to see. Policy must provide guidance to administrators and to those who operate content-sensing devices about what is and is not appropriate when private information is exposed.

Note

Every time we buy a new product or upgrade a system, our goal must be to build an architecture that actively enforces our policy.

Presumption of Privacy

If you are a student at a university in the United States, you have a presumption of privacy. Certainly, some speech is not protected; for example, you can't threaten the President or threaten to take your own life and expect confidence. However, on the whole, custom, practice, and law protects your communications.

If you are a uniformed member of the United States Armed Forces, you tend to live on the other side of the spectrum. Every time you enter a military base, you are greeted by a sign letting you know that you and your possessions are subject to search. The telephones have stickers warning that they might be monitored. You know that you do not have a presumption of privacy.

In an earlier section, we gathered and evaluated both the written and unwritten policy, which gives us the groundwork to determine what the presumption of privacy policy is for our organization. This helps us make perimeter design decisions. If you are designing for a university, you probably shouldn't collect content of packets. One of the engineering requirements for the Shadow IDS was to be able to detect attacks without looking at content. Widely deployed antivirus tools might be the "canary in the coal mine" that alerts us to a user who is circumventing the perimeter. Usually, we can use the information about the presence of a virus, but what do we do when we start getting arbitrary files from someone's hard disk courtesy of a W32.SirCam-type infection? It depends on the presumption of privacy. Email handling is another sticky point.

Email Handling

Have you ever worked in an organization in which people were fairly certain that the postmaster read their email? Needless to say, it should be grounds for termination if someone intercepts and reads mail without cause or written permission, but bounced mail comes to the postmaster. Anyone who has been a postmaster for any length of time has a story to tell about bounced mail. A postmaster must try to handle this by giving a quick look at the mail headers and ignoring the content, but sometimes it is inevitable. If the mail to the postmaster is a complaint from an outsider who received mail from our organization, what then? We probably do need to respond and help in the investigation by collecting the logs that corroborate or disprove the complaint. This is just one of the ways that working with the perimeter defenses can vault us into the wonderful world of incident handling.

Incident Handling: Preparation to Containment

Consider the six stages of incident handling:

• Preparation

• Detection

• Containment

• Eradication

• Recovery

• Lessons learned

It quickly becomes apparent that the perimeter is a crucial player in the process. Building a perimeter that allows flexible, active policy enforcement is one of the best ways to prepare for an incident. The event might well be detected by firewall or intrusion detection logs. After detection, we can use the perimeter to assist in the containment phase, where we typically make a decision between two approaches: contain and clean, or watch and learn.

If you have a system that you suspect is infected, your policy might be to contain and clean. You might choose to lock it down tight and prevent traffic from coming from the Internet to this system, and also prevent outbound traffic from the system to the Internet. In this book, we cover egress filtering, but it is worth emphasizing that a compromised box might be sending packets with spoofed source addresses. If you have a switched environment, you can often accomplish lockout right at the wall socket. Alternatively, you might decide to increase your instrumentation and see what you can learn about the motives and techniques of the hackers.

The watch-and-learn approach to incident handling takes access and control to the level of an art form. The Honeynet Project (http://www.honeynet.org/) has done more than any other group to advance the state of observing attackers in the wild who have been granted access, while maintaining control over the state of the system. If you are considering this approach to incident handling, you would be wise to visit Honeynet's website, get on the mailing list, and get involved. Tools such as rate-limiting switches can be helpful with this approach. Instead of denying the attacker access to the suspected machine, you throttle the bandwidth to make the attacker's experience a longer wait. This gives you a little more time to analyze the situation. Watch and learn is a higher risk strategy than contain and clean, but the potential payoff is also much higher.

Incident Handling: Eradication to Lessons Learned

At some point, usually within 24 hours of a suspected compromise, the primary focus is to get the system back in business. The first step is to completely clean the system and then to restore operations. The perimeter systems can be used for additional monitoring and filtering. Often, the attacker comes back, and we must remain alert for this. In addition, the logs from the perimeter help tell the whole story and are useful during the lessons learned phase of the process. If you don't understand how you were attacked and make the appropriate changes, it is all too likely it will happen again tomorrow. In the final section of this chapter, we will briefly consider policy that provides the security controls that apply to firewall administrators.

Rules of the Road

The perimeter sets the rules of the road. If we use active policy enforcement to manage access and control for various information assets, when and how do we have the authority to make changes in the perimeter? Who has the authority to request these changes, and under what circumstances? Who makes the final approval? Whatever your process is to approve changes, make sure you document them. Often, an apparently small change in filtering policy can have unintended side effects. If a change log exists, it can be of great help to those who have to troubleshoot the system.

The Firewall Admin Who Shouldn't Have

When I was working for the U.S. Department of Defense, I noticed some suspicious traffic on the Shadow IDS the department had deployed. After considerable analysis, it was fairly clear that there was a complete TCP connection, stimulated from HTTP, but on a high port with a three-way handshake, a data exchange, and a graceful close. How could this be? A sandbox violation seemed impossible. The client system was behind an application gateway firewall, and things such as Java and ActiveX were not permitted. How had the client been directed to open the connection from the inside of the facility? When I went to see the firewall administrator with the logs, I learned that the firewall administrator had turned off the HTTP proxy. My jaw dropped as I asked why. The reply was, "I got a phone call and someone complained it was too slow." Make sure you understand and follow the process in your organization for making changes to the perimeter's policy.