Policy and Reality

Why do old systems lie around in the government and private sector, just waiting for Joe Hacker to come along? What about Jane, Sergey, and Wen Hacker too?

For most home users, it’s open the box and plug in the PC. Oh, yes forgot about those Mac commercials, but putting those aside, the OS we see is the OS we get. And the OS we get is often the one most users keep.

Of course, in the private sector and government you can’t just install or run machines, networks, or users in the absence of a policy framework. So systems are tested, then tested again, and so forth. The end result is usually a stamp of approval on one specific system, with a narrowly defined configuration.

A good thing because it provides everyone with a very predictable, reliable, and validated system. But what happens when a critical security patch is issued for an application or the OS? Installing the patch inherently changes the core of the system, and you are left with a system which is not the one before, and hence not validated. Validating various systems takes time, and as we all know, that translates into money. If you had to reassess a system every time a new Window patch was released, you’d never be able to test and approve a system before the next patch.

This leaves many systems out there in the government and otherwise, out of date, and vulnerable to attack. Many of these machines hold valuable data about you and I. Data about national security, financial information, and other goodies that many people would like to get their hands on. This leaves us in a tough spot; less security for more reliability. Applying the patches could cause disruptions to the system, create some unknown errors, or even introduce new security problems.

Some of these policies have clauses for security patches and some don’t. I think they should and here’s a simple way to test and apply the patches reducing any potential disruption to the system.

• An exact copy of a validated system should be available at all times.

• Critical application and OS patches should be given priority and tested on the copied validated systems. For most patches, through testing will not take much time at all.

• The patch should then be applied to the system(s) if they are proven not to cause problems in the system.

It may sound expensive or time consuming (or even obvious), but it doesn’t happen many times. Once data is stolen, it is gone forever and system that is taken offline by a script kiddie could cost millions. Testing and implementing work arounds is also costly, may lead to an overall less reliable system, and could make a system much more complicated than it needs to be.

Have you seen this situation? What are some of the methods you have seen to get patches and fixes installed on systems that are ‘policy configured’?