Cogitating & Masticating on the Patch Management Process

Today’s trends in security discussions generally revolve around emerging threats that can damage the company that we don’t know about yet or are difficult to detect.  Patching is controlling something that can damage the company from a source that we already know about.  A comprehensive patch management process will take care of one of the things that you know about so you can focus on defending yourself from threats that you don’t know about.

We are on track to have Microsoft patching running as desired (including testing patches sufficiently, distribute them in a timely fashion to local & remote clients, confirm successful install and re-boot, and report on patching compliance). There is a still an issue with patching in general. Other applications encounter vulnerabilities in their software and issue patches.  Some of these vulnerabilities are critical to patch for security, and are in software that is just as ubiquitous as Microsoft products:

  • Java
  • Adobe, with Reader, Air, and Flash
  • Google  Chrome, Mozilla Firefox and other browsers used by R&D
  • Apple  QuickTime and iTunes and other applications installed by end users that are not business applications

Because we have these products in our environment and we are not managing the patches and versions deployed just like with Microsoft software, we have un-remediated vulnerabilities.  Here are some things we should consider to control their risk:

  • Keep an up-to-date software inventory to find what is in our environment that introduce risk.  This will often reveal that there are many versions deployed of some software.
  • We need to reconsider whether all software in our environment has business need and should be allowed and supported (and then keep an up-to-date list of it).  In general if we allow it, then we should manage these installs to make sure they are properly maintained and secured.
  • Since end users can install software themselves, we need to watch our software inventory, scanning often to detect unauthorized and unpatched software.
  • In some situations, such as with development or support VMs, people try to use software that is unmanaged and unpatched and will have vulnerabilities that carry even greater risk.  Users will argue they need to test and evaluate software or maintain a legacy environment. In those cases the devices should be be “read-only” check-out for use and then reverted to the prior state and shut down so that the attack surface it decreased.
  • We need to ensure that a group is assigned the responsibility for monitoring applications for updates and their implementation in all geos.
  • Application patching should always be included in our patch compliance reporting.
  • At regular intervals (at least yearly if not quarterly) we should update our base system WIMs with the latest patches, and regularly refresh the supported versions of all deployed software, or otherwise ensure patches are applied to new machines being deployed or re-imaged.

These tips can greatly reduce the vulnerable attack surface of our environment.  There are many other less ubiquitous applications in our environment that also need to be monitored for updates, such as database systems, infrastructure components, and end-user software.  These generally get updated less frequently, but also need to be managed to reduce risks.

Advertisements

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s