In security, whether to build or buy a given solution is one of the oldest questions. I was most recently reminded of this question a few weeks ago. Despite all my years on the operational side, I am unable answer the “build or buy” question. Not because I don’t understand how technology is procured, deployed, and operated in an enterprise, but rather because the question makes no sense. Sound like a radical statement? Allow me to elaborate.
Perhaps it’s best to begin with the etymology of the word solution. Solution comes from the Latin root words solv and solut. Both those root words mean to “loosen”. A solution is something that has “loosened” a complex underlying problem. In other words, a solution is something that takes a complex problem and turns it into something that can be addressed. Further, when most people ask the question “build or buy”, they are most often talking about technology.
In this context, it is easy to see that the question of “build or buy” is not the right question to be asking when looking to implement a security solution. Solutions require the combination of people, process, and technology. Technology in and of itself is necessary but not sufficient to form a solution.
If we really want to have a serious discussion along the lines of this topic, we should ask a few different questions. Questions like “What problem am I looking to solve?”, “What are the goals and priorities into which I can break that problem down?”, and “What is the right mix of people, process, and technology to address those goals and priorities?”. These questions and other questions like them are much more relevant to the discussion.
Looking at this topic from a solution-centric perspective, rather than a technology-centric “build or buy” perspective changes the nature of the discussion. People, process, and technology are all equally important components in this discussion. Further, it’s important to understand how they inter-connect, rely on, and depend upon one another.
Let’s begin with an example. A few years back, I saw a presentation on building a $100 network flow data sensor at a conference I attended. The presenter described the process he went through and the mix of different approaches he tried before finally arriving at the sensor he desired. What was most interesting to me was what the presenter omitted from the presentation – that it had taken six months to get just the one sensor working. With overhead and benefits, that’s more like a $100,000 sensor. Moreover, what happened to his other work duties during the time he was building the sensor? Was someone else required to perform them?
I use this example to illustrate a larger point. When an investment is made in one component of the people, process, and technology triad, it affects the others. For example, investing less in technology may necessitate investing more in people and process. When looking to implement a given solution, we should be thinking about what mix of people, process, and technology maximizes the value to the security program at minimal cost. There are a number of different angles to consider when making this calculation. While certainly not an exhaustive list, I’ve put together a few different points worth considering here.
Resource Constraints
Resources vary in how easy they are to acquire, retain, and replace. For many reasons, information security personnel are most often the scarcest resources an organization can have. Many people, including me, have written about the talent shortage in the information security field, and my point here isn’t to rehash those points. Rather, it serves to remind us how truly inter-connected each of the components of the people, process, and technology triad truly are.
When we develop technology internally, those resources generally need to be pulled from elsewhere. I don’t mean to imply that there aren’t times when technology should be developed internally – indeed there are times when this approach is appropriate. My point is simply that the cost of developing technology internally is most often higher than people realize. Beyond the monetary cost, there is also the long-term cost that results from pulling a resource off of important security work for technology development.
As an example, consider the case of an individual who is tasked with improving alert quality or performing a telemetry gap analysis – both of which are important tasks that contribute to the overall maturity of the security program. If that individual is subsequently pulled off of that task to develop technology, then that potentially impedes or delays the security organization’s growth and maturity. It is that hidden, long-term cost to the organization that is important to capture in any decision-making process. Regardless of which way an organization decides to go in the end, it is important for that organization to understand the costs and ramifications of the decision.
Scalability
When looking to implement a security solution, scalability is an important consideration. When most people think about scalability, they think about a solution’s ability to handle a certain throughput, a certain number of requests, or other similar metrics. While these are certainly important considerations, they aren’t sufficient to capture the concept of scalability. Scalability for a production solution also involves additional factors, some of which I’ve listed here:
• Tracking and prioritizing feature requests
• Adding new features
• Deploying in multiple locations initially
• Deploying in additional locations as required
• Identifying, fixing, and patching vulnerabilities
As we can see, scalability is a bit more complex of an issue than many may initially realize. It’s an important point to consider – success in a lab environment does not always translate to success in a real-world operational environment.
O&M
Operations and Maintenance (O&M) is another cost that is often overlooked. After the initial deployment of a solution, resources are needed to operate, maintain, monitor, and leverage that solution. While most organizations calculate deployment costs fairly well, there are many additional costs that come during the lifecycle of the solution and are too often overlooked or underestimated. It’s important to consider the Total Cost of Ownership (TCO), including all applicable people, process, and technology costs over the entire lifecycle of the solution when evaluating solutions. It’s not a simple calculation, but it is one that is extremely important when an organization is looking to make the right decision for itself.
The question of build or buy is not a new one, but it is one that does not adequately suit the implementation of a security solution. Rather, I would argue that we should be asking a different question: What is the right mix of people, process, and technology that will solve my problem at the least cost? The first step toward arriving at the correct answer, of course, is asking the correct question.
