Unifying Our View of Applications

Imagine for a moment that we are standing together in a kitchen. I turn to you and exclaim, “I’m hot!”. Aside from thinking (what a weirdo), you might also be wondering why I am hot. Is it a hot summer day and there is no air conditioning in the room? Perhaps the heat in this room is set too high? Or maybe the oven is on fire and the flames are lashing out in our direction.

While there are dozens of possibilities as to why I might be hot, without asking some additional questions you’d never know the answer. As humans we ask questions to help understand a situation better and ultimately use that information to infer our contextual understanding of a situation.

This might just be a silly example, but in a world where thousands if not millions of vulnerabilities are being reported each week…wouldn’t it be nice if we had the context to not only connect these issues back to their source, but also understand if they are running, and exposed, in production? Certainly sounds like context could help us more accurately prioritize vulnerabilities. So how can we get there…

What’s in a Name?

Shakespeare said it best, but in our case names are really important. Names hold significant importance to humans for several reasons:

  • Recognition - A name can evoke recognition and recall, making it easier to establish relationships or remember the association of application components. See, humans are really bad at remembering things and it’s why we associate names, or sometimes words in general, with things that we want to remember. It’s also why we don’t use IP addresses to access websites but instead use domain names.

  • Connection - Names can signify relationships and connections to family, systems, community, or even teams. If we want to think about “how” things are connected, we need to understand the name(s) of the various components that make up the whole application. Naming conventions also allow us to create memorable connections as well.

  • Communication - Names are fundamental in communication, allowing us to address and refer to individuals, teams, or applications. If we want to collaborate with other teams to remediate issues or do threat modeling for a new application, we need to be able to discuss the various components that make up the application. Without names, how can we communicate together effectively? Since one of the core principles of DevSecOps is collaboration, I can’t underscore enough the importance of the name(s) that we choose for our applications.

Are We on the Same Page?

My daughter (who is six) will sometimes come to me and say, “Dad, Amazon is down!”. The first time she told me this I thought to myself there is no way Amazon is down and that she must be mistaken…also we don’t let her use Amazon so something is off. I opened a browser on my phone and went to Amazon’s website which quickly greeted me along with the items that were on sale for the day. I called my daughter over and showed her my phone, “See Amazon is working fine…what are you even doing trying to get on Amazon?”.

She looked at me confused for a moment and then said, “No dad, I mean Amazon on the TV where I watch movies”. Ah, she meant Prime Video…but how would she know that it’s called that when every time it loads (on the TV) it has the word Amazon and their logo. The name she used to describe an application that wasn’t working and the application that I associated Amazon with in my mind were in fact not the same.

When it comes to securing applications; Dev, Sec, and Ops can’t have different naming conventions and standards to describe applications or services. Imagine if someone on the Support team reported “Amazon” as down? The Operations team at Amazon would be left scratching their heads trying to figure out which one of their hundreds of applications Support was referring to! Not cool.

It’s not enough to just agree on a naming convention, but it has to be documented, shared, and continuously reinforced. This enables teams to build dashboards and reporting centered around the same unified understanding of an application and its components. So how exactly should we go about naming applications?

Glad you asked!

What Shape is This Thing?

At this point I think we can all agree that names are important. Now we need to apply this to reality and see what this thing looks like (this is the fun part!). We need to build, or document, a map of what our application looks like so we can visually see all the components from code source straight through to runtime. Let’s jump into an example.

Luminous Books

Let’s explore a bookstore web application called Luminous Books. This is a fairly simple application using all cloud services so the map should be pretty easy to put together, but there are a few nuances we’ll explore along the way. Our application is built using the following services:

In this web application, customers can browse and buy their favorite books online. Users can access the web application online, there is a clear domain name associated with the application, and the components that make up the application are also fairly well contained. But this isn’t the only application that Luminous Books has; there is also a backend web application that is used by employees for inventory management.

Unsurprisingly this web application is more complex. While there are some shared resources with the customer-facing app (GitHub + Supabase), the rest of the application lives within AWS. Here is where things start to get complicated. We clearly can’t use the name “Luminous Books” to describe both web applications and their components, so how can we create a name for each? Here are some things to consider:

  • While the URLs for the two web applications are different, the base URL is the same so we can’t use the domain name as a differentiator
  • We should differentiate each web application by its primary function
  • If the organization is large enough we can also differentiate by the business unit that owns each web application (not applicable here)
  • We need to account for the shared components in each web application
  • Each shared component should include an indication of the services + something more granular (e.g. GitHub + repository name)

After taking these points into consideration, we settled on the names “LB E-Commerce” and “LB Warehouse”.

They are more descriptive of each application so the naming is more clear. Note in the image that these web application maps are also more granular to only include the components that relate to each of the web applications (and not the entire source code manager!).

Why Names Matters

Now that we have established a “portfolio” to manage our applications, assigned a name to each web application, documented (or mapped) how each web application is built from code to production…we are done! But why go through all this trouble? Why not just integrate / import the entire SCM into a code scanner or the AWS environment into a CSPM solution?

Context.

While Luminous Books is just a simple example, think about enterprise environments where there are dozens to hundreds of applications, thousands of code repositories, and dozens to hundreds of AWS accounts! If you were to just lump all of these together, you’d never be able to action any of the findings. In order for Development, Security, Operations, Governance, Product Owners, Support, etc. to all be on the same page, we need to have a unified view and language for each application.

How can you secure something that you don’t truly understand? This is the interconnection part of Interconnected Security. So what’s in a name? Turns out a whole lot.

Return Home →