AWS Security Services for Network Security Engineers (Part 1)

Getting started with AWS Security Services can be overwhelming. But truth be told, securing compute resources, wherever they are located is overwhelming. In this article, the first of a series, I’ll focus on a small subset of security; security in the cloud, specifically using AWS services. If you are a network engineer that has a security responsibility (IDS, IPS, Firewalls, VPN, Identity Management, etc..) then this series is for you. In this article I will overview six areas of security with AWS and highlight the two or three areas that you’ll likely want to focus on to begin with. Subsequent articles will expound upon these services.

The Six Areas of Security

You may be able to list other areas, but here is my breakdown of the six areas of security.

1. Identity and Access Management
2. Infrastructure Protection
3. Data Protection
4. Detective Controls
5. Incident Response
6. Compliance

You might be wondering why I broke these down into the areas listed above. After all, the Well-Architected Framework lists six categories for security that are slightly different. Well, one thing you will notice in the Well-Architected Framework, Compliance is not listed. However, the network security architect will usually have some degree of responsibility for meeting compliance. You’ll also notice that the first area listed in the Well-Architected Framework is Foundations. I feel that each of the areas in my list above include certain foundations so I will not list them separately. I’ll address the foundations of a topic as it comes up in its respective area. As far as the other areas, I’ve broken them down into these categories and sorted them in this order because it’s logical to me. None of my personal reasons for creating a list that’s slightly different negates the importance of following the Well-Architected Framework. Allow me to elaborate on this.

As you begin your journey to the cloud you start by creating an account. This immediately calls to mind Identity and Access Management. I believe you should start here, from the very beginning, by thinking through how identity and access will be handled. This will give you the opportunity to apply best practices including the least privilege principle. Next, I have Infrastructure Protection and Data Protection. As you build your infrastructure I believe you need to in interested in securing the following areas:

1. Access to the infrastructure components (Identity and Access Management)
2. The data in transit that traverses the infrastructure (Infrastructure Protection and Data Protection)
3. The data at rest that is stored within your cloud resources (Data Protection)

These will be the three main areas I will focus on, however I will still touch on the three other areas.

With that said, Detective Controls are next. You probably want to monitor activity once your architecture is deployed and this is where that’s done. You can also use detective controls to apply preventative measures. We will dig into that a bit more in that respective article. Detective Controls is followed by Incident Response, and after incident response I’ll touch on Compliance.

So, let’s dive in, shall we? In this article let’s begin by addressing the first area, Identity and Access Management. Let’s look at which AWS Identity and Access Management Services you might end up using as a network security engineer and how they fit together in the overall picture.

Identity and Access Management Services

In the AWS Console you can find most of the following services listed in the Security, Identity, & Compliance section. I won’t go through that entire list, but I will cover the following services:

- AWS Identity and Access Management (IAM)

- AWS Organizations

- AWS Single Sign-On (SSO)

- AWS Directory Service

- AWS Resource Access Manager

AWS Identity and Access Management (IAM)

When you get started with AWS the very first user you create is the root user. This user has access to everything. If the account were to fall into the wrong hands, a bad actor could go so far as to delete the entire account. That’s pretty extreme, but I want you to understand the implications. Because this root user is critical to everything you do within this AWS account. Its best practice to set this user account up, enable Multi-Factor Authentication (MFA) and then create at least one IAM user (with MFA enabled also) that you will use for building anything in your account. You can see how to setup your account in the Setting up your AWS Environment getting started guide.

But what is IAM?

IAM is at the core of AWS Security. IAM is where user accounts and permissions are configured and applied. IAM users can be created for individual users or for enabling programmatic access to AWS resources. You should be using an IAM user for the day-to-day and I’ll go into more detail on that in a future post. Right now, understand that you should be visiting IAM and creating an IAM user before you do anything else in your new AWS account. The video below gives a brief introduction to how IAM is used.

AWS Organizations

AWS Organizations fall under Management and Governance in the AWS documentation and console, but I have it listed here as an Identity and Access Management service because it’s integrated heavily with AWS Single Sign-on as well as other services. AWS Organizations let you create several AWS accounts and centrally manage them under an organization. They can further be organized into Organizational Units to make it easier to apply management controls and consolidated billing. Think production account, staging account, and dev account as an example. For example, if you create your first AWS Account you might use it as your management account and do nothing else with it. Then you might open a second account and deem that to be your production account. You might run all your workloads, applications, etc., that are public. Then you might create another account, call it Dev or Staging and use those to build, test, and validate before moving them to production. This is what I did in the screenshot below.

There is obviously more to AWS Organizations, but you need to get a sense for them up front. Try to set these up before moving on. You can always add more organizations for different reasons later on, but think a bit about this. It will give you good isolation between things you’re testing and working on and the production environment, or even isolation between different groups that have different goals in how they build on AWS. The video below gives a nice introduction to AWS Organizations.

AWS Single Sign-On (SSO)

The next service to discuss is AWS Single Sign-On. In your day-to-day work you may log into many devices and tools. For example, when I was managing a large network at a training company, we used TACACS+ and RADIUS for authentication into our devices. In the early days of my career, we had an architecture that resembled the image below.

1. First we stored usernames and passwords on the router. This wasn’t the best option because nothing would sync the user databases between routers. We did it manually. It didn’t scale and was problematic if we didn't copy/paste the exact database between then. We then changed the location of the database to what you see in #2.
2. We moved our user database to the Access Control Server and used the TACACS+ or RADIUS protocol to query the server. This was better but still had it’s shortcomings. The Access Control Server credentials differed from the domain. So, we migrated to #3.
3. After some time we migrated the authentication to query the Active Director server which was the single source of identity truth. It didnt matter where the user was attempting to access the environment, it was always the same credentials.

You can think of AWS SSO in the same way. To provide a simple example have a look at the image below.

1. A user wants to SSH into an EC2 instance. The EC2 instance could have its own user account.
2. The user could also have an IAM account.
3. The user could also have credentials in Azure Active Directory.

If using AWS SSO you could use the credentials stored in Azure Active Directory to connect to the EC2 instance.

If you set up AWS Organizations you can grant access to an organizations and it’s resources via a Single Sign-on URL. When you navigate to the Single Sign-on URL you see something similar to the image below from my test configuration.

Clicking one of the three organizations listed will reveal the permission set applied, in this case AdministratorAccess as well as links to access the management console, command line or programmatic access. So from the page shown below you can connect to the management console of the GCTS-dev organization with administrator access and then use Session Manager (similar to an SSH session) to connect to the EC2 instance all from the management console and without needing to enter additional credentials. While I don’t cover it specifically in this article, I will cover this type of configuration in more detail in a later post. If you want to dive in now and learn more you can find detailed instructions in this video.

AWS Single Sign-on

With AWS SSO you now have a single sign on for your routers, switches, firewalls, laptop, and now your cloud resources. The video below gives a nice overview.

AWS Directory Services

What about AWS Directory Service? AWS Directory Service is a managed service the allows you to connect your AWS resources with an existing on-premises Microsoft Active Directory or, if you prefer, set up a new, stand-alone directory in the AWS cloud. If you use AWS Directory Service to connect to your Microsoft Active Directory, your users can then log into AWS resources using their Active Directory Credentials. Again, this is a managed service, meaning that you provide a few details and AWS will manage the rest. You will not need to worry about building the server, patching the server, keeping Active Directory up-to-date, and so on. There are ways to sync with Azure AD, but this is specifically talking about your standard Active Directory.

AWS Resource Access Manager

AWS Resource Access Manager is another AWS Service that you might end up using as a Network Security Engineer. If you setup multiple AWS Organizations and break them out into something like Prod, Staging, and Dev, you can use AWS Resource Access Manager to share things like subnets, network firewall policies, and network firewall rule groups with each account, just to name a few. This ties into the conversation of AWS Organizations. As you can see in the image below, I’m creating a share that will apply to the AWS organizations that I setup earlier.

This could keep things consistent as they are developed, staged, and moved to production, including the security configuration. Here is a list from the documentation of the resources that are supported. Here is a brief demo video.

So far, we have covered only five resources, all within the Identity and Access Management category. I’ll be breaking these down in further articles, sharing details on how to get started configuring them and points that are important for a network engineer or network security engineer to keep in mind. In the next article though, we will have a look at the second area on our list, Infrastructure Protection.

Now, even though we didn’t get into configurations here you may already be itching to lab up some of what we’ve talked about. I encourage you to do so. Taking time to explore in a lab is a great way to learn the ins and outs of AWS and it will help with retention. There are a few labs available here to get you started.