Currently we support Amazon Web Services (AWS), Azure, and Google Cloud Platform (GCP).

A full list of supported regions is available:

These are the permissions that File Storage Security management roles StorageStackManagementRoleARN and ScannerStackManagementRoleARN will have after File Storage Security has been deployed and configured:

For details on performance, see: Performance and scaling

For more information, see Performance and scaling

Yes. We support multiple stacks which can all be connected to the File Storage Security console. To deploy stacks, see Add stacks.

During stack deployment, the File Storage Security backend service configures the license to your scanner stack. This requires Azure permissions that can take up to 30 minutes to take effect according to Azure documentation. If you get this error message, try deploying the stack in the File Storage Security console a few minutes later.

For deployment information, see s3:ObjectCreated:* event in use.

For more information, see Deploy the all-in-one stack on AWS.

Yes, you can.

When you deploy from the template, you will need to get the corresponding External ID. If you modify it, the next update will rewrite the old one.

The bucketListener of Storage stacks is the producer of the queue. The producer needs to have the permission of the key to generate the encrypted message for the consumer (Scanner stacks). That is why both the Scanner Stack and the Storage Stack need `KMSKeyARNForQueueSSE` to make the encrypted process work as expected.

Here are the references to explain the KMS permissions for producers and consumers:

The KMSKeyARNForQueueSSE field has to be filled with the same value for both Scanner and Storage stacks if you want to encrypt the queue message.

It will not work if the KMSKeyARNForQueueSSE field is filled for only one of the Scanner stack or the Storage stack.

Please use the following link to see the minimum policy required of FSS deployment:

Yes, you can download the template and deploy with a service role. However, you must ensure that you are using the correct `external-ID`.

Please check whether the External ID of the stack's deployment parameter is the same as your Cloud One account. For information on finding the External ID, see Obtain an external ID. Update the stack if they're not matched.

If you tend to deploy stacks using APIs, we encourage you to refer to our documentation site for detailed steps to use APIs to deploy your stacks.

If you're not deploying stacks by CLI, please deploy the stack on FSS console to ensure the process and parameters are correct. For more information, see [Deploy the all-in-one stack](gs-deploy-all-in-one-stack-all.xml).

Sometimes the CloudFormation doesn't create the role properly. This can be due to an AWS service issue: https://github.com/aws/serverless-application-model/issues/2132

We have several suggested actions:

Try deploying the stack using another stack name. If the issue persists, export the stack events for the failed "Scanner Stack". (You need to click the "Scanner Stack" resource for getting the events of the Scanner Stack.)

One common root cause of the error "invalid license status" is, the stacks are deployed on AWS but did not submit to FSS backend to get valid license status for the stacks.

If you have more than one storage stack, every stack's StorageStackManagementRoleARN should be added to FSS backend. For more information, see Add stacks.

No, they aren't publicly accessible. You can review ScannerQueuePolicy defined in the scanner stack's template.

To see what AWS recommends, see Amazon SQS security best practices.

Enabling SSE for queues can be configured through the KMSKeyARNForQueueSSE parameter when deploying the scanner stack's template.

To see what AWS recommends, see Encryption at rest.

If the ScannerLambda property needs to be modified in the stack update, the customized memory size will be overwritten. You need to specify the customized memory size in the CFN template when performing the stack update.

The setting won't change if there is no specific change on Lambda's setting in our template, otherwise, the setting will be overwritten.

We recommend setting the customized settings like memory, or timeout, in the template before doing the stack update.

The Azure resources sometimes take time to update. For example, the role assignment sometimes may take at most 30 minutes to take effect. During that period, the blob listener cannot send scanning messages and will return an error. If this is the scenario that you encountered, please wait for a while and try uploading the files again.

You use the File-stores API. For more information, see File Storages.

You use the File-stores API. For more information, see File Storages.

According to GCP support, Safari prior to version 15 cannot operate GCP Cloud Console.

You can use Safari with version 15 or greater. If this is not possible, you can use GCP Cloud Shell for GCP operations.

This is a known issue of GCP Terraform provider. For a workaround, you can use the commands mentioned in terraform-google-secure-cicd.

No. Our current design does not allow you to configure files to be excluded from (or included in) scans.

AWS provides some default metrics that should be enough for monitoring the performance. Please try following the AWS documents to monitor SQS and Lambda used by FSS:

Lambda DLQ is not related to a scanning timeout issue. It is used for storing the messages that have failed to process due to a function code error or service error (like Lambda throttling). However, this type of error can already be monitored by CloudWatch metrics.

First, you can check the ScannerQueue's metrics in SQS page.

"Approximate Age Of Oldest Message" and "Approximate Number Of Messages Not Visible" indicate whether the messages are processed smoothly. If the numbers keep in high volume, it may be related to throttles on ScannerLambda.

If message volume continues to be high, continue to check the ScannerLambda's metrics.

If any throttles are observed, try following Best practices for working with AWS Lambda functions to make sure ScannerLambda has enough concurrency to process messages.

You can also check the log groups of ScannerLambda and ScannerDeadLetterLambda to see if there is any error log.

File Storage Security uses Smart Scan Agent Pattern, IntelliTrap Exception Pattern and IntelliTrap Pattern.

Smart Scan Agent Pattern (icrc$oth.XXX) is used for Heuristic/Generic detection, too. It can also detect known ransomware such like RANSOM_HPLOCKY.SM4.

Only a partial download is done on the file when scanning.

The Smart Scan (iCRC) only uses and encrypts the input hash value that is received from the scan engine. This value is not calculated from the whole file content.

The functions in the deployed stacks require certain permissions to retrieve scanning events and publish scan results. These permissions can take up to 30 minutes to take effect according to Azure documentation. To mitigate the issue, try uploading the files and monitoring the scan results a few minutes later.

No. Only identification information is sent to the Trend Micro Global Smart Protection Server.

File Storage Security can scan SSE-KMS but cannot scan client-side encrypted files.

Yes.

Every networking error regarding to retrieving the file via a presigned URL results in a network module related error.

In the scanner's logs, we can detected scan messages that in the scanner queue for more than 1 hour:

The SAS tokens for the scanner to retrieve files are available for 1 hour only. The scanner got a 403 error when attempting to get the file because the SAS token had expired.

The default instance count for the scanner function app is 1. When large amounts of messages are uploaded to the scanner in a short time period, delays in processing the messages may occur. To mitigate the issue, go to the Scale out (App Service plan) page in the function app, and follow the Azure Functions Premium plan to increase Maximum Burst of Plan Scale out setting. The maximum is 20. It can reduce the time that the messages stay in the queue.

It may help to examine our basic performance test regarding of the setting: Azure performance and scaling.

In some rare cases, there might be networking issue in the cloud environment that causes the scan to fail. We suggest that you retry such failed scans by subscribing to the scan result topic with a post scan action function. The function can filter all successful scans and send scan messages for all scan failed files to the scanner queue to trigger the scan.

To parse the scan result, please refer to Scan result format. The BlobListener function in the storage stack can be used to send scan messages to the scanner queue.

No, the design of AWS S3 does not allow you to determine from the result of an upload request whether an uploaded file is malicious.

The result is available to you after the scan is finished.

We recommended that you implement a Post Scan Action to move the malicious file to a quarantine bucket for this case. For more information, see https://github.com/trendmicro/cloudone-filestorage-plugins/tree/master/post-scan-actions/.

Yes, you are correct. S3 "fss-scan-result" tag: "failure" = FSS console: "Scan Error". Yes, the S3 "fss-scan-result" tag: "failure" is equivalent to the FSS console: "Scan Error". The "Scan Error" on FSS web console comes from the results of List scan statistics API (the "failed" key in API response). A file that was scanned and has the tag “fss-scan-result” : “failure” will be included in the number of failed scans.

For the failed scans, please refer to "scanner_status and scanner_status_message" section in FSS online docs.

Yes. Out-of-box, File Storage Security tags a malicious file with a `malicious` tag, and no further action is taken. After that you can create actions based on the tag assigned to the file.

See the post-scan action sample code GitHub page for actions that can be taken after the scan.

When a file is scanned and found to be malicious, File Storage Security tags it as `malicious` and returns it to the S3 bucket to scan. For details on tagging, see View tags.

Please help us by submitting a new ticket to AM team by leveraging the Threat Investigation Portal (TIP).

The count may not match because ScannerLambda will retry a failed scan once. This means that if the Lambda failed to scan the first time, it will retry the scan the second time.

The Lambda publishes a message about scan failure after both attempts have failed. However, every invocation of ScannerLambda will report the scan result to the FSS backend once.

The Trend Micro backend service pushes malware patterns, the license, and Lambda code updates.

Patterns can be updated multiple times a day. The patterns, which are updated as Lambda layers, are about 30 to 40MB in size. Please note that the pattern update will not retry the failed update until the next pattern is released.

To see the revision history for a template, go to our repository on GitHub.com and click the Blame button to see that view.

Stacks have no expiration date, but we strongly recommend that you use the latest version.

For upgrade instructions, see Update stacks.

Currently, there are three kinds of updates:

• Lambda code. Currently, there are three Lambda functions in scanner and storage stacks to update. File Storage Security backend updates BucketListenerLambda and PostScanActionTagLambda in storage stacks, and ScannerLambda in scanner stacks as well. The Lambda code change is published in What's New.
• Malware patterns in Lambda layer. File Storage Security backend pushes the latest malware pattern to your ScannerLambda.
• Scanner license. File Storage Security backend updates the license residing in ScannerLambda every week. If you remove your scanner stack from the File Storage Security console, the license will expire and fail to scan four weeks later.

Using a Stack that has not been updated may result in update failures, data inconsistency occurrences, support expiration, and other problems.

No, Lambda's memory settings and log retention period are within the scope of Stack Update.

If the Lambda is deployed by FSS (for example, PostScanActionTagLambda, or BucketListenerLambda), it will be automatically updated by FSS backend. The update might relate to bug-fixing, or some new features. So it cannot be avoided.

We recommend that you do not modify the code of any Lambda functions in the scanner or storage stacks. For more information, see Customizing AWS stacks.

No, you cannot roll back a stack update.