Observability before fragility, this is how to build secure clouds.

Building contemporary software applications is a complex process. Despite the rise of low-code/no-code platforms and a whole firmament of software application development and data analytics automation channels, we still exist in a world where systems are created with instabilities, fragilities and incompatibilities.

With ERP systems very typically supporting mission-critical use cases – which in some scenarios straddle and support life-critical software deployments – the need to assess where the pressure and pain points are in the modern IT stack has never been more pressing.

But where do we start? Is it a question of the surface-level interactions at the “presentation layer” and the way we manage what users are capable of doing inside their chosen application’s user interface? Is it the middle-tier networking layer and all the application programming interface (API) connections that now form neural joins between data, services, operating systems and applications themselves? Could it be the lower substrate base of our technology infrastructures and the way these are now engineered to perform in essentially cloud-native environments? Or, inevitably, is it perhaps all of these tiers and all the internal connection points within them?

Syntax to system semantics

Spoiler alert! No prizes for guessing that it’s obviously everywhere. Code fragility manifests itself in a seemingly infinite variety of forms and functional formulations from syntax structures to higher-level system semantics. Given the Sisyphean challenge ahead then, shall we at least start at the foundation level with infrastructure?

We need to build enterprise technologies based upon infrastructures that work as ‘dynamically orchestrated entities – Sumedh Thakar, Qualys 

Qualys CEO Sumedh Thakar says he has looked at the use case models being showcased across his firm’s customer base and beyond. As an IT, security and compliance solutions company, Qualys has advocated a concerted move to Infrastructure-as-Code (or IaC) as a core capability for secured operations.

Thakar has described the need to now build enterprise technologies based upon infrastructures that work as “dynamically orchestrated entities” with fine-grained engineering controls

As it sounds, IaC is a SaaS cloud method that delivers a “descriptive model” to define and subsequently provision a cloud infrastructure layer. Just as a physical infrastructure would include data storage capabilities, server capacities and properties, lower system level relationships and network management control tools such as load balancer – an IaC layer does the same, but is defined by code, for the cloud.

Among the technologies on offer here is Qualys’ CloudView, an IaC-level management product designed to enable firms to assess what is now being called their level of cloud security posture management (CSPM). CEO Thakar points to his firm’s ability to shift left (i.e. start earlier) an enterprise’s approach to cloud security via a combination of integrated application services designed to insert security automation into the entire application lifecycle. Qualys says this ensures visibility into both pre-deployment application build-time and post-deployment live operational runtime environments to check for misconfiguration and more, all via a single unified dashboard.

Go figure, right?

But why does so much misconfiguration happen and can we do more to stop it? Largely, it appears to be a natural byproduct of diversity in both cloud-native and “terrestrial” enterprise software platform environments that may eventually migrate to cloud. 

“Misconfigurations happen for a range of reasons, the most blatant being insecure-by-default settings, where security or hardening is an added control rather than a default state,” says Martin Jartelius, CSO at Outpost24. “The next challenge is that configurations are often evaluated in test environments where insecure configurations may occur, such as use of invalid certificates or ignoring signatures and validations at the point of testing. This means that once a transition to production is made, insecurities remain just as they were tested.”

Years ago, the silver bullet was called ‘gold builds’ for workstations and servers – today it’s the Infrastructure-as-Code – Martin Jartelius, Outpost24

Further, notes Jartelius, new functionality is added over time and unless organizations are attentive, this may introduce new and – once again – default insecure options. He agrees that an IaC approach offers the benefits of reusing trusted and well-audited templates and thereby reduces the room for human errors. It does not address the root causes of misconfigurations, but it does allow consistency. 

“Without consistency, maintenance and keeping up to date become even harder, and keeps getting harder over time,” clarifies Jartelius.

“Years ago, the silver bullet was called ‘gold builds’ for workstations and servers – today it’s the Infrastructure-as-Code. It will not solve all issues, but it will provide a remedy to a degree and most importantly it will allow those proactive who utilize its full power to reap its benefits.

“For those who are not versed in what they are doing, it however creates the opportunity to do a low-quality job faster, so at the end of the day just as any other tool its usefulness depends entirely on whose hands it is put.”

With so many differences in syntax, format, structure, code dependencies and other delineating factors across every development environment, every application toolset and indeed every cloud platform, misconfiguration is an inevitability throughout the modern IT stack all the way to the presentation layer. But that said, we can dive into cloud security more specifically to understand what’s happening here. 

An ability for visibility  

Misconfigurations in the cloud can cause data breaches – James Hastings, eSentire 

Because of the complexities described thus far, the overarching issue many organizations see when working with live cloud environments is a lack of visibility. This manifests in multiple ways such as complications when more than one cloud account or platform is leveraged, issues where the chosen technology necessitates new tooling for security monitoring purposes, or a lack of understanding of what is deployed or how it’s configured. This is the opinion of James Hastings in his position as senior product manager at eSentire, a cloud software and security specialist focused on managed detection and response.

“Misconfigurations in the cloud, which occur due to improper settings being used when architecting and deploying to cloud platforms, can cause data breaches that have a business-wide impact. According to a recent Cyber Security Hub study on the future of cloud security, almost half of the respondents (44 percent) said their primary challenge with cloud security was a reduced ability to detect and prevent cloud misconfigurations. 

“This lack of visibility usually stems from improper tooling that either can’t pull the needed data from a cloud account or workload, or where the tool isn’t designed to scale in cloud environments,” said Hastings. 

 These issues impact both ends of the cloud adoption model; users early in their cloud journey struggle from a lack of knowledge and experience, while cloud-native customers tend to run into issues establishing visibility and monitoring for services like serverless functions and other shared or ephemeral technologies. Outside of visibility, the eSentire team reports that cloud customers experience some common security pain points like alert fatigue and fear of (or the inability to detect) unknown threats.

 Collaboration situation

Looking at the way cloud-centric IT departments are run today, can we ask whether IT security teams and developers really collaborate with each other effectively – even in the so-called age of DevOps, when it should arguably be taken as a given? Or is there still a need to improve this aspect of operations?

“It really depends on the teams in question, but in my experience, yes, some do… and it’s becoming easier than ever,” says Hastings. “Newer cloud security tools take a more holistic approach to security. These solutions usually feature multiple modules that are all intertwined to offer native multi-signal correlation out of the box and are increasingly targeting the shift of security into the development process.” 

Tooling such as code analysis focuses on hardening application code before it’s deployed to server-based or serverless workloads; the hardening of this code reduces the attack surface of the eventual workload and also cuts down on the patching, investigation and response that might otherwise be necessary. 

The previously noted CSPM-style checks found in IaC are helpful when it comes to evaluating cloud infrastructure for misconfigurations but, notes the eSentire engineering team, this process happens as a fundamental part of the automation template. So this enables organizations to create secure infrastructure from the get-go and spend less time on remediating platform misconfigurations.

“The last tool that we see making a significant impact on this collaboration is the idea of integrating vulnerability assessment into a continuous integration and continuous deployment (CI/CD) pipeline,” explains Hastings. “Here, before any code or a container can be published, it must have a vulnerability assessment run against it. Organizations are able to set their own bar for security compliance and even go as far as blocking a build that doesn’t meet their security standards.”

A skewed security sentiment

All said and done then, doesn’t where we stand now in cloud security (and system robustness as a whole) beg a wider question? Are modern IT approaches built to be secure by design, or are we missing out on embedding security into these processes from the start? It comes back to a comment and sentiment spoken many times when customers move to the cloud – cloud is more secure. While the statement is true in broad terms, it really needs qualification; perhaps we should instead say – cloud can be more secure, but it’s up to each and every organization to lock it down and make it so. 

The problem with cloud security and perhaps system security in general is, it’s all too often bolted on and implemented as an afterthought. Hastings speaks from a position of experience and reminds us that most cloud practitioners (and certainly all cloud-native practitioners) realize this inconvenient truth. 

“This has ultimately spawned the idea of ‘shifting security left’ i.e. starting it earlier and/or pushing a more embedded approach to security into engineering and DevOps practices,” says Hastings. “Doing so embeds security throughout the organization’s operational fabric and means that code is written and infrastructure is created to a secure and locked-down narrative. It reduces the number of times that teams need to circle back to change code, implement patches or make other changes that likely have change control and approval processes in place. 

“The combination of security and development streamlines both processes, reduces the organization’s risk, and enables velocity.”

Would we do it all again?

Cloud computing’s evolution has been nothing if not flaky from the start. We know that AWS CEO Adam Selipsky talks of the very early stages of cloud as having been a somewhat embryonic phase, when the virtualization planets were still aligning. It’s for sure that we have spent the last decade and more shoring up security, consolidating cloud tool sprawl and looking for key avenues through which we can automate many of the management tasks that can lead to cloud fragility in the first place. 

If we had the chance to “do cloud” all over again, we might use a different and more considered approach, but perhaps we wouldn’t. This might just be a hefty symptomatic nuance of the way new technology platforms rapidly escalate and eventually germinate, oscillate, occasionally fluctuate and finally become part of our operational substrate.