Partner Hosted Foundational Technical Review

Partner Hosted Validation Checklist

October 2021 - 2021_q4_v1

Introduction

The Foundational Technical Review ('FTR') assesses an AWS Partner's solution against a specific set of AWS best practices around security, performance, and operational processes that are most critical for customer success. Passing the FTR is required to qualify AWS ISV Partners for APN programs such as AWS Competency and AWS Service Ready but any AWS Partner who offers a technology solution is eligible to request a FTR review through Partner Central.

Foundational Technical Review Lens in the Well-Architected tool helps AWS Partners with hosted workloads prepare for an FTR. The FTR Lens has some additional best practices which are not covered in the FTR. These additional best practices will be added to FTR over-time. We strongly recommend that you follow all the best practices in the FTR lens including the ones which are not part of FTR at the moment.

This checklist is applicable to solutions which are hosted by the Partner (e.g. SaaS solution). If your solution is deployed and managed by your customers in their own account, please use the checklist for customer deployed solution.

Expectations of Parties

AWS Partners must review this document in detail before submitting an AWS Foundational Technical Review request. If items in this document are unclear AWS Partners should contact their Partner Development Representative (PDR) or Partner Development Manager (PDM). AWS reserves the right to make changes to this document at any time.

FTR requests must be submitted on the APN Partner Central. For more information on how to submit a request, please see the "Request an FTR" section on this page.

For the details on FTR process please see the FTR guide. If you need more information, please contact your PDR or PDM. You can can also request an FTR using alternative manual process. Please see the FTR guide for more information.

After submitting a request, an AWS Partner Solutions Architect will review your request and reach out to you, if any additional information or a phone call is required.

The PSA approves an FTR if the solution meets all FTR requirements. If the solution has unfulfilled requirements, the partner can remediate all unfulfilled requirements to complete the FTR. If the FTR is not completed within six months, the Partner must submit a new FTR request and meet all the FTR requirements effective at that time which may include additional controls.

AWS Foundational Technical Review Prerequisites

The following items will be verified by AWS before a technical validation is executed.

  1. 1.0Foundational Technical Review Requirements

    1. 1.1AWS ISV Partner Path Membership

      Partners must be enrolled in the AWS ISV Partner Path. SI Partners should talk to their PDR/PDM on how to join the AWS ISV Partner Path.

Partner Hosted FTR Requirements

The following requirements apply to any components hosted and operated by the AWS Partner in their own AWS account. The controls which include a Center for Internet Security(CIS) benchmark ID are covered by the automated AWS account scan. You do not have to respond to them in self-assessment.

Support Level

  • SUP-001 - Enable AWS Business Support (or greater) on all production AWS accounts or have an action plan to handle issues which require help from AWS Support so the customer SLAs can be met.

    Subscribing to AWS Business Support or greater for all production accounts provides faster response time from AWS Support and strongly recommended. If you don't have premium support, you must have an action plan to handle issues which require help from AWS Support. AWS Support provides a mix of tools and technology, people, and programs designed to proactively help you optimize performance, lower costs, and innovate faster. AWS Business Support provides additional benefits including access to AWS Trusted Advisor and AWS Personal Health Dashboard and faster response times.

AWS Well-Architected Review

  • WAFR-001 - Conduct periodic architecture reviews (minimum once every year).

    Conduct periodic architecture reviews of your production workload (minimum once every year) using the AWS Well-Architected tool with FTR lens. The AWS Well-Architected Tool helps you review the state of your workloads and compares them to the latest AWS architectural best practices. The tool is based on the AWS Well-Architected Framework, developed to help cloud architects build secure, high-performing, resilient, and efficient application infrastructure. Well Architected Reviews including AWS Well-Architected Framework and FTR Lens must be conducted on the production workload on a periodic basis. After conducting the review, you should prioritize the remediation of any identified issues according to your business priorities. It is not a requirement to complete the remediation of any issues identified in the review other than the requirements defined in this checklist.

    If you have an internal, well defined architecture review process, you can use that process to conduct the review. If you are using an internal process, please provide details of that process including the owner and the industry standards you follow.

AWS Root Account

  • ARC-001 - Use root user only by exception. (CIS 1.1)

    The root user has unlimited access to your account and its resources, and using it only by exception helps protect your AWS resources. The AWS root user must not be used for everyday tasks, even administrative ones. Instead, adhere to the best practice of using the root user only to create your first AWS Identity and Access Management (IAM) user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks. To view the tasks that require you to sign in as the root user, see AWS Tasks That Require Root User.

  • ARC-003 - Enable multi-factor authentication (MFA) on the root user for all AWS accounts. (CIS 1.13)

    Enabling MFA provides an additional layer of protection against unauthorized access to your account. To configure MFA for the root user, follow the instructions for enabling either a virtual MFA or hardware MFA device.

    If you are using AWS Organizations to create new accounts, the initial password for the root user is set to a random value that is never exposed to you. If you do not recover the password for the root user of these accounts, you do not need to enable MFA on them. For any accounts where you do have access to the root user’s password, you must enable MFA.

  • ARC-004 - Remove access keys for the root user. (CIS 1.12)

    Programmatic access to AWS APIs should never use the root user. It is best not to generate static an access key for the root user. If one already exists, you should transition any processes using that key to use temporary access keys from an AWS Identity and Access Management (IAM) role, or, if necessary, static access keys from an IAM user.

  • ARC-005 - Create an incident response (IR) runbook for root account credential misuse.

    A runbook that details an appropriate response to root account credential misuse enables you to promptly act in the event that your root user becomes compromised. In the event your root account credentials are inaccessible, you will need to either change your AWS account root user password, or contact account and billing support through the Unable to Sign in & Submit Billing or Account Request page. An example of a runbook can be found here.

Communications from AWS

  • ACOM-001 - Configure AWS account contacts.

    If an account is not managed by AWS Organizations , alternate account contacts help AWS get in contact with the appropriate personnel if needed. Configure the account’s alternate contacts to point to a group rather than an individual. For example, create separate email distribution lists for billing, operations, and security and configure these as Billing, Security, and Operations contacts in each active AWS account. This ensures that multiple people will receive AWS notifications and be able to respond, even if someone is on vacation, changes roles, or leaves the company.

  • ACOM-002 - Set account contact information including the root user email address to email addresses and phone numbers owned by your company.

    Using company owned email addresses and phone numbers for contact information enables you to access them even if the individuals whom they belong to are no longer with your organization.

CloudTrail

  • CTL-001 - Configure CloudTrail in all AWS Accounts and in all Regions. (CIS 2.1)

    AWS CloudTrail enables governance, compliance, operational auditing, and risk auditing of your AWS account. To meet FTR requirements, you must have management events enabled for all AWS accounts and in all regions and aggregate these logs into an Amazon Simple Storage Service (Amazon S3) bucket owned by a separate AWS account. The first copy of management events in each region is delivered free of charge and you only pay for S3 storage cost. Additional copies of management events will incur charges. Should you enable data events, you will incur charges for each copy along with associated S3 storage costs. For latest pricing information see CloudTrail pricing. To learn more about Cloud Trail best practices see this blog post.

  • CTL-002 - Store logs in in a separate administrative domain with limited access (e.g. Separate AWS Account or an equivalent AWS Partner solution).

    Configuring the logs to flow to a central account (i.e. separate AWS Account that is only intended for log storage and limited access ) or an equivalent AWS Partner solution protects the logs from manipulation or deletion.

  • CTL-003 - Protect log storage from unintended access (e.g. MFA-delete, versioning on S3, object lock or an equivalent solution)

    Protecting log storage locations from unintended access helps with avoiding any unintended changes to log files.

  • CTL-004 - Enable CloudTrail log file integrity validation. (CIS 2.2)

    A validated log file using integrity validation enables you to assert positively that the log file itself has not changed, or that particular user credentials performed specific API activity. The CloudTrail log file integrity validation process also lets you know if a log file has been deleted or changed, or assert positively that no log files were delivered to your account during a given period of time. CloudTrail log file integrity validation uses industry standard algorithms: SHA-256 for hashing and SHA-256 with RSA for digital signing. This makes it computationally unfeasible to modify, delete or forge CloudTrail log files without detection. For more information, see Enabling Validation and Validating Files.

Identity and Access Management

The requirements in this section pertain to how you manage identities and access for your solution. This includes both AWS Identity and Access Management (IAM) resources as well as other identity providers and access mechanisms (e.g. access management for end users of your product, handing of database credentials, intra-service access control, etc.)

  • IAM-001 - Enable multi-factor authentication for all Human Identities with AWS access. (CIS 1.2)

    You must require any human identities to authenticate using MFA before accessing your AWS accounts. Typically this means enabling MFA within your corporate identity provider. If you have existing legacy IAM users you must enable MFA for console access for those principals as well. Enabling MFA for IAM users provides an additional layer of security. With MFA, users have a device that generates a unique authentication code (a one-time password, or OTP). Users must provide both their normal credentials (user name and password) and the OTP. The MFA device can either be a special piece of hardware, or it can be a virtual device (for example, it can run in an app on a smartphone). Please note that Machine Identities do not require MFA.

  • IAM-002 - Rotate credentials regularly. CIS 1.4

    When you cannot rely on temporary credentials and require long term credentials, rotate the IAM access keys regularly. If an access key is compromised without your knowledge, you limit how long the credentials can be used to access your resources. For information about rotating access keys for IAM users, see Rotating Access Keys.

  • IAM-003 - Use strong password policy. (CIS 1.5, CIS 1.6, CIS 1.7, CIS 1.8, and CIS 1.9)

    Enforce a strong password policy, and educate users to avoid common or re-used passwords. For IAM users, you can create a password policy for your account on the Account Settings page of the IAM console. You can use the password policy to define password requirements, such as minimum length, whether it requires non-alphabetic characters, and so on. For more information, see Setting an Account Password Policy for IAM Users.

  • IAM-004 - Create individual identities (no shared credentials) for anyone who needs AWS access.

    By creating individual identities for people accessing your account, you can give each user a unique set of security credentials and permissions. Individual users provide the ability to audit each users activity.

  • IAM-005 - Use IAM roles and its temporary security credentials to provide access to third parties.

    Do not provision IAM users and share those credentials with people outside of your organization. Any external services that need to make AWS API calls against your account (e.g. a monitoring solution that accesses your account's AWS CloudWatch metrics) must use a cross-account role. See documentation on providing access to AWS accounts owned by third parties for more information.

  • IAM-006 - Grant least privilege access (CIS 1.22)

    You must follow the standard security advice of granting least privilege. Grant only the access that identities require by allowing access to specific actions on specific AWS resources under specific conditions. Rely on groups and identity attributes to dynamically set permissions at scale, rather than defining permissions for individual users. For example, you can allow a group of developers access to manage only resources for their project. This way, when a developer is removed from the group, access for the developer is revoked everywhere that group was used for access control, without requiring any changes to the access policies.

  • IAM-007 - Manage access based on life cycle.

    Integrate access controls with operator and application lifecycle and your centralized federation provider and IAM. For example, remove a user’s access when they leave the organization or change roles.

  • IAM-008 - Audit identities quarterly.

    Auditing the identities that are configured in your identity provider and IAM helps ensure that only authorized identities have access to your workload. For example, remove people that leave the organization, and remove cross-account roles that are no longer required. Have a process in place to periodically audit permissions to the services accessed by an IAM entity. This helps you identify the policies you need to modify to remove any unused permissions, see IAM access advisor.

  • IAM-009 - Do not embed credentials in application code.

    Ensure all credentials used by your applications (e.g. IAM access keys, database passwords, etc.) are never included in your application's source code or committed to source control in any way.

  • IAM-010 - Store secrets in specialized service.

    Where you cannot use temporary credentials, such as tokens from AWS Security Token Service, storing your secrets such as database passwords, using a service like AWS Secrets Manager or an equivalent AWS Partner solution, helps secure your credentials. AWS Secrets Manager handles encryption, rotation, and access control of stored credentials.

  • IAM-011 - Encrypt all end user/customer credentials and hash passwords at rest.

    If you are storing end user/customer credentials in a database that you manage, encrypt credentials at rest and hash passwords. As an alternative, AWS recommends using a user identity synchronization service, such as Amazon Cognito or an equivalent AWS Partner solution

  • IAM-012 - Use centralized identity

    Applies to: SaaS

    Integrate IAM with a central corporate identity provider or directory service for all user authentication. This reduces the requirement for multiple credentials and reduces management complexity. Static AWS key can be used to bootstrap a IAM role assumption for granting access to applications running outside of AWS(e.g. a CI/CD solution running on-prem deploying code to AWS).

    Note: This will become a requirement on July 1st 2022. All Partner solutions must have a plan to federate identity by January 1st 2022 and complete the integration by July 1st 2022.

Backups and Recovery

  • BAR-001 - Perform data backup automatically.

    You must perform regular backups to a durable storage service. Backups ensure that you have the ability to recover from administrative, logical, or physical error scenarios. Configure backups to be taken automatically based on a periodic schedule, or by changes in the dataset. RDS instances, EBS volumes, DynamoDB tables, and S3 objects can all be configured for automatic backup. AWS Marketplace solutions or third-party solutions can also be used.

  • BAR-002 - Perform periodic recovery of the data to verify backup integrity and processes.

    Validate that your backup process implementation meets your recovery time objectives (RTO) and recovery point objectives (RPO) by performing a recovery test both on a periodic basis and after making significant changes to your cloud environment. AWS provides resources to help you manage backup and restore of your data.

Disaster Recovery

  • DR-001 - Define a Recovery Point Objective (RPO) according to your organizational needs.

    Your data loss tolerance is the basis of your backup strategy and frequency. Recovery Point Objective (RPO) defines your data loss tolerance in-terms of time. Define a Recovery Point Objective (RPO) according to your organizational needs.

    Provide your RPO in "Partner Response" column of the self-assessment worksheet.

  • DR-002 - Establish a Recovery Time Objective (RTO) to meet business needs and expectations. This should be on the order of minutes for all components that are critical for providing service to your customers, but should never exceed 24 hours.

    Recovery Time Objective (RTO) defines your tolerance for downtime. The FTR requirement is for the RTO to be less than 24.

    **Provide your RTO in "Partner Response" column of the self-assessment worksheet.

  • DR-004 - Test disaster recovery implementation to validate the implementation.

    Test failover to DR to ensure that RTO and RPO are met, both periodically and after major updates. The DR test must include accidental data loss, instance, and Availability Zone (AZ) failures. At least one DR test that passes RTO and RPO requirements must be completed prior to FTR approval.

    **Provide the last DR test date in "Partner Response" column of the self-assessment worksheet.

Amazon S3 Bucket Access

  • S3-001 - Review all Amazon S3 buckets to determine appropriate access levels.

    You must ensure that buckets that require public access have been reviewed to determine if public read or write access is needed, and appropriate controls are in place to control public access. When using AWS, it's best practice to restrict access to your resources to the people that absolutely need it (the principle of least privilege).

  • S3-002 - Restrict access to S3 buckets that should not have public access.

    You must ensure that buckets that should not allow public access are properly configured to prevent public access. By default, all S3 buckets are private, and can only be accessed by users that have been explicitly granted access. Most use cases won't require broad-ranging public access to read files from your S3 buckets, unless you're using S3 to host public assets (for example, to host images for use on a public website), and it's best practice to never open access to the public.

  • S3-003 - Implement monitoring and alerting to identify when S3 buckets become public.

    You must have monitoring and alerting in place to identify when S3 buckets become public. Trusted Advisor checks for S3 buckets that have open access permissions. Bucket permissions that grant List access to everyone can result in higher than expected charges if objects in the bucket are listed by unintended users at a high frequency. Bucket permissions that grant Upload/Delete access to everyone create potential security vulnerabilities by allowing anyone to add, modify, or remove items in a bucket. The Trusted Advisor check examines explicit bucket permissions and associated bucket policies that might override the bucket permissions. You can also use AWS Config to monitor your S3 buckets for public access. For more information on using AWS Config to monitor S3, please take a look at this blog.

Cross-Account Access

  • CAA-001 - Use cross-account roles to access customer accounts.

    Cross-account roles reduce the amount of sensitive information AWS Partners need to store for their customers.

  • CAA-007 - Provide guidance or an automated setup mechanism (e.g. AWS CloudFormation template) for creating cross-account role with minimum required privileges.

    The policy created for cross-account access in customer accounts must follow the least privilege principle. The partner must provide a role policy document or an automated setup mechanism (e.g. an AWS CloudFormation template) for the customers to use to ensure that the roles are created with minimum required privileges. More information on using AWS CloudFormation to create cross-account roles are available in these blog posts.

  • CAA-002 - Use external ID with cross-account roles to access customer accounts.

    The external ID allows the user that is assuming the role to assert the circumstances in which they are operating. It also provides a way for the account owner to permit the role to be assumed only under specific circumstances. The primary function of the external ID is to address and prevent the confused deputy problem.

  • CAA-004 - Use a value you generate (not something provided by the customer) for the external ID.

    When configuring cross-account access using IAM roles, you must use a value you generate for the external ID, instead of one provided by the customer, to ensure the integrity of the cross account role configuration. A partner-generated external ID ensures that malicious parties cannot impersonate a customer's configuration and enforces uniqueness and format consistency across all customers. If you are not generating an external ID today we recommend implementing a process that ensures a random unique value, such as a Universally Unique Identifier, is generated for the external ID that a customer would use to setup a cross account role.

  • CAA-005 - Ensure all external IDs are unique.

    The external IDs used must be unique across all customers. Re-using external IDs for different customers does not solve the confused deputy problem and runs the risk of customer A being able to view data of customer B by using the role ARN of customer B along with the external ID of customer B. To resolve this, we recommend implementing a process that ensures a random unique value, such as a Universally Unique Identifier, is generated for the external ID that a customer would use to setup a cross account role.

  • CAA-006 - Provide read-only access to external ID to customers.

    Customers must not be able to set or influence external IDs. When the external ID is editable, it is possible for one customer to impersonate the configuration of another. When the external ID is editable Customer A can create a cross account role setup using customer B’s role ARN and external id, granting customer A access to customer B’s data. Remediation of this item involves making the external ID a view only field ensuring that the external ID cannot be changed for purposes of impersonating the setup of another customer.

  • CAA-003 - Deprecate any historical use of customer-provided IAM credentials.

    If your application provides legacy support for the use of static IAM credentials for cross-account access, the application's user interface and customer documentation must make it clear that this method is deprecated and the use of a cross-account IAM role is recommended. Existing customers should be encouraged to switch to cross-account role based-access, and collection of credentials should be disabled for new customers.

Sensitive Data

  • SDAT-001 - Identify sensitive data (e.g. Personally Identifiable Information (PII) and Protected Health Information (PHI)).

    Data classification enables you to determine which data needs to be protected and how. Based on the workload and the data it processes, identify the data that is not common public knowledge.

  • SDAT-002 - Encrypt all sensitive data at rest.

    Encryption maintains the confidentiality of sensitive data even when it gets stolen or the network through which it is transmitted becomes compromised.

  • SDAT-003 - Only use protocols with encryption when transmitting sensitive data outside of your VPC.

    Encryption maintains data confidentiality even when the network through which it is transmitted becomes compromised.

  • SDAT-004 - Log access to sensitive data comprehensively throughout the system

    Visibility into any unexpected access to sensitive data provides you with the opportunity to perform necessary corrective actions to further protect your data. Scope your systems for components that store sensitive data. Implement application- and resource-level auditing and logging to monitor all access to data and quickly identify unauthorized access.

Protected Health Information

This sections only apply to solutions with US customers which handle Protected Health Information (PHI).

  • BAABP-001 - If the solution handles Protected Health Information (PHI), the partner must have a Business Associate Addendum (BAA) in place with AWS for every AWS account with PHI

    Have a Business Associate Addendum (BAA) in place with AWS for every AWS account with Protected Health Information (PHI).

  • BAABP-004 - Use services in the HIPAA Eligible Services Reference for solutions handling PHI.

    Solutions handling PHI must use services in the HIPAA Eligible Services Reference.

Regulatory Compliance Validation Process

  • RCVP-001 - Establish a process to ensure that all required compliance standards are met.

    If you advertise that your product meets specific compliance standards, you must have an internal process for ensuring compliance. Examples of compliance standards include PCI DSS, FedRAMP, and HIPAA. Applicable compliance standards are determined by various factors, such as what types of data the solution stores or transmits and which geographic regions the solution supports.