Tag Archives: Faulty Patch Management

Jun
22
2012

K1000 Kloser Look: Testing Patches before deployment

Testing patchesK1000 Patch management report before deploying them to all of your production machines can be a tedious task that few want to do, but it is a crucial part of keeping your network as secure and bug free as possible. While no company releases patches to break their product it does happen from time to time. There are several methods for testing patches; one method requires you to look at each individual patch and approve it for deployment after careful research, another method is to have a test group of computers that get deployed patches before the rest of your environment does.

The first method is fairly straight forward, what you will want to do is have a manual patch label, created under “Label Management”. This manual label can have patches manually added to it on the Patch Listing page, the Patch Listing is located under the Security Tab. This will show you all available patches that you can choose from to add to this label. What you do next is simply click the check box to the far left of the appropriate patch(es), then click the Choose Action drop down box and select Apply Label and viola your label is now updated. This allows you to have a great degree of control over what patches are applied to the machines in your environment.

The second method is a bit more hands off, for those that don’t have the time to go through all the patches one by one you can set up a patch smart label for testing and another for production machine deployment. The way this works is you create a Patch smart label, targeting the appropriate patches you wish to deploy for testing. Next you create another patch label with the same criteria with one extra item, select “Release Date” “>” “DATE_SUB(now(), INTERVAL 30 DAY)” and create the label, name it ex. OS Patches Greater than 30 days Old. Next you will need to edit this label, to go the Home – > Label – > Smart Labels and select the label you just created by clicking on it. Once you’ve clicked on it, locate the ’DATE_SUB(now(), INTERVAL 30 DAY)’) and remove the quotation marks before Date and between the last to parenthesis. This greater than 30 days old will be your production patches because it will allow you to deploy the first label that includes all patches regardless of age to a test group of machines and if there is an issue you can catch it before it goes company wide. What you can now do is take the standard label and deploy it to a group of computers in various departments for testing (or use a labels that includes your standard testing machines), if your other deployment labels are also including a variation of this for GREATER than 30 days- your automated testing of the patches has 30 days before it goes live for deployment to the rest of your network, so you have 30 days to catch any issues that are caused by a particular patch. Adjust INTERVAL 30 DAY to INTERVAL 10 DAY or any other number that you wish to set your release cycle to.

These are just two methods of testing patches before they are deployed to your environment, they vary in the amount of automation for the deployment and both offer better flexibility and security than just simply deploying patches and hoping for the best.  In many environments we see that “testing” amounts to deploying the patches to the IT staff to see if it breaks anything. If not, it just rolls out to the rest of the world. The challenge with that and similar methods is that you’ve forgotten that you use your machines differently than the end users; if I update office and open Word and Excel and say it’s all good, then roll it out to a group of Publisher and Access users and there’s an important feature that’s broken… we might well create more work for ourselves to undo the patch, and worse- we’ve impacted the users. Testing across multiple departments and business functions is ideal if possible. Many companies are taking a tiered approach based on our Label automation noted above- IT First for 1-3 days, Testing Label including various hardware types/OSes/Departments/Etc. for 10-14 days, then all deployed machines within 30 days.

Posted in New Posts | Tagged , , , , , | Comments Off
May
24
2011

Faulty Patch Management a Winning Bet for a Security Breach

Comptuer wrapped up in yellow hazard tapeHey you. Yup you, the IT admin who’s running around trying to frantically deploy Windows 7, while trying to take care of that printer that dropped off the network and recovering those systems that crashed, all while trying to help that one idiot who keeps forgetting their password. Got all of your endpoints patched correctly? Want to bet on it? Yeah, I know you just  finished pushing all 64 patches that Microsoft released last month (or are just about to); but, I’m going to put my money on the fact that all of your endpoints still aren’t patched correctly. Why so smug and confident in my position? Well, I’m a numbers gal, and numbers don’t lie.

Because I’m not a thug and don’t feel like suckerin’ you out of your money, I’m going to share some of the patching deet’s:

  • Most organizations today take at least twice as long to patch third-party application vulnerabilities than patching operating system vulnerabilities.
  • Vulnerabilities in software commonly found on PCs shot up 71% between 2009 and 2010.
  • Most vulnerabilities in software, were due to problems in third-party applications rather than in the Windows OS or Microsoft apps.
  • 98% of Windows machines have at least one un-patched application.
  • There are at least 2.7 billion un-patched applications running on machines within the U.S. alone.

So, are you still willing to make that bet?

Let’s face it, current methods of securing systems still lag behind a hacker’s ability to find vulnerabilities, and even though almost every organization has some sort of security method in place, there are still huge security breaches happening. Just take a look at the Sony PlayStation megabreach, Conde Nast’s $8 million dollar payout, the recent discovery of a DIY Crimeware tool kit that specifically targets Macs, and a new Fake AV called Mac Defender that specifically targets Mac OSX.

Most organizations still focus on patching their OS’s first, and rely on free tools to cobble together some type of patch management solution. The reality is these free patching tools just can’t cut it. They can’t effectively handle patching the multitude of third-party applications sitting on all of your endpoints. And need I remind you that most vulnerabilities are due to third-party apps?

The frontlines of security breaches are happening at the patch management level and the free tools out there suck at handling third-party patches, but worst of all, free patch management tools can end up costing you more. Face it, you need a better patch management solution.

Get your security solution together, stop trying to piecemeal your tools, because you know you don’t have the time, and they’re not working together as well as you’d like. Get a plan together for a solid security strategy; pick up a few of our tips and tricks for building your security strategy.

Posted in New Posts | Tagged , , , | Comments Off