Architecture Overview
An in-depth overview of our architecture.
Architecture
The architecture seen below supports the object flow as described in the Object Scanning section both in a single region as well as across all regions supported. The Console region will have all components deployed to it. Any additional regions only require the scanning Agent(s) which will report back to the centrally located Console. In addition to this high-level architecture, you can get more details on routing and the public access required on the Deployment Details page.
Architecture - High-level Overview
ECS is the core of our application, which hosts 4 types of services.
The Console service is utilized for configuration of our product and provides the main communication to other AWS services. It also surfaces data from our product for user analysis.
The API Agent provides an endpoint where files can be sent and scanned before entering a storage volume.
The Event Agent scans files as they land into an S3 bucket by leveraging SNS and SQS.
The Scheduled & On-demand Agent scans pre-existing objects in a storage volume using Fargate Run Tasks.
Users and apps can log into our management console service through Cognito, or send files directly to our API scanning agent through a load balancer.
Objects can be uploaded either directly into the supported storage volumes or uploaded to S3 via our API Agent.
In AWS, we currently scan S3, EBS, EFS, and FSx.
Integrations are handled through our Console service.
The Console stores and reads configuration details from DynamoDB and Parameter Store, for example to ensure consistency when scaling agents or restarting tasks.
The Console logs all application activity in CloudWatch, which can be integrated with most SIEM tools.
ECS is the core of our application, which hosts 4 types of services.
The Console service is utilized for configuration of our product and provides the main communication to other AWS services. It also surfaces data from our product for user analysis.
The API Agent provides an endpoint where files can be sent and scanned before entering a storage volume.
The Event Agent scans files as they land into an S3 bucket by leveraging SNS and SQS.
The Scheduled & On-demand Agent scans pre-existing objects in a storage volume using Fargate Run Tasks.
Users and apps can log into our management console service through Cognito, or send files directly to our API scanning agent through a load balancer.
Objects can be uploaded either directly into the supported storage volumes or uploaded to S3 via our API Agent.
In AWS, we currently scan S3, EBS, EFS, and FSx.
Integrations are handled through our Console service.
The Console stores and reads configuration details from DynamoDB and Parameter Store, for example to ensure consistency when scaling agents or restarting tasks.
The Console logs all application activity in CloudWatch, which can be integrated with most SIEM tools.
To scan objects in regions separate from the Intial Deployment Region, we spin up Scanning Agents in that region to perform scans so the files never leave the region. Results are then sent back to the Console service.
All application information that takes place in secondary deployment regions are logged into that region's CloudWatch log groups.
ECS is the core of our application, which hosts 4 types of services.
The Console service is utilized for configuration of our product and provides the main communication to other AWS services. It also surfaces data from our product for user analysis.
The API Agent provides an endpoint where files can be sent and scanned before entering a storage volume.
The Event Agent scans files as they land into an S3 bucket by leveraging SNS and SQS.
The Scheduled & On-demand Agent scans pre-existing objects in a storage volume using Fargate Run Tasks.
Users and apps can log into our management console service through Cognito, or send files directly to our API scanning agent through a load balancer.
Objects can be uploaded either directly into the supported storage volumes or uploaded to S3 via our API Agent.
In AWS, we currently scan S3, EBS, EFS, and FSx.
Integrations are handled through our Console service.
The Console stores and reads configuration details from DynamoDB and Parameter Store, for example to ensure consistency when scaling agents or restarting tasks.
The Console logs all application activity in CloudWatch, which can be integrated with most SIEM tools.
To scan objects in regions separate from the Intial Deployment Region, we spin up Scanning Agents in that region to perform scans so the files never leave the region. Results are then sent back to the Console service.
All application information that takes place in secondary deployment regions are logged into that region's CloudWatch log groups.
For multiple accounts, the Console deploys a Cross Account Role with permissions so that CSS services can access and scan storage volumes from separate accounts. Note that scanning infrastructure remains in the primary AWS account where your Console was deployed. Similar to a multi-region deployment, CSS will spin up Scanning Agents in each region where data is scanned.
When linking an account in the CSS console, we deploy resources in the new CSS Resource Group created in Azure. Those resources will have access to the Blob Containers that reside within the linked Azure Account.
Once the Azure Account is linked, Azure Blob Containers will be made available to be scan through the CSS Console in the Protection > Azure Blob Containers page. You can select blob containers to scan or run scans on a schedule basis.
We offer two types of scanning for Azure: Event-Scanning and Retro Scanning.
Event-based scanning scans files as they drop into the Blob Container.
Users upload data to storage containers.
The storage account's system topic has an Event Grid Subscription tied to it that points to Azure Queue Storage as its event handler.
The Azure Queue Storage receives information about the object via the Event Grid Subscription.
The Container Application pulls information from the queue and scans the object that the notification refers to.
Results are tagged onto the object.
Results and metering are sent back to the CSS Console.
Retro-based scanning scans the entire Blob Container.
Users upload data to storage containers.
The Container Application runs a Crawl Job that evaluates the items to be scanned.
The Crawl Job places objects in Azure Queue Storage.
The Container Application pulls information from the queue and runs a Scan Job to scan the objects in the Queue.
Results and metering are sent back to the CSS Console.
Excluding the Event Grid Subscription, note that all of these resources and cross-permissions are only deployed inside of the CSS Resource Group through the Azure Resource Manager. The rest of the organizations and projects inside of your Azure account remain untouched.
When linking an account in the CSS console, we deploy resources in a new CSS Project created in GCP through our terraform module. Those resources will have access to the customer project(s) denoted in the deployments parameters (projects_to_protect).
Once the projects are linked, GCP buckets will be made available to be scan through the CSS Console in the Protection > GCP Buckets page. You can select buckets to scan or run scans on a schedule basis.
We offer Retro and Event-Based scanning for GCP.
Event-based scanning scans files as they drop into the GCP Bucket.
Users or apps place files into Google Cloud Storage.
The Pub/Sub service has a Topic set up to notify whenever new objects are created in designated Buckets.
The Cloud Run Job's subscription to the Topic activates whenever a new file is created.
The Cloud Run Job accesses the designated Bucket and loads that new object in memory to scan.
Files in the protected Bucket are tagged with their scan result.
(Optional) The Cloud Run Job will move infected files to a Quarantine Cloud Storage that resides in CSS' Project.
Results are returned to the Console service for processing.
Retro-based scanning scans the entire GCP Bucket.
Users or apps place files into Google Cloud Storage.
The Console Service initiates a scan request to the Cloud Run service that resides in CSS' Project that is provisioned via Terraform.
The Cloud Run Job accesses the customer's Cloud Storage and loads a list of its objects in memory, procedurally scanning each item.
Results are returned to the Console service for processing.
(Optional) The Cloud Run Job will move infected files to a Quarantine Cloud Storage that resides in CSS' Project.
All scan results are logged in AWS CloudWatch logs Agent.ScanResults, Problem Files are reported in the console, and objects in Google Cloud Storage are tagged with the scan result as well via the file metadata.
Note that all of these resources and cross-permissions are only deployed inside of the CSS Project through Terraform. The rest of the organizations and projects inside of your GCP account remain untouched.
Platform Services
While many services are used (ECS Fargate, App Config, CloudWatch, CloudFormation, DynamoDB, SNS, SQS, IAM) to deliver the Antivirus for Amazon S3 solution, two will be called out here. CloudWatch and IAM are leveraged for logging and permissions respectively. These are the usual questions we get from customers:
How do I check the logs?
What are you doing behind the scenes (permissions wise)?
We wanted to make sure you had those bases covered with the information below.
CloudWatch Log Group Overview
Log groups for the Console
Buckets
Logs of changes to bucket protection status and any errors that may occur while trying to turn on/off buckets.
EcsConfig
Logs of actions taken to enable or disable Agents in a region. This includes creation of clusters, task definitions, services, sns topics, sqs queues, quarantine buckets, and autoscaling policies.
RetroScan
Logs of when retro scanning starts and finishes per bucket as well as when queue entries are added.
System
Logs of general Console system information and errors and the return of the entitlement verification.
Log groups for the Agent
ScanConfig
Scan settings for the agent.
Settings include, but are not limited to:
Tags for the objects scanned
Actions taken on objects
Scan and skip lists
Bucket handling configuration
Classification Rules configuration for DLP
Note that the following snippet below has been shortened for brevity.
ScanStatistics
Every-hour statistics of an agents activity for each bucket being monitored. These include the number of files scanned, the number of clean/infected/error files, and the total bytes scanned.
Log groups for ECS
As of version 6.06 we enable ECS logging by default. These logs will be shown in the following log groups.
For each of these log groups you will see your seven character application ID in the title of each log group as noted below by the AppID between the ECS and type of ECS service the log is for.
IAM Permissions Review
We have been able to simplify the management and delivery of the solution such that there are very few tasks the administrator is required to perform inside the AWS Console. As a result, the Console and EventAgent have a number of permissions assigned to them within their respective roles to allow them to perform the actions needed on your behalf. In all cases, we went with a least privilege model wherever possible. There are a few instances where we have assigned * when it is required. Below you will find a review of the two IAM Roles we create and assign to the Console and scanning Agents.
Please review and Contact Us if you have any questions we can clear up for you.
The permission descriptions below follow the format:
Permissions Policies
Console Role
Console Role Customer Inline Policies
Console Role Customer Managed Policies
Scan Engines
Antivirus for Amazon S3 has been built in such a way that the underlying scanning engine can be exchanged with other scanning engines as needed or desired. There are three engines included out of the box:
Sophos - a well known enterprise solution that offers speed, great accuracy and large file scanning
ClamAV - a widely used open source antivirus engine for detecting trojans, viruses, malware & other malicious threats
CSS Premium - our latest scanning engine that can be used as either a primary scanning engine or as a secondary scanning engine to increase the efficacy of your scan
Agent checks every 15 minutes Vendor typically updates 4 times per day
195GB 5TB with extra large file scanning File Types
Faster engine; refer to Sizing Discussion
Signature Based
Yes
Agent checks every hour Vendor typically updates once per day
2GB File Types
Good performance engine; refer to Sizing Discussion
Signature Based
Yes
Agent checks every 15 minutes Typically updates one to four times per day
195GB through an ECS task 5TB with extra large file scanning File Types
Great performance; data to be released in the near future
Signature Based
Yes
Antivirus for Amazon S3 has the ability to use multiple scanning engines configured serially to ensure the highest level of efficacy and protection. Antivirus for Amazon S3 updates virus definitions as defined above as well as with each reboot / new spin up.
If you are a scan engine vendor and would like to partner with us to get your engine integrated into our solution or if you are a customer who would prefer another engine, please Contact Us.
Last updated