Remediating exposures for EC2 instances

AWS Security Hub can generate exposure findings for Amazon Elastic Compute Cloud (EC2) instances.

On the Security Hub console, the EC2 instance involved in an exposure finding and its identifying information are listed in the Resources section of the finding details. Programmatically, you can retrieve resource details with the GetFindingsV2 operation of the Security Hub API.

After identifying the resource involved in an exposure finding, you can delete the resource if you don't need it. Deleting a nonessential resource can reduce your exposure profile and AWS costs. If the resource is essential, follow these recommended remediation steps to help mitigate the risk. The remediation topics are divided based on the type of trait.

A single exposure finding contains issues identified in multiple remediation topics. Conversely, you can address an exposure finding and bring down its severity level by addressing just one remediation topic. Your approach to risk remediation depends on your organizational requirements and workloads.

Note

The remediation guidance provided in this topic might require additional consultation in other AWS resources.

Contents

• Misconfiguration traits for EC2 instances

  • The EC2 instance allows access to IMDS using version 1

  • The IAM role associated with the Amazon EC2 instance has an administrative access policy

  • The IAM role associated with the Amazon EC2 instance has a service admin policy

  • The Amazon EC2 instance has a security group or network ACL that allows SSH or RDP access

  • The Amazon EC2 instance has an open security group

  • The Amazon EC2 instance has a public IP address

• Reachability traits for EC2 instances

  • The EC2 instance is reachable over the internet

  • The Amazon EC2 instance is reachable within the Amazon VPC

• Vulnerability traits for EC2 instances

  • EC2 instance has network-exploitable software vulnerabilities with a high likelihood of exploitation

  • The Amazon EC2 instance has software vulnerabilities

Misconfiguration traits for EC2 instances

Here are misconfiguration traits for EC2 instances and suggested remediation steps.

The EC2 instance allows access to IMDS using version 1

Instance metadata is data about your Amazon EC2 instance that applications can use to configure or manage the running instance. The instance metadata service (IMDS) is an on-instance component that code on the instance uses to securely access instance metadata. If IMDS is not properly secured, it can become a potential attack vector, as it provides access to temporary credentials and other sensitive configuration data. IMDSv2 provides stronger protection against exploitation through session-oriented authentication, requiring a session token for metadata requests and limiting session duration. Following standard security principles, AWS recommends that you configure Amazon EC2 instances to use IMDSv2 and disable IMDSv1.

Test application compatibility

Before implementing IMDSv2, test your instance to ensure its compatibility with IMDSv2. Some applications or scripts may require IMDSv1 for core functionality and require additional configuration. For more information about tools and recommended paths for testing application compatibility, Transition to using Instance Metadata Service Version 2 in the Amazon Elastic Compute Cloud User Guide.

Update instance to use IMDSv2

Modify existing instances to use IMDSv2. For more information, see Modify instance metadata options for existing instances in the Amazon Elastic Compute Cloud User Guide.

Apply updates to instances in an Auto Scaling group

If your instance is part of an Auto Scaling group, update your launch template or launch configuration with a new configuration, and perform an instance refresh.

The IAM role associated with the Amazon EC2 instance has an administrative access policy

Administrative access policies provide Amazon EC2 instances with broad permissions to AWS services and resources. These policies typically include permissions not required for instance functionality. Providing an IAM identity with an administrative access policy on an Amazon EC2 instance (instead of the minimum set of permissions the role attached to your instance profile needs) can increase the scope of an attack if the Amazon EC2 instance is compromised. If an instance is compromised, attackers could utilize these excessive permissions to move laterally across your environment, access data, or manipulate resources. Following standard security principles, we recommend you grant least privileges, which means you only grant the permissions required to perform a task.

Review and identify administrative policies

In the IAM dashboard, find the role with the role name. Review the permissions policy attached to the IAM role. If the policy is an AWS managed policy, look for AdministratorAccess or IAMFullAccess. Otherwise, in the policy document, look for statements with "Effect": "Allow", "Action": "*", and "Resource": "*".

Implement least privilege access

Replace administrative policies with policies that grant only the specific permissions required for the instance to function. For more information about security best practices for IAM roles, see Apply least-privilege permissions in Security best practices in the AWS Identity and Access Management User Guide. To identify unnecessary permissions, you can use the IAM Access Analyzer to understand how to modify your policy based on access history. For more information, see Findings for external and unused access in the AWS Identity and Access Management User Guide. Alternatively, you can create a new IAM role to avoid impacting other applications using the existing role. In this scenario, create a new IAM role, then associate the new IAM role with the instance. For instructions on replacing an IAM role for an instance, see Attach an IAM role to an instance in the Amazon Elastic Compute Cloud User Guide.

Secure configuration considerations

If service-level administrative permissions are necessary for the instance, consider implementing these additional security controls to mitigate risk:

• Secure configuration considerations

  • Multi-factor authentication (MFA) – MFA adds an additional security layer by requiring an additional form of authentication. This helps prevent unauthorized access even if credentials are compromised. For more information, see Require multi-factor authentication (MFA) in the AWS Identity and Access Management User Guide.

  • IAM conditions – Setting up condition elements allow you to restrict when and how administrative permissions can be used based on factors like source IP or MFA age. For more information, see Use conditions in IAM policies to further restrict access in the AWS Identity and Access Management User Guide.

  • Permissions boundaries – Permission boundaries establish the maximum permissions a role can have, providing guardrails for roles with administrative access. For more information, see Use permissions boundaries to delegate permissions management within an account in the AWS Identity and Access Management User Guide.

Apply updates to instances in an auto scaling group

For Amazon EC2 instances in an AWS auto scaling group, update the launch template or launch configuration with the new instance profile, and perform an instance refresh. For information about updating a launch template, see Modify a launch template (manage launch template versions) in the Amazon Elastic Compute Cloud User Guide. For more information, see Use an instance refresh to update instances in an Auto Scaling group. For more information about using IAM roles with Auto Scaling groups, see IAM role for applications that run on Amazon EC2 instances in the Amazon EC2 Auto Scaling User Guide.

The IAM role associated with the Amazon EC2 instance has a service admin policy

Service access policies provide Amazon EC2 instances with broad permissions to AWS services and resources. These policies typically include permissions that are not required for instance functionality. Providing an IAM identity with an administrative access policy on an Amazon EC2 instance instead of the minimum set of permissions the role attached to your instance profile needs can increase the scope of an attack if an instance is compromised. Following standard security principles, we recommend that you grant least privileges, which means that you grant only the permissions required to perform a task.

Review and identify administrative policies

In the IAM dashboard, find the role with the role name. Review the permissions policy attached to the IAM role. If the policy is an AWS managed policy, look for AdministratorAccess or IAMFullAccess. Otherwise, in the policy document, look for statements with "Effect": "Allow", "Action": "*", and "Resource": "*".

Implement least privilege access

Replace service admin policies with those that grant only the specific permissions required for the instance to function. For more information on security best practices for IAM roles, see Apply least-privilege permissions in Security best practices in the AWS Identity and Access Management User Guide. To identify unnecessary permissions, you can use the IAM Access Analyzer to understand how to modify your policy based on access history. For more information, see Findings for external and unused access in the AWS Identity and Access Management User Guide. Alternatively, you can create a new IAM role to avoid impacting other applications that are using the existing role. In this scenario, create a new IAM role, then associate the new IAM role with the instance. For information about replacing an IAM role for an instance, see Attach an IAM role to an instance in the Amazon Elastic Compute Cloud User Guide

Secure configuration considerations

If service-level administrative permissions are necessary for the instance, consider implementing these additional security controls to mitigate risk:

Secure configuration considerations

If service-level administrative permissions are necessary for the instance, consider implementing these additional security controls to mitigate risk:

• Multi-factor authentication (MFA) – MFA adds an additional security layer by requiring an additional form of authentication. This helps prevent unauthorized access even if credentials are compromised. For more information, see Require multi-factor authentication (MFA) in the AWS Identity and Access Management User Guide.

• IAM conditions – Setting up condition elements allows you to restrict when and how administrative permissions can be used based on factors like source IP or MFA age. For more information, see Use conditions in IAM policies to further restrict access in the AWS Identity and Access Management User Guide.

• Permissions boundaries – Permission boundaries establish the maximum permissions a role can have, providing guardrails for roles with administrative access. For more information, see Use permissions boundaries to delegate permissions management within an account in the AWS Identity and Access Management User Guide.

Apply updates to instances in Auto Scaling group

For Amazon EC2 instances in an AWS auto scaling group, update the launch template or launch configuration with the new instance profile, and perform an instance refresh. For information about updating a launch template, see Modify a launch template (manage launch template versions) in the Amazon Elastic Compute Cloud User Guide. For more information, see Use an instance refresh to update instances in an Auto Scaling group. For more information about using IAM roles with Auto Scaling groups, see IAM role for applications that run on Amazon EC2 instances in the Amazon EC2 Auto Scaling User Guide.

The Amazon EC2 instance has a security group or network ACL that allows SSH or RDP access

Remote access protocols like SSH and RDP allow users to connect to and manage Amazon EC2 instances from external locations. When security groups permit unrestricted access to these protocols from the internet, they increase the attack surface of your Amazon EC2 instances by allowing internet access to your instance. Following standard security principles, AWS recommends you limit remote access to specific, trusted IP addresses or ranges.

1. Modify security group rules

   Restrict access to your Amazon EC2 instances to specific trusted IP addresses. Limit SSH and RDP access to specific trusted IP addresses, or use CIDR notation to specify IP ranges (e.g., 198.168.1.0/24). To modify security group rules, see Configure security group rules in the Amazon Elastic Compute Cloud User Guide.

The Amazon EC2 instance has an open security group

Security groups act as virtual firewalls for your Amazon EC2 instances to control inbound and outbound traffic. Open security groups, which allow unrestricted access from any IP address, may expose your instances to unauthorized access. Following standard security principles, AWS recommends restricting security group access to specific IP addresses and ports.

Review security group rules and assess current configuration

Evaluate which ports are open and accessible from broad IP ranges, such as (0.0.0.0/0 or ::/0). For instructions on viewing security group details, see DescribeSecurityGroups in the Porting Assistant for .NET API Reference.

Modify security group rules

Modify your security group rules to restrict access to specific trusted IP addresses or ranges. When updating your security group rules, consider separating access requirements for different network segments by creating rules for each required source IP range or restricting access to specific ports. To modify security group rules, see Configure security group rules in the Amazon EC2 User Guide.

The Amazon EC2 instance has a public IP address

Amazon EC2 instances with public IP addresses are publicly accessible from the internet. While public IP addresses are sometimes necessary for instances that provide services to external customers, this can be used as a potential by attack unauthorized principals. Following standard security principles, AWS recommends that you limit public exposure of resources when possible.

Move the instance to a private subnet

If the instance does not require direct internet access, consider moving it to a private subnet within your VPC. This will remove its public IP address while still allowing it to communicate with other resources within your VPC. For more information, see How do I move my Amazon EC2 instance to another subnet, Availability Zone, or VPC? in the AWS Knowledge Center.

Configure instances to launch without public IP addresses

If the instance was launched in a public subnet that doesn’t require public IP addresses, the launch configuration can be modified to prevent the automatic assignment of public IP addresses. This can be disabled at the subnet level or when launching individual instances. For more information, see Modify the IP addressing attributes of your subnet in the Amazon Virtual Private Cloud User Guide and Amazon Amazon EC2instance IP addressing in the Amazon Elastic Compute Cloud User Guide.

Alternative access methods

Consider the following options for alternative access methods:

• Use a NAT Gateway for outbound internet connectivity –

  For instances in private subnets that require access to the internet (e.g., to download updates), consider using a NAT Gateway instead of assigning a public IP address. A NAT Gateway allows instances in private subnets to initiate outbound connections to the internet while preventing inbound connections from the internet. For more information, see NAT gateways in the Amazon Virtual Private Cloud User Guide.

• Use Elastic Load Balancing – For instances that are running web applications, consider using an Elastic Load Balancer (LB). LBs can be configured to allow your instances to run in private subnets while the LB runs in a public subnet and handles internet traffic. For more information, see What is Elastic Load Balancing? in the AWSELB User Guide. See Load balancer subnets in AWS Prescriptive Guidance for guidance on how to choose a stickiness strategy for your LB.

Reachability traits for EC2 instances

Here are reachability traits for EC2 instances and suggested remediation steps.

The EC2 instance is reachable over the internet

Amazon EC2 instances with ports that are reachable from the internet through an internet gateway (including instances behind Application Load Balancers or Classic Load Balancers), a VPC peering connection, or a VPN virtual gateway may expose your instance to the internet. Following standard security principles, we recommend implementing least-privilege network access controls by restricting inbound traffic to only necessary sources and ports.

Modify or remove security group rules

In the Resources tab, open the resource for the Amazon EC2 Security Group. Review whether internet access is required for the instance to function. Modify or remove inbound security group rules that allow unrestricted access (0.0.0.0/0 or ::/0). Implement more restrictive rules based on specific IP ranges or security groups. If limited public access is necessary, restrict access to specific ports and protocols required for the instance's function. For instructions on managing security group rules, see Configure security group rules in the Amazon EC2 User Guide.

Update network ACLs

Review and modify network access control lists (ACLs) associated with the instance's subnet. Verify that the ACL settings align with the security group changes and don't unintentionally allow public access. For instructions on modifying network ACLs, see Work with network ACLs in the Amazon VPC User Guide.

Alternative access methods

Consider the following options for alternative access methods:

• Use NAT Gateway for outbound internet connectivity – For instances in private subnets that require access to the internet (e.g., to download updates), consider using a NAT Gateway instead of assigning a public IP address. A NAT Gateway allows instances in private subnets to initiate outbound connections to the internet while preventing inbound connections from the internet. s

• Use Systems Manager Session Manager – Session Manager provides secure shell access to your Amazon EC2 instances without the need for inbound ports, managing SSH keys, or maintaining bastion hosts.

• Use WAF and Elastic Load Balancing or Application Load Balancer – For instances that are running web applications, consider using an LB combined with AWS Web Application Firewall (WAF). LBs can be configured to allow your instances to run in private subnets while the LB runs in a public subnet and handles internet traffic. Adding a WAF to your load balancer provides additional protection against web exploits and bots.

The Amazon EC2 instance is reachable within the Amazon VPC

Amazon Virtual Private Cloud (Amazon VPC) allows you to launch AWS resources in a defined virtual network. Amazon VPC network configurations that allow unrestricted access between instances can increase the scope of an attack if an instance is compromised. Following security best practices, AWS recommends implementing network segmentation and least-privilege access controls at the subnet and security group levels.

Review Amazon VPC network connectivity patterns

In the the exposure finding, identify the security group ID in the ARN. Identify which instances need to communicate with each other and on which ports. You can use Amazon VPC Flow Logs to analyze existing traffic patterns in your Amazon VPC to help identify which ports are being used.

Modify security group rules

Modify your security group rules to restrict access to specific trusted IP addresses or ranges. For example, instead of allowing all traffic from the entire VPC CIDR range (e.g., 10.0.0.0/16), restrict access to specific security groups or IP ranges. When updating your security group rules, consider separating access requirements for different network segments by creating rules for each required source IP range or restricting access to specific ports. To modify security group rules, see Configure security group rules in the Amazon EC2User Guide.

Consider organizing your Amazon VPC resources into subnets based on security requirements or function. For example, place web servers and database servers in separate subnets. For more information, see Subnets for your VPC in the Amazon Virtual Private Cloud User Guide.

Configure network ACLs for subnet level protection

Network Access Control Lists (NACLs) provide an additional layer of security at the subnet level. Unlike security groups, NACLs are stateless and require both inbound and outbound rules to be explicitly defined. For more information, see Control subnet traffic with network access control lists in the Amazon Virtual Private Cloud User Guide.

Additional considerations

Consider the following when restricting access to your Amazon VPC

• Transit Gateway or Amazon VPC Peering with restrictive routing – If your architecture uses multiple VPCs that need to communicate, consider using AWS Transit Gateway and Amazon VPC peering to provide connectivity between Amazon VPCs while allowing you to control which subnets can communicate with each other. For more information, see Get started with using Amazon VPC Transit Gateways and VPC peering connections.

• Service endpoints and private links – Amazon VPC endpoints can be used to keep traffic within the AWS network to communicate with AWS resources rather than over the internet. This reduces the need for direct connectivity between instances accessing the same services. For information on VPC endpoints, see What are Amazon VPC endpoints? in the Amazon Virtual Private Cloud User Guide. For connectivity to services hosted in other Amazon VPCs, consider using AWS PrivateLink.

Vulnerability traits for EC2 instances

Here are vulnerability traits for EC2 instances and suggested remediation steps.

EC2 instance has network-exploitable software vulnerabilities with a high likelihood of exploitation

Software packages that are installed on EC2 instances can be exposed to Common Vulnerabilities and Exposures (CVEs). Critical CVEs pose significant security risks to your AWS environment. Unauthorized principals can exploit these unpatched vulnerabilities to compromise the confidentiality, integrity, or availability of data, or to access other systems. Critical vulnerabilities with high exploitation likelihood represent immediate security threats, as exploit code may already be publicly available and actively used by attackers or automated scanning tools. We recommend patching these vulnerabilities to protect your instance.

Update affected instances

Review the References section in the Vulnerability tab of the trait. Vendor documentation may include specific remediation guidance. Follow the appropriate remediation using these general guidelines:

Use Systems Manager Patch Manager to apply patches for both operating systems and applications. Patch Manager helps you select and deploy operating system and software patches automatically on large groups of instances. If you don't have Patch Manager configured, manually update the operating system on each affected instance.

Update the affected applications to their latest secure versions following the vendor’s recommended procedures. To manage application updates across multiple instances, consider using Systems Manager State Manager to keep your software in a consistent state. If updates aren't available, consider removing or disabling the vulnerable application until a patch is released or other mitigations, such as restricting network access to the application or disabling vulnerable features.

Follow the specific remediation advice provided in the Amazon Inspector finding. This could involve changing security group rules, modifying instance configurations, or adjusting application settings.

Check if the instance is part of Auto Scaling Group. AMI-replacement patching is done on immutable infrastructures by updating the AMI ID that is configured to deploy new Amazon EC2 instances in an Auto Scaling group. If you are using a custom/golden AMI, create an instance with the new AMI, and then customize the instance and create a new golden AMI For more information, see AMI updates patching (using patched AMIs for Auto Scaling groups).

Future considerations

To prevent future occurrences, consider implementing a vulnerability management program. Amazon Inspector can be configured to automatically scan for CVEs on your instances. Amazon Inspector can also be integrated with Security Hub for automatic remediations. Consider implementing a regular patching schedule using Systems Manager Maintenance Windows to minimize disruption to your instances.

The Amazon EC2 instance has software vulnerabilities

Software packages that are installed on Amazon EC2instances can be exposed to Common Vulnerabilities and Exposures (CVEs). Noncritical CVEs represent security weaknesses with lower severity or exploitability compared to critical CVEs. While these vulnerabilities pose less immediate risk, attackers can still exploit these unpatched vulnerabilities to compromise the confidentiality, integrity, or availability of data, or to access other systems. Following security best practices, AWSrecommends patching these vulnerabilities to protect your instance from attack.

Update affected instances

Use AWS Systems Manager Patch Manager to apply patches for operating systems. Patch Manager helps you select and deploy operating system and software patches automatically on large groups of instances. If you don't have Patch Manager configured, manually update the operating system on each affected instance.

Update the affected applications to their latest secure versions following the vendor’s recommended procedures. To manage application updates across multiple instances, consider using AWS Systems Manager State Manager to keep your software in a consistent state. If updates aren't available, consider removing or disabling the vulnerable application until a patch is released or other mitigations, such as restricting network access to the application or disabling vulnerable features.

Follow the specific remediation advice provided in the Amazon Inspector finding. This could involve changing security group rules, modifying instance configurations, or adjusting application setting.

Check if the instance is part of Auto Scaling Group. AMI-replacement patching is done on immutable infrastructures by updating the AMI ID that is configured to deploy new Amazon EC2 instances in an Auto Scaling group. If you are using a custom/golden AMI, create an instance with the new AMI, and then customize the instance and create a new golden AMI For more information, see AMI updates patching (using patched AMIs for Auto Scaling groups).

Future considerations

To prevent future occurrences, consider implementing a vulnerability management program. Amazon Inspector can be configured to automatically scan for CVEs on your instances. Amazon Inspector can also be integrated with Security Hub for automatic remediations. Consider implementing a regular patching schedule using Systems Manager Maintenance Windows to minimize disruption to your instances.