Avoiding Technical Security Debt During Cloud Transformation – InApps 2022

Prisma, from Palo Alto Networks, sponsored this post.

Cloud transformation, or the process of migrating workloads to the cloud, creates a number of benefits — including greater agility, scalability, and infrastructure centralization.

But cloud transformation can come with a downside: it leads to technical security debt (and other types of technical debt) that gets overlooked as businesses “lift-and-shift” legacy workloads into the cloud — often without fully or genuinely migrating those workloads to a cloud native architecture.

Here’s a look at the types of debt that cloud transformation can cause, especially in the realm of security operations, and best practices for avoiding it.

Cloud Transformation and the Creation of Technical Security Debt

Migrating workloads to the cloud means changing not just where they are hosted, but the entire technology stack that powers them. Your monitoring and deployment tools will change, or at least expand, to include the solutions offered by your cloud host. Your application architecture may change if, for example, you migrate from VMs to containers. Application lifecycle management may change too if you leverage the cloud to enable faster updates.

Changes like these are part and parcel of the benefits that cloud transformation enables. But they can also leave you with some rough edges in your technology stack that create technical debt.

To contextualize this risk, consider the following examples of ways in which technical security debt — meaning inefficient security processes that, when repeated on a continual basis, hamper your ability to keep security operations lean, mean and effective — could arise during cloud transformation.

More Complex Monitoring Tools

When you undergo cloud transformation, you may be tempted to keep using your old monitoring tools, which you know and love, while also adopting new, cloud-based alternatives — like those offered by your cloud vendor. Indeed, sometimes you have to use the vendor’s tools even if you also use a third-party monitoring solution, because only the vendor’s tools can collect all of the data that you need. By adding more tools to the mix, you create more moving pieces and more panes of glass for the security team to work with. This makes security operations less efficient, creating technical security debt.

Less Isolation

In an on-premises environment where each workload is neatly isolated on its own bare metal server or virtual machine, there are few points of convergence between workloads that you need to manage from a security perspective. Each workload has its own physical or virtual hardware resources, storage, network, and so on.

You lose this benefit if, as part of your cloud transformation strategy, you migrate to containers or serverless functions — which are not as strictly isolated and are more likely to share resources like storage and networking. In turn, the burden placed on your security team increases, making it harder to monitor and manage vulnerabilities efficiently.

Cloud Native Applications That Aren’t Really Cloud Native

There are two ways to build a cloud native application. One, which requires more resources than many teams have on hand, is to write it from scratch to run on a cloud native architecture. The other is to take a legacy application and shoehorn it into a cloud native “wrapper.” For example, you could take an application that you deploy on-premises inside a VM, move it to a container, deploy it on Kubernetes, and call it cloud native.

The latter approach is relatively easy to achieve with limited time and resources, but it creates technical security debt, because it involves taking an application that was not written with cloud native security risks in mind and running it on a cloud native platform. Your security team will be left to plug the resulting gaps by hand, constantly monitoring for security problems that the application’s original developers never even thought about, because Kubernetes wasn’t even a thing when they were writing the code.

Hybrid Architectures

In some cases, cloud transformation involves not a wholesale move to the cloud, but instead, a piecemeal approach wherein some parts of some workloads are migrated to the cloud while others remain on-premises.

In the latter case, you end up with a hybrid architecture that creates technical security debt, because your security team has to manage two distinct hosting environments and their associated technology stacks — all while handling vulnerabilities within the APIs that bind the hybrid environment together.

Less Security Testing

Sometimes, the pressures that IT organizations face to move to the cloud at all costs can lead them to sacrifice security testing. If your boss tells you that you need to have your legacy application running in AWS by the end of the quarter or else, you may decide to skip some of the security testing and analysis that you’d perform if you had a longer timeframe.

Less security testing means a higher likelihood of security issues that pop up after you’ve made the migration, creating more debt for the security team to manage.

Mitigating Technical Security Debt During Your Cloud Migration

To a degree, a change as momentous as cloud transformation will necessarily involve some amount of technical debt. No migration is perfect, and you shouldn’t expect that there will be no hiccups.

Nonetheless, you can take steps to minimize the amount of technical security debt you’ll face during and after the migration of some or all of your workloads to the cloud:

• Consolidate your security tools: Instead of trying to juggle different security tools for different parts of your architecture, adopt a toolset that will allow you to monitor and manage security issues across on-premises and cloud-based environments consistently.
• Take cloud native seriously: If you decide to make an application cloud native, invest the resources in making it truly cloud native. As noted above, trying to squeeze a legacy codebase into a wrapper that makes it appear that cloud native is not worth the security risks or hassles it will create over the long term.
• Communicate between IT and security: The IT team is usually the main driver of cloud transformation (developers may play a lead role, too, depending on how important cloud architectures are to the code they write). The security team may or may not be consulted extensively before the migration begins. To avoid the sorts of pitfalls and oversights that contribute to security technical debt, the security team should be plugged into the cloud transformation conversation from the start. Giving security a prominent voice will also help ensure that you don’t skimp on testing.

Again, you can’t expect to prevent every piece of technical security debt from creeping into your cloud transformation process. But you can avoid the bulk of security inefficiencies, by planning ahead and making efficient security operations just as much a goal of cloud transformation as other types of IT efficiencies.

Feature image via Pixabay.