Lab 3: Security

us-east-1.durian.bkr.team.aws.training/session/aEzFcgjpk6HCrFRc2CaL3p

Your AWS Services are ready.

© 2022 Amazon Web Services, Inc. or its

affiliates. All rights reserved. This work may
not be reproduced or redistributed, in
whole or in part, without prior written
permission from Amazon Web Services,
Inc. Commercial copying, lending, or selling is prohibited. All trademarks are the property
of their owners.

Note: Do not include any personal, identifying, or confidential information into the lab
environment. Information entered may be visible to others.

Corrections, feedback, or other questions? Contact us at AWS Training and Certification.

Objectives
In this hands-on activity, you will identify which cloud-native solutions can mitigate the
risks while providing scalability, reliability, and cost optimization at a low operational
burden. During this Lab, mainly you will apply the Enable traceability design principle,
learning how to use cloud native controls like AWS CloudTrail, Security Groups, and AWS
Systems Manager, to secure the cloud architecture.

After completing this lab, you will be able to:

Apply granular logging

Improve granular control of communication
Improve granular network-based controls
Evaluate detailed logging capabilities
Minimize admin access risk

Prerequisites
This lab requires:

Access to a notebook computer with Wi-Fi and Microsoft Windows, Mac OS X, or

Linux (Ubuntu, SuSE, or Red Hat)
The lab environment is not accessible using an iPad or tablet device, but you can use
these devices to access the student guide.
For Microsoft Windows users: Administrator access to the computer
An Internet browser such as Chrome, Firefox, or IE9 (previous versions of Internet
Explorer are not supported)

1/13
 An SSH client such as PuTTY

Duration
This lab will require 60 minutes to complete.

Scenario

The Security pillar encompasses the ability to protect data, systems, and assets to take
advantage of cloud technologies to improve your security.

Security is our top priority. According to the Well-

Architected Framework Review, you should implement
some cloud native controls to prevent and detect security
issues.

Architecture

After completing tasks in this lab, you will have the following architecture:

Start lab
1. To launch the lab, at the top of the page, choose Start lab.

2/13
You must wait for the provisioned AWS services to be ready before you can continue.

2. To open the lab, choose Open Console.

You are automatically signed in to the AWS Management Console in a new web browser
tab.

Do not change the Region unless instructed.

Common sign-in errors

Error: You must first sign out

If you see the message, You must first log out before logging into a different
AWS account:

Choose the click here link.

Close your Amazon Web Services Sign In web browser tab and return to your
initial lab page.
Choose Open Console again.

Error: Choosing Start Lab has no effect

In some cases, certain pop-up or script blocker web browser extensions might prevent the
Start Lab button from working as intended. If you experience an issue starting the lab:

Add the lab domain name to your pop-up or script blocker’s allow list or turn it off.
Refresh the page and try again.

Task 1: Enable granular logging

AWS CloudTrail is a service that provides governance, compliance, operational
auditing, and risk auditing of your AWS account. With AWS CloudTrail, you can log,
continuously monitor, and retain account activity related to actions across your AWS
infrastructure.

We want to apply detailed, holistic logging and network-based security monitoring.

3/13
 3. In the AWS Management Console, choose the Services menu, and then choose
CloudTrail. Alternatively, you can type the service name in the Search box to
access the service directly.

We are going to create a trail to capture all read/write events which would show us
every API call made to our AWS environment from now on.

Note: You might see a warning in your console: “The option to create an organization
trail is not available for this AWS account. Learn more
com.amazonaws.services.organizations.model.AccessDeniedException: You don’t have
permissions to access this resource. (Service: AWSOrganizations; Status Code: 400;
Error Code: AccessDeniedException; Request ID: 0080f181-3022-4e69-af49-
9d76a5dabd85; Proxy: null)”. You can safely ignore this warning and continue
with the next step.

Note: Alternatively, you might see two additional warning messages Failed to get
CloudTrail events and Failed to get Insight events, likewise, you can safely ignore
these, too.

We should save trail logs for further evaluation, so you would want to create a new S3
bucket and give it a unique name e.g.

.
Follow these steps:

4. In the left navigation pane, choose Dashboard.

5. Choose Create trail.

Trail Name :

Storage Location : Select Create new S3 bucket

Trail log bucket and folder :

Note: Do not enter the curly brackets in the bucket name. A valid bucket name
would look like: cloudsecurity-demo-bucket-johndoe.

Under Log file SSE-KMS encryption, uncheck Enabled.

Keep other parameters as default and choose Next.

Note: S3 buckets must have unique names, so make sure to add your name at the end.
They can also only be lower case letters, numbers, “-“, and “.”).

6. In the Choose log events page, keep the default settings. You should see the
Management events selected.

7. Choose Next.

4/13
 8. Review the different selcteions, and choose Create trail.

You will come back to this later. Monitoring what API calls are made is great, but it’s
difficult to convert that into something like change management for all infrastructure
in the cloud. Is there any service to help us here?

Next, you will also look into one of the Services called AWS Config.

9. In the AWS Management Console, choose the Services menu, and then choose
Config. Alternatively, you can type the service name in the Search box to access
the service directly.

10. Choose Get started.

Note: If you don’t see that option, you can access your configuration by choosing
Settings in the left navigation pane.

11. In the next screen, make sure that Record all resources supported in this region is
selected.

12. Choose Include global resources

You will store this data in a central bucket as well. Next, you will create a new bucket and
use the default to ensure its unique (Note: you could use the bucket we just created, but
you would have to add permissions, which would take more time).

13. In the Delivery method section, choose Create a bucket, and leave settings and
parameters with their default values.

14. Choose Next.

15. In the next step, you could choose the rules you want to test against, but you will be
doing that later in this lab, so you can skip this step for now, and simply chooseNext.

16. Review your selections, and choose Confirm.

17. If prompted, you may close the Welcome to AWS Config popup window.

You enabled Config to monitor all changes to our environment. And we’ll see that in a bit.

NOTE: When we looked at the on-premises environment, we identified that there are
disjointed security tooling, lack of insight into what’s going on in the environment. There
is difficulty managing change control and permissions, which led to risks becoming
problems pretty quickly. With the services we just configured, we’ll see how we now have
complete insight into who’s doing what in the environment, what changes are being made,
and when problems start to arise.

Task 2: Improve granular control of communication

5/13
In this task you will review and improve upon granular control of communication
between workloads in the cloud.

18. In the AWS Management Console, choose the Services menu, and then choose
EC2. Alternatively, you can type the service name in the Search box to access the
service directly.

19. In the left navigation pane, in the Network & Security section, choose Security
Groups.

Looking at the granular control of system-to-system communication used to be difficult.

Now, looking at your EC2 Service, Security Groups, allows you to quickly see who can
talk to whom.

20. Choose the security group with the Security group name of wa-database-sg.

21. Navigate to the Outbound rules tab. You will see the servers can talk to a range of
IP’s, 65,536 to be precise. But there are only maybe 6-8 servers that they actually
need to talk to. You can start reducing that number by editing the Destination rule.

22. Choose Edit outbound rules, then choose Delete to eliminate the existing rule.

23. Next, choose Add rule.

24. For Type, select “All Trafic”. For Destination, with Custom selected in the
dropdown, look for the Security Group name

using the input field, and select it.

25. Choose Save rules.

26. You will see the Destination of the rule now shows the Security Group you
selected.

Note: By doing this, you’ve reduced the scope of internal traffic communication from
65,535 hosts down to 1. Additionally, if you ever need to start more servers up in these
groups, they would be automatically become accessible without intervention, as long as
you associate them with the same Security Group. Were this on premises, you would
either need to have Firewalls between all internal VLAN’s, Routers, and sites, or complex
Network ACL’s on every switch in your environment. This reduces the risk of threats, the
risk of misconfiguration, and the operational burden all at once.

Task 3: Improve granular network-based controls

Next, you will improve you network-based controls by using Network ACLs to prevent
side-to-side movement in a granular way.

6/13
Security Groups are a good choice to control how you allow access. However, Security
Groups are stateful, so any inbound traffic you allow, will allow outbound traffic through
the same ports, and vice versa.
If you need to block access, then you need to use
Network ACLs. For instance, if you wanted to make sure you explicitly blocked the Load
Balancer in your Web Application from talking to the Database servers, you could Create
a network ACL to block that communication.

Follow the next steps to do so:

27. In the AWS Management Console, choose the Services menu, and then choose
VPC. Alternatively, you can type the service name in the Search box to access the
service directly.

28. In the left navigation pane, in the SECURITY section, choose Network ACLs.

29. Choose Create network ACL.

30. For Name, use

. For VPC, select

.
31. Choose Create network ACL.

32. Choose the link of the Network ACL you just created. When you see the Details
table, copy the NACL ID in a text editor and save it. You will use it later.

33. In the Outbound rules tab, choose Edit outbound rules.

Adding Rules like these would block whatever Subnet you apply this to, from
communicating to the Database Subnets, but still allow access to the rest of the network.
Note that NACLs are evaluated in the specific order of their Rule #.

34. You will add three rules.

For each rule, choose Add new rule.

Use the following information per rule.:

Rule #: 50
Of type All
Traffic
To the Destination 

And a Deny Behavior
and

7/13
 Rule #: 60
Of type All Traffic
To the Destination 

And a Deny Behavior
and

Rule #: 100

Of type All Traffic
To the Destination 

And an Allow Behavior

35. Once you have added all three, choose Save changes.

After Saving you need to allow access to that subnet from the internet, so recreating
the All Traffic Allow rule for Inbound Rules is necessary.

36. In the Inbound rules tab, choose Edit inbound rules.

37. Choose Add new rule, and then add the followgin information for the rule:

Rule #: 100

Of type All Traffic
To the Destination 

And a Allow Behavior

38. Choose Save changes.

39. In the Subnet Associations tab, choose Edit subnet associations.

40. Next, select both

 and 
subnets, and choose Save changes.

Now, you will confirm the application is working after these changes.

41. Copy the

value to the left of this instructions in a new browser tab and access the Application.
You should see the application come up without issues.

Note: Now, you’ve effectively ensured that if the Load Balancers in your environment
misbehave, they can’t communicate with or compromise the Database servers directly.
But there was no additional hardware, firewall, or complex routing required to make this
simple change in the simple network topology.

8/13
Task 4: Evaluate detailed logging capabilities
You just made several configuration changes, something that on-premises may be difficult
to track them. However, using CloudTrail we can see the different actions that took
place throughout the lab so far.

42. In the AWS Management Console, choose the Services menu, and then choose
CloudTrail. Alternatively, you can type the service name in the Search box to
access the service directly.

The Dashboard shows us some recent events, but you will want to see the API calls you
just did throughout this lab.

43. In the left navigation pane, choose Trails.

44. On the Trails page, find the name of the trail you created earlier (

).
45. In the row for the trail, choose the value for the S3 bucket (

).

The Amazon S3 console opens and shows that bucket, at the top level for log files. Because
you created a trail that logs events in all AWS Regions.

46. Choose the

link.

It shows you each Region folder. The hierarchy of the Amazon S3 bucket navigation at
this level is bucket-name/AWSLogs/account-id/CloudTrail.

47. Choose the folder for the AWS Region where you want to review log files. For
example, to review the logs in this lab, choose us-west-2.

48. Navigate the bucket folder structure to the year, the month, and the day where you
want to review logs of activity in that Region. In that day, there are a number of files.
The name of the files begin with your AWS account ID, and end with the extension
.gz. For example, if your account ID is 123456789012, you would see files with
names similar to this: “123456789012_CloudTrail_us-east-
2_20190610T1255abcdeEXAMPLE.json.gz”.

To view these files, you can download them, unzip them, and then view them in a plain-
text editor or a JSON file viewer. Some browsers also support viewing .gz and JSON files
directly. To open and view the file:

49. Choose the checkbox next to the most recent file.

50. Choose the Download option, and save the file locally.

9/13
 51. You can open the unzipped file with a text editor. We recommend using a JSON
viewer, as it makes it easier to parse the information in CloudTrail log files.

As you’re browsing through the file content, you might start to wonder about what you’re
seeing. CloudTrail logs events for every AWS service that experienced activity in that AWS
Region at the time that event occurred. In other words, events for different AWS services
are mixed together, based solely on time. To learn more about what a specific service logs
with CloudTrail, including examples of log file entries, see the list of supported services
for CloudTrail, and read the CloudTrail integration topic for that service. You can also
learn more about the content and structure of CloudTrail log files by reviewing the
CloudTrail log event reference.

You might also notice what you’re not seeing in log files in US East (Ohio). Specifically,
you won’t see any console sign-in events, even though you know you logged into the
console. That’s because console sign-in and IAM events are global service events, which
are usually logged in a specific AWS Region. Those files are not accessible in this lab, but
the following snippet represents an event similar to what you would find in those:

"eventVersion": "1.05",

"userIdentity": {

"type": "IAMUser",

"principalId": "AKIAIOSFODNN7EXAMPLE",

"arn": "arn:aws:iam::123456789012:user/Mary_Major",

"accountId": "123456789012",

"userName": "Mary_Major"

},

"eventTime": "2019-06-10T17:14:09Z",

"eventSource": "signin.amazonaws.com",

"eventName": "ConsoleLogin",

"awsRegion": "us-east-1",

"sourceIPAddress": "203.0.113.67",

"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101

Firefox/60.0",

"requestParameters": null,

"responseElements": {

"ConsoleLogin": "Success"

},

"additionalEventData": {

"LoginTo": "https://console.aws.amazon.com/console/home?
state=hashArgs%23&isauthcode=true",

"MobileVersion": "No",

"MFAUsed": "No"

},

"eventID": "2681fc29-EXAMPLE",

"eventType": "AwsConsoleSignIn",

"recipientAccountId": "123456789012"

This log file entry tells you more than just the identity of the IAM user who logged in
(Mary_Major), the date and time she logged in, and that the login was successful. You can
also learn the IP address she logged in from, the operating system and browser software

10/13
of the computer she used, and that she was not using multi-factor authentication.

Now that you have a trail, you have access to an ongoing record of events and activities in
your AWS account. This ongoing record helps you meet accounting and auditing needs for
your AWS account. However, there is a lot more you can do with CloudTrail and
CloudTrail data.

Next, you will go to the AWS Config service.

52. In the AWS Management Console, choose the Services menu, and then choose
Config. Alternatively, you can type the service name in the Search box to access
the service directly.

53. In the Dashboard, you will see all of your resources, including some called EC2
NetworkAcl. If you are not able to see the resources, wait until the list is
populated.

Note: If you don’t see any entry of Type EC2 Network ACL, in the left navigation pane,
choose Resources. Using the Resource type dropdown you can filter using the

type.
54. Choose the EC2 NetworkAcl link. That gives you a list of ACLs. Choose the link in
the Resource Identifier column that matches the NACL ID that you copied
earlier in this lab when you created the Network Access List.

In the details view of the ACL, you can also see a visual Resource Timeline.

55. Choose Resource Timeline.

In the resource timeline, you can see the changes that occurred over the past few minutes.
If you expand Changes you can see exactly what changes you made to the resource,
including what you applied to as a Relationship Change.

Task 5: Minimize admin access risk

Finally, you will further reduce administrative risks by reducing access and improving
logging. With your current setup, there is still a risk of open administrative ports. It’s a
bigger risk if those ports are open to the internet and a smaller risk if open internally for
malware to find.

You will analyze this further:

56. In the AWS Management Console, choose the Services menu, and then choose
VPC. Alternatively, you can type the service name in the Search box to access the
service directly.

57. In the left navigation pane, in the SECURITY section, choose Security Groups.

11/13
 58. Check the wa-asg-sg security group.

59. In the Inbound Rules tab you will notice there is no rule to access the instances
using SSH protocol (Port 22).

This is great, but with no access through port 22, how can you log into the instance and
monitor it if you need to?

For that purpose, you will use AWS Systems Manager. You are already familiar with
this service because you used it in Lab 1.

Systems Manager has a feature called Session Manager that will allow you to connect
to the instances even though they are not open for SSH communication.

60. In the AWS Management Console, choose the Services menu, and then choose
Systems Manager. Alternatively, you can type the service name in the Search
box to access the service directly.

61. In the left navigation pane, in the Node Management section, choose Session
Manager.

62. Choose Start Session.

The setup uses Amazon Linux 2 instances, they have the Systems Manager agent installed
by default. Thanks to that, you can start a session and access the instances.

63. From the listed instances, select one with its name starting with
, and then choose Start Session.

A new tab/window will be opened in your browser.

Next you will determine if this terminal belongs to one of the EC2 instances provisioned
for this architecture.

64. In the terminal, type:

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-

metadata-token-ttl-seconds: 21600"`

curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-

data/instance-id

Does that instance ID look familiar?

curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-

data/security-groups

That looks like the Security Group we checked, doesn’t it?

Should it work?

ping 8.8.8.8

12/13
Sure looks like an EC2 instance!

Lab Complete
Congratulations! You completed the lab.

You have successfully set up this AWS environment for strong logging with AWS
Cloudtrail and AWS Config, granular communication with Security Groups and NACLs,
and configured your machines to have safe administrative access without requiring access
from the public internet.

End lab
Follow these steps to close the console and end your lab.

65. Return to the AWS Management Console.

66. At the upper-right corner of the page, choose AWSLabsUser, and then choose
Sign out.

67. Choose End lab and then confirm that you want to end your lab.

For more information about AWS Training and Certification, see

https://aws.amazon.com/training/.

Your feedback is welcome and appreciated.

If you would like to share any feedback, suggestions, or corrections, please provide the
details in our AWS Training and Certification Contact Form.

13/13