Stepping Safely Through The Software Sprawl

Software sprawls. The ‘sprawl’ term is used by technology advocates, evangelists and even managers themselves to explain just how many applications and data services a typical enterprise organization runs and operates at any given time. In the modern era of IT, it’s not unusual for a reasonably sized travel and leisure firm (for want of an example, the same applies in other business sectors) to be running not just one security tool, it might well be running upward of a hundred software system security tools spanning various different systems.

Equally, that same firm might run a dozen different billing systems, a handful of identity management software products, a small bushel of HR solutions and certainly more than one database.

Hold on please, caller

When you call up your bank, travel agency, gas & electric billing company or any other service-centric utility or business to try and resolve an issue, there’s often a delay on the line while callers are put on hold. Sometimes that gap is caused by the need for a call center operative to speak to a manager, sometimes it’s a result of system latency as the representative waits for information to be presented on screen… and sometimes it’s simply because the company is searching through your customer files.

It also happens because the service rep needs to check inside one application, then look in another, then try and find the answer elsewhere and so on and so on.

Today, the complexity of managing an organization’s increasingly cloud-hosted software estate is made even more challenging due to the sheer number of applications and microservices that can be produced using no-code & low-code development platforms. In this changing environment, it is increasingly difficulty for IT teams to map these applications across the whole infrastructure.

Manual (documentation) labor

According to CrowdStrike’s 2024 State of Application Security Report, around three-quarters of companies still rely on manual documentation like visio diagrams to track their software stack. A surprisingly large proportion of firms use spreadsheets like Excel (other spreadsheet apps are also available) or content management databases (CMDBs), both of which are examples of an IT tool being ‘crowbarred’ into place to serve a workplace function that it is somewhat capable of performing, but inherently not built or engineered for in the first instance.

“Low-code platforms allow teams to create and extend business applications with a lower barrier of entry and reduced complexity. However, reduced complexity comes with a cost: as low-code functionality increases, so do the number of interactions between ‘traditional’ (hard-coded) applications and low-code apps, which 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,” said Eyal Mamo, VP of engineering at CrowdStrike, a company known for its work user endpoint protection and security technologies that now span into the generative AI space with its Charlotte product.

What should we be doing then? Firstly, we can remember that 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.

Mamo, who is also co-founder and CTO at Bionic, an Israeli application security posture management startup now owned by CrowdStrike, reminds us that 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.

Application & data service topography

While many teams still rely on manual documentation to track applications, CrowdStrike positions its Falcon ASPM (application security posture management - a module within CrowdStrike Falcon Cloud Security) as a means of being able to automate this mapping process by scanning cloud environments continuously to understand all application dependencies.

Simply put, the number of attack surfaces exponentially grows as developers adopt cloud technologies and continuously deliver applications. The more application code 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.

“Today we know that many data breaches are related to application and API attack surfaces in the cloud. This is because every software application is hosted somewhere. By adding a runtime protection agent to servers that run business-critical applications, security teams can halt dangerous activity,” proposes Mamo. “Common indicators of attacks, such as persistence, lateral movement and enumeration should trigger alerts to the organization. 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.”

CrowdStrike claims to be able to automatically discover all system information in the cloud so it knows what infrastructure is running. It can also reverse engineer applications in the cloud so organizations can 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, the company’s platform can continuously update its inventory and map of each application so customers can see and manage their cloud and application security posture.

This begs the question: why systems with this deeper insight weren’t built in the first place?

Mamo has seen developers have tried to do this for years with system logging and IT operations has tried with CMDB projects. However, system logging lacks context and is often too low-level (e.g. component-level information) so it misses the bigger picture – it’s like looking at each tree in the forest individually, but not seeing the forest and the bigger picture (the application).

“Many projects have also failed, primarily because they are always out of date by the time their scan or analysis completes. For example, it might take 24 hours to scan a cloud environment using a CMDB, in that time the application code, components and services could have changed tens or hundreds of times,” asserted Mamo. All deployed software presents some risk to its parent company and understanding the current risk posture is a vital step in reducing risk to the organisation. However, it is imperative that this protection doesn’t disrupt productivity or the speed of DevOps processes that are at the heart of the IT function.”

You can’t protect what you can't see

CrowdStrike joins the long line of cloud-centric resilience, security, observability, application performance management and cloud management companies that are so fond of one key expression: you can’t protect what you can't see. With cloud computing being so inherently abstracted and virtualized, so widely distributed (as in distributed computing as a formalized piece of terminology) and so essentially ephemeral in nature, it is no wonder that technology vendors are working so fervently to try and provide us with insights into our stack of services.

Can we tread through the sprawl and over the software service stepping stones more safely now? Things are improving, but there’s always a chance of rain, so still watch your step.