July 2008 Archives

Compliance is just the beginning!

Know your enemy. Know your weaknesses. Have a plan.

Behind these seemingly simple statements lies a lot of thought. Firstly, we talk about compliance. By definition, compliance means that you comply with standards. These standards are set up as a bare minimum operating level for any given industry so that all the players meet some standard set of rules and can work together based on them. With cars, it's state inspection. With food preparation, it's health inspection. With any structure, it's building code. In every one of these, the bare minimum is almost always just that, and the gross majority strive to be better. If your car only barely passes inspection, it's likely not very safe or efficient. If your food was cooked in a kitchen that got the lowest allowable score on a health inspection, there's a good chance that you'll be sick in the near future. If your house only meets building code minimums, it likely won't hold up very well in a wind storm.

So, given that compliance is just the bare minimum, and that the bare minimum is not something you should be aiming for, why is it that so much effort is spent in the financial industry on being compliant? Almost all of the security breaches in recent memory and likely in to the future have been and will be at organizations compliant with security requirements. Compliance is a minimum, and the minimum is never good enough when you're dealing with other people's money. Striving for compliance is like trying to come in last place.

Real security should be approached just like all other parts of the business. You need to have a metric, you need to measure it, and you need to manage it. In security, the metric is risk, and it is measured against cost and the risk mitigated. That's the theory anyways. In reality, it's so much more than just cost vs reward. Something we try and make clear to our customers is that there is a balanced security level for every organization, system, and situation. It is reached when security reaches a level where it complements all other parts of the business and is maintainable.

In the end, your goal should be security, not compliance. Compliance is a byproduct of good security practices and good corporate stewardship.

So, as many in the IT and security fields know, it's bad practice to have any one device touching more than one network. The exceptions to this rule are usually security devices like firewalls and IDS sensors, all of which need to be specially hardened as any one vulnerability would go against the point of having multiple networks to separate groups of devices. In the process of evaluating devices from all the top vendors in the arena, I set up a test network on which to run each of the platforms. As part of this testing, I wanted to be sure that straddling a firewall and connecting to several network segments wouldn't be an issue. As it turns out, one of the boxes I tested had an issue. (As I'm under NDAs with pretty much every company I dealt with, I'm not going to comment on which product had the issue. I have been told that a patch is on its way and will hit in several weeks.)

The device in which I found an issue did meet all of my criteria. It had almost zero footprint on the network. It communicated only in encrypted tunnels, which were outbound from the appliance only. It had no listening ports. However, what I did find is that the device responded to ICMP pings (standard echo request/reply). I can see where this functionality would be useful for the end users, but from the standpoint of super-hardening, it should be disabled, or at least have an option to be disabled.

The specific flaw I found was that the OS's kernel didn't perform proper source checking on packets. For example, if interface 1 is on 10.1.1.0/24, and interface 2 is on 10.2.2.0/24, it should drop packets claiming to come from 10.2.2.2 which arrive on interface 1, and vice versa. Failing to do this, the device I was testing happily replies back out the other interface. Spoofing packets from both directions allows us to set up an ICMP tunnel, over which we can move just about anything. Unless the backbone is set up to detect excessive ICMP traffic (monitor port + IDS, or switch-based IDS), or if the traffic needs to pass over standard security devices (an upstream firewall/IDS/IPS/router), this would be pretty difficult to track down. Most organizations I've been in do not have the infrastructure to watch for this kind of tunneling when it is used specifically to bypass the firewall.

This attack isn't exactly l33t or hardcore, it's quite basic. It's unfortunate that some of the basics do get missed when most attention is paid to higher level attacks and other threats, but it does happen quite often. Fortunately, the vendor had an excellent response in terms of time and quality, and hopefully will give me many discounts in the future for doing some QA work for them ;-).