Internal Security Staff Matters
I read Gunter Ollmann's post in the IBM ISS blog with interest today. Gunter is "Director Security Strategy, IBM Internet Security Systems," so he is undoubtedly pro-outsourcing. Here is his argument:[S]ecurity doesn’t come cheap. While individual security technologies get cheaper as they commoditize, the constant influx of new threats drives the need for new classes of protection and new locations to deploy them...
If you were to examine a typical organizations IT security budget, you’d probably see that the majority of spend isn’t in new appliances or software license renewals, instead it’ll lie in the departments staffing costs...
This is at odds with the way most organizations normally deal with specialized and professional skill requirements... Just about every organization I deal with (including some of the biggest international companies) relies upon external agencies to provide these specialist services and consultancy – as and when required – it’s more cost effective that way.
With that in mind, why are organizations building up their own highly-trained (and expensive) specialist internal security teams? Granted, some of the security technologies being deployed by organizations are relatively complex, but do they really require a Masters degree and CISSP certified experts to babysit them full-time...
Nowadays you can tap in an incredibly broad range of expertise – ranging from hard-core security researchers capable of helping you evaluate the security of new products you’re thinking of buying and deploying throughout your enterprise, through to 24x7 security sentinels; so knowledgeable about the security product you’ve deployed that they’re capable of guaranteeing protection with money-back SLA’s...
Organizations should take a closer look at their security budgets and evaluate whether they’re getting the right value out of their internal teams and whether their skills investment meets the daily need of the business. (emphasis added)
By highlighting the focus on "security products," you can probably predict my response to Gunter's post. Sure, you can get hire experts that may (or may not) be cheaper than internal staff, and they may be smarter in individual products or even defensive tactics, but they are poor with respect to the most critical aspect of modern security: business knowledge. It does not matter if you are the world's greatest packet monkey if you 1) don't know what matters to a business; 2) don't know business systems; 3) don't know what is normal for a business... do I need to continue?
This is the biggest challenge I see for consultants, having been one and having hired them. It's easier to hire a consultant to help configure a security product than it is to figure out if that product is even needed, which to buy, how to get approval and business buy-in, how to support it operationally, and a dozen other decisions.
I agree that certain specialized tasks merit outside support. That list changes from organization to organization. However, beware arguments like Gunter's.
Comments
Even as a consultant myself, I have to agree with Richard...the most technically proficient consultant isn't going to help if they don't take a company's business operations into account. However, I have also seen my share of the opposite...internal IT staff that "does" security in isolation of other internal departments, such as Legal Counsel, HR, Communications/PR, etc. Organizations like this can expose (have exposed) themselves to more risk through their own internal IR procedures that the incident did in the first place (ie, think PCI).
I agree with Richard that consultants can provide value in many areas and it is tough to extract value on a short term basis from any entity external to the core business. I do think that an external team can learn and provide value over a longer period of time as it learns more of the business influences and require ments and how they continually evolve, but that basically means the external entity is completely internalized and part of the team.
All in all I'm starting to think that the hardest battles we face as Security Professionals are not the technical issues we always find a way to solve those - it is the political/business/partnership questions that we struggle with the most.
Stick to the first aid analogy and I think this guy has a point.
It's makes sense for a company to keep a physician's assistant or an RN type skill on the internal staff. Although not a full MD or surgeon, these types could provide 1) an understanding of what matters to the body (the business) 2) knowledge of what type of specialist is needed to address the different body (business) systems (i.e. vascular, skeletal, neurological, etc.) 3) Based on proximity and time with the patients (employees, biz context) understand a normal baseline for this group.
Gunters point is that with a few lower priced PA's and RN's and organization can provide reasonable protection if the appropriate specialists are on retainer. A company cannot afford to have a brain surgeon (packet monkey), vascular surgeon(e-discovery), and anesthesiologist (malware reverse engineering, etc.) on staff. This may fit the Military, but not the marketplace.
IT security, like medicine, depending on how critical; is really about specialization.
Look at an NFL team. The players a multi-million dollar assets, but the team usually on keeps a only a generalist doctor on retainer, but mainains connections to the best Orthopedic specialists in the country.
Plenty of IT Managers in my country think they know security but don't. They outsource so many things that they couldn't even tell if a particular IP address is active within their company! This is no way to run an internal IT Team and if they had some security foundation, at least they'd know how to evaluate what MSSP's are offering them so they don't get conned!
I think we should sell only to clients who have a CISSP, not the other way around ;)
Best, Hal
Security risk cannot be "shifted" or "transferred" to third parties. External organizations can be used to help mitigate risks, (i.e. lessen their impact or likelihood) but at the end of the day the risk to the organization still belongs to it. For example, if I hire an MSSP to monitor my network perimeter and a breach is discovered... my reputation is still damaged. The rep of the MSSP will likely be damaged as well but it doesn't necessarily lessen the overall impact on what my company cares about. The only effective ways to transfer risk are through insurance and by divesting functions/assets.
I did a lot better with my old Snort box but it couldn't be monitored by me 24/7 so we had to get a managed service for compliance reasons.
Maybe decades of research has been suddenly ignored, but last time I checked Risk Transference was an accepted form of dealing with risk. You can accept it, mitigate it, or transfer it. Did some new "guru" shift the paradigm? (Thats sarcasm :-)) And yes your are technically correct, it is more about shifting blame. I just tend to take a more real world look at things vs an academic approach. When the s hits the fan, everybody talks blame, not risk. That's definitely wrong, but its the world we live in.
http://online.wsj.com/article/SB124603518881261729.html