The practical guide to patch management
Paper trail You may have noticed how often these days IT vendors talk about “building a business case “. They want to furnish you, the IT pro, with the info to persuade sceptical business unit managers, or B.U.M.s as they are sometimes known, to buy their stuff for the good of mankind.
Let us put to one side the notion that this is perhaps something that the IT vendors should be doing themselves. More interesting is that the need to argue for sensible stuff like a proper patch management process or a web application security strategy, shows how high the stock of the penny pincher has risen – or how low the standing of the IT security pro has fallen.
And so to the Reg Library for two papers from a couple of industry heavyweights on building that business case.
Building a business case for patch management is the most crucial step to obtaining executive support, says Dell as it sets out its stall. An unpatched vulnerability can result in “loss of customer confidence, productivity and legal ramifications if not properly resolved”, the company notes. And as Dell says, the overall cost to a successfully exploited vulnerability can easily exceed the cost of patching against the vulnerability.
This paper is all about the process and the bureacracy of patch management. The company itemises the steps that should be taken to articulate the business case for patch management. It argues for the formation of a patch and vulnerability group and suggests a charter to map out the team’s responsibilities. The paper contains lots of links and practical advice on policy. A useful, if somewhat dry, guide.
“the problem of insecure software is not primarily a technological problem, it is an economic problem.” – Bruce Schneier.
The above quote, cited approvingly by HP, encapsulates the company’s challenge in building that business case for web application security. The complexity of web applications creates a larger attack surface than ever, as we examine in our upcoming webcast Jump-start your application security initiatives .
It is self-evident to us that HP is right in saying that “risks from web applications justify making a commitment to secure application development and procurement”. But this appears to be less obvious to many of the company’s prospective customers.
The paper’s main goal is to convince the reader that “excellence in application security is achieved by embedding security into the complete application development lifecycle. A security vulnerability is a software defect that should be identified during development. Incorporating security into the very beginning; from strategy, planning, design, coding, testing, and operation is a proven approach.”
Application security is also part of good corporate governance. But HP notes that security practitioners “sometimes need to be reminded of the extent to which business executives are willing to take risks as a part of corporate strategy. Risk is opportunity, and chief executive officers often are huge risk takers, for good or for bad.” Don’t we know it.
The paper runs through various business case models for application security and ends by mapping out where its technology sits within the application lifecycle. Not bad at all. ®