Apple's Java sabotage is bad IT business

Bob Lewis |
Feb. 7, 2013

Apple's handling of the Java vulnerability provides a textbook example of what not to do in a production environment

Afterward, the head of information security should be unceremoniously booted out the door or, better, out an upper-story window or, even better, installed as the head of information security at your fiercest competitor.

Whatever the identified threats, they aren't crisis-level problems, which means IT operations should respond as it does for every other proposed change to production:

Prepare an impact analysis. In this case, the impact analysis would reveal whether any business activities would immediately grind to a halt from the change that might cost the company many multiples of any Java-delivered intrusion -- or it might not. That's why change control is what it is.

Apple and the minimum standard of basic professionalismThis is also how Apple should have dealt with the problem: Give its sophisticated enterprise licensees the information they need to understand the threat and deal with it properly, in accordance with their preferred security posture.

But there's a difference. For its enterprise licensees, Microsoft provides lots of information about what's in each patch and delivers them in a form that facilitates internal regression testing, as does every other software vendor that claims to support enterprise customers. Why would they do anything else, and if they did, why would any business license their wares?

Let's make this personal just for a moment. Developers generally detest change control, considering it an annoying bureaucratic aggravation. If you're a developer who shares this attitude: You're supposed to detest it.

Here's how it works: IT operations succeeds by maintaining a stable, unchanging production environment. IT applications succeeds by changing the production environment. Ops and apps are natural enemies, and the change control process is where they meet. If apps likes the change control process, something is seriously wrong. For that matter, if ops likes the change control process, something else is seriously wrong -- it's probably so restrictive that it prevents real progress.

Now you know. And thanks to Apple, now you know what it's like when an entity responsible for keeping things running doesn't respect change control fundamentals -- the minimum standard of basic professionalism.