Policy Templates for AWS
This table lists the Policy Templates provided for use with AWS.
For Policy Templates for Amazon ECS, EKS, Google Kubernetes Engine (GKE), and Azure Kubernetes Services (AKS), and AWS Fargate, see Policy Templates for Container Security.
For response actions, see Auto-Remediation of AWS Incidents.
For instructions on how to find Policy templates that are new or updated due to changed recommendations, see Find New and Updated Policy Templates.
|
Policy Name |
Resource/ |
Skyhigh CASB Recommended |
CIS v1.2.0 Level 1 |
CIS v1.2.0 Level 2 |
CIS v1.3.0 Level 1 |
CIS v1.3.0 Level 2 |
CIS v1.4.0 Level 1 |
PCI DSS v3.2 |
HIPAA |
NIST 800-53 Rev4 |
Policy Description |
|---|---|---|---|---|---|---|---|---|---|---|---|
| IAM user should have only one active access key | User | 1.13 | 164.308(a)(4) | Access keys are long-term credentials for an IAM user or the AWS account 'root' user. You can use access keys to sign programmatic requests to the AWS CLI or AWS API. One of the best ways to protect your account is to not allow users to have multiple access keys. | |||||||
| AWS IAM should not have expired SSL/TLS certificates | AWS IAM Server Certificate | 1.19 | 4.1.1, 4.2 | 164.308(a)(3) | Removing expired SSL/TLS certificates eliminates the risk that an invalid certificate will be deployed accidentally to a resource such as AWS Elastic Load Balancer (ELB), which can damage the credibility of the application/website behind the ELB. As a best practice, it is recommended to delete expired certificates. | ||||||
| IAM Access Analyzer should be enabled in all regions | AWS Region | 1.20 | AWS IAM Access Analyzer helps you identify the resources in your organization and accounts, such as Amazon S3 buckets or IAM roles, that are shared with an external entity. | ||||||||
| S3 Bucket Policy should deny HTTP Request | S3 | By default, Amazon S3 allows both HTTP and HTTPS requests. To achieve only allowing access to Amazon S3 objects through HTTPS you also have to explicitly deny access to HTTP requests. | |||||||||
| Network ACLs should not have unrestricted SSH access | AWS Network Acl | 5.1 | 1.2.1, 1.1.6, 1.3.4, 1.3.5 | 164.312(e)(1) | Public access to remote server administration port 22, increases the resource attack surface and unnecessarily raises the risk of resource compromise. | ||||||
| Network ACLs should not have unrestricted Remote Desktop access | AWS Network Acl | 5.1 | 1.2.1, 1.1.6, 1.3.4, 1.3.5 | 164.312(e)(1) | Public access to remote server administration port 3389, increases the resource attack surface and unnecessarily raises the risk of resource compromise. | ||||||
| Default Security Group of every VPC should restrict all traffic | Security Group | 5.3 | 1.2.1, 1.1.6, 1.3.4, 1.3.5 | 164.312(e)(1) | Configuring all VPC default security groups to restrict all traffic will encourage least privilege security group development and mindful placement of AWS resources into security groups which will in-turn reduce the exposure of those resources. | ||||||
| Root account access key should not exist | IAM | Level 1 | 1.12 | 1.4 | 164.312(a)(2)(i), 164.312(e)(1) | Using access keys with the root account is a direct vector of account compromise. Anyone who gets access to the key has access to all the services in the AWS account. Creating role based accounts with appropriate privileges and access keys is the recommended best practice. | |||||
| CloudTrail trails should be integrated with CloudWatch logs | CloudTrail | Level 1 | 2.4 | 3.4 | 164.312(e)(1) | With this integration, real-time and historic activity logging based on user, API, resource, and IP address is facilitated. It also enables an opportunity to establish alarms and notifications for anomalous or sensitive account activity. | |||||
| CloudTrail logging should be enabled for the account | CloudTrail | 10.2 | 164.308(a)(1)(ii)(D), 164.312(a)(2)(i), 164.312(c)(2) | CloudTrail provides a history of AWS API calls for an account, including API calls made via the Management Console, SDKs, command line tools, and higher-level AWS services (such as CloudFormation). This enables security analysis, resource change tracking, and compliance auditing. | |||||||
| CloudTrail logging should be enabled for multi-regions | CloudTrail | Level 1 | 2.1 | 3.1 | 164.312(b) | CloudTrail provides a history of AWS API calls for an account, including API calls made via the Management Console, SDKs, command line tools, and higher-level AWS services (such as CloudFormation). This enables security analysis, resource change tracking, and compliance auditing. Additionally, ensuring that a multi-regions trail exists will ensure that unexpected activity occurring in otherwise unused regions is detected. | |||||
| EC2 instance should belong to a VPC | EC2 | 1.1.7, 1.2, 1.3, 2.4, 1.1.4 | Checks whether your EC2 instances belong to a Virtual Private Cloud (VPC) which is logically isolated to your AWS account. This allows controlling the outbound traffic from your instances (egress filtering) in addition to controlling the inbound traffic to them (ingress filtering). It also allows to add an additional layer of access control to your instances in the form of network access control lists (ACL). | ||||||||
| Hardware MFA should be enabled for the root account | IAM | Level 1 | 1.14 | 1.6 | Secure access to your AWS resources by ensuring hardware MFA is enabled for your root account. A hardware MFA has a negligible attack surface and cannot be hacked unless the malicious user gain physical access to the hardware device. | ||||||
| MFA Delete should be enabled on S3 buckets | S3 | 8.3 | Ensure that your S3 buckets are using MFA Delete feature which requires additional authentication for either versioning change of bucket or permanent deletion of an object version operations. | ||||||||
| MFA should be enabled for root account | IAM | Level 1 | 1.13 | 1.5 | 164.312(e)(1) | Enabling MFA for the root account provides increased security for console access as it requires the authenticating principal to possess a device that emits a time-sensitive key and have knowledge of a credential. | |||||
| IAM instance roles should be used to provision access to AWS resources | EC2 | Level 1 | 1.19 | 1.18 | Provisioning access to resources using IAM roles is recommended versus providing individual set of credentials to access. This ensures that credentials are not lost or misplaced accidentally, leading to account compromise. | ||||||
| The S3 bucket used to store CloudTrail logs should not be publicly accessible | CloudTrail | Level 1 | 2.3 | 3.3 | 10.2.3, 10.5.2, 1.2.1 | Risk of unauthorized access or account compromise increases with unrestricted access to CloudTrail logs. | |||||
| Non HTTP/HTTPS ports should not have unrestricted access | EC2 | 1.1.7, 1.2, 1.3, 1.2.1 | Ensure that only ports 80 and 443 can be accessed publicly. Unrestricted access could lead to unauthorized access to data or lead to an accidental breach. | ||||||||
| Security Groups should not have unrestricted CIFS access | EC2 | Level 2 | 1.2.1 | If you are using DNS, ensure that access through port 53 is restricted to required entities only. | |||||||
| Security Groups should not have unrestricted DNS access | EC2 | Level 2 | 1.2.1 | If you are using DNS, ensure that access through port 53 is restricted to required entities only. | |||||||
| Security Groups should not have unrestricted FTP access | EC2 | Level 2 | 1.2.1 | Ensure that access through port 20/21 (FTP) is restricted to required entities only. FTP is a commonly used protocol for sharing data. Unrestricted access could lead to unauthorized access to data or lead to an accidental breach. | |||||||
| Security Groups should not have unrestricted ICMP access | EC2 | Level 2 | 1.2.1 | Ensure that access for ICMP is restricted to required entities only. Unrestricted access could lead to unauthorized access to data as attackers could use ICMP to test for network vulnerabilities or employ DDOS against your infrastructure. | |||||||
| Security Groups should not have unrestricted inbound access on uncommon ports | EC2 | Best Practice | 1.2.1 | Allowing unrestricted inbound access to uncommon ports can increase opportunities for malicious activity such as hacking, data loss and all multiple types of attacks (brute-force attacks, Denial of Service (DoS) attacks, etc). | |||||||
| Security Groups should not have unrestricted MySQL access | EC2 | Level 2 | 1.2.1 | If you are using MySQL, ensure that access through port 3306, used for MySQL, is restricted to required entities only. | |||||||
| Security Groups should not have unrestricted NetBIOS access | EC2 | Level 2 | 1.2.1 | If you are using NetBIOS, ensure that access through port 139 (TCP) and 137/138 (UDP) are restricted to required entities only. | |||||||
| Security Groups should not have unrestricted outbound access | EC2 | Level 2 | 1.2.1 | Outbound access from ports must be restricted to required entities only such as specific ports or specific destinations. | |||||||
| Security Groups should not have unrestricted Remote Desktop access | EC2 | Level 1 | 4.2 | 5.2 | 1.2.1, 1.1.6, 1.3.4, 1.3.5 | 164.312(e)(1) | If you are using Remote Desktop, ensure that access through port 3389, used for Remote Desktop, is restricted to required entities only. | ||||
| Security Groups should not have unrestricted RPC access | EC2 | Level 2 | 1.2.1 | If you are using RPC, ensure that access through port 135, used for RPC, is restricted to required entities only. | |||||||
| Security Groups should not have unrestricted SMTP access | EC2 | Level 2 | 1.2.1 | If you are using SMTP, ensure that access through port 25, used for SMTP, is restricted to required entities only. Unrestricted SMTP access can be misused to spam your enterprise, DDOS, etc. | |||||||
| Security Groups should not have unrestricted SSH access | EC2 | Level 1 | 4.1 | 5.2 | 1.2.1, 1.1.6, 1.3.4, 1.3.5 | 164.312(e)(1) | If you are using SSH, ensure that access through port 22, used for SSH, is restricted to required entities only. | ||||
| Security Groups should not have unrestricted Telnet access | EC2 | Level 2 | 1.2.1 | If you are using Telnet, ensure that access through port 23, used for Telnet, is restricted to required entities only. | |||||||
| EC2 instance should not use default security group | EC2 | 1.1.7 | Default Security Group allows all inbound traffic from other instances associated with the default security group. It also allows all outbound traffic from the instance. | ||||||||
| S3 buckets should not be world readable | S3 | Best Practice | 164.312(a)(1), 164.308(a)(4)(i), 164.308(a)(4)(i) | Risk of unauthorized access or loss of customer data increases with an S3 bucket that grants READ (LIST), READ_ACP (VIEW PERMISSIONS) access to everyone or AWS signed users. Malicious users can exploit the information acquired through the listing process to find objects with misconfigured Access Control Lists (ACLs) permissions and access these compromised objects. This is a Skyhigh recommended best practice. | |||||||
| Resources should always be tagged | All | Best Practice | A tag is a label that you assign to a resource. Each tag consists of a key and an optional value, both of which you define. Tags enable you to categorize your resources in different ways, for example, by purpose, owner, or environment. Ensure that user-defined tags (metadata) are being used for labelling, collecting and organizing resources available within your environment. | ||||||||
| KMS keys should not be scheduled for deletion | KMS | Best Practice | Deleting a Key Management Service (KMS) CMK prevents all associated encrypted data from later being decrypted. Disabling, rather than deleting, a KMS/CMK allows users with access to the key to re-enable it and recover encrypted data in the future.. | ||||||||
| CloudFront Distribution should use secure ciphers | CloudFront | Best Practice | 4.1, 2.3, 2.2.3 | 164.312(a)(2)(iv), 164.312 (e)(1), 164.312(e)(2)(ii) | CloudFront, a content delivery network (CDN) offered by AWS, is not using a secure cipher for distribution. It is a best security practice to enforce the use of secure ciphers TLSv1.1 and TLSv1.2 in a CloudFront Distributions certificate configuration. This policy scans for any deviations from this practice. | ||||||
| AWS account should not have single IAM admin | IAM | Best Practice | IAM Administrator roles should never reside on only one individual's IAM account. The risk of that individual losing access to those credentials, through a variety of possibilities, creates undue risk for an organization.There should be at least two IAM Admins configured to prevent a Single-Point-of-Failure (SPoF) | ||||||||
| SQS should not have cross account access | SQS | Best Practice | Recommended best practice is for SQS queues to not support cross-account access if the list account IDs are on another account or if the access is exposed to everyone. This policy scans any violation to this. | ||||||||
| Lifecycle configuration should be applied to S3 buckets | S3 | 3.1 | Checks if lifecycle configuration is applied to S3 buckets which allows you to manage your objects so that they are stored cost effectively. These rules define ‘Transition’ or ‘Expiration’ actions that Amazon S3 applies to a group of objects. | ||||||||
| Access Logging should be enabled for ELB | ELB | Best Practice | 164.308(a)(1)(ii)(D), 164.312(c)(2), 164.312(e)(1), 164.312(b) | AU-2a, AU-8a, AU-8b | Enabling ELB access logging will allow ELB to record and save information about each TCP and HTTP request made. The access logging data can be extremely useful for security audits and troubleshooting sessions. For example your ELB logging data can be used to analyze traffic patterns in order to detect different types of attacks and help implementing custom protection plans. | ||||||
| IAM policies should be attached to groups and roles only | IAM | Level 1 | 1.16 | 1.15 | IAM Policies are recommended to be associated with groups or roles only. This prevents the risk for users to get excessive permissions or privileges accidentally, in large enterprise deployments. | ||||||
| Access keys should not be unused | IAM | Best Practice | 8.1.4 | Unused access keys minimize the risk aperture of an enterprise to a compromised account or Insider threat. It is highly recommended that any access keys unused for over 30 days be terminated. | |||||||
| AWS account should not have unused IAM users | IAM | Level 1 | 1.3 | 1.12 | Removing unused IAM users can reduce the risk of unauthorized access to your AWS resources, help you manage the user-based access to the AWS Management Console more efficiently and is a recommended best practice. | ||||||
| AWS account should not have unused SSH public keys | EC2 | Best Practice | Lower the risk of unauthorized access to your data using SSH from unrestricted locations by deleting unused SSH Public Keys. | ||||||||
| Last restorable time should be configured for RDS | RDS | Best Practice | The Amazon RDS automated backup feature automatically creates a storage volume snapshot of your DB instance, backing up the entire DB instance and not just individual databases.You can restore to any point in time during your backup retention period. The latest restorable time for a DB instance should be typically within 5 minutes of the current time.. | ||||||||
| Backup retention period for RDS should be sufficient | RDS | 3.1 | Longer backup retention periods might be required for compliance purposes. If the maximum retention period for automated backups is greater, it enables you to store more and hence recover your database to any point in time during the backup retention period. | ||||||||
| CloudTrail log file validation should be enabled | CloudTrail | 2.2 | 3.2 | 10.5.5 | 164.312(b) | Validated log files are invaluable in security and forensic investigations. Determine whether a log file was modified, deleted, or unchanged after CloudTrail delivered it. | |||||
| AWS CloudFront CDN should be used | CloudFront | Best Practice | The AWS account is not currently leveraging any CloudFront distributions. CloudFront provides scalable, distributed, and inexpensive Content Distribution Network (CDN) within AWS. Using a content delivery network (CDN) can provide a layer of security between your origin content and its destination. CDNs can ensure consistent delivery of content during a distributed denial of service (DDoS) attack or unexpected increase in traffic volume by providing you time to scale infrastructure to meet traffic demands or helping to identify the origin and mitigate the risk of an attack. | ||||||||
| AWS Config should be enabled in all regions | AWS Account | 2.5 | 3.5 | 2.2 | The AWS Config service provides visibility to user configuration history and configuration change notifications. Along with use of CloudTrail, we consider enabling AWS Config to be a best practice for users. | ||||||
| AWS DNS service should not be used | AWS Account | Best Practice | Using DNS resolution on VPC gives Amazon provided host names to all the instances behind it. Turn this OFF if that is not desired and specific host names are needed | ||||||||
| EC2 instances should not reach regional limit for elastic IP addresses | AWS Account | Best Practice | The EC2 instance is nearing the regional limit for allowed elastic IP addresses. | ||||||||
| RDS event notification subscription should be enabled | RDS | Best Practice | An Amazon RDS event notification subscription can be created to be notified when an event occurs for a given DB instance. This policy checks to see if RDS event subscription DB instance sourcetype is enabled and active. | ||||||||
| Object versioning should be enabled for S3 buckets | S3 | Best Practice | 164.312(c)(1), 164.312(c)(2) | SC-28 | Verify if object versioning is enabled on your S3 buckets. | ||||||
| Access logging should be enabled on the CloudTrail S3 bucket | CloudTrail | Level 1 | 2.6 | 3.6 | 10.2.3 | 164.312(e)(1) 164.312(b),164.312(c)(2) | AC-2g | CloudTrail buckets contain sensitive information. These should be protected from unauthorized viewing. With S3 Server Access Logging enabled for your CloudTrail buckets, you can track any requests made to access the buckets or even limit who can alter or delete the access logs to prevent a user from covering their tracks. S3 Bucket Access Logging generates a log that contains access records for each request made to your CloudTrail S3 bucket. | |||
| CloudTrail logs should be encrypted at rest | CloudTrail | Level 1 | 2.7 | 3.7 | SC-28 | Ensure that CloudTrail logs are encrypted at Rest to minimize the risk of unauthorized access. | |||||
| CloudTrail logs should be encrypted with CMKs | CloudTrail | Level 2 | 2.7 | 3.7 | 2.7, 3.5 | 164.312(e)(1) | Ensure that CloudTrail logs are encrypted with Customer Master Key (CMK) to minimize the risk of unauthorized access. | ||||
| RDS should be encrypted | RDS | Best Practice | 3.4 | 164.312(a)(2)(iv), 164.312 (e)(1), 164.312(e)(2)(ii) | SC-28,SC-13 | To be compliant with data at rest encryption policies, ensure that your database is being encrypted. | |||||
| EBS should be encrypted | EBS | Best Practice | 2.2.1 | 2.2.1 | 3.4 | To be compliant with data at rest encryption policies, ensure that your data volumes and snapshots are being encrypted. | |||||
| EC2 security group should have inbound access configured to specific IP addresses | EC2 | Best Practice | Ensure that excessive permissions to access EC2 instances is not specified, such as using RFC 1918 to whitelist large ranges of IP Addresses. Only specific Private IP Addresses must have inbound access. | ||||||||
| EC2 security group should have specific ports configured | EC2 | Best Practice | Ensure that ranges of ports are not open on your EC2 security groups. Leaving large ranges of ports open leads to vulnerabilities potentially being exposed. In addition, attackers can scan ports and expose vulnerabilities of applications hosted without easy traceability due to large port ranges being open. | ||||||||
| CloudFront Distribution should use HTTPS protocol | CloudFront | Best Practice | 4.1 | 164.312(a)(2)(iv), 164.312 (e)(1), 164.312(e)(2)(i), 164.312(e)(2)(ii) | If you are using CloudFront, ensure that CloudFront distributions use HTTPS. This ensures all traffic to and from CloudFront is encrypted and minimizes the risk of MITM. | ||||||
| IAM access keys should be rotated periodically | IAM | Best Practice | 1.4 | 1.14 | 164.312(e)(1), 164.312(d) | Rotating AWS IAM access keys reduces the risk of compromised credentials or malicious insiders using stale credentials to exfiltrate or misuse sensitive data. | |||||
| IAM users should not have multi-mode access | IAM | Best Practice | IAM users must be enabled for either API Access or for Console Access to reduce the risk of unauthorized access in case their credentials (access keys or passwords) are compromised. Application users should use only access keys to programmatically access data in AWS and administrators who need console access should use only passwords to manage AWS resources. | ||||||||
| Unused access keys should be disabled | IAM | Level 1 | 1.4 | 1.14 | Removing unused AWS IAM credentials can significantly reduce the risk of unauthorized access to your AWS resources. Access must not be enabled to resources for IAM users who have left the organization or applications tools that are no longer using these resources. | ||||||
| Access for inactive IAM users should be disabled | IAM | 1.3 | 1.12 | 8.1.4 | 164.312(e)(1) | Disabling access for inactive IAM users can reduce the risk of unauthorized access to your AWS resources and helps you manage the user-based access more efficiently. | |||||
| Rotation for customer created CMKs should be enabled | KMS | Best Practice | 2.8 | 3.8 | 164.312(d), 164.312(e)(1) | Reduce the possibility that a compromised customer master key (CMK) could be used without your knowledge to access certain AWS resources. Enabling KMS Key Rotation will allow you to set a yearly rotation schedule for your CMK such that the KMS service can automatically use the latest version of the HSA Backing key to perform encryption. | |||||
| MFA should be enabled for deleting CloudTrail bucket | CloudTrail | Best Practice | Deleting the CloudTrail logs without authorization is the first step, after an account is compromised. Enabling MFA for deleting the CloudTrail bucket provides increased security to your CloudTrail logs. | ||||||||
| MFA should be enabled for all IAM users that have a console password | IAM | Level 1 | 1.2 | 1.10 | 8.3 | Multi-Factor Authentication (MFA) adds an extra layer of protection on top of a user name and password. It is recommended that MFA be enabled for all accounts that have a console password. | |||||
| S3 buckets should not be publicly writable | S3 | Best Practice | 164.312(a)(1), 164.308(a)(4)(i) | Risk of unauthorized access or loss of customer data increases with unrestricted access to S3 buckets | |||||||
| Password Policy should be strong | IAM | Level 1 | 1.5-1.11 | 1.8-1.9 | 164.312(d), 164.308(a)(5)(ii)(D) | Ensure that a password policy is specified for use with user accounts to minimize the risk of compromise. For example, a strong password policy requires atleast one uppercase, one lowercase, one symbol, one number, is atleast 14 characters long, prevents reuse of older passwords and expires periodically. | |||||
| S3 buckets should not be unencrypted | S3 | Best Practice | 2.1.1 | 2.1.1 | 164.312(a)(2)(iv), 164.312 (e)(1), 164.312(e)(2)(ii) | SC-28,SC-13 | The risk of sensitive data being compromised is significantly lower if a S3 bucket is encrypted. | ||||
| AMIs should not have unrestricted access | AMI | Level 2 | 1.2.1, 2.2.4 | Unrestricted access to AMIs makes these AMIs available in the Community AMIs where everyone with an AWS account can use them to launch EC2 instances. Most of the time, AMIs will contain snapshots of enterprise specific applications (including configuration and application data). Hence, unrestricted access to AMIs is not recommended. | |||||||
| RDS instances should not have unrestricted access | RDS | Best Practice | 1.2.1 | 164.312(e)(1) 164.312(c)(1) | When the VPC security group associated with an RDS instance allows unrestricted access (0.0.0.0/0), entities on the Internet can establish a connection to your databases. This increases the risk for malicious activities such as brute force attacks, SQL injections or DoS/DDoS attacks. | ||||||
| S3 buckets should not have unrestricted access | S3 | Best Practice | 1.20 | 1.2.1 | 164.312(a)(1), 164.308(a)(4)(i) | Risk of unauthorized access or loss of customer data increases with unrestricted access to S3 buckets. | |||||
| Security Groups should not have unrestricted MongoDB access | EC2 | Level 2 | If you are using MongoDB, ensure that access through port 27017, used for MongoDB, is restricted to required entities only. | ||||||||
| Security Groups should not have unrestricted MSSQL access | EC2 | Level 2 | If you are using MSSQL, ensure that access through port 1433, used for MSSQL, is restricted to required entities only. | ||||||||
| Security Groups should not have unrestricted Oracle Database access | EC2 | Level 2 | If you are using Oracle DB, ensure that access through port 1521, used for Oracle DB, is restricted to required entities only. | ||||||||
| Security Groups should not have unrestricted PostgreSQL access | EC2 | Level 2 | If you are using PostgreSQL, ensure that access through port 5432, used for PostgreSQL, is restricted to required entities only. | ||||||||
| VPC flow logging should be enabled for all VPCs | VPC | Level 1 | 2.9 | 3.9 | 164.312(b), 164.312(e)(1) | VPC Flow Logs provide visibility into network traffic that traverses the VPC and can be used to detect anomalous traffic or insight during security workflows. Enabling it will detect security and access issues like overly permissive security groups, network ACLs and alert abnormal activities such as rejected connection requests or unusual levels of data transfer. | |||||
| Default VPCs should not be used | VPC | Best Practice | A default VPC is ready for use so that you dont have to create and configure your own VPC. It allows to immediately start launching Amazon EC2 instances into the default VPC which comes with a default Security Group that denies all inbound traffic but allows all outbound traffic. Default VPC in any unused region allows you to launch resources, and hence should be removed or reviewed and updated according to your requirements. A default VPC may be suitable for a small non-critical single tier application, but is not ideal for a robust production environment | ||||||||
| AWS account should not reach limit for max subnets per VPC | VPC | Best Practice | Detects when your account is approaching the maximum allowable number of subnets per Virtual Private Cloud (VPC) | ||||||||
| AWS account should not reach configured limit for EC2 instances | AWS Account | Best Practice | Detects if the account is near or at the limit of EC2 instances allowed by AWS | ||||||||
| RDS DB should always be encrypted with Customer Managed KMS key | RDS | Best Practice | SC-12 | Customer-managed KMS keys should be used instead of AWS-managed keys in order to have more granular control over encrypting and encrypting data. Or, if you want full control, then you must create a customer-managed key and use the same for encryption. | |||||||
| Security Groups should not have unrestricted MSSQL Database (UDP) access | EC2 | Level 2 | 1.2.1 | Check your EC2 security groups for inbound rules that allow unrestricted access to UDP port 1434 and restrict access to required IP addresses only. UDP port 1434 is used by the Microsoft SQL Server. | |||||||
| Security Groups should not have unrestricted PostgreSQL access | EC2 | Level 2 | 1.2.1 | If you are using PostgreSQL, ensure that access through port 5432, used for PostgreSQL, is restricted to required entities only. | |||||||
| Security Groups should not have unrestricted VNC listener access | EC2 | Level 2 | 1.2.1 | Check your EC2 security groups for inbound rules that allow unrestricted access to TCP port 5500 and restrict access to required IP addresses only. TCP port 5500 is used by the VNC Listener | |||||||
| Security Groups should not have unrestricted VNC Server access | EC2 | Level 2 | 1.2.1 | Check your EC2 security groups for inbound rules that allow unrestricted access to TCP port 5900 and restrict access to required IP addresses only. TCP port 5900 is used by the VNC Server | |||||||
| Security groups should never remain unused | Security Group | Best Practice | 164.312(e)(1) 164.312(c)(1) | Cleaning unused security groups eliminates the risk of a forgotten security group policy being used to accidentally open an attack surface. Delete those that you are certain are not being used or don’t belong to a default security group. | |||||||
| AWS account should not reach its configured limit for VPCs per region | AWS Account | Best Practice | Detects if your account is near the limit of VPCs per Region. Increasing this limit increases the limit on internet gateways per region by the same amount. Usually, you can request an increase for these limits using the AWS Support Center | ||||||||
| AWS account should not reach limit for security group in a VPC | VPC | Best Practice | Detects if your account is near the EC2 Security Group Limit for your security group in a VPC | ||||||||
| Access logging should be enabled for S3 bucket | S3 | 10.2 | 164.312(e)(1), 164.312(b), 164.308(a)(1)(ii)(D), 164.312(a)(2)(i), 164.312(c)(2) | AU-2a | S3 Logging provides a way for you to get details about S3 bucket activity. By default, AWS does not enable logging for S3 buckets. This additional insight into bucket activity can be useful when troubleshooting and may be requested by AWS Support. | ||||||
| Customer Managed Keys should be used | KMS | Best Practice | Customer managed key management service (KMS) keys are not in use. To provide more granular control of your data encryption, we recommend using customer-managed KMS keys instead of AWS managed KMS keys. | ||||||||
| RDS cluster snapshot should not be publicly accessible | RDS | Best Practice | If you set DB Snapshot Visibility to Public, all AWS accounts can restore a DB instance from your DB snapshot and have access to your data. Best practice is to not share any RDS Cluster Snapshots that contain private information as Public. This policy detects manual RDS Cluster Snapshots with Public Permissions. | ||||||||
| RDS snapshot should not be publicly accessible | RDS | Best Practice | If you set DB Snapshot Visibility to public, all AWS accounts can restore a DB instance from your DB snapshot and have access to your data. Best practice is to not share any DB snapshots that contain private information as Public. This policy detects manual RDS Snapshots that are marked as public. | ||||||||
| Redshift cluster should be encrypted with Customer Managed KMS key | Redshift | 3.5 | 164.312(a)(2)(iv), 164.312 (e)(1), 164.312(e)(2)(ii) | The recommended best practice is for customer-managed KMS keys to be used instead of AWS-managed keys to have granular control over encrypting and encrypting data. Redshift clusters should be encrypted with a Customer-managed KMS key. | |||||||
| Redshift Cluster should not be publicly accessible | Redshift | Best Practice | It is the recommended best practice that Redshift cluster nodes should not accessible to the public internet, outside of your VPC. This is dangerous, as Redshift databases should normally be privately accessible only from within your VPC. This policy scans for such incidents when one is discovered. | ||||||||
| AMIs should not be unencrypted | AMI | Best Practice | Instances that are not based on encrypted EBS root volumes pose a security threat due to potential data snooping. This policy scans for AMIs that are based on unencrypted root volume snapshots and returns an alert notifying you of any occurrences that fail this standard. | ||||||||
| Redshift cluster should not be unencrypted | Redshift | 3.4 | Database encryption is available for Redshift. It is recommended to create Redshift clusters with encryption turned on. Regulations and Compliance such as PCI DSS, SOX and HIPAA generally require encryption of Redshift clusters. | ||||||||
| AWS account should not reach VPC Private Gateway regional limit | VPC | Best Practice | Detects if your account is near the private gateway limitation per VPC per Region | ||||||||
| Custom IAM policy should grant least privileges | IAM | Level 1 | 1.22 | 1.16 | 1.24, 7.1.1, 1.22, 2.2.4 | 164.308(a)(4)(i) | IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended and considered a standard security advice to grant the least privilege—that is, granting only the permissions required to perform a task | ||||
| Default access keys should not be unused | IAM | Best Practice | When a new IAM user is created, it generates an API access key for the user by default. This detects any unused default access keys in the account | ||||||||
| EBS volumes should have recent snapshot | EBS | Best Practice | Elastic Block Store (EBS) volumes have no snapshots in recent history per the configured value specified in the policy. These are needed to retain critical system data, security logs, and system state. EBS volume snapshots are an important tool to record system state, security log data, and critical system data at various points in your EC2 instance lifecycle. Snapshots provide point-in-time recovery and review capability that is necessary for many operational and security practices. | ||||||||
| EBS volumes should always be attached to EC2 instances | EBS | 3.5 | One or more EBS volumes appear to not be attached to an EC2 instance. EBS volumes often persist after an EC2 instance has been terminated. We recommend regular review of these volumes, since they can contain sensitive data related to your company, application, infrastructure, or even users. | ||||||||
| At least one IAM group/role should be assigned to the policy AWSSupportAccess | IAM | 1.20 | 1.17 | The best security practice is to assign the least privilege available for access control to a user's role to manage Incidents with AWS Support. This policy scans to ensure that at least one policy group or policy role is assigned to AWSSupportAccess | |||||||
| NAT gateway should be used | VPC | Best Practice | Use a network address translation (NAT) gateway to enable instances in a private subnet to connect to the internet or other AWS services, but prevent the internet from initiating a connection with those instances. AWS recommends to use NAT gateways, as they provide better availability and bandwidth over NAT instances | ||||||||
| SNS should not support cross account access | SNS | Best Practice | Recommended best practice is for SNS queues to not support cross-account access if the list account IDs are on another account or if the access is exposed to everyone. This policy scans any violation to this. | ||||||||
| AWS account should not reach Customer gateway limit per region | VPC | Best Practice | Detects if your account is near the VPC Customer Gateway limit per Region | ||||||||
| AWS ELB listener should be secure | ELB | Check your Elastic Load Balancers (ELBs) listener for secure configurations. Skyhigh Security recommends using HTTPS or SSL protocols to encrypt the communication between the client and your load balancers. | |||||||||
| AWS account should have IAM user | IAM | Ensure that the access to your AWS services and resources is made only through individual IAM users instead of the root account. | |||||||||
| AWS Lambda | Lambda | Upload or Import AWS Lambda code using Skyhigh's custom policy to identify non-compliant services. | |||||||||
|
AWS resources should be tagged |
Ensure that user-defined tags (metadata) are being used for labeling, collecting and organizing resources available within your AWS environment. | ||||||||||
| AWS Route 53 should have SPF DNS Records | Route53 | Ensure your AWS Route 53 hosted zones have a TXT DNS record that contains a corresponding Sender Policy Framework (SPF) value set for each MX record available. The SPF record enables your Route 53 registered domains to publicly state which mail servers are authorized to send emails on its behalf. | |||||||||
| EC2 instance should be configured to use Instance Metadata Service version 2 (IMDSv2) | EC2 | AWS recommends adopting IMDS v2 and restricting access to v2 only for added security against open firewalls, reverse proxies and SSRF vulnerabilities. With IMDSv2, every request is now protected by session authentication. | |||||||||
| EBS Snapshots should not be publicly accessible | EBS | Ensure that your AWS Elastic Block Store (EBS) volume snapshots are not public (i.e. publicly shared with other AWS accounts) in order to avoid exposing personal and sensitive data. Skyhigh strongly recommends against sharing your EBS snapshots with all AWS accounts. If required, you can share your volume snapshots with particular AWS accounts without making them publicly accessible |
Deprecated Policy Templates
The following Policy Templates for AWS are deprecated in Skyhigh CASB 5.2.0.
| Policy Name | Comments | Web Link |
|---|---|---|
| Nearing Limits of EC2 Instances |
max-instances: This attribute is no longer supported. The returned value does not reflect your actual vCPU limit for running On-Demand Instances. Hence deprecating the policy For more information, see On-Demand Instance Limits in the Amazon Elastic Compute Cloud User Guide.
|
https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-account-attributes.html |