Operation Bootstrap

Web Operations, Culture, Security & Startups.

Re-tooling Your Infosec

| Comments

For the last year I’ve had a full time gig to build the InfoSec program at a small company. This is a company who had no prior security program and needed to have one built. Looking back on the last year there were a few things I did right, but plenty of things that didn’t go as expected. At the risk of putting my annual review out here for public scrutiny, lets talk about what I’ve learned and make some fun of us security professionals… at my expense.

First – “The Plan”

A plan, it’s what everyone needs to get started doing anything right? Yeah, except for one thing. A quote attributed to Mike Tyson probably summed it up best (trying to make my best Mike Tyson voice here):

“Everybody’s got plans… until they get hit”.

A plan is great if it works. If it doesn’t work, it serves as fantastic documentation of the fact that you had no idea what you were getting into from the start. But let there be no mistake, you need a plan. The problem is, if you’ve never hired someone to hit you to test out your plan, you are gonna get clocked in the head and the plan goes right out the window. This wasn’t the first lesson I learned, but it’s the first one you should learn.

My plan was to do the following, in as scientific a way as possible, and work right through the process that seemed so simple:

  • Get a detailed list of information assets the company thinks they have

  • Get a detailed list of systems on which those assets reside.

  • Get executives in a room to agree on which assets / systems are most critical — executives in a room? Agreement? stop giggling!

  • Examine the security around those critical systems, starting with “the most critical system” — critical according to who?

  • Build policies that users will read & which are sensible.

  • Build an awareness/training program to teach employees not to click strange links, pickup dirty USB keys, insert CD’s into their computer’s orifices if they don’t know where they have been.

  • Build an incident response plan.

  • Build monitoring systems to detect attacks!

  • Work with Engineering to build secure practices into our software & systems.

  • And on… and on… and on…

I got to the 2nd bullet point – FAIL. Did it take a year? Nope, but the 3rd bullet point is a more difficult nut to crack; or at least it has been for me. I hear you now, “Really, you’ve been doing this all year and that’s the only thing you accomplished?!?”. No, I’ve accomplished a lot in my opinion, but is the organization really more secure because of it? I say no, they are not, I need to do things differently. My accomplishments are scattered across many of those goals above, and the core requirement of understanding risk & prioritizing the remediation effort is still undone.

The outline above isn’t all that bad, but it lacks some subtle details that weren’t made clear to me when I started this. I don’t think I’ve “wasted” a year figuring this out, but maybe I can help you spend less time than I did. I still haven’t gotten this done though, so take what I say with a huge block of salt.

Have a plan, but unless you’ve made that plan work before – know that you have more learning to do than planning. Once you truly understand the risks, the plan becomes more self evident. Before we go further, lets talk about the next problem.

Second, Relationships & Organization.

Picture this: You are the guy who needs to fundamentally change the way your company thinks about security. You are going to get people to do things they don’t want to do, you are going to move the behavior of huge chunks of the organization like HR, Engineering, Operations, IT, Executives (yes, you must influence at this level FIRST). Are you going to do this as the “Security Manager” reporting to the Director of IT? Maybe, if you do it right. But it’s a whole lot more likely you’ll get nowhere fast. Either way, you will need some really good relationships & horsepower to get things done.

Security is a business unit like anything else in the company. It is rooted at the highest levels of a company’s organizational structure if the company intends for it to succeed. If it’s placed within another organization like IT, Operations or the like, then the power of a security team to influence the behavior of organizations such as HR & Engineering is dramatically reduced. This is a hard thing to change if the company doesn’t realize it, and you will need to be patient if you are in this position. But if you get the chance to be heard, speak up and call it out as a problem. There are enormous amounts of published data which will backup your claim that security needs to report high in the organization. Start with “How to Cheat at Managing Information Security” or heck, even the ISC2 materials for the CISSP.

That said, you have to operate in environments where that is not the case. You may not have influence but your boss or your bosses boss does. If there’s something you want to do and your boss supports it, put it in writing and have him sign it. Make it something of a declaration that “we will do xyz” and you are the implementor empowered to do it. It’s no longer your desire, it’s your bosses requirement. And if he’s not comfortable signing, ask if he can take it to his boss. If they aren’t comfortable standing behind your changes then at least you know where you stand. You need to spend more time showing them why this is important, or take another look at whether it’s actually the right place to focus.

Third – Testing, Training & Awareness

The beginning of realization for me came when I saw Chris Nickerson speak at RMISC. I talk about this guy a lot but it’s because the message he’s spreading is about real security, not compliance. My company doesn’t have compliance as a pillow of comfort against which they can disavow knowledge of the real world. I can’t tell my management that we’re PCI Compliant, or that we’re SoX compliant, or that our datacenter has SAS70 certification. They don’t care. And I like it that way, because I don’t care either.

Real security means we aren’t playing with rules & scope definitions. If I can walk into your office, or come through a skylight, or con an employee, or steal a server, I have your data. Game over, you lose. Think about your environment like this and all kinds of big scary beasts with claws start appearing and you have no idea how to protect against them. How do you know how you will respond when those buggers step out of the elevator and attack your receptionist? You put a few on your payroll, that’s how.

I recently conducted the beginnings of this test myself. I dropped some USB keys around the office which would autoexec a meterpreter client, gather some data using metasploit on my server, and then disconnect. The number of people who picked these up was surprising, and who picked these up was even more surprising. These are not ignorant folks, these are intelligent people who took a calculated risk because they had never been caught before. They had never been hit. In many cases they were just trying to figure out who’s key it was.

In every case, these people learned a little bit that day. They learned that something that had never happened in our office before could start happening. If everyone knows it could be a test and that fact alone keeps them from picking it up, I’m doing my job. I don’t care if it’s fear of humiliation or genuine security awareness that keeps us safe – but I’ll contribute to both.

It’s your employees, contractors and the like who make everyday decisions which impact risk. As the security team, your job is to facilitate training them and communicate the direction provided by executives so that appropriate decisions are made. You then must test your assumptions about whether or not they are understanding this information.

Testing also reinforces the awareness training, the policy documents, the talks, the guest speakers, all the other stuff that YOU do to help them become more aware of the issues. No budget? Start a blog. If you can make it internal, share internal details of stuff going on – security issues (where safe & sensible) and security news which relates to their day to day life. Find articles about security researchers pwning people on Facebook. Go to some conferences and record a fantastic speaker and get people to watch the video. Anything and everything to find interesting bits of security to get people enrolled. Show them how this stuff matters to them, PERSONALLY.

Fourth – Tools & Expertise.

This is something I felt all year, but could never express it well enough to get agreement by my management. It’s still in progress – wish me luck. If you are a one guy show managing InfoSec, you cannot do it all. Say this after me “I cannot do it all”. Yes, you are a skilled security professional and if given time and focus, you can probably do any one thing very well. If you are anything like me, you’re a jack of all trades who has always learned to do things themself and has a hard time telling someone “I need help to do this”. But there’s a better way.

You are managing InfoSec, maybe you have staff but my guess is that you don’t have a full pentesting staff, guys who research exploits all day, someone managing all your scanning software, IDS, etc etc. Oh, and someone has to write those TPS reports, attend meetings, deal with ad-hoc issues, etc. Now lets imagine the attacker who wants to pwn your company for fun and (probably) profit. Do they have all those obstacles? No, they do not.

If you don’t get it already, understanding the risks to your business is priority #1. Without understanding, you cannot address those risks. Guessing at risk based on what’s in the news and trendy is a recipe for disaster, don’t do it. Understanding this risk is much easier and faster if you can dedicate someone to the task and if that someone has experience doing it. Don’t hire a big auditing firm who knows compliance in and out but has never heard of metasploit. Hire someone with experience, who understands the business side of risk, who knows that while hacking my corporate web server might be a big deal, hacking my CRM or Financial databases is a much bigger deal.

Also – do not buy an IDS just because you need to have one. Do not buy a security scanner because you think you need one. Understand the risk. Understand how these tools are going to mitigate the risk. If the tool doesn’t improve security, don’t spend money on it!

If you have a farm of public web servers that you KNOW are not patched, that you KNOW are not going to get patched, that security scanner is going to do nothing but cost your company money. If you need to prove the vulnerabilities exist, fire up Nessus & prove it (with permission, please). But you have some politics to work on before it’s worthwhile to pay for tools to tell you what you already know. Same for IDS, unless you have a plan to respond to even a single alert that comes from the IDS, save your pennies & buy a professional penetration test.

Quick Summary

Mistakes

  • Having a plan, not understanding how to execute on it.

  • Trying to do it all myself

  • Not understanding risks to the business & having that guide my tasks.

  • Buying tools before understanding.

New Goals

  • Get some help to understand risk & communicate that to executives.

  • Position the InfoSec team in the organization in order to maximize influence.

  • Build an awareness program and get employees enrolled in security.

  • Training, testing, training, testing, training….

I hope this helps someone out there.

Comments