With the recent headlines, we've seen heartbleed (which was not exclusive to Linux, but was predominately there), an IE zero day that had folks over-reacting with headlines of "stop using IE", but Firefox and Safari vulnerabilities where not that far back in the news either.

So what is "safe"?  And as an System Administrator or CSO  what should you be doing to protect your organization?

It's great to say "Defense in Depth" and "The 20 Critical Controls", but that's easy to say and not so easy to do when you are faced with a zero day in the browser that your business application must have to run.  What can you do that's quick and easy, that offers some concrete protection for your community of 20, 200, 2,000 or 20,000 workstations?

I'm starting a list here, but this is by no means a well-researched, exhaustive and complete list, just a starting point:
Inventory your hosts and the software that you run.  Know your network, and know what's running on your servers and workstations.  (if this sounds like another way of saying "read the 20 controls, start implementing at #1 and work your way down the list", then you get my point).  After you inventory, read the list.  Expect a story on this in the next week or so.

Deploy EMET.  In the hype of "don't run IE" headlines, many of the folks who recommended this missed the fact that if you installed EMET, you were nicely protected against last week's 0-day.  Expect a story on this later today (yes, I'm on a bit of a tear).

Read your logs.  In every incident that I've worked, there's been *some* indication of the attack or compromise in logs somewhere - this is why you log after all.  This also holds true for system crashes and problems of any kind.  Troubleshooting always starts with your logs, but if you monitor logs for unusual things, you can expect less trouble to troubleshoot, because you'll see it before it gets to be a problem.  If there are too many logs (yes, log volumes are insane), deploy a tool (there are tons of free ones) that will help you with this.  ELSA (https://code.google.com/p/enterprise-log-search-and-archive/) is a decent starting point for log consolidation and prioritizing, but it's by no means the only solution - find what works for you and use it.

Control your network perimeter (if you can define a perimeter).  Put an egress filter that allows what you need, then has a deny any/any/log statement at the bottom.  The "log" part makes it simpler to add new list entries to satisfy new business requirements as they come up.

Also at your perimeter, have the ability to block some of the "problem" applictions when you know that things have gone particularly bad.  For instance, if there is a Flash zero-day, there's no shame in sending a note to your users to say "we have to block flash at the firewall for a few days until there's a fix".  Ditto that for ActiveX, Java, PDF files and whatever else you'd care to add to the list.  

Many of these settings are simple tick-boxes at the firewall, some are IPS signatures or some might need a proxy or web content filter product.  The key to all of these is to be prepared, know where the knobs are that you need to tweak, and know what you can and can't do both technically and within your organization.  If you're caught by surprise and put a "fix" together in a hurry, document what you did so you can re-use that next time, or improve it when you have an hour to spare.

Talk to your users.  Keep a steady flow of communication going, let them know what's going on.  Call this "Security Awareness Training" if that scores you points, but the object of the game is to keep your user community in the loop - the more they know about what they should do or not do (and why), the fewer problems will come your way from that direction.  Also, the more that IT and the Security Team is seen as helping and advising (in a good way), the more slack they'll cut you when you need it - for instance when you need to block Flash, PDF files or their favourite website for a day or three.

We've been saying this for years, but I still have clients who say "we trust our people, why would we do any of that".  My answer remains "so you trust their malware too?".

I'd invite you, our readers to add to this list in the comments.  This is meant as just a starting point - what have I missed?  What has worked for you?

===============
Rob VandenBrink
Metafore