How to securely onboard customers during a cloud security solution migration

For a company running an application in the cloud, replacing their security tool comes with a couple of big concerns. First, there is no margin for tool downtime during the transition — operating without perimeter defense could provide an opening for attackers. And second, dealing with two security tools simultaneously can be even more challenging. Security tools tend to be intrusive, and the concurrent manipulation of kernel modules and eBPF probes by two tools could lead to complications.

Companies do not want to expose themselves to breaches or performance issues, which is why replacing a security tool can be a tough prospect. But in an industry where attackers (and attack surfaces) are constantly evolving, moving at the speed of the cloud is crucial.

Meeting our customer’s business needs

In November 2023, a new customer joined Sysdig. Over the past few years, the customer expanded their operations, employee roster, and their business. These were all positive changes, but with growth comes pain. 

The DevOps program that worked well for an early-stage startup could no longer support a mature organization that had to protect more resources, safeguard more customers, and potentially deal with a new reality as a very attractive attack prospect.

With these priorities in mind, the customer chose Sysdig for posture management, as well as runtime threat detection.

In addition to adding posture management and cloud detection and response capabilities, we learned that the customer was a heavy user of AWS-managed services, so the ability to detect events from AWS quickly was critical. 

We immediately set up a series of introductory calls with them in order to create an onboarding strategy. During our call, we learned we had less than six months to complete the full transition, all while ensuring the essential cloud security solution replacement requirements were met.

Non-negotiables for replacing a cloud security solution 

When replacing a security tool in the cloud, there are several concerns. But whether the organization is migrating from an OSS tool or a specific vendor, there are three critical requirements that must be fulfilled:

• Achieving feature parity between tools — The new solution needs to deliver the same baseline capabilities as the existing solution, while addressing additional needs that the organization has. 
• Making sure that there is at least one tool active at all times — This is a fundamental requirement to ensure the environment is protected during the transition and is not being exposed to attacks. 
• Making sure resources are available for all other applications — Ensuring that resources are available to operate other software is imperative during the migration.

How we built a plan of action 

The first thing we did was assess the expectations, priorities, and needs of the customer. We knew we had to move fast, and we needed to ensure that all features were effectively in place, and that we had coverage for AWS-managed services.

We reached out to our Sysdig engineering team and established a dedicated task force to fulfill these requirements.

The task force worked quickly to create a roadmap for a smooth migration:

• A tailored approach — With limited time, we had to work smart and identify what components that had to be included and when.
• Leveraging automation — Using Helm and Terraform, we were able to deploy our components across their infrastructure much faster and more efficiently.
• Custom updates — Working with our engineering team, we customized some of Sysdig’s components to ensure a smooth migration.

Up and running in six weeks 

From firsthand experience managing countless tool migrations, we know that there is no one-size-fits-all method. After the basic requirements have been met, we have to customize the approach to the individual environment, infrastructure, and business needs.

Once we had a plan, the Sysdig team got to work, along with our champions and collaborators on the customer team. 

Within six weeks, we implemented product features and enhancements. The customer’s memory usage was reduced by 20% compared to what it was with their previous tool. And Falco rules made a big difference for our customer; they were able to create custom rules for their CDR compliance. 

How our automation processes accelerated the migration process 

Among the real heroes of this story are the Sysdig automation processes that leverage Helm and Terraform. But what are they?

Helm is an open-source graduated CNCF project now known as the package manager for Kubernetes, focused on automating the Kubernetes applications lifecycle in a simple and consistent way.

Terraform, on the other hand, is an infrastructure-as-code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently.

Automation is key for swift and efficient tool management in the cloud. At Sysdig, we believe that the future of cloud security is open, which is why everything we do has an open-source angle.

Continuous collaboration and communication are the keys to customer success  

Implementing this plan required cross-team collaboration, as well as a fair bit of engineering. However, the most important aspect was continuous communication with our customer. 

In the first edition of this series, security is a team sport, we talked about how a cloud security vendor needs to be a full-fledged business partner. It’s the customer’s engagement in this migration process that was instrumental to its success. 

As customers adopt Sysdig, our Customer Success team is dedicated to supporting them throughout their journey. We prioritize maintaining continuous engagement, keeping open lines of communication, and enriching their experiences with the Sysdig team.