Happy New Year - How's your patches?
It's about the middle of January of 2010 and in the news, Google was hacked by unknown's from China and Google is considering a few options, including a complete pull out of China. A large search engine in China (not Google) was defaced by the Iranian cyber thugs, Adobe was appartently targeted in the same attack as Google. And in other news the new BREECH report came out from the ITRC showing that overall while breeches were lower than the year before, the number of exposed records was higher. And as I write this article, this just came across my desk:
"Hackers have stolen the login credentials for more than 8,300 customers of New York's Suffolk County National Bank after breaching its security and accessing a server that hosted its online banking system. "
source: https://www.theregister.co.uk/2010/01/12/bank_server_breached/
What does this have to do with your Joomla site? Everything. Today I am discussing patching and patch management with you. For the purpose of this article I am going to refer to my personal favorite work on patching from ProjectQuant - Measuring and Optimizing Patch Management: an Open Model. A must read in my opinion.
Occasionally, when I talk to clients about 'patching' or 'patch-management' I often get the feeling they are, well, imagining they would rather be in a dentist chair getting a root-canal, with out pain-killers. Sadly this attitude lowers their awareness and increases their vulnerability.
I read a book, some years ago, about process improvement by one of the strongest authorities in that venue. He outlined a real life example of how a medium size corporation was having trouble with employees speeding in the parking lot. Causing what they were rightfully concerned about, a safety issue. They spent countless hours in employee education, helpful tips, encouragement, out and out pleading. The speeding continued.
Someone suggested a simple solution to stop the speeding problem. They implemented the solution and the speeding problem dropped to zero overnight - the company installed large speed bumps all through out the parking lot. Anyone who has hit one of those at high speed knows the result.
What the company tried through education was admirable, but short-sighted. The people needed an incentive to NOT speed. That incentive was the speed bump.
Your incentive to patch? Google getting hacked - if it can happen to Google - well - you are easy pickings.
The real problems in my estimation with WHY people don't patch are not to different than the speeding issue. We can educate our clients, we can plead with them, we can show them stats. They still often do not patch. I see this primarily though as a bonifide education/resource/time issue.
They don't know what the patch is for, because they don't know where to find it and if they do find information - it may be late in coming. They are inundated with lots and lots and lots of information. Hence TIME becomes a problem. "I don't have time to wade through all that vulnerability information and we've never been hacked. " - ok - do you have time when your site is hacked and you have to stop your business and clean up? .. I think that's a yes.
This is why I love the ProjectQuant document. It is a real world process that can be adopted by anyone at any level.
According to the authors of the document, the steps or phases as they are called are broken down in the 3 major sections. Those sections of course break down in to various steps.
- Patch Cycle Phases
- Shielding and Workarounds
- The Deploy Through Clean Up Sub-Cycle
Each of these represents several steps.
The first section however includes identification and monitoring for patches. This is a tough one - in their research they identified these sources of information, while not a complete list, is a overwhelming amount of data:
As you can see - that is an intimidating list to keep up with. Yet - if you are serious about security and protecting sensitive data, then you have to get a plan.
I believe that security problems, are not going to stop. Information is simply too valuable, and the quantity of information grows daily. It is not like a natural resource that at some point we mine, drill it or use it till its gone. Rather it is generated exponentially daily. This information has monetary value and should be treated as if it were physical gold. It is the burden and responsibility of each of us to protect the information we produce and are in charge of by way of customers trusting us with their information.
The first major section is critical to your success. According to the ProjectQuanta document they are:
1. Identify asset types
In other words what do you have? What software on the server, what extensions, what about your desktop? what about the Apache version? You have to have a baseline.
2. Identify advisory sources
Who has the information you need? As you can see above - there are many sources! (HINT: Check this site at the end of the month for a article specifically about this).
3. Monitor for advisories
You must dedicate an employee, time or what have you to check and monitor to make sure that a security or operational or functional patch has been released and IF it matches your inventory
These three steps alone form the corner stone of your Patch Management Program.
In future articles I will be covering more of what I like out of this document, but I encourage you to read the ProjectQuant report - Its short and well worth the read.
Until next time - Stay Safe!