AWS Security and Encryption:KMS, SSM Parameter Store , Shield , WAF video

transacript as below-

Web Application Firewall(WAF)

"So now let's talk about AWS WAF, the Web Application Firewall. It's used to
protect your web application from common web exploits at the Layer 7. Just a
reminder Layer 7 is HTTP, so it protects you against HTTP exploits. Whereas as
comparison Layer 4 is for TCP or UDP protocol. So this WAF, this Web Application
Firewall can be deployed on the Application Balancer, and API gateway, CloudFront,
the AppSync GraphQL API, or Cognito user pools. So remember, this is very
important. You remember the targets of WAF because the exam will try to trick
you, and for example, make you deploy WAF on an NLB but this is not possible. So
once you've deployed a firewall on these services, you can define web ACL,
they're web access control lists, and their rules. And so you can set a rule, for
example, to filter based on IP addresses. So you can define an IP sets. Each IP
set can be up to 10,000 IP addresses. And if you need more IP addresses, you can
use multiple rules for more IPs. You can also filter based on HTTP headers, body.
You can use URI strings to protect from the most common attacks, such as SQL
injection and cross-site scripting. You can have size constraints to make sure
that the request are only up to, for example, two megabytes or geo match to allow
or block specific countries. And you can even have rate-based rules to count the
occurrences of requests per IP for DDoS protection, for example, to prevent a
specific IP from sending more than 10 requests per second. So these web ACLs,
they're regional, except for CloudFront, where they are defined globally. And if
you see the term rule group, well, it's a set, it's a reasonable set of rules
that you can add it to many web ACL. So this is just to organize them. So WAF has
a really good use case. So what if you want to get a fixed IP on our application
while using WAF with an application load balancer? So WAF does not support the
Network Load Balancer because the NLB operates on Layer 4 and WAF is for Layer 7.
So therefore, to provide WAF, you need to have an application load balancer. But
we know that an application balancer does not have fixed IPs. So to solve a
problem, we can use a Global Accelerator to get fixed IP for application, and
then enable WAF on our ALB. So the architecture looks like this. We have one
region with an ALB and EC2 instances. We're going to front our ALB with a Global
Accelerator to get a fixed IP for our application. And we're going to attach a
Web Application Firewall with a WebACL on the same region as where our
application low balancer is located. And therefore, we have achieved our target
architecture."

AWS Shields-
"So now let's talk about AWS Shields. And Shield is a service to protect yourself
from DDoS attacks. What is DDoS? Well, it's a distributed denial of service. And
the idea is that your infrastructure is going to suddenly receive many, many
requests at the same time from a lot of computers all around the world. And so the
goal of it is to overwhelm and overload your infrastructure. And this way your
infrastructure cannot serve your real users and this is what it's called a
distributed denial of service. So we can protect against it, so we have the AWS
Shield Standard service. It's a free service, it's already activated for every
customer of AWS and is going to give you protection from attacks such as the SYN or
UDP floods or any reflection attack or other layer 3, or layer 4 attacks. And if
you want to get advanced protection, you can use the AWS Shield Advanced service.
So this is an optional DDoS mitigation service. It costs around 3,000 per month per
organization. And the idea is that you're going to get protected against more
sophisticated DDoS attacks on Amazon EC2, Elastic Load Balancing, Amazon
CloudFront, the Global Accelerator and Route 53. It also gives you 24/7 access to
the AWS DDoS response team. So in case you get attacked, you will have someone to
help you and get you along the way. In case you are incurring higher fees because
you are also being attacked, this Shield Advance protects you from these higher
fees. And this Shield Advance has an automatic application layer, DDoS mitigation,
and it's going to mean that it's automatically going to create and evaluate and
deploy WAF rules to mitigate layer 7 attacks. So automatically your web application
firewall will have rules to help you mitigate these attacks, DDoS attacks if they
happen at the layer 7, which is great."

Firewall Manager-
"So now let's talk about the AWS Firewall Manager. So this is a service to manage
all the firewall rules in all accounts of an AWS organization. So the idea is
that you can manage rules across many, many accounts at the same time. So you can
set a security policy, and a security policy is a common set of security rules.
And so this could be Web Application Firewall rules, so they apply it to the ALB,
the API gateways, CloudFronts and so on. Or it could be Shield Advanced rules,
so for your ALB, CLB, NLB, the Elastic IP, and CloudFront. It could be security
policy to standardize security groups for EC2, your Application Load Balancer,
and ENI resources in your VPC. And it could be, as well, rules for your AWS
Network Firewall at the VPC level. So this is something we haven't seen yet or
your Amazon Route 53 Resolver DNS Firewall. So the idea is that Firewall Manager
allows you to manage all your firewalls in one place. The policies are created at
the region level, okay? And then they are applied to all the accounts of your
organization. And on top of it, if somehow in your organization, for example,
you create a WAF rule for an Application Load Balancer, and somehow there's a new
Application Load Balancer being created, then automatically the Firewall Manager
is going to apply the same rule to this newly created ALB. That's a feature of
Firewall Manager. So you may ask yourself, "Well, what is the difference between
WAF and Firewall Manager and Shield?" Well, WAF, Shield, and Firewall Manager
are used together for comprehensive protection of your accounts. So first you
define your Web ACL rules in WAF. And in case you need one-time protection, then
WAF is going to be the right choice for you. But if you want to use WAF across
multiple accounts and accelerate WAF configuration and automate the protection of
new resources, then you would manage your WAF rules within Firewall Manager. And
Firewall Manager will just apply all these rules to all your accounts and all
your resources automatically. So now we also have Shield Advanced to help you get
protected against DDoS attacks. And it has additional features on top of WAF such
as a dedicated support from the Shield Response Team, SRT, advanced reporting,
and also, it can automatically create WAF rules for you. And if you're prone to
frequent DDoS attacks, then you should definitely consider purchasing Shield
Advanced. And so Firewall Manager can also help you deploy Shield Advanced
across all your accounts So hopefully the distinction is pretty clear for you
now."

DDoS Protection Best Practices-

"So here is a lecture that is more focused on the solution architecture, and this
is around DDoS protection and best practices. So let's assume that you have this
kind of architecture. We have an auto scaling group with EC2 instances. It's
fronted by a Elastic Load Balancer, and then your load balancer can be either
exposed by a Global Accelerator as fixed IPs, or it could be fronted, for
example, by CloudFronts. CloudFronts can be linked to WAF, a web application
firewall, and so on. You can have Route 53 for DNS routing. And finally you could
also have another architecture where you have CloudFront and the API gateway. So
this is just to represent the kind of combinations you can do. Obviously there
are more than one, but the idea's that we're going to discuss thanks to the
letter BP1, best practice one, best practice two, et cetera, what the
implications are in terms of DDoS resiliency, okay? So by using CloudFront, we
are actually at the Edge. So this slide is all about Edge location mitigation.
That means that your web application delivery is at the Edge, and so you're going
to be protected against DDoS common attacks by using Shield, just a normal setup
of Shield's, so SYN floods and UDB reflection. If you use the Global Accelerator,
this is going to be able to access your application around the world, again at the
Edge. And again, it's fully integrated with Shield for DDoS protection. So it's
very helpful if your backend is somehow not compatible with CloudFronts. In this
case, you would have Global Accelerator in front of it, and so that means that no
matter what backend you have, either using CloudFront or the Global Accelerator,
you will be fully distributed at the Edge of AWS and the Edge location will be
DDoS protected. Also, if you use Route 53, then the domain name resolution is
global, it's at the Edge, and you also have a DDoS protection mechanism on your
DNS. So we understand that if we're at the Edge, we can have a better DDoS
protection. Next, we can have the best practices for DDoS mitigation. So first,
let's look at the infrastructure layer defense. This is BP1, BP3, and BP6. So the
idea is that by using CloudFront, Global Accelerator, Route 53 and the Elastic
Load Balancing, we protect our Amazon EC2 instances against high traffic. And
this is the idea that by using all these services, the traffic is going to be
handled by most of them before ever reaching our EC2 instances. Now, if we enable
our EC2 instances with auto-scaling, that means that in case the traffic does
indeed reach our auto scaling group, we can scale automatically to accommodate
for a greater load on our application. And if we use Elastic Load Balancing, then
the ELB is going to automatically spread the traffic across many EC2 instances.
And so that means that each EC2 instances will have a manageable amount of traffic
onto them, provided the fact that the auto-scaling group of course has scaled as
well. Now at the application layer defense, we can detect and filter malicious
requests at BP1 and BP2. So the idea is that CloudFront is going to serve static
content, and serve it from Edge locations, therefore protecting your backend. And
then you can use WAF on top of CloudFront, or your application load balancers to
filter and block requests based on request signatures, for example, you can block
specific IPs, specific request types and so on. And if you use the WAF rate based
rules, you can automatically block the IPs of bad actors. So you can use a bunch
of managed rules on WAF to block IPs based on reputation or block anonymous IPs
and so on. And using CloudFront, you can block specific geographies. The idea is
that CloudFront and WAF are managed services, and so they will take care of
filtering some requests for you, so you can be protected against DDoS attack.
And of course using Shield Advanced, so in case you enable it, then it will
automatically create WAF rules for you to mitigate layer seven attacks. So this
is good for the application layer defense, again to protect your EC2 instances
from getting any bad request or at least minimize them. And also, how do we reduce
our attack surface? So the idea with this architecture is that the backend AWS
resources are used to serve our application, are hidden. So we have BP1, BP4, and
BP6. So if we use CloudFront, the API Gateway, or Elastic Load Balancing, we can
hide our backend resources. The attacker will never know if it's a lambda function
or EC2 instances or ECS tasks, and so on, because we have used other things in
front of them. Also, we can set up security groups and network ACLs to filter
traffic based on specific IPs, and elastic IPs, if we use them, they can be
protected by AWS Shield Advanced as well. And then you can protect API endpoints
themselves, so if you use the API gateway, then you can hide whatever backend it
is, whether it be EC2, lambda or something else. And if you use the Edge
optimized mode, you're already global. Otherwise you can use CloudFront plus the
regional mode, which gives you more control for DDoS protection. And if you use
WAF on top of the API gateway, then you can get filtering of any HTTP request.
And if you set up the API gateway correctly, you can have burst limits, you can do
headers filtering, and you can use and force API keys for your users, therefore
protecting yourself from a DDoS attack. So hopefully this kind of architecture
makes sense and you understand the different ways you can protect against DDoS,
because the exam will ask you to think just like that, okay?"

Amazon GuardDuty-
"So now let's talk about Amazon GuardDuty. GuardDuty helps you do intelligent
threat discovery to protect your AWS accounts. How does it do it? Well, it has
machine learning algorithm, performs anomaly detection and uses third party data
to find these threats. So to enable it, it's just one click. Then you have a 30
days trial. You don't need to install any software. So GuardDuty is going to look
at a lot of input data, such as your CloudTrail event logs to look for unusual
API calls or unauthorized deployments. It's going to look at your management
events and your data events. So for example, on the management side, the create
VPC Subnet event and so on, whereas on the S3 data events for example, get
object, list objects, delete objects and so on. And then for VPC flow logs, it's
going to look at unusual internet traffic. It's going to look at unusual IP
addresses. DNS logs to look at EC2 instances, sending encoded data within DNS
queries, which would mean they're compromised and optional features to allow you
to analyze, for example, other input data sources such as your EKS audit logs,
your RDS and Aurora login events, your EBS, your Lambda and your S3 data events.
So we can also set up EventBridge rules to be notified automatically in case you
have findings. And then these rules can target whatever EventBridge can target,
such as AWS, Lambda, or SNS topics. Also, this can come up in the exam. GuardDuty
is a very good tool to protect you against cryptocurrency attacks because there
is a dedicated finding for it. So it knows how to analyze all these input data
and find that there is a cryptocurrency attack. So to summarize, within GuardDuty,
we have several input data. We have the VPC flow logs, the CloudTrail logs, and
the DNS logs that will be, no matter what, into GuardDuty as well as some
optional features you can enable, such as your S3 logs, your EBS volumes, your
Lambda network activity, RDS and Aurora login activity and your EKS logs and
runtime monitoring as well as most likely, more features over time that I will
not put here because you get the idea of optional features. And so from all these
things, then GuardDuty can generate findings and if these findings are detected,
an event is created in Amazon EventBridge. And therefore from EventBridge, thanks
to rules, we can trigger automations, for example, using Lambda functions or
send notifications, for example, using SNS."

Amazon Inspector-
"So now let's talk about Amazon Inspector. So Amazon Inspector is a service that
allows you to run automated security assessments on a couple of things. First of
all, on the E2 instances. So you are going to be leveraging the Systems Manager
agent on your EC2 instances and Amazon Inspector is going to start to assess the
security of that E2 instance. It's going to analyze against unintended network
accessibility and also analyze the running operating system for known
vulnerabilities. This is done continuously. Then we have also Amazon Inspector
for your Container Images push to Amazon ECR. For example, your Docker images. So
as your Container Images are being pushed to Amazon ECR, they will be analyzed by
Amazon Inspector against known vulnerabilities. And we also have Amazon Inspector
for Lambda functions. So Lambda functions, when they're deployed, will be
analyzed again by Inspector for software vulnerabilities in the function code and
the package dependencies. And this assessment happens as the functions are being
deployed. So once Amazon Inspector is done doing its job, it can report its
findings into the AWS Security Hub and also send findings and events of these
findings into Amazon EventBridge. This gives you one way to centrally see the
vulnerabilities running on your infrastructure and with EventBridge you can run
some kind of automations. So what does Amazon Inspector evaluate? You have to
remember, the Inspector is only for your running EC2 instances, your Container
Images on Amazon ECR and your Lambda functions. And it's going to do a continuous
scanning of the infrastructure only when needed. So it's going to look at a
database of vulnerabilities, so CVE, for package vulnerability for EC2, ECR and
Lambda. And it's going to look at network reachability on Amazon EC2 and in case
the database of CVE gets updated, then Amazon Inspector is going to automatically
run again to make sure that all your infrastructure is tested one more time.
Every time it will run, a risk score is going to be associated with all the
vulnerabilities for prioritization. So that's it for Amazon Inspector."

Amazon Macie-
"Now let's talk about Macie. Macie is a fully managed data security and data
privacy service that will use machine learning and pattern matching to discover
and protect your sensitive data in AWS. More specifically, it will alert you
around sensitive data such as personally identifiable information, which is named
PII. So very simply, your PII data will be in your S3 buckets and it will be
analyzed by Macie which will discover what data can be classified as PII. And
then will notify you through EventBridge of the discoveries. Then you can have
integrations into an SNS topic, Lambda functions and so on. So Macie in this
instance will be used to find the sensitive data in your S3 buckets and that's
the only thing it will do. It's just one click to enable it. You just specify the
S3 buckets you want to have and that will be it. So that's it for this lecture,
very, very short, but that's enough on Macie."