The “build vs buy” debate in security technology has been argued so many times that there are few unique positions left to take. Builders prioritize flexibility and control, while buyers prioritize predictable performance, scale, cost, and results. The debate continues not because there are groundbreaking arguments in favor of one or the other.
The build vs buy debate continues because as an industry we demand a false choice.
Many information security technologists and operators are staunch proponents of designing systems, building tools, and implementing services (“building”). This is doubly true as it relates to security solutions. By definition, an effective security solution requires an understanding of both the target as well as the new system designed to defend that target. Building demands deconstructing the problem you’re trying to solve and a deep understanding of the problem’s environment. This includes everything from human factors to the technologies and business processes upon which the problem and solution rely. And when done well1, the solution will be both immediately effective and adaptable well into the future.
From a security perspective, building complicates the adversary’s pre-intrusion planning by introducing systems against which they are unable to test unilaterally. Products can be procured and inserted into target ranges to ensure that a given payload or tactic won’t set off alarms. But a complete solution designed to protect a particular environment and used by a particular team is inherently unpredictable. This is no small advantage when facing a qualified adversary.
Building is not without its complexities, of course. Building implies that the organization knows what it needs today, and also how its needs may evolve. It implies that the team is capable of designing, building, and supporting a solution that is as reliable, scalable and effective as one built by a specialized third-party.
Overall, building can be very expensive not only in terms of time but in terms in risk, particularly if a stop-gap is not available while the solution is being built.
Executives are faced with the reality that security is just one of many competing priorities that must be considered when allocating resources. The business can invest in its own products, services, sales, and marketing–these will grow the business and allow the business to provide value to customers, employees and shareholders. Or the business can invest hundreds of thousands of dollars at a minimum to acquire talent, train them, and provide them with the resources needed to build a functional security program. The former has a clearly positive impact; the latter will be neutral at best or in the worst case may actually do harm.
Businesses in this position often rely on third-party products and services to bring mature capabilities to bear quickly and with predictable results. This does not, however, obviate the need for expertise. There will always be room for an experienced leader who is able to set forth a vision, recognize specific needs, and establish priorities. And if that leader or her team possess applicable expertise, that expertise can be applied to solving the organization’s newest and most unique problems.
Like building, buying comes with its own set of considerations: Buying security products often means using the same defenses that are available to the adversary. Services mitigate this to some degree as it is much more difficult for the adversary to predict not only how the service operates or its technical components behave, but also how the customer’s response to alerts might change over time.
Buying any product or service can also impact skill alignment. Technical personnel may focus more on later-stage activities such as validation, investigation, and remediation as opposed to earlier-stage activities such as data analysis and detection. Skill alignment, however, assumes that the organization has the human resources it needs today or expects to have them soon–a situation that is increasingly uncommon.
An effective approach
With proper planning, a suite of commercial products and services can be every bit as effective as a built solution – though at less cost. In fact, a properly scoped and implemented collection of third-party products and services you buy are a built solution–the organization is simply choosing to buy what a specialized team has built.
Simply stated, building and buying are not mutually exclusive. Once a need has been established, organizations must decide whether to build now, buy with an intention to build in parallel, or buy with the intention to outsource that function indefinitely. Decisions should be based on value to the organization both today and into the future, and priorities should reflect the need for tactical and strategic outcomes.
This is exemplified when peeling back the onion of almost any leading product or service. Being close to the endpoint side of the Managed Detection and Response (MDR) space, we can use this as a case study. Building an endpoint-based MDR capability requires:
- Identification of viable EDR products
- Evaluation of and selection from the above
- EDR product implementation
- Collection of endpoint data
- Integration of both data and product into the enterprise technology portfolio
- Detection criteria based on endpoint data (examples here and here)
- Analysis of detected events by security staff (example skill sets here)
- Investigation into confirmed threats
- Incident response
- Conversion of response lessons into new or improved controls
This list is oversimplified but fairly complete. It took only a few moments to write and takes no longer to read, but for most organizations, implementing these capabilities can take years. Is there value in acquiring the expertise and technical resources to perform the above? Perhaps. From a security standpoint is this worth doing? Absolutely.
For organizations that place a premium on significant and sustained investments in talent and technology, building this capability may be time-consuming but viable. But again, we find that this organizational profile is rare.
A more practical approach for most organizations: buy as many of these steps as they can and allow their internal team to focus on those steps that must be handled internally.
What to do
Before making any decision, design the ideal solution and then determine whether resources exist to implement that solution in-house. If resources do exist, determine whether the build time will surpass the desired go-live window. If building isn’t possible in a timely manner or at all, find a provider that is capable of delivering something that is close to an ideal solution as possible.
“Build” and “buy” should not be viewed as governance strategies or inflexible commitments, but as means to achieve an outcome at a particular point in time.
1Never to be confused with “well done,” a meat temperature to be summarily avoided.