Editor’s note: Today we are hearing from Jono MacDougall , Principal Software Engineer at Ravelin. Ravelin delivers market-leading online fraud detection and payment acceptance solutions for online retailers. To help us meet the scaling, throughput, and latency demands of our growing roster of large-scale clients, we migrated to Google Cloud and its suite of managed services, including Cloud Bigtable, the scalable NoSQL database for large workloads.

As a fraud detection company for online retailers, each new client brings new data that must be kept in a secure manner and new financial transactions to analyze. This means our data infrastructure must be highly scalable and constantly maintain low latency. Our goal is to bring these new organizations on quickly without interrupting their business. We help our clients with checkout flows, so we need latencies that won’t interrupt that process—a critical concern in the booming online retail sector. 

We like Cloud Bigtable because it can quickly and securely ingest and process a high volume of data. Our software accesses data in Bigtable every time it makes a fraud decision. When a client’s customer places an order, we need to process their full history and as much data as possible about that customer in order to detect fraud, all while keeping their data secure. Bigtable excels at accessing and processing that data in a short time window. With a customer key, we can quickly access data, bring it into our feature extraction process, and generate features for our models and rules. The data stays encrypted at rest in Bigtable, which keeps us and our customers safe.

Bigtable also lets us present customer profiles in our dashboard to our client, so that if we make a fraud decision, our clients can confirm the fraud using the same data source we use.

We have configured our bigtable clusters to only be accessible within our private network and have restricted our pods access to it using targeted service accounts. This way the majority of our code does not have access to bigtable and only the bits that do the reading and writing have those privileges.

We also use Bigtable for debugging, logging, and tracing, because we have spare capacity and it’s a fast, convenient location. 

We conduct load testings against Bigtable.  We started at a low rate of ~10 Bigtable requests per second and we peaked at ~167000 mixed read and write requests per second  at absolute peak. The only intervention that was done to achieve this was pressing a single button to increase the number of nodes in the database. No other changes were made.

In terms of real traffic to our production system, we have seen ~22,000 req/s (combined read/write) on Bigtable in our live environment as a peak within the last 6 weeks.

Migrating seamlessly to Google Cloud 

Like many startups, we started with Postgres, since it was easy and it was what we knew, but we quickly realized that scaling would be a challenge, and we didn’t want to manage enormous Postgres instances. We looked for a kind of key value store, because we weren’t doing crazy JOINS or complex WHERE clauses. We wanted to provide a customer ID and get everything we knew about it, and that’s where key value really shines.  

I used Cassandra at a previous company, but we had to hire several people just for that chore. At Ravelin we wanted to move to managed services and save ourselves that headache. We were already heavy users and fans of BigQuery, Google Cloud’s serverless, scalable data warehouse, and we also wanted to start using Kubernetes. This was five years ago, and though quite a few providers offer Kubernetes services now, we still see Google Cloud at the top of that stack with Google Kubernetes Engine (GKE). We also like Bigtable’s versioning capability that helped with a use case involving upserts. All of these features helped us choose Bigtable.

Migrations can be intimidating, especially in retail where downtime isn’t an option. We were migrating not just from Postgres to Bigtable, but also from AWS to Google Cloud. To prepare, we ran in AWS like always, but at the same time we set up a queue at our API level to mirror every request over to Google Cloud. We looked at those requests to see if any were failing, and confirmed if the results and response times were the same as in AWS. We did that for a month, fine tuning along the way. 

Then we took the big step and flipped a config flag and it was 100% over to Google Cloud. At the exact same time, we flipped the queue over to AWS so that we could still send traffic into our legacy environment. That way, if anything went wrong, we could fail back without missing data. We ran like that for about a month, and we never had to fail back. In the end, we pulled off a seamless, issue-free online migration to Google Cloud.

Flexing Bigtable’s features

For our database structure, we originally had everything spread across rows, and we’d use a hash of a customer ID as a prefix. Then we could scan each record of history, such as orders or transactions. But eventually we got customers that were too big, where the scanning wasn’t fast enough. So we switched and put all of the customer data into one row and the history into columns. Then each cell was a different record, order, payment method, or transaction. Now, we can quickly look up the one row and get all the necessary details of that customer. Some of our clients send us test customers who place an order, say, every minute, and that quickly becomes problematic if you want to pull out enormous amounts of data without any limits on your row size. The garbage collection feature makes it easy to clean up big customers.  

We also use Bigtable replication to increase reliability, atomicity, and consistency. We need strong consistency guarantees within the context of a single request to our API since we make multiple bigtable requests within that scope. So within a request we always hit the same replica of Bigtable and if we have a failure, we retry the whole request. That allows us to make use of the replica and some of the consistency guarantees, a nice little trade-off where we can choose where we want our consistency to live.https://www.youtube.com/embed/0-eH5u7rrQQ?enablejsapi=1&

We also use BigQuery with Bigtable for training on customer records or queries with complicated WHERE clauses. We put the data in Bigtable, and also asynchronously in BigQuery using streaming inserts, which allows our data scientists to query it in every way you can imagine, build models, and investigate patterns and not worry about query engine limitations. Since our Bigtable production cluster is completely separate, doing a query on BigQuery has no impact on our response times. When we were on Postgres many years ago, it was used for both analysis and real time traffic and it was not the optimal solution for us. We also use Elasticsearch for powering text searches for our dashboard.

If you’re using Bigtable, we recommend three features:

• Key visualizer. If we get latency or errors coming back from Bigtable, we look at the key visualizer first. We may have a hotkey or a wide row, and the visualizer will alert us and provide the exact key range where the key lives, or the row in question. Then we can go in and fix it at that level. It’s useful to know how your data is hitting Bigtable and if you’re using any anti-patterns or if your clients have changed their traffic pattern that exacerbated some issue.
• Garbage collection. We can prevent big row issues by putting size limits in place with the garbage collection policies.  
• Cell versioning. Bigtable has a 3d array, with rows, columns, and cells, which are all the different versions. You can make use of the versioning to get history of a particular value or to build a time series within one row. Getting a single row is very fast in Bigtable so as long as you can keep the data volume in check for that row, making use of cell versions is a very powerful and fast option. There are patterns in the docs that are quite useful and not immediately obvious. For example, one trick is to reverse your timestamps (MAXINT64 – now) so instead of the latest version, you can get the oldest version effectively reversing the cell version sorting if you need it.

Google Cloud and Bigtable help us meet the low-latency demands of the growing online retail sector, with speed and easy integration with other Google Cloud services like BigQuery. With their managed services, we freed up time to focus on innovations and meet the needs of bigger and bigger customers. 

Learn more about Ravelin and Bigtable, and check out our recent blog, How BIG is Cloud Bigtable?

Many organizations require effective processes and techniques for removing or obfuscating certain sensitive information in the data they store. An important tool to achieve this goal is de-identification. Defined by NIST as a technique that “removes identifying information from a dataset so that individual data cannot be linked with specific individuals. De-identification can reduce the privacy risk associated with collecting, processing, archiving, distributing or publishing information.

Always striving to make data security easier, today we are happy to announce the availability of a de-identification action for our Cloud Storage inspection jobs. Now, you can de-identify Cloud Storage objects, folders, and buckets without needing to run your own pipeline or custom code. Additionally, we have enhanced our transforms by adding a new dictionary replacement method that can help you achieve stronger privacy protection – especially with unstructured data you might store like customer support chat logs.

The “De-identify findings” Action

The “de-identify findings” action for Cloud DLP inspection jobs is a fully managed feature that creates a de-identified copy of the data objects that are inspected. This means that you can inspect a Cloud Storage bucket for sensitive data like Personal Identifiable Information (PII) and then create a redacted copy of these objects all with a few clicks in the Console UI. No need to write custom code or manage complex pipelines and since it’s fully managed, it will auto-scale for you without you needing to manage quota.

This new action supports the following data types:

• Text files
• Comma- or tab-separated values
• Images (see regional limitations)

Once enabled, the DLP job will perform an inspection of the data and produce a de-identified copy of all supported files into the output bucket or folder.

You can also use the new de-identify action on Job Triggers to automatically de-identify new content as it appears on a recurring schedule. This is useful for creating a workflow with a safe drop zone for incoming files that need to be de-identified before being made accessible.

What can automatic De-identification do?

Cloud DLP provides a set of transformation techniques to de-identify sensitive data while attempting to make the data still useful for your business. These techniques include:

• Redaction: Deletes all or part of a detected sensitive value.
• Replacement: Replaces a detected sensitive value with a specified surrogate value.
• Masking: Replaces a number of characters of a sensitive value with a specified surrogate character, such as a hash (#) or asterisk (*).
• Crypto-based tokenization: Encrypts the original sensitive data value using a cryptographic key. Cloud DLP supports several types of tokenization, including transformations that can be reversed, or “re-identified.”
• Bucketing: “Generalizes” a sensitive value by replacing it with a range of values. (For example, replacing a specific age with an age range, or temperatures with ranges corresponding to “Hot,” “Medium,” and “Cold.”)
• Date shifting: Shifts sensitive date values by a random amount of time.
• Time extraction: Extracts or preserves specified portions of date and time values.

New Dictionary Replace method

When a sensitive data element is found, dictionary replacement replaces it with a randomly selected value from a list of words that you provide. This transformation method is especially useful if you want the redacted output to have more realistic surrogate values.

Consider the following example: You collect customer support chat logs as part of providing service to your customers. These support chat logs contain various types of Personal Identifiable Information (PII) including people’s names and email addresses. Cloud DLP can find and de-identify the sensitive elements with static replacements such as “[REDACTED]” to help prevent someone from seeing this sensitive data.

With the new dictionary replacement method you can instead replace these findings with a randomly selected value from a dictionary. This dictionary replacement provides two key benefits over static replacement:

1. The resulting output can look more realistic
2. Because the output looks more realistic, it can help conceal any residual names (a privacy de-identification technique sometimes referred to as “hiding in plain sight”)

An example of this:

Input:

[Agent] Hi, my name is Jason, can I have your name?

[Customer] My name is Valeria

[Agent] In case we need to contact you, what is your email address?

[Customer] My email is v.racer@example.org

[Agent] Thank you. How can I help you?

De-identified Output:

[Agent] Hi, my name is Gavaia, can I have your name?

[Customer] My name is Bijal

[Agent] In case we need to contact you, what is your email address?

[Customer] My email is happy.elephant44@example.org

[Agent] Thank you. How can I help you?

As you can see in the output, the names and email addresses have been replaced with a random value that both protects the original sensitive information but also makes the output look more realistic. This can make the data more useful and help “hide” any residual PII.

Next Steps:

To learn more about De-Identification check out our Technical Docs, try De-identification of Storage in the Cloud Console and Watch a recent Google I/O talk on De-identification of data.

Part of being a security leader whose organization is taking on a digital transformation is preparing for hard questions – and complex answers – on how to implement a transformation strategy.

In our previous CISO Survival Guide blog, we discussed how financial services organizations can more securely move to the cloud. We examined how to organize and think about the digital transformation challenges facing the highly-regulated financial services industry, including the benefits of the Organization, Operation, and Technology (OOT) approach, as well as embracing new processes like continuous delivery and required cultural shifts.

As part of Google Cloud’s commitment to shared fate, today we offer tips on how to ask the right questions that can help create the conversations that lead to better transformation outcomes for your organization. While there often is more than one right answer, a thoughtful, methodical approach to asking targeted questions and maintaining an open mind about the answers you hear back can help achieve your desired result. These questions are designed to help you figure out where to start and where to end your organization’s security transformation. By asking the following questions, CISOs and business leaders can develop a constructive, focused dialogue which can help determine the proper balance between implementing security controls and fine-tuning the risk tolerance set by the executive management and the board of directors.

To start the conversation, begin by asking:

• What defines our organization’s culture?
• How can we best integrate the culture with our security goals?

CISOs should ask business leaders:

• What makes a successful transformation?
• What are the key goals of the transformation?
• What data is (most) valuable?
• What data can be retired, reclassified, or migrated?
• What losses can we afford to take and still function?
• What is the real risk that the organization is willing to accept?

Business leaders should ask CISOs and the security team:

• What are the best practices for protecting our valuable data?
• What is the business impact of implementing those controls?
• What are the top threats that we need to address?

CISOs and business leaders should ask:

• Which threats are no longer as important?
• Where could we potentially use spending for more cost-effective controls such as firewalls and antivirus software?
• What benefits do we get from refactoring our applications?
• Are we really transforming, or lifting and shifting?
• How should we perform identity and access management to meet our business objectives?
• What are the core controls needed to ensure enterprise-level performance for the first workloads?

CISOs and risk teams should ask:

• How can we use the restructuring of an existing body of code to streamline security functions?
• How should we monitor our security posture to ensure we are aligned with our risk appetite?

Business and technical teams should ask:

• What’s our backup plan?
• What do we do if that fails?

Practical advice and the realities of operational transformation

Some organizations have been working in the cloud for more than a decade and have already addressed many operational procedures, sometimes with painful lessons learned along the way. If you’ve been operating in the cloud securely for that long, we recognize that there’s a lot to be gained from understanding your approaches to culture, operational expertise, and technology.

However, there are still many organizations that have not thought through how they will operate in a cloud environment until it’s almost ready – and at that point, it might be too late. If you can’t detail how a cloud environment will operate before its launch, how will you know who should be responsible for maintaining it?

Who are the critical stakeholders, along with those responsible for engineering and maintaining specific systems, who should be identified at the start of the transformation? There are likely several groups of stakeholders, such as those aligned with operations for transformation, and those focused on control design for cloud aligned with operations.

If you don’t have the operators involved in the design phase, you’re destined to create clever security controls with very little practical value because those tasked with day-to-day maintenance most likely won’t have the expertise or training to effectively operate these controls.

This is complicated by the fact that many organizations are struggling to recruit and retain resources with the right skills to operate in the cloud. We believe that training current employees to learn new cloud skills, and giving them the time away from other responsibilities, can help build skilled, diverse cloud security teams.

If your organization continually experiences high turnover in security leadership and skilled staff, it’s up to you to navigate your culture to ensure greater consistency. You can, of course, choose to supplement internal knowledge with trusted partners – however, that’s an expensive strategy for ongoing operational cost.

We met recently with a security organization that turns over skilled staff and leadership every two to three years. This rate of churn results in a continual resetting of security goals. This particular team joked that it’s like “Groundhog Day” as they constantly re-evaluate their best security approaches yet make no meaningful progress. This is not a model to emulate.

Many security controls fail not because they are improperly engineered, but because the people who use them – your security team – are improperly trained and insufficiently motivated. This is especially true for teams with high turnover rates and other organizational misalignments. A security control that blocks 100% of attacks might be engineered correctly, but if you can’t efficiently operate it, the effectiveness of the control will plummet to zero over time. Worse, it then becomes a liability because you incorrectly assume you have a functioning control.

In our next blog, we will highlight several proven approaches that we believe can help guide your security team through your organization’s digital transformation.

To learn more now, check out:

• Previous blog
• Podcast: CISO walks into the cloud: Frustrations, successes, lessons… and does the risk change?
• Report: CISO’s Guide to Cloud Security Transformation

European organizations are moving their operations and data to the cloud in increasing numbers to enable collaboration, drive business value, and transition to hybrid work. However, the cloud solutions that underpin these powerful capabilities must meet an organization’s critical requirements for security, privacy, and digital sovereignty. We often hear from European Union policymakers and business leaders that ensuring the sovereignty of their cloud data, through regionalization and additional controls over administrative access, is crucial in this evolving landscape.

Today, we’re announcing Sovereign Controls for Google Workspace, which will provide digital sovereignty capabilities for organizations, both in the public and private sector, to control, limit, and monitor transfers of data to and from the EU starting at the end of 2022, with additional capabilities delivered throughout 2023. This commitment builds on our existing Client-side encryption, Data regions, and Access Controls capabilities.

Offering enhanced customer controls, including Client-side encryption

Encryption is an important technical control that limits a cloud provider’s access to customer data. Google Workspace already uses the latest cryptographic standards to encrypt all data at rest and in transit between our facilities. The European Data Protection Board recommendations include encryption as part of the supplementary measures to protect data. Google Workspace is leading the way on such measures with our Client-side encryption feature that allows customers to continue benefiting from the powerful innovations of Google Cloud while retaining complete confidentiality and control over their data.

Google Workspace’s unique approach to client-side encryption provides our customers with authoritative privacy control over their data through encryption keys that they can hold on site, within a nation’s borders, or within any other boundary they define. Google never has access to the keys or key holders, which means the data is indecipherable to us and we have no technical ability to access it. We deliver this level of encryption without the need for legacy desktop clients, while maintaining the same high-quality experience for your users such as online co-authoring.

Organizations can choose to use Client-side encryption pervasively across all their users, or create rules that apply to specific users, organizational units, or shared drives. Client-side encryption is now generally available for Google Drive, Docs, Sheets, and Slides, with plans to extend the functionality to Gmail, Google Calendar, and Meet by the end of 2022.

Expanding data location controls

Data regions already allow our customers to control the storage location of their covered data at-rest. We will enhance this capability by the end of 2023 through expanded coverage of data storage and processing in-region along with an in-country copy.

As employees and organizations adopt new ways of working in a hybrid world, they need secure access to data to drive key business outcomes. But this trend, combined with complex technical architectures, presents significant challenges to retaining control over where data resides.

Our cloud-native architecture means that Google Workspace functions fully within a browser, without requiring caches or installed software on employee devices. We adopt a zero-trust approach, with built-in security that provides controls to geo-fence devices and users through Context Aware Access. Moreover, admins can set sharing boundaries and define rules that govern user communication.

In short, we empower admins with critical capabilities that can give them granular control over the flow of their data without hindering the modern collaboration capabilities that form the foundation of Google Workspace. We are enabling organizations to strike the right balance between data location and collaboration across teams, partners, and customers.

Control and transparency for administrative access

When moving to a cloud-based service, organizations need greater visibility and control over all forms of administrative access to their systems, including who has access, the nature and circumstances of that access, and the ability to specify that only certain personnel—in designated countries or regions—have access. These capabilities are core to our approach for meeting evolving digital sovereignty standards.

Building on this approach, we will implement a series of new Access Controls by the end of 2023 that will enable customers to:

• Restrict and/or approve Google support access through Access Approvals.
• Limit customer support to EU-based support staff through Access Management.
• Ensure round-the-clock support from Google Engineering staff, when needed, with remote-in virtual desktop infrastructure .
• Generate comprehensive log reports on data access and actions through Access Transparency, which is already available in GA.

Sovereign Controls for Google Workspace will deliver digital sovereignty through a comprehensive set of capabilities for organizations working in and across EU regions. In parallel, Google Cloud will continue to provide customers with legal mechanisms for international data transfer, which will include making the protections offered by the new EU data transfer framework available once it is implemented.

We remain committed to equipping our customers in Europe and across the globe with powerful technical solutions that help them adapt to, and stay on top of, a rapidly evolving regulatory landscape. We’ve designed and built Google Workspace to operate on a secure foundation, providing capabilities to keep our users safe, their data secure, and their information private. Digital sovereignty is core to our ongoing mission in Europe and elsewhere, and a guiding principle that customers can rely on now and into the future.

In every industry, in every part of the world, cybersecurity concerns continue to grow in the wake of attacks on critical infrastructure and the software supply chain. Governments and businesses of all sizes recognize that they must do more to protect their employees, customers and citizens. 

But doing more of the same, like putting security band-aids on legacy infrastructure, is no longer helpful or productive. We need an enduring commitment, in products, people and monetary terms, to drive meaningful improvements in our collective security posture. Google recently announced a $10 billion investment to advance the security of governments around the world, and by extension, help enterprises and organizations to do the same. 

Over the past year, Google Cloud has been delivering on our vision of Invisible Security for our customers, where capabilities are continuously engineered into both our trusted cloud platform and market-leading products to bring the best of Google’s security to wherever your IT assets are. But being a provider of best-in-class technology is not enough. We want to share our expertise to help organizations with their security transformation and offer even more ways to accelerate these essential improvements. This week, at Google Cloud Next ‘21, we’re sharing the first of what will be many more steps in advancing these efforts.

Introducing our Cybersecurity Action Team

While access to the latest, most advanced security technology is important, the expertise of what it will take to become resilient in the face of today’s risk and threat environment is foundational.  

Today, we’re announcing the formation of the Google Cybersecurity Action Team. The Google Cybersecurity Action Team marshals experts from across Google to form what we believe will be the world’s premier security advisory team. It has a singular mission to support the security and digital transformation of governments, critical infrastructure, enterprises and small businesses.

Building on existing security solutions engineering efforts, today the Google Cybersecurity Action Team announced a security and resilience framework that delivers a roadmap for a comprehensive security management program aligned with the National Institute of Standards and Technology’s Cybersecurity Framework using cloud technologies from Google Cloud and our partners. 

“Google Cloud has been a critical partner in the BBVA security journey, helping us protect our customers’ sensitive and proprietary data with modern frameworks like zero trust and secure-by-default products like Google Workspace,” said Alvaro Garrido, Chief Security Officer at BBVA. “We look forward to the strategic services and guidance the Google Cybersecurity Action Team will deliver as we continue on our security transformation.”

Learn more about the Cybersecurity Action Team here. 

Announcing a safer way to work

Bringing you the expertise and hands-on guidance to help with your security transformation is just one valuable step. We recognize that too many organizations can’t wait any longer to begin their modernization efforts – they need a new baseline, and they need it now. 

That’s why today, we’re announcing the launch of our Google Work Safer offering, designed to help organizations, their employees, and partners collaborate and communicate securely and privately in today’s hybrid work environment. Work Safer provides companies with access to best-in-class security for email, meetings, messages, documents, and more. It uniquely brings together the cloud-native, zero-trust solutions of Google Workspace with BeyondCorp Enterprise for secure access with integrated threat and data protection. For customers who want secure devices, Work Safer includes Pixel phones managed with Android Enterprise, Chrome Enterprise Upgrade, and HP Chromebooks. Customers can also leverage Google’s Titan Security Keys for account protection, reCAPTCHA Enterprise for website fraud prevention, Chronicle for security analytics, and a variety of migration services for a seamless transition.

The program is designed to meet the needs of all organizations, including small businesses, enterprises and public sector institutions, many of which are reliant on legacy technology and often lack expertise to fully address rising security challenges associated with hybrid work. To learn more, visit our Work Safer homepage. 

Advancing our trusted cloud with new security capabilities

Above all, security has been and continues to be the cornerstone of our product strategy. There are three critical areas where Google Cloud’s capabilities can make a meaningful difference for any business’ or government’s digital security transformation:

At Next’ 21, we’re introducing new security products and partnerships that will enable you to:

• Protect your employees with new zero trust access capabilities: We’re delivering new features that expand the surface area for our zero trust access solution, BeyondCorp Enterprise, to cover all your apps – both modern and legacy. The new client connector, now in preview, enables identity and context-aware access to non-web applications running in Google Cloud and non-Google Cloud environments. We are also making it easier for admins to diagnose access failure, triage events, and unblock users with the new Policy Troubleshooter feature. You can learn more about both of these new enhancements in the live BeyondCorp Enterprise demo on October 13.
• Improve your detection and response capabilities: We announced a new collaboration with Cybereason for Extended Detection and Response (XDR) across endpoints, networks, cloud and workspaces. The combination of these capabilities delivers a cloud-native XDR solution, Cybereason XDR powered by Chronicle, that automates prevention for common attacks, guides analysts through security operations and incident response, and enables threat hunting with precision at a pace never before achieved. We are also deepening the integration between Chronicle and Security Command Center (SCC) on GCP. New integrations in preview centralize alerts and investigative workflows across the two platforms, and enable threat-specific pivots by enriching SCC alerts with intelligence on associated threat actors and entities. 
• Automate and bolster protection of your sensitive data: Automatic DLP, now in preview, is a prime example of how we are making Invisible Security a reality. It’s a game-changing capability that discovers and classifies sensitive data for all the BigQuery projects across your entire organization without you needing to do a single thing. We’re also introducing Ubiquitous Data Encryption, a solution which combines our generally available Confidential Computing, External Key Management, and Cloud Storage products to seamlessly encrypt data as it’s sent to the cloud. Using your External Key Management solution, data can now only be decrypted and run in a confidential VM environment, greatly limiting potential exposure.
• Protect your IP and implement a zero trust software supply chain: Today, we’re building on our zero trust software supply chain with new launches. Cloud Build is SLSA Level -1 compliant by default, with scripted builds and available provenance. With the new Build Integrity feature, Cloud Build automatically generates a verifiable build manifest that includes a signed certificate describing the sources that went into the build, the hashes of artifacts used, and other parameters. Additionally, Binary Authorization’s integration with Cloud Build makes it easy to set up deploy-time constraints. You can also now easily pair Binary Authorization with Cloud Run to ensure only trusted images make it to production. These integrations are now generally available.
• Protect your users and brand: We recently announced the preview of Cloud Armor Bot Management, which integrates Cloud Armor and reCAPTCHA Enterprise. You can enable protection without any server-side changes to your applications, and because detection and enforcement happens in-line, at the edge of Google’s network, you can mitigate threats before they have a chance to impact your applications, whether they run on GCP, on premise, or in a hybrid or multicloud deployment.
• Ensure secure collaboration: Today, Google Workspace is also introducing new security features. Client-side encryption for Google Meet, in beta, gives customers direct control of encryption keys and the identity service used to access keys. Data Loss Prevention (DLP) for Google Chat, in beta, helps prevent sensitive information from leaking outside of your organization. Check out the blog post from Google Workspace to learn more. 

As we head into three days of great content and engagements from our security and technology teams across Google Cloud at Next ‘21, we want to leave you with this: You are not alone on your security journey. Our goal is to ensure that every day, you are making your organization safer because you have partnered with us. Please make sure to watch our security experts, customers, and partners in our track sessions to go deep on the topics and products that matter most to you.