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.
Small Numbers to Myriads
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.
65,000-lane Highway of Attack
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.
Your Company on Restriction
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.