One Size Never Fits All

by Fred Avolio, Avolio Consulting

At computer-related conventions, the free give-away T-shirts seem as ubiquitous as the software they advertise. Usually the vendors simplify their lives by offering only one shirt size, optimistically promising, “One size fits all!” The reality, of course, falls short. When I was working for a vendor, we used to quip, “One size fits no one.”

Yet, some of us have the opposite view of security device configuration. Here, we act as if “one size fits all.” For example, we tend to set our firewalls up with coarse rather than fine granularity. If three people need access to an Internet service, we give every employee access to it. All services are allowed between offices over a VPN rather than just the required services.

We can do better. In fact, we must.

From Small Numbers to Myriads
It used to be when someone said they needed “just the basic services” from the Internet, they meant these four:

1. terminal services (TELNET)
2. file transfer (FTP)
3. e-mail (SMTP)
4. USENET News (NNTP).

This small number of services was required by a small number of people for the company to transact business. But things changed. Today, we add to this basic list HTTP, SSL, RealMedia, H.323, and what seems like a myriad of others. What services we allow, and how we allow them, can make the difference between mediocre security and good security.

The 65,000-lane Highway of Attack
As network administrators, we often paint with broad brush strokes when finer ones will do. Broad strokes seem easier in the short run. Perhaps they mean fewer rules to enter in the Firebox configuration; fewer mouse clicks. Broad brush strokes may suffice — for a small number of services, for a small number of users. But as we add services and users, loose configurations should lead to sleepless nights of worry because of the possible disaster ahead. Let me explain.

Every service we allow through the firewall is a potential avenue of attack. Every user is a potential threat agent. If we have n users and m services, we have an (n x m) problem. When we provide the same services to everyone without regard to what the business requirements dictate, the risk multiplies. So, if everyone can use TELNET, and everyone can use e-mail, and everyone can use HTTP, and everyone can use RealMedia, then every desktop has the potential to be the weakest link in the security chain. If an attacker compromises a single user’s account or system, the attacker has a large choice of services from which to extend his reach and continue the attack.

A bad case becomes worse when we interconnect offices using Virtual Private Network (VPN) technology. For many of us, the VPN not only connects remote offices and users, but connects them in such a way that the firewall doesn’t seem to be there at all. The VPN virtually circumvents the firewall, and our offices feel like they are on one big flat WAN with all network services permitted. If an attacker gains access to a remote office, he has a 65,000-lane highway to use for furthering his attack.

Put Your Company on Restriction
The better practice is to be more specific. The better practice is to be more restrictive, but to be so in a way that still supports the business requirements. If your network is currently permissive, how do you find your way to a more disciplined implementation? Let’s look briefly — and simplistically — at some planning questions we might ask, at the answers, and at what we might do for a hypothetical company of a hundred people.

First, ask: What services are required by most (if not all) people in the company? E-mail probably tops the list. E-mail from and to anywhere? No, we allow SMTP (e-mail transmission) from anyone (all 100 people) to the e-mail servers in the company. We allow every user on every desktop to retrieve e-mail from the internal e-mail servers. Then we allow SMTP connections from each e-mail server, to anywhere on the Internet, and from everywhere on the Internet to our firewall or external mail gateway. (There are probably no other network services universally required. Think about it.)

Second, ask: What services are required only by a few? Example answer: HTTP (Web access) for thirty sales and sales support people, and outbound TELNET for five people in technical support. The TELNET connections shouldn’t go “wherever;” they are needed to ten particular Internet addresses — specific customers of the company. Some researchers in R&D need NetMeeting. Lots of other people may want other services, but often, they have no legitimate business purpose.

Next, we configure our firewall by first turning off all services, then testing it. Most firewalls come with default settings. Turn them all off. Start with a closed door. After you’re convinced that the firewall is as tight as you can make it, selectively add the services required, for the people who require them. What? Not everyone gets Web access? It’s up to you and your security policy, but when we ask, “Who needs HTTP to conduct business?” the number will almost always be smaller than the total population of the company.

Do the same exercise for interoffice protocols over a VPN. What services are required? Configure the firewalls to only allow those. And remember this: It’s better to be too restrictive than too promiscuous. If you’re too restrictive, you’ll get complaints, so you’ll know that you turned off a service that was required. On the other hand, you will rarely learn that you are allowing too much through the firewall or between your offices … unless you discover a network break-in.

Sleeping Easy
What’s the point? To sleep easier. You meet the business requirements — just the requirements. You lock down as much as you can. You start with a completely closed firewall (nothing flows) and then add only those services that are required. You sleep easier knowing that you’ve done everything you can to achieve the balance of security and business. You also sleep easier knowing that — for once — you’ve turned a sloppy “one size fits all” into a custom-tailored fit. ##