To Build Or Buy Your Own Security Platform
Tim Armstrong examines the high level considerations that need to be addressed when building your security platform, paving the way for additional discussion around the build vs. buy question.
Join the DZone community and get the full member experience.Join For Free
What’s your priority: to become a Security Company or be a Secure Company?
If you’re truly in the security business, then of course you’ll be building your own security platform. For all the rest, please keep reading . . .
In this post I will cover some of the challenges involved in building a cloud security platform like Threat Stack. My goal is to give you a clear idea of what is involved and the complexity, so you can make a decision about building or buying that is meaningful from both an engineering and a business perspective.
Spoiler alert: In my view, the right choice for most companies is not to build their own security. Most should strive to become Secure Companies so they can get on with their core business.
But if you were to build...
Let’s begin with the basics. You’ll need resources. First in terms of software, then in terms of software engineers to make that software work. To begin, you’ll either need to find open source monitoring software, or write some. At its most basic, this software will need to take millions of kernel events from hundreds of systems, analyze them, and then provide some way for you to act on them. Some open source options exist out there, but you’ll need to understand how they work so you can assemble them into a functioning system. You could use Auditd, but we’ve already investigated why that might not be the best choice.
Here’s where things get even more challenging. You’ll need people with the domain expertise to turn raw telemetry into alerts. (And as anyone in the software security space can tell you, finding domain experts is extremely difficult right now. So you’ll have to make a decision about training internal personnel to be security experts or hiring outside experts.)
Back to the alerts.
Pulling meaningful alerts from various systems isn’t the biggest problem you’ll have. The bigger challenge will be making sense of the alerts and responding to them. You’ll need to take all the alerts you’re getting, put them somewhere, and then analyze them for security threats in real time. You’ll need to have the additional bits inside the tool to bubble up critical context. This is a large part of the return on your investment: Reducing Mean Time To Know (MTTK) saves headcount while also helping you respond more quickly. Probably the best way to do this is to build a behavior-based intrusion detection system with configurable rulesets. But in fairness, there are organizations out there that already have the expertise to build these behavior engines, and they also have the experienced security staff that’s needed to make those detections useful and keep them up to date for the latest threats.
And don’t forget 2-factor login as well as support for multiple browsers. And QA. And potentially, coverage for multiple flavors of Linux with different package managers.
Once you’ve got all this under control, you’ll need to write software to analyze your AWS configuration and compare it against Amazon best practices and CIS benchmarks, write a vulnerability collection database (read: scrape HTML and XML from third parties multiple times per day) and assessment engine, incorporate threat intelligence and geolocation capabilities, and create a means of collecting and displaying all this data in a single, easy-to-understand dashboard. I don’t mean to sound flip, but this is no small undertaking. If no one can understand your results, they won’t provide much help.
Most importantly, you’ll need to develop this security technology alongside your core business in such a way that it will scale with you. You’ll need to focus on the success of your organization and simultaneously maintain this security platform. Which brings us to . . .
This is an important one. Care and feeding of a large-scale data collection and behavior analysis platform, vulnerability database, and multiple expert systems is no small feat.
As new threats arise you’ll need to address them with new behavioral rules. New releases should ship multiple times a day. As new technologies become available, you’ll have to integrate them. You’ll need to have support staff available during all working hours, and these need to be people who really understand the inner workings of all your technologies and integrations. We’re DevOps-ing here! You’ll need QA again across multiple platforms and browsers. You’ll need to develop new features.
It’s a bit exhausting even talking about everything that’s required!
Much of the tone in this blog post has been a bit tongue-in-cheek, but the underlying considerations are not. The serious proposition here is that just because you could (possibly) build doesn’t always mean you should.
Building a technology that protects your organization is a complex endeavour and should not come at the expense of your ability to focus on your organization’s primary mission, core competencies, key differentiators, and ability to grow. We want to encourage you to take security issues very seriously. But we also want you to be realistic when determining how to become a secure company.
The security industry has evolved and matured over the last half decade to a point where cloud native, integrated, end-to-end solutions are available on the market, and the reality, as we see it, is that there’s little or no reason to build or assemble your own solution. (Most people won’t even make their own pizza when a high quality, reasonably priced, ready-made pie can be delivered directly to their door in much less time.)
Building several different technologies that reliably take in data, turn it into meaningful alerts, and provide context around those alerts is a very large undertaking. Making that technology perform at scale is even more daunting. And adding features like configuration auditing and vulnerability assessment, which you’ll have to deal with, adds layers of expertise that may only serve to distract from your main directive: making a great app that your customers will love.
In upcoming posts we’ll look at the Build vs. Buy question in more detail.
First we’ll dig deeper into the key functionalities that should be present in a purpose-built, cloud-native security platform. Then we’ll present three use cases that are intended to reflect the current size and state of your business along with the considerations you need to make around security and development at each stage.
Published at DZone with permission of Tim Armstrong, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.