Platt Perspective on Business and Technology

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

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

This is my second installment in a series on security policy and on finding a balance between standardized processes, and ad hoc one-offs. I focused on what I call the Patch Tuesday Effect in Part 1 and I left that with a significant open issue that I will turn to here in this posting.

• What are the core best practices that can be used to determine which updates and patches can and should be scheduled according to standardized processes and fixed release dates, and
• Which updates and patches require special processing and release? And for these special case exceptions, what are the best ways to manage and release them?

Any response to these questions has to begin with some fundamental points:

• It is vitally important that you understand the risk remediation issues and challenges that your software customers face, and certainly where they might arise in whole or significant part from installation, distribution or use of your software products.
• In this, their risk liabilities are your risk liabilities too.
• And it has to be noted in this context, that user agreements that have to be clicked to, in order to complete a software download my be written so as to limit or even attempt to eliminate liability to the software provider, and regardless of consequences accruing to the downloader or their business or organization. But there is plenty of precedent in case law in the courts for this protection to prove illusory. Most people do not even try reading these documents before filling a check box that they have agreed to the terms included, and clicking to continue. Most of these documents are poorly written, and unclear and even if they are very well written, they are often not upheld in the event of legal challenge.
• So to repeat my second bullet point, your customers’ risk liabilities are your risk liabilities too, or they are at least, with sufficient likelihood so that prudence would dictate you always assume they are.

Microsoft makes an effort to identify and early-release significant security patches rather than waiting for that second Tuesday of the month, and its standard scheduled release dates. Quite simply, doing otherwise can create significant enough risk to outweigh any cost savings that might be seen from simply following procedure.

My initial plan at this point was to outline some of the factors that would go into making this type of determination and I will at least touch on that here with some questions.

• What does it cost to simply bundle one more patch into a scheduled release, with much of the expenses for that in effect already covered by any less pressing patches and updates already planned for scheduled release?
• What would be the cost of taking all of those steps separately and without being able to amortize them across a group of same-release date updates?
• What types and levels of additional expense might a customer face if they did not receive this patch and install it, that would be prevented with it? And what is the likelihood of that event happening. Here, costs calculated would be determined by estimated cost per instance valuations, multiplied by probability of occurrence, so even a rare event might calculate out to be costly if it is sufficiently costly when it does occur. And even relatively low cost per-incident outcomes may become costly if they are significantly likely to occur.

But a lot more potential cost liabilities enter in here, as a publicized security breach in a company’s software products can have very deleterious effects on that company’s name and reputation and on its market share. A problematical software product released before a significant security flaw in it is addressed, coupled with a delayed security patch release after the problem is identified would constitute a marketing nightmare. And I add this is precisely the situation where the company offering that software would be least likely to be able to hide behind what could frequently be called boiler plate user agreement copy.

As a final note here, I have written this posting largely in terms of software companies and the risk liabilities they face. But much of what I have been writing about here applies outside of that business category too. Most of the above applies to businesses that do not primarily produce and distribute software and in fact they may find themselves facing the greatest challenges here. That is because they are the ones that would be less likely to have effective due diligence and risk remediation processes in place here, or even be aware of these potential problem areas.

I have written about apps and their distribution as an emerging category of tools for better connecting to the marketplace and for creating and capturing market share. If that new app download creates a security breach of consequence to its users most all of the above applies regardless of what marketplace that providing company works in, or what its for-profit products and services are.

I have not written this posting to argue against software releases or apps and app releases. I am writing this to argue the case for a more fully reasoned process and suite of processes for managing them, their production, testing and distribution, plus any follow-through after that. And my goal in Part 1 to this series and this follow-up posting is to help you build tools for better understanding and managing this type of risk.

Tagged with:

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: