All Resources
In this article:
minus iconplus icon
Share the Blog

Minimizing your Data Attack Surface in the Cloud

November 8, 2022
4
Min Read

The cloud is one of the most important developments in the history of information technology. It drives innovation and speed for companies, giving engineers instant access to virtually any type of workload with unlimited scale.

But with opportunity comes a price - moving at these speeds increases the risk that data ends up in places that are not monitored for governance, risk and compliance issues. Of course, this increases the risk of a data breach, but it’s not the only reason we’re seeing so many breaches in the cloud era. Other reasons include: 

  • Systems are being built quickly for business units without adequate regard for security
  • More data is moving through the company as teams use and mine data more efficiently using tools such as cloud data warehouses, BI, and big data analytics
  • New roles are being created constantly for people who need to gain access to organizational data
  • New technologies are being adopted for business growth which require access to vast amounts of data - such as deep learning, novel language models, and new processors in the cloud
  • Anonymous cryptocurrencies have made data leaks lucrative.
  • Nation state powers are increasing cyber attacks due to new conflicts

Ultimately, there are only two methods which can mitigate the risk of cloud data leaks - better protecting your cloud infrastructure, and minimizing your data attack surface.

Protecting Cloud Infrastructure

Companies such as Wiz, Orca Security and Palo Alto provide great cloud security solutions, the most important of which is a Cloud Security Posture Management tool. CSPM tools help security teams to understand and remediate infrastructure related cloud security risks which are mostly related to misconfigurations, lateral movements of attackers, and vulnerable software that needs to be patched.

However, these tools cannot mitigate all attacks. Insider threats, careless handling of data, and malicious attackers will always find ways to get a hold of organizational data, whether it is in the cloud, in different SaaS services, or on employee workstations. Even the most protected infrastructure cannot withstand social engineering attacks or accidental mishandling of sensitive data. The best way to mitigate the risk for sensitive data leaks is by minimizing the “data attack surface” of the cloud.

What is the "Data Attack Surface"?

Data attack surface is a term that describes the potential exposure of an organization’s sensitive data in the event of a data breach. If a traditional attack surface is the sum of all an organization’s vulnerabilities, a data attack surface is the sum of all sensitive data that isn’t secured properly. 

The larger the data attack surface - the more sensitive data you have - the higher the chances are that a data breach will occur.

There are several ways to reduce the chances of a data breach:

  • Reduce access to sensitive data
  • Reduce the number of systems that process sensitive data
  • Reduce the number of outputs that data processing systems write
  • Address misconfigurations of the infrastructure which holds sensitive data
  • Isolate infrastructure which holds sensitive data
  • Tokenize data
  • Encrypt data at rest
  • Encrypt data in transit
  • Use proxies which limit and govern access to sensitive data of engineers

Reduce Your Data Attack Surface by using a Least Privilege Approach

The less people and systems have access to sensitive data, the less chances a misconfiguration or an insider will cause a data breach. 

The most optimal method of reducing access to data is by using the least privilege approach  of only granting access to entities that need the data.  The type of access is also important  - if read-only access is enough, then it’s important to make sure that write access or administrative access is not accidentally granted. 

To know which entities need what access, engineering teams need to be responsible for mapping all systems in the organization and ensuring that no data stores are accessible to entities which do not need access.

Engineers can get started by analyzing the actual use of the data using cloud tools such as Cloudtrail.  Once there’s an understanding of which users and services access infrastructure with sensitive data, the actual permissions to the data stores should be reviewed and matched against usage data. If partial permissions are adequate to keep operations running, then it’s possible to reduce the existing permissions within existing roles. 

Reducing Your Data Attack Surface by Tokenizing Your Sensitive Data

Tokenization is a great tool which can protect your data - however it’s hard to deploy and requires a lot of effort from engineers. 

Tokenization is the act of replacing sensitive data such as email addresses and credit card information with tokens, which correspond to the actual data. These tokens can reside in databases and logs throughout your cloud environment without any concern, since exposing them does not reveal the actual data but only a reference to the data.

When the data actually needs to be used (e.g. when emailing the customer or making a transaction with their credit card) the token can be used to access a vault which holds the sensitive information. This vault is highly secured using throttling limits, strong encryption, very strict access limits, and even hardware-based methods to provide adequate protection.

This method also provides a simple way to purge sensitive customer data, since the tokens that represent the sensitive data are meaningless if the data was purged from the sensitive data vault.

Reducing Your Data Attack Surface by Encrypting Your Sensitive Data

Encryption is an important technique which should almost always be used to protect sensitive data. There are two methods of encryption: using the infrastructure or platform you are using to encrypt and decrypt the data, or encrypting it on your own. In most cases, it’s more convenient to encrypt your data using the platform because it is simply a configuration change. This will allow you to ensure that only the people who need access to data will have access via encryption keys. In Amazon Web Services for example, only principals with access to the KMS vault will be able to decrypt information in an S3 bucket with KMS encryption enabled.

It is also possible to encrypt the data by using a customer-managed key, which has its advantages and disadvantages. The advantage is that it’s harder for a misconfiguration to accidentally allow access to the encryption keys, and that you don’t have to rely on the platform you are using to store them. However, using customer-managed keys means you need to send the keys over more frequently to the systems which encrypt and decrypt it, which increases the chance of the key being exposed.

Reducing Your Data Attack Surface by using Privileged Access Management Solutions

There are many tools that centrally manage access to databases. In general, they are divided into two categories: Zero-Trust Privilege Access Management solutions, and Database Governance proxies. Both provide protection against data leaks in different ways.

Zero-Trust Privilege Access Management solutions replace traditional database connectivity with stronger authentication methods combined with network access. Tools such as StrongDM and Teleport (open-source) allow developers to connect to production databases by using authentication with the corporate identity provider.

Database Governance proxies such as Satori and Immuta control how developers interact with sensitive data in production databases. These proxies control not only who can access sensitive data, but how they access the data. By proxying the requests, sensitive data can be tracked and these proxies guarantee that no sensitive information is being queried by developers. When sensitive data is queried, these proxies can either mask the sensitive information, or simply omit or disallow the requests ensuring that sensitive data doesn’t leave the database.

Reducing the data attack surface reflects the reality of the attackers mindset. They’re not trying to get into your infrastructure to breach the network. They’re doing it to find the sensitive data. By ensuring that sensitive data always is secured, tokenized, encrypted, and  with least privilege access, they’ll be nothing valuable for an attacker to find - even in the event of a breach. 

 

Discover Ron’s expertise, shaped by over 20 years of hands-on tech and leadership experience in cybersecurity, cloud, big data, and machine learning. As a serial entrepreneur and seed investor, Ron has contributed to the success of several startups, including Axonius, Firefly, Guardio, Talon Cyber Security, and Lightricks, after founding a company acquired by Oracle.

Subscribe

Latest Blog Posts

Kristin Grimes
Kristin Grimes
David Stuart
David Stuart
March 5, 2026
3
Min Read

Meet Sentra at RSAC 2026: AI Data Readiness, Continuous Compliance, and Modern DLP in Action

Meet Sentra at RSAC 2026: AI Data Readiness, Continuous Compliance, and Modern DLP in Action

RSAC 2026 is shaping up to be one of the most important RSA Conferences to date, especially for security teams navigating AI adoption, Copilot readiness, and large-scale data governance. At RSA Conference 2026 in San Francisco, Sentra is bringing together security leaders from major enterprises across financial services and global consumer industries to discuss how modern enterprises are preparing their data for AI, strengthening governance, and rethinking DLP in an AI-driven world.

If you’re attending RSAC 2026, here’s where to find us, and why it matters.

CISO AI Copilot Readiness Roundtables at RSAC 2026

March 23–26 | W Hotel | Steps from Moscone

AI assistants like Microsoft Copilot and Google Gemini are transforming how employees access enterprise data. What once required manual searches across drives, mailboxes, and SaaS applications can now be surfaced instantly.

That shift is powerful, but it also forces CISOs to confront a difficult question: is our data actually AI-ready?

During RSAC 2026, Sentra is hosting closed-door CISO AI Copilot Readiness Roundtables, bringing together security leaders from major enterprises across financial services and global consumer industries. These sessions are intentionally intimate and designed for candid peer discussion rather than vendor presentations.

No slides. No marketing decks. Just real-world insights on what’s working, and what isn’t - as organizations operationalize AI securely. Register for a roundtable.

AI Data Readiness for 70+ PB: Lessons from a Leading Financial Platform at RSAC 2026

March 24 | 7:45 AM – 9:00 AM

Preparing data for AI at scale is not theoretical, especially when you're dealing with more than 70 petabytes of data.

In this RSAC 2026 session, a former Director of Product Security from a leading digital financial platform will share how their organization approached AI data readiness using Sentra. The session will explore how large financial institutions can gain visibility into massive data environments, reduce exposure risk, and enable Copilot and machine learning adoption without compromising governance.

If you're managing AI adoption in a complex, high-scale environment, this session offers practical lessons grounded in real-world enterprise execution. Register for the session.

Continuous Compliance with AI Visibility: Lessons from a Major Mortgage Institution at RSAC 2026

March 25 | 12:00 PM – 1:00 PM

For a $500B U.S. mortgage institution, compliance is not a one-time event, it’s a continuous obligation.

In this RSA Conference 2026 session, a CISO from one of the largest mortgage lenders in the United States will share how their organization uses Sentra to gain visibility into sensitive data, automate Jira masking workflows, and transform compliance from a reactive burden into a proactive advantage.

As regulatory expectations increase around AI systems and data governance, continuous compliance becomes a strategic capability rather than just an audit checkbox. Register for the session.

A Global Enterprise Blueprint for Modern DLP Compliance at RSAC 2026

Global enterprises face an even more complex challenge: governing data consistently across Azure, Snowflake, Microsoft 365, and Purview, while preparing for AI and Copilot integration. At RSAC 2026, data security leaders from one of the world’s largest consumer brands will share how they built a governance framework that integrates large data catalogs with modern DLP controls. The session explores how traditional policy-based DLP can evolve into a model that combines deep data intelligence with enforcement aligned to business context.

For organizations operating across regions and platforms, this blueprint offers a practical path forward. Register for the session.

Visit Sentra at Booth #N4607 at RSA Conference 2026

If you’re walking the floor at RSAC 2026, stop by Booth N4607 to explore how Sentra enables AI-ready data security.

Our team will be showcasing how organizations can:

  • Eliminate risk from AI agents and ML model adoption
  • Discover unknown sensitive data exposures
  • Add AI-powered intelligence to improve DLP precision

Rather than simply layering new policies on top of old systems, we’ll demonstrate how DSPM and DLP can work together in a unified architecture. Book a Demo at Booth N4607.

Executive Briefings at RSAC 2026

For security leaders looking to go deeper, Sentra is offering private briefings during RSA Conference 2026. These sessions provide the opportunity to discuss real-world data security challenges, proven best practices, and lessons learned from enterprise deployments.

Each discussion is tailored to your environment, whether your focus is AI readiness, exposure reduction, or continuous compliance. Schedule a Personal Briefing.

Special Events During RSAC 2026

The Women in Security Documentary

March 24 & 25 | AMC Metreon 16

Just steps from Moscone Center, join us for a special screening celebrating women redefining leadership in cybersecurity. The red carpet begins at 4:00 PM, with the screening starting at 4:45 PM.

Register Now

Sentra + Defensive Networks RSA Dinner

March 25 | 7:00 PM | The Tavern, San Francisco

We’re hosting an intimate, relationship-centered dinner for security leaders navigating today’s most pressing AI and data security challenges. Designed for meaningful dialogue and peer exchange, this event offers space for authentic conversation beyond the conference floor.

Why AI Data Security Defines RSAC 2026

The defining theme of RSA Conference 2026 is clear: AI has changed the security equation. AI systems do not create new data, but they dramatically increase its discoverability, accessibility, and movement. That reality exposes gaps between visibility and enforcement that many organizations have tolerated for years. To secure AI adoption, organizations need more than isolated tools. They need continuous data intelligence, context-aware enforcement, and feedback between the two. That is the architecture Sentra is bringing to RSAC 2026.

See You at RSA Conference 2026

If you’re attending RSAC 2026 in San Francisco, we’d love to connect.

📍 Booth N4607
📅 March 23–26, 2026
📍 Moscone Center

Join us to explore how AI-ready data security becomes practical, measurable, and operational- not just theoretical.

<blogcta-big>

Read More
David Stuart
David Stuart
March 4, 2026
4
Min Read

Microsoft Copilot Chat Incident: A Wake-Up Call for AI Assistant Security in Microsoft 365

Microsoft Copilot Chat Incident: A Wake-Up Call for AI Assistant Security in Microsoft 365

The recent Microsoft Copilot Chat incident, in which enterprise users reportedly saw AI-generated summaries that included confidential content from Drafts and Sent Items despite sensitivity labels and DLP policies, has reignited a critical conversation about AI assistant security.

Microsoft clarified that Copilot did not bypass underlying access controls. But that explanation only addresses part of the problem. The real issue isn’t whether Microsoft Copilot broke security controls. It's that Copilot inherits user permissions, and can apply its extensive abilities to uncover data the user may have long forgotten (or never properly secured in the first place).

Copilot didn’t create new risks, it surfaced existing exposure - instantly, at scale, and in a way that made it visible. For organizations deploying Microsoft Copilot, that distinction matters.

Why the Microsoft Copilot Incident Matters More Than It Appears

Microsoft Copilot operates within the permissions of the signed-in user. On paper, that sounds safe. In reality, it means Copilot can access everything the user can access - across years of accumulated data.

In a typical Microsoft 365 environment, that includes:

  • Emails stretching back years
  • Linked SharePoint Online documents
  • OneDrive folders shared broadly across teams
  • External guest-accessible sites
  • Archived projects no one has reviewed in years

When Copilot summarizes a mailbox, it can follow embedded links into SharePoint and OneDrive. If those linked files contain overshared financials, HR investigations, contracts, or regulated data, Copilot can surface insights from them in seconds.

Previously, this data exposure existed quietly in the background. AI assistants remove friction:

  • No need to manually search multiple systems
  • No need to remember file locations
  • No need to understand organizational silos

A single natural-language prompt can traverse it all.

That is the shift. And that is the risk.

AI Assistants Change the Data Risk Model

Traditional enterprise security assumes that risk is constrained by human effort. Data may technically be accessible, but if it requires time, institutional knowledge, or manual searching, exposure is limited.

AI assistants like Microsoft Copilot eliminate those barriers.

Instead of asking, “Who has access to this file?” organizations must now ask:

What can an AI assistant synthesize from everything a user can access?

This is a fundamentally different security model.

The Microsoft Copilot Chat incident demonstrated that even when sensitivity labels and DLP policies are in place, unexpected AI-generated outputs can undermine confidence. The concern is not only regulatory exposure, its reputational, operational, and executive trust in AI initiatives.

Why Sensitivity Labels and DLP Are Not Sufficient for Copilot Security

Many organizations rely on Microsoft Purview, sensitivity labels, and Data Loss Prevention (DLP) policies to control how information is handled in Microsoft 365.

Those tools are essential, but they are not enough on their own.

In real-world environments:

  • Labels are inconsistently applied
  • Legacy data predates modern classification policies
  • SharePoint sites remain broadly accessible long after projects end
  • OneDrive folders accumulate stale and redundant files
  • Linked documents inherit exposure from misconfigured parent sites

AI assistants operate on access reality, not policy intention. If sensitive data is accessible (even unintentionally) Copilot can surface it. The Copilot Chat incident did not reveal a failure of AI. It revealed a failure of data posture alignment.

Microsoft Copilot Requires AI Data Readiness

Before enabling Copilot broadly across Microsoft 365, organizations need what can be described as AI Data Readiness.

AI Data Readiness means achieving continuous visibility into:

  • Where sensitive data lives
  • How it is shared internally and externally
  • Which SharePoint and OneDrive assets are overshared
  • Whether classification matches actual content
  • What historical data remains unnecessarily accessible

Without this foundation, Copilot becomes a force multiplier for hidden exposure.

With it, Copilot becomes a productivity accelerator.

DSPM: The Missing Layer in Secure Microsoft Copilot Deployment

Data Security Posture Management (DSPM) provides the continuous, data-centric visibility required for secure AI adoption.

Rather than focusing solely on permissions or labels, DSPM answers deeper questions:

  • What sensitive and regulated data exists across Microsoft 365?
  • Where is it exposed?
  • What is its purpose? 
  • Who can access it?
  • How does it move?
  • Is it properly classified and governed?

Sentra’s DSPM-driven approach continuously discovers and classifies sensitive data across SharePoint Online, OneDrive, cloud storage, and SaaS platforms. Using AI-enhanced classification, it differentiates routine collaboration documents from high-risk assets such as HR investigations, financial statements, intellectual property, and regulated PII or PHI.

This creates a unified, context-rich map of enterprise data exposure, the exact context Copilot relies on when generating responses.

From Visibility to Remediation

Once visibility exists, security teams can act with precision.

Instead of broadly restricting Copilot access, which reduces productivity, organizations can surgically reduce risk by:

  • Identifying overexposed SharePoint sites containing sensitive data
  • Detecting OneDrive folders shared with large groups or external guests
  • Removing stale, redundant, and “ghost” data
  • Reconciling missing or misaligned sensitivity labels
  • Aligning MPIP and DLP controls with actual content reality

The result is not AI avoidance. It is controlled AI expansion.

The Strategic Shift: Treat Copilot Security as a Data Problem

The Microsoft Copilot Chat incident should not trigger panic. It should trigger maturity.

AI assistants reflect the state of your data. If your Microsoft 365 environment contains overshared, misclassified, or stale sensitive information, AI will surface it.

Organizations that succeed with Microsoft Copilot will be those that:

  • Audit their Microsoft 365 data exposure continuously
  • Reduce unnecessary access before enabling AI at scale
  • Align labels, policies, and actual content
  • Limit AI blast radius through data posture improvements
  • Treat AI adoption as a data governance transformation

The conversation should move from “Is Copilot safe?” to:

Is our data posture ready for Copilot?

When DSPM underpins AI adoption, Copilot shifts from potential liability to competitive advantage.

Final Thought: AI Assistants Don’t Create Risk - They Reveal It

The Microsoft Copilot incident is not an isolated anomaly. It is an early indicator of how AI assistants will reshape enterprise security assumptions. Copilot can only summarize what users already have access to. If access is overly broad, outdated, or misconfigured, AI will expose that reality faster than any audit ever could.

Organizations that invest in AI Data Readiness today will not only prevent future incidents, they will accelerate secure AI transformation across Microsoft 365.

<blogcta-big>

Read More
Nikki Ralston
Nikki Ralston
February 25, 2026
3
Min Read

SOC 2 Without the Spreadsheet Chaos: Automating Evidence for Regulated Data Controls

SOC 2 Without the Spreadsheet Chaos: Automating Evidence for Regulated Data Controls

SOC 2 has become table stakes for cloud‑native and SaaS organizations. But for many security and GRC teams, each SOC 2 cycle still feels like starting from scratch; hunting for the latest access reviews, exporting encryption settings from multiple consoles, proving backups and logs exist - per data set, per environment. If your SOC 2 evidence process is still a patchwork of spreadsheets and screenshots, you’re not alone. The missing piece is a data‑centric view of your controls, especially around regulated data.

Why SOC 2 Evidence Is So Hard in Cloud and SaaS Environments

Under SOC 2, trust service criteria like Security, Availability, and Confidentiality translate into specific expectations around data:

Is sensitive or regulated data discovered and classified consistently?

Are core controls (encryption, backup, access, logging) actually in place where that data lives?

Can you show continuous monitoring instead of point‑in‑time screenshots?

In a typical multi‑cloud/SaaS environment:

  • Sensitive data is scattered across S3, databases, Snowflake, M365/Google Workspace, Salesforce, and more.
  • Different teams own pieces of the puzzle (infra, security, data, app owners).
  • Legacy tools are siloed by layer (CSPM for infra, DLP for traffic, privacy catalog for RoPA).

So when SOC 2 comes around, you spend weeks assembling a story instead of being able to show a trusted, provable compliance posture at the data layer.

The Data‑First Approach to SOC 2 Evidence

Instead of treating SOC 2 as a separate project, leading teams are aligning it with their data security posture management (DSPM) strategy:

  1. Start from the data, not from the infrastructure
  • Build a unified inventory of sensitive and regulated data across IaaS, PaaS, SaaS, and on‑prem.
  • Enrich each store with sensitivity, residency, and business context.

  1. Attach control posture to each data store
  • For each regulated data store, track encryption status, backup configuration, access model, and logging/monitoring coverage as posture attributes.

  1. Generate SOC‑aligned evidence from the same system
  • Use the regulated‑data inventory plus posture engine to produce SOC 2‑friendly reports and CSVs, rather than collecting evidence manually for each audit cycle.

This is exactly the pattern that modern data security platforms like Sentra are implementing.

How Sentra Helps Security and GRC Teams Automate SOC 2 Evidence

Sentra sits across your data estate and focuses on regulated data, with capabilities that map directly onto SOC 2 evidence needs:

Comprehensive data‑store discovery and classification
Agentless discovery of data stores (managed and unmanaged) across multi‑cloud and on‑prem, combined with high‑accuracy classification for regulated and business‑critical data.

Data‑centric security posture
For each store, Sentra tracks security properties—including encryption, backup, logging, and access configuration, and surfaces gaps where sensitive data is insufficiently protected.

Framework‑aligned reporting
SOC 2 and other frameworks can be represented as report templates that pull directly from Sentra’s inventory and posture attributes, giving GRC teams “audit‑ready” exports without rebuilding evidence from scratch.

The result is you can prove control over regulated data, for SOC 2 and beyond, with far less manual overhead.

Mapping SOC 2 Criteria to Data‑Level Evidence

Here’s how a data‑first posture shows up in SOC 2:

CC6.x (Logical and Physical Access Controls)

Evidence: Identity‑to‑data mapping showing which users/roles can access which sensitive datasets across cloud and SaaS.

CC7.x (Change Management / Monitoring)

Evidence: Data Detection & Response (DDR) signals and anomaly analytics around access to crown‑jewel data; logs that tie back to sensitive data stores.

CC8.x (Risk Mitigation)

Evidence: Risk‑prioritized view of data stores based on sensitivity and missing controls, plus remediation workflows or automatic labeling/tagging to tighten upstream policies.

When this data‑level view is in place, SOC 2 becomes evidence selection rather than evidence construction.

A Repeatable SOC 2 Playbook for Security, GRC, and Privacy

To operationalize this approach, many teams follow a recurring pattern:

  1. Define a “regulated data perimeter” for SOC 2: Identify which clouds, SaaS platforms, and on‑prem stores contain in‑scope data (PII, PHI, PCI, financial records).

  1. Instrument with DSPM: Deploy a data security platform like Sentra to discover, classify, and map access to that data perimeter.

  1. Connect GRC to the same source of truth: Have GRC and privacy teams pull their SOC 2 evidence from the same inventory and posture views Security uses for day‑to‑day risk management.

  1. Continuously refine controls: Use posture and DDR insights to reduce exposure, close misconfigurations, and improve your next SOC 2 cycle before it starts.

The more you lean on a shared, data‑centric foundation, the easier it becomes to maintain a trusted, provable compliance posture across frameworks, not just SOC 2.

Turning SOC 2 From a Project Into a Capability

Ultimately, the goal is to stop treating SOC 2 as a once-a-year project and start treating it as an ongoing capability embedded into how your organization operates. Security, GRC, and privacy teams should work from a single, unified view of regulated data and controls. Evidence should always be a few clicks away - not the result of a month-long scramble. And every audit should strengthen your data security posture, not distract from it. If you’re still managing compliance in spreadsheets, it’s worth asking what it would take to make your SOC 2 posture something you can prove on demand.

Ready to end the fire drills and move to continuous compliance? Book a Demo 

<blogcta-big>

Read More
Expert Data Security Insights Straight to Your Inbox
What Should I Do Now:
1

Get the latest GigaOm DSPM Radar report - see why Sentra was named a Leader and Fast Mover in data security. Download now and stay ahead on securing sensitive data.

2

Sign up for a demo and learn how Sentra’s data security platform can uncover hidden risks, simplify compliance, and safeguard your sensitive data.

3

Follow us on LinkedIn, X (Twitter), and YouTube for actionable expert insights on how to strengthen your data security, build a successful DSPM program, and more!

RSA 2026 Conference Logo
Going to RSA?

Meet with CISOs from Nestlé, SoFi, and PennyMac

Hear how they are making data AI ready

Join our exclusive RSA Roundtable 

Register Now