Checking for misconfigurations isn’t enough

Misconfiguration errors are often the main focus of security for cloud-native applications, and for good reason.

Earlier this year, Hobby Lobby accidentally exposed 136 GB of sensitive data for 300,000 customers. Artwork Archive was recently alerted that an Amazon S3 bucket with 200,000 files in it was left open, although it was found by a cybersecurity firm and not a threat actor so the issue was quickly resolved.

Massive amounts of data are potentially vulnerable due to misconfigurations and, according to recent research, 32 percent of cloud professionals think misconfigurations will rise within the next year.

Despite the many high-profile breaches caused by misconfigurations, focusing security simply around fixing these errors often ignores the larger security issues in the entire application architecture. It’s akin to a building inspector checking that all the doors have locks without bothering to make sure the structure is sound.

We need a more dynamic and comprehensive approach to security in cloud-native applications, and it starts with acknowledging the limitations of detecting misconfigurations.

The problem with focusing on misconfigurations

There are plenty of tools that check for misconfiguration errors. They compare static, hard-coded rules against specific configurations within an environment and have helped organizations catch the kind of mistakes that lead to highly publicized and damaging data breaches.

But there are several issues with this approach. First, misconfiguration checking only goes an inch deep, in assessing if a given application meets its security requirements. Ensuring that security is comprehensively assessed requires a different approach.

Checking for misconfigurations also doesn’t scale. To truly cover your environment and evolving use cases, you need to create more and more rules, until you have thousands of them. At that point, there are likely to be many applications where those rules don’t apply.

Static rules are not tailored to the application and its needs, so this leads to false-positives and an over-prescription of security that is not commensurate with the risk, eroding trust in the security team. The example I like to use is the company’s cafeteria menu application, one that is open to the entire workforce and does not deal with business-sensitive data. This application does not require the same level of rigor from a security standpoint as the company’s most business-critical application. However, it still needs to meet a minimum-security baseline and it needs to be appropriately isolated and segregated to ensure that a compromise of this application does not impact the business.

So you create exceptions, until you have thousands of those too. It starts to become unwieldy.

The bigger problem with this kind of reactive, static approach to security is that it lacks any understanding of your business, the application, and your compliance needs. Not to mention that applying thousands of rules and hundreds of exceptions is time consuming and inefficient. We certainly need to check for misconfigurations to avoid the unforced errors we see in the news so often, but security shouldn’t stop there.

The divide between development and security

The problem is that identifying misconfigurations is relatively simple compared to securing the entire application architecture.

Pressure is greater than ever for application development to happen quickly. With IaC, developers are empowered to take more ownership of the entire application lifecycle via cloud services and features, like compute, storage, and other capabilities. This allows for an even quicker and more efficient process for them.

Security, however, hasn’t reached the same velocity. They’d still prefer to go off and analyze the application design and make recommendations before developers can proceed. This has left developers with two options when it comes to security: they can wait for security teams to catch up to them while business momentum comes to a halt, or they can go to market first and worry about security concerns later.

Clearly, neither is a great option. But it shows why so many organizations take a narrow and reactive approach to security.

How to achieve more dynamic, comprehensive security

Applications and their architecture are constantly evolving. The static rule-based approach of checking for misconfigurations doesn’t have any context for these changes and is always applying the same policy to every application. There is no way, using that method, to apply tailored best practices that comprehensively address the security and compliance needs of the application.

The solution is to focus on architecture rather than just misconfigurations. This is the first step in a shift to more comprehensive security. It means automating your visibility into the interdependent components of the application architecture to ensure the whole is secure. You need to check the locks on the building but also that the walls can bear the load.

Security is an emergent property of a complex system. Individual configurations are an important piece of the overall architecture, but viewing the bigger picture allows you to prevent the security debt that can build up from one version of an application to the next.

In that way, addressing security in a holistic fashion allows you to catch foundational gaps early. If you’re only catching security issues after deployment, you’ve already exposed yourself to risk. It’s also much more costly to fix any issues you find, and development teams won’t be thrilled to revisit the application.

But if security teams get visibility early on, when the developers and the application architects are designing applications, both teams can understand the capabilities, features, and components that are being utilized and act quickly to implement best practices.

They’ll also better anticipate how applications change to address shifting business needs, new compliance standards, and evolving customer requests. You can address security from square one and constantly update it within the application’s lifecycle. There is no need to have security teams and developers working separately and taking double the time.

Misconfigurations have long been a cybersecurity risk and deserve attention. But we need to expand our approach to security to take a more dynamic and comprehensive approach to secure the entire application architecture.