We’re excited to announce the public preview of Certificate Manager and its integration with External HTTPS Load Balancing. Certificate Manager enables you to use External HTTPS Load Balancing with as many certificates or domains as you need. You can bring your own TLS certificates and keys if you have an existing certificate lifecycle management solution you’d like to use with Google Cloud, or enjoy the convenience of our fully Managed TLS offerings.  

Extend the security and performance of the Google network to your customers

Certificate Manager brings support for multiple certificates per customer. When  coupled with our global anycast load balancing solution with automated autoscaling and failover, you now have a powerful platform for building robust SaaS and PaaS offerings. This enables custom domain support for your customers with the lowest latency and the highest level of availability. 

Alon Kochba, the head of web performance at website-building service Wix, explained how the new features lighten their workload. 

“As a SaaS product, we need to terminate SSL for millions of custom domains and certificates. GCP’s Certificate Manager and External HTTPS Load Balancing lets us do this at the edge, close to the clients, without having to rely on our own custom solution for terminating SSL,” Kochba said.

Customers who switch to External HTTPS Load Balancing can also now protect their SaaS users from denial of service attacks, OWASP Top 10 risks, and other common Web attacks by adopting Cloud Armor.

DNS authorization

This release also now enables you to provision your Google-managed certificates with DNS-based authorizations and have them ready to use before your load-balancing production environment is fully set up. This will help streamline the migration process to Google Cloud, for example. To create a DNS authorization, use the following command:

  gcloud beta certificate-manager dns-authorizations create example-authorization --domain="example.com"

This command returns the CNAME record for _acme-challenge.example.com that you must add to your DNS configuration in the DNS zone of the target domain. This CNAME record points to a special Google Cloud domain, e.g.: “534959-1a8a-40cf-90b6-b1f5f8d22517.2.authorize.certificatemanager.goog” that is used  to verify domain ownership.

When you request a certificate based on the above authorization, Cloud Certificate Manager will work with the Certificate Authority automatically to get and later renew your certificate for that domain.

Wildcard support

This DNS-based domain control authorization also allows us to bring you support for wildcard certificates. To configure the use of wildcard certificates you first must configure the DNS authorization as we’ve indicated above. Once that has been completed, you can configure the use of a wildcard certificate using the following command. Our example below is for a top-level registered domain and its wildcard subdomains.

  gcloud beta certificate-manager certificates create example-wildcard-certificate --domains="example.com,*.example.com" --dns-authorizations="example-authorization"

Monitoring for Certificate Expiration

Another new feature that will be enabled with this product  is the ability to monitor certificate expiration with Google Cloud Logging.  Cloud Logging creates a record of certificate expiration, uses the `certificatemanager.googleapis.com/Project` monitored resource, and is represented by the following message:

  message CertificatesExpiry {
  // Expiration state of the certificate.
  enum State {
    // Unspecified state, should never be reported.
    STATE_UNSPECIFIED = 0;

    // Certificate will expire soon.
    CLOSE_TO_EXPIRY = 1;
    // Certificate is expired.
    EXPIRED = 2;
  }

  // Number of reported certificates.
  int64 count;

  // Names of reported certificates. If there are too many, the list is sampled.
  repeated string certificates = 2;

  // State of reported certificates.
  State state = 3;

  // Approximate expiration time of reported certificates.
  // Multiple certificates with close expiration time are batched 
  // together in a single log, so the timestamp is not precise.
  google.protobuf.Timestamp expire_time = 4;
}

The log message is delivered every hour and contains a sample of the certificates being close to expiry or already expired.

Pricing

The best part is that there’s no additional charge to use the Certificate Manager for the first 100 certificates. To use more than 100 certificates with the management tools, we will charge on a per-certificate, per-month pricing structure. This empowers you to scale up to as many certificates as you need, and as cost-effectively as possible. The pricing will be enabled when the solution goes to General Availability.

It is our hope that these new features, combined with the programmability offered by Certificate Manager, will enable you to simplify the way you deploy HTTPS and offer a more scalable and secure service to your customers.

Today, we published a new Google research report on software supply chain security because we’ve seen a sharp rise in software supply chain attacks across almost every sector —and expect these trends to continue for the foreseeable future. We urge all organizations to act now to improve their software supply chain security.

Among the report’s conclusions, there are two key findings we want to highlight. First, the lessons we’ve learned from various security events call for a more holistic approach to strengthen defenses against software supply chain attacks. Second, we have worked with the security community to develop and deploy a common Supply-chain Levels for Software Artifacts (SLSA) framework that can mitigate threats across the entire software supply chain ecosystem. These frameworks can help organizations securely build and verify the integrity of software. You can find more information on the report’s conclusions here.

We know that modern day software supply chains continue to grow deeper, wider, and more complex. That complexity can make it challenging for customers to even know where to begin analyzing their supply chains for security issues. Our research shows that organizations must deal with these same complex issues regardless of which environments they operate in.

At Google Cloud, we’re deeply committed to working with our customers to help ensure that they have the support they need to evaluate their security posture, resiliency, and hygiene. Below, we suggest five steps to protect software across processes and systems, and tap into relevant Google Cloud products and services. These recommendations can enable customers to benefit from Google’s extensive security experience and reduce their need to develop, maintain, and operate complex processes to secure their open source dependencies.

Implementing best practices with Google Cloud

Customers who are interested in improving their software supply chain security can take immediate steps to implement best practices.

1. Enhance your existing Google Cloud security features with the Google Cloud security foundation guide. The guide can help you weigh important considerations including organizational structure, authentication and authorization, resource hierarchy, networking, logging, and detective controls. You can further engage Mandiant experts to assess your readiness.

You can also view centralized information about vulnerabilities and possible risks using Google Cloud services like Security Command Center, and get information about your service usage with Recommender, including recommendations that can help you to reduce risk. For example, you can identify IAM principals with excess permissions or unattended Google Cloud projects. You can also find additional resources from the Google Cybersecurity Action Team (GCAT), our premier security advisory team, here.

2. Explore fast software delivery and reliable and secure software with Google Cloud’s DevOps capabilities. You also should review foundational practices for designing, developing, and testing code that apply to most programming languages.

We strongly recommend you evaluate how you distribute software and the terms of software licenses in all of your dependencies. For more information on Google’s approach to helping organizations address vulnerabilities in open source software, see Appendix B in the research report.

3. Document the policies for your organization and incorporate validation of policies into your development, build, and deployment processes as you implement best practices. For example, your organization’s policies might include criteria for deployment that you implement with Binary Authorization. GCAT has published additional information on security policies and other cloud security transformation tips for CISOs here.

You can also explore Minimum Viable Secure Product, a security checklist of controls to establish a baseline security posture for a product. You can use the checklist to establish your minimum security control requirements and to evaluate software by third-party vendors.

Tapping into new Google product and service offerings

At Google Cloud, we continue to focus on delivering new and innovative security capabilities to help customers address the latest security threats. From the attack on SolarWinds to the community response to open source vulnerabilities such as Log4j, we’re seeing a spike in demand from customers on what we can do to help them manage software supply chain risk. We’ve made several recent announcements on that front that can help customers get started with Google Cloud today.

4. Use Google Cloud’s Software Delivery Shield. It provides a fully managed software supply chain security solution that offers a modular set of capabilities to help equip developers, DevOps, and security teams with the tools they need to build secure cloud applications. Software Delivery Shield spans across a family of Google Cloud services from developer tooling to runtimes including GKE, Cloud Code, Cloud Build, Cloud Deploy, Artifact Registry, and Binary Authorization. To learn more about Software Delivery Shield, check out the solution page, or watch this Google Cloud Next session to get a quick overview of Software Delivery Shield.
5. Enable our Assured Open Source Software (OSS) service, which can help enterprise and public sector open source software users to easily incorporate the same OSS packages that we use at Google into their own developer workflows. Packages curated by the Assured OSS service:

• are regularly scanned, analyzed, and fuzz-tested for vulnerabilities;
• have corresponding enriched metadata incorporating Container/Artifact Analysis data;
• are built with Cloud Build including evidence of verifiable Supply chain Levels for Software Artifacts (SLSA)-compliance;
• are verifiably signed by Google;
• and are distributed from an Artifact Registry that is secured and protected by Google.

If you are interested in learning more about software supply chain security in general, please contact us or reach out to your sales representative to schedule a software supply chain security workshop.

For more than a decade, Google has applied a Zero Trust approach to most aspects of our operations. Zero Trust’s core tenet–that implicit trust in any single component of a complex, interconnected system can create serious security risks–is fundamental to how we operate and build our security architecture.

Early in our security journey, we realized that despite our best efforts user credentials would periodically fall into the hands of malicious actors. This is why we developed the BeyondCorp framework. We needed additional layers of defense against unauthorized access that would not impede user productivity. We also understood that software that interacts with the larger world should not have a perimeter-based trust model. These realizations led to the layered protection in our BeyondProd framework, which extends the Zero Trust paradigm to our production workloads.

Earlier this year, the United States Office of Management and Budget (OMB) released a Federal Strategy to Move the U.S. Government Towards a Zero Trust Architecture. This marks an important step for the U.S. government’s efforts to modernize under Executive Order 14028 on Improving the Nation’s Cybersecurity. In parallel, guidance from the United Kingdom’s National Cyber Security Center (NCSC) has also called for the move to a Zero Trust approach to security and outlined in 2021 its report on Zero Trust architecture design principles.

Adopting a Zero Trust approach can help organizations inside and outside the public sector stay ahead of both regulatory requirements and security threats, but it requires thoughtful planning and execution. Our goal is to bring the best practices for Zero Trust together in one place, leveraging the experiences and knowledge of our existing customers, and Google’s own experience with implementing Zero Trust.

How Google Cloud can help government agencies move toward Zero Trust

Agencies can rely on Google Zero Trust capabilities for remote access, secure collaboration, and boundary security. To better serve the Zero Trust needs of our customers, we introduced BeyondCorp Enterprise in January 2021, a solution that provides Zero Trust secure access to resources and applications in the cloud and on-premises. BeyondCorp Enterprise was built based on years of Google’s own innovation as we implemented Zero Trust globally for ourselves. It leverages the Chrome browser and Google’s global network, and it offers integrated real-time threat and data protection.

Here are five ways BeyondCorp Enterprise can be applied to help organizations adopt the Zero Trust cybersecurity principles set forth in the recent White House memorandum (M-22-09) and other global government guidance for Zero Trust.

1. Enable enterprise applications to be used over the public internet: It’s no secret that VPN usage poses daily burdens and long-term challenges for IT and cybersecurity managers, as well as end-users. BeyondCorp Enterprise provides users with seamless and secure access to web applications (including SaaS apps and apps hosted on any cloud), plus central management controls and threat and data protection capabilities, all built-in to the Chrome browser. Through BeyondCorp Enterprise, end-users can access applications simply and still benefit from enterprise-grade security, without sacrificing their productivity or user experience.
2. Leverage phishing-resistant MFA to access secure resources: Many cyberattacks start with phishing messages that lead users to infected websites and attempt to steal credentials. The use of phishing-resistant MFA, as recommended by M-22-09, can protect personnel from sophisticated online attacks. BeyondCorp Enterprise supports strong phishing-resistant authentication, by allowing factors such as Titan Security Keys to be used as attributes in access policies that are enforced at the application layer. Organizations can customize how to incorporate phishing-resistant MFA methods into their access policies for individual applications and resources. Phishing protection is also built into the Chrome browser, powered by Google Safe Browsing, and these capabilities block access to malicious content, detect phishing sites, prevent malware transfers, and generate reports of unsafe activity, adding even more protection against bad actors.

3. Use context-aware authorization: The U.S. federal strategy states that a Zero Trust architecture should incorporate more granularly and dynamically defined permissions and that every request for access should be evaluated to determine whether it is appropriate. With context-aware authorization, organizations can build and customize access policies to include different contextual signals about a user including their role, their location, and even the time of day. Every interaction between a user and a BeyondCorp-protected resource is evaluated in real-time against the resource’s access policy to ensure users are and remain authorized to access it, with continuous authorization for all interactions at a per request level.
4. Incorporate device-level signal into authentication: At Google, we believe that trust must be granted based on what is known about a user’s identity and their device. We are pleased that OMB similarly recommends that authentication incorporate at least one device-level signal alongside identity information. Since BeyondCorp Enterprise supports device-level attributes without requiring users to install agents, this can be done easily by leveraging the Endpoint Verification extension in the Chrome browser, where administrators can gather endpoint security posture information and easily construct and implement granular resource access policies. The ability to collect and utilize this information through an agentless approach is especially helpful for BeyondCorp Enterprise customers who support a workforce with bring-your-own-device policies or unmanaged devices.
5. Include the extended workforce in your Zero Trust strategy: A Zero Trust approach aimed to provide secure access to the right users, at the right time, and for the right purposes should be inclusive of all users, not just full-time staff. Government agencies rely on contractors and partners to carry out many important missions. Unfortunately, the extended workforce is often more vulnerable to attacks if they are given too much privileged access or if their security practices are not properly assessed before access is provisioned. At the same time, federal administrators can’t always manage third-party devices or software directly, which can make secure access challenging.

BeyondCorp Enterprise supports a feature called protected profiles, an ideal solution for granting Zero Trust access to the extended workforce. It enables users to securely access resources from unmanaged devices and be protected by the same security capabilities without needing to install agents. Furthermore, administrators can gain visibility into risky activities and view any security events that are generated from within protected profiles.

Applying the NCSC Zero Trust principles on Google Cloud

Last year, the U.K. government’s NCSC launched its Zero Trust architecture design principles to help organizations securely adopt a Zero Trust architecture. To help private and public sector organizations in the U.K., the Google Cybersecurity Action Team (GCAT) released a detailed research paper that outlines how organizations can leverage Google Cloud technologies and services to align with these principles. This is a technical guide aimed at enterprise and security architects charged with developing and executing a Zero Trust strategy under the principles outlined by the NCSC, including:

• Know your architecture, including users, devices, services and data with Google Cloud Professional Services Organization (PSO) who can support discovery, planning and risk mitigation.
• Know your User, Service and Device identities including reference architectures for Cloud Identity.
• Assess your user behavior, device and service health by leveraging built in reporting from Google Cloud and Chronicle.
• Use policies to authorize requests with BeyondCorp Enterprise policy-based authorization.
• Authenticate & Authorize everywhere by reviewing the BeyondCorp and BeyondProd frameworks which combine to deliver ubiquitous authentication and authorization.
• Focus your monitoring on users, devices and services with device management and Cloud native monitoring capabilities.
• Don’t trust any network, including your own. Review details on Google’s Secure by Design infrastructure.
• Choose services designed for Zero Trust. Review how to protect modern and legacy applications with BeyondCorp.

For more detail on how we’re supporting the U.K.’s NCSC, please review our recent research paper for insight into their priorities, and where Google will be discussing Secure by Design principles and how to respond to security incidents.

Zero Trust assessment and planning services for organizations

Organizations that are managing complex environments while undergoing Zero Trust adoption could benefit strongly from experienced support and guidance. The Google Cybersecurity Action Team (GCAT) is committed to helping customers meet Zero Trust security and compliance requirements in the cloud through specialized consulting engagements and workshops for public sector customers. Read more about how growing cybersecurity requirements for U.S. federal government customers via executive orders and White House mandates are being supported through Google Cloud solutions.

GCAT’s multi-week Zero Trust Foundations engagement helps organizations build a strategy to achieve a Zero Trust security model across their operations. Zero Trust Foundations is co-delivered by Google Cloud’s Office of the CISO and our public sector Professional Services Organization. It can help focus and accelerate customers’ Zero Trust efforts by sharing lessons learned from Google’s own BeyondCorp zero-trust journey, and our global implementation of defense-in-depth best practices. Contact us today to learn more.

To learn more about ways Google Cloud can help organizations embarking on a Zero Trust journey, tune into our second annual Google Cloud Security Summit on May 17 and hear directly from customers who are already using our Zero Trust solutions to achieve their organization’s security goals.

About the Authors:
Jeanette Manfra is the former Assistant Director for the Cybersecurity and Infrastructure Security Agency at the Department of Homeland Security. Dan Prieto is the former Director of the Defense Industrial Base Cybersecurity program at the Department of Defense. Both Dan and Jeanette also served in the White House on the staff of the National Security Council’s cybersecurity directorate.

Twenty years ago, organizations discovered the magic of server virtualization. Among the many benefits of virtualization, it heralded the end of the need for one physical server per application and the beginning of managing software-defined infrastructure. It helped automate building and installing systems, and it helped lay foundations for today’s Continuous Integration/Continuous Delivery mechanisms and DevOps practices. However, the adoption of virtualization was not always smooth and several hurdles stood in its path. Today’s organizations are facing similar obstacles in their journey to the cloud.

Organizations that wanted to virtualize their server environment two decades ago faced a significant challenge that was neither technical nor budgetary, but organizational, stretching across IT teams and beyond. The first team to be concerned about virtualization was the one in charge of installing the physical servers in the racks of the datacenter, managing the physical network connections and operating environmental controls, such as HVAC and power systems. These tasks were drastically reduced, if not outright eliminated.

The second team affected by this shift in technology was the one responsible for installing the operating system and running the post-install procedures. Their job almost completely disappeared as most virtual machines were automatically instantiated from templates.

As a result, successful adoption relied on the ability to smooth these organizational changes. Along the way, training the staff and making sure they acquire the new skills necessary to operate the virtualization infrastructure was critical. And usually, the affected teams eventually found that their new responsibilities were different but still essential to the organization, and perhaps even more appealing.

Virtualizations lessons for cloud transformation regulators

Discussions on virtualization didn’t end with these internal changes when organizations were operating in a regulated environment. They needed to engage closely with their regulators. Regulated organizations often considered the hypervisor solely as an additional layer of software with potential vulnerabilities.

This viewpoint raised risks (such as virtual machine escape) that didn’t exist with physical servers. Even if this is taken into account and the risks mitigated, it should have been considered in balance with all the benefits of machine virtualization, including security benefits such as asset identification, harmonization, and smoother patch management.

While the relevance and benefits of virtualization are now widely accepted, history has repeated itself as similar issues have arisen for organizations facing cloud migrations. When large cloud service providers (CSP) began supporting critical workloads for their customers, regulators increased their oversight over CSPs and issued guidance concerning cloud adoption. This happened in the European financial sector, with guidelines from the European Supervisory Authorities (European Banking Authority, European Securities and Market Authority and European Insurance and Occupational Pensions Authority,) and the coming Digital Operational Resilience Act regulation.

These regulations can help establish trust between providers and customers. As regulator decisions are vital for organizations, there is an opportunity now with cloud technology to balance the risks with the benefits and take into consideration all the ways CSPs can help organizations improve their overall security and compliance levels.

Cultural transformation can drive cloud transformation

Another similarity between cloud transformation and the journey to virtualization is the required internal transformation. When an organization decides to start its journey to the cloud, training its staff with the new technology and tools is a necessary step, but probably not the first nor the most arduous to make. A change of mindset is paramount to fully incorporate all the cloud benefits, in particular regarding security.

This new approach begins with a deep transformation at the organizational level. Organizations should avoid viewing the cloud as a datacenter because there’s so much more potential to cloud technology. This new approach and its accompanying organizational transformation is driven by two factors: The burdens that the CSP removes from the customer, and the new flexibility that software-defined infrastructure brings to the table.

The CSP directly manages several tasks and services, and their security, which means that they’re no longer a direct concern for the customer. These responsibilities include data center management, security-hardened hardware, default encryption for data at rest and data in transit, and resilient network management.

Since all the infrastructure used by the organization to manage its workloads is software defined, it brings much more flexibility to what can be done with it. Software-defined infrastructure can more easily enable security guardrails and continuous compliance that weren’t possible before.

While there’s a temptation to approach an organization’s cloud transformation as merely a “lift and shift” operation from on-premises infrastructure, the reality is that approach reduces the potential gains a cloud transformation can bring to an organization. Moving systems to the cloud accounts for a small portion of the potential impact, while updating the mindset can be truly transformational. Development, architecture and security processes need to be rebuilt; this inevitably requires a deeper transformation of the organization.

The next step is to transform the operations, to align them with the overall organization and the new defined processes, operationalize CI/CD and build DevOps practices. After that, the technological gap will be adjusted, moving the new tools and teaching teams how to best use them.

The important point here is the order of the transformation to manage: organization, operations and technologies (O-O-T) and not the other way round (T-O-O). Of course, these three steps should not be considered completely sequential, as technology plays an important role in the organization and the operations. However, it is essential to support the development of personnel and frameworks to take full advantage of the transformation opportunity, rather than primarily focusing on the tooling.

In addition, at Google Cloud, we believe in a shared fate that goes far beyond the usual shared responsibility model. We think it is part of our duty to help our customers to achieve their goals in their scope of responsibility. We prepare secure landing zones and guide the customers, we bring transparency to security controls and help them with cyber-insurance.

Our shared objective with our customers is to continuously improve security. Our Google Cybersecurity Action Team initiative helps us to be engaged alongside our customers, provide them with necessary guidance, support them in their security and compliance strategies, and assist their organizational and operational transformation in their cloud journey.

• Listen to a related podcast “How to Apply Lessons from Virtualization Transition to Make Cloud Transformation Better”
• Listen to “Preparing for Cloud Migrations from a CISO Perspective, Part 1”
• Read “The journey to the cloud mitigates enterprise risk”
• Also, review “Megatrends drive cloud adoption—and improve security for all”
• Visit Google Cybersecurity Action Team website