In a previous post, I wrote about some things that were interesting from a very neat conversation with a healthcare CISO. This post is a follow-up to that initial post, discussing the very real Build vs. Buy problem many CISOs are running into. Whether it's for lack of available talent, time, or simply priorities, CISOs have to make this decision nearly every day so this post discusses some of those choices, their consequence and rationale.
First off, let me explain what I'm talking about, just to level-set. The "Build vs. Buy" problem in Information Security (not unlike anywhere else in IT) is a dilemma faced by the security leadership when trying to best service the business need with the available resources. At some point the decision needs to be made whether to "do-it-yourself" (DIY) or outsource it to someone else. The added catch is that in the healthcare industry some things you need to think twice through, because of regulations.
Why Build vs. Buy
Where does build vs. buy show up the most? While no organization, in size or in market-space, is immune to wrestling with this question the group that has to deal with this most is the SME (Small to Medium Enterprises). When you're faced with all the issues that make you a target while battling with the small-scale budget and resource issues - you simply have no choice but to split the work and outsource some of it.
Budget finality means that you can't hire 10 software security experts to staff a team because you can't afford more than 1 or 2 - yet your organization has 300+ applications which undergo regular release cycles, some of them are even agile and there's just no way to keep pace. Then there's the security infrastructure which needs constant care, updates, and tuning to your organization's pulse and you again simply don't have the manpower to keep pace. Change control, application security reviews, incident response, policy review, audit preparation, acquisition due-diligence ... all of these require people, money and more importantly time which is a precious commodity - but you've got it all in short supply. Here's one way of looking at making the decision of what to build, and what to outsource...
When to Build vs. Buy - Talent, Time, Priorities
When trying to decide what to build vs. buy, there are 3 key things to consider:
- Does your organization have the in-house talent to handle the activity as an expert?
- Do your in-house resources have enough time to perform the activity well?
- Is the activity a business priority?
When thinking through these three questions, it can be daunting to make the decisions necessary to move forward.
Expertise (talent) in Information Security is in short supply - this is no secret. We're at nearly full employment in Information Security disciplines across the board, and recruiters are having to lure good employees away from current employment rather than having resumes come to them. Finding the right person to fit into your organization is proving increasingly difficult - especially when employees know they have a choice. Being able to choose means that the cost of talent acquisition is going up, which means this puts an even bigger squeeze on the SME budget. The typical SME has no more than 6-8 full-time Information Security employees at any given time, not because they don't want more, but because more is simply not affordable. With 6-8 full timers on staff, and a mountain of work to do, you have to pick the things that your people are good at, hire for the things that are critical that you're missing, and outsource the rest. The more specialized the work, the more likely it is you'll be outsourcing it - unless it's a business critical task. SCADA systems security is one of the most specialized of the specialized - but you're probably not going to outsource that work if your company makes smart-meters ...at least I would hope not. In the health care space, if you're making heart monitors that may be operating over some sort of wireless mode, you're going to hire the type of security people who understand security, wireless communications, and purpose-build devices and yes those are extremely rare and you'll pay a premium for them... but even though you're more likely to find a software security expert available, you'll likely outsource that rather than the business-critical work.
Just because you have 2 people who are software security experts doesn't mean they've got the time needed to handle the 300+ applications in the typical SME out there. With the rapid release cycles of certain types of code, or the excruciatingly painstaking type of work it can be - often times we'd need 10x the resources to get the job done. This is a perfect opportunity to outsource - at least part of the task to someone else who has efficiency in scale and expertise. I made a reference to outsourcing part of the work because there are certain parts of even commodity activities which require someone who is close to the business, with context, to make appropriate risk decisions. Outsourcing the work that can be automated, context-agnostic is a great way to get yourself added efficiency and scale without having to acquire more talent... and it can often be much more cost-effective when purchased on an "as needed" basis or "by the drink" if you prefer.
Lastly, it comes down to a matter of priorities. You'll see this come up often but more often than not it comes down to priorities. Does your organization require a forensics investigator on staff? Probably not... unless you're in a high-risk business and you go through that activity often. You probably don't need a full-time security-compliance person, but they're helpful to have around when you have to do those mapping and auditing exercises, a few times a year. Do you really need to have a staffed Security Operations Center 24x7? Probably not ... but it's one of those nice-to-have activities which can be outsourced to someone else, and the second-level support can be brought back to your in-house staff for escalations support in a crisis or suspected incident. Here choosing the right partner is important because you simply can't just trust anyone who can sit down and stare at blinking lights all day. Additionally, I've seen organizations outsource the execution of change management... and while it may sound dangerous and critical to the business ... the trick is in the how. It's perfectly natural to want to keep the review and governance part of change management in-house, and I would expect that to be critical, but the actual execution of the tasks ...not so much. In my previous organization a change-management analyst on the security team would review changes and help make architecture/design decisions and then at the appropriate change windows (usually middle of the night, and weekends) the changes would be executed by some outsourced contractor who just looked at the logic approved, and made the appropriate mouse clicks, or keyboard inputs, executing the change, and verifying integrity of the change and system sanity afterwards. If a change went wrong the person who approved it would be paged from his slumber - but there was no reason for that person to be working 24x7 when a contractor hired to only execute changes would do just fine.
Tomorrow I'll cover the second part of this post - providing you hints on WHAT to outsource, and what questions to answer to get you there...come back tomorrow!
As always, if you have a comment, of additional thoughts, please don't hesitate to leave a comment here (but don't forget to leave your Twitter handle!) or connect with me on Twitter @Wh1t3Rabbit and using the #SecBiz hashtag.