0% found this document useful (0 votes)
4 views43 pages

Notes

The document outlines AWS Security Fundamentals, emphasizing design principles such as implementing a strong identity foundation, enabling traceability, and applying security at all layers. It details the AWS shared responsibility model, data center security, compliance, and governance, as well as various AWS services for identity and access management, detective controls, infrastructure protection, and data protection. Key services mentioned include AWS IAM, AWS CloudTrail, Amazon GuardDuty, and AWS Systems Manager, which collectively enhance security and compliance in AWS environments.

Uploaded by

Prateek
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views43 pages

Notes

The document outlines AWS Security Fundamentals, emphasizing design principles such as implementing a strong identity foundation, enabling traceability, and applying security at all layers. It details the AWS shared responsibility model, data center security, compliance, and governance, as well as various AWS services for identity and access management, detective controls, infrastructure protection, and data protection. Key services mentioned include AWS IAM, AWS CloudTrail, Amazon GuardDuty, and AWS Systems Manager, which collectively enhance security and compliance in AWS environments.

Uploaded by

Prateek
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

Training – 1 AWS Security Fundamentals

Design Principles

Implement a strong identity foundation

Implement the principle of least privilege and enforce separation of duties with appropriate authorization
for each interaction with your AWS resources.
Enable traceability

Monitor, alert, and audit actions and changes to your environment in real time. Integrate logs and metrics
with systems to automatically respond and take action.
Apply security at all layers

Rather than just focusing on protection of a single outer layer, apply a defense-in-depth approach with other
security controls.
Automate security best practices

Automated software-based security mechanisms improve your ability to securely scale more rapidly and cost
effectively. Implement controls that are defined and managed as code in version-controlled templates.
Protect data in transit and at rest

Classify your data into sensitivity levels and where appropriate, use mechanisms like encryption and access
control.
Enforce the principle of least privilege

Access to data should only be granted to the people who really need that access. Start with denying access
to everything and grant access as needed.
Prepare for security events

Prepare for an incident by having an incident management process that aligns to your organizational
requirements. Run incident response simulations and use tools with automation to increase your speed for
detection, investigation, and recovery.

AWS shared responsibility model


AWS Global Infrastructure
AWS groups their physical data centers into logical units called Availability Zones. These data centers are
interconnected over fully redundant, dedicated, low-latency connections. WS groups its Availability Zones into
AWS Regions. An AWS Region usually has two or more of these Availability Zones, which are physically
separated and isolated from each other, so that if one Availability Zone goes down, the others are not affected.

Data Center Security


The AWS Global Infrastructure is designed and managed according to security best practices and a variety of
security compliance standards. As an AWS customer, you can be assured that you are building solutions
supported by one of the most secure computing infrastructures in the world. Customers can't visit AWS data
centers to see how they are secured.

Perimeter Layer

AWS data center physical security starts at the Perimeter Layer.

Environmental Layer

AWS carefully chooses their data center locations to mitigate environmental risks like flooding, extreme
weather, and seismic activity. Companies generally use 77 percent fewer servers, 84 percent less power, and
tap into a 28 percent cleaner mix of solar and wind power in the AWS Cloud, compared to their own traditional
data centers.

Infrastructure Layer

Components like backup power equipment; the heating, ventilation, and air conditioning (HVAC) system; and
fire suppression equipment are all part of the Infrastructure Layer and help protect servers and, ultimately,
your data.
Data Layer

Even though protecting your data is ultimately your responsibility in the cloud, AWS takes extra precautions to
protect the media that your data lives on. Storage devices are decommissioned by using NIST800-88
techniques to destroy customer data. AWS is audited by external auditors who inspect our data centers and
confirm that we are following established rules needed to obtain our security certifications. AWS servers can
notify employees of any attempts to remove data. In the unlikely event of a breach, the server is automatically
disabled.

Compliance and Governance

Compliance on AWS

AWS communicates about its security and control environment to customers by doing the following:

 Obtaining industry certifications and independent third-party attestations


 Publishing information about AWS security and control practices in whitepapers and website content
 Providing certificates, reports, and other documentation directly to AWS customers under a non-
disclosure agreement (NDA), as required
 Providing security features and enablers, including compliance playbook and mapping documents for
compliance programs

AWS service spotlight


AWS Artifact

AWS Artifact is a no-cost, self-service portal for access to the AWS security and compliance reports and select
online agreements. Reports available include the AWS System and Organization Controls (SOC) reports,
payment card industry (PCI) reports, and certifications from accreditation bodies across geographies and
compliance verticals.

Entry Points on AWS


API calls: Authentication and authorization

Everything you do on AWS, whether you’re using the management console, the AWS CLI, or one of the AWS
SDKs, requires API calls. What you’re basically doing is sending an API request to an AWS service API endpoint.
Even when an AWS service talks to another service, it’s through API calls. But before the request gets there, it’s
authenticated and authorized by AWS Identity and Access Management, or AWS IAM. Even though it’s your
responsibility to protect your data and resources in the cloud, AWS makes this task much more manageable by
offering services like AWS IAM to help you along the way.

AWS Identity and Access Management


AWS IAM users and groups
When you open an AWS account, the identity you begin with has access to all AWS services and resources in
that account. You use this identity to establish less-privileged users and role-based access in AWS Identity and
Access Management (IAM).

An IAM group is a collection of users. With groups, you can specify permissions for similar types of users. For
example, if you have a group named Developers, you can give that group the types of permissions that
developers typically need.

Types of AWS credentials

Username & Password

A password policy is a set of rules that defines the type of password an IAM user can set. You should define
a password policy for all of your IAM users to enforce strong passwords and regular changing of passwords.

Multi-Factor Authentication

Multi-factor authentication (MFA) is an additional layer of security for accessing AWS services. With this
authentication method, more than one authentication factor is checked before access is granted, which
consists of a user name and password, and the single-use code from the MFA device. AWS Command Line
Interface (AWS CLI) also supports MFA.

User Access Keys

Users need their own access keys to make programmatic calls to AWS using the AWS CLI, the AWS SDKs, or
direct HTTPS calls using the APIs for individual AWS services. Access keys are used to digitally sign API calls
made to AWS services. Each access key credential is comprised of an access key ID and a secret key. Each
user can have two active access keys, which is useful when you need to rotate the user's access keys or
revoke permissions.
Amazon EC2 Key Pairs

To enable Secure Shell (SSH) or Remote Desktop Protocol (RDP) connections to an Amazon Elastic Compute
Cloud (Amazon EC2) instance, AWS uses a public–key infrastructure to sign the login request. The public and
private keys are known as a key pair. To log in to your instance, you must create a key pair, or use an existing
key pair, and provide the private key when you connect to the instance. You can choose to have the Amazon
EC2 key pairs generated by AWS or import your own set of keys.
Amazon EC2 key pairs do not provide accountability (who is using the keys). Therefore, they are not
recommended for routine usage. If you require daily access to EC2 instances, AWS recommends the
following. Add the EC2 instances to a directory domain (Active Directory or Lightweight Directory Access
Protocol [LDAP]) for federated access. This will provide accountability by tracking which user is logging into
which instance.

Additional AWS services for IAM

The following AWS services can also be used to protect credentials, provide user federation, and centrally
manage and secure multiple AWS accounts.

AWS Secrets Manager

AWS Secrets Manager is designed to centrally manage secrets used to access resources on AWS, on-
premises, and third-party services. Secrets can be database credentials, passwords, third-party API keys, and
even arbitrary text.
AWS IAM Identity Center

AWS IAM Identity Center is a cloud single sign-on (SSO) service that provides the central management of SSO
access to multiple AWS accounts and business applications. Users can sign in to a user portal with their
existing corporate credentials and access all of their assigned accounts and applications from one place. IAM
Identity Center includes built-in SAML integrations to many business applications.
AWS STS

The AWS Security Token Service (STS) is a web service that gives you the ability to request temporary,
limited-privilege credentials for IAM users who are taking on a different role, or for users who are being
federated. A scenario in which someone, or something, needs access to your account to perform a specific
task that is not done on a daily basis would be a great candidate for temporary credentials.
AWS Directory Service

AWS Directory Service for Microsoft Active Directory, also known as AWS Managed Microsoft AD, enables
your domain workloads and AWS resources to use managed Active Directory in the AWS Cloud.
AWS Organizations

With AWS Organizations, you can centrally manage and enforce policies for multiple AWS accounts. This
service allows grouping accounts into organizational units (OUs) and using service control policies to
centrally control AWS services across multiple AWS accounts. With Organizations, you can automate the
creation of new accounts through APIs. You can also streamline billing by setting up a single payment
method for all the accounts in your organization through consolidated billing. Organizations is available to all
AWS customers at no additional charge.

Amazon Cognito

With Amazon Cognito, you can add user sign-up, sign-in, and access controls to your web and mobile apps. You
can define roles and map users to different roles so your app can access only the resources that are authorized
for each user. User sign-in can be done either by a third-party identity provider, or directly through Amazon
Cognito.
An Amazon Cognito user pool is a user directory that manages the overhead of handling the tokens that are
returned from social sign-in providers, such as Facebook, Google, and Amazon, and enterprise identity
providers through SAML 2.0. After a successful user pool sign-in, your web or mobile app will receive user pool
tokens from Amazon Cognito. These tokens can then be used to retrieve AWS credentials through Amazon
Cognito identity pools. These credentials allow your app to access other AWS services and you don’t have to
embed long-term AWS credentials in your app.

Detective Controls
Capturing and collecting logs

In AWS, there are a number of approaches to consider when addressing detective controls. AWS CloudTrail
records API calls made on your account. This information helps you track changes made to your AWS resources,
troubleshoot operational issues, and ensure compliance with internal policies and regulatory standards.

AWS CloudTrail is enabled by default on your AWS account. You can use the AWS API call history produced by
CloudTrail to track changes to AWS resources, including creation, modification, and deletion of AWS resources.
Here we have an example of the type of information found in a CloudTrail log file.

 Who made the request?


The log file example that is being analyzed shows that an IAM user named Alice performed some kind
of action. You can verify the user's account ID and access key ID.
 When and from where?
If you scroll down a bit, you can verify the date of the request and the source IP address from where
the request was made. Also available here is the eventName, or the action that was requested, and
what was used to send the request in the userAgent field.
 What happened?
If you continue to scroll down, you can see which resource was affected. Here, you see that an
Amazon EC2 instance of Id "i-ebeaf9e2" was the resource in this request.

Monitoring and notifications

In AWS, you use Amazon CloudWatch to route events and information reflecting potentially unwanted changes
into a proper workflow. CloudWatch can be used to monitor resources and logs, send notifications, and invoke
automated actions for remediation.

Auditing on AWS

The AWS Management Console, along with the AWS CLI, can produce powerful results for auditors across
multiple regulatory standards and industry authorities. The key services to audit include Amazon S3, Elastic
Load Balancing (ELB), Amazon CloudWatch, AWS CloudTrail, and Amazon Virtual Private Cloud (Amazon VPC).
Additional AWS services for detective controls

When talking about monitoring and logging, AWS provides a variety of tools and services.

 Amazon GuardDuty
Amazon GuardDuty is an intelligent threat-detection service that provides customers with a way to
continuously monitor and protect their AWS accounts and workloads. GuardDuty identifies suspected
attackers through integrated threat intelligence feeds and uses machine learning (ML) to detect
anomalies in account and workload activity. It monitors for activity such as unusual API calls or
unauthorized deployments that indicate that a customer’s accounts might have been compromised. It
also monitors direct threats, like compromised instances or reconnaissance by attackers.

 AWS Trusted Advisor


AWS Trusted Advisor is a service that draws upon best practices and inspects your AWS environment,
making recommendations for saving money, improving system performance, or closing security gaps.
You can configure Trusted Advisor notifications to receive weekly emails about any changes. You can
also subscribe to Business-level and Enterprise-level support to access the full suite of Trusted Advisor
best-practice checks.

 Amazon VPC Flow Logs


Many AWS services provide built-in access-control audit trails and logs. You can enable Amazon VPC
Flow Logs to capture information about the IP traffic going to and from network interfaces in your
VPC. VPC Flow Logs can help you with a number of tasks. For example, you can troubleshoot why
specific traffic is not reaching an instance.

 AWS Security Hub


AWS Security Hub gives you a single pane of glass view of your high-priority security alerts and
compliance status across AWS accounts. It provides you a single place that aggregates, organizes, and
prioritizes your security alerts, or findings, from multiple AWS services, such as Amazon GuardDuty,
Amazon Inspector, and Amazon Macie, in addition to AWS Partner solutions.

AWS Config

AWS Config is a continuous monitoring and assessment service that can help you detect non-compliance
configurations in near real time. You can view the current and historic configurations of a resource and use this
information to troubleshoot outages and conduct security attack analyses.

Infrastructure Protection
Protection through isolation

Infrastructure protection ensures that systems and resources within your workloads are protected against
unintended and unauthorized access, and other potential vulnerabilities. With Amazon VPC, you can isolate
your AWS resources in the cloud. Using a VPC, you can launch resources into a virtual network that you have
defined. You can define this network to closely resemble a traditional network that you would operate in your
own data center.

Application and OS security

Securing your network and making sure that all your servers are hardened and properly patched are some of
the tasks required in infrastructure security. AWS Systems Manager has capabilities that help you automate
management tasks. Such tasks include collecting system inventory, applying operating system patches,
maintaining up-to-date antivirus definitions, and configuring operating systems and applications at
scale. Systems Manager helps keep your systems compliant with your defined configuration policies.

AWS Systems Manager features

Automation

Safely automate common and repetitive IT operations and management tasks across AWS resources.
Inventory

Collect data about your instances and installed software to help understand your configurations and
applications. This data includes apps, files, network configurations, and system properties.
Patch Manager

Deploy software patches automatically across large groups of Amazon EC2 or on-premises instances.
Parameter Store

A centralized store to manage your configuration data, whether plain-text data, such as database strings, or
secrets such as passwords. You can separate your secrets and configuration data from your code.
Run command

Manage instances remotely without logging in to your servers. It provides a way of automating
administrative tasks across groups of instances, such as registry edits, user management, and software
installations.
Session manager

Manage Windows and Linux EC2 instances through a browser-based interactive shell or CLI, without the
need to open inbound ports, manage SSH keys, or use bastion hosts.

Additional AWS services for infrastructure protection


Each of the following AWS services can be used to provide protection for your network and infrastructure.

 AWS Firewall Manager


AWS Firewall Manager is a security management service that helps you to centrally configure and
manage AWS WAF rules across your accounts and applications. Firewall Manager is able to bring new
applications and resources into compliance with a common set of security rules from the start.
 AWS Direct Connect
AWS Direct Connect is a cloud service solution that is used to establish a dedicated and secure
network connection from your premises to AWS. Using AWS Direct Connect, you can establish private
connectivity between AWS and your data center, office, or colocation environment.
 AWS CloudFormation
AWS CloudFormation automates and streamlines the task of repeatedly creating and deploying AWS
resources in a consistent manner. With AWS CloudFormation, you can ensure that all of your security
and compliance controls are deployed along with your new environment.

Amazon Inspector

Amazon Inspector is an automated security assessment service that helps improve the security and compliance
of applications deployed on AWS. It continuously scans and assesses applications for vulnerabilities or
deviations from best practices. All findings are aggregated in the Amazon Inspector console, routed to AWS
Security Hub, and pushed through Amazon EventBridge to automate workflows, such as ticketing.

Data Protection
Protection at rest

Protecting data at rest has to do with encrypting data while using one of our storage services, including our
database services. When it comes to Amazon S3, for example, there are two types of encryption options
available.

Protection in transit

Any data that gets transmitted from one system to another is considered data in transit. AWS recommends the
following solutions and best practices.

 AWS services provide HTTPS endpoints using Transport Security Layer (TLS) for communication, thus
providing end-to-end encryption when communicating with the AWS APIs.
 Use AWS to generate, deploy, and manage public and private certificates used for TLS encryption in
web-based workloads.
 Use IPsec with VPN connectivity into AWS to facilitate encryption of traffic.

Additional AWS services for data protection

Each of the following AWS services can be used to provide protection for your data.

AWS CloudHSM

AWS CloudHSM provides hardware security modules (HSM) in the AWS Cloud. An HSM is a computing
device that processes cryptographic operations and provides secure storage for cryptographic keys. With
CloudHSM, you can generate, store, import, export, and manage cryptographic keys, including symmetric
keys and asymmetric key pairs.
Amazon S3 Glacier

Amazon S3 Glacier is a storage service optimized for infrequently used data, also called cold data. This
service provides durable and extremely low-cost storage with security features for data archiving and
backup. Amazon S3 Glacier stores data as archives within vaults. You can enforce compliance controls for
individual Amazon S3 Glacier vaults with a vault lock policy.
AWS Certificate Manager

AWS Certificate Manager (ACM) handles the complexity of creating and managing public SSL/TLS certificates
for your AWS based websites and applications. ACM can also be used to issue private SSL/TLS X.509
certificates that identify users, computers, applications, services, servers, and other devices internally.
Amazon Macie

Amazon Macie uses ML to automatically discover, classify, and protect sensitive data in AWS. Macie
recognizes sensitive data, such as personally identifiable information (PII) or intellectual property. It provides
you with dashboards and alerts that give visibility into how this data is being accessed or moved.

AWS KMS

AWS KMS is a managed service that helps you to create and control the keys used in data encryption. If you
want a managed service for creating and controlling encryption keys, but do not want or need to operate your
own HSM, consider using AWS KMS. You can use the key management and cryptographic features directly in
your applications or through AWS services that are integrated with AWS KMS. This includes AWS CloudTrail,
which helps meet your auditing, regulatory, and compliance needs.

Incident Response
Incident response in the AWS Cloud is faster, cheaper, more effective, and convenient to manage. Your ability to
detect, react, and recover can be significantly enhanced with AWS. The following are some capabilities for
investigation that are possible by using AWS.

The power of APIs for automation

In AWS, you can use APIs to automate many of the routine tasks that need to be performed during incident
response. For example, using a single command, you can isolate an instance by changing the security groups
associated with the instance.
Performing forensics on data volumes

Forensics often require capturing the disk image or as-is configuration of an OS. You can use Amazon
EBS(opens in a new tab) snapshots and the Amazon EC2 APIs to capture the data and state of systems under
investigation.
Operating in a clean room

AWS CloudFormation(opens in a new tab) can be used to quickly create a new, trusted environment in which
to conduct deeper investigation. AWS CloudFormation can deploy preconfigured instances in an isolated
environment that contains all the necessary tools forensic teams need to determine the cause of the
incident.

AWS Step Functions


With AWS Step Functions, you can coordinate multiple AWS services into serverless workflows so you can build
and update apps quickly. Workflows are made up of a series of steps, with the output of one step acting as the
input into the next. Step Functions can be used to design and run workflows that stitch together services, such
as AWS Lambda and AWS CloudFormation, to respond to an incident in the cloud.

DDoS Mitigation
Protection at the edge

A combination of AWS services may be used to implement a defense in-depth strategy when it comes to
distributed denial of service (DDoS) attacks. These services are designed with an automatic response to DDoS
attacks and can help minimize time to mitigate and reduce impact. AWS Edge locations provide an additional
layer of network infrastructure that increases your ability to absorb DDoS attacks and to isolate faults while
minimizing availability impact.

Edge locations are physical data centers located in key cities, that are different from Availability Zones. As
access to certain data increases with time, this data is copied to an edge location near your customer base for
better performance and latency. Threats can then be taken care of at these edge locations, away from your
web applications, AWS resources, and the original data.

AWS services for out-of-Region protection

The following AWS services work seamlessly together to create a flexible, layered security perimeter against
multiple types of DDoS attacks. All of these are referred to as AWS edge services and provide a scalable,
reliable, and high-performance security perimeter for your applications and content.

 Amazon Route 53
Amazon Route 53 is a highly available and scalable DNS service that can be used to direct traffic to
your web application. It includes many advanced features like traffic flow, latency-based routing,
weighted round-robin, Geo DNS, health checks, and monitoring.
 Amazon CloudFront
Amazon CloudFront is a content delivery network (CDN) service that can be used to deliver data,
including your entire website, to end users. CloudFront only accepts HTTPS and HTTP well-formed
connections to prevent many common DDoS attacks.
 AWS Shield
AWS Shield is a managed DDoS protection service that safeguards web applications that run on AWS.
AWS Shield provides always-on detection and automatic inline mitigations that minimize application
downtime and latency.

AWS WAF

AWS WAF helps protect your web applications from common web exploits that could affect application
availability, compromise security, or consume excessive resources. AWS WAF gives you control over which
traffic to allow or block by defining customizable web security rules.

AWS Well-Architected Tool


The AWS Well-Architected Tool is a self-service tool that is designed to help customers review AWS workloads
at any time, without the need for an AWS Solutions Architect. By using this tool, you can review your workloads
using a consistent process, understand potential risks in your workload architectures, and identify next steps
for improvement.

First define your workload, then answer a set of questions across the six pillars of the Well Architected
Framework: operational excellence, security, reliability, performance efficiency, cost optimization, and
sustainability. The AWS Well-Architected Tool then provides a plan describing the improvements that can be
applied to the workload. There’s no charge for the AWS Well-Architected Tool; you pay only for any AWS
resources that you consume. However, the tool is only available in select Regions.

Training – 2 AWS Shared Responsibility Model

Training – 3 Introduction to AWS Identity and Access Management (IAM)

Training – 4 AWS Identity and Access Management (IAM) – Troubleshooting

Overview of AWS Identity and Access Management


What is AWS Identity and Access Management?

AWS Identity and Access Management (IAM) is a web service that helps you securely control access to Amazon
Web Services (AWS) resources. With IAM, you can centrally manage permissions that control which AWS
resources users can access. You use IAM to control who is authenticated (signed in) and authorized (has
permissions) to use resources.

What are some benefits of IAM?


What are the important concepts and terminology I need to know?

IAM Users

An IAM user is an entity you create in AWS to represent the person or application that uses it to interact
with AWS. A user in AWS consists of a name and credentials. IAM users have standard long-term credentials,
such as a password or access keys associated with it.
IAM Groups

An IAM user group is a collection of IAM users. With user groups, you can specify permissions for multiple
users, which can make it easier to manage the permissions for those users.
IAM Roles

An IAM role is an IAM identity you can create in your account that has specific permissions. An IAM role is
similar to an IAM user in that it is an AWS identity with permission policies. These policies determine what
the identity can and cannot do in AWS.

However, instead of being uniquely associated with one person, a role is intended to be assumable by
anyone who needs it. Also, a role does not have standard long-term credentials, such as a password or
access keys associated with it. Instead, when you assume a role, it provides you with temporary security
credentials for your role session.

Roles can also be used to provide temporary access to users who already have passwords elsewhere.
IAM Policies

Access in AWS is managed by creating policies and attaching them to IAM identities (users, groups of users,
or roles) or AWS resources. The policy defines the permissions of the identity or resource.
AWS evaluates these policies when an IAM principal (user or role) makes a request. Permissions in the
policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON
documents.
An AWS managed policy is a standalone policy that is created and administered by AWS. Standalone policy
means that the policy has its own Amazon Resource Name (ARN) that includes the policy name.
An inline policy is a policy that's embedded in an IAM identity (a user, group, or role). That is, the policy is an
inherent part of the identity. You can create a policy and embed it in an identity, either when you create the
identity or later.

Principal

A principal is a human user or workload that can make a request for an action or operation on an AWS
resource. After authentication, the principal can be granted either permanent or temporary credentials to
make requests to AWS, depending on the principal type.
Authentication

A principal must be authenticated (logged in to AWS) using their credentials to send a request to AWS. The
process of logging in requires the submission of information (credentials) that proves the identity of the
user.

The types of credentials include:


 Username and password
 Digital certificate
 Access keys
Authorization

You must be authorized (given permission) to complete your request. During authorization, AWS uses the
values from the request context to check for policies that apply to the request. AWS then uses the policies to
determine whether to allow or deny the request.
Actions or operations

After your request has been authenticated and authorized, AWS approves the actions or operations in your
request. Operations are defined by a service and include things that you can do to a resource, such as
viewing, creating, editing, and deleting that resource.
Resources

After AWS approves the operations in your request, they can be performed on the related resources in your
account.

A resource is an object that exists within a service. Examples include the following:
 An Amazon Elastic Compute Cloud (Amazon EC2) instance
 An IAM user
 An Amazon Simple Storage Service (Amazon S3) bucket
Least-privilege permissions

When you set permissions with IAM policies, grant only the permissions required to perform a task. You do
this by defining the actions that can be taken on specific resources under specific conditions, also called
least-privilege permissions. You might start with broad permissions while you explore the permissions
required for your workload or use case. As your use case matures, you can reduce the permissions you grant
to work toward least privilege.
AWS Security Token Service

AWS Security Token Service (AWS STS) is a web service you can use to request temporary, limited-privilege
credentials for IAM users or users you authenticate (federated users).
AWS Organizations and service control policy

AWS Organizations is a service for grouping and centrally managing multiple AWS accounts. A service control
policy (SCP) limits permissions for entities in member accounts in Organizations.

If you activate all features in an organization, then you can apply SCPs to any or all of your accounts. SCPs do
not grant permissions. Instead, SCPs establish permissions guardrails that specify the maximum available
permissions for an organization, organizational unit (OU), or account.

Gathering Information with the AWS Management Console


Use an architectural diagram

An architecture diagram provides a quick overview of your AWS Cloud environment. These diagrams can help
you and your team understand which types of IAM identities are deployed and which policies are in effect.
How can I test identity-based policies that are attached to IAM users, user groups, or roles?

You can use the IAM policy simulator to test and troubleshoot identity-based policies and IAM permissions
boundaries. Some common things you can do with the policy simulator are as follows:

 Test identity-based policies that are attached to IAM users, user groups, or roles in your AWS account.
 Test and troubleshoot the effect of permissions boundaries on IAM entities.

The policy simulator evaluates statements in the identity-based policy and the inputs you provide during
simulation. It determines whether a requested action will be allowed or denied.

How can I obtain information about my IAM resources using the AWS CLI?

The AWS CLI commands provide basic information about IAM, similar to the AWS Management Console. In
most cases, they provide more details, and the AWS CLI is useful for automating data collection. For examples
of some useful IAM commands and their output, expand each of the following four sections.

Retrieve information about a specified IAM user aws iam get-user --user-name Braket_User

List group members & information about a specified aws iam get-group --group-name developers
IAM group
Retrieve information about a specified IAM role aws iam get-role --role-name Test_Role

Retrieve information about a specified managed aws iam get-policy --policy-arn


policy IAM policy arn:aws:iam::aws:policy/AmazonBraketFullAccess
Here are some tips when troubleshooting with AWS CLI. Expand the following two sections.

Identify the requester aws sts get-caller-identity

Obtain debug logs aws iam get-role --role-name Test_Role --debug

Monitoring IAM
Why is monitoring important for troubleshooting?

You should collect monitoring data from all the parts of your AWS solution so you can more efficiently
troubleshoot a multipoint failure if one occurs. Before you start monitoring IAM, however, you should create a
monitoring plan.

How can I monitor IAM resources?

Monitoring is an important part of maintaining the reliability, availability, and performance of IAM, AWS STS,
and your other AWS solutions. AWS provides several tools for monitoring your AWS resources and responding
to potential incidents. These tools include the following:

 AWS CloudTrail
 AWS Identity and Access Management Access Analyzer
 AWS Identity and Access Management access advisor

How can I use CloudTrail?

CloudTrail captures all API calls for IAM and AWS STS as events, including calls from the console and API calls.
You can filter the CloudTrail logs by specifying a lookup attribute, such as AWS access key, Event ID, Event name,
Event source, Read-only, Resource name, Resource type, and User name.

In the CloudTrail console, you can select Event history from the navigation pane to display the Event history
content pane.

How can I use the IAM Access Analyzer?

IAM Access Analyzer provides the following capabilities:

 IAM Access Analyzer helps identify resources in your organization and accounts, such as Amazon S3
buckets or IAM roles, that are shared with an external entity.
 IAM Access Analyzer validates IAM policies against policy grammar and best practices.
 IAM Access Analyzer generates IAM policies based on access activity in your CloudTrail logs.

How does IAM Access Analyzer work?


1) Create an analyzer

You can set the scope for the analyzer to an organization or an AWS account. This is your zone of trust. The
analyzer scans all the supported resources in your zone of trust.

If you're using AWS resources in multiple AWS Regions, you should create an analyzer in each Region where
you use AWS services. Findings generated by an analyzer in a Region are separate from findings from
analyzers in other Regions.

The zone of trust for the analyzer determines the set of resources that are analyzed. Access to resources
from within the zone of trust is trusted. For example, if you choose an organization, access to any resources
in the organization is considered trusted for any principal in the same organization. You can create only one
analyzer when an AWS account is the zone of trust.

2) Review active findings

After you run the IAM Access Analyzer, the next step is to review any findings to determine whether the
access identified in the findings is intentional or unintentional. You can review findings to determine
common findings for access that is intended, and then create an archive rule to automatically archive those
findings. You can also review archived and resolved findings.

When IAM Access Analyzer finds a policy that allows access to a resource from outside your zone of trust, it
generates an active finding. Findings include details about the access so you can take action.

Findings are generated only once for each instance of a resource that is shared outside your zone of trust.
Each time a resource-based policy is modified, IAM Access Analyzer analyzes the policy.
 If the updated policy shares a resource that is already identified in a finding but has different
permissions or conditions, a new finding is generated.
 If the access in the first finding is removed, that finding is updated to a status of Resolved.

3) Take action

If the access is intended, you can archive the finding so you can focus on reviewing active findings. If the
access is not intended, you can resolve the finding by modifying the policy to remove access to the resource.

What is the IAM access advisor?

The IAM access advisor provides last accessed information to help you identify unused permissions so you can
remove them. You can use last accessed information to refine your policies and allow access only to the
services and actions your entities use.

You can examine last accessed information for IAM on the Access Advisor tab in the IAM console. The Access
Advisor tab is available for the following:

 User groups
 Users
 Roles
 Policies

How can I troubleshoot access denied errors?


Access denied errors appear when AWS explicitly or implicitly denies an authorization request as follows:

 An explicit denial occurs when a policy contains a Deny statement for the specific AWS action.
 An implicit denial occurs when there is no applicable Deny statement and also no applicable Allow
statement.

Troubleshooting MFA-Related Issues


What is MFA?

MFA adds extra security by requiring users to provide unique authentication from an AWS supported MFA
mechanism. This is in addition to their regular sign-in credentials when they access AWS websites or services.
Supported MFA mechanisms include the following:

 Fast Identity Online (FIDO) security key: This is a hardware key.


 Virtual MFA devices: These are virtual authenticator applications.
 Time-based one-time password (TOTP) token: This is a hardware device that generates a six-digit code.

How do I troubleshoot MFA issues?

Do your access denied or unauthorized errors occur only with AWS CLI or programmatic access and not on the
console? It might be because there is an MFA enforcement policy on the user, but the user is not using an MFA-
authenticated set of credentials.

To use MFA with AWS CLI or AWS SDK calls, there is a separate process that includes generating a temporary
session token for the user.

Troubleshooting other MFA-related issues


Troubleshooting FIDO security keys

Trouble with activating a FIDO security key


Issues with sign in using a FIDO security key
Trouble with a lost or broken FIDO security key

Troubleshooting an entity already exists error when creating an MFA device

Symptom

An admin tries to create a MFA device for an IAM user who doesn't have any MFA devices. The admin
receives an error similar to the following:

"MFADevice entity at the same path and name already exists."

Explanation
This error occurs because an MFA device was created but wasn't activated for use with any IAM users. This is
a well-known issue.

Resolution

The steps to resolve this issue are as follows:


1. Deactivate the MFA device.
2. Delete the device.
3. Recreate the MFA device.

Resetting a lost or broken MFA device

Issue
An admin activates MFA for IAM users or the AWS account root user. Subsequently, they need to reset a lost
or broken MFA device, but they no longer have access to their root user account.

Resolution

The steps to resolve this issue involve the following:


1. Recover access to the root user account.
2. Reset the MFA device.

What does it mean to assume an IAM role?

Assuming a role involves using a set of temporary security credentials to access AWS resources that you might
not normally have access to. These temporary credentials consist of the following:

 Access key ID (for example, AKIAIOSFODNN7EXAMPLE)

 Secret access key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY)

 Security token (for example, IQoJv4JpZ2lu..........30j)

You must use all three together to authenticate your requests using the role's temporary credentials. Typically,
you assume a role in your AWS account or for cross-account access.

How does assuming a role work?


When an IAM user assumes an IAM role, there are two sets of permissions involved as follows:

 A permission policy (managed or inline) on the IAM user that allows the user to assume the role.
 A trust policy on the IAM role that trusts the IAM user, which is defined as follows:
A trust policy is a JSON policy document in which you define the principals that you trust to assume
the role. An IAM role trust policy is a required resource-based policy that is attached to a role in IAM.
The principals that you can specify in the trust policy include users, roles, accounts, and services.

Same account: If the IAM user and role are in the same account, a trust policy that explicitly trusts that specific
IAM user is sufficient. The trust policy does not have to trust the root user account as a whole.

Separate accounts: If the IAM user and role are in separate AWS accounts, permissions are required from both
ends. The user’s permission policy must allow the user to assume the role and the role’s trust policy must also
trust the user.

What is SAML?
AWS supports identity federation with Security Assertion Markup Language 2.0 (SAML 2.0), an open standard
that many identity providers use. This feature activates federated single sign-on (SSO) so users can log in to the
AWS Management Console or call the AWS API operations. Administrators do not need to create an IAM user
for everyone in their organization. By using SAML, you can simplify the process of configuring federation with
AWS. You can use an identity provider's service instead of writing custom identity proxy code.

Training – 6 Threat Modeling for Builders 2025

Introduction to Threat Modeling


What is a system model?

A system is group of entities or components that interact with each other to form a complex whole.
Intentionally designed systems often deliver some type of value. A system may be hardware or software. The
set of entities working together that make applications, products, and services can all be considered systems.

A system model is a representation of a system. Models are often used in system design and maintenance to
help everyone understand how the system is meant to work together to produce its intended value.

What is threat modeling?

Threat modeling is a structured approach to identifying threats that may affect a system. A threat is something
that can go wrong in or to a system. Threats can be unintentional, such as a computer processor overheating
causing a computer crash, or intentional, such as a human hitting the processor with a hammer. Threats create
security risk. Security risk is equal to the likelihood of a threat occurring multiplied by the impact.

Threat modeling works to identify, communicate, and understand threats and mitigations within the context of
protecting something of value.

Assets
It is worth understanding which aspects of a system are the most valuable. This helps you decide where to
focus your resources. We recommend identifying the data and assets that exist in your system. You can then
consider where they are processed or stored. This can help you focus on protecting the parts of your system
that store or process the assets and data you value the most.

Why use a threat model?

When to threat model

 Start threat modeling as early as possible in the lifecycle of your system; this gives you more flexibility
on what to do with the threats you have identified.
 Much like software bugs, the earlier you identify threats the more cost effective it is to address them.
 We recommend you threat model often, but remember that the reason to threat model is to drive
improvements to your system, so you should also balance how often you threat model with how much
value you’re getting out of the activity.
 Penetration testers also refer to threat models to understand the service being tested and determine
which mitigations are working as intended. You can use a threat model to inform your penetration test
scope. A scope is the document that describes what you want tested. You can walk through your list of
threats and/or mitigations to identify test cases you want included.

Threat modeling triggers

Good times to revisit your threat model are when you:

 Design a new system or feature.


 Introduce changes to a system beyond the scope of existing threat models.
 Have previous assumptions/models invalidated.
 Identify a new threat to your existing service.

Agile threat modelling

Threat modeling can be done in sprints. As features are designed and implemented, you can threat model
them in parallel. Keep an eye out for potential gaps between separate threat models. Mitigations that cannot
be implemented immediately can be added to your backlog to ensure you keep track of them.

How to threat model

This training proposes an approach that you’ll hopefully find both helpful, as well as adaptable to meet your
needs. It’s based on Shostack's Four Question Frame for Threat Modeling:

Question 1 What are we working on?


This question helps you understand and agree upon the system you are building and
the details that are relevant to security.
Creating models and diagrams are important approaches to help answer this question,
as they help you visualize what you are building. This course focuses on the data flow
diagramming technique.

Question 2 What can go wrong?


Threats are accidental or intentional events that may have unwanted impacts to your
system. For information technology systems, threats normally affect the
confidentiality, integrity, or availability of data that your system processes or stores.
Threats create security risk. It is very difficult to devise a good strategy to secure your
system without a clear understanding of what could go wrong.
Question 3 What are we going to do about it?
Once you have identified what can go wrong, there are four approaches you can take
to do something about it. These are known as risk response strategies:
 Avoid the risk: change your system such that a given risk is no longer possible.
 Mitigate the risk: reduce the likelihood and/or impact of a risk occurring.
 Transfer the risk: get someone or something else to reduce the likelihood
and/or impact of a risk occurring.
 Accept the risk: explicitly decide to do nothing about a risk.
Question 4 Did we do a good enough job?
The whole point of threat modeling is to drive improvements to the system you are
modeling. Whether you are using your threat model to securely design a system or
evaluate an existing one, you can evaluate whether your threat model is helping you
make your system better.

Threat Composer
The open-source Threat Composer tool aims to be a simple threat modeling tool to help humans to reduce
time-to-value when threat modeling. It helps to guide you through the threat modeling process via a workflow.
It helps you create both human readable and machine-readable threat models.

This tool is offered both as standalone web application as a hosted demo and for self-hosted deployment.
Additionally, it is a feature of the AWS ToolKit for Microsoft Visual Studio Code (VS Code), which allows you to
create, view and edit Threat Composer threat models (.[Link] files) directly within VSCode.

Threat Modeling at AWS


Threat model content management

At some point, you will need to decide whether to create fewer, larger threat models, or numerous, smaller
threat models to threat model your system(s). Here are some considerations to keep in mind:

 Threat models are living documents that should be maintained for the lifespan of the system they
model.
 It’s in your best interest to minimize reader cognitive load. You and your team’s future selves will need
to read and understand the threat model.
 Like your code, try to structure your threat models for maintainability. You also want to minimize
friction for anyone who needs to add to it. Ideally, if you or your team think of a new threat, or a new
candidate mitigation, you can add it right away to your threat model.
 Consider whether you need attribution for your threat models. This helps you understand who added
(or removed) content.
 Consider whether you need to version control your threat models. This can help you easily identify
what state your threat model was in at a specific point in time.
 Think about the number of people that need to be familiar with the threat model. As a silly and
extreme example, think about how large and complex a threat model would be that describes the
entire AWS Cloud, and how many people would need to read it. It would be unfeasible to maintain. By
the time a reader had finished digesting the content, the threat model would have been updated in
important ways.

Threat modeling at the feature level

This approach has the following benefits:

 It aligns to the software development lifecycle (SDLC). Having smaller chunks of work allows for more
granular tracking of progress, which aligns with development teams that follow Agile-style delivery,
and gives the management team a constant view of progress.

 It is easier to think about smaller systems. You can focus on the details that matter for threat
modeling, which lets you uncover more potential areas of improvement where you can mitigate
additional threats.

What Are We Working On?


Models and diagrams

A model is some type of abstraction that explains a system. A diagram is a visualization, in this case of a
system.
Data flow diagrams

Data flow diagrams model the exchange of data between system elements, including:

 Processes. Elements that perform computation. They receive data as input and produce data as
output.
 Data stores. Where your data assets are kept at rest.
 External entities. Elements you do not control that interact with your system. These are often found
outside your system boundaries.
 Human actors. Special kinds of entities that model humans who interact with your system. They can
include members of your organization or external humans who have access to your system. It is
helpful to distinguish humans from other external entities because they may behave differently and
have different threats and mitigations.

Zones of trust

A system can be divided into zones of trust that are separated by boundaries. Within a zone of trust, all
elements are considered to be equally or similarly trusted. While each zone may be trusted differently, zones of
trust do not define whether one zone has more or less trust than another. The standard convention for drawing
trust boundaries is a dashed line or square indicating where the separation exists. Zones of trust can be named
for clarity.

What Can Go Wrong?


STRIDE

STRIDE is an acronym of six threat categories. It groups similar threats together by the security property they
violate. A given threat may fit into multiple categories.
STRIDE-per-element

This approach applies STRIDE to each of the data flow diagram elements, namely the:

 Human actors,
 External entities,
 Processes,
 Data stores, and
 Data flows.

Definition of done

When using STRIDE-per-element, try to identify at least one threat for each STRIDE category per element, as
applicable. Until you are unable to identify additional threats, or you run out of time, repeat the process as
many times as necessary until you are unable to identify additional threats.

Planes of operations

Control/administrative planes are used to configure the environment.

The data/request plane is responsible for delivering real-time service.

Simple threat grammar

If you don’t have a preferred way to write consistent and concise threat statements, we recommend you use
this threat grammar structure:

[threat source] [prerequisites] can [threat action], which leads to [threat impact], negatively
impacting [impacted assets].

Calculating risk

Risk is equal to the likelihood of a threat occurring, multiplied by the impact, which is the cost of the
occurrence of the threat.

 Impact: A measure of the potential cost of the damage caused by the threat occurring.

 Likelihood: A measure of the likelihood of the threat occurring over the expected lifetime of the
system.

Risk = Likelihood * Impact

What Are We Going to Do About It?


Risk response strategies
AWS Security Governance at Scale – Technical
Governance at Scale Basics

Using AWS, they can have both governance and agility.

AWS offers a set of management and governance services to help you improve governance control AND
maintain business agility. When IT deploys management and governance services on AWS, they can support
innovation, unclog provisioning bottlenecks, improve their security and compliance posture, enhance
operational efficiency, and reduce costs.

Concerns

Your resources must be centrally managed for audits and compliance in a secured environment. You might
need to ask tough questions.

Focal points
Governance at scale provides answers to these questions by focusing on three major areas: account
management, security and compliance automation, and budget and cost management. These focal points help
you be agile, while ensuring your workloads meet security and compliance requirements.

Account management

Governance at scale processes streamline account management across multiple AWS accounts and workloads
in your company through centralization, standardization, and automation of account maintenance. This is done
through policy automation, identity federation, and account automation.

Security and compliance automation

Governance at scale security and compliance practices consist of three main goals: identity and access
automation, security automation, and policy enforcement.
Budget and cost management

Budget planning and enforcement practices help leaders and staff allocate and manage budgets for multiple
AWS accounts and define enforcement actions. With governance at scale, leaders can make proactive and well-
informed decisions when it comes to budget control and allocation across their organization. This framework
focuses on two items: budget planning and budget enforcement.

Governance Automation
The process of adopting a governance at scale framework is part of your journey to the cloud. This process
consists of three pillars: implement, provision, and operate.

The first service is AWS Control Tower, which provides a governance-at-scale framework that spans all three
pillars. It is a simple way to set up and govern a multi-account AWS solution at scale.

AWS Organizations is a service that aligns a company’s organizational structure with the AWS Cloud. You get a
preconfigured, secure, scalable, multi-account AWS offering called a landing zone. The landing zone supports
the three governance-at-scale focal points that you learned about earlier in this section (account management,
security and compliance automation, and budget and cost management).

AWS Service Catalog, AWS Marketplace, and AWS CloudFormation, along with other services, give you self-
service capabilities. You can provision products and services, manage workloads, and ensure that these
provisioned resources meet the organization’s policies and regulations.

Finally, monitoring services like AWS Config, Amazon CloudWatch, AWS CloudTrail, and AWS Cost Explorer
simplify your efforts to operate by letting you monitor your environment, track resource usage, and enforce
security and compliance.

Implementing with Best Practices


This module focuses on implementing, which helps an organization innovate faster and perform daily activities
in an agile manner.

It's always Day 1

The expression "It’s always Day One" means that there is always something new, disruptive, or innovative to
manage.

AWS Control Tower

You can use AWS Control Tower to set up a multi-account AWS solution based on best practices we have
identified after working with thousands of enterprises. Control Tower is built on trusted and reliable AWS
services, including AWS Service Catalog, AWS SSO, and Organizations.

AWS Control Tower landing zone

You learned that a landing zone is a well-architected, multi-account AWS environment based on security and
compliance best practices. You can also think of it as an enterprise-wide container that holds your OUs,
accounts, users, and other resources subject to compliance regulation. A landing zone can scale to fit the needs
of an enterprise of any size.
Provisioning with Self-Service Capabilities
The previous module described the implementation aspect of the governance at scale lifecycle. Developers
must be agile and focus on what they do best—innovating and adding value to the products they create and
support.

In this section, you will learn about the provision aspect of governance at scale—how developers can work in a
self-service and secure fashion.

Developers must move from concept to production as fast as possible. The ability to move fast has multiple
dependencies in the development lifecycle.

Without governance at scale developers might run into daily challenges with processes, cost, and best practice
implementations.

AWS Service Catalog

AWS Service Catalog provides a single location to centrally manage catalogs of preapproved resources,
grouping them as products. It supports the governance at scale model in the cloud adoption journey, especially
the provision step. It also provides developers with agility through self-service, so they can achieve faster time-
to-market.

AWS Service Catalog is an IT service catalog that manages approved AWS services.

Goals of a self-service solution

Integration with IT Service Management Tools


Using an ITSM solution as your standard platform for requesting enterprise services will have you facing the
following challenges:
AWS offers different ways to manage integration with ITSM tools, such as the AWS Service Catalog API. The API
allows communication with AWS Service Catalog from almost any third-party ITSM tool with integration
capabilities.

Additionally, AWS has two connectors that simplify and streamline the integration process for deploying
Service Now and Jira Service Desk ITSM solutions.

ServiceNow

ServiceNow is a service-oriented enterprise service management platform. End users can access a centralized
catalog to order IT services based on request, fulfillment approvals, and workflows. To integrate the
provisioning of secure, compliant, and preapproved AWS products into their ServiceNow portal, customers can
use AWS Service Management Connector for ServiceNow.

JIRA Service Desk

Jira Service Desk is a flexible, collaborative ITSM solution designed for rapid service delivery. You can manage
the lifecycle of AWS resources from Jira Service Desk with the AWS Service Management Connector for Jira
Service Desk.

Cloud Governance Pillars


Key pillars of effective governance

The first pillar of an effective governance framework is inventory and configuration management. An effective
system maintains a real-time inventory of cloud resources and information about current and historical
configurations.

After the configuration is properly set up and tracked, you must make sure it stays that way. And you must also
verify that it stays compliant. That’s where configuration compliance management comes in. It provides a way
to define policies around best practices and regulatory requirements for cloud resources. Then it alerts
customers in real time when any resource violates the policies.

Inventory and configuration management

 What is currently in my inventory? (Real-time resource inventory)


 What is the latest configuration state of my resources? (Configuration snapshot)
 What relationships exist between my resources? (Resource relationships)
 What configuration changes occurred on my critical workload in a specific time period? (Configuration
history)
 Which EC2 instances are built on top of a certain machine image? (For example, AMI-234314)

Configuration compliance management

 Are my resources still properly configured? (Best-practice configuration checks)


 Do my resources comply with regulatory requirements? (For example, PCI or HIPAA)
 How do I ensure compliance? (Checking for policy violations immediately after a configuration change)
 How can I get notified in real time if certain resources go out of compliance? (Real-time compliance
change notifications)

Key Services to Support Effective Cloud Governance


Governance lifecycle with services

These services work together and play a crucial role in the governance at scale framework.

AWS Config

With AWS Config, you can assess, audit, and evaluate your AWS configurations.

AWS Config monitors and records AWS resource configurations and automates the evaluation of recorded
configurations against desired configurations.

To recap, there are two types of guardrails: preventive and detective. AWS Config rules are added to detective
guardrails. You learned that AWS Control Tower comes with multiple guardrails, in place by default, in AWS
Organizations.

Systems Manager

Systems Manager gives you visibility and control of your infrastructure on AWS. Systems Manager provides a
unified user interface, so you can view operational data from multiple AWS services. It also lets you automate
operational tasks across your AWS resources.

GuardDuty

GuardDuty protects AWS accounts, workloads, and data with intelligent threat detection and monitoring.
GuardDuty is a threat detection service that monitors for malicious activity and unauthorized behavior to
protect AWS accounts, workloads, and data stored in Amazon Simple Storage Service (Amazon S3).

Security Hub

Security Hub is the compliance and security center for AWS customers. With Security Hub, you can centrally
view and manage security alerts and automate security checks.

AWS Security Best Practices: Monitoring and Alerting


Logging Network Traffic

Capture information about the traffic going to and from network interfaces in your VPC.

VPC Flow Logs is a feature that helps you with many tasks, such as diagnosing overly restrictive security group
rules or monitoring the traffic that's reaching your instance.

Flow logs provide visibility into network traffic that traverses the VPC and can detect anomalous traffic or
provide insight during security workflows.

 VPC Flow Logs can be turned on per elastic network interface, per subnet, or per VPC to help you with
several tasks, such as diagnosing overly restrictive security group rules, monitoring the traffic that's
reaching your instance, and determining the direction of the traffic to and from the network
interfaces.
 Turning on VPC Flow Logs on an entire VPC or subnet may generate a very large volume of logs. To
minimize the log volume, filter for desired results, based on need, and confirm you will use the
information before turning on VPC Flow Logs on an entire VPC or subnet.
 Flow logs can be sent to an Amazon S3 bucket or CloudWatch Logs, where you set up alarms or
visualize the data. Use S3 Lifecycle policies to manage large amounts of log data by moving logs to the
appropriate storage tier or expiring log files that are no longer needed. Query logs in Amazon S3 using
Amazon Athena or analyze data with CloudWatch Logs with Insights.

Exempt traffic (not logged)


Not all traffic traversing your network is captured by VPC Flow Logs. It's important to understand what types of
traffic are not captured.

 Traffic generated by instances when they contact the Amazon Domain Name System (DNS) server; if
you use your own DNS server, then all traffic to that DNS server is logged
 Traffic generated by a Windows instance for Amazon Windows license activation
 Traffic to and from [Link] for instance metadata
 Traffic to and from [Link] for the Amazon Time Sync Service
 DHCP traffic
 Mirrored traffic
 Traffic to the reserved IP address for the default VPC router
 Traffic between an endpoint network interface and a Network Load Balancer network interface

Flow logs can be published to Amazon S3 or CloudWatch Logs.

Traffic Mirroring

While VPC Flow Logs can be used for basic flow analysis, they lack full packet-level information. Using the AWS
Traffic Mirroring service, you can copy your traffic from an Amazon Elastic Cloud Compute or Amazon EC2
network interface and send it to a supported target. You can “sniff” the cloud network traffic traveling in and
out of your EC2 instances. The copied traffic can be sent to a security or monitoring device for inspection,
threat monitoring, or even troubleshooting.

Traffic Mirroring is another way to perform monitoring. From a security perspective, you can use this to deploy
out-of-band intrusion detection and analysis tools.

Target intrusion detection devices or analysis tools can be deployed as individual instances or as a fleet of
instances behind a Network Load Balancer. Traffic mirroring also supports filters and packet truncation, so you
only extract only traffic of interest.

Components:

 Target—The destination for mirrored traffic. A single instance or appliance or a load balancer
connecting to a fleet.
 Filter—A set of rules that defines the traffic that is of interest. Traffic that will be copied in the traffic
mirror session.
 Session—An entity that describes Traffic Mirroring from a source to a target using filters.

Logging User and API Traffic

AWS CloudTrail tracks the who, what, where, and when of any API calls that occurs in your AWS environment.

AWS CloudTrail Workflow

AWS CloudTrail is turned on in your AWS account when you create it. When activity occurs in your AWS
account, that activity is recorded in a CloudTrail Event. With CloudTrail being turned on by default, you can log
into CloudTrail and review your Event History. In this view, not only do you see the last 90 days of events, you
can also select a specific event to view more information about it.

To access your CloudTrail log files directly or archive them for auditing purposes past the 90-day window, you
can create a specific trail and specify the S3 bucket for log file delivery. Creating a trail (as opposed to just
viewing the default CloudTrail information) also lets you deliver events to CloudWatch Logs and CloudWatch
Events for further action.
CloudTrail destinations

 CloudTrail records API calls in your account and delivers a log file to your selected destination (S3
bucket or CloudWatch Log).
 (Optional) Receive a notification when CloudTrail publishes new log files to your Amazon S3 bucket
with Amazon Simple Notification Service (Amazon SNS).
 Multiple Partners offer integrated solutions to analyze log files.

Security Benefits and Uses of CloudTrail logging

 Security analysis: Perform security analysis and detect user behavior patterns by ingesting CloudTrail
API call history into log management and analytics solutions such as CloudWatch Logs, CloudWatch
Events, Athena, Amazon OpenSearch Service, or another third-party solution.
 Compliance aid: CloudTrail facilitates compliance with internal policies and regulatory standards by
providing a history of API calls in your AWS account.
 Automated remediation: Detect data exfiltration by collecting activity data on S3 objects through
object-level API events recorded in CloudTrail. After data is collected, use other AWS services, such as
Amazon EventBridge and Lambda, to initiate response procedures.

CloudTrail Configuration

Best practice configuration

You can configure CloudTrail to deliver log files from multiple regions to a single S3 bucket for a single account.
When you change an existing single-region trail to log all regions, CloudTrail logs events from all regions in your
account. As long as CloudTrail has permissions to write to the target S3 bucket, the bucket for a multi-region
trail does not have to be in the trail's home region.

You can configure two types of trails:

 A trail that applies to one Region


 A trail that applies to all Regions (This is the default setting when you create a trail in the CloudTrail
console and is a best practice recommendation.)

If you have a multi-account setup through AWS Organizations, you can create a trail that logs all events for all
AWS accounts in that organization. This centralization is important for thorough and accurate monitoring.

Centralizing CloudTrail Logging


Multi-account CloudTrail logging

Centralized CloudTrail logging is a generally recommended deployment to ensure integrity of logs. This is also
the recommended deployment when an organization has a dedicated security team or managed service
provider that will be exclusively handling the logs.

In a multi-account environment using AWS Organizations, you can enable CloudTrail once in the management
account and have it applied to all AWS accounts.

AWS CloudTrail Best Practices

Turn on in all Regions

 Unused Regions are tracked.


 A single configuration step is required.
Turn on log file validation

 Log file integrity is ensured.


 Validated log files are invaluable in security and forensic investigations.
 Industry standard algorithms (SHA-256 or SHA-256 with RSA) are used.
 CloudTrail starts delivering digest files on an hourly basis.
 Digest files contain hash values of log files delivered, signed by CloudTrail.
Encrypt Logs

 Log files are encrypted using SSE-S3 by default.


 You can choose to encrypt using SSE-KMS.
 Amazon S3 will decrypt on your behalf if your credentials have decrypt permissions.
Integrate with CloudWatch Logs

CloudWatch Logs allows you to monitor and receive alerts for specific events captured by CloudTrail. For
example, you can monitor key security and network-related management events, such as failed AWS
Management Console sign-in events or changes made to security groups.
Centralize logs from all accounts

 You can configure all accounts to send logs to a central security account.
 There is a reduced risk for log tampering.
 This can be achieved with AWS Organizations.
 This can be combined with S3 cross-Region replication.
Apply lifecycle policies to logging buckets
 This limits the storage costs of log files.
 This prevents manual pruning and the risk of altering of log files.
 You can automate archiving of log files for long-term storage.

Log Analytics
Amazon OpenSearch Service for Analytics

Amazon OpenSearch Service streamlines the performance of interactive log analytics, real-time application
monitoring, and more. You can use Amazon OpenSearch Service to centralize and analyze logs from disparate
applications and systems across your network and enhance threat detection and incident management.

OpenSearch Service is an open source, distributed search and analytics suite derived from Elasticsearch.
Amazon OpenSearch Service offers the latest versions of OpenSearch, support for 19 versions of Elasticsearch
(1.5 to 7.10 versions), and visualization capabilities powered by OpenSearch dashboards and Kibana (1.5 to
7.10 versions).

Amazon OpenSearch Service advantages

 Secure log analysis: The service offers encryption, authentication, authorization, and auditing
features. It includes integrations with Active Directory, LDAP, SAML, Kerberos, JSON web tokens, and
more. Amazon OpenSearch Service also provides fine-grained, role-based access control to indices,
documents, and fields.
 Compliance assistance
 Support for multiple query languages: Amazon OpenSearch Service supports domain-specific
language (DSL), OpenSearch SQL, and OpenSearch Piped Processing Language (PPL).
 Integration with open source tools: OpenSearch and Kibana dashboards are built in. The service
integrates with Logstach and allows direct access to Elasticsearch APIs and plugins such as Kuromoji,
Phonetic Analysis, Ingest Processor Attachment, Ingest User Agent Processor, and Mapper Murmur3.
 Event monitoring and alerting: Use machine learning anomaly detection based on the Random Cut
Forest (RCF) algorithm to automatically detect anomalies as your data is ingested. Combine this with
alerting to send notifications to stakeholders.

Visibility with Amazon CloudWatch

Indicators of Compromise

Indicators of Compromise (IoC) are largely similar in cloud environments to how they are in traditional IT
environments. Some of the types of anomalies that may be recognized through the use of CloudWatch alarms
include:

 Abnormal CPU utilization


 Significant or sudden increases in database reads
 HTML response sizes
 Mismatched port-application traffic
 Unusual DNS requests
 Unusual outbound network traffic
 Anomalies in privileged user account activity
 Geographical irregularities (source or destination of traffic)
 Unusually high traffic at irregular hours
 Multiple, repeated, or irregular log-in attempts

CloudWatch Alarms

CloudWatch alarms come in two types, a metric alarm and a composite alarm, which can help you to customize
what you are monitoring and ensure that even complex situations composed of corresponding events or
metrics can be captured.

 Metric Alarm
Metric alarms watch a single CloudWatch metric or the result of a math expression based on
CloudWatch metrics. The alarm performs one or more actions based on the result, such as sending a
notification to an Amazon SNS topic, performing an Amazon EC2 action or an Amazon EC2 Auto
Scaling action, or creating an OpsItem or incident in AWS Systems Manager.

A metric alarm has the following possible states:


OK – The metric or expression is within the defined threshold.
ALARM – The metric or expression is outside the defined threshold.
INSUFFICIENT_DATA – The alarm has just started, the metric is not available, or not enough data is
available for the metric to determine the alarm state.

 Composite Alarm
With composite alarms, you can combine multiple alarms into alarm hierarchies. This reduces alarm
noise by initiating just once when multiple alarms are initiated at the same time. You can use this to
provide an overall state for a grouping of resources such as an application, AWS Region, or Availability
Zone. Composite alarms are created using one or more alarm states combined with Boolean operators
AND, OR, and NOT and constants TRUE and FALSE. A composite alarm is initiated when its expression
evaluates to be TRUE.

Enhancing Monitoring and Alerting

Amazon GuardDuty

Logs are also a useful source of information for automated threat detection. GuardDuty is a managed,
continuous security monitoring service that analyzes and processes events from several sources, such as VPC
Flow Logs, CloudTrail management event logs, CloudTrail Amazon S3 data event logs, and DNS logs. It uses
threat intelligence feeds, such as lists of malicious IP addresses and domains, and machine learning to identify
unexpected and potentially unauthorized and malicious activity within your AWS environment. GuardDuty is
a passive service; however, it can be used in a multi-service workflow to initiate remediation through Lambda
or other AWS services and features.
GuardDuty data sources

 DNS Logs
DNS logs are based on queries made from EC2 instances to known questionable domains. DNS logs
are in addition to Route 53 query logs. Route 53 is not required for GuardDuty to generate DNS based
findings.

 VPC Flow Logs


Flow logs for VPCs do not need to be turned on to generate findings. Data is consumed through
independent duplicate stream. Turn on VPC Flow Logs to augment data analysis (charges apply)

 CloudTrail Events
CloudTrail history of AWS API calls used to access the console, SDKs , AWS CLI, and so on, parsed by
GuardDuty. Identification of user and account activity including source IP address is used to make the
calls.

AWS Security Hub

Security Hub is a fully managed AWS service offering that is turned on within a Region in minutes
and aggregates findings across a customer’s accounts.

With Security Hub, you can centrally manage security and compliance findings in one location, reducing the
time spent wrangling data from different locations within the AWS Management Console.

An AWS Security Hub insight is a collection of related findings. It identifies a security area that requires
attention and intervention. For example, an insight might point out EC2 instances that are the subject of
findings that detect poor security practices.

AWS Security Best Practices: Network Infrastructure

Introduction to Securing the Network

Organizations are building complex environments on premises and also in the cloud, where workloads can have
a variety of security requirements. Using security best practices, organizations should strive to design and apply
security at every layer within their workload. A logical starting point in this endeavor is the virtual network and
corresponding infrastructure. Securing this layer generally benefits from segmentation, enforcing security
boundaries, and monitoring of traffic to detect potential anomalies or threats.

Amazon Virtual Private Cloud

With Amazon Virtual Private Cloud (Amazon VPC), you can build a virtual network in the AWS Cloud without
having to worry about physical connectivity. You can define your own network space and control how the
network and resources inside your network are connected.

Built-in VPC security

The enhanced security inherent in a VPC can benefit your security posture. These built-in protections help
defend against attacks such as:
 IP spoofing: Traditional Layer 2 security attacks, including media access control (MAC) spoofing and
Address Resolution Protocol (ARP) spoofing, are blocked
 Packet sniffing by other tenants: Virtual instances running in promiscuous mode cannot receive or
“sniff” traffic destined for other virtual instances.
 Man-in-the-middle (MITM) attacks: All AWS application programming interfaces (APIs) are available
through Transport Layer Security (TLS)-protected endpoints, which provide server authentication.

Network segmentation

Basic VPC and subnet segmentation options

Larger VPCs and subnets are more flexible, but they are harder to scale and manage and make it more difficult
to maintain access controls.

Smaller VPCs and subnets are simpler to secure effectively but might prove less efficient for some business use
cases.

VPC peering

The simplest way to connect two VPCs is to use VPC peering. In this setup, the connection provides full
bidirectional connectivity between the VPCs privately over the AWS backbone without having to leave the AWS
network. This peering connection is used to route traffic between the VPCs. VPCs across accounts and AWS
Regions can also be peered together. VPC peering only incurs costs for traffic traveling over the connection
(there is no hourly infrastructure fee). VPC peering is point-to-point connectivity, and it does not support
transitive routing.

A drawback to VPC peering is that is does not scale well. Scaling is constrained by the maximum limit of 125
peering connections per VPC. Despite this constraint, imagine you had 32 VPCs you wanted to interconnect in a
mesh. This would result in 496 connections to manage!

When to use VPC peering

 Resources in one VPC must communicate with resources in another VPC.


 The environment of both VPCs is controlled and secured.
 The number of VPCs to be connected is less than 10.
 VPC peering offers the lowest overall cost compared to other options for inter-VPC connectivity.

Using VPC endpoints

A VPC endpoint makes connections between a VPC and supported services without requiring that you use an
internet gateway, NAT device, VPN connection, Direct Connect connection, or public infrastructure. VPC
endpoints are virtual devices. They are horizontally scaled, redundant, and highly available VPC components.

There are different types of VPC endpoints used to connect to supported AWS services: interface endpoints,
Gateway Load Balancer Endpoints, and gateway endpoints.

A gateway endpoint is a gateway that is a target for a route in your route table used for traffic destined to
either Amazon Simple Storage Service (Amazon S3) or Amazon DynamoDB. There is no charge for using
gateway endpoints, and Amazon S3 supports both gateway endpoints and interface endpoints.
AWS PrivateLink

AWS PrivateLink provides private connectivity between VPCs, AWS services, and your on-premises networks,
without exposing your traffic to the public internet using interface VPC endpoints. You can connect services
across different accounts and VPCs, without having to configure firewall rules or route tables. PrivateLink does
not require an internet gateway or VPC peering connection. It simplifies your network architecture while
providing the connectivity you need.

Connecting to on-premises environments

 AWS managed VPN


Amazon VPC provides the option of creating an IPsec VPN connection between your remote networks
and Amazon VPC over the internet, as shown in the following diagram. A virtual private gateway
is nothing but a VPN connector on the AWS side of the site-to-site VPN connection. The virtual private
gateway is a logical network device that permits you to create an IPsec VPN tunnel from your VPC to
your on-premises environment.

 AWS Direct Connect


With Direct Connect, you can connect your on-premises network and AWS environment using the
following types of connections to a local Direct Connect facility (which connects securely to the AWS
global infrastructure):

AWS Transit Gateway

Transit Gateway is a highly available and scalable service to consolidate the VPC routing configuration for a
Region with a hub-and-spoke architecture.

Transit gateways permit you to consolidate connections into a single point by attaching:

 One or more VPCs


 A connect SD-WAN or third-party network appliance
 An AWS Direct Connect gateway
 A peering connection with another transit gateway
 A VPN connection to a transit gateway

AWS Security Incident Response Overview

Security Incident Definition


A security incident is any impact on business operations that runs counter to your organization's policies or
standard security practices. The National Institute of Standards and Technology (NIST) defines both security
events and incidents.

 Security Event
An event is any observable occurrence in a system or network. Events can include the following:
o A user connecting to a file share
o A server receiving a request for a webpage
o A user sending email
o A firewall blocking a connection attempt

An adverse event is an event with a negative consequence. These can include the following:

o System crashes
o Packet floods
o Unauthorized use of system privileges
o Unauthorized access to sensitive data
o Malware that destroys data

 Security Incident
A computer security incident is a violation or an imminent threat of violation of computer security
policies, acceptable use policies, or standard security practices.
Examples of incidents include the following:
o A threat actor commands a botnet to send high volumes of connection requests to a web
server, which causes it to crash.
o A threat actor obtains sensitive data and threatens that the details will be released publicly if
the organization does not pay a designated sum of money.
o A user provides or exposes sensitive information to others through peer-to-peer file-sharing
services.

Investigating Security Incidents


AWS has a shared responsibility model. AWS manages the security of the cloud, and customers are responsible
for security in the cloud.

AWS incident response principles and design goals

Establish response objectives

Work with stakeholders, legal counsel, and organizational leadership to determine the goal of responding to
an incident. Some common goals include containing and mitigating the issue, recovering the affected
resources, preserving data for forensics, returning to known safe operations, and ultimately learning from
incidents.
Respond using the cloud

Implement response patterns within the cloud where the event and data occur.
Know what you have and what you need

Preserve logs, resources, snapshots, and other evidence by copying and storing them in a centralized cloud
account dedicated to response. Use tags, metadata, and mechanisms that enforce retention policies. You
will need to understand what services you use and then identify requirements for investigating those
services.
Use redeployment mechanisms

If you can attribute a security anomaly to a misconfiguration, the remediation might be as convenient as
removing the variance by redeploying resources with the correct configuration. If you identify a possible
compromise, verify that your redeployment includes successful and verified mitigation of the root causes.
Automate where possible
As issues arise or incidents repeat, build mechanisms to programmatically triage and respond to common
events. Use human responses for unique, complex, or sensitive incidents where automations are
insufficient.
Choose scalable solutions

Strive to match the scalability of your organization's approach to cloud computing. Implement detection and
response mechanisms that scale across your environments to effectively reduce the time between detection
and response.
Learn and improve your process

Be proactive in identifying gaps in your processes, tools, or people, and implement a plan to fix them.
Simulations are safe methods to find gaps and improve processes.

Security incidents in AWS Cloud domains


Security incidents might happen in three domains of the AWS Cloud: service, infrastructure, and application.

 Service Domain
Incidents in the service domain might affect your AWS account, AWS Identity and Access Management
(IAM) permissions, resource metadata, billing, or other areas. A service domain event is one that you
respond to exclusively with AWS API mechanisms. It might also have root causes associated with
configuration or resource permissions and service-oriented logging.

Example:

An IAM user accidentally posts their access keys on GitHub, and a threat actor uses them to access an
AWS account.

 Infrastructure Domain
Incidents in the infrastructure domain include data-related or network-related activity, such as the
following:
o Processes and data on your Amazon Elastic Compute Cloud (Amazon EC2) instances
o Traffic to your Amazon EC2 instances within the virtual private cloud (VPC)
o Other areas such as containers or other future services

Your response to infrastructure domain events often involves acquiring incident-related data for
forensic analysis. It might include interacting with the operating system of an instance and, in some
cases, AWS API mechanisms.

 Application Domain
Incidents in the application domain occur in the application code or software deployed to the services
or infrastructure. Include this domain in your cloud threat detection and response playbooks and
incorporate similar responses to those in the infrastructure domain.

Security incident response workflow


Detect Phase

The goal of the detect phase is to identify a potential security incident.

The primary part of the detect phase is an alert. An alert generates a notification based on AWS account
activity to initiate the incident response process.

Analyze Phase

The goal of the analyze phase is to determine if the security event is an incident and assess the scope of the
incident. Some of the components you will use during the analyze phase include logs, query capabilities, and
threat intelligence.

Contain Phase

The goal of the contain phase is to minimize and limit the scope of the security incident.

Containment is the process or implementation of a strategy during a security event that minimizes the scope of
the security incident. Additionally, it contains the effects of unauthorized usage within the environment.

Eradicate Phase

The goals of the eradicate phase are to remove unauthorized resources or artifacts related to the security
event and mitigate the causes of the security incident.

Eradication is the removal of suspicious or unauthorized resources to return the account to a known safe state.
The eradication strategy depends on multiple factors, which depend on the business requirements of your
organization.

Recover Phase

The goal of the recover phase is to restore systems to a known safe state and monitor these systems to verify
that the threat does not return.

AWS SimuLearn: Core Security Concepts

You might also like