Introduction
Let’s be real - when you’re working in a smaller company or with a lean cloud team, you don’t always have a full-blown CNAPP solution in place. A lot of cloud engineers I meet just want to keep things manageable: they’re already routing logs to the SIEM, but don’t necessarily want to work with a separate team to define detections. Instead, they’d rather build everything right inside Security Command Center (SCC) in Google Cloud.
That’s where SCC’s Event Threat Detection Custom Modules come in - and they’re incredibly underrated and well hidden. Think of them as your own mini detection engine: you can write logic that flags when someone spins up a VM with an unapproved image, assigns over-permissive roles like Owner, or touches sensitive accounts meant only for emergencies. No need to wait for someone else to define it. You know your environment best, so why not build detections that reflect that
In this article, we’ll explore how to use Custom Modules within SCC’s Event Threat Detection engine to create tailored detections that complement your organization’s cloud governance.
Where to Start: Navigating to Custom Threat Detection Rules
To begin working with Custom Modules, head over to Security Command Center in the Google Cloud Console. From there:
- Click on Settings in the right-hand navigation.
- Under Threat Detection, choose Event Threat Detection (ETD).
It’s worth noting: ETD is currently the only threat detection module in SCC that supports custom modules. This is your place to defining your own detections based on internal policies or unusual activity patterns.
Once you’re inside the ETD settings, you’ll find the option to create a custom module, allowing you to define rules that are evaluated based on logs and cloud activity.
What Can You Detect? Current Custom Module Capabilities
As of now, SCC’s Custom Modules support a targeted set of threat detection use cases. Each rule you create is based on a specific event type or condition. Here’s what’s available:
- API Method
Detect if a specific API method has not been used in a defined number of days - useful for identifying unused capabilities. - API Calls
Trigger findings when an API call matches a specific combination of principal, method, and resource. Think of this like regex-based detection for suspicious log entries. - Compute Engine Regions
Flag when a new Compute Engine instance is created in a region outside your approved list - handy for geo-fencing or compliance concerns. - Compute Engine Source Images
Detect the use of unauthorized base images during VM creation, helping enforce your golden image strategy. - Domains
Raise alerts when traffic is seen going to specific domain names - great for catching connections to high-risk or suspicious destinations. - Emergency Access Accounts
Detect when breakglass accounts are used. These high-privilege accounts should be tightly controlled and rarely accessed. - IP Addresses
Identify connections to particular IPs, such as known malicious infrastructure or internal-only ranges. - Permissions
Trigger a finding when a custom role is granted and contains any IAM permissions you’ve flagged as sensitive. - Roles
Catch when specific roles (e.g.,OwnerorEditor) are assigned to a user or service account. - Compute Engine Instance Types
Detect when new VMs don’t match your organization's approved instance types or configurations - helpful for managing cost and risk.
A Practical Example: Flagging Risky Role Assignments
Let’s walk through a simple use case: Detecting the assignment of basic roles such as Owner, Editor, or Viewer to any principal.
These roles are broad and often violate least-privilege principles. While you might enforce restrictions via Organization Policies, you might also prefer a soft enforcement approach where these actions are allowed but flagged for review.
In our example:
- Denied Roles:
roles/owner,roles/editor,roles/viewer - Custom Severity:
High
Once deployed, this rule will generate a high-severity finding in your SCC dashboard whenever one of these roles is granted. This allows your security team to maintain visibility into risky behavior - even in cases where outright denial isn’t feasible due to business exceptions or legacy dependencies.
But there’s a philosophical question here: if we know these roles shouldn't be used, shouldn’t we just block them entirely via Organization Policies with custom constraints?
Yes - in many cases, org policies are the cleaner solution. In fact, I’ve written about this approach in my other article. But sometimes, you need flexibility. You may want to allow an action temporarily, or simply raise visibility without hard enforcement. This is where SCC custom modules shine: they complement policy with visibility.
Alexander Hose
Member discussion