AWS Service Configuration

The following page provides details on the configuration of specific AWS services for use with InsightCloudSec. Since there are dozens of services this page is not exhaustive. If you have specific configuration requirements or questions reach out to us through the Customer Support Portal.

S3 Buckets (Storage Containers)

Harvesting Cadences

Due to the global scope, count, and scale of S3 buckets, we recommend that the harvest cadence for Storage Containers be no less than 30 minutes.

Impaired Visibility

Customers using AWS will have improved visibility warnings if an S3 bucket’s properties are unable to be harvested due to an overly restrictive bucket policy.

While there are multiple policy possibilities that can prevent complete harvesting of an S3 bucket, here's an example policy that will show as impaired in InsightCloudSec:

{
    "Version": "2008-10-17",
    "Statement": [
        {
            "Sid": "DenyAll",
            "Effect": "Deny",
            "Principal": "*",
            "Action": [
                "s3:GetBucketLogging",
                "s3:GetBucketPolicy",
                "s3:GetEncryptionConfiguration"
            ],
            "Resource": "arn:aws:s3:::myimpairedbucket"
        }
    ]
}

Because the bucket policy denies all principals, InsightCloudSec won't be able to harvest the bucket logging, policy, or encryption statuses.

This will surface like this in the UI:

Other Causes

In addition to the policy example above other possible causes include:

• inability to get the bucket location
• inability to get the bucket ACL
• inability to get IAM policy details
• inability to get versioning config
• inability to get static website config
• inability to get lifecycle policy config
• inability to get encryption settings

To get more information about what specific call(s) failed, you can run sudo docker-compose logs | grep "Unable to retrieve" | grep "yourbucketname" on the instance you have running InsightCloudSec.

Note: Don't forget to update the command with your unique bucket name.

❗️

Recommend Bot Remediation

When using custom insights and bot actions on storage containers, it's recommended that the condition of Storage Container Without Impaired Visibility be applied. This prevents a bucket's policy from being overwritten when InsightCloudSec sees it as not having one.

For visibility and reporting, you can use the filter "Storage Container With Impaired Visibility" to alert you when there's a bucket policy in place that prevents visibility for InsightCloudSec.

Elastic Beanstalk

InsightCloudSec includes support and visibility for AWS Elastic Beanstalk that includes filter and enhanced insight into both Elastic Beanstalk Applications and Environments. These details will appear under "Compute --> WebAppGroup".

AWS Elastic Beanstalk can include many instances, ASGs, etc., linked to a given environment. The following resource types are supported by InsightCloudSec and can be linked to an environment:

• Instances
• Auto Scaling groups
• Launch configurations
• Load balancers
• Queues

📘

AWS Read Permissions

The new extensive set of AWS read permissions required are available here.

InsightCloudSec includes a data point for WebApps: automatic_patching. It is exclusive to AWS Beanstalk and tracks whether or not Managed Actions are enabled. To support Beanstalk resources we added the following filters:

• Instance Managed By Web App
• Web App With Automatic Patching Enabled
• Web App With Automatic Patching Disabled

With Beanstalk you can have multiple runtime versions so we added a new column on the resources page to display this information.

Permissions

When Beanstalk make sure that you have given InsightCloudSec the proper permissions for all the supported resources (see list below) used by your Beanstalk app/environment.

🚧

New AWS Elastic Beanstalk permissions:

• elasticbeanstalk:DescribeApplications
• elasticbeanstalk:DescribeEnvironments
• elasticbeanstalk:DescribeEnvironmentResources
• elasticbeanstalk:DescribePlatformVersion