how a cso can make life harder for an attacker

Really diggin’ an article by Drazen Drazic where he goes over 14 things a CSO (read: IT security) can do to make an attacker’s life harder. What’s nice is this list goes beyond the typical (yet effective!) suggestions like just patch systems. In normal fashion, I’ll summarize and react to the bullet points.

1. Avoid password re-use for admins. Duh!

2. Run something that detects new hardware on your network. – Oh my god, absolutely! This isn’t usually as easy to do as it sounds and doesn’t easily fall under the “can-we-buy-a-box-or-tool-turn-it-on-and-it’ll-protect-us-this-way” category that CSOs too often fall into. But the value in this is really phenomenal. Know what’s normal on your network and know when something strange and new pops up.

3. Monitor your internal network to detect weird behavior and unexpected requests. – This bullet point is like a 3-punch combo and should be printed out and taped to walls. I love this: “Your Network Admins…should be allowed and supported with time and resources to monitor logs of the systems they manage.” And this: “Outsourced perimeter management providers don’t care. Their SLA’s claim that they do, but they don’t…” This item also mentions monitoring traffic, which is also invaluable.

I should break here and say two of these items are orgasmically valuable, but they’re also not things that CSOs like. You don’t just buy a box or tool to do it. You don’t just hire more staff (you need staff who know their shit). You don’t just make a project, task someone to scope it out, and then start, progress, and end it with a stamp of success. There’s no end to it. That takes effort to justify to businesses and accounting. Oh wait, that’s basically the point of a CSO. If you want security, you have to spend the manhours and you have to make it an intrinsic cultural goal.

4. Monitor external DNS to detect new website/hostname exposed on Internet by your company. – Whoa, this is new, and I’m not even sure how to interpret this. I think this gets down to knowing what has been published by your domain team to our external DNS and/or what has been exposed by your firewall/perimeter team. You don’t ever want to not know that your dev/test server has had its balls hanging out in the digital breeze of the Internets on accident. For websites, this might be an indication that your web server is hosting sites you didn’t know about, perhaps.

5. Let your System/Network Admins use their magic. – I completely agree that you need to let your talented admins leverage their talent. But there’s a few gotchas. First, not all admins give a rip about security or know jack shit about it or what questions they should be answering. You really need your security folks to also be admin folks, or vice versa. Second, scripting and rolling your own stuff is fine, but that usually has drawbacks such as easy and useful reporting, performance, scalability, feature creep, and limited support outside the people who built the internal tools. Keep in mind that not every system/network admin has the chops (or desire) to dive deep into scripting or even real coding.

I should also break here and say that I still think it is valuable to let talented staff do their thing, even if it means if they leave, their thing is going to go to waste. If you bring in a painter to paint your house, he’ll use his tools and equipment and experience and preferences to do his work. If he leaves halfway into the job, you won’t expect the replacement painter to adopt the exact same project plan, preferences, and tools as your last guy. You let them do the job they do in the way they do it, even if it means starting over.

6. Win small fights – one at a time – Even down-in-the-trenches guys like me need to adhere to this. We can’t get our way on everything, but we do need to make progress whenever we can, so we pick our battles and win the ones we can while noting future challenges we can tackle later.

7. Save the money to hire people with skills instead of getting magic boxes that do little or nothing. – It all comes back to people. Enterprise, especially IT, tends to hate this (or at least be bad at swallowing this pill). At least in my experience.

8. Use open source. – I can agree and disagree with this item, but really the point still gets back to letting staff use their talents, and I agree a talented staffer can probably be more valuable wielding small, more surgical open source tools than unwieldy big-box suites or tools that suck away time and don’t give quite as much value back. Honestly, I think blending tools/appliances from the traditional commercial space along with open source/DIY tools is a solid way to go.

9. Go to real hacking conferences. – Absolutely. This is the “training” security-minded talent yearns for.

10. As a CSO, you MUST be involved with all “critical” projects. – This is a bit political for my taste, but I agree, ultimately. Even from an operations standpoint, it sucks goat balls to be surprised at the final hour of a major project with tasks and requirements you need to meet for their project to work. Security is even lower on that totem pole of information-sharing and inclusion… Ideally, if you run an absolutely tight ship with regards to many of the above bullet points and beyond, I’d almost hope that security is so tight, anything new needs to go through security or at least be noticed by security in quick order. I like to think of security like good ol’ bumper bowling for the kids, where security are the bumper pads placed into the lane gutters that keep the ball rolling toward the pins. If security is tight, people aren’t going to accidentally find themselves throwing gutter balls and upsetting the order of things.

11. Rub shoulders with those in the trenches. – Absolutely, for the most part. I’ve always said if you want to know a company’s security posture, you just have to ask the admins and desktop support persons. They know the score more than any manager or C-level.

12. It takes time. – Yup!

13. Find a blend of talented people for various roles. – I absolutely love this item as well. There really isn’t a security person around who can talk toe-to-toe with the Unix team, the Windows team, the networking team, the virtual team, the web dev team, the software team, the mobile team, and then desktop team at the same time. Assuming the “security guy” can answer every single question is setting him up for failure and loss of credibility. Find the security allies in every team and tap them.

14. Dedicate time to your security technologies. – Just like having talented staff, it can’t be said enough how time investment is important. The article mentions WAF and IDS, and that’s completely true in all cases. You can’t just stand up a WAF and expect it to do magic; you have to get it up, tune it, adjust it, work with devs as they make changes, tighten it up right to the point of breaking shit but not quite breaking it, and then test it, tune it, validate it, etc. That’s not a project, that’s a job.