Design Flaws in Deployment

Let's suppose you work in IT security at some large company. From one perspective, your job is to make sure that nobody's security expectations are violated. Your users probably think of this as you taking care of security for you, or possibly you trying to prevent them from getting their jobs done, but really you're balancing variables: stakeholder expectations, and security in reality.

This could be fairly straightforward if it were all about implementation problems. You could just run new software through your favorite testing method, and keep up with the patches. Add in as much explicit security technology (anti-virus, a firewall, NIDS) as your stakeholders are willing to pay for, and then keep telling stakeholders you need more staff or money to do X, or the company is at risk. (Cynical? Maybe. Typical 10 years ago? Yes. Typical now? Less so, but not entirely gone just yet.)

Enter design & configuration flaws, by which I mean all security issues in which every system is acting exactly as it is designed to act, yet an attacker is able to realize a threat. You could scan for some configuration flaws, and you could run new software through a design review, but these strategies won't give you much insight into how the new individual system will affect your overall security unless you take the systems' environment into account. That is, there are now 3 variables to tweak: stakeholder expectations, individual systems, and the environment of the systems. These variables are so interrelated that they can't be tweaked independently.

Here's how 2 common (and sometimes resisted) IT security techniques affect these variables, assuming the possibility of design & configuration flaws:

Configuration Rules

If you're like most IT security folks, you have some rules about how systems can be configured. Usually these rules are network-specific, e.g. if the machine lives on network X it can't be dual-homed and it must use Kerberos authentication. The ideal is, if the system doesn't meet these rules, it doesn't get on the network.

Rules like this affect both individual systems and the system environment. They have 2 purposes:
1. Fit an individual system into the environment without enabling any possible design & configuration flaws in this system.
2. Fit a new individual system into the environment without changing the environment in a way that enables a design or configuration flaw in existing systems.

For every rule on your security list, you should be able to say whether it is trying to do #1, #2 or both. If you can't, why is the rule on the list at all? As you can imagine, it will be a lot easier to determine the purpose of a rule and see whether a given set of security rules is effective and consistent for these purposes if someone has documented the intended properties of the environment. Whether you are writing a new set of rules or reviewing some existing rules, figuring out what you want in the environment is a great place to start.

One key environmental property is that individual systems affect each other in a known, limited set of ways. This means that for each environment you need a list of ways systems are allowed to interact. Can they mount each others' disks? Ssh in?

Other desirable properties are simplicity and consistency. For example, there should be some core services (usually including routing, DNS, and if applicable, DHCP) which are provided by the same source for every individual system in the environment.

I'm sure there are other useful properties for an environment; you get the idea. And yes, you could argue that these rules also affect stakeholder expectations, by presenting a picture of the facilities & properties of the environment.

Sign Off on Exceptions

Network X will sometimes be the most appropriate place for a system which simply cannot meet the rules. The standard way most IT security departments respond is to have an exception process which requires review and sign off, frequently by some high-level political figure at the company. This leads many people, including some security people, to believe that the primary purpose of such a process is to make it harder to get an exception than it is to comply with the set of rules to start with. To you I say: Danger! You are missing the point.

This review and sign off process affects individual systems, the system environment and stakeholder expectations. The purposes should be:
1. Determine whether the proposed exceptions will enable any design & configuration flaws in this system, and document any additional properties of the environment (beyond the initial list of intended properties) which are protecting this system.
2. Determine whether the proposed exceptions will enable any design & configuration flaws in other systems in the environment, and document any changed or additional properties of the environment (beyond the initial list of intended properties) adding this system will cause.
3. Ensure that stakeholders understand and approve any flaws that have been enabled, and any threats an attacker could now realize.

If this is going to work, you need to compare each proposed exception with the intended and actual properties of the environment. Answering a bunch of questions is not sufficient unless those questions reveal the information from #1 and #2. Also, it has to be cumulative. Previously authorized exceptions must change the documented properties of the environment, or you won't be able to tell whether this exception clashes with previous exceptions.

Whether to allow an exception is usually, in the end, a business decision, but the decision makers need to understand the security implications of what they're deciding, as in purpose #3. Doing this right will be hard enough that you won't need to add hoops just for their deterrent value.

I hope these ideas help you develop or re-design a plan for minimizing design flaws in deployment. Next time: some thoughts on design flaws and perimeter security.

--Brenda