How NOT To Build a Security Program

With that said, let me tackle some of Andy's comments and my gripe with them. Please note that I am working from the assumption of "building a security program from the ground up" and all that this implies (such as that there isn't already a program in place).

"Here are a couple of assumptions: They already have a firewall and host based security suite installed and up to date. Beyond that, it’s a crap shoot."

These are rather unfortunate assumptions. What is meant by "host based security suite"? AV? Something else? If you're coming into an existing organization to build a security program from the ground up, then you shouldn't come in with any assumptions. I've been in more than one organization that hasn't had a firewall, let along ANY host-based security (no AV, no HIDS, no logging, no monitoring, etc). Assumptions - especially bad assumptions - can be very bad things (see what a certain analyst says on this topic).

If you're going to assume anything going into a new "green field" opportunity like this, it should be that nothing exists, nothing is being done, and that you will be met with inordinate amounts of resistance and organizational inertia. You should assume that you will have been given the "happy" story during the interview process, and that reality is far more stark. You should also assume that, despite the lip service paid in the interviews, there will be no way to know the commitment of executive management until you are actually onboard and asking them to put some skin in the game.

"If I were coming into a company and had a free hand to do what I wanted I would first look at what I could do to get the biggest bang for my buck quickly and then focus on the long-term strategic planning."

Here we have another bad implicit assumption. There's no such thing as having a "free hand to do what I wanted" in an existing organization. To think otherwise is to be somewhat deluded. The reality is that the business existed before you got there, and it's likely to exist without you being there in the future, or so they'll all be thinking in the back of their minds.

In the comments of Andy's post Kevin Riggins makes the excellent observation that one of the first things you're going to need to do is go back to executive management AFTER the interview (and after you've started, presumably) to truly test their commitment and support. Without it, your life will be much more difficult. If you're thinking "not true, you can always do bottom-up", then sure, that's ok for certain operational concerns, but don't you dare bring up strategy or risk. :)

"I’d say the first thing I’d do is implement a monitoring system so I can have some insight into what is going on."

This comment isn't wrong, per se, it just fast-forwards through a number of steps. Monitor what? Logs? IDS? Firewall logs? Do you have a log server? Are you talking about *shudder* a SIEM solution? At the same time, what about policies and practices? So you're monitoring and seeing bad things... then what? Do you have the policies and executive support necessary to actually do something when you start seeing badness (and it definitely is when and not if).

Your goal from the outset should be to quickly assess the state of the environment and start architecting a path to a defensible and recoverable posture (see my posts "Defensibility and Recoverability" and "Surviving in Degraded Conditions: A Human Analogy" for more on what this means). Note that I say "quickly assess". Depending on the size of the organization, this could be done fairly quickly. Walk through a facility or two, talk to as many people as people, from execs to tech to the manager in between, and then start building that roadmap.

More important that anything here is that you need to learn what is critical to the business. If X blows up, then Y really bad consequence will occur. That sort of thing.

Also, note here that I'm not even talking about "risk" at all. Forget about risk for a moment and just think about basic prioritization. It very simply comes down to a) identifying what's critical to the business, b) defending what's critical to the business, and c) building contingency plans for adequate recovery of what's critical to the business when something bad happens.

"Once that was in place I’d probably implement a Vulnerability Management program that starts with Application and OS patching and then focus on the scanning, testing, exploiting etc..."

I have to be honest, my jaw dropped a bit when I read this one. That's quite the leap in logic. Don't get me wrong, patching is very important, but the way he says it here, almost nonchalantly, gives one the false impression that this is somehow easy or trivial. There is, in fact, so much more that needs to be done than simply going out and implementing such a program. Change management, configuration management, access control and management, etc. Sure, none of these are mandatory for patching, but they absolutely have ties into a Vulnerability Management program. As for scanning, testing, and exploiting... well, let's just say that this is somewhat jumping the gun, and an area where one needs to be very cautious, too.

Specifically, as you shift from the "push and pray" patch model to a formal Vulnerability Management program, don't forget that you are going to need to know what changes are being in your environment, when they're going in, what they're doing (impact), who made the change, and who authorized them, among other things. Yes, get the patching going (if it's not already), but hold off on the Vulnerability Management project until you have a better handle on processes.

---
After the last quote he talks about awareness training, governance, and policies & procedures being all run in parallel as much as possible. Gack. He talks earlier about long-term strategic planning, which is good in theory, but in practice not so much. He ends with "This is just a starting point." Fair enough, but the approach is far too technical without really knowing or understanding anything about the business, the environment, and - far more importantly - the people.

Allow me to offer alternative advice:

1. Garner Strong Executive Support: You must have strong executive support. None of this "responsibility without authority" nonsense. The minute you walk through the door, you will have to seek out and build support for everything you want to do. Unless you're given the authority to go make changes directly (extremely unlikely) then you will have to get various levels of management onboard for everything you want to do. Passive resistance can be deadly.


2. Lightning Assessment: You must understand what is important to the business, as well as begin to get a picture of why things are the way they are today (tech decisions, etc.). I'm not advocating here any sort of formal assessment, and I'm certainly not talking about "risk" anything. This is quite literally a very rapid organizational walk-through, if you will, to see who's around, what people do, and, more important than anything else, what is absolutely critical to the business. If you're unable to find this out, then I suggest looking for a new job, because what you're facing will be a situation not dissimilar to the one I was in. If the business doesn't have a solid direction ("making money" is not a solid direction), then you're not going to have much luck contributing to the success of the business. By the way, in addition to identifying what is critical to the business, you should also keep your eyes peeled for major gaping holes that need immediate redress.


3. Share Responsibility, Gain Accountability: Security needs to be a responsibility shared by everybody in the organization. Hence the role of basic awareness training. What I'm talking about here is something more radical. It's not enough to try to make people aware of security. Instead, you need them to have a vested interest in making sure critical assets are defended and can be recovered rapidly when something bad happens. From the investment comes a lever for establishing accountability. And, sad to say, it's then time to help move the business back from the squishy touchy-feely approach and get HR engaged so that when people do dumb, stupid, or patently bad things, they are disciplined accordingly, up to and including termination of employment. We seem to have lost the edge in the business world, and this is one area where we can start getting it back.


4. Not All Low-Hanging Fruit Are Equal: It's very tempting to walk into a new situation and immediately chase after the things that you personally know how to handle quickly and easily. Unfortunately, those things may be completely worthless in the grand scheme of things (well, not completely, I suppose). Based on the outcome of your Lightning Assessment above, you should know what's truly important to the business. From this, you should then be able to start focusing on how well protected those critical assets are. This is where you should start tackling low-hanging fruit. Now, obviously at the same time you need to keep an eye out for gaping holes that are so egregious that they cannot be allowed to stand.


5. Fight to Simplify: One of the biggest challenges in a ground-up opportunity is keeping yourself grounded. It's too easy - as I can attest from first-hand experience - to get completely overwhelmed by everything that needs to be done. This is why I recommend the previous steps, forcing yourself to find the truly important systems and then focus almost exclusively on them. It could be argued that this approach could be dangerous, and that is absolutely true. A long-term focus on just a narrow slice of the enterprise is fool-hardy. It will lead you to an outcome akin to all the major breaches we've read about recently. Now, in fact, this whole stripped-down approach is meant as a starter, not as a long-term strategy. At some point, you will have to look at the big picture. BUT... you can't really do any of that until you first establish the basics, building some political capital that will then free you to move onto bigger, better things.


6. Documentation and Processes: The one thing you will definitely have in your control is the ability to generate documentation. Whether it goes anywhere is, of course, a different story, but it is at least one thing you can - and definitely should - make use of. You'll want to document your findings, your short-term plans, your ideas, your low-hanging fruit, your critical business findings, etc. The other piece of documentation that is very useful relates to processes. It's great to start by documenting what people are doing today, and then offering incremental improvements to better formalize and standards those practices. Similarly, if nothing formal is being done (e.g. change management), you can develop basic processes to get the fundamentals in place (a formal write-up, a formal approval, a paper trail) and then you can go about iterating through incremental improvements over time as necessary. The key take-aways here are that a) you can write documentation from Day 1, b) make sure to bear in mind the difference between writing a process and having it followed.


7. Strategy: Everybody wants one, but how many actually use them? Seriously. Security has historically been reactive in nature. There are many proactive things we can do to help reduce some threats, but in the grand scheme of things it can be very difficult to make a case for proactive efforts until you have a baseline against which to measure success. Nonetheless, you will need a big picture at some point - though preferably after the first 6 months. The important role of a strategy is that it will look at the full breadth of the organization, rather than the short-term focus you've maintained just on critical resources. You NEED to look at everything at some point, because it is the weak links that will lead to the deepest attacks. Your strategy should also establish levels of tolerance for downtime, interruption, and loss of data. What we're talking about here is taking the critical resources initial assessment and expanding that into a broader conversation with executive management about how much pain they can tolerate in certain areas. This will help you set overarching priorities for the long-term. It will help you determine what your minimal level of defensibility and recoverability will need to be.

It would be easy to go on and on and on here, but I think the main points are covered. Certainly, there are other ways to tackle this challenge, but the above represents a significant chunk of what I learned in my 7 months facing such a challenge.

(Please Note: This is cross-posted from the T2PA Practical Security Core.)