Secure by Design – Part 2

Why the Most Critical Systems in Your Infrastructure Are Often Not Productive

In the traditional understanding of IT security, productive systems were always the focus of attention. Databases were hardened, network segments isolated, and applications secured against external attacks. The assumption behind this was as obvious as it was plausible: To protect critical data, you must protect the systems that process this data.

This perspective was correct for many years.

However, with the advent of Cloud Computing, Infrastructure as Code, and highly automated platform architectures, the distribution of responsibility and control within modern infrastructures has fundamentally changed. Today, infrastructure is no longer primarily administered but defined. Resources are no longer provisioned manually but created through declarative descriptions. Changes are no longer made by administrators on individual systems but through pipelines, automation platforms, and runtime environments.

This has also shifted the actual power within modern IT landscapes.

Whoever controls the automation today controls the infrastructure.

The Shift in Control

To understand the significance of this development, it is worth looking back over the past few years.

In traditional data center environments, the compromise of a single system was often already a significant security incident. Administrators worked directly on servers, configurations were changed locally, and many systems had clearly defined areas of responsibility. Even privileged access was often limited to individual platforms or applications.

Modern platform architectures function differently.

A Terraform process often has permissions to create entire networks, databases, and Kubernetes clusters. CI/CD systems can roll out productive applications worldwide. GitOps platforms determine the desired state of entire environments. Automation systems manage operating systems, middleware, and security policies across thousands of systems.

The result of this development is remarkable.

While the number of individual systems continues to increase, the actual control over these systems is concentrated on fewer and fewer platforms.

From an attacker’s perspective, this creates a completely different threat model.

The compromise of a single server grants access to just that server. However, the compromise of an automation platform can have implications for the entire infrastructure.

The Paradox of Successful Automation

The more successfully an organization automates, the more permissions are concentrated within fewer systems.

This connection initially seems contradictory but is the logical consequence of modern operational models.

Automation aims to reduce manual interventions and operate infrastructure consistently. To fulfill this task, automation inevitably requires extensive permissions. A platform cannot provision infrastructure if it is not allowed to create resources. It cannot configure systems if it lacks administrative access. It cannot perform deployments if it does not have the appropriate rights within the target environments.

The more companies rely on automation, the more important the question becomes of how these privileged systems themselves are secured.

Interestingly, many security measures still primarily focus on production systems, while the platforms that control these systems comparatively rarely receive the same attention.

Yet they often have greater reach.

This comparison illustrates why modern security architectures are increasingly moving away from a purely system-centric view.

The crucial question is no longer solely which systems need to be protected.

Rather, it is which systems have the ability to control other systems.

Why Permissions Alone Are Not an Adequate Security Model

Many security concepts implicitly rely on the assumption that privileged systems are trustworthy as long as only authorized individuals can access them.

This assumption increasingly fails to meet the requirements of modern platforms.

The number of technical components between the user and the infrastructure is continuously growing. A single infrastructure change today can be processed across multiple Git repositories, CI/CD pipelines, Container Runtimes, and automation tools before the actual change becomes effective in production.

At the same time, the importance of traditional user accounts is decreasing.

API tokens, service accounts, machine identities, and automated workflows are increasingly taking over tasks that were previously performed by administrators. The actual security problem is therefore no longer solely who has access.

The crucial question is under what conditions this access can be used.

Privileged access that cannot be traced poses a significantly greater risk than highly restricted access with full transparency.

Security is therefore not created by permissions alone.

Security is created through controlled execution.

From Access Control to Execution Control

This distinction is gaining increasing importance in modern platform architectures.

Traditional access control answers the question:

Who is allowed to do something?

Secure-by-Design approaches expand this perspective with an additional dimension:

Under what conditions is something allowed to be executed?

This shifts the focus from identities to processes.

No longer is the person or system solely in focus, but the complete execution context.

Which runtime was used?

Which version of an artifact was used?

What parameters were passed?

Which systems were affected?

Which identities were used?

Only when these questions can be answered does the foundation for robust governance and comprehensible security decisions arise.

Why Auditability Must Be a Technical Feature

Many organizations still view auditing as a compliance issue.

In fact, it is a fundamental technical feature of modern platforms.

The more infrastructure is automated, the more difficult it becomes to retrospectively reconstruct the origin of individual changes. Between a commit and a productive change today often lie numerous technical components, each with its own states, dependencies, and permissions.

Without systematic recording of these relationships, any form of incident response becomes significantly more difficult.

The real challenge is not in collecting information.

The challenge is making the relevant information available during execution.

Auditability can therefore only be added to a limited extent retrospectively.

It must be part of the platform architecture.

Secure by Design Means Control Over the Control Systems

The past years have shown that the architecture of modern infrastructures has fundamentally changed. While security strategies long focused on productive systems, the actual control is increasingly shifting to platforms that create, change, and operate infrastructure.

This development does not make automation insecure.

It merely changes the places where security must be established.

The most critical systems of an organization today are often not those on which applications run or data is stored. They are the systems that decide which applications are rolled out, which infrastructure is created, and which configurations become effective in production.

Anyone who talks about Secure by Design must inevitably talk about automation. And anyone who talks about automation will sooner or later come to a central realization:

The most important security question of modern platforms is not which systems are controlled.

The most important security question is who controls the systems that control everything else.