Modern Application Security Overview

To understand security in a modern application, we must first understand how a modern application works and how the community has started to define the many layers of security when using a modern application.

The Kubernetes community defined a model for thinking about cloud native security which is referred to as the 4C's of Cloud native security or Code, Container, Cluster, and Cloud as the layers of a cloud native application to be secured. However, that only takes into account the running bits built for the application and the infrastructure that runs those applications.

Here in the VMware Modern Application business we look at the entire scope of a modern business application which starts with business critical data and continues all the way to end users or services that work with that data.

All security programs start with what is the data being used. The data determines the control requirements and the risks that are acceptable. No application or security model can start without data.

In addition to Data, we in Tanzu and Aria also recognize that applications do not stand alone. There are end-users, layers upon layers of APIs, dependent applications or just other services that need to all be connected together. Whether using a service mesh or other mechanism the VMware modern application definition concludes with connectivity.

As the diagram above illustrates the full VMware model of a modern application security starts with Data and continues through the 4 Cs (Code, Container, Cluster, Cloud) and finishes with the 5th C of Connectivity.

Normally adding more layers of security controls would be seen as a burden on the process and one might assume would add not just toil but also slow down releases.

However, the creation of modern cloud native applications and the orchestration tools that build and run them has enabled the potential of modernizing how security works and how each of the modern application cloud native security model layers can be automated and streamlined with pre-designed and approved security guardrails.

What has changed with application development

image-20230810103255-5

There are two main changes with applications that have occurred over the last two decades that have enabled cloud native modern applications.

Breaking of applications into micro-services (and containerizing them) allowing for Agile and extreme development processes
Automating the servers, clusters, networks and other infrastructure that the applications run on

These functional changes have reduced the toil on developers and platform operators while also reduce the risk with releases as they are changed because they are pre-configured, minimal (micro-service) and automated.

The changes that created agile development teams and automated modern infrastructures are the exact changes that security organizations are going through right now and is a huge opportunity to change not only the security tools, but also the people and processes for security teams to reduce risk for the business while increasing efficiency in their processes.

How are modern applications built

The steps to build and run software have been established for many decades. When containerized applications were created and agile development lifecycles changed how teams built and released software the ability to automate many of these steps allowed for more frequent and faster changes to applications.

image-20230810103315-6

But it is the splitting of code from old monolithic code bases into micro services and using pre-defined operating states through platforms like Cloud Foundry and Kubernetes created automated, highly available and scalable applications were possible and it changed the way applications function in today's modern world.

image-20230810103334-7

Real world modern application

image-20230810103347-8

As we have worked with businesses and governments globally, the scope and scale of what is really being built with modern applications is more than just a single cluster but instead a multi-cloud, multi-cluster, multi-platform system.

Modern Application Security

image-20230815141742-1

Every component within every service of every supply chain, including 3rd party dependencies and data services that is deployed on any of the many cloud, on prem or edge platforms has risks to the people, processes and technologies used throughout the application lifecycle.

With many organizations this view above may only be one of thousands of applications, and each team may be building their own orchestration methodologies making it harder to monitor and secure the business without impacting developer or platform teams and processes.

To solve this there are multiple community based supply chain and cloud infrastructure security frameworks going beyond the original 5Cs and have started to be shared and used by the industry. These include SLSA and CNAPP.

Supply Chain Levels for Software Artifacts (SLSA)

SLSA or the Supply Chain Levels for Software Artifacts attempts to address risk to the security and trust of the artifacts consumed and built by a software build and release process. It is a cross industry collaboration and released by the Linux Foundation.

image-20230810103918-15

Tanzu can't help with developer or endpoints security, please see other sessions with Carbon Black or Workspace One for solutions that can protect end users and endpoint security, including authentication controls for services such as source repositories.

SLSA focuses on the steps from code commit through it's deployment on a platform. The key intent behind SLSA is a repeatable process that can attest to the source of all build components, the process used to build and assurances such as signatures which can be used in attestations to the build process. When there are thousands of applications made up of hundreds or thousands of micro services the integrity and ability to reproduce trusted builds is key to assuring the security of what is running for all of the many components of the many business applications operating today.

image-20230810110159-27

The Tanzu Application Platform which includes the Tanzu Build Service is working toward SLSA 3 support for applications built and deployed with the Tanzu Application Platform. Until full SLSA 3 is supported, there are components of levels 1,2 and 3 such as sBOM generation, dependency mapping, artifact signing and other meta data that can be used to document and attest toward the integrity of the build and the build process.

Cloud Native Application Protection Platform (CNAPP)

SLSA focuses on the assurance of the applications that will be running, but does not get into the security of where the applications will be running.

Gartner released their own model which has elements of artifacts but focuses on the security scanning of them along with the cloud and cluster configurations security and the security of the running applications. This standard was released and called the Cloud Native Application Protection Platform or CNAPP.

image-20230810103932-16

CNAPP provides for actionable processes that security, platform and application teams can follow for a more secure application and platform it runs on.

Artifact Scanning
- Configurable supply chains enforce consistent testing guardrails and meta data generation for CNAPP and best practices application security tests with Tanzu Application Platform developer portal, supply chains and accelerators
- SCA and container secrets and CVE scanning can be performed with Carbon Black for Containers
Cloud Configuration
- Standards based configurable guardrails for public clouds, cloud networks, kubernetes clusters with Aria Guardrails and Tanzu Mission Control
Runtime Protection
- Carbon Black provides container based runtime application, network and container protections
- NSX Advanced Load Balancer provides Web Application protection
- Tanzu Service Mesh provides API protection and application segmentation

CNAPP + SLSA the VMware Way

image-20230810104011-17

I'm not going to go into this diagram in detail, we will go through a walk through of what a VMware + Tanzu + Aria solution looks like before we are finished. However one thing worth pointing out is that just like with the 5Cs introduction, a VMware opinion on the optimization of security within the process starts with automation and pre-approved guardrails for cloud configurations in addition to application guardrails and runtime controls.

Pre-Pipeline Cloud Configuration - One touch pre-defined guardrails deployment of cloud, cluster and dependent data and services
Artifact Scanning - Developer portal guardrails, accelerators and workflows
Cloud Configuration - One touch standards based guardrails deployment and monitoring
Runtime Security