The following is a sample conversation that happens a lot between security personnel and other IT personnel.

Security: We noticed vulnerability X in service Y on machine Z.

IT: On machine Z? That’s no big deal – we don’t use service Y anyway, so it doesn’t really matter.

Any security person know that rather than reducing the risk, not using the service actually raises the risk presented by the vulnerability. If you don’t use it, you probably also won’t remember to patch it, review it, log it, or look at it if something goes wrong. The IT person though thinks that if they don’t use the service, no one can exploit the vulnerability because it’s not being actively used. The simple reason for this communications failure is that people who specialize in risk always define it differently than everyone else. This goes for other specialists too – medical professionals have started talking about risk management in the last few years, and people who deal with investments have been talking about it for decades. We all though conceive of it a little differently, think about it in different ways, and most importantly, we conceive of it differently than the general public, which is why we constantly have conversations like the one above.

I’ve long thought that one of the problems with the information security field is that so often we’re separated into our own IT security group within the IT department (or another department), instead of being integrated throughout an IT organization. There is a lot that could be written about this subject, but I just want to talk about one aspect here – patching.

Because software bugs are discovered, patches are necessary. Since IT security was (and still is) in its own echo chamber, we kept repeating the same mantra over and over again – patch, patch, patch. It’s one of the first pieces of advice given to people when trying to explain how to run secure systems, and time to patch is one of the leading security metrics.

The problem is it doesn’t work. People hate patching. Large organizations don’t patch. There are a variety of reasons why patches don’t get deployed – a sensitive application, lack of vendor support, lack of time, lack of money, concerns about stability, etc.. etc. Those that do patch well usually spend so much time and effort on testing and deploying patches that it takes a serious toll on other activities, whether they be security related or not. IT security though never stopped to consider the root of the problem – the consultants, conferences, industry news sources, and professionals just kept parroting the same advice over and over – patch, patch, patch. When breaches happened we could just sit back coolly and say “see? this is what happens when you don’t patch.”

If IT security had left the echo chamber we might have heard what we’re just starting to hear right now – patching is broken. Other methods are needed. Software needs to be more secure from the start. Other after the fact alternatives to patching are needed. More robust defenses need to be in place to ensure that a single buffer overflow can’t destroy your entire enterprise. As an industry we need to realize that patching just isn’t working and find other ways of ensuring robust systems.

Car manufacturers used to recommend specific intervals for various vehicle services in their owner’s manuals – 50,000 miles for this service, 55,000 for another, 60,000 for a third. What they found out was that this was too complicated – people did not bring their cars in every 5,000 miles for a unique service. Now owner’s manuals list all three services as being required at 50,000. It may not be as accurate or as efficient, but it works because it’s easier advice to follow. By simplifying the maintenance people needed to do, they got a higher rate of compliance. We, as an industry, need to do the same thing – simplify the ownership and stop relying on the owners to be perfect custodians of their investment. Or we can continue to rely on patching and smile a smug smile with every new data breach that’s recorded.

There was a brief flutter of noise around the fact that Fannie Mae discovered a logic bomb on its systems, placed there by a fired systems administrator. Logic bombs can be frightening things. Often placed by the disgruntled employees who know the systems the best, they can do significant damage. There are two main things people always recommend to defend against logic bombs, and one that they forget. The two people always point out are:

1. When firing anyone (especially a sysadmin) do not let them return to their work area until all of their access has been terminated. (Fannie Mae appeared to fail at this one).
2. Review logs and systems periodically to make sure nothing is amiss. (Fannie Mae apparently did this as another employee found the logic bomb before it did any damage).

The other factor that people often overlook is the simplest, and one you probably do already:

1. Back up your files!

If your data is backed up, it doesn’t matter if they get wiped out by a logic bomb, virus, natural disaster, hardware failure, or human error – the cost of recovery can be minimized. If the culprit wipes the OS in addition to the files, then restoration may take time as you’ll have to rebuild the OS also, but I think everyone agrees that rebuilding the OS is a far better solution than not having backups at all.

I went to a medical school graduation last night, and the keynote speaker gave a speech wherein he pointed to three things that were changing the way medicine is practiced. The first was the sequencing of the human genome, the second was the IT revolution, and the third was the fact that medicine is now being treated as a market commodity. While all are interesting, it was his comments on the first factor (the human genome) that bear some commonality with information security professionals. For millenia medicine has been a reactive science. Someone gets sick, so doctors try to find a cure. Although the human genome is clearly not the only think to bring about a change in the way medicine is practiced, it was pointed to as a major landmark in the shift of medicine from reactive to proactive. Doctors can now know ahead of time if someone is at high risk for certain conditions, and begin treatment before a patient actually exhibits symptoms. (I know this is an oversimplification, but it’s the principle that matters).

Information security has been struggling with a similar transformation for several years now. Everyone seems to realize that reactive information security is not the way to go in the long run, yet not many people can figure out how to get away from it. We’re still stuck in our test-patch-repeat mindset. Maybe we need something similar – something like the sequencing of the human genome – to shake things up.