For each of the AWS services that I have touched on so far, there are numerous best practices to follow and recommendations to adhere to when architecting your environments. These best practices are defined to allow you to follow tried and tested processes and procedures that optimize your solutions, ensuring that security is built in at every layer of your architecture and minimizing the risk of security vulnerabilities and exposures.  

Within this chapter, I shall review some of the common security best practices that should be implemented where possible. I will also dive into AWS Trusted Advisor, which automatically highlights any deviation from a number of security best practices as defined by AWS. Finally, I shall take a closer look at penetration testing in AWS.

The following topics will be covered in this chapter:

• Common security best practices
• Using AWS Trusted Advisor
• Penetration testing in AWS

Technical requirements

To view and follow the demonstrations in this chapter, you must have access to AWS Trusted Advisor. For more information on managing permissions, please review Chapter 4, Working with Access Policies.

Common security best practices 

There are so many AWS security best practices, and you should try and adopt as many as possible in an effort to enhance your security posture. I want to highlight and review a number of common best practices that are easy to implement and could play a huge role in protecting your solutions and data:

• Enable Multi-Factor Authentication (MFA): In addition to a password that is required for users to authenticate to AWS, it is recommended to implement MFA to add a second layer of authentication. By using MFA, you are required to enter a randomly generated six-digit number once you have entered your password when using the AWS Management Console.  This is a best practice for your AWS root account and any other user accounts that have elevated privileges. This was covered in Chapter 3, Access Management.
• Enable AWS CloudTrail: This service should be enabled within all regions that you operate your AWS solutions within. It is essential in helping you to monitor, log, and capture all API activity, which can then be used to identify any security threats within your environment. For details, visit Chapter 13, Auditing and Governance.
• Remove your root accounts access keys: You should not enable access keys for your root account that could enable programmatic access to your AWS account. These keys enable the user to authenticate to AWS resources programmatically using the AWS CLI, the SDK, or other development tools, and if these were compromised, a malicious user would have full access to and control over your AWS account. This was also covered in Chapter 3, Access Management.
• Implement a strong password policy: From within AWS IAM, you should ensure that you have created and implemented a strong password policy; the more complex the policy is, the stronger and harder to break your passwords will be:

• Implement the Principle of Least Privilege (PoLP): Regardless of which policy you are using, one key point is to always implement security based on the PoLP. This essentially means that you should only ever grant permissions for an identity that the identity actually needs, and no more. For example, you should not allow full access to EC2 (ec2:*) for a user who only actually needs to use stop and terminate instances. Instead, you would assign the permissions of ec2:stopinstances and ec2:terminateinstances. By granting additional permissions, you increase risk and the level of potential damage should a breach of credentials occur. For more details, read Chapter 4, Working within Access Policies.

• Encrypt, encrypt, encrypt: Depending on the sensitivity of your data, you might need to implement a level of encryption to prevent it from being accessed as plaintext data. Whether your data is being sent in transit or stored at rest in AWS, you have a variety of ways to implement encryption to prevent it from being viewed should it fall into the wrong hands. I shall be covering more on encryption and using AWS Key Management Service (KMS) in Chapter 16, Managing Key Infrastructure.
• Automation and Remediation: As discussed in Chapter 14, Automating Security Threat Detection and Remediation, implementing a level of automation and remediation through a variety of managed services is crucial to being able to identify, classify, and remediate potential security vulnerabilities within your environment far quicker than you could manually. Services such as Amazon GuardDuty, AWS Lambda, AWS Security Hub, AWS CloudTrail, AWS Config, and Amazon Macie, to name but a few, are great for helping you to have an eyes-on approach to all activities undertaken within your environment.

Following these few simple best practices paves the way in providing a robust and secure environment that many of your deployed solutions will be tightly integrated with, giving you a great start in implementing a tight security posture. Failure to comply with these simple practices will provide easier access to your data and resources for those who aim to carry out malicious activity.  

In order to help us adopt these best practices, AWS also provides us with a few services. Let's begin by looking at AWS Trusted Advisor.

Using AWS Trusted Advisor

The AWS Trusted Advisor service has been around for quite some time and continues to play an integral role in helping customers to optimize their AWS environment through recommended best practices. It acts, much as the name suggests, as an advisor to you and highlights and recommends enhancements against a number of predefined best practice checks across five different areas of your account:

Within each of these areas, AWS Trusted Advisor has a list of predefined checks based on best practices that should be adhered to within your AWS account. Trusted Advisor would then highlight and identify any misalignment with these checks and suggest remediation steps to take action against the alert criteria. We will understand this better in the Reviewing deviations using AWS Trusted Advisor section, when we actually carry out a check in our environment. For now, just make sure you understand the basics.

The following points summarize and provide definitions of each of the five areas checked by Trusted Advisor:

• Cost Optimization: These checks help you to identify resources that are not being optimally used and see where you could save money by optimizing your infrastructure.  
• Performance: Performance checks look at your resources to identify any resources that could make use of provisioned throughput and identifying resources that are over-utilized.
• Security: Here, the checks taken are used to identify weaknesses that could lead to vulnerabilities within your account.
• Fault Tolerance: The checks within this category are used to determine whether you have adequate resiliency and fault tolerance built into your environment – for example, through making use of multi-Availability Zone features and auto-scaling.
• Service Limits: This category checks whether any of your services have reached 80% or more against the allotted service limit. For example, you are only allowed five VPCs per region; once you reach four VPCs in a single region (80%), you will be notified.

To the view the checks within Trusted Advisor for each of the categories, you can follow these steps: 

1. From within the AWS Management Console, select Trusted Advisor from the Management & Governance menu on the service list page:

2. Select the category using the relevant icon from the dashboard:

3. From here, you can then view the available checks within each category. As an example, the following screenshots show a check from each of the five categories:
   
   • Cost Optimization: This check will review your EC2 instances to determine whether any of them have been running at 10% CPU utilization or less, or if the network I/O was 5 MB or less on 4 or more days over the previous 2 weeks:

• • Performance: This check tries to identify any security groups that seem to have an excessive amount of rules, as too many rules can hinder a security group's performance:

• • Security: This check looks for any unrestricted access to a resource that could be overly permissive, increasing the potential for a malicious user to gain access unnecessarily:

• • Fault Tolerance: This check will identify any RDS databases that have been deployed in a single Availability Zone in an effort to suggest that you use multi-Availability Zone deployments for high availability:

• • Service Limits: This check will determine whether more than 80% of your DyanmoDB-provisioned throughput limit has been reached for reads per account:

At the time of writing this book, there are over 70 different checks that are performed against your resources and your account, and this list is continuously being updated and growing.

Understanding the availability of AWS Trusted Advisor 

Now, you might be thinking that AWS Trusted Advisor is a great tool and you'll probably want to start using it right away if you don't already. However, the service is not freely available to everyone. The amount of AWS Trusted Advisor checks that you can use and access is dependent on your support plan with AWS – understanding this is important.

Each of the support plans offers different features, such as the following:

• Best practices
• Technical support
• Architecture support
• Proactive guidance
• Programmatic case management
• Account assistance
• Health status and notifications

Access to Trusted Advisor falls under the best practices feature set, and as a result, the support plans for Trusted Advisor are set out as follows:

 As you can see, there are four different support plans:

• Basic
• Developer
• Business
• Enterprise

For any AWS accounts that are on the Basic or Developer support plans, they will only have access to seven core Trusted Advisor checks.

For any accounts on the Business or Enterprise support plans, they will have access to all AWS Trusted Advisor checks across all five categories. There are also additional Trusted Advisor benefits that come with these two support plans, which include the following:

• Notifications: Allow you to create alerts and implement automation with the assistance of Amazon CloudWatch
• Programmatic access: Provides the ability to access and view any Trusted Advisor results via the appropriate AWS support APIs

The seven core checks that are accessible to everyone (through the Basic and Developer support plans) include six checks from the security category and the entirety of the service limit category (which is classed as one check but covers many different services). The checks are as follows:

The checks that are accessible for the security category include the following:

• S3 bucket permissions
• Security groups – specific ports unrestricted
• IAM use
• MFA of root account
• EBS public snapshots
• RDS public snapshots

The checks that are accessible for the service limits category include the following:

If you are on the Basic support plan, then you can view these checks easily within the AWS Management Console by doing the following:

1. Selecting Trusted Advisor from the Management and Governance category on the service list page.
2. Selecting either the Security or Service Limits category and viewing the available services. From here, you can view each check in more detail.

Now that we have a basic understanding of what the service is and does, I want to show you what the interface and the findings look like when the set criteria have been breached. 

Reviewing deviations using AWS Trusted Advisor

When you begin using AWS Trusted Advisor, over time you will see that the service begins to highlight potential issues within your account. In this section, I want to cover how to review the deviations that Trusted Advisor highlights and how to interpret the severity of the issues found.

From within the AWS Management Console, select AWS Trusted Advisor from the Management & Governance category list. This will then present you with the following dashboard:

As you can see, you are presented with the five different categories that I explained earlier, each with a series of icons underneath that provide a high-level summary of the status of the checks within that category:

Let's understand what each of these icons signifies:

• The green square with a tick mark indicates the number of checks that successfully passed, where no action is required.
• The yellow triangle with an exclamation mark indicates the number of checks that require some level of investigation.
• The red circle with an exclamation mark indicates that immediate action and attention should be given.

My AWS account is only on the Basic support plan, and so I only have access to the free checks discussed earlier. Under the Security category, I can see that five of the six security checks passed successfully, but one element requires investigation, as signified by the yellow alert. Also, within the Service Limits category, I can see that I have a red alert for one of my checks. Let me take a look at both of these alerts.

Yellow alert

Firstly, we will try and understand the yellow triangle exclamation warning in my Security category. But how? There are two ways of doing so:

• You can select the alert from the Recommended Actions list, as shown in the previous screenshot.
• You can select the Security category icon showing the alert.

When selected, you can drill down into the check further to show the details captured. This shows my security alert:

Let's take a closer look at the information presented on this page:

• Firstly, it identifies the check that this alert was issued against, this being Security Groups - Specific Port Unrestricted, which quite simply checks security groups for rules that allow unrestricted access (0.0.0.0/0) to specific ports.
• Alert Criteria defines the state at which this check is considered green, red, or yellow (its current state):
  • Green: Access to port 80, 25, 443, or 465 is unrestricted.
  • Red: Access to port 20, 21, 1433, 1434, 3306, 3389, 4333, 5432, or 5500 is unrestricted.
  • Yellow: Access to any other port is unrestricted.

• It also provides a suggestion for Recommended Action, and here it has indicated the following: Restrict access to only those IP addresses that require it. To restrict access to a specific IP address, set the suffix to /32 (for example, 192.0.2.10/32). Be sure to delete overly permissive rules after creating rules that are more restrictive.
• For additional clarification on the topics surrounding this issue, the check also supplies links to other resources, such as those shown here on Wikipedia and AWS's own documentation. 
• Finally, at the bottom of the page, we can see a list of resources that were captured by this alert state, in which there are eight security groups. 

So, my action to resolve this would be to restrict the source and destination addresses, instead of having the open access of 0.0.0.0/0 for these security groups. 

If, for some reason, the configuration of one of these security groups was correct, despite this best practice, then I could exclude the resource from this check going forward to ensure that it didn't appear each and every time as an issue within Trusted Advisor. I could do this in two simple steps:

1. First, I would select the security group in question. In the example here, I have selected the DNS security group:

2. Then, select Exclude & Refresh, which you can see at the top of the table. AWS Trusted Advisor will then exclude that resource from its checks and refresh the entire listing:

In this section, we reviewed a yellow alert, although it was not a critical find that needed immediate intervention. If left, then over time this could have become more of a security threat. So, essentially, yellow alerts still need rectifying, but it is not essential for you to act upon them immediately, whereas red alerts should require this level of response.

Red alert

Let me now take a look at the red alert from within the Service Limits category. To do so, select the alert from the main dashboard page:

The service check limit seen here is for VPC. As explained previously, the service limit checks for usage that is more than 80% of the service limit; in this case, it's the VPC limit. 

The alert criteria is either yellow (80% of the limit is reached), red (100% of the limit is reached), or blue (Trusted Advisor was unable to retrieve utilization or limits in one or more regions).

Based on this alert criteria, I can assume that I have five VPCs within a single region, and the recommended action to resolve this is to open a case in the Support Center to request a limit increase if I anticipate that I will require more than five VPCs in the affected region.

Looking at my list of VPCs, I can see that it is the eu-west-1 region that does indeed have five VPCs within it:

As we have seen, AWS Trusted Advisor is a great tool for monitoring, getting advice, and getting recommendations about actions to take within your infrastructure based upon best practices that can help you to refine your architecture to the benefit of costs, performance, fault tolerance, service limitations, and most importantly, security! Having a service that is always analyzing your infrastructure and advising you to adhere to best practices, especially from a security perspective, makes this a very powerful service and helps you to maintain a stronger security posture.

Penetration testing in AWS

Firstly, what is a penetration test? A penetration test, or pentest, is essentially an authorized cyber attack on your own environment and infrastructure that is used to determine its weak points and vulnerabilities, in addition to its strengths, against defined security standards. 

This is a good security practice to perform on your environments to understand the areas of improvement required at all layers of your architecture. It is better for an authorized attacker to find a weak spot, allowing you to fix and remediate the risk, than to have a malicious attacker who would exploit the flaw for their own gain.

However, within AWS, you must adhere to some strict policies and procedures when penetration testing. For example, you can't carry out penetration testing on whatever service you would like to; in fact, there are very few services that you can pentest without prior approval from AWS. These services are as follows:

• Amazon EC2 instances, NAT gateways, and elastic load balancers
• Amazon RDS
• Amazon CloudFront
• Amazon Aurora
• Amazon API Gateways
• AWS Lambda and Lambda Edge functions
• Amazon Lightsail resources
• Amazon Elastic Beanstalk environments

For the preceding "allowed" services, there are also some very strict rules regarding services that are not to be pentested under any circumstances – these are as follows:

• DNS zone walking via Amazon Route 53 hosted zones
• Denial of Service (DoS), Distributed Denial of Service (DDoS), simulated DoS, simulated DDoS
• Port flooding
• Protocol flooding
• Request flooding (login request flooding and API request flooding)

In addition to this, you are not allowed to carry out any kind of security assessment on AWS's own infrastructure or any of the services they offer.

Finally, the following terms and conditions should be adhered to at all times when it comes to pentesting:

• Pentesting will be restricted by service, network bandwidth, requests per minute, and instance type.
• Pentesting is subject to the terms of the AWS Customer Agreement (https://aws.amazon.com/agreement/) between you and AWS.
• You should abide by AWS's policy regarding the use of security assessment tools and services.

Summary

In this chapter, we quickly went through some of the industry best practices that have been tried and tested, are easy to implement, and should be followed at all times. We then understood how AWS Trusted Advisor is a service that is based upon AWS best practices within your environment and covers not only security best practices but also those focused on cost optimization, performance, fault tolerance, and service limits. However, depending on your support plan, not all of the checks within Trusted Advisor may be available. Finally, we looked at the dos and don'ts for the policies that must be followed, to ensure that you do not breach any security procedures set out by AWS when pentesting.

In the next chapter, we will be looking at AWS Key Management Service, known as KMS, and CloudHSM, which are two services used to manage encryption keys. Therefore, the next chapter will be very much focused on data protection using different encryption mechanisms.

Questions

As we conclude, here is a list of questions for you to test your knowledge regarding this chapter's material. You will find the answers in the Assessments section of the Appendix:

1. True or false: You should enable access keys for your root account that would enable programmatic access to your AWS account.
2. Which AWS service highlights and recommends enhancements against a number of predefined best practice checks across five different areas of your account?
3. Which check within AWS Trusted Advisor is used to determine whether you have adequate resiliency built into your environment, for example, through making use of multi-Availability Zone features and auto-scaling?
4. Which support plans only give access to seven core Trusted Advisor checks?
5. True or false: A penetration test, or pentest, is essentially an authorized cyber attack on your own environment and infrastructure in an effort to determine its weak points and vulnerabilities, in addition to its strengths, against defined security standards.