- Trends in Malware
- Where Are Your Bottlenecks?
- What Can You Do to Streamline the Process?
- Bottom Line
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
What Can You Do to Streamline the Process?
It's apparent from the previous paragraphs that testing and deploying patches can take up to several weeks. Unfortunately, with today's threat environment that's simply too long. Let's discuss what you can do to speed things up.
Bypass Lab Testing
Now I know many of you are already asking "Is this guy crazy?" No, I'm not. Seriously, when is the last time you had a patch cause you any serious problems? For most of us, we've had one or two problems over the last several years.
Most flawed patches are discovered with the first 24–48 hours of distribution. So consider skipping the lab testing and watch the security boards and your vendor websites for updates instead.
This may not be possible in some organizations. Perhaps your system is simply too critical to suffer any potential downtime, or perhaps your system owner is just paranoid.
If you can't completely skip testing, do you have other options? If you have a test lab and a production prototype, why not just skip the test lab? Phase the patches in, just the way you plan to do in production.
Streamline the CCB Process
If you can streamline the CCB process you will likely save a few days on the overall process. First, take a look at everyone involved in the review—are they all necessary for the patch process? Trim the list where possible.
Next, consider hand-walking the change request to each of the key people. Take 15 minutes with each, discuss their concerns, and move on to the next. The process may not always be this simple, but it's bound to save a lot of time in the long run.
Consider Multiple Patch Distribution Points
You've cleared the previous hurdles, but you still have hundreds of systems to patch. You're not really trying to do this with only one patch server, are you?
Consider the investment in additional infrastructure. Look at your architecture and determine how best to implement multiple patch distribution points. Should you do a tiered approach, or would a logical/functional breakdown work better? Perhaps you need to patch based on physical location, or available bandwidth. There's got to be a better way!