Creating a secure-by-default experience based on robust defenses has always been a core design principle for Gmail. That’s why we’ve established a strong baseline of security in Gmail, with built-in protections to help automatically filter out potentially malicious messages. While these defenses help keep Gmail users safe, email functions as part of a large, complex, interconnected ecosystem that we continually invest in and work to protect. After first announcing Gmail’s Brand Indicators for Message Identification (BIMI) pilot last year, today we’re announcing that over the coming weeks we’re rolling out Gmail’s general support of BIMI, an industry standard that aims to drive adoption of strong sender authentication for the entire email ecosystem. BIMI provides email recipients and email security systems increased confidence in the source of emails, and enables senders to provide their audience with a more immersive experience.

“Bank of America has a wide range of security measures in place to support our customers, and we constantly evolve our program to deliver best in class protection. Part of this effort is our partnership with Google on BIMI, which provides an easy way to validate if correspondence is from us.” — Bank of America

BIMI enables organizations that authenticate their emails using Domain-based Message Authentication, Reporting, and Conformance (DMARC)—a standard for providing strong sender authentication that allows security systems to perform better filtering, separating legitimate messages from potentially spoofed ones—to validate ownership of their logos and securely transmit them to Google. BIMI is designed to be easy: for organizations with DMARC in place, validated logos display on authenticated emails from their domains and subdomains.

Here’s how it works: Organizations who authenticate their emails using Sender Policy Framework (SPF) or Domain Keys Identified Mail (DKIM) and deploy DMARC can provide their validated trademarked logos to Google via a Verified Mark Certificate (VMC). BIMI leverages Mark Verifying Authorities, like Certification Authorities, to verify logo ownership and provide proof of verification in a VMC. Once these authenticated emails pass our other anti-abuse checks, Gmail will start displaying the logo in the existing avatar slot.  

“Gmail’s support of BIMI is a win for email authentication, brand trust, and consumers alike. BIMI gives organizations the opportunity to provide their customers with a more immersive email experience, strengthening email sender authentication across the entire email ecosystem.” — Seth Blank, Chair of the AuthIndicators Working Group

This is just the start for BIMI. The standard expects to expand support across logo types and validators. For logo validation, BIMI is starting by supporting the validation of trademarked logos, since they are a common target of impersonation. Today, Entrust and DigiCert support BIMI as Certification Authorities, and in the future the BIMI working group expects this list of supporting validation authorities to expand further. To learn more about BIMI and see the latest news, visit the working group’s website.

To take advantage of BIMI, ensure that your organization has adopted DMARC, and that you have validated your logo with a VMC. For Gmail users, no action is required. We’re proud to be one of the leading members in both establishing and supporting the BIMI standard and will continue to support efforts that contribute to security for the entire email ecosystem.

What’s the most difficult question a security operations team can face? For some, is it, “Who is trying to attacks us?” Or perhaps, “Which cyberattacks can we detect?” How do teams know when they have enough information to make the “right” decision? Metrics can help inform our responses to those questions and more, but how can we tell which metrics are the best ones to rely on during mission-critical or business-critical crises?

As we discussed in our blogs, “Achieving Autonomic Security Operations: Reducing toil” and “Achieving Autonomic Security Operations: Automation as a Force Multiplier,” your Security Operations Center (SOC) can learn a lot from what IT operations discovered during the Site Reliability Engineering (SRE) revolution. In this post, we discuss how those lessons apply to your SOC, and center them on another SRE principle—Service Level Objectives (SLOs).

Even though industry definitions can vary for these terms, SLI, SLO, and SLA have specific meanings, wrote the authors of the Service Level Objectives chapter in our e-book, “Site Reliability Engineering: How Google runs production systems.” (All subsequent quotes come from the SLO chapter of the book, which we’ll refer to as the “SRE book.”)

• SLI: “An SLI is a service level indicator—a carefully defined quantitative measure of some aspect of the level of service that is provided.”
• SLO: “An SLO is a service level objective: a target value or range of values for a service level that is measured by an SLI.”
• SLA: An SLA is a Service Level Agreement about the above: “an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain.”

In practice, we measure something (SLI) and we set the target value (SLO); we may also have an agreement about it (SLA).

This is not about cliches like “what gets measured gets done” here, but metrics and SLIs/SLOs will to a large extent determine the fate of your SOC. For example, SOCs (including at some Managed Security Service Providers) that obsessively focus on “time to address the alert” end up reducing their security effectiveness while making things go “whoosh” fast. If you equate mean time to detect or discover (MTTD) with “time to address the alert” and then push the analyst to shorten this time, attackers gain an advantage while defenders miss things and lose.

How to choose which metrics to track

One view of metrics would be that “whatever sounds bad” (such as attacks per second or incidents per employee) needs to be minimized, while “whatever sounds good” (such as successes, reliability, or uptime) needs to be maximized.

But the SRE experience is that sometimes good metrics have an optimum level, and yes, even reliability (and maybe even security). The book’s authors, Chris Jones, John Wilkes, and Niall Murphy with Cody Smith, cite an example of a service that defied common wisdom and was too reliable.

“Its high reliability provided a false sense of security because the services could not function appropriately when the service was unavailable, however rarely that occurred… SRE makes sure that global service meets, but does not significantly exceed, its service level objective,” they wrote.

The SOC lesson here is that some security metrics have optimum value. The above-mentioned time to detect has an optimum for your organization. Another example is the number of phishing incidents, which may in fact have an optimum value. If nobody phishes you, it’s probably because they already have credentialed access to many of your systems – so in your SOC, think of SLI optimums, and don’t automatically assume zero or infinite targets for metrics.

Three specific quotes from the SRE book remind us that “good metrics” may need to be balanced with other metrics, rather than blindly pushed up:

• “User-facing serving systems generally care about availability, latency, and throughput.”
• “Storage systems often emphasize latency, availability, and durability.”
• “Big data systems, such as data processing pipelines, tend to care about throughput and end-to-end latency.”

In a SOC, this may mean that you can detect threats quickly, review all context related to an incident, and perform deep threat research—but the results may differ for various threats. A fourth guidepost explains why your SOC should care even about this: “Whether or not a particular service has an SLA, it’s valuable to define SLIs and SLOs and use them to manage the service.” Indeed, we agree that SLIs and SLOs matter more for your SOC than any SLAs or other agreements.

Metrics matter, but so does flexibility

When considering the list of most difficult questions a security operations team can face, it’s vital to understand how to evaluate metrics to reach accurate answers. Consider another insight from the book: “Most metrics are better thought of as distributions rather than averages.”

If the average alert response is 20 minutes, does that mean that “all alerts are addressed in 18 to 22 minutes,” or that “all alerts are addressed in five minutes, while one alert is addressed in six hours?” Those different answers point to very different operational environments.

What we’ve seen before in SOCs is that a single outlier event is probably the one that matters most. As the authors put it, “The higher the variance in response times, the more the typical user experience is affected by long-tail behavior.” So, in security land, that one alert that took six hours to respond to was likely related to the most dangerous activity detected.

To address this, the book advises, “Using percentiles for indicators allows you to consider the shape of the distribution.” Google detection teams track the 5% and 95% values, not just averages.

Another useful concept from SRE is the “error budget,” a rate at which the SLOs can be missed, and tracked on a daily or weekly basis. It’s a SLO for meeting other SLOs.

The SOC value here may not be immediately obvious, but it’s vital to understanding the unique role security occupies in technology. In security, metrics can be a distraction because the real game is about preventing the threat actor from achieving their objectives. Based on our own experiences, most blue teams would rather miss the SLO and catch the threat in their environment. The defenders win when the attacker loses, not when the defenders “comply with a SLA.” The concept of the error budget might be your best friend here.

The SRE book takes that line of thinking even further. “It’s both unrealistic and undesirable to insist that SLOs will be met 100% of the time: doing so can reduce the rate of innovation and deployment.”

More broadly, and as we said in our recent paper with Deloitte on SOCs, rigid obeisance is its own vulnerability to exploit. “This adherence to process and lack of ability for the SOC to think critically and creativity provides potential attackers with another opportunity to successfully exploit a vulnerability within the environment, no matter how well planned the supporting processes are.”

To be successful at defending their organizations, SOCs must be less like the unbending oak and more like the pliant but resilient willow.

Track metrics but stay focused on threats

A third interesting puzzle from our SRE brethren: “Don’t pick a target based on current performance.”

We all want to get better at what we do, so choosing a target goal for improvement based on our existing performance can’t be bad, right? It turns out, however, that choosing a goal that sets up unrealistic or otherwise unhelpful, or woefully insufficient, expectations can do more harm than good.

Here is an example: An analyst handles 30 alerts a day (per their SLI), and their manager wants to improve by 15% so they set the SLO to 35 alerts a day. But how many alerts are there? Leaving aside the question of whether it is the right SLI for your SOC, what if you have 5,000 alerts, and you drop 4,970 of them on the floor. When you “improve,” you still drop 4,965 on the floor. Is this a good SLO? No, you need to hire, automate, filter, tune, or change other things in your SOC, not set better SLO targets that seemingly improve upon today’s numbers.

To this, our SRE peers say: “As a result, we’ve sometimes found that working from desired objectives backward to specific indicators works better than choosing indicators and then coming up with targets… Start by thinking about (or finding out!) what your users care about, not what you can measure.”

In the SOC, this probably means start with threat models and use cases, not the current alert pipeline performance.

SOC guidance can sometimes be more cryptic than we’ve let on. One challenging question is determining how many metrics we really need in a typical SOC. SREs wax philosophical here: “Choose just enough SLOs to provide good coverage of your system’s attributes.”

In our experience, we haven’t seen teams succeed with more than 10 metrics, and we haven’t seen people describe and optimize SOC performance with fewer than 3. However, SREs offer a helpful, succinct test: “If you can’t ever win a conversation about priorities by quoting a particular SLO, it’s probably not worth having that SLO.”

SLOs will get to define your SOC, so define them the way you want your SOC to be, the book advises. “It’s better to start with a loose target that you tighten than to choose an overly strict target that has to be relaxed when you discover it’s unattainable. SLOs can—and should—be a major driver in prioritizing work for SREs and product developers, because they reflect what users care about.”

Importantly, make SLOs for your SOC transparent within the company. As the SREs say, “Publishing SLOs sets expectations for system behavior.” The benefit is that nobody can blame you for non-performance if you perform to those agreed upon SLOs.

Finally, here are some examples of metrics from our teams at Google. In addition to reviewing all escalated alerts, they collect and review weekly:

• event volume
• event source counts
• pipeline latency
• triage time median
• triage time at 95%

Analyzing these metrics can reveal useful guidance for applying SRE principles and ideas with their detection and response teams.

Event volume: What we need to know here is what is driving the volume. Is the event volume normal, high, or low—and why? Was there a flood of messages? New data source causing high volume? What caused it? Any bad signals? Or is there a problematic area of the business that needs strategic follow-up to implement additional controls?

Event source count: Are there signals or automation that’s behaving abnormally? Is there new automation that’s misbehaving? Counting events for each source call makes for a decent SLI.

Pipeline latency: Here at Google, we aim for a confirmed detection within an hour of an event being generated. The aspirational time is 5 minutes. This means that the event pipeline latency is something that must be tracked very diligently. This also means that we must scrutinize automation latency. To achieve this, we try to remove self-caused latency so that we’re not hiding the pain of bad signals or bad automation.

We triage median and 95p time: We track the response time to events. As the SRE book points out, tracking only a single average number can get you in trouble very quickly. Note that triage time is not the same as time to resolution, but more of a dwell time for an attacker before they are discovered.

Incident resolution times: When you have a SLI but not a SLO, this can be the proverbial elephant in the room and create all sorts of bad incentives to “go fast” instead of “go good.” Specifically, SLO without SLI causes harm from encouraging the analysis to resolve quickly and potentially increase the risk of missing serious security incidents, especially when subtle signals are involved.

When reviewing alert escalations, we look to determine if the analysis is deep enough, if handoffs contain the right information for our response teams, and to get a sense of analyst fatigue. If analysts are phoning in their notes, it’s a sign that they’re over a particular signal or that there are a ton of duplicate incidents and we need to drive the business in some way.

By measuring these and other factors, metrics allow us to drive down the cost of each detection. Ultimately, this can help our detection and response operation scale faster than the threats.

Related posts:

• “Achieving Autonomic Security Operations: Automation as a Force Multiplier”
• “Achieving Autonomic Security Operations: Reducing toil”
• “Taking an autonomic approach to security operations” video
• “New Paper: “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 of 4)”
• “New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center””
• “EP75 How We Scale Detection and Response at Google: Automation, Metrics, Toil” podcast episode

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

When you think about climate change, you might not consider a daily commute to work or a drive around town as big contributing factors. And yet, transport is the fastest growing source of CO2 emissions from fossil fuel, which in turn is the largest contributor to climate change. This is the key insight behind the mission of Spanish carbon-neutral multinational Acciona. The group, which provides sustainable solutions for infrastructure and renewable energy projects across 65 countries, launched an electric scooter sharing service called Acciona Mobility in 2018.

Aiming to contribute to the decarbonization of the transport sector while helping relieve traffic congestion within cities, Acciona Mobility enables users to rent electric scooters powered 100% by energy from renewable sources. Users can find, reserve, and rent the scooters at the tap of their mobile screens via the Acciona Mobility application and pay on the basis of minutes spent riding. The app, which is available free to download online, is also the gateway through which new users can register for the service, which welcomes anyone with a valid driver’s license for motorbikes. After having their right to drive, identity, and card details validated, citizens can start enjoying the service, available 24 hours a day, every day of the year.

“We needed to deploy a reliable infrastructure for a new service before understanding exactly what its scale and demand would be. Our strategy was to adopt a serverless architecture that can grow with us to sustain our long-term vision. This kind of thinking led us directly to Google Cloud.”

—Jose Luis Rosell, CIO Services Division, Acciona

“Acciona Mobility is exciting because it stems from our vision to make people’s lives easier in a sustainable way,” says Jose Luis Rosell, CIO of Acciona’s Services Division. “40% of the pollution near cities comes from private transportation. We want to help solve that problem with zero-carbon, electric, multimodal transportation that’s also convenient for people to use.”

However, Jose Luis says that building the appropriate IT infrastructure to bring the new service to life required external support. “We needed to deploy a reliable infrastructure for a new service before understanding exactly what its scale and demand would be. Our strategy was to adopt a serverless architecture that can grow with us to sustain our long-term vision,” he explains. “This kind of thinking led us directly to Google Cloud.”

Developing the transportation platform of the future

Because Acciona was already a Google Cloud customer, Jose Luis and his team reached the decision to develop the new service on Google Cloud with ease, as he explains: “We had a very positive experience working closely with the Google Cloud team during Acciona’s first project on Google Cloud, and that collaborative mentality is very important for us. We feel Google Cloud is a trustworthy partner that is willing to take risks with us and is flexible enough to lead us through business uncertainty with the right technology,” he says. “So we were confident that its technology and people could help us bring the Acciona Mobility service from theory to reality.”

This time, Acciona partnered with cloud consultancy Altostratus as well, to consult on a selection of Google Cloud products that would help develop the application quickly by making use of managed services. Acciona’s strategy was to launch the new services first in Madrid, where the company is headquartered, and then spread the vision across more cities later, if the idea worked out well in practice. Due to the scale of the project and its data needs, BigQuery was chosen as the primary data warehouse to store all the information related to the service, such as the location of scooters and their availability status. With all its data readily available on BigQuery, Acciona is able to run specific queries that help it to gain insights such as which urban areas have the highest volume of scooters being rented. Knowing this, Acciona can reorganize availability to make sure there are always enough scooters in that specific location.

Integrating it with Pub/Sub and Dataflow, Acciona ensures that the data generated by scooters is ingested and processed in real time so that users searching for scooters nearby, using the Acciona Mobility application on their phones, can always have up-to-date information at hand. Using Google Maps Platform APIs such as the Directions API, Acciona’s mobile app translates the geographical coordinates of scooters into an easy-to-read address displayed beside a visual map. Using Cloud SQL, Acciona automates the storage capacity management of the database as the number of scooters and active users grow.

Meanwhile, Google Cloud Armor protects the service against cyber breaches and distributed denial of service attacks to keep it running uninterrupted. In addition, Google Cloud itself helps to reinforce the cyber security measures with secure-by-default managed services, such as data encryption. “The managed services mean more resilience and more uptime, because we don’t need to worry about maintenance or external threats,“ says Jose Luis of the solutions protecting all information generated by the new service, which as CIO is a topic he holds dearly. “I face cybersecurity issues more confidently as a Google Cloud partner,” he adds.

“Today, we have data coming in every 15 seconds from 10,000 electric scooters around Europe. BigQuery and Cloud SQL-managed services help us handle that data very carefully and with precision so that our users don’t experience any lags when searching for scooters or returning them.”

—Jose Luis Rosell, CIO Services Division, Acciona

Expanding an 100% sustainable transport solution throughout Spain

Within two months of the decision to deploy Acciona Mobility on Google Cloud, the service was ready for launch, filling the streets of Madrid with 500 electric scooters that run 100% on renewable energy. By 2020, the number of scooters has grown to 10,000 and the service has scaled to multiple cities in and outside of Spain, including Lisbon, Milan, and Rome. To date, more than 3.5 million intracity rides have used the Acciona Mobility app, reducing CO2 emissions by more than 1,000 tons.

“Today, we have data coming in every 15 seconds from 10,000 electric scooters around Europe. BigQuery and Cloud SQL-managed services help us handle that data very carefully and with precision so that our users don’t experience any lags when searching for scooters or returning them,” says Jose Luis of the fast-growing scale of the project.

“Google Cloud enables us to keep our services always available and to scale quickly to respond to its growing demand. Our ratings have been very positive as a result. More importantly, our vision of transportation as a cleaner, more sustainable commodity is really spreading and resonating with the public.”

—Jose Luis Rosell, CIO Services Division, Acciona

Set to continue expanding, Acciona is using Google Kubernetes Engine to make sure the Acciona Mobility application has the computing capacity it needs to continue scaling to reach new markets and serve more users. On that note, Google operations tools (formerly Stackdriver) are also being deployed to help monitor, troubleshoot, and improve the performance of the application as it scales.

“Google Cloud enables us to keep our services always available and to scale quickly to respond to its growing demand. Our ratings have been very positive as a result. More importantly, our vision of transportation as a cleaner, more sustainable commodity is really spreading and resonating with the public,” he concludes.

All over the world, businesses, schools and users depend on G Suite to help them stay connected and get work done. Google designs, builds, and operates our products on a secure foundation, aimed at thwarting attacks and providing the protections needed to keep you safe. G Suite and Google Meet are no exception.

Google Meet’s security controls are turned on by default, so that in most cases, organizations and users won’t have to do a thing to ensure the right protections are in place. Here, we’ll summarize the key capabilities of Google Meet that help protect you.

Proactive protections to combat abuse and block hijacking attempts

Google Meet employs an array of counter-abuse protections to keep your meetings safe. These include anti-hijacking measures for both web meetings and dial-ins. 

Google Meet makes it difficult to programatically brute force meeting IDs (this is when a malicious individual attempts to guess the ID of a meeting and make an unauthorized attempt to join it) by using codes that are 10 characters long, with 25 characters in the set. We limit the ability of external participants to join a meeting more than 15 minutes in advance, reducing the window in which a brute force attack can even be attempted. External participants cannot join meetings unless they’re on the calendar invite or have been invited by in-domain participants. Otherwise, they must request to join the meeting, and their request must be accepted by a member of the host organization. 

In addition, we’re rolling out several features to help schools keep meetings safe and improve the remote learning experiences for teachers and students, including:

• Only meeting creators and calendar owners can mute or remove other participants. This ensures that instructors can’t be removed or muted by student participants.
• Only meeting creators and calendar owners can approve requests to join made by external participants. This means that students can’t allow external participants to join via video, and that external participants can’t join before the instructor.
• Meeting participants can’t rejoin nicknamed meetings once the final participant has left. This means if the instructor is the last person to leave a nicknamed meeting, students can’t join later without the instructor present.

Secure deployment and access controls for admins and end-users

To limit the attack surface and eliminate the need to push out frequent security patches, Google Meet works entirely in your browser. This means we do not require or ask for any plugins or software to be installed if you use Chrome, Firefox, Safari, or Microsoft Edge. On mobile, we recommend that you install the Google Meet app. 

To help ensure that only authorized users administer and access Meet services, we support multiple 2-Step Verification options for accounts that are secure and convenient. These include hardware and phone-based security keys and Google prompt. Additionally, Google Meet users can enroll their account in our Advanced Protection Program (APP), which provides our strongest protections available against phishing and account hijacking and is specifically designed for the highest-risk accounts. 

For G Suite Enterprise and G Suite for Education customers, we offer Access Transparency, which logs any Google access to Google Meet recordings stored in Drive, along with the reason for the access (support team actions that you might have requested, for example). Customers can also use data regions functionality to store select/covered data of Google Meet recordings in specific regions (i.e. US or Europe). 

Secure, compliant, and reliable meeting infrastructure 

In Google Meet, all data is encrypted in transit by default between the client and Google for video meetings on a web browser, on the Android and iOS apps, and in meeting rooms with Google meeting room hardware. Meet adheres to IETF security standards for Datagram Transport Layer Security (DTLS) and Secure Real-time Transport Protocol (SRTP). For every person and for every meeting, Meet generates a unique encryption key, which only lives as long as the meeting, is never stored to disk, and is transmitted in an encrypted and secured RPC (remote procedure call) during the meeting setup.

Security is an integral part of all our operations at Google. Our team of full-time security and privacy professionals supports our software engineering and operations to ensure that security is always a part of how we build and run our services. All of our Google Cloud and G Suite customers benefit from these capabilities, including: 

• Secure-by-design infrastructure: Google Meet benefits from Google Cloud’s  defense-in-depth approach to security, which utilizes the built-in protections and global-private network that Google uses to secure your information and safeguard your privacy.
• Compliance certifications: Our Google Cloud products, including Google Meet, regularly undergo independent verification of their security, privacy, and compliance controls, including validation against standards such as SOC, ISO/IEC 27001/17/18, HITRUST, and FedRAMP. We support your compliance requirements around regulations such as GDPR and HIPAA, as well as COPPA and FERPA for education. 
• Incident management: We have a rigorous process for managing data and security incidents that specifies actions, escalations, mitigation, resolution, and notification of any potential incidents impacting customer data.
• Reliability: Google’s network is engineered to accommodate peak demand and handle future growth. Our network is resilient and engineered to accommodate the increased activity we’ve seen on Google Meet.
• Transparency: At Google Cloud, we’re clear about our commitments regarding customer data: we process customer data according to your instructions; we never use customer data for advertising purposes; and we publish the locations of our Google data centers, which are highly available, resilient, and secure.  

During COVID-19 and beyond, we will continue to protect Google Meet users and their data, and keep innovating with new features to make our tools helpful, secure, and safe.