Platt Perspective on Business and Technology

Security policy and the potential for conflicts of interest: a software provider perspective – 1

Posted in strategy and planning by Timothy Platt on May 16, 2011

This is a posting about security, and about due diligence and risk remediation. But perhaps more than that, this is a posting about running a business on autopilot, which is precisely what is happening when crucial operational processes and the decisions behind them are simply carried out by momentum. And I start this by discussing Microsoft’s Patch Tuesday and what I would more generally call the Patch Tuesday Effect.

Patch Tuesday generally takes place on the second Tuesday of the month, and this is a regularly scheduled day in which software patches and other incremental updates are released for public use. This standardized-release scheduling approach was first instituted at Microsoft when Windows 98 was released and began going through post-release testing and updates, and they have used this same approach and the same standardized Tuesday release dates for a great many other products as well.

This type of approach arguably makes a great deal of sense. After all, patch development and release and distribution need to be coordinated with all of the steps involved covered and in the right order and in the right way. Standardizing make this process a lot more reliable, and it makes for a more cost-effective set of operational processes for doing so. The people who have to be involved in this know when and where they have to do what, and by when. An ongoing theme in this blog, and certainly for business strategy and operations postings has been about moving past the one-off and ad hoc to create reliable, replicable efficiencies and this certainly looks to fit that pattern.

But some patches are security patches, and are intended to resolve risk vulnerabilities that have been discovered in the current and up to date releases of software already on client computers and networks. And sometimes the vulnerabilities that these patches would address are very significant.

A zero day attack is an attempt to exploit a software vulnerability that is so new that the software developers involved have not had time to develop a patch for it yet, and it may in fact be so new that these software developers do not even know of the underlying vulnerability yet either. Every software developer should have a goal of identifying potential vulnerabilities in their software, and if not in their alpha testing, then in their pre-release beta testing. But no matter how diligently software testing is conducted, some vulnerabilities will leak through and particularly for very complex software that functionally connects widely in a complex software and hardware environment. That means zero day attacks will happen and post-release follow through has to include response mechanisms for that if it is to be effective, and if it is to actively support the end user customer and offer them value.

When patches simply address standard usage issues, this is not as much a problem, but when security vulnerabilities and risk management issues enter in, the scheduled delayed release of patches can be anything but benign.

Microsoft in fact does seek to pre-release crucial security patches rather than waiting for that special one Tuesday of the month. But short term and internally facing decision making with an eye to operational efficiencies alone, and without careful consideration of the customer and their needs can lead to real problems. Microsoft is definitely not the only business to use a Patch Tuesday approach, and not every business makes the crucial distinctions as to which patches can wait for a scheduled release date and which ones cannot.

I will add that the Patch Tuesday Effect is not limited to software alone. Basically, the same effect, with the same capability for allowing ongoing risk management vulnerabilities can happen in any of a very wide range of contexts and settings. All you need is a system that allows for and perhaps even encourages scheduled delays and regardless of potential risks involved from that. And you can most easily achieve that by separating scheduling decisions from analysis and understanding of what is to be done on that schedule, and the risks for delaying and to whom. Just make scheduling and prioritization decisions in a vacuum and it is guaranteed that a Patch Tuesday Effect will flourish in your organization.

I am going to follow up on this posting with a second installment that will look into some of the issues of scheduling and prioritizing more effectively, and with a more fully managed and reduced risk liability.

You can find a range of operational and strategy postings at Business Strategy and Operations.

Tagged with:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: