Thursday, November 7, 2013

Read Only Friday - Patch Management - our Silent "Achilles Heel"

Patch Management is held to be a key part of operational security

The drill is "keep everything up to date to handle known vulnerabilities in commonly used software". Sometimes it seems the software vendor does not have the needs of IT at heart. Why is that?

The software vendor:
  1. Responds to market conditions and targets the consumer more often than not
  2. Is constrained by marketing, budgeting and massaging the quarterly earnings reports when responding to reported vulnerabilities
  3. Companies' primary responsibility is to their shareholders, and not to the security of the user

Eliminate Admin rights for users

The other commonly spoken mantra is to eliminate admin rights for users (and administrators as well.)
This way any Malware executeables delivered via email, and some of them delivered via a browser will fail to install. UAC will prompt the user even if they do have admin rights.

Eliminating Admin rights is working well

Eliminating Admin rights is working great in my environment, but it is not a universal solution.
Some software, notably Java, can easily compromise a machine even when the user has no admin rights. Java needs to be constantly upgraded. But embedded systems and back end software often rely on specific Java versions. That means that the vulnerable version of Java can't easily be upgraded, or resides on a machine that the vendor views as an appliance (which should not be upgraded.)

Some users actually use Java, for example to look up information on many State and local Government websites. For the most part I can just uninstall it, but not everywhere.

Software companies respond to user concerns about security

There are differences in how software companies respond to user concerns about security. User concerns affect the shareholder value in a company very directly. Microsoft, to its credit, has provided an entire infrastructure to maintain patches on our MS based systems. Adobe and Oracle have provided update mechanisms in their products - but these update mechanisms are directed at users with admin rights.

Most users don't know what to do when presented with an 'update now' prompt that fails due to the lack of admin rights.

There's a Gap for smaller companies who need to patch Acrobat, Flash and Java

For businesses, the patching process for these products is complicated by the consumer driven 'update' mechanism. We simply want the products to continue working. We don't want the user to have to reconfigure the product, accept a new EULA, and be presented with options to purchase additional services simply to apply a patch.

The answer to these questions is either to manually install every patch, which is either expensive or impossible; or alternatively to repackage the executable using tools that the manufacturers provide.
Repackaging allows you to pre-select the EULA, configure any options that are available and remove weird features that confuse the user - or cause expense to the company. One of those features to remove is the prompt to update the product - because the end user can't complete the task!

In a smaller company - repackaging is out of reach due to the required technical expertise, and the constant interruptions to provide desktop support. End users can't install or update their software. And so the 'security' update feature of products like Acrobat and Java actually causes more trouble.

Chrome does everything wrong. It installs in the user context, and doesn't respect the user's lack of admin rights. But... It updates itself every time it is used, and updated Flash is baked in. Chrome is IT's problem child, Chrome is IT's "Love/Hate" relationship.

What can be done?

There should be a place where we can get tweaked versions of Acrobat Reader and Java, packaged with all the right options. As my mom would have said "For the sake of Pete!" Why should we all have to do this work independently? For open source products this might not be an issue, but for proprietary products - even 'free' software - why is there no repository of tested corporate ready packaged applications?

Sites such as IT Ninja, and Spiceworks do provide tips on how to do the packaging, and installation options for patches. Application virtualization is another way to maintain the current versions of applications.

Licensing issues are the main reason that this has not happened. Also, the software vendors may want to 'offer services' to the end user that we want hidden, Adobe might want to preserve the ability to up-sell the user. IT wants to prevent the user from buying an online PDF conversion service - when the user should just ask us for the full version of Acrobat. And then there is the 'not invented here' factor. Acrobat's packaging methods are different than Oracle's, etc. An important consideration is whether the 'golden' version of the product could be infected in the repository. Companies might not trust a user community to maintain safe patched installers for software.

A Software Repository

Here's what I want to see. Software makers and patch management vendors, for example Lumension, should work together to take a best guess at packaging corporate versions of these applications. These would be silent installs with no user intervention, that have the options set so that users can simply go about their work with no interruptions. Smaller companies can then use a patch management system to maintain the patch level of these applications without hiring someone to repackage the apps.

Patch Management - our Silent "Achilles Heel"

Patch management is a lot like running backups. Patches fail to apply, backups fail for seemingly no reason.
Unless you go digging, the failure is pretty much silent. 

As the flurry of vulnerabilities has grown exponentially it is widely acknowledged that AV is no longer keeping up, patching has to be in place as another foot of the stool. Patching is essential and it needs to occur at an increasing frequency.


No comments: