« Pavel Brings RKC to Philly - 1st Time!! | Main | On "Responsibility Without Authority" »

Do You Need a Security Department?

(There's been some confusion about my post here. I'm not saying you "can't" setup a security department. I'm questioning whether you "should" set one up. I wonder if we've not created major problems for ourselves by taking too much direct ownership over the years, effectively creating a "nanny state" where the front-line folks aren't actually expected to act responsibly.)

I had an interesting discussion with my boss today, and I think it warrants further exploration. To give a little background, I'm the head of security for a mid-size tech firm. My role is new, meaning there haven't been any "formal" security practices in the past. Note that this does not mean they've not been doing security "stuff" - just that there hasn't been anything formal around it.

One of my challenges in this position has been to determine how best to setup a formal security program. This is a well-established company, with a variety of obligations and requirements, and that is running on a tight staff. There are not spare people to go around, which means that getting much of anything done is an uphill battle.

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.


TrackBack URL for this entry:

Listed below are links to weblogs that reference Do You Need a Security Department?:

» On "Responsibility Without Authority" from The Falcon's View
Continuing my line of thinking from my previous post, "Do You Need a Security Department?", I wanted to speak to this notion of having responsibility without authority. It seems to be a problem common to many security people in their... [Read More]

» How NOT To Build a Security Program from The Falcon's View
Andy Willingham (Andy ITGuy, @andywillingham) had a post up early this week titled "Building a security program from the ground up". It's an interesting read, though a bit on the naive side. Having just come out of an environment where... [Read More]

» Uninspired. from The Falcon's View
In case you haven't noticed, my blogging has trailed off the last few weeks, roughly corresponding with starting a new contract. There could be any number of reasons why this has happened, but it's nothing you couldn't probably guess at.... [Read More]

Comments (4)

Thomas Sanders:

Have you ever taken a look at the ISO 27002?

Section 6.1.2 - Information security activities should be co-ordinated by representatives from different parts of the
organization with relevant roles and job functions.

Your ideas are not ground-breaking by any means, but you are missing the point of the importance of a separate internal entity.

Some 'security' functions in Security Departments, as you speak to it, are likely there due to lack of experience, time, or job role in any other department. Perhaps even segregation of duties due to compliance and/or regulatory measures.

Some real-world examples of why you believe this is true would be helpful.


I think the above would work as long as someone actually listens to either the CXO thats ultimately in charge or the security guy without a team and not on the org chart.

In larger organizations, he who is not on the org chart has no power and will only be tolerated but until a certain pain threshold. At that point you'll just get blown off because you "dont exist"

good luck with it, responsibility without authority is never fun and functionality will almost always win over security by the operations team.


@Thomas -

I'm not sure you're understanding my point. As for examples, I can't give you any real world specifics today as it's too early in my journey. My goal throughout my career has always been to work myself out of a job. To do that means that people outside of security have to take responsibility, which ironically seems to happen only rarely.

@CG -

I think you're definitely right, you absolutely need a CISO/CSO who has strong authority who can ensure that policies are enforced, hopefully with consequences. It's important, however, that the right people be subject to those consequences.



To Thomas's question, here's an example: Assuming a requirement to pentest annually, should you hire a full-time pentester, or should you outsource the role? If you're a small company with a very small number of target servers, then it probably makes fiscal sense to simply outsource the task to a qualified organization. However, at some point the amount of work will justify having a full-time resource onboard. For example, a full-time resource could have time split between pentesting and assisting with remediation (advising, retesting, etc.).

The point here is that there may or may not be a good justification for bringing a resource in-house, and thus building out a team or department. We need to be careful that we don't always run to the position of always building an internal security department.

Post a comment


This page contains a single entry from the blog posted on July 16, 2009 1:36 AM.

The previous post in this blog was Pavel Brings RKC to Philly - 1st Time!!.

The next post in this blog is On "Responsibility Without Authority".

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.