4 min

Cyber security and application security endpoint posture management company CrowdStrike has explained its mission to combat the so-called ‘software sprawl’ that exists today. The company suggests that the modern use of component-based cloud architectures, the interconnection of multiple Application Programming Interfaces (APIs), the proliferation of shadow IT and the increasing use of no-code & low-code application development practices are just a few of the reasons we have endemic (possibly even pandemic-level) sprawl situations developing across enterprise software stacks now. If this nightmarish scenario is real, just what should we doing to combat the ensuing sprawl?

Let’s step back first and remind ourselves that low-code platforms allow teams to create and extend business applications with a lower barrier of entry and reduced complexity. However, says Eyal Mamo, VP of engineering at CrowdStrike, this reduced complexity comes with a cost: as low-code functionality increases, so do the number of interactions between traditional and low-code apps, which (argues Mamo) highlights the limitation of low-code platforms. Ultimately this requires teams to create more API interactions between apps to meet business needs – low code or not – which leads to more complexity and microservices.

“Change management is an essential discipline for securing applications in production. New and altered dataflows and APIs, even seemingly minor ones, can significantly impact the risk of sensitive data exposure. As code changes alter custom applications, it’s imperative to track changes to their risk posture,” explained CrowdStrike’s Mamo, who is also co-founder and former CTO of Bionic, a Tel Aviv-based cyber start-up now acquired and absorbed into the CrowdStrike platform. “Newly introduced dataflows and APIs can have a massive influence on the likelihood of sensitive data exposure. Even more challenging to manage are changes to existing dataflows and APIs – small updates can present massive risk, such as accidentally removing authentication from an API or returning sensitive data in an API’s payload for the first time.

An endemic automation issue?

Is this whole predicament an endemic issue thrown up by the use of automation in modern software systems then? The CrowdStrike team think it is i.e. if we look at how Tesla has automated and simplified the production of electric cars, so that it can increase manufacturing and customer adoption. We might even suggest that Tesla has done for electric cars what low-code and Continuous Integration & Continuous Delivery (CI/CD) has done for applications and microservices.

Looking for solutions then, what does an IT team do to ‘map’ their application and data service topography, what tool is used and how 3D is that map in the first place?

According to CrowdStrike’s 2024 State of Application Security Report, some 74% of teams still rely on manual documentation like visio diagrams, 68% used spreadsheets, and 54% used CMDBs to keep track of their applications. Falcon ASPM (application security posture management), a module within CrowdStrike Falcon Cloud Security, is able to automate this mapping process in less than an hour by scanning the cloud environments continuously to understand all application dependencies.

Is cloud cyber-risk different?

What we should question at this point is just how is a cloud-conscious threat actor’s actions necessarily different to a pre-cloud era exploit – are they more interconnectivity conduits to tap into and is this the major issue?

“Simply put, the number of attack surfaces exponentially grows as developers adopt cloud technologies and continuously deliver applications,” said Mamo. “The more application code is deployed, the more an application architecture grows and potentially drifts from its original design. For example, in the cloud many applications expose dozens of APIs so they can connect with other applications and services, but if these APIs aren’t secured using authentication they are potentially vulnerable to cloud-conscious threat actors. Eight out of the top 10 data breaches in 2023 related to application and API attack surfaces in the cloud.”

Mamo reminds us that every software application is hosted somewhere. The CrowdStrike team suggest that by adding a runtime protection agent to servers that run business-critical applications, security teams can halt dangerous activity. Common indicators of attack, such as persistence, lateral movement and enumeration should trigger alerts to the organisation. Real-time insights allow detection and response teams to intercept suspicious activity before data exfiltration occurs. On-premise software benefits from endpoint detection and response solutions, while cloud-native applications use cloud workload protection to stop attacks in real-time.

Gearing up for reverse engineering 

“CrowdStrike can automatically discover all system information in the cloud so it knows what infrastructure is running. Further still, CrowdStrike can reverse engineer applications in the cloud so we know all services, APIs, data flows, dependencies and attack surfaces that cloud-conscious actors can exploit. As these applications change over-time with code changes, CrowdStrike is able to continuously update its inventory and map of each application so customers can see and manage their cloud and application security posture,” said Mamo.

All of which fun and games kind of begs the question… why didn’t we think this through when we started to build the distributed computing networks of the cloud, when we started to embrace the neural network-like links that form between APIs, containers, microservices and all the other elemental components that make up the modern approach to composable software stacks? 

Mamo and team say that developers have of course known about the predicament and have been using content management databases to try and combat the swell of the sprawl as much as they could. The deeper challenge has been down the fact that system logging lacks context and is often too low-level (e.g. it’s component-level information) so it misses the big picture of the way a stack is growing and developing. Yes, an application posture management would say that kind of thing wouldn’t it, but there’s (arguably) a thread to take away from this discussion as we look at the tool sprawl that exists in any given deployment.