Your approach to security governance, risk management, and compliance can be an enabler to digital transformation and business agility. As more organizations progress in their digital transformation journey—empowered by cloud computing—security organizations and processes cannot simply participate, they must lead in that transformation.
Today, many customers establish a security foundation using technology-agnostic risk management frameworks—such as the National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF)—to understand their organization’s current capabilities, set goals, and develop a plan to improve and maintain security posture. However, you still need the right model to optimize security outcomes in the cloud. To help you adapt your security program for the cloud, AWS developed two tools the: AWS Cloud Adoption Framework (CAF) and AWS Well-Architected Framework. By complementing your risk-based foundation with the AWS CAF, you can integrate your organizational business drivers at scale as you move to the cloud; and, when you’re ready to implement specific workloads, you can use the AWS Well-Architected Framework to design, measure, and improve your technical implementation.
Through this post, we will explore the value and use of the NIST CSF as a framework to establish your security objectives, assess your organization’s current capabilities, and develop a plan to improve and maintain your desired security posture. We will then look at how to use the AWS CAF to help you begin your digital transformation journey in the AWS Cloud with strategies around organizational practices and governance at scale that align to your business drivers. Next, we will cover how the AWS Well-Architected Framework can enable security best practices at the workload level. And lastly, we will bring everything together to demonstrate how these frameworks are mutually supportive. Figure 1, below, shows how using these three complementary frameworks can optimize your security outcomes. While they can be used independently, each builds upon the other to strengthen and mature your cloud environment and organizational security program.
Using the AWS Cloud Adoption Framework (CAF) and AWS Well-Architected Framework to help meet NIST Cybersecurity Framework (CSF) Objectives and Achieve a Target Profile
Figure 1: How to use CAF and AWS Well-Architected to help meet NIST CSF objectives
As shown in Figure 1, this process involves the following steps:
- Establish your organization’s cybersecurity governance and desired security outcomes with the NIST CSF using the Core functions and implementation Tiers to create your target profile.
- Prepare for cloud migration and implement a scalable foundation using AWS CAF to map those capabilities in the cloud.
- Measure and improve your security architecture and operational practices with AWS Well-Architected and select the AWS services to support your security needs.
As you work to organize and optimize security on AWS, it is important to understand that security is a shared responsibility between you and AWS, as described in our shared responsibility model. This shared model can reduce your security burden and help you attain your risk-based security goals.
NIST CSF – Establish your security governance and desired security outcomes
Ideally, your organization is already using a framework for your organizational security program, but if not, you can consider using the NIST CSF, an internationally recognized risk management framework intended for use by any organization, regardless of sector or size. The CSF provides a simple and effective method for understanding and communicating security risk across your organization. Its technology and industry-agnostic approach allows for an outcome-based common taxonomy that you can use across your business, from the board level to your technical teams. We continue to see accelerating adoption of the CSF across industries and countries, and its principles are becoming standardized approaches, as we see in the latest ISO 27103:2018 and draft ISO 27101 standards.
The NIST CSF consists of three elements—Core, Tiers, and Profiles. The Core includes five continuous functions—Identify, Protect, Detect, Respond, and Recover—which you can map to other standards or control requirements as required by your business. The Tiers characterize an organization’s aptitude and maturity for managing the CSF functions and controls, and the Profiles are intended to convey the organization’s “as is” and “to be” security postures. Together, these three elements are designed to enable your organization to prioritize and address security risks consistent with your business and mission needs. See our whitepaper Aligning to the NIST CSF in the AWS Cloud to understand how AWS services and resources can integrate with your existing program.
NIST CSF use case with identity
Unlike the process for building on-premises networks and datacenters that start with physical facilities, computer and storage hardware, and a network perimeter to protect what is being built out, adopting the cloud starts with identity and access management with the chosen cloud service provider. For AWS, this means creating an AWS account and leveraging AWS IAM to create users and groups, define roles, and assign permissions and policies. Customers who are familiar with the NIST CSF should recognize the five functions—Identify, Protect, Detect, Respond, and Recover. If we look at the Protect function as an example, there are 7 subcategories under the Identity Management, Authentication and Access Control (PR.AC) category:
- PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes
- PR.AC-2: Physical access to assets is managed and protected
- PR.AC-3: Remote access is managed
- PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties
- PR.AC-5: Network integrity is protected (e.g., network segregation, network segmentation)
- PR.AC-6: Identities are proofed and bound to credentials and asserted in interactions
- PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction (e.g., individuals’ security and privacy risks and other organizational risks)
Of the 7 subcategories, PR.AC-2 is a good example of how the shared responsibility model comes into play. With most cloud services, physical security is implemented and managed by the cloud service provider and you get to inherit those controls. This is true for AWS, with the exception that when you utilize a hybrid cloud service, such as AWS Snowball or AWS Outposts, where we will ship a physical device for you to use in your on-prem environment or in the field, you are responsible for their physical security while the physical device is in your custody. For the purpose of this blog, however, we will focus on non-hybrid AWS cloud services, and so we will skip PR.AC-2 for this use case. Customers retain the responsibility to manage the physical security of their datacenters and their physical assets that connect to and access cloud services.
For the remaining 6 subcategories, the AWS frameworks that we will discuss next consist of best practices and implementation sprints that will build out your governance structure, roles and permissions, authentication and access controls, and automated auditing.
The organizational context: Using the AWS Cloud Adoption Framework – Prepare your organization for the cloud
Cloud computing introduces a significant shift in how technology is procured, accessed, used, and managed. To operationalize and optimize your security program for the cloud, your organization needs to understand the new paradigm, and update skills, adapt existing processes, and introduce new processes. The AWS Cloud Adoption Framework (CAF) helps organizations plan for a successful cloud migration, and not just the technical aspects for a single application lift-and-shift, but with the intent to establish an organizational foundation to facilitate deploying, operating, and securing workloads at scale. This may include establishing a DevSecOps culture and processes, training staff and incorporating new paradigms into assignments and work, building shared cloud infrastructure and management service environments, implementing central governance and logging, and other aspects that will integrate with individual applications and use cases. Each organization’s path will be different, so it’s important to plan ahead and connect your business goals and desired security outcomes to the right processes and technologies.
As shown in Figure 2, the AWS CAF is comprised of six perspectives that you can use for planning and strategic considerations, based on common principles that apply to most organizations. Three perspectives—Business, People, and Governance—focus on the organization, while technical aspects are considered in the Platform, Security, and Operations perspectives. As we have seen with the NIST CSF, all of these perspectives influence management of security risks and help achieve your security outcomes. Using the AWS CAF, you can structure your security program to meet your desired outcomes with agility, scale, speed, and innovation that comes with AWS. The Security Perspective of the AWS CAF helps customers operationalize their security goals through its four principles: Directive, Preventive, Detective, and Responsive. Similar to the NIST CSF Identify, the Directive principle provides guidance to help you understand your environment and data in the cloud. Preventive provides guidance to help you operate selected security controls in AWS; Detective provides a means to analyze the environment and alert on anomalies and risks; and then Responsive looks to mitigate detected risks, with an emphasis on automation.
The AWS CAF Security Perspective is comprised of 5 core + 5 augmenting security epics—or themes—as depicted in Figure 3. Consistent with the principles of the NIST CSF, an organization’s foundational capabilities focus on identifying, applying, and scaling security best practices at the program and organizational levels to support business outcomes. Security epics begin with identity and access management as the backbone to secure cloud deployment.
AWS CAF use case with identity
When you look at the Identity and Access Management (IAM) sprint from the AWS CAF Security Epics (Figure 3), you see a few AWS services being applied and configured to govern IAM at scale. Working bottom-up, there are three tiers to consider when designing and building your IAM security—Implement IAM Guardrails, Operationalize IAM, and Privileged Access Management. At AWS, we shift the mindset from “locking down” a system, which implies inflexibility that can impact usability and business agility, to the concept of “guardrails” where security is defined by outer limits that allow freedom of movement within those constraints. This allows for more flexibility for developers and IT operators to explore new methods and technologies to meet dynamic market changes. Specifically for AWS IAM, look at implementing guardrails through services such as AWS Organizations, AWS IAM, and AWS Control Tower. For example, AWS Control Tower provides the easiest way to set up and govern a new, secure, multi-account AWS environment based on best practices established through AWS’ experience working with thousands of enterprises as they move to the cloud.
Next, operationalize IAM by federating with an existing directory service, or creating a cloud directory, and implementing account and access control lifecycles. And, finally, explore options to implement a privileged access management (PAM) solution to protect these important accounts. AWS Secrets Manager and Systems Manager Sessions Manager are two services that can assist with this objective.
Using this small excerpt of the AWS CAF, and with your input into the process, you can design your AWS IAM to meet the NIST CSF subcategories PR.AC-1, 3, 4, 6, and 7 highlighted above.
Secure and resilient system architecture: Using AWS Well-Architected Framework to measure and improve your workload architecture
The AWS Well-Architected Framework helps you understand considerations and key decision points for building systems on AWS— it is a framework for guiding and evaluating your workload architectures. By using AWS Well-Architected, you will learn architectural best practices for designing and operating reliable, secure, efficient, and cost-effective systems in the cloud. It provides a way for you to consistently measure your architectures against best practices and identify areas for improvement. The process for reviewing an architecture is a constructive conversation about architectural decisions and having AWS Well-Architected systems increases the likelihood of business success.
To assist customers in documenting and measuring their workloads, we offer the AWS Well-Architected Tool (see Figure 5)— a questionnaire available on the AWS Management Console that helps you answer, “Am I well-architected?” AWS Well-Architected focuses on the workload level—your infrastructure, systems, data, and processes—by examining five core pillars: Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization.
You can use AWS Well-Architected for designing, evaluating, and continuously improving your architectures. After preparing, planning, and scaling for cloud migration using the Cloud Adoption Framework, AWS Well-Architected can inform how you secure specific workloads in line with the security outcomes (and Target Profile) applied from the NIST CSF.
AWS Well-Architected use case with identity
There are five areas in the security pillar of the AWS Well-Architected Framework: Identity and Access Management (IAM), Detection, Infrastructure Protection, Data Protection, and Incident Response. AWS Well-Architected provides guidance for secure implementation and approaches for selecting the right AWS services to put these core security practices in place in your workloads. You might notice that these areas are similar to those under the AWS CAF security perspective. That’s because those capabilities that were identified at the strategic level should be addressed at the technical layer. That traceability from business requirement to technical strategy to technical architecture and operations is a crucial element to make sure security is applied at all levels of your organization, and that it is meeting a business need.
When you read through the IAM of the AWS Well-Architected security pillar, you’ll see some workload-level best practices for activities like multi-factor authentication, use of temporary credentials, auditing, and least privilege. Following these guidelines can help you meet NIST CSF subcategories 1, 3, 4, 6, and 7 for individual workloads and applications, uniquely for each if needed.
For example, PR.AC-1 includes an objective to audit for authorized devices, users, and services. Although there are several options to implement auditing, and areas to focus on, one of the AWS Well-Architected best practices is to audit and rotate credentials periodically. Following the general guidance below along with prescriptive AWS service guidance, you can design your workload to help meet this requirement.
In support of this use case, AWS Well-Architected recommends that you transition from user and group permissions to the use of inherited roles for human and machine principals, retire long-term credentials and access keys for temporary credentials and MFA where appropriate, and then use automation to verify controls are enforced.
Putting it all together
Using NIST CSF, AWS CAF, and AWS Well-Architected, you can tailor your approach to incorporate security management best practices for your cloud journey. These three frameworks offer related, but distinct lenses on how to approach security for your organization, connecting business goals and outcomes to your security program.
Using the NIST CSF, you can develop an organizational understanding to managing security risks. Using the AWS CAF, you can plan your cloud security approach and map activities to security controls operating in the cloud and scale them throughout the organization. This will help you build out your architecture. You can use AWS Well-Architected to consistently measure your workload against best practices and identify areas for improvement.
The intent of this blog post is to demonstrate how the AWS Cloud Adoption Framework (CAF) and AWS Well-Architected can help you align with and meet the NIST Cybersecurity Framework (CSF) objectives, and provide an understanding that they are mutually supportive.
Below are a few recommendations to help you take advantage of this new understanding and guide you through the different frameworks that can help you meet your security and compliance objectives:
- Download and review:
- Use the AWS Well-Architected tool to perform a self-assessment of your alignment to AWS best practices. If you have questions about the results from your well-architected review and:
- you do not have a support plan and are not assigned an AWS account executive, leverage the free AWS Forums.
- you have Basic, Developer, or Business Support, and you have an assigned AWS account executive, request a meeting with a solutions architect to discuss.
- you have Enterprise Support, contact your aws account executive and technical account manager (TAM) to request a meeting to discuss.
- If you’re not an existing customer, start your journey on AWS by reaching out to us here.
- If you’re looking for migration support, look into AWS Professional Services offerings and AWS consulting partners that can assist with implementing the AWS CAF and WAF as part of your cloud migration or optimization strategy.
- If you’re new to AWS, there are many online and in-person training and certification options provided by AWS and our partners.
If you have feedback about this post, submit comments in the Comments section below.
Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.