Skip to main content
On this page

​
Coverage by target cloud

​
How the backends compare

Each row compares a capability of GuardDuty with its adaptation on each backend. A dash means this row is not stated for that backend.

​
Infrastructure-only adaptation

​
On Google Cloud

​
How it works

On Google Cloud, GuardDuty maps to Security Command Center (SCC) threat detection. When Tensor9 builds the deployment it creates one SCC source, “Tensor9 GuardDuty Equivalent”, in your Google Cloud organization. Google runs detection over your resources and produces findings with severity levels. This is a best-effort match between different security products, so review each threat scenario you depend on. Event Threat Detection analyzes supported logs; other SCC services cover container and VM threats. You turn on the services and log inputs in your organization or projects, and connect findings to Pub/Sub or Google SecOps. GuardDuty filters and response rules must be rewritten for SCC.
On AWS, GuardDuty analyzes AWS telemetry and reports severity-scored findings. On Google Cloud, Security Command Center detectors such as Event Threat Detection analyze Google Cloud logs, and findings can be exported to Pub/Sub. You turn on the detectors and the export.On AWS, GuardDuty analyzes AWS telemetry and reports severity-scored findings. On Google Cloud, Security Command Center detectors such as Event Threat Detection analyze Google Cloud logs, and findings can be exported to Pub/Sub. You turn on the detectors and the export.

Security Command Center detectors analyze Google Cloud logs; you turn them on and export their findings.

​
What you configure in SCC

The SCC source Tensor9 creates records the posture; it does not turn on Event Threat Detection. You switch that on in SCC’s settings, at the Premium or Enterprise tier, for your organization or projects. The detectors you choose decide which logs and which service tier you need. GuardDuty’s feature toggles map to this configuration, not to one identical Google detector. Turn on the logs and finding exports you need, then test the response rules that read SCC findings. Google’s service list describes the detectors available for each workload.
SCC services are configured for your organization or projects; the detectors you choose decide which logs and service tier you need, and findings feed your export and alert rules.SCC services are configured for your organization or projects; the detectors you choose decide which logs and service tier you need, and findings feed your export and alert rules.

​
Finding names and rules

GuardDuty identifiers such as UnauthorizedAccess:EC2/SSHBruteForce, CryptoCurrency:EC2/BitcoinTool.B and Recon:EC2/Portscan do not become SCC finding identifiers. SCC detectors produce their own categories and severity levels, so update rules that match the AWS identifiers. Review EventBridge filters, suppression rules and downstream parsers that use GuardDuty finding names, including patterns such as CryptoCurrency:*. Determine whether a Google detector covers each required case before rewriting the rule. The diagram describes areas to review, not verified one-to-one finding mappings.
GuardDuty finding types such as UnauthorizedAccess:EC2/SSHBruteForce have no matching SCC finding names. Review SSH, cryptomining and network-scan detection in SCC separately; there is no one-to-one mapping.GuardDuty finding types such as UnauthorizedAccess:EC2/SSHBruteForce have no matching SCC finding names. Review SSH, cryptomining and network-scan detection in SCC separately; there is no one-to-one mapping.

SCC uses its own finding categories. Rewrite each rule that matches a GuardDuty finding type.

​
Detection sources

Cloud Audit Logs, network logs, DNS logs and GKE signals are candidate inputs for the Google services used in this mapping. Coverage depends on the specific detector and its supported log sources. Review the threats your application must detect instead of assuming that similar log names imply equivalent analysis. GuardDuty Malware Protection scans EBS volume snapshots. SCC Virtual Machine Threat Detection examines running VM memory. These inspect different data, so assess the required malware scenarios separately; memory inspection does not replace every snapshot-scan use case.
Each GuardDuty detection source compared with the Google Cloud logs and SCC detector that covers it. VM memory inspection differs from EBS snapshot scanning.Each GuardDuty detection source compared with the Google Cloud logs and SCC detector that covers it. VM memory inspection differs from EBS snapshot scanning.

Review each Google detector and its log inputs against the required threat scenarios.

​
Detectors and access

Event Threat Detection analyzes supported log sources. Container Threat Detection and Virtual Machine Threat Detection examine different workload signals. Choose the services for the workloads you actually run and confirm they are available in your SCC subscription. Control who can read findings and exports, as well as who can reach the protected resources. Your security operators need SCC’s categories, severity levels and resource identifiers in their response procedures.

​
Limitations

Where Security Command Center and GuardDuty differ
  • Event Threat Detection is not turned on for you. Tensor9 creates the SCC source only. You turn on the detectors in SCC’s settings, at the Premium or Enterprise tier, and confirm each one is available.
  • Finding names behave differently: rules that match GuardDuty names stop matching. Rules matching UnauthorizedAccess:EC2/SSHBruteForce or CryptoCurrency:* need a detector-by-detector coverage review and new rules for SCC.
  • GuardDuty filters, IP sets, threat feeds and publishing destinations are not recreated. The build reports each aws_guardduty_filter, aws_guardduty_ipset, aws_guardduty_threatintelset and aws_guardduty_publishing_destination it does not transfer. Configure the matching SCC controls, such as mute rules, for each requirement.
  • You must turn on detection for S3 data events, EKS audit logs and malware scanning. If your detector uses these sources, the build reports a warning for each one. Turn on and check the matching SCC service.
  • Malware scanning behaves differently. GuardDuty scans EBS snapshots; SCC Virtual Machine Threat Detection inspects VM memory. They examine different data, so choose protection by workload and threat.

​
Other considerations

  • Organization scope. The source is created in your Google Cloud organization. Historical GuardDuty findings are not copied.
  • Export and response rules. Configure Pub/Sub export, Google SecOps rules and response automation for the detectors you turn on. Review GuardDuty EventBridge rules against SCC categories and severity.
  • Service tier and detector settings. SCC service availability and pricing depend on your subscription. Confirm each detector and log input you need.
  • Outputs keep working. Terraform outputs that read the detector’s id, arn or account_id still resolve; they return the detector’s name.

​
On Azure

​
How it works

On Azure, GuardDuty maps to Microsoft Defender for Cloud. When Tensor9 builds the deployment, it turns on two Defender plans for the subscription, Servers and Storage, at the Standard tier. Microsoft runs detection over your Azure resources and raises security alerts with severity levels. This is a best-effort match: Defender uses different signals and rules from GuardDuty, so review each threat scenario you depend on. You choose any further protection your workload needs, such as Containers and subscription activity, and connect alerts to Microsoft Sentinel or another supported tool for analysis and response. Plan, telemetry and alert names differ from GuardDuty’s detector and finding types.
On AWS, GuardDuty analyzes AWS telemetry and reports severity-scored findings. On Azure, Tensor9 turns on the Defender for Cloud Servers and Storage plans when it builds the deployment; Defender analyzes Azure telemetry and raises alerts. Tensor9 is not in the detection path.On AWS, GuardDuty analyzes AWS telemetry and reports severity-scored findings. On Azure, Tensor9 turns on the Defender for Cloud Servers and Storage plans when it builds the deployment; Defender analyzes Azure telemetry and raises alerts. Tensor9 is not in the detection path.

Tensor9 turns on Defender for Servers and Defender for Storage; you choose other protection and connect Sentinel.

​
What Tensor9 turns on

Tensor9 creates two azurerm_security_center_subscription_pricing resources at the Standard tier: VirtualMachines (Defender for Servers) and StorageAccounts (Defender for Storage). It creates them once per stack, however many detectors you declare, and none if the detector is disabled. Containers and subscription-activity protection need their own settings, which you configure. Check the effective plan, subplan and extensions for your resources: a subscription-level plan does not mean every workload or scanning feature is protected. Choose telemetry collection and the Sentinel connection alongside the plans.
Your GuardDuty detector becomes two Defender for Cloud plans at the Standard tier, Servers and Storage, turned on for the whole subscription. Containers and other protection are selected separately.Your GuardDuty detector becomes two Defender for Cloud plans at the Standard tier, Servers and Storage, turned on for the whole subscription. Containers and other protection are selected separately.

The detector becomes one azurerm_security_center_subscription_pricing per plan, at the Standard tier, for the whole subscription.

​
Finding names and rules

GuardDuty finding identifiers such as UnauthorizedAccess:EC2/SSHBruteForce, CryptoCurrency:EC2/BitcoinTool.B and Recon:EC2/Portscan are AWS-specific. Defender uses its own alert names and severity assignments for threats such as brute-force attempts, cryptomining and port scans. Review EventBridge filters, suppression rules and downstream parsers that use GuardDuty names, including patterns such as CryptoCurrency:*. Rewrite them for Defender’s alerts and the signals each enabled plan analyzes. Turning on the plans does not translate those rules, and Defender does not detect exactly the same set of threats.
GuardDuty finding types such as UnauthorizedAccess:EC2/SSHBruteForce become Defender alerts with their own names and severities, such as a brute-force attempt on a VM. Rules that match GuardDuty names must be rewritten.GuardDuty finding types such as UnauthorizedAccess:EC2/SSHBruteForce become Defender alerts with their own names and severities, such as a brute-force attempt on a VM. Rules that match GuardDuty names must be rewritten.

Defender uses its own alert names. Rewrite each rule that matches a GuardDuty finding type.

​
Detection sources

Match server, storage, container and subscription-activity threats to the Defender protection that covers them. DNS protection is part of Defender for Servers; the older standalone Defender for DNS plan is not used for new deployments. Review the resources and signals actually protected for each GuardDuty use case. Defender for Servers includes endpoint protection, and Plan 2 also offers agentless scanning, including malware scanning. Compare the selected subplan and scanning settings with the application’s EBS malware requirements. Different scanning mechanisms do not imply identical detection. See Microsoft’s plan comparison.
Each GuardDuty detection source compared with the Azure telemetry and Defender protection that covers it: management events, flow logs, DNS, Kubernetes audit logs and malware scanning. Server malware protection has endpoint and agentless options with different coverage.Each GuardDuty detection source compared with the Azure telemetry and Defender protection that covers it: management events, flow logs, DNS, Kubernetes audit logs and malware scanning. Server malware protection has endpoint and agentless options with different coverage.

Review each AWS detection requirement against the selected Azure protection and scanning settings.

​
Alerts and response

On AWS, GuardDuty findings can feed Security Hub and EventBridge. On Azure, Defender alerts can feed Microsoft Sentinel, a security information and event management (SIEM) service. Configure the connection, analytics rules and playbooks for the required responses. Rewrite EventBridge filters against the relevant Defender alert names and test severity handling and response actions. Similar alert topics do not imply that the rule matches the same event or has the same false-positive behavior.
On AWS, GuardDuty findings flow to Security Hub and EventBridge for automation. On Azure, Defender alerts flow to Microsoft Sentinel, where you configure analytics rules and playbooks.On AWS, GuardDuty findings flow to Security Hub and EventBridge for automation. On Azure, Defender alerts flow to Microsoft Sentinel, where you configure analytics rules and playbooks.

A configured Sentinel connection receives Defender alerts for analytics rules and response playbooks.

​
Limitations

Where Defender for Cloud and GuardDuty differ
  • Only the Servers and Storage plans are turned on for you. Tensor9 does not turn on Containers, Resource Manager or other Defender protection, agents or scanning extensions. Select them as needed and review effective coverage in the subscription.
  • Finding names behave differently: rules that match GuardDuty names stop matching. Rules matching identifiers such as UnauthorizedAccess:EC2/SSHBruteForce or CryptoCurrency:* must be rewritten for Defender’s alert names and behaviour.
  • GuardDuty filters, IP sets, threat feeds and publishing destinations are not recreated. The build reports each aws_guardduty_filter, aws_guardduty_ipset, aws_guardduty_threatintelset and aws_guardduty_publishing_destination it does not transfer. Re-create the suppression, allowlists, feeds and export you need in Azure.
  • You must turn on protection for S3 data events, EKS audit logs and malware scanning. If your detector uses these sources, the build reports a warning for each one. Enable and check the matching Defender protection.
  • Network and malware detection behave differently. Similar plan names do not mean every GuardDuty network finding or EBS malware scenario is detected. Check active subplans, extensions and workload settings.

​
Other considerations

  • Subscription scope and cost. The plans apply to the whole subscription; review their scope and cost there. Historical GuardDuty findings are not migrated.
  • Further protection. Configure protection beyond Servers and Storage yourself. Defender plan names and availability change, so use current Microsoft documentation when you choose.
  • Sentinel. Configure the alert connection, analytics rules and playbooks, then test the responses your application needs.
  • Outputs keep working. Terraform outputs that read the detector’s id, arn or account_id still resolve; they return the detector’s name.

​
On OCI

​
How it works

On OCI, GuardDuty maps to Cloud Guard. Detector recipes, sets of rules that analyze OCI resources, raise problems with severity levels. Oracle operates the service. This is a best-effort match: OCI’s rules and signals do not reproduce GuardDuty’s finding catalog. When Tensor9 builds the deployment, it enables Cloud Guard and creates a target for the deployment’s compartment. You attach the detector recipes for the threats you need, and configure OCI Events or responder recipes for follow-up actions. Review network and container detection separately: Cloud Guard’s extra configuration checks do not fill gaps there.
On AWS, GuardDuty analyzes AWS telemetry and reports severity-scored findings. On OCI, Tensor9 enables Cloud Guard with a target for the deployment's compartment; detector recipes you attach analyze OCI activity and configuration and raise problems.On AWS, GuardDuty analyzes AWS telemetry and reports severity-scored findings. On OCI, Tensor9 enables Cloud Guard with a target for the deployment's compartment; detector recipes you attach analyze OCI activity and configuration and raise problems.

Tensor9 enables Cloud Guard and creates a compartment target; detector recipes decide what is detected.

​
What Tensor9 turns on

Tensor9 creates an oci_cloud_guard_cloud_guard_configuration with status = "ENABLED" and an oci_cloud_guard_target for the deployment’s compartment. The reporting region is the deployment’s OCI region; if none is set, it defaults to us-ashburn-1 and the build reports a warning. Detector recipes attached to the target decide which rules run. Choose and check Activity, Configuration and Threat recipes against your requirements. Responder recipes are separate controls that can change resources.
Your GuardDuty detector becomes the Cloud Guard tenancy setting, enabled with a reporting region, and a Cloud Guard target for the deployment's compartment. You attach detector recipes and configure responses separately.Your GuardDuty detector becomes the Cloud Guard tenancy setting, enabled with a reporting region, and a Cloud Guard target for the deployment's compartment. You attach detector recipes and configure responses separately.

The detector becomes Cloud Guard’s tenancy setting and a target for the deployment’s compartment.

​
Finding names and rules

GuardDuty identifiers such as UnauthorizedAccess:EC2/SSHBruteForce, CryptoCurrency:EC2/BitcoinTool.B and Recon:EC2/Portscan are AWS-specific. Cloud Guard reports problems for suspicious activity, public exposure and risky configuration using its own names and severity assignments. Review EventBridge filters, suppression rules and downstream parsers that use GuardDuty finding names, including patterns such as CryptoCurrency:*. Rewrite them for the relevant Cloud Guard problem types and detector rules. Enabling Cloud Guard does not translate this automation, and Cloud Guard does not detect exactly the same set of threats.
GuardDuty finding types such as UnauthorizedAccess:EC2/SSHBruteForce have no matching Cloud Guard problem names. Cloud Guard reports its own problems, such as suspicious activity on an instance; check each rule and severity.GuardDuty finding types such as UnauthorizedAccess:EC2/SSHBruteForce have no matching Cloud Guard problem names. Cloud Guard reports its own problems, such as suspicious activity on an instance; check each rule and severity.

Cloud Guard uses its own problem types. Rewrite each rule that matches a GuardDuty finding type.

​
Detection sources

Cloud Guard Activity, Configuration and Threat recipes analyze OCI Audit events, resource settings and threat signals. The specific rules and available data determine coverage. Configuration checks are a separate capability from GuardDuty threat detection. Review GuardDuty VPC Flow Log network analysis and EKS audit-log scenarios individually. Cloud Guard’s configuration checks do not replace those detections. Document missing scenarios and decide whether other OCI controls can meet the application’s requirements.
Each GuardDuty detection source compared with the OCI signal and Cloud Guard detector that covers it. Cloud Guard has no VPC Flow Log network detection, and container coverage is partial.Each GuardDuty detection source compared with the OCI signal and Cloud Guard detector that covers it. Cloud Guard has no VPC Flow Log network detection, and container coverage is partial.

Cloud Guard offers configuration checks; they do not fill network or container detection gaps.

​
Detector and responder recipes

Attach the detector recipes you need to the target and tune their rules. Check the problems raised for your resources; choosing a recipe by name does not give equivalent coverage. Responder recipes can act on problems by changing public bucket access or security-list rules. Review the actions and resources they can affect, then configure and test the intended responses. See Oracle’s target guide for recipe selection.
Detector recipes attached to your compartment target raise problems. Responder recipes, if you configure them, can change the affected resources.Detector recipes attached to your compartment target raise problems. Responder recipes, if you configure them, can change the affected resources.

Detector recipes produce problems. Separately configured responder recipes can act on affected resources.

​
Limitations

Where Cloud Guard and GuardDuty differ
  • You must attach detector recipes. Tensor9 enables Cloud Guard and creates the target, but detection depends on the recipes attached to it. Check the rules you need before relying on detection, and configure responder actions separately.
  • Finding names behave differently: rules that match GuardDuty names stop matching. Rules matching UnauthorizedAccess:EC2/SSHBruteForce or CryptoCurrency:* must be rewritten for Cloud Guard problem types and behaviour.
  • GuardDuty filters, IP sets, threat feeds and publishing destinations are not recreated. The build reports each aws_guardduty_filter, aws_guardduty_ipset, aws_guardduty_threatintelset and aws_guardduty_publishing_destination it does not transfer. Decide which Cloud Guard rules or lists meet each requirement.
  • Network and container detection are not fully supported. Cloud Guard configuration checks do not replace GuardDuty VPC Flow Log analysis or EKS audit-log coverage. If your detector uses EKS audit logs, S3 data events or malware scanning, the build reports a warning for each.

​
Other considerations

  • What Tensor9 creates. Tensor9 enables Cloud Guard and creates a compartment target. Historical GuardDuty findings are not copied, and creating the target does not prove that detection is active.
  • Reporting region and recipes. Confirm the reporting region and the recipes attached to the target. Turn on responder recipes only for the actions you want automated.
  • Response automation. Configure OCI Events rules or responder recipes yourself. Review which resources a responder can change, and test each response before you rely on it.
  • Outputs keep working. Terraform outputs that read the detector’s id, arn or account_id still resolve; they return the detector’s name.

​
Debug this service

For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping. Follow the BYOC service-adapter debugging runbook to capture and interpret the diagnostic evidence. Service Catalog.