The CISO’s View of Securing Application Data in the Cloud

Introduction

What Is Application Data Security?

Application data security is an application-centric approach to data privacy and protection. The goal is to secure and protect sensitive data as it flows through application services and APIs.

Why Does Application Data Security Matter?

Every company is responsible for securing sensitive data of some kind, whether it’s generic personally identifiable information (PII) protected health information (PHI), or information about financial transactions that is subject to the payment card industry data security standard (PCI-DSS).

For companies that build modern cloud-native applications, application data security should be a top priority. Protecting sensitive data isn’t just about complying with GDPR or CPRA to avoid massive fines, it’s about building and maintaining customer trust and growing the business, as it evolves digitally.

Why Is Application Data Security So Difficult?

TL;DR: It’s difficult because:

1. Until recently, security posture management has focused only on cloud infrastructure and storage.
2. Application security testing (AST) tools lack data context.
3. Applications and APIs are highly dynamic, distributed, and ephemeral.
4. Application and API access permissions are often overlooked.
5. DevOps + CI/CD = frequent application, code, and API changes.

Many organizations first started managing their security posture from the cloud perspective (e.g. secure S3 Buckets). Some have opted to use a data-centric approach (e.g. secure relational databases). But until recently, the application-centric approach wasn’t possible. 

Running parallel to posture management are AST tools that test throughout parts of the SDLC, with most focusing on pre-production, specifically code repositories. There is no single tool that applies to the entire application lifecycle. This gap prevents organizations from understanding their application data security posture in production. This gap is critically important to fill because sensitive data lives in production, not in development or QA environments.

Further complicating matters is the way in which cloud-native applications are built. Complex, distributed microservice architectures with many dependencies have replaced monolithic applications with fewer dependencies. Similarly, security is challenged to understand all the ways that modern applications interact with sensitive data. APIs, upstream and downstream dependencies, third parties, shared databases/caches, and anything that consumes data in an application influences data security and determines exploitability.

Securing databases and managing access to systems are foundational cybersecurity practices, but restricting application and API permissions are sometimes overlooked or not fully understood. When developers are granted read-write access so their microservices can interact with databases programmatically, a single unvetted code change has the potential to expose an entire database of sensitive information. 

Plus, as DevOps teams introduce application changes weekly, daily, or hourly through CI/CD pipelines, it becomes harder to reconcile one’s data security perceptions with reality.

This guide defines three maturity levels and perspectives for data security: 

1. Cloud-centric
2. Data-centric
3. Application-centric

For each level, we’ll identify key challenges and common characteristics in terms of people, processes, and tools.

Level 1: Cloud-Centric

The first maturity level takes a cloud-centric perspective. It is about securing the foundation on which applications and data run. Organizations at this level understand the cloud shared responsibility model and are committed to fulfilling their part. Discovering and securing cloud infrastructure and storage from misconfiguration is the first step in managing application data security risk.

People

Leadership and the C-suite broadly support growing the application data security program, but there’s a lack of defined ownership. 

The key players at this level are often cloud security teams or cloud center of excellence (CoE) teams.

Processes

Cloud security is responsible for creating guardrails that help cloud engineering or DevOps teams provision cloud infrastructure and resources securely so they can innovate quickly without creating risk. Engineering teams are responsible for innovating within those defined security guardrails.

Tools

Cloud Security Posture Management (CSPM) tools are purpose-built to help teams deploy cloud infrastructure securely. CSPM applies common frameworks, regulatory requirements, and custom policies to identify and help remediate cloud misconfigurations.

While CSPM is a critical part of security, it is unable to provide visibility into the application, service, or data layers. CSPM can’t identify how data runs through applications or how sensitive data is being used in applications. 

As such, teams fill this gap in different ways, usually a mix of manual tasks and application security tools. Manual tasks include creating Visio diagrams, managing CMDBs, and updating spreadsheets to document application architecture and map data flows. AST tools include SAST, SCA, DAST, IAST, and RASP. By combining signals from SAST, SCA, DAST, IAST, and RASP, teams can claim to have security through the full application lifecycle. But in reality, no single solution alone can secure applications in production.

Key Takeaways

Here are the key takeaways for the cloud-centric level:

• Generic buy-in, unclear ownership.
• Security provides guardrails to help developers provision cloud infrastructure and services securely.
• Securing application, service, and data layers requires manual effort and/or a combination of various other tools.

Level 2: Data-Centric

This level takes a data-first approach with a specific focus on securing where data is stored and managed. For example, AWS S3 buckets or relational/non-relational databases like Oracle, MongoDB, and DynamoDB.

People

Application data security ownership is shared across data privacy, data security teams, and even database administrators.

Responsibility is siloed like cloud security, with a specific perspective on where data is hosted and managed versus what is consuming or requesting the data.

Processes

After securing cloud infrastructure with CSPM, organizations focus on finding the data resources (etc., storage services, relational databases, NoSQL) they need to secure, identifying who should have access to what data, managing access requests/permissions processes, and specifying legitimate business needs to access sensitive data.

There are usually policies in place to meet the data protection regulations they need to comply with, i.e., GDPR, CCPA, HIPAA, etc. Accordingly, training and awareness programs at this level focus on compliance.

Tools

Data security posture management (DSPM) provides visibility as to where sensitive data is, who has access to that data, how that data has been used and what the security posture of the data store. With a data-centric solution, teams will be able to perform data risk assessments and evaluate alignment to data governance policies.

In its 2022 Hype Cycle for Data Security, Gartner points out that DSPM is nascent and products have a wide range of abilities for mapping user access and privileges and to identify, discover, and track data and identify associated risks. 

Furthermore, DSPM integrations with other security tools are limited. This makes it difficult for teams to contextualize DSPM signals from the application perspective, which inhibits remediation. 

Key Takeaways

Here are the key takeaways for the data-centric level:

• Semi-defined application data security ownership.
• Able to comply with data protection regulations with manual processes.
• Limited context of how applications and APIs interact with data.

Level 3: Application-Centric

The third level approaches data security from an application-centric perspective. This approach is based on the idea that having full visibility into how an application is architected, as well as its dependencies and data flows will empower teams to secure applications, APIs, and sensitive data at scale.

At this level, organizations proactively and continuously protect sensitive data in production. They seek to understand their application data security posture by asking questions like:

• How does software delivery affect our application data security in production?
• Which code changes expose sensitive data?
• Which 3rd party services are requesting or consuming sensitive data?
• Which application services and APIs are internet facing that expose sensitive data?
• Which application services are in compliance with data privacy regulations like GDPR?

People

Application data security ownership is well defined. Security champions are embedded across the organization, particularly in product, engineering, and DevOps teams. These champions bring on-demand data security subject matter expertise to the individuals and teams building applications and fixing security bugs.

Processes

In addition to having embedded security champions in every department, application data security training programs are elevated and become central to the organization’s culture. Raising security issues is rewarded and acknowledged. DevOps and engineering teams are trained to understand application data security best practices.

Data protection compliance is systematic and requires much less manual effort, and technology supports this. 

Here’s why that matters:

A major retailer in the United States is focused on maintaining customer trust and confidence. They are particularly interested in securing payment data.

Their security team of 8 performs between 200 and 300 1-hour manual security reviews per month to support:

• 1,500 developers working on
• 1,300 application services across
• 500 teams
  

Based on average salary costs, this company spends ~$1.6 million per month just to perform security reviews.

Tools

At this level, organizations have invested in Application Security Posture Management (ASPM). ASPM brings full visibility into an application’s architecture, identifies critical assets, and maps data flows. The output of ASPM is similar to security reviews and threat modeling exercises, but with much less time and manual effort. 

ASPM takes its full visibility one step further by analyzing all environment variables and dependencies in production. This holistic approach gives organizations real-time context of what the application is doing in production and identifies the top critical risks to fix right away. ASPM helps organizations actively govern their applications and protect sensitive data by prioritizing the most critical threats in production.

Key Takeaways

Here are the key takeaways for the application-centric level::

• Holistic and contextual approach. 
• Application data security champions are embedded in every part of the organization.
• Security is talked about openly. This blog post from Coinbase is a great example of what this looks like. 
• Application security scales with deployment cadence (weekly, daily, hourly).
• Threats that pose the greatest risk are visible, contextualized, and can be fixed in minutes.

Conclusion

Here’s a quick summary of all three perspectives.

Ready to Learn More?

• Read more about ASPM
• Watch a demo of Bionic
• Talk to us one-on-one