I’m way behind on posts, and just about everything else. So I’m just getting ready to talk about the post Bex threw out there about security. It was a simple enough post, asking people to participate in the IOUG Oracle Security Survey. Not using any Oracle product, except for databases that I don’t really control, I wasn’t going to participate. However, there was this neat tidbit:

With easy patching, easy maintainability, stable software, and a vigilant community, security is a natural by-product.

A commenter quickly mentioned how keeping up with patches can be expensive, if for no other reason than to test and verify each application during the patch process. In my more critical deployments, we roll software updates out in releases every 6 months or so, depending on a myriad of factors. To make the cutoff for testing, the patch needs to be released 2-3 months before a release so that it can be adequately tested.

Bex replies to the comment and explains how a good patch system reflects better discipline among the development team. My experience backs this observation up. Patching a system when the development team isn’t well disciplined can lead to nightmares.

Thus, in order to achieve the the goals of secure software, its more important for developers to understand the nuances of patch management, the dangers of code branching, and the law of unintended consequences.

A few hour-long seminars on security would prevent developers from making the really stupid mistakes… however, the nasty security problems are much more subtle… and frequently you don’t notice them until your system is live.

James Chimes In

The last line immediately brings to mind thoughts by James, and I wasn’t the only one to notice.

James responded to Bex’s post. His key difference was that if software was written with security in mind to start, then the patch wouldn’t be necessary. As I’ve stated before, you can test all you want, but the wild will always find things that tests, even automated ones, failed to find. So let us just take it as granted that patches will always happen.

Bex replies and mirrors my thoughts on this almost exactly, but with better detail.

If True Then Secure Software = Microsoft?

This is the fun part. If Bex’s supposition is true, does that mean that Microsoft has secure software? Their patching system is pretty good. By default, it is proactive and it is up to the system administrators to stop the Automatic updates. If a Microsoft patch isn’t applied, then the system is either really old or the administrators have chosen not to deploy patches.

This, of course, would seem to absolve Microsoft of lots of abuse that they take on a regular basis. We all know that it isn’t that simple. The original comment on Bex’s post shows the reality of trying to patch every three months in a large company. The company in the comment put a price on security and decided it was worth the investment.

James says that patches don’t equal security (though he is in favor of easy to patch software). In his last of the string of posts, he points to the frequency of patches provided by Microsoft as being too frequent. Bex alludes to the same thing in suggesting that the vendor should limit their patches to rolled-up patches.

This begs the question, is it worse to issue a security patch as soon as you have things ready or to wait until you have a bundle of them for a quarterly release? The answer appears obvious…Patch right away. This is what Microsoft does. You can wait and run Windows Update once a month, or you can take everything as it comes down the pike. Being able to decide your own risk is a good thing.

Do you know who has the best patch system? Online gaming companies. Maybe we can learn a thing or two about security from the gaming companies.