Do You Need a Security Department?

Without going into my approach (that's a post for another day), I wanted to delve into an interested side-discussion. Specifically, I've begun to wonder if it's really necessary to have a formal, dedicated security department any more. I wonder if we've perhaps reached the point where we simply need a few dedicated champions in key positions, possibly even with a matrix report-to relationship with your CISO/CSO, who can help drive initiatives within each respective area, ranging from risk management to policies to operations to development to audit and testing and beyond.

Ok, I lied, let me talk about my view of the big picture for 1 minute (give or take). The following diagram shows my updated TEAM Model (v2), for which I will be releasing a revised white paper in the not-too-distant future. I think it is fairly self-explanatory, but wanted to highlight it quickly, with this comment: You cannot implement all of this in one big shot at an existing organization - particularly one with limited resources.

Alrighty, back from that little segue, let's now talk about whether or not you really need a dedicated security department. Overall, I think the answer depends on the context. How big is your organization? What's your resource picture? How are responsibilities currently aligned and assigned? The reason these questions are important is because it helps define your constraints/scope. If you're in a situation like mine where you have no other resources but yourself, no pre-existing formal program, and really not much to lean on, then that is much different from, say, a large corporation that already has a lot of pre-existing program in place.

The IT Insource/Outsource Sine Wave

One thing to key to this question is one of financial prudence, and it seems to strongly resemble the sine wave cycle for evaluating whether to insource or outsource given IT functions. The insource/outsource sine wave is a modulation wave that swings between "definitely outsource" and "definitely insource" based on the cost to the organization. Without delving too much into the theory behind it, consider that a 2-person company is likely much better suited outsourcing a lot of IT than it is in trying to hire a staff to bring the services in-house. However, as that 2-person company grows, they will eventually cross a threshold where it actually makes more fiscal sense to bring those roles in-house. Similarly, if the company again continues to grow, they will eventually cross the threshold again where they can outsource the entirety of IT operations at a price point that is lower than the cost of keeping those resources internal.

Note that this sine wave does not look at other key factors, such as risk management or quality, but instead focuses solely on cost-effectiveness. A more complete analysis would obviously look at other factors to ensure that the quality of services being provided, for example, were in keeping with the expectations of the organization in either insource or outsource models. But I digress...

What's Really Important?

Thinking back to my TEAM Model, then, I wonder what functions are really necessary as part of a dedicated security function, versus what can be delegated out to the respective teams for performance. Again, bear in mind that the ultimate answer will vary depending on the organizational context. That being said, I think it's safe to draw these conclusions:

* If you already have a risk management team, then it makes sense to integrate information risk management into it. In fact, this approach may be far superior to keeping information risk management separate. Note that there may be an opportunity cost in getting your existing risk management team up-to-speed, but there may be significant long-term value here as well.

* Much of information security management responsibilities are operational in nature. You don't necessarily need dedicated security people hardening systems or writing secure code. In fact, I would argue that you almost never should have dedicated security people performing those functions, but should instead focus on ensuring that your existing personnel are well-trained.

* Logging, monitoring, and incident response is an area where I'm going to expect a lot of push-back. Why? Because, let's be honest, we security people don't tend to trust others in the organization (admit it!:). However, let's think about this for a minute. If you have proper policies and reporting in place, why can't your rely on your operations team to implement central logging and monitoring? In terms of incident response, show me an operational team that's not already doing this. Now, there is a potential major exception, and that's in ensuring a forensically sound response to a breach that may require legal support. However, once again, many organizations already have outsourcing arrangements with forensics teams because it's too expensive to maintain a team in-house (unless you're getting breached A LOT, which raises other red flags). I then flip back to ensuring you have a strong policy framework in place with decent training to back it up.

* Policies likely need to be owned by a dedicated security function. Your risk management team isn't going to write them. You darn well better not let your auditors write them. And, while it's likely ok for your operations team to write the procedures and configuration guides, someone still needs to check them. Now, this being said, I've seen organizations outsource the writing of the policies, and this is certainly a viable option. Ultimately, your senior management (or executive) team is responsible for publication and awareness. Overall, then, it seems logical to make this an assigned and dedicated security responsibility. On the other hand, we could assign this responsibility to your Legal Department (or in-house counsel). So, I don't think this is so much a hard-and-fast rule as it is just a limited logical conclusion.

* Security testing should be part of QA. It really should. This quip does not necessarily apply to certain regulatory requirements for qualified assessments, etc. Beyond that, however, this seems to be a set of activities that again maps cleanly into existing practices.

* IT audit should be part of your audit department. If you already have auditors, then IT audit may as well be part of that crowd. Make sure they have someone qualified, and off to the races you go. Ultimately, the reason for rolling these together is because your C*s already read and respond to audit reports. Streamline that reporting and viola you're good to go.

Now, a few caveats here.

1) Obviously, the above assumes a larger organization already.

2) If you're a small organization, then consider outsourcing these responsibilities altogether. Especially if you're already outsourcing much of what you're doing in IT.

3) It is absolutely vital that you have a CISO/CSO who does not report up through IT and who is treated as a true C-level executive. That person should be ultimately responsible for all of this good stuff. In a small company, this person is likely going to be very hands-on in nature.

4) For mid-sized companies, your 1 or 2 dedicated security people should not be overly aggressive about trying to grow the security team. As far as I can tell, it's counter-productive. Even if your operations and development teams (if you have them) are heavily loaded, it will be far more useful and productive to demonstrate their need for additional resources than it will be to try and justify parallel resourcing. Case-in-point: identity and access management. While some facets, such as definition of roles, and policies that support the entire category, clearly should be owned by the CISO/CSO, much of it is purely operational in nature. Moreover, operations (or IT) benefits the most from implementing these solutions in the long-run. Make the case, get their buy-in, help with the project planning, and then get out of the way.

5) There is absolutely a need for a trusted security advisor. Guess what? That person does not necessarily need to be a full-time employee. At some point you will have enough practices in place that the organization can run relatively cleanly. Why burn a full resource, then, on babysitting that infrastructure? It just doesn't seem to make sense to me.

Work Yourself Out of a Job? Crazy Talk!

In essence, I am talking about nothing short of working myself out of a job here. In my context, it absolutely does not make sense to waste the money building a large security team. Much of what needs to be done today has to be owned by other people. My role, then, is far more of a coaching and advising responsibility than anything else. My job will quickly become about defining discrete projects that can have cost and resource estimates attached, be prioritized, and be executed by other people.

There are a few exceptions here. Security policies need to be written and distributed. Training and awareness needs to be conducted. Some oversight needs to be put in place. However, I view many of these things as short-term start-up tasks that in the long-run get handed back over to other teams.

Security has a very bad reputation for getting in the way of work. I'm increasingly of the opinion that the best way around this is to stop pushing projects as "security" work, and instead make them the responsibility of teams like operations/IT. Make a business case, spec out the requirements and the cost, and then hand it over to your management team to own.

What If Nothing Gets Done?

A part of project planning is justifying the project. In the end it's up to the executive management team to make risk decisions. The CISO/CSO can only provide the research and recommendations. If the money isn't available, then there's not much you can do. If there are other priorities that take precedence, then you have to respect that. Why? Because if the core of the business fails, then you won't really need to worry too much about security.

My Point

I fully expect this post to go over like a lead balloon. What I'm saying flies in the face of conventional wisdom, and what's worse, it actually advocates making people be responsible for their actions (outside of security). It's occurred to me, however, that maybe part of our problem in this industry is that we've been in a nanny state for far too long. Why should security accept the responsibility without the authority? Does that really make sense? It certainly isn't fair!

As such, I hope that you will take some time to seriously consider what I'm saying. Having a fully dedicated security department may not, in fact, be in the best interest of the organization. Sure, maybe you can justify a small team, and sure that might qualify as a "department." However, let's not get caught-up in such trivialities and instead look at the big picture. My guess is that a significant percentage of "security" has no place in a dedicated security department. If this is true, then we have an excellent opportunity to redefine this industry, break the counterculture monotony that we've become, and instead focus on making the right people responsible for the right things.