Security cannot exist in a vacuum. If an organization’s security is dictated from one room, one group of people, the value of shared responsibility is lost. So says Alex Kreilein, the Chief Information Security Officer of RapidDeploy, a “computer-aided dispatch” company which serves the public safety market.
Randori sat down with Alex to discuss a variety of topics, including the foundations for good security and the need for continuous vulnerability management. Part one of our interview is below, where Alex discusses how he helped build the security infrastructure at RapidDeploy with an eye toward best practices and shared responsibility.
Editor’s note: The following are Alex’s words. The transcript of this interview has been lightly edited for brevity and clarity.
On Building a Security Foundation
An easy first step for us was to focus on the system architecture. So even before we got to training, we really made sure that we had a tight, tight system architecture and that we also have a really solid process for a hatching and monitoring and incident response based on the six principles of the center for internet security:
Identify What’s Running in our Environment
We care very much about identifying all hardware and software running in our environment. Most organizations tend not to even begin there, but it’s really hard to protect your attack surface when you don’t have a good understanding of what’s inside of your perimeter.
Inventory and Control of Access to Assets
Poorly controlled machines are likely to be either running software that is unneeded for business purposes (introducing potential security flaws), or running malware introduced by an attacker after a system is compromised. We make sure to inventory control access to hardware assets and software assets, identifying them.
Continuous Vulnerability Management
We always try t0 do continuous vulnerability management. We have our our list of all of our infrastructure across multiple environments inside of the company and we run a process to look continuously for known vulnerabilities. If there are known vulnerabilities then we attempt as best we can to mitigate that risk by patching and vulnerabilities in some methodology that’s important to us.
Controlled Use of Administrative Privileges
We would like to try and control administrative privileges. We’ve locked down privileges really tight. People who are on finance and accounting teams do not have developer team environment credentials and people who are in developer team environments do not have finance credentials.
The Chief Technology Officer of our company—even though he’s a cofounder—does not have finance credentials. We’ve made sure that people have least privileged access to instances and information and we enforce that tightly. But we also go beyond that too. We don’t just enforce their privileges on our own infrastructure.
Secure Configuration for Hardware and Software on Employee Devices and Servers
We only sign contracts with third parties for services if they use SAML [Security Assertion Markup Language which allows for Single Sign On functionality]. We enforce a certain type of identity access management. We’re willing to pay more for a CRM for us to be able to use SAMLs and integration because we don’t want rogue passwords or rogue authentications just roaming around our organization as it grows and grows.
Where we struggle is in the secure configuration of all devices. We make a real attempt and effort in doing secure configurations, but we use third-party products to do that with us. We take it seriously to manage all of the phones, laptops, desktops and then all of the stuff that’s in our server environment, in the cloud and all of the routers, switches and firewalls that are on premise. We’re going to make sure that we have very few vulnerabilities, but also that we’re managing the infrastructure continuously.
Practice Monitoring, Logging and Analysis
The last piece that we’re turning on right now is a monitoring and logging and analysis. Everything that’s in our environment, we can pull logs off of it and we can see those logs in some sort of engine that allows us to say, “these were our areas of attack.”
This is how we could be vulnerable, this is how they could get in. Next time let’s make sure that we’re closing off those ports or let’s make sure that we’re setting better access control on those applications. Or whatever that point of ingress. Let’s be smart and manage that and understand that attacks will happen. But because we have a defense-in-depth strategy, our hope is we’ll catch attackers somewhere between their first initial access and their objective.
Empowerment is Greater Than Control
I absolutely don’t believe in building security organizations. That just creates a new organizational problem. If I were to build an ideal security organization, they would have rights and access credentials, but very little of their job would be to use it. Their job would be mostly to work with IT and make sure that they’re empowered to make the right decisions.
At RapidDeploy, we actually don’t consider ourselves to be “security” employees, yet security is part of the consideration process for every decision. Instead of setting up a separate security department, I’d rather give people resources and be available to help them follow through on our requirements giving solid resources to meet those expectations. Every Microsoft Office Admin, every DBA, every network admin that we have, I required them to work these tools with a defined set of security objectives, instead of creating one security team that tells them what they can and cannot do.
When security is a shared responsibility, it trickles down to building a stronger culture, a stronger product and a stronger response team. Especially when the people on the other end of the line are relying on you above anyone else.