Our Cloud Data Loss Prevention (Cloud DLP) discovery service can monitor and profile your data warehouse to bring awareness of where sensitive data is stored and processed. Profiling is also useful for confirming that data is not being stored and processed where you don’t want it. 

But how can you make use of this intelligence within your existing security and governance workflows so you can reduce risk? Starting today, we have integrated Cloud DLP’s sensitive-data discovery service with Security Command Center, our platform-native security and risk management solution. By bringing together sensitive data intelligence with your security controls, security teams can identify and act quickly on the vulnerabilities and help address threats that matter for your organization.

Data sensitivity and risk prioritization

Not all security threats, vulnerabilities, and misconfigurations generate an equal degree of risk. Some affect only test data or development environments. But others can place your organization’s sensitive information at risk of exposure or misuse. Understanding what to prioritize is often a big challenge for security professionals.

When this awareness is fed into Security Command Center, it allows your team to prioritize the Security Command Center findings that are driving greater security and compliance risk, and to help make informed decisions as to how to address those issues.

Understanding BigQuery data exfiltration threats

Security Command Center’s threat detection capability can analyze access and copy behavior of BigQuery data to help detect potential risk of exfiltration. With Cloud DLP intelligence on where sensitive data lives in BigQuery tables and datasets, you can now focus and prioritize on the exfiltration findings tied to your sensitive assets.

Remediation and data security posture management

The intelligence from Cloud DLP’s sensitive-data discovery service helps you take a data-first approach to securing your assets.  Use insights like Cloud DLP’s predicted infoType to apply column-level, fine-grained access or dynamic masking policies and consider de-identification to further help reduce the risk of data use operations and improve your overall security, privacy, and compliance posture.

Get started

To get started with richer sensitive data intelligence, enable the connection between Cloud DLP’s discovery service and Security Command Center.  There is no additional cost to enable the integration for users of both products.  

As soon as it’s enabled, you can begin to use your sensitive data intelligence to supercharge your security and support your compliance teams’ work.

Read more about how the sensitive data discovery service can meet your organization’s needs, and how you can get started managing your security posture with Security Command Center.

In May, the White House issued an Executive Order aiming to improve the nation’s cybersecurity defenses and requiring US Federal agencies to develop plans to implement Zero Trust architectures in alignment with National Institute of Standards and Technology National Institute of Standards and Technology (NIST) guidance. This Executive Order also calls on agencies to accelerate cloud adoption, with a preference for cloud capabilities that implement or advance the adoption of Zero Trust. 

Zero Trust moves front and center 

The White House guidance is timely and necessary given the surge of ransomware and other cyber attacks over the past year targeting remote workers and VPNs, software supply chains, identity infrastructure and email, and various critical infrastructure sectors. These attacks have raised concerns about cyber-risk across the board, including pervasive IT monocultures that persist, unquestioned, despite their exploitability by attackers. 

This order ties together multiple strands of US cybersecurity best practices and policy that have evolved over the past decade, including stronger identity and access controls, expanded use of encryption and authentication, increased monitoring and visibility, and prioritizing high-value IT assets. Yet the urgent challenge of cybersecurity requires more than simply adding to the existing proliferation of cyber tools or ratcheting up traditional measures around hygiene and compliance. The Administration’s focus on Zero Trust marks a critical shift to prioritizing architectures in which the strategic coordination of layered cyber defenses drives improved cyber outcomes.  

In many ways then, the demand for accelerating the adoption of Zero Trust in federal IT is not a new requirement, as departments and agencies are already implementing many of the core technical components that can contribute to achieving the goals laid out in the executive order.  

What is new, however, is the fact that Zero Trust, when done right, is primarily an outcomes-oriented approach to security. Successfully implementing Zero Trust can drive down cyber risk, transform the daily security experience of users, reduce management complexity and toil for IT managers, and improve the overall productivity of the workforce. 

Outcomes, not just technology 

Successfully implementing Zero Trust is not about the individual technology components and inputs themselves.  Instead, what matters most is how security components are integrated and orchestrated to achieve and enforce a simple set of core principles: 

• Connecting from a particular network must not determine which services you can access
• Access to services and data is granted based on what we know about you and your device
• All access to services must be authenticated, authorized and encrypted.  

Using this set of principles as our north star, Google began our Zero Trust journey, with BeyondCorp, over a decade ago, under similar circumstances to those driving federal cybersecurity policy now. Google had been targeted by nation-state cyber attacks (Operation Aurora), and in the aftermath, we recognized that providing remote access with VPNs was not sustainable or efficient for business performance, especially at a time when Google’s global workforce was growing rapidly. Something had to change.

To improve our security posture and user experience, we had to reimagine our infrastructure and production networks. This ultimately drove innovations in how we protect our supply chains and resulted in a complete rethinking of the scale, analytics and visibility needed to fully modernize and transform enterprise security. The journey forced us to consolidate redundant systems, understand usage patterns better, and transform how people experience security day to day.

A shift in technology and a change in mindset

When we developed BeyondCorp, we had to reimagine our infrastructure and production networks in order to affect a better security posture and user experience. This ultimately drove innovations in how we protect our supply chains and resulted in a complete rethinking of the scale, analytics and visibility needed to fully modernize and transform enterprise security. 

Moving to a Zero Trust approach drastically changed how Google’s end users did business and reduced the toil on both individual users and IT professionals to do their part to secure the enterprise, further fostering  the innovation, architectures, operational integrations and best practices we see today. Now, the layered defenses and invisible security our users experience have been incorporated into Google’s secure cloud offerings, so our customers can experience the same benefits and provide their users with a secure and productive work environment. 

Leadership for a cross-team journey

Of course, change isn’t trivial, especially in government. A shift in behavior, user experience, collaboration, tools and infrastructure requires planning, change management, and executive support.  To make the Zero Trust journey a success, organizations need the long-term focus and vision of leadership to drive meaningful change. For traditional security and technology leaders, accelerating the journey to Zero Trust will require them to think less tactically and and act more strategically, in order to focus more on outcomes and less on inputs, and to integrate, harmonize, orchestrate and automate what were previously standalone IT and security efforts.  For non-technology leaders, their engagement and leadership is essential – and much more likely – given the visible benefits to collaboration, culture, and the business from what could otherwise be seen as a technology-centric initiative.      

Done right, Zero Trust brings a sea change from how most people experience security.  The crossroads of the Zero Trust journey present organizations with two clear choices: stick with an old and not-so-secure security model that’s clunky and burdensome, or adopt a new model that’s more intuitive, easy, and secure.  

Jump start your own journey

Today, the same opportunity exists to transform government security, operations, and organizational models by implementing Zero Trust. By sharing lessons learned from Google’s BeyondCorp journey and building core security capabilities into many of our cloud products, our goal is to help government agencies  accelerate their own Zero Trust journey, transforming the security posture of their highest value and most-critical applications and data.  

To learn more, watch our on-demand sessions from the Google Cloud Government Security Summit,

About the authors

Dan Prieto previously served in the White House as Director for Cybersecurity Policy on the staff of the National Security Council.  He also served as CTO and Director of the Defense Industrial Base Cybersecurity Program in the Office of the Department of Defense CIO.

Max Saltonstall tells stories about Google Cloud, how we use similar Cloudy tools inside Google, and what diverse solutions Cloud’s many customers have created. At Google he’s worked within DoubleClick, Corporate Engineering, Staffing and the Cloud CTO Office.

Digital transformation is now a strategic imperative for organizations across every industry. For governments and regulated businesses, moving services to the cloud poses a unique set of challenges.

As a vital enabler of transformation, the cloud can unlock innovation and help keep pace with the accelerating pace of digital business. Unfortunately, many government agencies and firms in regulated industries don’t have the luxury of adopting new systems at will. They must deal with issues such as limited resources, lack of digital skills, and siloed operations. However, they also face cloud-specific challenges, including: 

• Data sovereignty: Regulated industries and the public sector often have concerns about the location of data, how it is protected, who else can access it, and whether it is stored in a secure location.
• Compliance: Government agencies and regulated businesses must ensure that their data and cloud use are compliant with all applicable government requirements, privacy and data protection laws, and other regulations.
• Security: Compliance is a natural component of any strong approach to security. As a result, government regulations and industry standards mandate a responsibility to secure and protect data from unauthorized access or use. 
• Cost: Every organization wants to ensure it’s getting good value for their money when using cloud computing, but especially government agencies that are more likely to be working with fixed budgets and fewer resources. 

To address the unique requirements of governments and other highly regulated organizations, some cloud providers have built separate government clouds (“GovClouds”) that run in specialized, stand-alone data centers that make it easier to meet specific requirements around data residency, personnel controls, and other government standards. However, isolated GovCloud environments come with limitations: They can restrict the ability to integrate regulated data with data from other sources, they create siloed infrastructure that can slow down access to new features and technologies, and they usually require more resources to manage and maintain, which translates into higher costs for end-users of GovCloud services.

But what if you could get the features of a government cloud — the certifications and strict controls on data residency and personnel access — on a commercial cloud? 

This is where Assured Workloads comes in. Assured Workloads is a unique Google Cloud service that allows governments and organizations from regulated industries to meet stringent compliance requirements at scale on commercial cloud infrastructure. 

What is Assured Workloads?

Assured Workloads provides a set of security controls and guardrails you can apply to your cloud environments, making it easier to achieve compliance while maintaining the advantages of a full commercial cloud. It includes features like data residency controls for specific compliance types, data and personnel access controls, and real-time monitoring for compliance violations to ensure you implement and maintain the cloud controls required by your compliance regimes. 

Check out our Best Kept Security Secrets series

• Tap into the power of Organization Policy Service
• How VPC Service Controls can help build defense in depth
• How Cloud EKM can help resolve the cloud trust paradox

Assured Workloads can make it easier for agencies and businesses in regulated sectors to meet compliance requirements by providing: 

• A secure and compliant environment: With Assured Workloads, you can create controlled environments for your regulated workloads and automatically enforce data location and resource deployment. It’s designed for customers that need to meet strict security and compliance requirements, such as the government, healthcare, and financial services sectors. 
• Broad security capabilities: Assured Workloads provides comprehensive security for your regulated workloads. Data is encrypted at rest and in transit by default and includes additional features, such as encryption key management according to your compliance regime and Identity and Access Management (IAM) for authentication, authorization, and user access management. 
• Support for multiple compliance frameworks: Assured Workloads is designed to create regulated boundaries on public cloud infrastructure that support multiple compliance frameworks across sectors, including FedRAMP, IL5, PCI DSS, SOC 2, HIPAA, and HITRUST, allowing customers to segment and label their regulated data.
• Control data residency: Assured Workloads gives you the ability to control the regions where data at rest is stored. 
• Assured support: Assured Workloads’ approach ensures only Google Cloud support personnel meeting specific geographical locations and personnel conditions support customers’ workloads.

Instead of having to configure, manage, and maintain the right controls and guardrails yourself, you select the regulatory framework you need to follow. Assured Workloads automatically configures and deploys the controls needed to help meet your requirements. 

With these specific capabilities, governments can simplify compliance configurations and monitor for violations without missing out on Google Cloud’s innovative technologies, scalability, performance, reliability, and cost savings that are hallmarks of our commercial Cloud offering. 

How it works

When you use Assured Workloads to create controlled environments in Google Cloud, you will be required to set up an Assured Workloads folder. This folder acts as the regulatory boundary to help enforce your chosen compliance framework. They are created with preconfigured platform controls, which are packaged based on the specified regulated data type, personnel controls, and data location. 

Assured Workloads automatically restricts developers to using products and services that are in-scope for your selected compliance framework. Security controls are mapped to Assured Workloads folders, so any Google Cloud resources you deploy in an Assured Workloads folder inherit the same controls. This also helps ensure that only Google Cloud personnel who meet your compliance requirements have the ability to support your resources and prevents resources from being deployed outside of compliant regions. 

Depending on your compliance regime, Assured Workloads supports several different options for encryption. You can use any Google key management service unless your compliance requirements mandate otherwise, including Cloud Key Management Service, Cloud External Key Manager, or customer-managed encryption keys (CMEK). You can also choose Google-managed keys, which provide on-by-default FIPS-validated encryption. 

Here are a few common use cases that companies are already accomplishing with Assured Workloads:

• Iron Mountain uses Assured Workloads to serve our customers’ compliance needs
• Implementing EU Data Sovereignty
• Running CJIS workloads 

However, Assured Workloads is more than a better government cloud or a tool for highly regulated businesses. Assured Workloads is a packaged solution that provides security by default and removes toil and complexity for users. Users can reduce the time and effort required to meet their compliance requirements and also improve the security of their data.

Do I need Assured Workloads? 

We believe that cloud adoption for governments, government suppliers and contractors, and other strictly regulated businesses shouldn’t have to happen in a separate, isolated cloud environment that forces tradeoffs in terms of service availability, scale, and cost. Assured Workloads is a new approach to running regulated workloads that transforms the “govcloud” into a capability that cuts down on the friction of compliance without sacrificing any of the cloud-y goodness. 

To learn more about Assured Workloads, please review these resources: 

• Getting started with Assured Workloads
• Overview of Assured Workloads

Request a free trial today and experience how Aside Assured Workloads helps you achieve compliance-based outcomes.

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?

These days, using a password alone to secure user accounts containing sensitive, identifiable, or private information just isn’t sufficient. Passwords are often subject to reuse and can easily be phished and stolen. 

With this in mind, we recently teamed up with researchers from New York University and the University of California, San Diego to find out just how effective basic account hygiene is at preventing account takeovers. The research showed that simply adding a SMS as a second factor to a Google account can block up to 100% of automated bots, 96% of bulk phishing attacks, and 76% of targeted attacks that occurred during our investigation.

To help you enhance the security of your apps and protect your users, Identity Platform now supports multi-factor authentication (MFA) with SMS in beta.

You can now configure Identity Platform to require users who attempt to login to your application to self-enroll in MFA—also known as two-factor authentication (2FA)—and register a device that is capable of receiving SMS messages. When users attempt to sign-in to your app with their first-factor credential (email/password, social login, SAML, OIDC), Identity Platform will require them to enter the six-digit authentication code that it sends via SMS to their registered devices before they can sign-in to your apps and services. 

Getting started

You can learn more about this new feature by checking out the documentation page. To get started with Identity Platform, enable it in GCP Marketplace, watch our Cloud Next ‘19 presentation, and read the quickstart.