Creating An Enterprise Workstation Patch Policy that Works

A critical component of endpoint management, as a service, must include remediation of workstation vulnerabilities to security threats. Threats to the environment include virii, worms, and open access points to network and company information.

Regular, consistent patching of the enterprise workstation environment must become an organizational practice to therefore prevent such threats.

Patch Management as a Service

Maslow pontificated in his "Hierarchy of Human Needs" there are certain foundational needs we as humans need to meet before we can "graduate" to higher social function. As parts of service providing organizations, we Altiris administrators also have a hierarchy of similar design. The focus of our hierarchy must first be a focus on the company, and protecting the data, infrastructure, and internetworks that support day to day operations.

Our second focus of priority must be the personnel who look to our organization to keep them safe while minimizing the disruptions we make to their daily work life in the delivery of vulnerability protection. This responsibility is unique, because alongside members of our department, we share it. They, too, must ensure the specialized products and services they provide to personnel remain largely unaffected by our activities.

Our third and final priority must therefore point to our department. Our responsibility in this space includes creating and providing a test environment, clearly providing adequate testing timeframes, and communicating with necessary stakeholders regularly of our planned or unplanned activities.

This document intends to clearly define and establish the types of regular monthly services and activities we as leaders in our respective service-providing organizations must deliver to satisfy all areas of priority identified above.

When We Patch - Two Points of Intervention

If our aim is to deliver patches reliably to the enterprise with minimal disruption, then when should we deploy patches?

After spending time discussing the myriad of options and reviewing existing organizational SOPs, the team assigned to make those decisions should come away with AT LEAST the following two critical points of intervention:

A. Monthly - Monthly patching is defined as the release of critical or necessary Microsoft operating system and Office patches provided by Microsoft on the second Tuesday of each month.

B. Daily - At a specified every day, if the system detects any vulnerabilities to newly installed software with previously approved patches in the environment, a machine will be patched. This policy is helpful for users who may have been out of the office, on leave, or not well-connected to the network infrastructure.

Patching Consideration Calendar Dates of Note

Second Tuesday of the Month: On the second Tuesday of the month, Microsoft releases desktop patches to the Windows Server and Workstation operating systems.

Patch Pilot Thursday (Thursday following Patch Tuesday): 48 hours after the patches are released by Microsoft, patches are guaranteed to be made available in ALL languages in the Altiris infrastructure for staging and deployment. English only patches are available 24 hours after release.

The following tasks might then performed on this day, given the following criteria and definitions:

A. Application Testing Workstations - Workstations for the exclusive purpose of testing an application should be provided or made available to application owners within the business, provided the following criteria are met:

• Testing Script - The application tester has provided to your team a document detailing the specific steps taken for patch testing to their application. We have them complete this documentation for the following purposes:
     i. It assures the application owner that the designee performing the test meets the required criteria for the application.
     ii. It provides the application owner greater flexibility in handing off the task to different members of the application ownership team.
     iii. It limits hardware provisioning to those teams that require detailed testing.
     iv. It helps gauge testing time requirements in the event of an unscheduled update event.
     v. It's a written record of the testing being completed; with appropriate sign-offs at each level.
• Client Configuration - The workstation must be maintained exclusively for the patch testing purpose. No reconfiguration, changes, or deviations from standard user/client application build can or should be permitted. Remember the purpose of the hardware: To test real world impact on applications needed to run the business.
• Patch Updates - The workstations will be placed in a group or collection to receive the patches on the Thursday immediately following Patch Tuesday, at a time convenient for all. This will provide the application owners one full business week to test their application against the patches. If you can shorten that window, it is recommended.

NOTE: Extending past a week begins to negate the value-add of performing the update every month. Don't plan monthly patches unless you can keep a consistent process in place.

Patches then, given the above scenario, will be deployed to your enterprise on the third Thursday of the month.

B. Production Patch 'Piloteers' - Select individuals within the organization, preferably within IT and other business organizations can and likely should be part of the first Thursday group. You won't get a clear picture of overall anomaly impact with smaller testing groups.

One Week from Patch Pilot Thursday: Provided no issues are reported, or reported issues are resolved, a full business week following Patch Pilot Thursday, all enterprise workstations would receive the month's patches.

Reporting: An automated report should be delivered to users requesting it, an analysis of your vulnerability as an organization on the Thursday following Patch Deployment. A second report, given the scenario, with updated information might be provided one week later. The report should also be made available on the outward facing portal for internal customers.

Conclusion:

By setting a monthly process in place, you and your end points can be protected and secure.

In my next article in this series, we'll cover server patching.