We’re pleased to announce that Confidential Space, our new solution that allows you to control access to your sensitive data and securely collaborate in ways not previously possible, is now available in public Preview. First announced at Google Cloud Next, Confidential Space can offer many benefits to securely manage data from financial institutions, healthcare and pharmaceutical companies, and Web3 assets. Today, we will explore some security properties of the Confidential Space system that makes these solutions possible.

Confidential Space uses a trusted execution environment (TEE), which allows data contributors to have control over how their data is used and which workloads are authorized to act on the data. An attestation process and hardened operating system image helps to protect the workload and the data that the workload processes from an untrusted operator.

The Confidential Space system has three core components:

1. The workload is a containerized image with a hardened OS that runs in a cloud-based TEE. You can use Confidential Computing as the TEE that offers hardware isolation and remote attestation capabilities.
2. The attestation service, which is an OpenID Connect (OIDC) token provider. This service verifies the attestation quotes for TEE and releases authentication tokens. The tokens contain identification attributes for the workload.
3. A managed cloud protected resource, such as a Cloud Key Management Service key or Cloud Storage bucket. The resource is protected by an allow policy that grants access to authorized federated identity tokens.

The system can help ensure that access to protected resources is granted only to authorized workloads. Confidential Space also can help protect the workload from inspection and tampering, before and after attestation.

In our published Confidential Space Security Overview research paper, we explore several potential attack vectors against a Confidential Space system and how it can mitigate those threats. Notably, the research notes how Confidential Space can protect against malicious workload operators and administrators, and malicious outside adversaries, who are attempting to create rogue workload attestations.

Through these protections, Confidential Space establishes confidence that only the agreed upon workloads will be able to access sensitive data. The research also highlights some of the extensive security reviews and tests executed to identify potential weak points in the system, including domain expert reviews, meticulous security audits, and functional and fuzz testing.

We asked the NCC Group for an independent security assessment of Confidential Space to analyze its architecture and implementation. NCC Group leveraged their experience reviewing other Google Cloud products to dig deep into Confidential Space.

The NCC Group’s extensive review, which included penetration testing and automated security scanning, found zero security vulnerabilities. In their report, the architecture review highlights how the security properties are achieved through the coordination of measured boot with vTPM attestation, reduced attack surface with constricted administrator controls and access, workload measurement and enforced launch policy, and resource protection policy based on attested workload runtime properties.

The combination of these attributes creates powerful security properties, gating release of data on runtime measurements of the actual workload code and environment instead of just user and service account credentials. Confidential Space provides a platform that includes:

• A dependable workload attestation, including workload code measurement, arguments and environment, and operating environment claims
• A fully-managed attestation verification service that validates expected environmental attestation claims
• A policy engine allowing for arbitrarily complex (or extremely simple) policy to be created around those claims
• A mechanism to attach those policies to Google Cloud resources

Together, the platform provides a mechanism where one can ensure that their data is only ever released into trusted workloads that will not abuse that data.

Take a look at our documentation and codelab and take it for a spin. We hope that Confidential Space can inspire organizations to solve their use cases around multi-party collaboration with sensitive data; please contact your Google Cloud sales representative if you have any questions.

Since Aristocrat’s founding in 1953, technology has constantly transformed gaming and the digital demands on our gaming business are a far cry from challenges we faced when we started. As we continue to expand globally, security and compliance are top priorities.

Managing IT security for several gaming subsidiaries and our core business became more complex as we entered into new markets and scaled up our number of users. We needed a centralized platform that could give us full visibility into all of our systems and efficient monitoring capabilities to keep data and applications secure. We also needed the ability to secure our systems without compromising user experiences.

We turned to Google Cloud and Splunk to better manage complexity and support highly efficient, secure, and more dynamic gaming experiences for everyone. We are committed to using today’s modern technologies to give players more optimal experiences.

Bringing our digital footprint into the cloud

When we set out on our digital transformation, we looked to address many business requirements.

These requirements included:

• Regulation: We wanted a platform that could efficiently address our industry’s stringent and global regulatory compliance requirements.
• Player experience: Our IT environment must support smooth gaming experiences to keep users engaged and satisfied.
• Scalability: As we grow and diversify, meeting the changing demands of an increasingly global gaming community, we need an easily scalable platform to align with our current and future needs.

Google Cloud offered us the perfect foundation through solutions such as Compute Engine, Google Kubernetes Engine, BigQuery, and Google Cloud Storage. These acted as the right infrastructure components for us for the following reasons:

• Google Cloud is globally accessible and supports compliance, helping to streamline security and regulatory processes for our team.
• With Google Cloud, we can manage our entire development and delivery processes globally with fast and efficient reconciliation of regional compliance requirements.
• When we need to adjust existing infrastructure or deliver new capabilities, Google Cloud accelerates the process and takes the heavy lifting off of our team.
• Google Cloud allows us to support tens of thousands of players on each of our apps while experiencing minimal downtime and low latency. The importance of this support can’t be underestimated in an industry where players have little to no patience if lags in games occur.

We migrated our back-office IT stack alongside our consumer-facing production applications to Google Cloud given our positive experiences with compliance, security, scalability, and process management. This migration has significantly accelerated our digital transformation while streamlining our infrastructure for faster and more cost-effective performance.

In many ways, Google Cloud has been, with maybe a pun intended, a game-changer for us. For instance, when we suddenly had to support a lot of remote work during the COVID-19 pandemic, native identity and access management tools in Google Cloud allowed us to retire costly VPNs used for backend access and quickly adopt a more easily managed, cost-effective zero-trust security posture.

Accessing vital third-party partners and managed services

Aristocrat has many IT needs best addressed in a multi-cloud environment. Google Cloud is particularly attractive given its strong cloud interoperability, as well as the many products and services available on Google Cloud Marketplace. The marketplace accelerated our deployment of key third-party apps including Splunk and Qualys.

Given the personal information we store and the global regulatory compliance statutes we must oblige, security lies at the heart of our business. Splunk is a critical component of our digital transformation because it offers solutions that provide the enhanced monitoring capabilities and visibility we need. The integration between Splunk and Google Cloud gives us confidence that our data is secure. We know our data can be secure in Google Cloud, while simplified billing through Google Cloud Marketplace makes payments and license tracking easier for our procurement team.

As part of our protected environment, we use the Splunk platform as our security information and event management system, leveraging the InfoSec app for Splunk that provides continuous monitoring and advanced threat detection to significantly improve our security.

We can manipulate and present data in Splunk in a way that provides us with a single pane-of-glass for our hybrid, multi-cloud environment and our third-party apps and systems. Splunk observability tools have likewise helped us to track browser-based applications like our online gaming apps to monitor details related to security and performance.

Splunk and Google Cloud have transformed how we operate. We can now quickly ingest and analyze data at scale within our refined approach to security management by offloading software management to Splunk and Google Cloud. This ability enables us to approach security more strategically, and positions us to integrate more AI/ML capabilities into our products for even greater governance and performance.

This is just the beginning of our journey with Splunk and Google Cloud. We’re excited to see the innovation we can continue bringing to the gaming community worldwide.

Security is often seen as a zero-sum game between “go fast” or “stay secure.” We would like to challenge this school of thought and introduce a framework to change that paradigm to a “win-win game,” so you can do both—“go fast” and “stay secure.”

Historically, application security tools have been implemented much like a gate at a parking lot. The parking lot has perimeter-based ingress and egress boom gates. The boom gates let one car through at a time, and vehicles often are backed up at the gates during busy hours. However, there are few controls once you get inside. You can access nearly any space on any level and easily move between levels.

When you apply this analogy to application development, AppSec tools are often implemented as “toll gates” within waterfall-native workflows. Developers are required to get in line, submit to a security scan, and wait to see the results. When the results are produced, developers spend significant time and energy investigating red flags raised by security. This process is slow and, not surprisingly, not very popular with developers. It’s why they often view traditional security programs as inhibitors to innovation.

Guardrails not gates

We suggest a workflow that’s less like a parking lot gate and more like a freeway with common-sense safety measures. Freeways have directive rules for all users. Speed limits, single direction of travel, and mandatory speed reduction zones when exiting contribute to freeway safety. Some freeways implement preventative measures based on these rules, such as physical walls dividing opposite flows of traffic and protective guardrails to reduce collisions and keep vehicles from veering off the road. While driving on a freeway comes with its own complications, there are no boom-style gates blocking your path.

Following the same directive rules, there are detective and responsive controls, such as speed detectors, cameras, signs reminding drivers which direction they are going, and how fast they are traveling. Some freeways have deployed rumble strips to remind a dozing driver to stay in their lane.

Applying lessons from freeways to application development and compliance in the cloud represents the perfect opportunity to build software more securely.

Modern application security tools should be fully automated, largely invisible to developers, and minimize friction within the DevOps pipeline. To do this, these security tools should work the way developers want to work. Security controls should integrate into the development lifecycle early and everywhere. These controls should live within the developer’s preferred tools and create rapid feedback loops so mistakes can be remediated as soon as possible.

A typical compliance cycle looks like this:

Here, we highlight the gap between the desired state and the actual state that becomes problematic when audit times come. This increases the overall cost of the audit and the time spent in generating the evidence of controls.

Instead, this is what we need.

We need the actual state to track the desired state continuously. We need continuous preventative controls to stop insecure resources from being introduced. We need detective controls to find non-compliant resources promptly and constantly. We need responsive controls to fix non-compliant resources automatically. In all, we need continuous compliance.

Infrastructure continuous compliance reference architecture

How do we get started with continuous compliance? Here is the reference architecture that enables you to develop this capability.

The architecture is centered on building a close-loop of directive, preventative, detective and responsive controls. It is also open and extensible. Although we reference Google Cloud architectures in this blog, you can use them for other cloud service platforms or even on-premise

The National Institute of Standards and Technology’s Open Security Controls Assessment Language (OSCAL) is a helpful resource to express your control library in a machine-readable format. OSCAL can allow organizations to define a set of security and privacy requirements, which are represented as controls, which then can be grouped together as a control catalog. Organizations can use these catalogs to establish security and privacy control baselines through a process that may aggregate and tailor controls from multiple source catalogs. Using the OSCAL profile model to express a baseline makes the mappings between the control catalog and the profile explicit and machine-readable.

Directive controls

The starting point of the close-loop is the directive and harmonized controls. Next, you should have control mappings rationalized to the technical controls against your compliance requirements. These requirements can come from various sources, such as the threat landscape of your industry, your internal security policies and standards, your external regulatory compliance, and industry best practice frameworks.

Control mappings will form a Technical Control Library. The library is a dataset mapping out harmonized controls to requirements written in different compliance frameworks. The control mapping justifies the security controls. It builds the linkage between security and compliance and helps you reduce your compliance audit cost. This dataset should be a living document.

An easy first step in building such as library is to begin with the CIS Google Cloud Platform Foundation Benchmark. The benchmark is lightweight and it constitutes foundational security any entity should get right on Google Cloud. In addition, Security Command Center Premium’s Security Health Analytics can help you to monitor your Google Cloud environment against these benchmarks on a continuous basis across all the projects within your organization.

The Technical Control Library will guide the rest of the closed-loop. For every directive control, you should have corresponding preventative control to stop non-compliant resources from being deployed. You should have the detective control to look over the entire environment seeking non-compliant resources. And you should have the responsive control remedying non-compliant resources automatically or kicking off responsive workflow with your Security Operations function. Finally, every policy evaluation point should have a feedback loop to the engineers. A prompt and meaningful feedback loop provides a better engineering experience and increases development velocity in the short run. These feedback loops will breed good behaviors to write better and more secure code in the long run.

Preventive controls

Almost every action on the Google Cloud is an API call, such as when creating, configuring, or deleting resources, so preventative controls are all about API call constraints. There are different wrappers for these API calls, including Infrastructure-as-Code (IaC) solutions such as Terraform or Google Cloud Deployment Manager, the Cloud Console interface, Cloud Shell SDK, Python, or GO SDK.

As with any other application code deployment, the IaC solutions should use a Continuous Integration (CI) solution. On the CI, you could orchestrate IaC constraints, similar to writing unit tests for application code. Since all IaC solutions come in or can be converted to JSON format, you can use Open Policy Agent (OPA) as the IaC constraint solution. OPA’s Rego policy language is declarative and flexible, which allows you to construct almost any policy in Rego.

For the input sources that are not IaC, you could fall back to the organization policies and IAM as these two controls have the closest proximity to Google Cloud. That said, it’s considered a best practice to restrict non-IaC inputs for higher environments such as production-like or production, so you could codify your infrastructure, apply controls and workflows in the source repository.

Detective and responsive controls

Even if you’ve nailed the preventive controls, and the cloud environment is sterile, we still need detective and responsive controls. Here’s why.

For one, not all the controls can be safely implemented as preventative controls in the real world. For instance, we may not fail all the Google Compute Engine deployments at the CI if these VMs have external IP addresses because external IP addresses may be required for a specific software or use cases. Another reason is that we want to produce time-stamped compliance status for audit purposes. Taking the CIS compliance as an example, we could have enforced all the CIS check on the CI and set IaC as the only deployment source for cloud infrastructure.

However, we will still need to demonstrate the runtime CIS compliance report using Security Command Center. Security responsive controls are not limited to remediation actions. They can also take the form of notifications via email, messaging tools, or integration with ITSM systems. If you use Terraform to deploy the infrastructure and use Cloud Function for auto-remediation, you need to pay attention to the Terraform state. Since auto-remediation actions performed by Cloud Function are not recorded in the Terraform state file, you will need to inform the engineers to update the source Terraform code.

The future

The fact that manual processes around security and compliance don’t scale points to automation as the next enabler. The economics of automation require a systemic discipline and holistic enterprise-wide approach to regulatory compliance and cloud risk management.

By defining a data model of the compliance process, the aforementioned OSCAL represents a game-changer for automation in risk management and regulatory compliance. While we realize that adopting “as code” practices is a long-term investment for most of our customers, Risk and Compliance as Code (RCaC) has a number of building blocks to get you started. By adopting the RCaC tenets you shift towards codified policies and infrastructure for a secure cloud transformation. Stay tuned as we introduce exciting new capabilities and features to Google Cloud Risk and Compliance as Code in the months to come.

In the US alone, 24.5 million school records have been leaked across 1,327 data breaches since 2005. And when +1.3 billion students moved to remote learning, the pandemic became an accelerant for cyber attacks with the number of attacks in education spiking 30% YoY during July and August 2020. In our experience working with education customers, we’ve seen three areas impacted by cyber attacks:

• Financial: Institutions experience financial loss from operational disruption and demands from cyber criminals who stole data. For example, The University of California, San Francisco confirmed it paid a ransom of $1.14 million to the criminals behind a cyber attack on its School of Medicine. To protect sensitive student data, the federal government released a statement encouraging all postsecondary institutions to implement NIST 800-171 controls, a policy designed to protect sensitive student data. 
• Operational:Cyber attacks can prevent students, faculty and staff from accessing systems that are necessary to continue teaching, learning, and research initiatives, bringing operations to a halt. Hartford Public Schools in Connecticut postponed its first day of classes following a ransomware attack that shut down the district’s system.
• Reputational: Institutions who have financial or student data breaches can suffer from lower enrollment rates and a loss of grant funding. A study conducted by the Ponemon Institute pointed out that higher education institutions are judged largely on their reputation. A single data breach can significantly impact the reputation of the institution, in addition to substantial financial implications.

How is Google Cloud helping educational institutions put security in place before a data breach happens?

Google Cloud’s security model model, global infrastructure, and unique capability to innovate is helping academic institutions keep their organizations secure and in compliance. For example, Brown University leverages Google Workspace for Education to protect information sharing among faculty, students, and staff, while reducing IT maintenance costs.

Google Workspace helps establish each user’s identity in Google Cloud and this feature has become a core component of Google’s Zero Trust security model, implemented through BeyondCorp. By shifting access controls from the network perimeter to individual users, BeyondCorp enables secure work from virtually any location without the need for a traditional VPN. 

Most academic institutions look to minimize their risk in a shared responsibility model when running infrastructure-as-a-service or platform-as-a-service workloads. Google Cloud has partnered with industry-leading security consortia like RHEDCloud to understand the specific needs of educational and academic research institutions, and follow applicable regulations and grant requirements. We have co-developed solutions with partners, like Burwood Group, to meet those needs and help our customers automate secure and compliant environments for their researchers, students and staff. Burwood Group has partnered with 27 top-tier research universities (R-1) to deploy security solutions. Here are a few of the products we’ve seen the most interest in:

• Blueprint scripts uses Google Cloud built-in services to automate the provisioning and management of enterprise applications and research environments to be in compliance with HIPAA, FedRAMP, CUI, NIST 800-53, NIST CSF, and GDPR regulations.
• Security Command Center manages assets in your organization, uncovers vulnerabilities and threats, and reviews your organization’s compliance.  The solution generates security alerts and audit events from logs that integrate with existing enterprise systems like Security Information and Event Management (SIEMs), Endpoint Detection & Response (EDR’s) and Security, Orchestration, Automation, & Response  (SOAR) tools.
• Chronicle, Google Cloud’s next generation SIEM platform, is changing the game. It is a cloud-native platform designed to ingest your organization’s logs for a flat rate, abandoning the tiered model most SIEM providers offer. It can sift through petabytes of data in seconds and is useful for organizations that are both cost and security conscious.
• VirusTotal Premium provides access to the world’s largest corpus of threat data to protect your organization proactively. The VT API can easily integrate into your commonly used SIEM, EDR and SOAR tools, alerting you to threats that would otherwise go unnoticed.
• reCAPTCHA, helps defend against common attack patterns such as scraping or credential stuffing in web applications.
• Cloud Armor defends against distributed denial-of-service (DDoS) attacks.

For research workloads, these tools provide controls for data ingestion, the export of research data, and, sharing permissions and auditability, allowing researchers to collaborate with other institutions. These tools also automate the provisioning of environments to provide secure execution of Jupyter notebooks and other applications commonly used in research, like Matlab, SAS and Python/R environments.

A customized approach that aligns with education-specific needs

Google Cloud has partnered with academic institutions and research groups to understand their specific needs, and co-develop solutions that help customers govern, control, and audit security and compliance for all types of workloads in a shared responsibility framework. These solutions integrate with most common enterprise and security systems and permit customization to accommodate specific needs around security or data sharing (e.g grant requirements).

To learn more, watch our latest on-demand webinar, Cloud Security Best Practices for Higher Education, hosted by Google Cloud and our partners, Burwood Group and Carahsoft.