Small Business Attack – Vulnerabilities and Exploits

So, by now, I am assuming that everyone around knows the importance of patching their systems when patches comes out.  However, the reasons behind the practice aren’t often clear.  It gets a bit complex, because a patch can be intended to solve a problem or add a feature.  It gets more complex because there are different sorts of problems, only some of which are security related.  For the purpose of this post, a “patch” is a small release that is intended to correct a security problem in a piece of software.

So, when these come out, there is generally a known problem in the software.  Since it can allow an attacker to do something bad (to the system, the application or the data, generally), it’s known as a “vulnerability”.  You’ll hear those of us in the industry natter on far longer than is polite about the different ways to classify these vulnerabilities and which ones are “real” and which ones aren’t.

Really, we’re part of the problem.  See, within the security industry, there is a small and vocal minority that think that patching is stupid, and that systems should be designed securely to begin with.  Secure systems should only need a patch to add new functionality, and never need one to correct a security problem.  They say that people shouldn’t patch at all, and instead should hold software vendors accountable so that their software is designed securely in the first place.  If we don’t, we’ll never get secure software.

These people are absolutely correct, and utterly wrong at the same time.

Developing secure software is very hard.  It requires that all developers understand security and have enough experience to make the proper design decisions, that project managers will support them when correcting problems causes a release date to slip.  It means lots and lots of testing.  It means better tools and much longer release cycles.

In the end, it means very slow and very expensive software.  The market doesn’t want that.  Thus, we have patches.

There is a large and mostly silent majority in the security industry that simply patch every time they become available.  They wait for the patches to be released, put them into their test systems and start running tests against them.  The often deploy the patches to production on the weekend following the update.  Thus, patches are often applied five to twelve days after they are released and cause a minimum of interruption to operations.

These people are absolutely correct, and utterly wrong at the same time.

Patches fix problems, and as we all know, problems come in different flavours and severities.  If you treat every problem the same way, you are giving some problems too much attention and, worse, some far too little.  This gets us to exploits.

The attackers have tools too.  There are tools that scan your systems looking for problems.  There are tools that automatically try to take over your system when problems are found.  There are tools that cover their traces.  These tools are updated too… with patches.

Specifically, when a patch comes out that addresses a security problem, attackers start looking at what the problem fixes, and add functionality to their tools that detect the problem and exploit it with ease.  The more urgent the patch (more severe the problem), the more quickly they work to update their tools.

This puts you, the business owner in an interesting position:

• You can’t not patch, as that would leave your business vulnerable.
• You can’t wait too long to patch, as the attackers would slip in, take over, and cover their tracks.
• You can’t patch too quickly, as that could cause problems in operations.

What are you going to do about it?