Tuesday, December 30, 2014

My 2014 Year in Review

So after a really crazy year, I felt like it would be good for me to look back and recap what I took out of 2014, if only for myself.  Here's my themes and lessons:

1. Open Source is not an excuse for bad security:

I took on a few Linux projects in 2014 and saw quite a few servers not behind an IPS because they were running IPtables.  No one took the threat seriously because open source software was trusted and seen as secure.  Heartbleed and Shellshock changed that, and I for one am glad it did.  There's no longer an argument that open source can be trusted implicitly, and i talked several customers into putting a WAF in front of these boxes and setting up rules and IPS properly because of these large scale vulnerabilities.

2. Patching is not the only game in town:

Waiting for a patch, and then applying that patch is slow and tedious.  Mitigating risks quickly is what my employer is paid to do, and we have to go above and beyond with different approaches to emerging threats.  This leads me to:

3. Think outside the box, and use the tools you have:

When CryptoWall was spreading through ad networks, we used content filtering to block those ad networks instead of waiting for our AV vendor to put out a definition. Content filtering is not made for this role, but it did work well and we avoided CryptoWall almost entirely.

4. Not all threats require action:

We found that Poodle wasn't a big deal for our environments.  Once I understood the threat vector and how it was being exploited, I found that the fix for the issue was not worth the huge disruption in service that the implementation would require.  There were very few systems actually negotiating SSLv3 sessions, and those that were could usually be shut down.  The short version is, I no longer accept a threat with a high CVSS score as requiring a patch until I run it through my threat modeling regimen.  It's not easy, it's not simple, and it's not perfect.  What it has become is a way of communicating quickly what systems could be affected and the business case/ impact around the vulnerability.

5. Knowing your systems is the best way to protect your systems:

Know what you have and you'll easily figure out how to protect it.  We use a monitoring and management tool built for MSP's that quickly lets me build reports based on installed software or patch status or whatever you might want to know.  This is a key to my threat modeling system I am building, and I will tell you that I have found quite a few packages that didn't need to be there and could be removed, including a Joomla site that had been compromised and only served as a link to a file share. The rest of it gets built into my database of implemented technologies so I can search quickly when a certain package or protocol is found to be vulnerable.  Inventories are really great, but great inventories are really important.

What was your biggest takeaway from 2014?