istock-657359998.jpg

Image: iStock/bowie15

In a recent article, I covered 7 tips for effectively rolling out emergency patches. Those tips covered best practices on the technical side of patch deployment, but there is another side to the coin: ensuring user compliance. Unlike computers, humans have an array of different behaviors and motivations, and can be much less predictable (and harder to motivate).

When you work in IT, you have to maintain a delicate balance between protecting the business and ensuring customer satisfaction. It’s understandable that people might be concerned about the the negative consequences of poor patch deployment, such as when updates cripple software or create unwanted changes. And the number one thing you’ll likely need your users to do when it comes to patching? Reboot. Nobody likes to reboot. Everyone is always too busy to reboot.

User fatigue can also be a factor; it seems there is always another critical update around the corner and repeatedly deploying urgent patches which can cause work interruptions can result in IT being seen as a bunch of Chicken Littles, forever proclaiming threats that never materialize. Being taken seriously is a key element to patching success.

It’s important to build a sense of community effort when it comes to distributing patches. IT staff should be well aware of their objectives and, in an ideal scenario, users should be equally committed to the same goals. With that in mind, here are five tips to help facilitate the compliance process.

1. Announce patch releases in advance

Announce the patch release in advance via email, company blogs, or other communication methods. Do so at least 24 hours beforehand if possible. Even if the patch is so urgent that a same-day release is necessary, give as much advance notice as possible so users aren’t blindsided with unexpected prompts – or worse, forced reboots out the blue.

Make sure to include an explanation of the threat motivating this patch; what can happen if the patch is not applied, how the patch fixes this problem and why it is critical for systems to receive this update. This provides subjective context which will help increase user participation and responsiveness.

Communicate any requirements that may be involved, such as remotely connecting to the company network to receive the patch, responding to a software update prompt (though ideally critical patches should be installed without requiring user intervention), rebooting the device when notified and so forth. Make sure to include any potential “side effects” if known.

SEE: IT email templates: Upcoming software release (Tech Pro Research)

2. Figure out the reboot challenge

If users don’t want to stop browsing Facebook to reboot their machines, that’s a reluctance which is hard to take seriously or show much sympathy for. However, if they’re cranking out work to meet an urgent deadline, it should be a reasonable request on their part to ask for a delay before installing a patch or rebooting a system.

Work out a policy to address these concerns as needed. You could have them conduct the process manually near the end of the day, or (depending on your patching infrastructure and software) schedule automatic patch updates/reboots for a more convenient time. It may also be possible implement “grace periods” that allow a user to postpone rebooting a set number of times or until a certain date.

If all else fails, you might also consider mandated automated system reboots after a certain period of time with a shutdown window of, for instance, 15 minutes during which the user will have the opportunity to save open files. Avoid simply rebooting systems without user awareness, however, since there will be resulting flak if critical work is lost. Look into ways to autosave files such as in Word or Excel, if possible, so as to reduce the frequency and impact of this problem.

SEE: Security awareness and training policy (Tech Pro Research)

3. Provide incentives

As the saying goes, you can catch more flies with honey than with vinegar. Providing incentives for patching compliance can greatly assist your cause.

If you can sweeten the deal by convincing management to implement a reward system for departmental compliance with patching efforts, that will be far more effective than punishing employees for non-compliance. It doesn’t have to involve big investments, but perhaps some measure of comp time, a round of golf, coffee and doughnuts or even a couple of pizzas might help grease the skids. The same principle applies to IT staff who stay late or work after hours; reward them as well to keep them motivated otherwise patching burnout can become a problem.

However, when it comes to offering rewards, don’t be patronizing or treat the effort like a high school rally (Hint: balloons and streamers for the winners are probably a no-no, along with goofy t-shirts.) or the effort will backfire and earn contempt rather than cooperation.

4. Follow up with users

User reluctance or ignorance of requested compliance efforts may be a factor when patches fail to deploy. If a user is on vacation and hasn’t booted their laptop in a week, cut them some slack (the device is off, after all, and thus not vulnerable at present). If they’ve been too busy or haven’t even checked e-mail for a while, that’s another thing, however.

Track which systems meet patching requirements and contact the users associated with unpatched systems/devices to remind them of their responsibilities. If sending out email announcements, send these only to non-compliant users and make sure to use the blind carbon copy option to notify them, or email them individually. You want to avoid pointing fingers or publicly shaming these users since it may send the message they’re irresponsible or in trouble. Don’t copy their managers in the email (yet) since that sends a negative message of threatening repercussions.

If users are worried their system won’t come back up post-reboot, takes too long to start up, or have some other technical concern, see if you can address the root cause of their reluctance so they have confidence in the technology they’re using. However, if someone is unwilling to reboot their machine because they just don’t feel like it, or they actively blocked the patch to avoid the rigmarole involved this should be addressed and remediated.

SEE: Guidelines for building security policies (Tech Pro Research)

5. Get manager buy-in

Where possible, ensure managers are on board with your plans and can assist with encouraging their employees to comply with patch releases. This will prove more effective than generic emails from the IT department. Make sure managers understand the business benefits to these patching endeavors as well as the risks of non-compliance. See if they can also assist with tasks such as updating/rebooting vacationing employee systems or devices to help improve results.

If worse comes to worst and employees refuse to comply with patching requirements, you should communicate the situation to their managers and ask them to step in. However, make sure to follow the previous step and engage users directly first before resorting to this; you don’t want to be seen as the bad guy who tattles on employees.

Also see:



Source link