App Instrumentation – The Boat Anchor Around Your Ankle

What is App Instrumentation?

A simple Google search will reveal that app instrumentation, in the context of cybersecurity, is nothing more than embedding sensors within applications so they can protect themselves from attacks. In actual fact, this “protection” is really “measuring” or “detecting”, i.e., sensing that an attack may be happening, then reporting that information back to some other system. Knowing that an application is being attacked is useful, no? In theory, this is useful, however one must understand how this instrumentation comes into being, and the associated costs levied for using it.

For the purposes of our discussion, we’ll talk about an organization that has a number of applications that they would like to protect from attack. Today, in light of digital transformation (simplistically, moving to the cloud) these applications have become foundational elements to most organizations, providing an interface between the organization and its customers and partners. These applications drive revenue, affect brand reputation, and impact customer satisfaction. So to call them mission critical would not be an overstatement.

How are Applications Instrumented?

Given the importance of these applications, our example organization has sought out a cybersecurity vendor to help protect them from attack. This vendor uses a common technique that requires each application needing protection to be instrumented. The process for implementing an app requires the app development team to modify each application, adding some code from the vendor that can detect attacks and provide some telemetry data about said attack. Most vendors offer JavaScript or a mobile SDK to facilitate this. Easy, right?

Instrumentation Implications

Let’s follow the process of instrumenting our application and talk through some of the downstream implications.

Development

The development team’s number one priority is creating needed features and functionality with the fewest code defects possible in a given timeframe. So, asking them to include someone else’s code in their application is seldom met with enthusiasm. And, even if they are willing to do so, this takes time, not only to add the code, but also time for a proper QA cycle. And time is something no development time has an abundance of. Last, every minute an application goes without protection is an additional minute that the organization is at risk.

For the purposes of our exploration today, let’s assume you manage to talk/coerce your dev team into spending the time needed to do this. Now you need to evaluate the performance hit that the application will suffer. After all, the application process is now burdened with the overhead of inspecting all inbound requests. Will your team perform some sort of before/after testing? The newly modified application is now doing some level of analysis and reporting back telemetry. There’s are CPU, memory, and perhaps storage impacts that must be considered.

Compliance

More and more organizations are taking a hard look at open source and third-party code. Does the third-party code we’re incorporating comply with our organizations API specifications and requirements? Is there a software bill of materials (SBOM) for the code so we can pass audit? Increasingly, enterprises want an SBOM for any third-party code they consume, as it is a key building block in software security and software supply chain risk management.

Performance

Will end users be able to perceive any performance change to your application? Under the best of circumstances, perhaps not. We know that as applications slow down, dissatisfaction goes up. The key thing to understand is that when an application comes under an automated attack, the application will slow down, as it now must process traffic volumes that are almost guaranteed to surpass its design envelope. It might crash, or the user interface might simply become unwieldy, causing the user to abandon what they were doing (like making a purchase). So now we have a dissatisfied customer, and potentially a tarnished brand.

Why make your application process bad traffic? Instrumenting an app leads to customer dissatisfaction as your app gets slower processing bad traffic.

Conversely, offloading bad traffic from an application that’s been suffering under the load typically improves its performance immediately.

Cost

Most cloud vendors charge for compute instances and storage (and you typically pay for all reserved compute and the entire storage volume, regardless of how much capacity you actually use). So, high volumes of bad traffic going to an application disproportionately consume CPU cycles and disk, directly increasing cloud costs.

What about the revenue loss that happens when application users become frustrated and fail to convert? Maybe they come back and try again later. Maybe they don’t.

Of course, we must also consider the outcomes of a successful bot attack. Are the attackers simply shutting down your e-commerce site, or have they stolen PII that, once discovered, will force your organization to provide credit monitoring services and suffer the subsequent brand damage hit.

Last, depending on the nature of the attack, there can be compliance and regulatory findings with financial implications. Fines are only going up, across industries.

Coverage

It’s obvious when you think about it, but even if you do agree to modify your apps to achieve some level of protection, you’re only protecting the specific apps that you modify. None of your other apps will get any protection until you modify them as well. And, critically, you typically can’t modify your non-web or mobile apps that are purely leveraged through APIs. So many applications today are really “faceless” back-office API applications.

Summary

It’s certainly easy for a vendor to say, “Just add our JavaScript to your app”, but that’s disingenuous. The implications of doing so run long and deep. There’s time, compliance, performance, cost, and coverage implications to consider when you instrument applications. Take advantage of Cequence’s expertise – and our no instrumentation approach – we’d love to talk with you in more detail about your specific situation. Or, let’s arrange a demo so you can see for yourself.