 [ALARM SOUNDING AS RUDY CHECKS BRIEFCASE]

 Ah-ha! The secret ingredient is still here! Phew!

 [RUDY DE-ACTIVATES ALARM AND CLOSES BRIEFCASE]
 Look, last night, someone tried to break into the coffee shop. Thankfully, nothing was
stolen because we have a top-notch security system in place. And just like security of
our coffee shop, security of your AWS account is pretty important.
 [RUDY THROWS THE BRIEFCASE OFF CAMERA]
 In fact, every one of us has a role to play in security. To help you on your way of
becoming a security guru, two crucial security components you should know about
are authentication and authorization.
 Authentication is the process of verifying the identity of a user or entity through
credentials like a username and password combination.
 Authorization, on the other hand, determines which actions users are permitted to
perform in a system or application. This is usually done by granting a user certain
access rights and permissions.
 For instance, authentication permits me to log in to our employee portal. But
authorization limits me to just the areas that I'm allowed to access, such as my own
employee records.
 Authentication and authorization play a vital role in data privacy and protection.
Organizations must, therefore, safeguard all their users' personal information. This
protection helps to maintain customer trust and prevent identity theft and financial
fraud.
 In essence, organizations must prevent unauthorized access and misuse as much as
possible.
 In this spirit, AWS offers multiple security mechanisms like the Shared Responsibility
Model, and a few other examples like:
 - Preventing security incidents through proper permission and access management
 - Proactively addressing security issues through thorough network, application, and
data protection
 - And quickly detecting and responding to security incidents as they occur
 And with that, let’s get things started and take a look at the different security
services, mechanisms, and features that AWS has to offer.

 Key concepts
 Authentication and authorization are two mechanisms that play a
big role in data privacy and system protection. Let's review these
 concepts and dive a little deeper into how security works in the AWS
shared responsibility model.










 Let's explore how user permissions and access control can prevent
security incidents from happening.

 When you create an AWS account, you are given what is called the
AWS account root user. This root user is the owner of the account
and has permission to do anything they want inside of that account.

 This is like being the owner of the coffee shop.

 [SLAPS OWNER TAG ON SHIRT]

 In this situation, let's say I am the owner of the coffee shop. I can
come into the shop, use my credentials to work the register, work
the inventory system, or any other system in the coffee shop. I
cannot be restricted.

 With the AWS account root user, you can access and control any
resource in the account. You can spin up databases, EC2 instances,
machine learning services, or literally whatever you want. Because
that user is so powerful, we recommend that when you create an
AWS account, you associate a strong password with your root user
account. Then, as soon as you log in with your root user, you turn on
multi-factor authentication, or MFA. This ensures that you need not
only the email and password, but also a randomized token to log in.

 Now, that's great. But even with MFA turned on, for security
reasons, you really don't want to use the root user for daily tasks.
So, with that being said, you can control access in a granular way on
AWS by using the service, AWS Identity and Access Management, or
IAM.

 In IAM, you can create IAM users to represent individual identities.

When you create an IAM user, by default, they have absolutely zero
permissions. They can't launch an EC2 instance. They can't create
an S3 bucket. Nothing. You have to explicitly grant the user
permission to do anything in the account. So, remember, by default,
all actions are denied. You have to explicitly allow any action done
by any user. You give people access only to what they need and
nothing else.

 This idea is called the least privilege principle. And the way that you
grant or deny permission is to associate what is called an IAM policy
 to an IAM user. An IAM policy is a JSON document that describes
what API calls a user can or cannot make. Let's take a look at this
quick example.

 In this example, you can see we have a permission statement. This

permission statement has the effect defined as Allow, the action as
s3:ListBucket, and the resource is a unique ID for the S3 bucket.

 So, if I attach this policy to a user, that user could view the bucket
coffee_shop_reports, but perform no other action in this account. To
break this down further, it's good to note that there are only two
potential options for the effect on any policy: either allow or deny.

 For action, you can list any AWS API call, and for resource, you
would list what AWS resource that specific API call is for.

 Now, as a businessperson or non-technical person, you likely would

not need to write these types of policies yourself. But, they are used
all over in AWS accounts. One way to make it more convenient to
manage your users and their permissions is to organize them into
IAM groups. Groups are, well, they are groupings of users. You can
attach a policy to a group and all of the users in that group will
inherit those permissions.

 Alright, so far with IAM, you have the root user—they can do
anything. You have users that can be organized into groups. And
you have policies, which are documents that describe permissions
that you can then attach to users or groups. There is one other
major identity in IAM, and that’s called a role.

 This idea of temporary access is important to understand when

thinking about how IAM roles work in AWS. Roles, similar to users
and groups, can have associated permissions that allow or deny
specific actions. And these roles can be assumed for temporary
amounts of time. It’s similar to a user, but has no static credentials
like a username and password. Instead, it’s an identity that can be
assumed to gain access to temporary permissions. You use roles to
temporarily grant access to AWS resources, to users, external
identities, applications, and even other AWS services.

 Roles are particularly helpful when trying to manage permissions at

scale in an organization. By using roles, you can actually avoid
creating IAM users for every person in your business that needs
access to your AWS account. You can accomplish this by federating
users into your account. This means that they could use their
regular corporate credentials to log into AWS by mapping their
corporate identities to IAM roles.
 IAM Identity Center is a service that can help you set up and
manage this process. With this service, you can set up single sign-
on so that your users get a streamlined login experience when
accessing AWS account resources.

 With IAM, we have authentication and authorization in place. So, I

know my employees will only have access to what they need, which
prevents some security incidents before they can even start.




 AWS account root user

 All AWS accounts are given an AWS account root user. The root user
is the account owner and has permission to do anything inside the
AWS account. You should associate a strong password with this
powerful account and turn on multi-factor authentication (MFA),
which requires at least two verification methods to log in. To
handle daily tasks, you should create other IAM identities, such as
IAM users.
 IAM users
 An IAM user represents a person or application that interacts with
AWS services and resources. It consists of a name and
credentials. AWS recommends creating individual IAM users for each
person who needs to access the AWS account, so they have their
own unique set of security credentials.
 IAM groups
 An IAM group is a collection of IAM users. When you assign
permissions to a group, all users in the group inherit the
permissions. For example, you might assign standard access
permissions to a group called employees so all your employees
receive the same generic access.
 IAM roles
 An IAM role is an identity you can assume to gain temporary access
to permissions. For example, an employee might need to work as a
barista in the morning and a cashier in the afternoon. When
someone assumes an IAM role, they abandon all previous
permissions they had under a previous role and assume the
permissions of the new role.
 IAM policies
 An IAM policy is a JSON document that allows or denies permission
to access AWS services and resources. IAM policies can also define
 the level of access to resources. For example, you can allow
employees to access all the Amazon S3 buckets in your AWS
account or only a specific bucket.


 Now that you understand the basics of IAM, let's see how this really
works. In this demonstration, I'll create a new user and then add
them to a group. Then I'll create a role that can be assumed to gain
access to temporary credentials.

 I'll begin by searching "IAM" in the search bar. And then, I will
choose the IAM service. The IAM dashboard provides a bunch of
different resources for managing user permissions. In this demo,
we'll be focusing on the Access management section of the
navigation pane.

 The first thing we need to do is to create a new IAM user profile for
an employee named John Doe. I'll select Users from the navigation.
And you can see we already have one user here named "admin." I
will go ahead and select Create user.

 And, this brings me to a series of steps that help me define this

user's information. In the first step, I'll give my user a unique name.
john_doe works! And then, I'm going to check the checkbox to
provide user access to the AWS Management Console so that John
can login to the console. Then, I will scroll down and select Next.

 And now we need to set the permissions. At this point, I could

choose to attach permission policies directly to John's user identity.
But, we have a standard set of permissions for our employees that
I'll need to update from time to time. It would be much more
convenient to manage these permissions all at once, instead of
modifying each employee's permissions individually. Thankfully, we
can do this using an IAM group. And wouldn't you know it, that's the
recommended action! Any existing IAM groups will be listed on this
 page with the Add user to group option selected. I can conveniently
add John to the appropriate group if it's already been created.

 Because I want to establish a new IAM group, I will select Create

group. I will name this group "employees." Next, I'll assign
permission policies to the group. I'm presented with a long list of
policies to choose from. I can shorten this list by searching for a
specific policy.

 Or, I can filter the list by choosing from the Filter by Type drop-down
menu. By default, this menu is set to show me all permission policy
types.

 There are two permission policy types to be aware of. AWS

managed policies and Customer managed policies. AWS managed
policies are standalone policies created and administered by AWS. I
can apply these policies to as many users as I want.

 I can also create my own permission policies if I have a specific use

case where I need custom control. These policies can be found
under the Customer managed policies.

 For now, I'm going to provide my employees group with the

ViewOnlyAccess that is managed by AWS. I can add more
permissions in the future, if I'd like. I'm curious about how this policy
works. So, I can expand it to view the JSON and learn more about
this specific policy.

 Next, I will go ahead and select Create user group. And, after the
group is created, I can then select it. And now, I can choose next.
And John will be added to this group, and he will receive the
ViewOnlyAccess permissions granted to the group. Any new group
members will also have these permissions.

 Now we are presented with a page to view the user details and
permissions summary. Everything looks good, so I will choose
Create user to complete John's user account.

 Now let's move on to creating an identity that can be assumed as

temporary, rotating credentials to access AWS resources. For this, I
will create an IAM role.

 I will return to the Users list, select Continue, and then we are
brought back to the dashboard. Now, I will select Roles from the
navigation, and then Create role. For Trusted Entity Type, I'll choose
AWS account. And then I will require MFA to turn on multi-factor
authentication. This will provide an extra layer of security.
 Let's say this temporary role needs access to Amazon S3. I'll select
Next. And then we can search for S3 permissions. I'll type in "s3." I'll
select AmazonS3ReadOnlyAccess and
AmazonS3TablesReadOnlyAccess permission policies for minimum
access to our data. Then, I will scroll down and select Next. At this
step, I'll enter "s3_read_only" into the Role name field and then we
can review the role details. Everything looks good, so I will scroll
down and then select Create role.

 Now, someone can assume the role and the needed permissions to
access Amazon S3, as defined in the policy. When they assume this
role, they will have access to our Amazon S3 bucket, but nothing
else.

 IAM roles are used for many different use cases, including granting
temporary permissions to access specific AWS resources like our S3
bucket. Roles allow AWS services to interact with each other to
enable federated identity access for users and applications, and to
support cross-account access for secure resource sharing.







 Now, let's discuss how you can proactively address some security
issues by protecting your network and applications.

 You might have heard of DDoS, which stands for distributed denial
of service. It's an attack on your enterprise's infrastructure. Your
security team might have written a plan for it, and many businesses
have been devastated by it. But what exactly is it, and more
importantly, how can you defend against it?

 In normal operations, your application takes requests from

customers and returns results. In a denial-of-service attack, a bad
actor tries to overwhelm the capacity of your application, basically
to deny anyone your services. But a single machine attacking your
application has no hope of providing enough of an attack by itself.

 So, the distributed part is when the attack uses other machines
around the internet to unknowingly attack your infrastructure. The
bad actor creates an army of zombie bots, brainlessly assaulting
your enterprise as you process an unbearable workload.

 For example, the UDP flood Denial of Service attack is based on the
helpful parts of the internet, like the National Weather Service.
Anyone can send a small request to the weather service, and say,
"Give me the weather forecast." In return, the weather service's
fleet of machines will send back weather telemetry, forecasts, and
updates. To initiate the attack, the bad actor, and its army of
zombie bots, send a simple request: give me the weather forecast.
But they give a fake return address on the request—your return
address. So, the weather service very happily floods your server
with megabytes of rain forecasts. And your system could be brought
to a standstill by just sorting through the information it never
wanted in the first place. That's just one example of half a dozen
low-level, brute-force attacks, all designed to exhaust your network.

 Fortunately, AWS can automatically defend your infrastructure from

these crippling assaults. How? Let's examine the UDP flood attack.

 The AWS solution here is Security groups. Security groups only allow
in proper request traffic. Things like weather reports use an entirely
different protocol than the ones your customers use. Not on the list,
you don't get to talk to the server. And what's more, security groups
operate at the AWS network level, not at the EC2 instance level, like
 an operating system firewall might. So, massive attacks like UDP
floods just get shrugged off by the scale of the entire capacity of the
AWS Region, not your individual EC2 capacity.

 Another strategy is the use of AWS managed services. Simply

making the front door of your application an Elastic Load Balancer
instead of an EC2 instance does a lot to mitigate an attack. That's
because AWS Shield Standard automatically protects AWS resources
from the most common, frequently occurring types of DDoS attacks.
Shield Standard is built into AWS managed services like Elastic Load
Balancing, CloudFront, and Route 53 at no extra cost.

 AWS Shield can be combined with AWS Web Application Firewall, or

WAF, to further protect your environment. AWS WAF filters incoming
traffic for the signatures of bad actors. It has extensive machine
learning capabilities, and can recognize new threats as they evolve.
So, it can proactively help defend your system against an ever-
growing list of destructive vectors.

 For even more protection, you can use AWS Shield Advanced. This is
a paid service that provides detailed attack diagnostics and the
ability to detect and mitigate sophisticated DDoS attacks.

 Unfortunately, DDoS network and application threats exist. But AWS

infrastructure and specialized security services can help you can
stop these attacks to protect your enterprise.










 Let's return to our coffee shop. Our new app is increasing sales
while also saving our customers time! No more long lines. Order
your coffee, pick it up, and sip that caffeine goodness.

 We need to protect customer data that is shared through the app.

This data includes sensitive personal information, such as phone
numbers and credit card information. Think about it. The last thing
we want is for some hacker to steal our customers' data and run up
high bills on our customers' credit cards! I mean, look, we would
lose customer trust and potentially face legal consequences. These
are big no-nos.
 So, let's proactively secure that data. One well-known method is
called encryption. It's like a lock and key mechanism. If you have
the right key, you can open the lock. If not, then you are locked out.
In this case, we only provide authorized parties with the right key to
encrypt the data. Then, to unlock the lock, they decrypt their data
by using that same exact key.

 This comes in two flavors: encryption at rest and encryption in

transit. At rest means that the data is idle and not moving.

 For example, the secret recipe for Rudy's Rhubarb Refresher,

Trademark, is stored in an Amazon S3 bucket. It's encrypted at rest
but... you know, we've gotten to know each other a bit by now... so
I'll let you in on the secret.... pssshh come closer... closer... The
secret ingredient is....

 [RUDY TRIES TO TALK BUT GETS CENSORED]

 Wait, what? It's....

 [RUDY TRIES AGAIN AND IS CENSORED AGAIN]

 Wait. Who? Okay, look, they won't let me tell you....but I got you
later, boo.

 [RUDY WINKS AT CAMERA]

 Alright, let's examine how some AWS services encrypt data at rest.

 With Amazon S3, all new buckets have encryption configured by

default. Moreover, all new objects that are uploaded to an S3 bucket
are automatically encrypted at rest.

 Amazon EBS volumes and snapshots can be encrypted at rest as

well. In fact, you can encrypt both the boot and data volumes of an
EC2 instance.

 And with Amazon DynamoDB, server-side encryption at rest is

enabled on all table data using encryption keys stored in AWS Key
Management Service, or KMS for short. In fact, KMS can be used
across a wide range of AWS services for that extra bit of control.

 KMS helps you create and manage cryptographic keys. These keys
look like random strings of digits to the human eye, and they can be
used to encrypt and decrypt your data. Additionally, you can set
specific levels of access control for your keys. For example, you can
specify which IAM users and roles are able to manage keys. You can
also disable keys so they can no longer be used. And one other
 important thing to point out is that your keys never leave KMS, so
you have complete control over them.

 Flipping to encryption in transit, it means data is moving between

locations. For instance, our coffee shop app needs to access a
customer's phone number to text them that their order is ready.
This phone number could be stored in a database. But, it would
need to be sent over the network from one AWS service to another
so we know where to send the text message.

 For this, we can use a protocol called Secure Sockets Layer—or SSL,
or Transport Layer Security—or TLS. TLS is an updated version of
SSL. With SSL and TLS, you use certificates to verify the identity and
subsequently establish an encrypted network connection from one
system to another. This means bad actors can't access our
customer's sensitive data in-transit. Actually, if you accessed our
coffee shop website in a browser, you'd see this lock icon on the left
here. The URL would also have HTTPS in the front. HTTPS stands for
hypertext transfer protocol secure, and it means that the site is
secured by an SSL, or TLS certificate.

 The AWS service that centralizes management of certificates is

aptly named AWS Certificate Manager, or ACM. What's nice about
ACM is that it can be used to protect various AWS services, in
addition to your connected on-premises resources.

 And, after securing your at-rest and in-transit resources, make sure
to secure your recipes like the Rhubarb...

 [RUDY IS CENSORED PREMATURELY]

 I didn’t say it this time! I give up.











 By now, you can tell that security is extremely important for all
businesses. You should always be working to prevent and
proactively address security events. You also need to be able to
detect and respond to security issues quickly. Remember our
attempted break-in?

 Sometimes, security events occur due to unaddressed software

vulnerabilities, simply because you didn't know they were there.

 Amazon Inspector helps to bring attention to these potential

vulnerabilities. The way it works is that Amazon Inspector runs
automated security assessments against your infrastructure. It
helps to check on deviations of security best practices, exposure of
Amazon EC2 instances, and vulnerable software version
installations.

 After Amazon Inspector has performed an assessment, it provides

you with a list of security findings prioritized by severity level in the
Amazon Inspector console. Each security issue includes a detailed
 description and a recommendation for how to fix it. You can also
retrieve findings through an API.

 But wouldn't it be nice if we had something looking for security

threats across some of the other resources in our account, too?

 Well, that's why we have Amazon GuardDuty. This service analyzes

continuous streams of your account metadata and network activity
as it looks for threats. It uses integrated threat intelligence, such as
known malicious IP addresses, anomaly detection, and machine
learning to identify threats more accurately.

 After you've detected a security issue, you can use Amazon

Detective to uncover the root cause. Amazon Detective streamlines
the investigative process across your AWS accounts. This service
automatically collects log data from your AWS resources and uses
machine learning and graph analytics to build interactive
visualizations of detected issues.

 These visualizations provide a unified, interactive view of your

resource and user interactions over a configurable timeline. These
insights help you to quickly comprehend security threats so you can
focus on fixing problems.

 As you can tell, AWS provides multiple services to help keep your
resources secure. But it would be really useful if we could somehow
consolidate them all in one place. AWS Security Hub was designed
for this exact purpose. With this service, you can quickly see your
AWS security and compliance state in one comprehensive view.
Security Hub automatically aggregates findings and organizes them
into actionable, meaningful groupings called insights.

 This helps you efficiently maintain a secure, and compliant

environment.

 OK, with that said, it's time to lock things down.

 [ACTIVATES SECURITY SYSTEM WITH KEY FOB]






 AWS security documentation

 There are lots of considerations when dealing with security on AWS. Make sure you
read the documentation on securing your AWS resources because it varies from
service to service.
 For general information on AWS security, identity, and compliance services, refer
to Security, Identity, and Compliance on AWS(opens in a new tab).
 To find answers to questions, troubleshoot issues, and learn more about AWS
security services, refer to the Knowledge Center(opens in a new tab).
 To search through documentation by product category, refer to AWS Security
Documentation(opens in a new tab).
 For expert insights, best practices, and updates on security-related features, refer to
the AWS Security Blog(opens in a new tab).
