Recently, I've seen several pieces which fall into this category, and would like to toss my own two cents on the pile. The one that sort of kicked off my initiative to write this was a posting by Adriel Desautels which appeared on the Snosoft blog and on the pentesting mailing list. The post asserts that vulnerability scanners don't work. The point is made that vulnerability scanning is not an effective tool because the core pieces fall on the tail end of vulnerability research and the scanners themselves aren't accurate. On the accuracy part, the claim is made that his best case experience with scanning tools is 30% accuracy (that's obviously a guesstimate, as no hard data is provided). Adriel's conclusion is that the best replacement for a vulnerability scanner is a well-trained penetration testing team which conducts its own research.

Of course, as with many outlandish claims, I disagree. Going down the list, I'd have to say first that of course vulnerability scanners have a huge amount of value, and definitely have their place. His estimate of 30% accuracy I suspect to be completely made up, and will continue to until I see some sort of data to back it up. Also, no reference point is given on that number. Is it 30% of all vulnerabilities that ever have been or ever will be known about a system? What is 100% then? Is this counting false positives and negatives (or just one of them, or neither)?

My experience with Nessus, Saint, nCircle, and others has shown the whole class of tools to be hugely useful, so long as you look at them in the right context. What's important to keep in mind is exactly the title of this post. All tools have their place, and all needs have a set of tools which address them best. Vulnerability scanners are generally useful in two roles. The first is in a one-time look at a network. I use Nessus whenever I assess a client's network for the first time. That's because in addition to pointing out vulnerabilities, it gathers tons of data. What's best is that it does this automatically. I could use a collection of 20 or more tools to enumerate hosts and poll their various services for data, but that's a waste of time when a vulnerability scanner will do all of it for me. While the vulnerability scanner is doing its thing, I'm free to do a walk of the premises, talk to staff, or take a nap. All of these are much better uses of my time than running individual tools manually. When the initial scan is done, I can then take closer looks at specific hosts and services with more specific tools if need be. My time at a client site is usually quite limited, so it's important for me to make the best use of it.

The other case where a vulnerability scanner is very useful is where a whole network needs to be monitored for change. Because the vulnerability scanner is pretty consistent in what it does and very broad in what it covers, and because the whole process is automated, scans can be done in intervals very easily. Data sets can then be compared over time to show trends in vulnerability and give hard data about where the most vulnerability probably is. I want to key in on the fact that I say "probably" in the last sentence for a reason. Vulnerability scanners are plenty of useful, but what they aren't is perfect. Adriel's article is pretty much centered around the main weakness of any automated security tool, which is that they can't see everything, and a good deal of security is in the soft/squishy part (the people and organization). Additionally, he makes the point of the lag time between vulnerability discovery and detection by scanner, but we'll get back to that. Backing up a bit, the reason you can't use a vulnerability scanner to identify where vulnerability in your network definitely is, is because of a lack of comprehensiveness of the tool, and the sheer complexity of vulnerability.

Vulnerability scanners can't tell you that your policy is terrible or that the structure of your network is poor. They can't tell you that Frank in accounting took home all of your company's customer data, and they can't even begin to detect your lack of visibility into the traffic flowing across your WAN. What they can do for you (and me), however, is catch low-hanging vulnerabilities and report them in an automated manner and allow us to use our time handling other tasks. As with all tools in all industries, you can't expect a tool meant for one task to be the end-all, be-all solution to something as conceptually large and complex as "security."

To address the issue of lag time between vulnerability discovery and detection by a vulnerability scanner, I believe this is a moot point. This lag exists in all tools and solutions in one form or another, and where one tool or solution might have a lower lag than others, it can't be considered comprehensive. Specifically, Adriel suggests that teams of security professionals replace vulnerability scanners functionally in organizations. This is just plan silly for a variety of reasons. First is cost. an internal team of security professionals is simply out of the question financially for most organizations. Contracting out the service just once is also expensive compared to even the most expensive vulnerability scanners (Nessus goes for $1200/year/scanner, nCircle is upwards of $30k for the initial installation). Getting a team of specialists to do even the basics of what a vulnerability scanner can do is a waste.

However, sticking to the title of this article, I believe that all tools and solutions have their place and that there is a proper process to attack any problem. For security, you first need to perform gap analysis. In the early stages of reaching a secure state, tools like vulnerability scanners are extremely useful, because they allow you to efficiently identify and address the most numerous and obvious flaws. A security professional's role here shouldn't require much direct interaction with the systems at all. Automated tools will churn up enough information to get an idea of where things stand, and help to identify major problems. This is your typical Vulnerability Assessment; a broad process which should take a shallow look at the whole organization, identify major and core issues, and develop a plan for action. This sets the current state and outlines a goal state.

The middle parts of the process require different tools for different reasons. The vulnerability scanner is still very useful here for the tracking of remediation and detection of new minor issues, but gives way to higher-end planning and consulting which aims to set up controls which proactively secure the network, and do so in intelligently redundant layers. The latter parts of a security ramp-up are where the vulnerability scanner becomes a minor player in that it is used to catch smaller issues which fall through the more proactive steps put in place to take care of issues before they cause vulnerability. Also, this phase of the process is where penetration testing becomes relevant. As is stated in this rather controversial prediction by Brian Chess, penetration testing should be used as testing is in the scientific process. That is, penetration testing should be used to test a theory. The theory should be something along the lines of: "security control ABC should stand up to XYZ types of attack, and those attacks should trip some sort of alarm when a certain point is reached." In other words, a security control is designed and put in place earlier in the process, then needs to be stress tested to prove that it is working as expected. This is exactly how we've approached penetration testing (especially since we make it very distinct from our vulnerability assessment service) since day one here at White Badger.

So to sum up, early in the security ramp-up process (where most organizations haven't even started), automated tools like vulnerability scanners have a huge amount of value because they allow for a large amount of data to be collected and acted on in a very efficient manner. As the process goes on, the more automated tools give way to more specialized tools used to assess certain specific hosts/services/vulnerabilities. At the end of the process, penetration testing is performed, and that is almost entirely manual. The best (in my opinion, the best are the most realistic, regardless of scale) penetration tests will combine attack methods from all different angles to properly estimate the success rate of exploiting a vulnerability.

Vulnerability scanners aren't worthless. That's like saying that a table saw is worthless because all woodworking can be done with a screwdriver and a utility knife. The worth of a tool is directly proportional to its cost and benefit. Vulnerability scanners generally have a low cost relative to their closest alternatives, and a high payoff so long as the expectation is reasonable. They have their place in the security process and won't be replaced functionally by an adjacent tool any time soon.

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 ;-).

The following speakers will be speaking on the following topics:

Date: Wednesday, June 11th, 2008

Time: Registration and refreshments at 2:15pm, program starts at 2:45pm sharp

Place: Records Management & Archiving main office

    2711 Freemansburg Ave.

    Easton, PA 18045

Refreshments: Light refreshments during registration and seminar, networking reception after presentations at 5pm.

If you would like to attend, please RSVP to info@recordsmanagementpa.com, or call 610-253-2753 and ask for Ed Rossner or Bill Magerman.

I just came across this article announcing Schlage and Z-Wave releasing a wireless door knob/lock. I'm honestly in shock. Given the history of very breakable security measures seen in supposedly secure wireless protocols (802.11a/b/g/n, WEP, WPA, LEAP, Bluetooth, etc), I don't see this as being any sort of good idea. As far as I know, there are no current security issues with Z-Wave's technology. Then again, I haven't heard of anyone actually taking a close look at it. I can virtually guarantee that once one of the many wireless security experts out there decides to break it, it will happen quickly.

While most of you might be thinking that I'm a nut for blasting this without first trying it myself, but there is a reason this is a bad idea. It comes down to forensics and liability. Suppose someone breaks in to a house protected by one of these units by exploiting the wireless controller. Aside from a bunch of missing stuff, there is no evidence that someone actually broke in. Even in the best cases (excluding some bumping), a picked lock will suffer irregular scratches inside the keyway. Brute force entry has obvious tell-tale signs. Wirelessly hacked locks would likely not be able to be discerned from ones that were simply left unlocked, or ones that had malfunctioned. When it comes to getting your insurance company to cover that, they'll likely laugh at you and refuse to reimburse you for losses.

In short, this sounds fun for keeping the kids out of the utility closet, or perhaps for some other hobby use, but don't use it to protect ANYTHING important.

Anyway, the video doesn't exactly go in to any sort of detail... on anything... but it's still a reasonably good showing for White Badger Group. Here's the link to the page with all the videos for the different regions, and here's the video for Lehigh Valley, which is the one we're in. Enjoy.

Every good security professional has a healthy respect for the unknown, which usually is tagged as paranoia. An appropriate amount of paranoia in the right area leads to being quite effective in securing the network you're in charge of. The key is education. This doesn't mean that you need a degree in watching over your shoulder, but you should know what to be afraid of, and how to make sure you know if/when trouble is happening.

Listening to a recent Pauldotcom podcast, the point was made that most people don't really get serious about securing their code or systems until they've personally been attacked. The other side of this is that actually doing some of the attacking and seeing it work firsthand usually has the same effect. As such, it's important that all IT professionals get that experience some time in their careers.

I find it very interesting how human psychology impacts the information security industry. To me, it seems very straightforward. You have something of value, bad people want it, you need to protect yourself. There's nothing outlandish or new there, that concept has existed since the beginning of life. But somehow, despite our advanced intelligence and civilized society, we all seem to have a default naiveté when it comes to information and IT security. I suppose this effect also occurs elsewhere, such as when a person doesn't regularly wear a seat belt until he/she has been in a serious car accident.

Given the above, it's not difficult to understand why FUD-style (fear, uncertainty, doubt) marketing is necessary and does work. Placing someone in a scared mode is an incredibly effective method for switching them from actively opposing security to actively embracing it.

To be an effective information security professional, what you need is a balanced, aware, and fact-driven sense of paranoia. A proper balance is struck when your paranoia drives you have a constant need for security while not blinding you to the reality of your environment. As such, you need to be incredibly aware of the organization you are working within. While security is important, it needs to coexist with functionality, usability, and visibility, while also making the political, budgetary, and regulatory parts of the equation work. Because paranoia is a 100% emotional response, it's important to keep it properly in check. All decisions need to be passed through a filter of reasonability and facts, so that you don't spend all of your resources defending unevenly against the threat that scares you the most.

I think all good security professionals possess the right kind of paranoia that drives them to stay effective and not become stagnant or complacent. I personally think every IT professional would do well to acquire a bit of the paranoia. While this usually comes as a result of a negative experience, it can also be had by way of a class with hands-on hacking. However you get it, your effectiveness and career will benefit greatly, as will the security of everything you touch.