Proactive Security Is the New Black: Lessons from the Trenches of Building a Security Product
On this week’s episode of Security Nation, we had the pleasure of speaking with Alex Kreilein, CISO for RapidDeploy, a back-end SaaS service for 911 and emergency communication systems. Prior to this, Alex ran a small investment fund for cybersecurity startups. He also had his own company called SecureSet, which was the country’s first cybersecurity boot camp.
Here is our recap of the podcast:
Focus on prevention, not reaction
In Alex’s time as an investor, he and his team were looking at companies that were focused on preventative security. In his view, defensive security means you just didn’t do your job; if an alert pops up, it means something wasn’t done properly that allowed someone nefarious to get somewhere they shouldn’t be. Unfortunately, most security pros have given up because they’ve been told that proactive security is impossible and a losing battle. While it may be true, to say you’ve lost before you ever got started is a defeatist mentality.
To address this, Alex and his team at RapidDeploy—no relation to Rapid7— are working on configuration patch and vulnerability remediation management, two things many security teams brush off as “boring” or something they “don’t believe in.” With their cloud-native solution, they’ve taken the NIST 800-53 compliance controls and put them in a security system plan written in code. This enables them to machine-read and version-control it. Having everything machine-readable does a few things. The first is they can take the 159 NIST 800-53 controls and run almost all (140) of them through Terraform to write the controls as a CI/CD (continuous integration/continuous deployment) framework.
Let’s use a password policy as an example. If you want to enforce this on your cloud assets manually, you’d log into an interface, click stuff manually on a GUI, and scale that across all of your cloud assets. This means if you have 300 cloud subscriptions, doing that across all of them by hand is very complex, labor-intensive, boring, and prone to human error.
What Alex is doing is building out a process that empowers what humans are really good at: communication, context, and creativity. So, once all of the controls are in Terraform, they’re shipped off to the DevOps team to use as a template that can be implemented through CI/CD. This injects the controls into the cloud assets and configures them to the cloud infrastructure. Separately, using tools like Puppet, Chef, or Ansible, they can configure the operating system environments and how Kubernetes runs. This means that if the security team wants to implement a control, they can do so as guardrails so that developers can do things, but within certain parameters. This creates what Alex calls a “box of safety.”
As a security professional, you’re often thought of as the “no” police, which also feels like it sets the engineering team up for failure. Alex is breaking that mold altogether by flipping the model on its head with controls set up in the environment upfront, as opposed to waiting for things to happen and then scrambling to fix them.
This approach can also help during an audit with clearly printed controls and scripts for things like configuration management or token management.
Onto vulnerability management and automation
Alex hopes ultimately this can be tied into the vulnerability management lifecycle, too. For example, if a vulnerability pops up, how do you define success? One way is by segmenting infrastructure into risk groups. You can choose to only let VMs live for 30 days, or to not accept any risk. You can also define it by if a virtual machine is in VNET and it is less than 30 days, let it live. If it’s more than 30 days, rehydrate it. This can be done through automation.
Automation is another area Alex sees security professionals struggling with. We talk about automating this and that, but all we do is PowerShell, Bash and CLI, which are administration, not automation. Instead, focus on things that are reproducible and highly scalable automated process and then apply them through PowerShell, Bash, CLI, etc.
Advice on starting a new security project and getting buy-in
Alex is no stranger to starting new projects, and in our podcast interview, he offered several great tips. The first is to sit down and actually design the thing you want to create. He said 90 percent of the time, people rush right into implementation, but to do it right, you need to document the architecture of it first. You also want to define what your acceptance criteria is and what success looks like. This may mean not needing to hire 75 security engineers, or using highly automated and repeatable processes.
Next, figure out how much it’ll cost to implement. If you’re looking at a $165,000 project but your whole security budget is $170,000, it won’t work. You should also compare what you want to build against pre-existing solutions so you can determine whether it’s cheaper to build it, buy it, or partner with a third party. You also want to do a total cost of ownership analysis and a return on security investment (ROSI) analysis. This is different from ROI—ROI is if you spend $5 and make $50, you have a profit of $45. Security investment thinking is radically different because you need to think in terms of security improvement, not necessarily a dollar amount.
Third, make sure that what you’re doing is actually different from what’s already on the market. Too often, Alex is pitched products that he knows already exist in the marketplace, which doesn’t make sense from a business perspective.
Once you know what you want to build, that it’s markedly different from what’s already on the market, and that you can make a return on the investment by doing it yourself, you’ve removed the friction and can take it to your CTO or CSO for buy-in. Whether or not you actually get buy-in, the conversation is much more productive and you build rapport with your CFO or CSO, which will help you the next time around.
Listen to the full interviewWe’d like to thank Alex for sharing his story. To hear Alex’s interview in full, be sure to check out our latest episode of Security Nation, and if you like what you hear, please subscribe!
