*Check out our podcast and youtube video released on 10/5/22, where we talk about this subject. Hope to see you there!

 

Introduction

Web applications and their corresponding threats aren’t new. We (the collective appsec world) have a pretty solid handle on understanding individual findings, such as SQL Injection or Client Side Parameter Pollution. We even have a pretty solid record of threat modeling and threat hunting. This is not to say we are perfect or have mastered the enumeration of web app threats across the enterprise, but we do a pretty good job. I would like to propose that we change our current view of enterprise web applications.

 

The old approach to AppSec

We have historically viewed applications as siloed. In other words, the applications are treated as if they exist all alone, in a vacuum. Of course, we accounted for the obvious things, such as the database or the application service. Sometimes we may consider a shared environment, but even then, we’ve viewed logical segmentation as absolute.

The landscape doesn’t reflect our view of applications. Let’s examine why.

In most cases, if you ask an enterprise architect or developer to describe an application, they will give you a ground-floor view of it. It might look something like this:

And they wouldn’t be wrong.

The problem is that most enterprise applications have many moving parts, meaning our ground-floor view likely isn’t the whole story. That same application, blown out to its moving parts, might more accurately be portrayed as the following:

Now we can start getting an idea of risk, right? I know I need a mobile app SAST/DAST and an API penetration test. I know I need to review our Development team’s hygiene. I can infer that we should probably check the customer’s interface, etc.

Solid.

However, this still isn’t the whole picture.

We must start asking about and understanding integrations and other forms of overlap. In the world of federated identities and blanket-SSO (single sign-on), applications are consuming more and more from other applications.

A more risk-oriented view might look something like this:

 

 

The new diagram presents a few challenges that we need to consider:

• Different development teams working on various projects have a ground-floor perspective
• Risk is shared across multiple apps
• Data is shared across multiple apps
• One app isn’t federated but still integrates with an app that is (top right)

 

A new way of viewing the problem

So what does this mean to our organization?

Well, we have to stop looking at applications as singular entities. We need to view them as part of an application “ecosystem” where the health of each component is critical to all other members. This may mean that you need to take a hard look at applications that previously would have been off your radar.

Ultimately, every application in our illustration above is connected, even if not directly. So that means we have to treat ALL applications that interact meaningfully as directly impacting all other applications.

A big part of this is what we call blocking and tackling. In this context, that might include change management, asset management, IT asset databases and tracking, automated discovery, etc.

Without fully baked components, visibility into your application ecosystem will be skewed.

So, now we understand what we must do. What’s the easiest way to get started?

Step one will be to start tracking your applications, data, etc., with an eye toward integrations. Draw virtual lines between each application component and what it touches. Include the development teams and systems owners (sponsors) in that discovery. Include the data owners if they aren’t the system owners.

You may be frightened to realize how many 3rd party integrations you have or how many previously unknown applications are connected to critical data.

Step two will be to prioritize workflows to perform security testing on each unknown entity and document previously unknown workflows. Beyond that, you’ll need to stay on top of this new worldview perspective. It will be a continuous process for sure.

 

Conclusion

I challenge you to consider this: what would the crater look like if this application was completely compromised? It’s a scary proposition, but it will help you get your head around what other systems might be in the blast radius if it happened.

Don’t forget to pay close attention to authentication components and microservices; these seem constantly changing and can easily make for a challenging target for the security team.

I hope this helps you get a different perspective on your web application ecosystem!

 

If you’re on to go, listen here or on your favorite podcast app: https://www.buzzsprout.com/1731753/11408563

Blog: https://offsec.blog/
Youtube: https://www.youtube.com/channel/UCCWmudG_CTNAFBaV48vIcfw
Twitter: https://twitter.com/cyberthreatpov
Work with Us: https://securit360.com