Skip to main content
McAfee MVISION Cloud

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

Policy Name

Resource/
Entity Type

MVISION Cloud 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

PCI DSS  v3.2

HIPAA

NIST 800-53 Rev4 

Policy Description

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. McAfee 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 MVISION Cloud 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
  • Was this article helpful?