Views:

Get answers to frequently asked support questions for Cloud Risk Management.

Related information

Cloud Risk Management FAQs

How do I manage rule failures related to Agentless Vulnerability & Threat Detection for GCP and Azure?

The Agentless Vulnerability & Threat Detection (AVTD) for GCP and Azure feature has undergone thorough testing including security and performance in order to meet cloud configuration best practices. The following rules findings have been reviewed by Trend Micro team and can be safely ignored:

Rule findings for Azure Agentless Vulnerability & Threat Detection

  1. AppService-013 Enable Automated Backups: The APP Service is stateless and does not store any data. In the event of a failure, it can be fully recreated and redeployed through Terraform, so backups are not required.
  2. Functions-002 Enable Virtual Network Integration for Azure Functions: The Function Apps are already secured through least-privilege role-based access control, managed identities, and encrypted connections, VNet integration is not necessary
  3. VirtualMachines-043 Disable Public Network Access to Virtual Machine Disks: The VM disk allows public network access because multiple services access the disks. Network and service-level controls are in place to limit exposure.
  4. Function-006 Exposed Azure Functions: The Function Apps are publicly accessible to maintain stability in inter-function communication. The role is required to access the function.
  5. VirtualMachines-008 Use BYOK for Disk Volumes Encryption: The scanner VMs launched by AVTD are short-lived and exist only for the scan duration, so BYOK disk encryption is not required.
  6. VirtualMachines-013 Enable Backups for Azure Virtual Machines: The scanner VMs launched by AVTD are short-lived and exist only for the scan duration, so the backup is not required.
  7. VirtualMachines-021 Enable Just-In-Time Access for Virtual Machines: The scanner VMs serve only for disk scanning, so Just-in-Time access is not required.
  8. VirtualMachine-039 Server Side Encryption for Boot Disk using CMK: The scanner VM is a short-term, transient instance that exists only for the duration of a scan, and its boot disk does not store any sensitive data. Therefore, CMK-based server-side encryption is not required.
  9. VirtualMachine-007 Check for SSH Authentication Type: The scanner VM does not allow SSH access, SSH key is not required.
  10. StorageAccounts-018 Storage Account Encryption using Customer Managed Keys: The storage account does not contain sensitive data and is already encrypted using Microsoft-managed keys, so customer-managed keys are not required.
  11. StorageAccounts-023 Private Endpoint in Use: A private endpoint is not required because the storage account does not contain sensitive data and is already secured with RBAC, managed identities, and encrypted access.
  12. StorageAccounts-024 Enable Infrastructure Encryption: Infrastructure-level encryption is not required because the storage account does not store sensitive data and is already protected by Azure’s default server-side encryption with Microsoft-managed keys.
  13. StorageAccounts-029 Disable Public Network Access to Storage Accounts: Public network access to this storage account is enabled because multiple services require access. Access keys and other security controls are in place to ensure that the data remains secure.
  14. KeyVault-001 Enable Key Vault Recoverability: AVTD created key vault is required to be removed immediately, no need for recovery.
  15. KeyVault-018 Use Private Endpoints for Key Vaults: Private endpoints for the Key Vault are not applicable, the Key Vault is securely accessed without requiring VNet integration.
  16. AppService-005 Check that Azure App is using the latest version of HTTP: AVTD Function App handles lightweight requests where HTTP/2 is not required.

Rule findings for Google Cloud (GCP) Agentless Vulnerability & Threat Detection

  1. CloudRun-005: Check for Unrestricted Outbound Network Access: Unrestricted egress is required for AVTD Cloud Run scanner services to work properly, and the associated risks are mitigated through strict IAM controls, isolation, authenticated access, ephemeral workloads, and comprehensive monitoring.
  2. CloudRun-008: Use Customer-Managed Encryption Keys for Services Encryption: AVTD Cloud Run function is encrypted by default using Google-managed keys, and it does not process highly sensitive data, so additional encryption controls are unnecessary.
  3. CloudStorage-006: Enable Object Encryption with Customer-Managed Keys: AVTD bucket is encrypted by default using [Google-managed keys, and it does not store highly sensitive data, so additional CMEK controls are unnecessary.
  4. CloudStorage-005: Define index page suffix and error page for the bucket website configuration: The cloud storage is not intended for website hosting where website configuration is not applicable.
  5. SecretManager-004: Use Customer-Managed Encryption Keys for Secret Manager Secret Encryption: AVTD resources are securely encrypted with default keys so adding additional encryption using customer-managed keys is not required.
  6. CloudRun-001: Check for the Minimum Number of Container Instances: For AVTD, cost efficiency is prioritized, and the small cold start delay is acceptable. Keeping instances running continuously would create unnecessary cost with no meaningful performance benefit.
  7. CloudRun-004: Enable End-to-End HTTP/2 for Cloud Run Service: AVTD Cloud Run service handles lightweight requests where HTTP/2 is not required.
  8. CloudRun-006: Enable Binary Authorization: Binary Authorization is not required because existing IAM, service account controls, private registry restrictions, and network security already ensure only trusted containers are deployed.
  9. CloudVPC-006: Ensure that Cloud DNS logging is enabled for all VPC networks: AVTD securely deploys a [Google network. Cloud DNS logging is not required for monitoring.
  10. CloudVPC-003: Enable VPC Flow Logs for VPC Subnets: AVTD securely deploys VPC subnets network. VPC Flow Logs is not required for monitoring.
  11. CloudStorage-009: Enable Usage and Storage Logs: AVTD access-log bucket is a dedicated bucket used to store logs from the resource bucket.
  12. CloudLogging-010: Configure Retention Policies with Bucket Lock: AVTD sets retention policy for the log sink buckets. Not enforcing the bucket lock feature to allow flexibility to adjust the policy.
  13. CloudStorage-003: Configure Retention Policies with Bucket Lock: AVTD sets retention policy for the cloud storage. Not enforcing the bucket lock feature to allow flexibility to adjust the policy.
  14. SecretManager-002: Enable Destruction Delay for Secret Versions: A delayed destruction policy is not needed because secrets must be removed immediately upon destruction.
  15. SecretManager-003: Enable Rotation Schedules for Secret Manager Secrets: AVTD includes a built-in secret rotation mechanism.

What are the potential rule failures related to Agentless Vulnerability and Threat Detection?

The new Guided Exclusions feature is automatically enabled by default to exclude AVTD resources and prevent failures from affecting the compliance and risk scores for your cloud accounts. For more information including disabling the exclusions, see: Managing preferences.
Potential Rule Findings for Excluded Resources
The following potential rule findings have been reviewed by Trend Micro team. When context of these resources is taken into account, these findings are not applicable and can be safely ignored:
The new Guided Exclusions feature is automatically enabled by default to exclude AVTD resources and prevent failures from affecting the compliance and risk scores for your cloud accounts. For more information including disabling the exclusions, see: Managing preferences.
Potential Rule Findings for Excluded Resources
The following potential rule findings have been reviewed by Trend Micro team. When context of these resources is taken into account, these findings are not applicable and can be safely ignored:
  1. Lambda-009: Enable Encryption at Rest for Environment Variables using Customer Managed Keys: AVTD resources are securely encrypted with default keys. In addition, the environment variables do not contain any secrets, so adding additional encryption using customer-managed keys is not required.
  2. SecretsManager-001: Secret Encrypted With KMS Customer Master Keys: AVTD resources are securely encrypted with default keys so adding additional encryption using customer-managed keys is not required.
  3. Lambda-001: Lambda Using Latest Runtime Environment: AVTD ensures that all our Lambdas use a Supported Runtime Environment with no End Of Life date. All supported runtime environments receive frequent security updates from AWS.
  4. Lambda-003: Lambda Tracing Enabled : AVTD ensures that this feature is throughly tested before the release hence this additional visibility via Enabling Tracing is not required.
  5. SecretsManager-002:Secret Rotation Enabled AVTD uses its own secrets feature instead of the one provided by AWS hence enabling the AWS provided Secret Rotation feature is not required.
  6. SecretsManager-003: Secret Rotation Interval AVTD uses its own secrets feature instead of the one provided by AWS hence enabling the AWS provided Secret Rotation feature is not required.
  7. S3-024: S3 Transfer Acceleration: The AVTD feature does not use the transfer acceleration feature.
  8. Lambda-006: Using an IAM Role For More Than One Lambda Function: AVTD employs a strategy called "permission planes” where Lambda functions that require identical permissions use a single IAM role. This ensures both efficiency and manageability when deploying to multiple regions e.g. reduction of the number of IAM roles used in a customer’s cloud account
  9. Lambda-007:VPC Access for AWS Lambda Functions: AVTD does not utilize resources like Redshift, ElastiCache, and RDS which may require a VPC implementation.
  10. CFM-001: CloudFormation Stack Notification: AVTD Cloudformation stack is already managed via V1 CAM instead AWS.
  11. CFM-002: CloudFormation Stack Policy: AVTD Cloudformation stack is already managed via V1 CAM instead AWS.
  12. CFM-005:CloudFormation Stack Termination Protection: In order to give customers control of the stacks in their environment, AVTD does allow users to deactivate and remove the stack from their account
  13. S3-025: S3 Buckets Encrypted with Customer Provided Keys CMKs: AVTD is already encrypted using S3-Managed Keys.
  14. SQS-006:SQS Dead Letter Queue: AVTD implements Dead Letter Queue (DLQ) in some of its SQS resources where applicable.
  15. S3-013: S3 Bucket MFA Delete Enabled: Objects stored in AVTD S3s are Objects are relatively short-lived hence enabling MFA Delete protection for accidental deletion is not required
  16. S3-023: Object Lock: Objects stored in AVTD S3s are relatively short-lived and hence Object lock for accidental deletion is not required.

Performance Parent topic

Related information

Performance troubleshooting Parent topic

Troubleshooting options for performance issues
Issue
Resolution or Cause
Compliance scan has caused my account to reach its rate limit
Manage performance issues by increasing the delay between Compliance scan runs
API throttling
Cloud Risk Management has optimised the platform to avoid unnecessary API calls. Examples of performance optimisation:1. when Cloud Risk Management calls the AWS API for S3 bucket list, the bot does not do repetitive calls, instead, the bot checks for changes only.2. Cloud Risk Management supports partial inventory. i.e. using partial lists of resources from AWS so the system is capable of dealing with partial calls e.g. S3 bucket list - secondary IP calls - if the bot fails to call second API calls, the rule engine will still work.3. Support for exponential backoff API.
If you experience any other issues, please let our team know via Cloud Risk Management support.