IaC Cloud Misconfiguration Tools too Noisy without Context

Analyzing Infrastructure as Code (IaC) to detect cloud misconfigurations is one of the hottest topics in cybersecurity. An entire industry has popped up around this single topic — and for good reason! But today’s IaC tools analyze security configurations in a limited, myopic way that generates noisy alerts and does not help organizations understand their risk.

Evaluating cloud infrastructure configurations without context is meaningless. The risks of cloud infrastructure and the applications that run on it are inherently connected. An effective understanding of risk requires connecting the dots between the applications and their infrastructure, from design to code to cloud.

Cloud Misconfigurations and Infrastructure as Code

Cloud misconfigurations are one of the greatest risks when it comes to cloud computing — not the underlying infrastructure. The issue comes from the speed of cloud adoption and cloud native development. VMs and containers are created and destroyed in near real-time. Entire environments can be spun up and existing environments duplicated, including complex architectures and configuration settings. But traditional means of securing these environments can’t keep up.

It’s time to stop thinking about application security and infrastructure security separately.

Cloud environments can be as secure — or more secure — than traditional on-premises environments, but agility, speed, and absolute consistency are required on the Security and Privacy side. This means automation and IaC, which help prevent manual configuration errors. The idea of IaC has been around for quite some time but it isn’t until now that security is beginning to catch up and make use of its potential.

The Problems with Today’s IaC Security

The issue with the Cloud Security industry is that it focuses on only one aspect of the problem and lacks the context needed to help organizations make risk-based decisions. A cloud environment never exists in true isolation from a security perspective. There are numerous factors that may impact the business risk of a breach, including:

• The type of applications that are deployed in the cloud (HBI, MBI, LBI)
  
• The type of data that is stored and/or processed in the application (e.g., PII, PHI, etc.)
  
• Compliance requirements (e.g., HIPAA, PCI, and GDPR)
  
• Whether the application is internal or Internet-facing
  
• Additional services that function as part of the application’s architecture, such as a cloud-based firewall, an API gateway, or identity provider
  
• Upcoming features that may change any of the above (such as a user story that calls for adding a new PII field)
  

The lynchpin of current solutions of detecting IaC cloud misconfigurations are single-dimensional. They look at individual factors, such as a storage bucket missing encryption, connections being unencrypted, etc. But without context, these alerts are just noise. In an ideal world, all data-at-rest and data-in-transit would be encrypted using the latest algorithms and frameworks.

In the real world, where Security Engineers are overwhelmed with alerts, prioritizing based on risk isn’t a “nice to have” — it’s required. Some data are more sensitive and business-critical than other data and any security tool that can’t effectively make that distinction is failing.

For example:

• If a connector is unencrypted but isn’t exposed to the outside world, the priority of fixing this “misconfiguration” may be low. A single-dimensional scanner won’t be able to correlate those two facts to prioritize appropriately
• Data on internal catering orders or past events may not need to be encrypted while encrypting customer data and financial information is critical. At an even more granular level, it is critical to encrypt a storage bucket that does not contain sensitive information but did in the past!

The point is that risk is multidimensional and existing cloud security tools can’t keep up.

App and Infra Security

It’s time to stop thinking about application security and infrastructure security separately. Individuals and teams cannot be assigned to one area or the other and be expected to succeed. App and infra security people, processes, and tools need to work together seamlessly in order to build an accurate view of risk:

• To improve visibility, inventories of application and infrastructure components need to be combined into a single source.
• Having separate lists of alerts for code vulnerabilities and cloud misconfigurations — from separate tools — leads to siloed processes, thinking, and activities. The wrong things get remediated at the wrong times while critical risks get missed. Alerts from across the entire SSDLC need to be analyzed and prioritized in a single place.
• Risk assessments and change management processes need to include both application and infrastructure data

Watch any experienced Security expert investigate a potential security risk and it will soon be obvious that context is everything! But an understanding of that context shouldn’t be left to manual reviews. Contextual risk assessments of both application and infrastructure code changes need to be performed both continuously and automatically. This is the only way to provide consistency, efficiency, and ultimately, remediate the app and infra risks that matter.