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](https://docs.cloud.google.com/security-command-center/docs/concepts-security-sources) describes the detectors available for each workload.
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 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.
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.
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.
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](https://learn.microsoft.com/en-us/azure/defender-for-cloud/plan-defender-for-servers-select-plan).
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.
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.
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.
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.
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 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](https://docs.oracle.com/en-us/iaas/Content/cloud-guard/using/targets-create.htm) for recipe selection.
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](/service-adapters/catalog).