GuardDuty

On this page

Coverage by target cloud
How the targets compare
- Infrastructure-only adaptation
On Google Cloud
On Azure
On OCI

Coverage by target cloud

Target	Available
Google Cloud	✓
Azure	✓
OCI	✓
Private Kubernetes	-

How the targets compare

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

Infrastructure-only adaptation

Capability	GuardDuty	Google Cloud	Azure	OCI
Continuous managed detection	Yes	Yes - Google-operated Security Command Center detectors	Yes - Microsoft-operated Defender plans	Yes - Oracle-operated Cloud Guard detector recipes
Detection sources · telemetry analyzed	CloudTrail, VPC Flow Logs, DNS, EKS audit, S3 data events	Supported Google Cloud logs and signals; required services and modules must be enabled	Azure signals supported by the configured Defender plans	OCI activity, configuration and threat signals supported by the selected recipes
Finding types · portability	GuardDuty finding types	Security Command Center categories; different detector rules	Defender alert types; different rules and categories	Cloud Guard problem types and detector rules
Severity-scored findings	Yes	Yes	Yes	Yes
Filters, IP sets, threat-intel sets	Yes	Partial - Review and recreate supported mute rules and other target-specific settings	Partial - Review and recreate supported target-specific rules	Partial - Review and recreate supported detector-rule conditions and managed lists
SIEM integrations and response	Yes	Yes - Pub/Sub exports and Google SecOps integrations	Yes - Microsoft Sentinel integrations, analytics rules and playbooks	Yes - OCI Events and optional Cloud Guard responder recipes
Enablement · how protection is configured	Detector and feature settings	Security Command Center service tier, detectors and log sources	Resource-specific Defender plans and settings	Detector and responder recipes attached to a compartment target
API coverage	full	partial	partial	partial

On Google Cloud

Operation	Area	Support	Depth	Notes
Account activity threat detection (CloudTrail analysis)	Detection sources	Supported	Common	Event Threat Detection analyzes supported Google Cloud audit logs. Its events and finding categories differ from GuardDuty’s CloudTrail findings.
DNS threat detection (DNS query-log analysis)	Detection sources	Supported	Most usage	Event Threat Detection can analyze supported DNS logs. Its detector rules differ from GuardDuty’s DNS finding catalog.
Kubernetes audit-log threat detection (EKS)	Detection sources	Supported	Most usage	Event Threat Detection analyzes supported GKE audit logs; Container Threat Detection covers runtime signals. Coverage differs from GuardDuty’s EKS rules.
Malware Protection (EBS volume scan)	Detection sources	Partial	Full surface	Virtual Machine Threat Detection uses a different scanning mechanism from GuardDuty’s EBS volume scanning; compare the malware coverage your workload needs.
Network threat detection (VPC Flow Log analysis)	Detection sources	Supported	Most usage	Google Cloud network-threat detection uses its supported network telemetry. Configure the required logs and review which GuardDuty detections have an equivalent.
Detector enablement (SCC Event Threat Detection)	Detector	Supported	Common	Maps to Security Command Center’s managed threat detectors, including Event Threat Detection. The required services and logging must be enabled; a custom finding source alone does not enable detection.
Detector-set tier gating	Detector	Partial	Full surface	Detector availability depends on the Security Command Center service tier and enabled modules. Choose the services and log sources required for the intended coverage.
GuardDuty finding-type catalog	Findings	Out of scope	Full surface	GuardDuty finding-type strings do not map one-for-one to Security Command Center categories. Update automations that match specific AWS finding names.
SIEM / event fan-out	Findings	Supported	Common	Findings can be exported to Pub/Sub and integrated with Google SecOps. Adapt response rules to the target’s finding schema.
Severity-scored findings	Findings	Supported	Common	Security Command Center produces severity-scored findings with Google Cloud categories. They are not GuardDuty finding types.
Finding filters (aws_guardduty_filter)	Suppression + lists	Out of scope	Full surface	GuardDuty filters do not translate directly into Security Command Center mute rules. Review and recreate required suppression.
Threat-intel sets (aws_guardduty_threatintelset)	Suppression + lists	Out of scope	Full surface	GuardDuty threat-intelligence feeds require target-specific configuration; they are not copied directly.
Trusted IP sets (aws_guardduty_ipset)	Suppression + lists	Out of scope	Full surface	GuardDuty trusted-IP lists require target-specific configuration; they are not copied directly.

How it works

On Google Cloud, GuardDuty maps to Security Command Center (SCC) threat-detection services. Google operates detection over the customer’s Google Cloud resources and produces findings with severity levels. This is a best-effort mapping between different security products: each required threat scenario needs a coverage review. Event Threat Detection analyzes supported logs; other SCC services cover container and VM threats. Configure the required services and log inputs in the customer’s organization or projects, and connect findings to Pub/Sub or Google SecOps for downstream processing. GuardDuty findings, filters and response rules need translation to the target services.

GuardDuty maps to Google Security Command Center threat detection over Google Cloud resources. Configure the needed detectors, log sources and finding exports; coverage differs by detector.

SCC provides the intended Google Cloud detection services. Review detector coverage and configure finding export.

SCC service configuration

Configure SCC’s built-in threat-detection services for the customer’s organization or projects. The selected detectors determine the required log inputs and service tier. GuardDuty feature toggles map to this service configuration rather than to one identical Google detector. Enable the required logs and finding exports, then test the response rules that consume SCC findings. Google’s service list describes the detectors available for each workload.

The Google target configures Security Command Center services for the customer's organization or projects, supplies the required logs and exports findings for response rules.

How findings map

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 names differ from SCC categories. Review SSH, cryptomining and network detection separately; no one-to-one catalog mapping is implied.

SCC uses its own finding categories. Review each rule that matches a GuardDuty finding type and rewrite it for the relevant SCC category.

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.

Review Google audit, network, DNS and container detection against the required GuardDuty scenarios. VM memory inspection differs from EBS snapshot scanning.

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

SCC activation and detectors

Event Threat Detection analyzes supported log sources. Container and Virtual Machine Threat Detection examine different workload signals. Select the services for the customer’s actual workloads and confirm their availability in the chosen SCC subscription. Scope access to findings and exports as well as access to the protected resources. Security operators need the target’s categories, severity and resource identifiers in their response procedures.

Limitations

△ Detection differences

GuardDuty finding identifiers and rules are not translated. Rules matching UnauthorizedAccess:EC2/SSHBruteForce or CryptoCurrency:* need a detector-by-detector coverage review and new target rules.
Filters, trusted IP sets and threat feeds are not generated. GuardDuty filters, trusted IP sets and threat-intelligence sets do not have a one-to-one mapping. Configure the corresponding target controls for each requirement and review their differences.
Malware scanning differs. GuardDuty EBS snapshot scans and SCC VM memory inspection examine different data. Select protection based on the workload and threat being detected.

Other considerations

Configure the customer scope. Use the customer organization or project scope selected for SCC. Historical GuardDuty findings are not copied into the target.
Configure finding export and response rules. Configure Pub/Sub export, Google SecOps rules and response automation for the selected detectors. GuardDuty EventBridge rules need review against SCC categories and severity.
Check the current service tier and detector settings. SCC service availability and pricing depend on the subscription. Confirm each required detector and log input individually.

On Azure

Operation	Area	Support	Depth	Notes
Account activity threat detection (CloudTrail analysis)	Detection sources	Supported	Common	Azure activity detection uses Azure’s activity and resource-management signals. The events and alert types differ from CloudTrail-based findings.
DNS threat detection (DNS query-log analysis)	Detection sources	Supported	Most usage	DNS-related threats are detected through the signals available to the configured Defender plans. Review coverage for the DNS threats your application needs.
Kubernetes audit-log threat detection (EKS)	Detection sources	Supported	Most usage	Defender for Containers analyzes AKS audit and runtime signals. Its detection rules differ from GuardDuty’s EKS rules.
Malware Protection (EBS volume scan)	Detection sources	Partial	Full surface	Defender for Servers provides malware detection, including agentless scanning in Plan 2. Select the required plan and scanning settings; detection differs from GuardDuty’s EBS scan.
Network threat detection (VPC Flow Log analysis)	Detection sources	Partial	Most usage	Network alerts depend on Defender’s available telemetry and plan configuration; they do not reproduce GuardDuty’s VPC Flow Log finding catalog.
Detector enablement (Defender for Cloud plans)	Detector	Supported	Common	Maps to Microsoft Defender for Cloud plans, including Servers and Storage. Protection is configured by resource type rather than through one GuardDuty detector.
GuardDuty finding-type catalog	Findings	Out of scope	Full surface	GuardDuty finding-type strings are AWS-specific. Update automations that match them to use the relevant Defender alert types.
Publishing destination (S3 finding export)	Findings	Out of scope	Full surface	GuardDuty’s S3 finding-export configuration does not translate directly. Select an Azure export destination and configure the required integration.
SIEM / event fan-out	Findings	Supported	Common	Microsoft Sentinel receives Defender alerts through its integrations. Response rules need to use Defender alert types rather than AWS event names.
Severity-scored findings	Findings	Supported	Common	Defender produces severity-scored Azure security alerts. Alert types and scoring differ from GuardDuty’s.
Finding filters (aws_guardduty_filter)	Suppression + lists	Out of scope	Full surface	GuardDuty suppression rules do not translate directly. Review and recreate required exclusions using Defender’s supported configuration.
Threat-intel sets (aws_guardduty_threatintelset)	Suppression + lists	Out of scope	Full surface	Custom GuardDuty threat feeds require a target-specific integration; enabling Defender does not copy them.
Trusted IP sets (aws_guardduty_ipset)	Suppression + lists	Out of scope	Full surface	GuardDuty trusted-IP lists do not translate directly. Review the exclusions supported by the relevant Azure detector.

How it works

On Azure, GuardDuty maps to Microsoft Defender for Cloud protection plans. Microsoft operates detection over Azure resources and produces security alerts with severity levels. This is a best-effort mapping: Defender uses different signals and rules, so review each required threat scenario. Select the Defender plans and settings for the customer’s servers, storage, containers and subscription activity. Configure Microsoft Sentinel or another supported integration for downstream analysis and response. The relevant plan, telemetry and alert names differ from GuardDuty’s detector and finding types.

GuardDuty maps to Azure Defender for Cloud plans selected for the customer resources. Configure required telemetry and Sentinel integration; detection fidelity is imperfect.

Defender plans provide the intended Azure detection services. Configure required plan settings and Sentinel integration.

Defender plan configuration

Defender protection is configured by resource type and plan, commonly through azurerm_security_center_subscription_pricing. Servers uses VirtualMachines and Storage uses StorageAccounts at the Standard tier. Containers and subscription-activity protection require their corresponding settings. Check the effective plan, subplan and extensions for the customer’s resources. A subscription-level setting does not establish that every workload or scanning feature is protected. Choose required telemetry collection and Sentinel integration alongside the plans.

Defender uses resource-specific plans and settings. Servers and Storage have their own subscription pricing resources; other protection and scanning settings must be selected for the workload.

The detector compiles onto the Defender for Cloud plans: one azurerm_security_center_subscription_pricing per resource type, at the Standard tier, enabled for the whole subscription.

How findings map

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 alert families and the signals each enabled plan analyzes. Enabling plans does not translate those rules or establish one-to-one detection coverage.

GuardDuty finding names differ from Defender alert names. Review detection behavior and rewrite rules for the required threats.

Defender uses its own alert families. Review each rule that matches a GuardDuty finding type and rewrite it for the relevant Defender alert.

Detection sources

Map server, storage, container and subscription-activity threats to the relevant Defender protection. DNS protection is part of Defender for Servers; the older standalone Defender for DNS plan is not the basis for a new deployment. Review the actual protected resources and signals 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.

Compare AWS detection requirements with Azure protection plans and active settings. Server malware protection includes endpoint and agentless options with different coverage.

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

Severity, response, and fan-out

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.

Defender alerts can feed Microsoft Sentinel. Configure analytics rules and playbooks for the required responses and verify their behavior.

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

Limitations

△ Configuration gaps

Protection depends on plan and workload settings. Select Containers and Resource Manager protection, agents and scanning extensions as required. Review effective settings and detection coverage in the customer subscription.
Finding names and automation differ. Rules matching GuardDuty identifiers such as UnauthorizedAccess:EC2/SSHBruteForce or CryptoCurrency:* need review against Defender alert behavior and names.
GuardDuty filters, IP sets and threat feeds are not translated. The build does not recreate aws_guardduty_filter, aws_guardduty_ipset or aws_guardduty_threatintelset. Assess target controls for each requirement.
Network and malware coverage need separate verification. Similar plan names do not prove that every GuardDuty network finding or EBS malware scenario is detected. Check active subplans, extensions and workload settings.

Other considerations

The plans apply at subscription scope. Review plan scope and cost across the customer subscription. Historical GuardDuty findings are not migrated.
Select additional protection for the workload. Configure required protection beyond Servers and Storage explicitly. Product plan names and availability change; use current Microsoft documentation when choosing those settings.
Configure Sentinel integration. Configure the alert connection, analytics rules and playbooks separately, then test the responses the application requires.

On OCI

Operation	Area	Support	Depth	Notes
Account activity threat detection (CloudTrail analysis)	Detection sources	Supported	Common	Cloud Guard activity detectors analyze OCI Audit events. Their rules differ from GuardDuty’s CloudTrail finding types.
Configuration / posture detection	Detection sources	Supported	Most usage	Cloud Guard configuration detectors identify resource configuration issues in addition to activity-based threats.
Kubernetes audit-log threat detection (EKS)	Detection sources	Partial	Most usage	OKE coverage depends on Cloud Guard’s available detector recipes. It does not reproduce GuardDuty’s EKS audit-log finding catalog.
Network threat detection (VPC Flow Log analysis)	Detection sources	Partial	Full surface	Cloud Guard’s activity and configuration detection differs from GuardDuty’s network-flow analysis. Review the specific network threats your workload requires.
Threat-intel detection	Detection sources	Supported	Most usage	Cloud Guard threat detectors use OCI’s threat signals and rules; findings do not match GuardDuty’s catalog one-for-one.
Detector enablement (Cloud Guard recipes + target)	Detector	Supported	Common	Maps to Cloud Guard with a compartment target and the required detector recipes. Recipes determine which resources and activity are monitored.
GuardDuty finding-type catalog	Findings	Out of scope	Full surface	GuardDuty finding-type strings do not map one-for-one to Cloud Guard problem types. Update automations that match AWS finding names.
Response / auto-remediation	Findings	Supported	Common	Cloud Guard responder recipes can act on detected problems. Responses are opt-in and can change live resources; review them before enabling.
Severity-scored findings	Findings	Supported	Common	Cloud Guard produces severity-scored problems using its own problem types and scoring.
Finding filters (aws_guardduty_filter)	Suppression + lists	Out of scope	Full surface	GuardDuty filters do not translate directly. Review and recreate required suppression in Cloud Guard detector-rule conditions.
Threat-intel sets (aws_guardduty_threatintelset)	Suppression + lists	Out of scope	Full surface	GuardDuty threat-intelligence feeds require target-specific configuration; they are not copied directly.
Trusted IP sets (aws_guardduty_ipset)	Suppression + lists	Out of scope	Full surface	GuardDuty trusted-IP lists require Cloud Guard managed-list or detector-rule configuration; they are not copied directly.

How it works

On OCI, GuardDuty maps to Cloud Guard detector recipes, sets of rules that analyze OCI resources and produce problems with severity levels. Oracle operates the service. This is a best-effort mapping: the OCI rules and signals do not reproduce the GuardDuty finding catalog. Enable Cloud Guard, define the target compartment and attach detector recipes for the required threats. Configure OCI Events or responder recipes for downstream actions. Review required network and container detections separately; extra configuration checks do not fill gaps in those scenarios.

GuardDuty maps to OCI Cloud Guard targets and detector recipes. Select and verify the required rules; responder recipes and OCI Events provide response options.

Cloud Guard targets and detector recipes provide the intended OCI detection architecture.

Cloud Guard target configuration

Cloud Guard uses a tenancy configuration and targets that identify monitored compartments. Terraform represents these with oci_cloud_guard_cloud_guard_configuration and oci_cloud_guard_target. Detector recipes attached to each target determine which rules run. Select and verify Activity, Configuration and Threat recipes against the customer’s requirements. Responder recipes are separate controls that can change resources. Select the reporting region for the customer’s deployment.

Cloud Guard uses tenancy enablement, a target compartment and attached detector recipes. The deployment selects the reporting region.

Enable Cloud Guard, define a compartment target and select the detector recipes needed for the workload.

How findings map

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 or establish one-to-one detection coverage.

GuardDuty finding names differ from Cloud Guard problem types. Review detection behavior and severity for each required case.

Cloud Guard uses its own problem types. Review each GuardDuty rule and rewrite it for the relevant Cloud Guard detector rule or problem.

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.

Cloud Guard offers audit, configuration and threat rules. Additional configuration checks do not replace missing network or container detection.

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

Detector and responder recipes

Attach the required detector recipes to the target and tune their rules. Verify the findings produced for the customer’s resources; selecting a recipe name alone does not establish 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 a target produce problems. Explicitly configured responder recipes can act on affected resources.

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

Limitations

△ Configuration gaps

Detection depends on the attached recipes. Select detector recipes and verify the required rules on the target before relying on detection. Configure responder actions separately.
Finding names and GuardDuty rules are not translated. Rules matching UnauthorizedAccess:EC2/SSHBruteForce or CryptoCurrency:* need review against Cloud Guard problem types and detection behavior.
Filters, IP sets and threat feeds require review. The build does not recreate aws_guardduty_filter, aws_guardduty_ipset or aws_guardduty_threatintelset. Assess which Cloud Guard rules or lists meet each requirement.
Network and container detection gaps remain. Cloud Guard configuration checks do not replace GuardDuty VPC Flow Log analysis or EKS audit-log coverage. Assess each required detection separately.

Other considerations

Cloud Guard enablement and target scope differ. The build enables Cloud Guard and creates a compartment target. Historical GuardDuty findings are not copied, and target creation alone does not verify active detection.
Confirm reporting region and recipe attachments. Confirm the configured reporting region and detector recipe attachments. Enable responder recipes only for the actions the customer wants automated.
Configure response automation. Configure required OCI Events rules or responder recipes separately. Review the resources a responder can change and test each response before using it.

Service Catalog.

Tensor9

Getting Started

How It Works

Deploying

Your Customer's Environment

Service Adapters

Auto-Customizations

Security

Connectivity & Networking

Observability & Operations

tensor9 CLI

Coverage by target cloud

How the targets compare

Infrastructure-only adaptation

On Google Cloud

How it works

SCC service configuration

How findings map

Detection sources

SCC activation and detectors

Limitations

Other considerations

On Azure

How it works

Defender plan configuration

How findings map

Detection sources

Severity, response, and fan-out

Limitations

Other considerations

On OCI

How it works

Cloud Guard target configuration

How findings map

Detection sources

Detector and responder recipes

Limitations

Other considerations

​Coverage by target cloud

​How the targets compare

​Infrastructure-only adaptation

​On Google Cloud

​How it works

​SCC service configuration

​How findings map

​Detection sources

​SCC activation and detectors

​Limitations

​Other considerations

​On Azure

​How it works

​Defender plan configuration

​How findings map

​Detection sources

​Severity, response, and fan-out

​Limitations

​Other considerations

​On OCI

​How it works

​Cloud Guard target configuration

​How findings map

​Detection sources

​Detector and responder recipes

​Limitations

​Other considerations

Coverage by target cloud

How the targets compare

Infrastructure-only adaptation

On Google Cloud

How it works

SCC service configuration

How findings map

Detection sources

SCC activation and detectors

Limitations

Other considerations

On Azure

How it works

Defender plan configuration

How findings map

Detection sources

Severity, response, and fan-out

Limitations

Other considerations

On OCI

How it works

Cloud Guard target configuration

How findings map

Detection sources

Detector and responder recipes

Limitations

Other considerations