Notes
Notes
Design Principles
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.
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 on AWS
AWS communicates about its security and control environment to customers by doing the following:
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.
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.
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.
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.
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.
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 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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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
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.
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:
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.
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:
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
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
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:
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.
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.
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.
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.
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 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.
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:
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.
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.
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.
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.
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
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.
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.
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.
The expression "It’s always Day One" means that there is always something new, disruptive, or innovative to
manage.
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.
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 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.
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 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.
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.
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.
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.
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
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.
AWS CloudTrail tracks the who, what, where, and when of any API calls that occurs in your AWS environment.
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 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
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.
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.
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.
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).
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.
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:
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.
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.
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.
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.
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.
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.
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.
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
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!
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.
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:
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.
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.
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.
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.