Recently in Commentary Category

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.

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.

If I were to start over with computing, I would make a number of fundamental changes:

1) ALL hardware should be hot-pluggable. I don't mean just USB and the like. All memory, expansion cards, storage, and other parts of the computing architecture should be able to be swapped out without powering off the system. In my thinking, this would require a small core system to be at the center of everything. It would manage all hardware and provide whatever OS with a basic functionality at incredible speeds. The base system should be nearly unusable as a full computer, but divert processing power, I/O, and memory storage appropriately to whatever modules are installed.

2) The architecture should allow for multiple processors of different types. Today, the x86 processor is nearly ubiquitous and is pretty much the most generic or general-purpose processors. However, in the average PC today there exists a number of speciality processors that help accelerate other tasks. The most notable of these is the GPU, which is effectively a processor many times more efficient than the main CPU, but useful only for a handful of commands. In future computers, I would like to see all processors treated equally through a processor abstraction layer, which allows for an arbitrary number of different types of processors, with a scheduler dividing work appropriately among the processors most suited for the work at hand. I would like to see this include FPGAs, which would be dynamically reprogrammed based on what work is being done. An average system would consist of the core components and processor (which would act as the manager/scheduler), a faster general-purpose CPU (possibly multi-core), and one or more FPGA or other specialty processors.

3) The whole platform should never need to be turned off or rebooted. The core system should be able to manage changes to hardware seamlessly and drivers should work at an abstracted layer which doesn't require the whole system to start over whenever a change is detected. Even in the case where processors are swapped out, everything should fall back to the core system whenever modules are removed. This doesn't mean that you shouldn't properly prepare the system for a change. It is unreasonable for the system to catch a physical disconnect and handle it for some components. For example, in the case where RAM is being swapped out, the contents of that memory need to be pulled and placed elsewhere before the system could handle such a change.

4) Everything should be abstracted. Absolutely every piece of everything should run through an abstraction layer. This layer should be running mostly in the aforementioned core system. This allows the OS developers to concentrate on developing a secure, extendable, and usable OS. APIs should be provided for hooking at all different levels so that third party providers can enhance most everything. Ultimately, tasks that, today, require a complete rebuild, should require almost no effort. For example, if I were to desire to move from a single HD to multiple HDs in RAID 5, I would have almost no choice but to start over from scratch. Similarly, upgrading a motherboard is usually catastrophe without reinstalling the OS. This should all be as simple as swapping out a keyboard or mouse is today.

5) Security. TPM, despite many cries to the contrary, is a pretty good idea in terms of keeping unwanted code from running on your system. Unfortunately, the execution this far has been poor, and not much has been done to fix it. Code signing and strict policy (followed up with enforcement) can help significantly cut down on malware. The issue is, they system needs to do several things to keep up. Firstly, it needs to be flexible enough to adapt quickly to emerging threats. Secondly, system needs to be set up with the right tools (like TPM) which enable it to effectively secure itself. Lastly, the system needs sane defaults. Most systems historically ship with defaults which leave them incredibly exposed. This is usually done with the excuse of "we want it to work with everything out of the box". That line of reasoning is not necessarily at odds with security, and vendors need to embrace security as a feature that users expect to work out of the box just as much as any other.

6) Automatic updating of everything. While this has been around for years in the BSD and Debian worlds, it's not something that many other platforms have picked up. The reality is that all software these days is constantly being updated for security and functionality issues. Updating software outside of the main OS in Windows, most unicies and OS X is hit and miss, with many vendors doing their own thing, or nothing at all. This kind of inconsistency leads to either a lot of effort going towards keeping things current, or to a lack of updates. Some OSs (like Debian-based Ubuntu) do a relatively good job, keeping everything installed through the package system (which is usually almost everything) updated automatically. For any new platform, I'd say this is a must. As a side note, all software should be in package form. Installing and uninstalling should be as simple and consistent as possible. Uninstalling should actually result in a clean system, and should be friendly to configurations.

7) A mouse-and-window-based GUI is pretty much standard these days, and there's not much on the horizon to be supplanting that for foreseeable future systems. But, as with developments in the last several years, there have been enhancements in usability. Probably the most widely usable OS out there is Mac OS X. Sure, argue with me if you will, but of the major OSs, I think OS X is the most friendly. There are certainly things that could be done better, and future systems should really be built around them. Firstly, I should never, ever, ever be able to outrun any UI I'm using. There's just no excuse for that. Secondly, windowing needs to work in a predictable way, and that model should never be broken. All too often, focus is stolen or ordering refuses to operate the way it should. Consistency here is of the utmost importance, and should be enforced.

8) Backups. Apple wins again at making backups easy with Time Machine in OS X 10.5, but more needs to be done. I need to be able to take an entire system and move it through time as a whole or in pieces, all the way back to its first boot. Backups should be able to be placed on any storage, whether directly connected, or on a network or the Internet. Backups should be able to be reloaded on different hardware in case of emergency. The backup images should be encrypted so that they may reside anywhere without concern for compromise.

9) Mobility. Systems of the future should allow you to move anywhere and do anything. Ultimately, I'd like to be able to feel as if I'm using the same computer anywhere I go. This can be accomplished using Terminal Services or a similar type of screen-sharing architecture, but that has serious limitations when it comes to certain applications. What I'd really like is for the OS and the hardware to become user centric.

10) Ubiquitous, high-speed, wireless internet access. Whatever system I'm using, it should always be connected, and always at a high speed. This seems like it might be coming to fruition with the recent developments in the 700mhz and TV white space bands which Google and the like are trying to leverage for wide area data use. Such a network, with speeds approaching those of wired broadband, would enable future systems to be constantly connected, which directly supports my previous item.

After all of my above ranting, what would my dream system look like? Well, let's start with my iPhone. This resembles what I would call a core system. It carries with it enough storage and processing power to be useful, but is quite weak compared to that of a desktop. When I go through my day, I transition from one to the other, to another. I'm spread across several machines, and have to put a decent amount of effort in to keeping them in sync. My perfect system would be a single device, which I would carry with me. Wherever I desire to do some work, I would simply plug it in to a dock. Through the dock, the core system would access more storage, faster network connectivity, enhanced processing power, and better displays. All in all, it would be the same as using a desktop, but I would be able to pick it up and walk away with it, without having to worry about anything. When I get home, I would take the core system, and plug it in to a laptop-shaped dock, which would provide additional power, memory, processing power, and display.

Perhaps I'll see my fantasy come true as a whole some day, but for now, I'm thrilled to see many of these developments on the horizon.