Security operations teams are facing a “perfect storm” of challenges from nation-state actors turning their attention to financial crime, to rising uncertainty and potential complexities because of rapidly advancing cloud migration and IoT adoption, to the long-lamented skills shortage. 

Now imagine having to face this trifecta without visibility into your IT and security infrastructure because scale and cost concerns have impeded your ability to ingest and monitor critical telemetry. To help organizations rethink threat detection and broader security team efforts, we showcased at this month’s Google Cloud Security Talks a keynote on why DEI is a cybersecurity imperative, Mandiant’s review of lessons for organizations two years after SolarWinds, how Google Chrome already helps protect your business (and what more you can make do with it,) how best to encourage your organization to pursue Zero Trust, and three key ways in which Chronicle Security Operations can help your organization scale threat detection and actionable outcomes. These include:

1. Operationalizing threat intelligence

Harnessing the power of threat intelligence to acquire context, prioritize risk, and act on detections requires more than just ingesting a set of indicator of compromise (IOC) feeds. Threat intelligence must have breadth and depth of coverage to provide custom details on the tools, tactics, and procedures of threat actors. Explore why part of the “magic” behind Google Cloud’s security is the sheer scale of threat intelligence we can share with our customers. 

2. Driving detection as code

We want to enable organizations that are more advanced in their cybersecurity maturity to build their own custom detections and rules, which means offering our customers a powerful detection-authoring platform. Chronicle Security Operations can help analysts build specific detections around, for example, known bad files or a specific registry key change. We also demonstrated how to create more complex detections, such as flagging process execution patterns or crafting a suspicious-behavior trigger from a specific activity sequence.

3. Leveraging curated detections

With curated detections, which we announced in August, we are putting the power of Google Cloud’s intelligence in the hands of security operations teams everywhere. Our detections offer actionable, ready-to-use threat detection content curated, built, and maintained by Google Cloud Threat Intelligence (GCTI) researchers. These detection sets cover a wide variety of threats for your network and beyond, including attacks such as ransomware, remote-access tools (RAT), infostealers, data exfiltration, and suspicious activity.

You can watch all nine of our Security Talks recorded sessions here, and keep an eye out for our next Security Talks, coming in March 2023.

Setting up your new cloud infrastructure is scary. Extra scary when you realize that someone (is it gonna be you?) gets to have phenomenal cosmic power over the whole thing. 

Yes, I’m talking about the admin account, and today we’ll dig into why they are important, dangerous and different.

When the team at pistach.io got their nuts-as-a-service business growing fruitfully, they knew they needed to think carefully about admin accounts. These people would have tremendous control over their use of Google Cloud, and they could potentially cause very big problems if any were compromised. Definitely resources that require a protective shell.

Early in pistach.io’s development, an employee named Walter Nutt wanted to play a prank by changing his co-worker’s profile photo from an almond to a peanut (pretty devious, since a peanut is actually a legume). He didn’t have access to his friend’s computer, but he did have access to the company’s Cloud Storage bucket. While searching for the profile photo in question, Wally inadvertently deleted the entire contents of the bucket! 

As he searched for ways to restore its contents, Wally modified access to two other pistach.io buckets.  The company was ground to a halt for a week while teams worked to crack through the permissions issues.

Time to rethink permissions a bit, so this couldn’t spoil their buttery smooth operations in the future.

Following the resource manager guide, the team made a super admin email address that wasn’t tied to a particular individual or Workspace account, and secured it with strong multi-factor authentication. This would be their backup in case an admin account were to be compromised, so they could recover and repair.

The team already uses Google Workspace, so they have an organization set up already. That creation process established initial super administrators, allowing them to create and modify all other resources inside the organization. As they looked toward using Google Cloud, the super administrators could:

1. Give the admin role to people, for Cloud
2. Act as a point of contact for account recovery
3. Modify or delete the organization if needed

Making admin users for the organization allows other people to then flesh out the resources and policies for pistach.io, before they go nuts and give everyone all the permissions. While that would speed things up, it would make it easy for an attacker to crack through the security shell because any account compromise could give ousize access. Yikes!

Instead, the IT leads specified certain people to act as organization admins, and then gave them permissions to:

1. Define Identity and Access Management policies
2. Structure the Resource Hierarchy
3. Delegate control of specific Cloud elements to others on the team

Once those organization admins were set up, they could give management and oversight of Compute, Storage, Networking and other resource types to the relevant leads, making sure each person had just the right amount of permission for the role they needed to perform. The organization admins don’t have permissions themselves to make these resources. They just delegate. 

Now each person can accomplish the job they’re responsible for, but doesn’t have overly permissive access. Delegating like this keeps the entire organization safer, and limits the blast radius if someone does manage to break in.

You can go through these steps yourself with this tutorial.

By default the creation of an organization resource for the domain gives everyone the ability to create projects and billing accounts. Once they set up their Organization Admin at pistach.io they decided to remove some of these wide permissions and, in a nutshell, bring everything down to a much finer control. So people could get permissions for a folder or a project, but not the entire organization!

Remember to take care of your admin roles, as they have the power, and responsibility, to cause serious harm if not used safely. Be safe with your Identity and Access Management. And keep your data yours! 

Next time we join you we’ll take a crack at creating and provisioning an app to run inside the policies and resource management frameworks created today.

More people than ever have been conducting more of their lives online due to the COVID-19 pandemic. This creates a new landscape for fraudsters to create and release new attacks. Research commissioned by Forrester Consulting showed 84% of companies have seen an increase in bot attacks. 71% of organizations have seen an increase in the amount of successful attacks. 65% of businesses have experienced more frequent attacks and greater revenue loss due to bot attacks. With so many people visiting government websites to learn more about the COVID-19 vaccine, make vaccine appointments, or file for unemployment, these web pages have become prime targets for bot attacks and other abusive activities. But reCAPTCHA Enterprise has helped state governments protect COVID-19 vaccine registration portals and unemployment claims portals from abusive activities.

Assisting with unemployment claims during COVID-19

Alongside the wave of unemployment claims caused by COVID-19, many state government agencies, such as Wisconsin’s Workforce Development, have seen an increase in attempted malicious bot logins on their external websites. Many states have had malicious actors visit unemployment claims portals and enter stolen credentials to file fraudulent unemployment claims. Because many unemployment claims portals are mandated to pay a recipient within 2 weeks, the claims portal processes this fraudulent information and bad actors receive unemployment checks weeks before their false claims are recognized. By then, the fraudsters have their money and have repeated this process using other stolen credentials.

reCAPTCHA Enterprise helps state governments reduce false claims by preventing adversaries from automatically reusing credentials on unemployment claims portals. reCAPTCHA Enterprise’s scale and speed to determine fraudster behavior across the Internet helped some of the largest states in the United States, such as Texas. 

Registering for the COVID-19 Vaccine and accessing state-sponsored resources

Several states, such as Pennsylvania, are challenged by web traffic that fluctuates based on the COVID-19 Vaccine Phase. For example, during Phase 1, there was a large increase in web traffic from both humans and bots because of the demand for the very few available vaccination slots. As more states move into Phase 2 and Phase 3, and the vaccine is more widely available, traffic is increasing because bad actors know more people are coming to these websites to register to be vaccinated. 

reCAPTCHA Enterprise was implemented to stop bad actors from scripting bots to book vaccine appointments and then sell those appointment slots on another website for profit. These fake web pages are falsely promoted as websites where people can register for the vaccine. Vaccine appointments are not the only government system from which fraudsters try to profit. Transportation and social service departments also face frequent attacks, wherein fraudsters try to profit by booking and then selling appointments with those organizations. 

Fending off these attacks was made easier thanks to reCAPTCHA Enterprise, a frictionless fraud detection service that leverages our experience from more than a decade of defending the internet and data for our network of more than 5 million sites. The reCAPTCHA Enterprise platform can understand fraudulent behavior, introduce friction to block bots from booking appointments, and allow legitimate users to access the vaccine portals and other state portals. 

Because reCAPTCHA Enterprise does not require end users to complete captcha challenges, several state governments installed reCAPTCHA Enterprise across search, login, and registration web pages. State governments are also placing reCAPTCHA Enterprise on webpages where end users can access healthcare, receive assistance for housing or food, register motor vehicles, or propose legislation. With reCAPTCHA Enterprise on more pages, it becomes more difficult for malicious software or bots to carry out their attacks against different pages, but not for end users to browse, login into accounts, book appointments, or apply for resources. Because reCAPTCHA Enterprise requires no action from end users to stop fraud, state governments implemented reCAPTCHA Enterprise on all points of interaction on their webpages to ensure maximum security without impacting the user experience. 

Providing security everywhere and pricing for all

Many state governments are familiar with buying cloud services in a pay-as-you-go model. reCAPTCHA Enterprise eased the purchasing process by providing state governments with predictable, scalable, and customizable pricing. State governments know up front how much they can expect to pay each month based on the number of assessments reCAPTCHA Enterprise performs. reCAPTCHA Enterprise’s flexible pricing model keeps pace with the natural fluctuations of visitors to vaccination registration and unemployment claims. reCAPTCHA Enterprise has a dedicated sales team that can tailor pricing to your specific use cases so both your webpages and budget are not compromised. 

reCAPTCHA Enterprise has helped many state governments serve their constituents by making it easier to get vaccinated and collect unemployment. It helps constituents take advantage of public services and makes it more difficult for fraudsters to manipulate and interfere with them. 

To start protecting your web pages from credential stuffing and other attacks, get started with reCAPTCHA Enterprise today.

When it comes to security, managing access is a foundational capability—whether you’re talking about a physical space or your cloud infrastructure. If you were securing an office, you wouldn’t give every employee a master key that can open the front door, the mailbox, and the safe. Likewise, when you’re securing your cloud infrastructure, you should limit employees’ access based on their role and what they require to do their job. 

This concept is known as the principle of least privilege, which NIST’s Computer Security Resource Center defines as: “A security principle that restricts the access privileges of authorized personnel… to the minimum necessary to perform their jobs.” In practice, this means assigning credentials and privileges only as needed to both users and services, and removing any permissions that are no longer necessary. 

Keeping the principle of least privilege in mind, here are five practical tips to minimize the surface area of exposed resources on Google Cloud Platform (GCP) and defend against some common attacks. 

Avoid excessive use of broad primitive roles

Primitive roles like Owner and Editor grant wide-ranging access to all project resources. To tighten access security, consider using more specific predefined roles in Cloud Identity and Access Management (IAM), or defining custom roles that are better suited to your organization. For example, if you have a Cloud SQL database, instead of granting the project-wide Editor role to everybody, you could grant the cloudsql.editor role to users who create new databases, cloudsql.client to those who only need to connect to existing databases, and limit cloudsql.admin to database administrators.

Our policy design page has some sample structures and policies for different types of organizations, including startups, large enterprises, and education and training customers.

Assign roles to groups, not individuals

If you assign an IAM role directly to an individual, they retain the rights granted by that role even if they change roles, move around your organization, or no longer require them. A safer and more maintainable option is to place users into logical groups. For example, to manage databases, you could create db-editors, db-viewers, and db-admins groups, and let users inherit roles from these groups:

Groups can be created within the Admin Console for any G Suite domain, or federated from an external tool like Active Directory. By using groups for ownership, you can also avoid “orphaned” projects and resources—where a project or resource has a single owner who leaves the organization. 

You can assign roles at the organization, folder, project, or resource level. This lets larger organizations easily manage roles for, say, a specific developer team or the entire accounting department. Be aware, however, that a child resource cannot limit roles granted by a parent: a user’s project-level cloudsql.viewer role, for example, will override any resource-level restrictions on any database in the same project.

Reduce the risks of default service account behavior

Service accounts are a special type of account intended for apps that need to access data. If the app’s own private credentials are compromised, however, the attacker then has all the access granted to the app by the service account’s roles.

The Compute Engine default service account, which has the editor role, is enabled for all instances created in a project unless you specify otherwise.

Creating a custom service account to use for creating instances and limiting its roles to the minimum necessary significantly reduces risk. For example, many apps using Cloud SQL only need the cloudsql.client role that lets them connect to an existing database.

An alternative approach is to grant the instance service account minimal privileges and create dedicated service accounts for your apps. This gives you more fine-grained control over each app’s privileges, although you will need to carefully manage the service account credentials.

Reduce risk and control access to your project by using networking features

To enable inter-resource communication, new GCP projects initially have a default network connecting all resources in that project. This is convenient for development, but in this default configuration, if an attacker gains unauthorized access to one resource, they may be able to reach others as well.

To limit this risk, don’t use the default network in production and explicitly specify accepted source IP ranges, ports, and protocols in network firewalls. You should also separate sensitive apps into individual virtual private clouds (VPCs), and if inter-app connectivity is required, use a Shared VPC. In each VPC, use different subnets for public facing services (e.g., web servers and bastion hosts) and private backend services. Allocate public IPs only to instances in the public subnet and add firewall rules with network tags to control which services can communicate with each other. Finally, grant permission to create or modify firewalls and routes only to those directly responsible for the network.

The Secure Instances and Apps with Custom Networks codelab walks you through setting up the public/private subnet configuration above. The Policy design for customers article we mentioned earlier also contains sample network designs for common use cases. For guidance on the tradeoffs of single, multiple, and shared VPCs, see Best practices and reference architectures for VPC design.

Consider using managed platforms and services

If you deploy and manage your own applications, you are responsible for security configuration, including the maintenance of accounts and permissions. You can limit your responsibilities by hosting your apps on managed platforms like Cloud Run, App Engine, or Cloud Functions, or by using fully managed services for databases and processing frameworks like Cloud SQL for MySQL and Postgres, Cloud Dataproc for Hadoop and Spark, and Cloud Memorystore for Redis.

A final note

Security is a priority in all aspects of Google Cloud, but cloud security is a shared responsibility, and ultimately you are responsible for making the right configuration and product choices for your organization to protect your data on GCP. These tips are a great starting point to help reduce your attack surface and help you make more informed risk decisions.