fudsec.com

Sometimes you just have to tell it like it is.  And this week, the man that puts the "Paul" in "PaulDotCom" does precisely that.  From system administrators whining, to defense in depth, this invited guest post challenges some common assumptions and provides an actionable response.  Thanks Paul!

By Paul Asadoorian

Microsoft patch Tuesday, or "Black Tuesday" as it is referred to as, has been around for some time.  At first it seemed like a good thing, with all these patches coming out it gave people time to plan accordingly and get them installed in their environment.  I firmly believe it was a knee-jerk reaction that has plagued us since 2001-2003 when "worms" and network-based vulnerabilities were being exploited on a regular basis.  The time has come to react more quickly to the wide variety of threats posing organizations infrastructure, and have the flexibility to apply patches as they come out, not just once a month.

I remember it fondly as I worked for a University at the time patch Tuesday was being dreamed up.  It was a time in a land where XP firewalls did not exist, nobody blocked the NetBIOS ports from the Internet, and the term "automatic updates" was something that did not exist.  Machines were getting compromised faster than they could be rebuilt, in fact many became compromised WHILE they were being re-built.  At some point, someone hit Microsoft with a clue bat and they began coming out with patches, lots and lots of patches.  Before you know it systems administrators were overwhelmed with patch installations, and were not armed with the appropriate tools to handle the patches.  So they do what some systems administrators do best, they bitch.  I have to admit, when I was a systems administrator, I did my share of bitching.  Its that kind of job, somewhat thankless, so bitching came with the territory.  But in this situation, it caused Microsoft to take a step back and think about how they release patches.  Then, Patch Tuesday was born (along with exploit Wednesday).  This meant Microsoft was now holding back patches, saving them up for one release!  While I started to grow hatred for this method, systems administrators did less bitching, which makes everyone's lives easier.  Another factor that played heavily into the decision to release regular patches was desktop management.  Very large corporations with 10s of thousands of desktops incurred costs when applying patches.  Each of these desktops, and servers, needed to be rebooted in order for the patches to apply!  This adds an economic factor to the equation, meaning is costs money for organizations to apply patches.

Times have changed and its time to evolve.  The regular patch release schedule got us over a hump and got systems administrators in a grove of applying patches. However, Imagine this situation:  

There are terrible viruses running around in the real world (like ones that infect you as a person, not your computer).  Your doctor is getting the vaccinations as soon as they are available.  However, its left to your doctor to determine when they are applied.  So to make things easy for everyone, vaccinations are done on the second Tuesday of every month.  In the mean time, you and your family (are users like children?) are vulnerable to the virus, some of which can be fatal, and others that are not so bad.

You should be equally as outraged about patch Tuesday, and here are some things you can do about it:

Set your own patch schedule

This is something I have been preaching for some time.  As an organization you need to evaluate the threats against your business, and prioritize the defensive measures you implement (if any).  You should not have to wait for an third party to release patches, they should be applied according to your own priorities.  Security is about evaluating risk and I can assure you that you can do a better job than Microsoft of evaluating risk for your organization.  

Define your own threat level

The other aspect of security that Microsoft believes they have covered for you is determining the criticality of each bulletin (which can contain multiple vulnerabilities, which doesn't help!).  What is deemed "critical" by Microsoft may not be as critical to your organization.  Evaluate each vulnerability, not just the bulletin, and think about the impact it has on YOUR organization, not the rest of Microsoft's customers.  Home users, small businesses, governments, health care, universities, they all use Microsoft products in some capacity, do they all treat threats the same way?  Hell no, and neither should you.  Define what "critical" means to your business, and that means reading each of the security bulletins when they are released, in detail.  So, on the second Tuesday of every month, get a bigger cup of coffee, sit down, relax, and enjoy the ride.

Conclusion

Dumb Questions: Is it "wormable"? Is there "public exploit" code available?

The real question you should be asking: "How does this impact our business?".  

Lets get one thing clear, evil bad guys have exploits.  They have exploits for stuff we don't know about yet.  When a patch is released, its too late. Shortly after a patch is released, its really too late.  So patching needs to be built right into your operations and balanced with your business plan.  Don't get caught up in the hype around "remote exploits", "wormable", and all that crap, take matters into your own hands, at least as much as Microsoft lets us. The game is risk mitigation, not patching.  But we can't rely on MS to provide reasonable, workable, mitigants to many of their bugs based on track record.

Loading mentions Retweet