Console Settings
The Console Settings page is used to make modifications to the console characteristics
Last updated
The Console Settings page is used to make modifications to the console characteristics
Last updated
This includes the CPU and Memory it is running with, the VPC and Subnets it is running within as well as the access URL you leverage to reach the console. Also included on this page is useful information about this particular deployment.
It is often useful to know the details of how the particular console you are in came about. Which stack did this console get deployed from? Where is it running? What is the unique service name? etc. Whether this is for your own purposes to explore within your AWS account or whether it is to get support from Cloud Storage Security, these data points are helpful. The Console Information section does just that. It gives you your current Subdomain, the CloudFormation Stack Name used to deploy, the uniquely generated Service Name and the AWS Region the console is deployed in.
AWS Security Hub provides a consolidated view of your security status in AWS. Automate security checks, manage security findings, and identify the highest priority security issues across your AWS environment. Antivirus for Amazon S3 has integrated with AWS Security Hub to allow your Amazon S3 object findings (malware and viruses) to be posted to this central location. Any infected files found within your Amazon S3 storage can be shown and managed alongside the rest of the findings coming from all other aspects of your infrastructure.
It is very simple to start sending infected scan results to AWS Security Hub. Simply toggle the switch on (becomes purple and text changes from Disabled to Enabled) and Antivirus for Amazon S3 will activate Accept Findings inside of AWS Security Hub and immediately start sending findings. You will not have to manually accept, although you can, the findings service inside the AWS Console. If you do happen to accept the service beforehand, you will still need to toggle inside the Antivirus for Amazon S3 console.
Antivirus for Amazon S3 expects AWS Security Hub to be subscribed to in the region the console is running within.
Any incident found, no matter the region, will be posted to the console region's AWS Security Hub.
Let us know if you'd like the findings written out to the region they were found in.
Flipping the toggle to enabled when AWS Security Hub is not subscribed to will be reflected with an error.
If you Stop Accepting Findings for the Antivirus for Amazon S3 service inside the AWS Security Hub console, but do not also disable it in the Antivirus for Amazon S3 settings, we will continue to try to send events and errors will be sent to logs.
This integration allows you to send notifications to EventBridge, usually used by customers that need to monitor results and stream the data somewhere else (e.g.: AWS Kinesis). Find setup instructions and examples here.
This field specifies the Tag Name to look for on a bucket to automatically turn on event-based protection for that bucket. The bucket catalog is refreshed every 30 minutes. During this refresh we will look for this tag and if present (currently values do no matter) we will protect the bucket. You can change this to any Tag Name you'd like.
Bucket Protection will be turned on when this tag is found. If you have disabled bucket protection from the console on the Bucket Protection page, at the next 30 minute catalog refresh protection will be turned back on. If you do not want this bucket to be protected again, you will need to remove this tag.
This should be part of the consideration when determining to use existing tag names or creating a custom one.
We don't currently use the tag value in any real way, so the presence of the tag alone will trigger the protection.
When using tag triggered protection any bucket in any region with the defined tag will be protected. If you do not have the region(s) pre-configured with networking setup then protection cannot be enabled. You must pre-configure or stage the regions you will be protecting buckets in.
Use the Event Agent Settings page to stage any/all regions where automatic protection may take place.
In order to give you a secure and consistent experience with how you access the Console, Cloud Storage Security has implemented a subdomain registration process on your behalf. By default, we create a subdomain that is made up of your AWS account ID - AppID. With this we generate an access URL to the Management Console consisting of <accountID-appID>.cloudstoragesecapp.com. This is shown to you in the Stack Outputs after completing the CloudFormation Template stack create. You are welcome to continue with this URL for as long as you use the product. But, we have seen with some customers they would prefer something more meaningful and relevant to their organization.
This management page is to allow you to do just that. Pick a value that is useful and meaningful to you. Check the availability just in case it is being used. If your value is unique, the Save button will be enabled. Clicking Save will replace the value with your new value.
External inbound access to the Console is controlled through an AWS Security Group (identified by the name CloudStorageSecConsoleGroup-)d
Tagging your resources within AWS is crucial for maintaining well-organized and manageable cloud infrastructure. By applying descriptive tags to your resources, you gain the ability to categorize, search, and filter based on specific criteria. The System Tags feature allows you to apply your own custom tags to the resources deployed by Cloud Storage Security within your AWS environment.
To use this feature, simply add the Tag Key(s) and Tag Value(s) that you would like added to your resources and click the Apply Tag Changes button. The console will initiate the update to apply the tags across your resources.
You can also delete your custom tags from this same menu by clicking the trash icon next to any added tag you would like removed. Be sure to click the Apply Tag Changes button to save and apply your changes.
Note
It will take a few minutes for these changes to be applied within AWS. We recommend that you apply all of your tag updates at once, or wait 5-10 minutes between updates to ensure all tags are applied appropriately.
The tags that you enter must adhere to AWS tag naming limits and requirements:
The tag key must be a minimum of 1 and a maximum of 128 characters.
The tag value must be a minimum of 1 and a maximum of 256 characters.
In general, the allowed characters are letters, numbers, spaces representable, and the following characters: _ . : / = + - @.
Tag Key cannot start with 'aws:'.
The Task Settings apply to the actual AWS Fargate Task (container) running the console. The default settings within the CloudFormation Template are to run the console with .5vCPU and 1GB of Memory. This is suitable in most cases and certainly when you get started. As your data sets grow and you do more with it as well and if you have large numbers of existing objects you plan to retro scan regularly, you may find that bumping these numbers will help your console run more smoothly. You selected a VPC and two subnets to run the console in during the CloudFormation deployment. There may be times you'd like to change these values after the fact and this section makes it very easy to do so.
This section is to allow you to easily modify the running values of the console.
You'll notice a Public or Private associated with each VPC. This is an indicator of whether or not the VPC is tied to an Internet Gateway. Thought process being that with an IG in place you will have the required outbound access. The console does not require a public IP address or to be accessible from the public in general, but it does require outbound internet access to get to AWS ECR to pull new Task images.
You'll notice a Public or Restricted associated with each Subnet. This is an indicator of whether or not the Subnet is outbound routable to the internet. Minimally, the agent task must be able to reach the AWS ECR to pull new Task images and to be able to pull AV signature updates. Two validations are performed for this check. First, we check to see if the NACL associated with the Subnet(s) has outbound open for 0.0.0.0/0. Secondly, we check to see if there is a custom Route Table in place and verify it is routed to an internet gateway.
Generally, the first indicator for a good configuration will be whether or not the VPC has an internet gateway or something that is taking its place. Secondly, check the subnets for their outbound access.
Changing these values will cause the console to reboot.
If the VPC or Subnets are not proper for the console, you could have trouble reaching the console.
Retro Scanning starts by crawling the objects in a given bucket(s) for a given time period. Crawling performance will be impacted by the specs (mainly vCPU) of the Console container. The default specs of .5vCPU will crawl one million objects (spread across 4 buckets in our testing) in about 4 minutes. A console with 2vCPU crawled the same one million objects in ~70 seconds. Extrapolate that out over 10s of millions or billions of objects and it can make a significant difference. We will be providing a mechanism to dynamically change the console specs for the duration of the crawl, but in the mean time please make adjustments to the specs here.
