Partner Hosted Foundational Technical Review

To qualify for FTR your product must run entirely on AWS. This includes the application and control planes. The application plane can run in the seller's AWS account, the buyer's AWS account, or both. For more information, refer to the Control plane vs. application plane whitepaper. Third-party services used by the product to transmit, store, or process application data must also run entirely on AWS —except for content delivery networks (CDNs), domain name systems (DNSs), and corporate identity providers (IdPs).

Agents or gateways used by the product for security, monitoring, data replication, or migration can run on buyer-owned environments outside AWS, including on premises, but must send data only to AWS for storage and analysis.

You must include an architecture diagram for review. For more information, refer to Architecture diagram.

Listing on Marketplace is not required to complete a FTR.

It is recommended that you subscribe to the AWS Business Support tier or higher (including AWS Partner-Led Support) for all of your AWS production accounts. For more information, refer to Compare AWS Support Plans. 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.

Conduct periodic architecture reviews of your production workload (at least once per year) using a documented architectural standard that includes AWS-specific best practices. If you have an internally defined standard for your AWS workloads, we recommend you use it for these reviews. If you do not have an internal standard, we recommend you use the AWS Well-Architected Framework.

Review the AWS Shared Responsibility Model for Security and the AWS Shared Responsibility Model for Resiliency. Ensure that your product’s architecture and operational processes address the customer responsibilities defined in these models. We recommend you to use AWS Resilience Hub to ensure your workload resiliency posture meets your targets and to provide you with operational procedures you may use to address the customer responsibilities.

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 accounts 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. FTR does not require you to actively monitor root usage.

We recommend you use AWS Organizations to centralize AWS root accounts access. If you are using AWS Organizations to create new member accounts and centralize root access, you can choose to delete root user credentials for all member accounts in your organization. You can find more information on centrally managing root access here.

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 for member account and not planning to centralize root access, then it is critical that MFA is enabled on the root user if you have access to the root user’s password for your member accounts.

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.

If you are using AWS Organizations for member account and not planning to centralize root access, then it is critical that access keys for root users are removed as root user should only be used for specific tasks in your AWS account.

An incident management plan is critical to respond, mitigate, and recover from the potential impact of security incidents. An incident management plan is a structured process for identifying, remediating, and responding in a timely matter to security incidents. An effective incident management plan must be continually iterated upon, remaining current with your cloud operations goal. For more information on developing incident management plan please see Develop incident management plans.

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.

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.

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.

Monitor and secure AWS IAM credentials by:

• Using IAM roles to reduce the risk of credentials being misused OR
• Rotating IAM access keys regularly (recommended at least every 90 days)

In cases where it is infeasible to use IAM roles or rotate keys, implement the following controls:

• Maintain an inventory of all static keys and where they are used and remove unused access keys.
• Implement monitoring of AWS CloudTrail logs to detect anomalous activity or other potential misuse (e.g. using AWS GuardDuty.)
• Define a runbook or SOP for revoking credentials in the event you detect misuse.

See Managing access keys for IAM users for more information.

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 and whether it requires non-alphabetic characters, and so on. For more information, see Setting an Account Password Policy for IAM users.

Create individual entities and give unique security credentials and permissions to each user accessing your account. With individual entities and no shared credentials, you can audit the activity of each user.

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 (for example, a monitoring solution that accesses your account's AWS CloudWatch metrics) must use a cross-account role. For more information, refer to Providing access to AWS accounts owned by third parties.

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.

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.

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 needto modify to remove any unused permissions. For more information, see Refining permissions in AWS using last accessed information.

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

Encrypt all secrets in transit and at rest, define fine-grained access controls that only allow access to specific identities, and log access to secrets in an audit log. We recommend you use a purpose-built secret management service such as AWS Secrets Manager, AWS Systems Manager Parameter Store, or an AWS Partner solution, but internally developed solutions that meet these requirements are also acceptable.

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.

Use temporary security credentials to access AWS resources.

• Use IAM roles to acquire temporary security credentials for machine identities within AWS, such as Amazon EC2 instances or AWS Lambda functions.
• All processes that run on AWS compute services should use temporary credentials from an associated IAM role to call AWS APIs.

Define a mechanism and frequency to scan and patch for vulnerabilities in your dependencies, and in your operating systems to help protect against new threats. Scan and patch your dependencies, and your operating systems on a defined schedule. Software vulnerability management is essential to keeping your system secure from threat actors. Embedding vulnerability assessments early into your continuous integration/continuous delivery (CI/CD) pipeline allows you to prioritize remediation of any security vulnerabilities detected. The solution you need to achieve this varies according to the AWS services that you are consuming. To check for vulnerabilities in software running in Amazon EC2 instances, you can add Amazon Inspector to your pipeline to cause your build to fail if Inspector detects vulnerabilities. You can also use open source products such as OWASP Dependency-Check, Snyk, OpenVAS, package managers and AWS Partner tools for vulnerability management.

All Amazon EC2 security groups should restrict access to the greatest degree possible. At a minimum, do the following:

• Ensure that no security groups allow ingress from 0.0.0.0/0 to port 22 or 3389 (CIS 5.3/ Security Control EC2.54 and CIS 5.2/ Security Control EC2.53)
• Ensure that the default security group of every VPC restricts all traffic (CIS 5.4/Security Control EC2.2)

Do not place resources in public subnets of your VPC unless they must receive network traffic from public sources. Public subnets are subnets associated with a route table that has a route to an internet gateway.

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 Backup, AWS Marketplace solutions or third-party solutions can also be used. If objects in S3 bucket are write-once-read-many (WORM), compensating controls such as object lock can be used meet this requirement. If it is customers’ responsibility to backup their data, it must be clearly stated in the documentation and the Partner must provide clear instructions on how to backup the data.

To confirm that your backup process meets your recovery time objectives (RTO) and recovery point objectives (RPO), run a recovery test on a regular schedule and after making significant changes to your cloud environment. For more information, refer to Getting Started - Backup and Restore with AWS.

Define an RPO based on your organization’s data-loss tolerance (as measured by time).

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

Define an RTO that meets your organization’s needs and expectations. RTO is the maximum acceptable delay your organization will accept between the interruption and restoration of service.

Enter your RTO in the Partner Response column of the self-assessment worksheet.

Test resilience to ensure that your established targets are met, both periodically (minimum every 12 months) and after major updates. The resilience test should include at minimum Availability Zone (AZ) impairments and any other failure modes relevant to your architecture such as: accidental data loss, instance impairments, or region impairments. At least one resilience test that meets established requirements must be completed prior to FTR approval.

You can use AWS Resilience Hub to verify your workloads to see if it meets its resilience target. AWS Resilience Hub works with AWS Fault Injection Service (AWS FIS), to provide fault-injection experiments of real-world failures to validate the application recovers within the resilience targets you defined. AWS Resilience Hub also provides API operations for you to integrate its resilience assessment and testing into your CI/CD pipelines for ongoing resilience validation. Including resilience validation in CI/CD pipelines helps make sure that changes to the workload’s underlying infrastructure don't compromise resilience.

Enter the date of the last resilience test in the Partner Response column of the self-assessment worksheet.

Clearly define your customers’ responsibility for backup, recovery, and availability. At a minimum, your product documentation or customer agreements should cover the following:

• Responsibility the customer has for backing up the data stored in your solution.
• Instructions for backing up data or configuring optional features in your product for data protection, if applicable.
• Options customers have for configuring the availability of your product.

If you publish or privately agree to availability targets or uptime SLAs, ensure that your architecture and operational processes are designed to support them. Additionally, provide clear guidance to customers on any configuration required to achieve the targets or SLAs. Refer to Resilience strategy for AWS ISV Partners to review your resilience strategy and make any required changes.

Establish a plan for communicating information about system outages to your customers both during and after incidents. Your communication should not include any data that was provided by AWS under a non-disclosure agreement (NDA).

You must ensure that buckets that require public access have been reviewed to determine if public read or write access is needed and if appropriate controls are in place to control public access. When assigning access permissions, follow the principle of least privilege, an AWS best practice. For more information, refer to overview of managing access.

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

The policy created for cross-account access in customer accounts must follow the principle of least privilege. The AWS Partner must provide a role-policy document or an automated setup mechanism (for example, an AWS CloudFormation template) for the customers to use to ensure that the roles are created with minimum required privileges. For more information, refer to the AWS Partner Network (APN) blog posts.

Depending on if you're using the AssumeRole API or AssumeRoleWithWebIdentity API, an external ID (AssumeRole) or dedicated issuer URL (AssumeRoleWithWebIdentity) must be used to access customer accounts. It 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 and dedicated issuer URL is to address and prevent the confused deputy problem. To implement the dedicated issuer URL for AssumeRoleWithWebIdentity API, refer to this documentation.

When configuring cross-account access using IAM roles, you must use a value you generate for the external ID or dedicated issuer URL, instead of one provided by the customer, to ensure the integrity of the cross-account role configuration. A partner-generated external ID or dedicated issuer URL 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 or dedicated issuer URL today we recommend implementing a process that generates a random unique value (such as a Universally Unique Identifier) for the external ID or dedicated issuer URL that a customer uses to set up a cross-account role.

The external IDs or dedicated issuer URLs used must be unique across all customers. Re-using external IDs or dedicated issuer URLs 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 and the external ID or dedicated issuer URL 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 or dedicated issuer URL that a customer would use to setup a cross account role.

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

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. Existing customers should be encouraged to switch to cross-account role based-access, and collection of credentials should be disabled for new customers.

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.

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

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

If you advertise that your product meets specific compliance standards, you must have an internal process for ensuring compliance. Examples of compliance standards include Payment Card Industry Data Security Standard (PCI DSS) PCI DSS, Federal Risk and Authorization Management Program (FedRAMP)FedRAMP, and U.S. Health Insurance Portability and Accountability Act (HIPAA)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.