The Build vs. Buy Decision: A Security Practitioner’s Point of View

Throughout my career, I’ve had a repeated conversation at yearly budget planning time. This conversation comes up when I want to invest in a new capability and we either have a) some internal employees that think they are capable of writing scripts, b) are long term sysadmins (a special breed), or c) we have had a true development organization that has historically built operational tools. This conversation? Whether or not we should buy a tool or we should allow the team to build a tool. Choosing to build or buy a mature security solution is a difficult one. Especially so if you come from an organization that has not had an increase in information security budget while the risk landscape has been increasing. If you have budget to spend, you are deciding to invest your capital spending vs investing your internal operational or development resources to build a set of capabilities. The following points have helped me direct the conversation and might help you finalize your decision on where best to use the funds and people you have available. I don’t want to make this a CAPEX vs OPEX decision, because that’s up to your finance team, so I want to focus on situational reality.

Seven scenarios that support a “buy” decision... you should buy if:

1) You need a solution that has already been proven in “Fit for Use” testing and allows your company to focus on “Fit for Purpose” testing. This means you can be confident that the product is already fully functional because a mature product has likely been fully tested by many organizations out there, including government entities, and they have very likely tested the product in a much more rigid way than you ever could. Your “Fit for Purpose” testing can be on testing can be on your specific use cases or your highly-customized environments. 2) You work in a publicly-traded, government, or highly-regulated environment that must utilize software that has gone through full third-party validation and conforms to a known industry best practice set of guidelines such as Common Criteria, COBIT, ISO, or NIST. Auditors, Boards of Directors and regulatory bodies understand known purchased solutions as they can assume the product has already passed others’ scrutiny as well. 3) You prefer to rely on a few key strategic partners you can trust and delegate some of the responsibility to the partner/vendor. By setting your use cases and expectations early, and looking for the partner to provide services and capabilities that meet your needs, you can direct your focus toward projects/efforts that bring business value. In my view, developing something that others have already created is not the best use of resources or money and is not delivering the best business value. Focus your time on business efforts instead. 4) You have capital funds available and need to deliver against a financial model that includes multiple year pre-paid hardware, software, or maintenance in a capitalized financial model. 5) You wish to contribute back to the industry, but cannot do it directly. Developing a partnership with a software company is your opportunity to improve the industry. Information security professionals have an obligation to use their learnings to provide back their knowledge through use cases, education, and experience so that we can reduce the overall risk of data breaches or other impactful Provide your learnings back to the vendors, conferences, and partners so that they can learn and adopt and improve. 6) You are forbidden from using open source software, or there is a strong push against utilizing certain types of licenses outside of NDA and contract agreements. 7) You are expected to deliver certain types of software to meet auditor expectations. This might be software that is considered “expected” or “table stakes” that provides foundational services and should just be bought so that you can move on to deliver functionality rather than inventing and testing. It is important that once you purchase a solution or a tool, you should focus your energy on making it work. Rank your use cases, start to execute, and partner with your vendor through relationships and tickets if there are issues. I’m a fan of solutions that work together and have learned that filling your company with a ton of best-of-breed solutions that don’t fully integrate leads to lack of delivery. At some point in the future, I’ll write some more about best-of-breed versus strategic platform/solutions.

Six scenarios that support a “build” decision, you should build if:

1) Your organization has permanent development resources with the technology skill in information security. It is a non-trivial activity to build information security products. That said, you should only build capabilities that are enhancements or deliver automation on top of embedded or open source solutions that must be truly unique to your business line, complexity, or scale. Don’t bother building something that someone else has already built. “Not created here” is a bad disease in my book. 2) If funding is simply not available or if solutions are simply too cost-prohibitive to buy at scale, consider other options such as immutable VM, edge controls and protecting other important areas of attack, rather than each individual host. Open source solutions are possible here, but be careful because they might lack enterprise features you require. If preventative controls are out of reach, at least turn on all of the logging-based detective controls that come with your operating system. 3) Depending on your specific organization, you might have some specific requirements that need your unique skills in machine learning, user behavior, high speed data or processing analytics that it may make sense to extend a product or develop additional capabilities. I think of AWS, Google, Facebook or Microsoft when I think of these things. 4) You’re a university, partner with universities, or a startup that is developing or conducting advanced research that advances your company mission. 5) If you research and discover something unique and want to invest in a patent portfolio or have need for a certification that no one has yet to obtain. 6) If open source solutions have improved beyond all vendors in the space and it is a standalone product that is very specific to its use case, it might make sense to adopt the more mature open source tool. BIND, Linux, nmap are examples. In general, my personal preference is to purchase solutions and invest my time in delivering against the use cases my company requires. I understand the innate desire to create and develop solutions, but also know my limitations and know there are those who have invested much more skills, resources, and capital in solutions. Information security specifically is a non-trivial area and I do not believe it is an appropriate use of time to attempt to recreate what companies have invested millions to build. Very few organizations have the capability to create/build and deploy open source security solutions (not simply to use them), so I think it makes much more sense to partner with someone who has proven technology and hold them accountable for it working. No matter which you choose – build or buy – make sure you turn it on and look at the output! SOME protection is better than NO protection. Suites of products, such as those delivered by BeyondTrust, can be a great strategic investment for your company. These solutions combine vulnerability scanning (Retina), privilege management (PowerBroker), password management (Password Safe), and advanced intelligence (BeyondInsight) to deliver an integrated set of features that no other vendor provides. Rather than invest in building solutions that do not fully deliver the strategic capabilities your company requires, have a conversation with us on how we can partner with you to quickly execute.