# Plan: Establishing your security scope and model
<a name="plan"></a>

Planning is an iterative process as you mature your security model. Key steps in the planning process include:
+ [Understanding the security scope](understanding-the-security-scope.md) – Security scope varies and depends on how the cloud is used.
+ [Choosing a security model](choosing-a-security-model.md) – Identify the best-fitting security model for your security use case.
+ [Creating a business objective model](creating-a-business-objective-model.md) – Define clear goals and mechanisms to measure success.

As you develop your plan, consider the following:
+ Be willing to iterate. Iteration is constant in the cloud. Iteration helps you identify gaps in the plan.
+ Do not start with services. Start with your plan instead of picking out what services you need. This helps drive your organization to its intended outcomes.

# Understanding the security scope
<a name="understanding-the-security-scope"></a>

The AWS shared responsibility model defines how you share responsibility with AWS for security and compliance in the cloud. AWS secures the infrastructure that runs all of the services offered in the AWS Cloud, and you are responsible for securing your use of those services, such as your data and applications.

This shared model can help relieve your compliance and operational burden because AWS operates, manages, and controls many components, from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates. Managed services help you reduce your security and compliance obligations by allowing AWS to manage some security tasks, such as patching and vulnerability management. Using managed services is a best practice in the [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_hardware_a4.html). In general, as infrastructure is modernized, more responsibility is shifted onto the service provider.

The following are three different service examples to help you understand how your security scope changes based on which services you choose:
+ [Infrastructure services](#infrastructure-services)
+ [Container services](#container-services)
+ [Serverless services](#serverless-services)

Your responsibility for security is not static, and it changes with the type of architecture that you select. Your time, effort, and costs are affected by the cloud architecture you choose.

## Infrastructure services
<a name="infrastructure-services"></a>

For infrastructure services, AWS focuses on securing the underlying infrastructure. Within infrastructure services, the scope is larger for the customer because they need to address platform security, OS patching, and application management, as compared to the other models. Amazon Elastic Compute Cloud (Amazon EC2) is an example of a common infrastructure service.



![\[AWS shared responsibility model for infrastructure services.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-accelerating-security-maturity/images/aws-shared-responsibility-model-infrastructure-services.png)


## Container services
<a name="container-services"></a>

As the infrastructure becomes more abstracted and modernized, the footprint becomes smaller. Your scope shrinks because responsibility for some security elements shifts to AWS. Container services is an example which some of the backend responsibilities shift back to AWS. For example, AWS becomes responsible for the operating system (OS) configuration, network configuration, platform management, and application management. Examples of common container services include Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Container Registry (Amazon ECR), Amazon Elastic Container Service (Amazon ECS), and AWS Fargate.



![\[AWS shared responsibility model for container services.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-accelerating-security-maturity/images/aws-shared-responsibility-model-container-services.png)


## Serverless services
<a name="serverless-services"></a>

When using serverless services, nearly all of the responsibility for security belongs to AWS. The scope of your responsibility is minimal. For example, a managed serverless database (DB) eliminates the need for you to secure the network, hardware, and operating system. All OS and DB patching is covered by AWS. Your only concern is securing access to the data through encryption and authentication.



![\[AWS shared responsibility model for serverless services.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-accelerating-security-maturity/images/aws-shared-responsibility-model-serverless-services.png)


# Choosing a security model
<a name="choosing-a-security-model"></a>

You can choose from various security models or approaches for AWS. The choice of approach and the best-fitting model depends on your audience, the target business outcomes, and the overall business process. It is possible to use a blend of multiple models.

**Topics**
+ [Architectural model](#architectural-model)
+ [Maturity model](#maturity-model)
+ [Governance model](#governance-model)

Each model has its own set of benefits and drawbacks. It is important to consider which approach is best suited for your organization. Involve security professionals early in the process of modernizing your infrastructure and adopting cloud strategies. The model you choose has a significant impact on the roles and responsibilities within your organization.

## Architectural model
<a name="architectural-model"></a>

The following image shows the [AWS Security Reference Architecture](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/architecture.html). This architectural approach provides a blueprint for a security model. This approach is best suited when you are engaging with technical teams within your organization. It helps set an  ideal future-state goal. It also aligns with many compliance and AWS frameworks.



![\[An architecture diagram of the AWS Security Reference Architecture\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-accelerating-security-maturity/images/aws-sra-architecture.png)


**Advantages of the architectural model:**
+ Aligns with Health Insurance Portability and Accountability Act (HIPAA) and Health Information Trust Alliance Common Security Framework (HITRUST CSF) requirements
+ Provides an architectural perspective
+ Aligns to cloud strategies and guidance for large enterprises
+ Aligns with the [AWS Cloud Adoption Framework (AWS CAF)](https://aws.amazon.com/cloud-adoption-framework/)
+ Aligns with the [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/)

**Disadvantage of the architectural model:**
+ Is technology-focused rather than business-focused

## Maturity model
<a name="maturity-model"></a>

The [AWS Security Maturity Model](https://maturitymodel.security.aws.dev/en/model/) approach focuses on managing and reducing risk by prioritizing the implementation of security measures. This approach is well-suited for security directors and CISOs, but it's not business-focused.

**Advantages of the maturity model:**
+ Is security focused
+ Is a model that focuses on using an agile-based implementation approach
+ Helps you quickly reduce risk
+ Aligns with the [AWS Cloud Adoption Framework (AWS CAF)](https://aws.amazon.com/cloud-adoption-framework/)

**Disadvantages of the maturity model:**
+ Is technology-focused rather than business-focused

## Governance model
<a name="governance-model"></a>

The [Cloud Foundation on AWS](https://docs.aws.amazon.com/whitepapers/latest/establishing-your-cloud-foundation-on-aws/capabilities.html) model uses a governance, risk management, and compliance (GRC) approach to help organizations meet security and compliance requirements. It defines the overall policies your cloud environment should follow. The capabilities within this model help you define action items, define your risk appetite, and align internal policies.



![\[The aspects of the Cloud Foundation on AWS governance model.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-accelerating-security-maturity/images/governance-model.png)


The Cloud Foundation model is a capability and governance guide that helps you build and evolve your AWS Cloud environment. It is based on a set of definitions, scenarios, guidance, and automations. The guide includes the people, process, and technology aspects of establishing an AWS Cloud environment. It covers six categories of capabilities that are essential for a cloud foundation:
+ Governance, risk management, and compliance
+ Operations
+ Security
+ Business continuity
+ Finance
+ Infrastructure

The guide also provides examples, timelines, and further reading for each capability.

**Advantages of the governance model:**
+ Has a broad technology focus
+ Is designed for reliability
+ Uses an operational approach

**Disadvantage of the governance model:**
+ Is technology-focused rather than business-focused

# Creating a business objective model
<a name="creating-a-business-objective-model"></a>

The business objective model involves defining business outcomes. It is similar to the AWS Cloud Adoption Framework and the AWS Well-Architected Framework. This approach focuses on what the business is interested in by interpreting the target business outcomes. The value of this approach is that it is easy to tie business objectives to security objectives. An example of a business objective is "Enable secure external connections and accelerated provisioning of new users and environments, by automating visibility and measuring against best practices to continuously drive down risk."  You establish technology objectives that help you meet corresponding business outcomes. The business objective model ties back to security objectives, such as maintaining visibility. You then implement a technical objective, such as AWS Identity and Access Management (IAM) security best practices, in order to reduce security risk.

**Advantages of business objective approach:**
+ Includes cost justification
+ Provides a clear, business-aligned security direction
+ Defines measures of success through achieving target business outcomes

**Disadvantages of business objective approach:**
+ Can be time consuming because you have to figure out what the business wants
+ Is business-focused rather than technology-focused