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.
Continue reading →