Architecture Drift: What It Is and How It Leads to Breaches

Mitigate the risks of architecture drift with application security posture management

Originally published by CrowdStrike.

Cybercriminals work around the clock to discover new tactics to breach systems. Each time a digital ecosystem changes, it can introduce a weakness for a threat actor to quickly discover and exploit. As technological innovation progresses rapidly, and organizations expand their infrastructure, this weakness may take shape in the form of architecture drift.

Today, we explore the concept of architecture drift: what it is, why it matters and how application security posture management (ASPM) can help.

Why Architecture Drift Is a Problem for DevSecOps

The rise of continuous integration and continuous delivery (CI/CD) and infrastructure-as-code (IaC) means apps, clusters and environments are constantly changing across organizations. Architecture drift occurs when an app, microservice or infrastructure “drifts” out of its intended configuration or approved operating boundaries.

Drift is difficult to detect and it introduces risk, which often isn’t seen or managed until something serious happens, such as an outage, incident or breach. It can happen in a variety of places, including:

• Infrastructure
• Network
• Container orchestration
• Application runtime
• Business logic
• Data flow

Architecture drift may affect infrastructure, for example, when IaC scripts such as Terraform or CloudFormation get out of sync with what’s running in the environments. For example, a development team might use a CloudFormation script to provision a new environment that declares all EC2 instances should be “t2.small.” Meanwhile, an engineer decides to manually add a “c4.large” instance to the same environment. Because C4 compute instances cost significantly more than T2 instances, this change will increase the company’s cloud bill and possibly create problems with reliability and performance.

Business Logic and Data Flows Can Drift Too

Continuous development means code, business logic, data flows and application architecture can change hourly in your environments. Depending on the level of automation and guardrails in your CI/CD pipelines, engineers might deploy code changes on demand or be required to follow a review process should a change be significant. These code changes can cause assets to drift, potentially interacting with one another and creating new risks.

A single code change can introduce new:

• Services
• APIs
• Dependencies
• Libraries
• Third-party service calls
• Datastore or database connections
• Data flows
• Risks you might not have considered or thought about

Even tiny changes can have a big impact. For example, several years ago, a small code change resulted in a personally identifiable information (PII) exposure at an enterprise. The risk made its way into production because the engineer who committed the code change didn’t know their code touched PII and stated this in their change request questionnaire. As a result, they caused code to drift and interfere with data it shouldn’t have been near, unintentionally exposing the sensitive data.

We detect and observe drift frequently among customers of Bionic, a CrowdStrike company. More often than not, that drift is related to business logic, architecture and data flows. You can’t eliminate all risks in applications or the business, but you can start to go beyond what you know and think differently about what could impact your business.

Applications are complex beasts to tame, encompassing hundreds or thousands of components and dependencies. Every code change introduces potential risk. The question is: Do you see these risks and know their potential impact?

How to Detect Architecture Drift

With application security posture management, you can detect and manage application drift in real time. ASPM allows teams to quickly baseline and lock in their application architectures, so they have drift policies that can notify them in real time, should an architecture change. For example, ASPM can detect things like new services, APIs, new libraries, ports, connections, dependencies or even data flows that an application might start to exhibit following CI/CD deployments or code changes.

ASPM flags these drifts and provides full business and application context so your teams can prioritize the cruciality of critical services or data flows that are impacted. They can also visualize where each drift is occurring so teams see the full picture and catch drift before it causes a problem.