Key Security Control Guidance

This technical paper highlights ten key security controls that developers should address when integrating with Selling Partner API and correlates these controls to the applicable Amazon Data Protection Policy (DPP) provision.

Developers and integrators who build solutions to integrate with Amazon Selling Partner API (SP-API) must ensure that their solutions and applications comply with the Data Protection Policy (DPP). Developers must maintain proper technology controls to verify compliance with the Data Protection Policy when audited. Developers can use the information in this technical paper to complement and enhance the security posture of their applications.

About the Data Protection Policy (DPP)

The Data Protection Policy (DPP) contains two categories related to security requirements:

• General Security Requirement: Requirements for all developers building SP-API applications. These requirements include best practices guidelines such as network protection, access management, password policy, encryption, and incident response plans.
• Additional Security Requirement: Additional requirements for developers performing restricted operations on SP-API that involve Personally Identifiable Information (PII). PII access is granted to developers for select tax and seller-fulfilled shipping purposes, on a must-have basis only. These requirements include policies around data retention, governance, encryption, logging, and vulnerability management.

Well-architected applications should implement security controls that fall in five broad categories specified in the Security Pillar of the AWS Well-Architected Framework. Although you are not required to use Amazon Web Services (AWS) to achieve these security controls, the five Security Pillar categories provide a framework to cross-check SP-API implementation architectures. For reference, these five categories are

• Identity and Access Management
• Detection
• Infrastructure Protection
• Data Protection
• Incident Response

If an application implements one or more security controls in these five categories, then the application can likely meet the criteria defined in the Data Protection Policy.

The following sections analyze ten key security controls grounded on the five categories from the Security Pillar of AWS Well-Architected Framework.

Credentials management

This control relates to credentials management policy in “General Security Requirements”. Credentials and personal data are among the most sought-after data types stolen. External actors that obtain credentials can use these later to access and steal data from assets such as databases, servers, and staff laptop storage. According to the Verizon Data Breach Investigations Report 2021, by far the motivation to extract user credentials is due to financial opportunities. External and internal actors can use credentials obtained illegally and illicitly to expand their goal to access the system and obtain customer PII or payment data. One way that credentials are accessed is through Brute Force Password attacks. With this type of attack, combinations of passwords are attempted multiple times until a successful password match is found.

Developers should implement the following password complexity settings to enhance protection against Brute Force Password attacks:

Developers must establish minimum password requirements for personnel and systems with access to Information. Password requirements must be a minimum of twelve (12) characters, not include any part of the user’s name, mix of upper-case letters, lower-case letters, numbers, and special characters, including minimum requirements for each. Developers must establish a minimum password age of 1-day and a maximum 365-day password expiration for all users. Developers must ensure that Multi-Factor Authentication (MFA) is required for all user accounts Developer must ensure that API keys provided by Amazon are encrypted and only required employees have access to them.

How to address: Developers who run AWS Directory Service can set password complexity settings by managing passwords for IAM users. Microsoft Active Directory administrators can enable Password Complexity in Group Policies. Multifactor Authentication (MFA) is a required technical security control that can offer resilience against Brute Force Password attacks. Finally, make sure to apply the concept of least privilege for user and service accounts.

Vulnerability management

This control relates to the Vulnerability Management policy in “Additional Security Requirements” specified in Amazon Data Protection Policy. When a bad actor manages to gain access to a computing system, often via stolen credentials or Brute Force attack, the bad actor can also install malware software. Software that can be installed illicitly includes ransomware, remote access trojan (RAT), and keystroke logging. In the case of RAT and keystroke logging software, a remote actor can capture usernames, passwords, and payment information remotely without the knowledge of the user in the compromised system.

How to address: Developers can conduct their own tests by running Kali Linux, Nessus, and Burp Suite or hire a third-party company specialized in vulnerability scanning and penetration tests to conduct assessments. Tests against external and internal infrastructure are necessary such as front-end web servers and internal database servers. A list of web applications vulnerability scanning tools can be found at OWASP.org. Note that developers are required to run vulnerability tests at least every 180 days. Before running vulnerability tests against AWS services, refer to the Penetration Testing guidance for a list of permitted tests and considerations.

Developers must create and maintain a plan or runbook to detect and remediate vulnerabilities. Developers must protect physical hardware containing PII from technical vulnerabilities by performing vulnerability scans and remediating appropriately. Developers must conduct vulnerability scanning at least every 180 days, penetration test at least every 365 days, and scan code for vulnerabilities prior to each release. Furthermore, Developers must control changes to the storage hardware by testing, verifying changes, approving changes, and restricting access to who can perform those actions. Developer must have appropriate procedures and plans to restore availability and access to PII in a timely manner in the event of a physical or technical incident.

Asset management

This control relates to the Asset Management policy in “Additional Security Requirements” specified in Amazon Data Protection Policy. Removable devices can store a large amount of data and security in those removable devices can be relaxed or non-existent. Removable devices can be stolen or misplaced and lost. Printed paper with PII information can be misplaced. PII data stored in unsecured and public cloud applications can fall into the hands of bad actors.

How to address: Developers should conduct an inventory of the various data storage mechanisms such as databases, object stores such as Amazon Simple Storage Service (Amazon S3), and file stores that store Personal Identifiable Information (PII) data. All storage mechanisms that hold or store PII data must encrypt data at rest with the industry best practices standard as specified in the DPP. For example, Amazon EC2 virtual machines with Amazon Elastic Block Store (Amazon EBS) volumes can be encrypted. Managed databases and employee laptop disks also require disk encryption to protect data at rest. Employee laptop policies can be applied and maintained using tools for endpoint security. Any encryption key used needs to be rotated at least once a year and stored securely.

Developers must maintain baseline standard configuration for the information system and keep inventory of software and physical assets (for example, computers and mobile devices) with access to PII and update quarterly. Physical assets that store, process, or otherwise handle PII must abide by all of the requirements set forth in this policy. Developers must not store PII in removable media, personal devices, or unsecured public cloud applications (for example, public links made available through Google Drive) unless it is encrypted using at least AES-128 or RSA-2048 bit keys or higher. Developers must securely dispose of any printed documents containing PII. Developer must implement data loss prevention (DLP) controls in place to monitor and detect unauthorized movement of data.

Data encryption at rest

This control relates to Encryption at Rest security control in “Additional Security Requirements” specified in Amazon Data Protection Policy. The Data Classification whitepaper provides developers with guidance to identify which systems and volume should be encrypted at rest. For example, Amazon EC2 virtual machines storing PII data should have Amazon EBS volumes encrypted to protect confidential data. Managed databases and employee laptop disks also require disk encryption to protect data at rest.

How to address: Developers should create their own data classification document to identify data that requires disk encryption to protect information, including end-devices drives, servers, databases and backup storage. In addition to encrypting data, any SP-API keys must be kept secure and encrypted. API keys should not be exposed in emails or remain in documentation in plain text.

Developers must encrypt all PII at rest using at least AES-128 or RSA with 2048-bit key size or higher. The cryptographic materials (for example, encryption/decryption keys) and cryptographic capabilities (for example, daemons implementing virtual Trusted Platform Modules and providing encryption/decryption APIs) used for encryption of PII at rest must be only accessible to the developer's processes and services.

Data retention processes

This control relates to the Data Retention policy in “Additional Security Requirements” specified in Amazon Data Protection Policy. Developers can retain the PII data encrypted for legal and tax purposes. After the PII data is no longer required to comply with legal requirements, the PII data must be erased. Many developers struggle with meeting this policy because they often store the complete PII information instead of the non-PII information that is actually required by their use case, such as order totals, 5-digit ZIP code used for tax calculation, and so on.

How to address: Developers can purge the PII related data, such as customer name, ID, address and so on from hot cache, or if access to this data is required by law beyond 30 days, developers can archive the PII related data in encrypted storage.

Developers will retain PII for no longer than 30 days after order delivery and only for the purpose of, and as long as is necessary to (i) fulfill orders, (ii) calculate and remit taxes, (iii) produce tax invoices and other legally required documents, and (iv) meet legal requirements, including tax or regulatory requirements. Developers can retain data for more than 30 days after order delivery only if required by law and only for the purposes of complying with that law. Per sections 1.5 (“Encryption in Transit”) and 2.4 (”Encryption at Rest”) at no point should PII be transmitted or stored unprotected.

Anti-malware controls

This control relates to the Network Protection policy in “General Security Requirements” specified in Amazon Data Protection Policy. Malware is usually installed by an external actor. Malware sent through email is the second most common method of malicious software delivery to a target system. For example, malware can be installed when users are visiting a compromised website. Computers and system users that do not run an up-to-date anti-virus can create vulnerabilities in the system network.

How to address: Developers should apply network segmentation in cloud and on-premises network infrastructures. For example, use firewall filtering rules to segment subnets and networks in both cloud and on-premises environments. Developers should deploy and maintain up-to-date antivirus in servers and endpoints and install network and application firewalls to protect external facing web servers. Adopt and maintain a Software Development Life Cycle (SDLC) framework for integration of security testing and efficient software management practices in the project. Deploy a security management and information management system and anti-advanced persistent threat solution where applicable.

Developers must implement network protection controls including network firewalls and network access control lists to deny access to unauthorized IP addresses. Developers must implement network segmentation, anti-virus and anti-malware software on end-user devices. Developers must restrict public access only to approved users and carry out data protection and IT security training for everyone with system access.

Incident management procedures

This control relates to the Incident Response Plan policy in “General Security Requirements” specified in Amazon Data Protection Policy. Incident response (IR) plans include a methodology and framework that helps organizations identify and implement proactive and reactive procedures to secure the Amazon Services API. Phases of an Incident and Management plan that developers should consider include preparation, identification, containment, eradication, recovery, and lessons learned sections.

How to address: Developers are required to maintain a updated incident response plan and ensure that there is a process to notify Amazon within 24 hours of an incident at [email protected]. The incident response (IR) plan must be approved by a senior manager and reviewed at least every six months.

Developers must have a risk assessment and management process that is reviewed by the developer's senior management annually, which includes, but is not limited to, assessment of potential threats and vulnerabilities as well as likelihood and impact in order to track known risks. Developers must create and maintain a plan or runbook to detect and handle Security Incidents. Such plans must identify the incident response roles and responsibilities, define incident types that can affect Amazon, define incident response procedures for defined incident types, and define an escalation path and procedures to escalate Security Incidents to Amazon.

Access review

This control relates to the Access Management policy in “General Security Requirements” specified in Amazon Data Protection Policy. The expectation for the Access Review policy is to establish a periodic review process to assure the concept of review user and service accounts no longer needed and delete inactive accounts.

How to address: Developers should create password management policy documentation. This password management policy documentation should lay out the requirement for least privilege for account access and provide directives on reviewing permissions for user and service accounts, including when these accounts should be disabled and deleted. The access review process within the policy is required to occur at least quarterly.

Developers must establish a formal user access registration process to assign access rights for all user types and services by ensuring that a unique ID is assigned to each person with computer access to Information. Developers must not create or use generic, shared, or default login credentials or user accounts and prevent user accounts from being shared. Developers must implement baselining mechanisms to ensure that at all times only the required user accounts access Information. Developers must restrict employees and contractors from storing Information on personal devices. Developers will maintain and enforce "account lockout" by detecting anomalous usage patterns and login attempts, and disabling accounts with access to Information. Developers must review the list of people and services with access to Information at least quarterly. Developers must ensure that access is disabled or removed within 24 hours for terminated employees.

Identification of potential incidents

This control relates to the Logging and Monitoring policy in “General Security Requirements” specified in Amazon Data Protection Policy. Users who have been subjected to phishing attacks are rarely able to realize they have a compromised system. Attacks can be launched against web servers in the form of distributed denial-of-service (DDoS) against the network and applications. Employees can have systems compromised by malware. Therefore, monitoring systems are critical to detect and notify users compromised through social engineering or other methods.

How to address: Deploy a monitoring and detection system for all applicable data assets such as a SIEM system or an Intrusion Detection & Prevention System. The requirement is to keep security logs retained for at least 90 days.

Developers must gather logs to detect security-related events to their applications and systems including success or failure of the event, date and time, access attempts, data changes, and system errors. Developers must implement this logging mechanism on all channels (for example, service APIs, storage-layer APIs, administrative dashboards) providing access to Information. Developers must review logs in real-time (for example, SIEM tool) or on a bi-weekly basis. All logs must have access controls to prevent any unauthorized access and tampering throughout their lifecycle. Logs must not contain PII unless the PII is necessary to meet legal requirements, including tax or regulatory requirements. Unless otherwise required by applicable law, logs must be retained for at least 90 days for reference in the case of a Security Incident. Developers must build mechanisms to monitor the logs and all system activities to trigger investigative alarms on suspicious actions (for example, multiple unauthorized calls, unexpected request rate and data retrieval volume, and access to canary data records). Developers must implement monitoring alarms and processes to detect if Information is extracted from or can be found beyond its protected boundaries. Developers should perform investigation when monitoring alarms are triggered, and this should be documented in the Developer's Incident Response Plan.

For more information, refer to the Amazon Data Protection Policy.

Notices

Amazon sellers and developers are responsible for making their own independent assessment of the information in this document. This document: (a) is for informational purposes only, (b) represents current practices, which are subject to change without notice, and (c) does not create any commitments or assurances from Amazon.com Services LLC (Amazon) and its affiliates, suppliers, or licensors. Amazon Marketplace Web Services (Amazon MWS) and Amazon Selling Partner API (Amazon SP-API) products or services are provided “as is” without warranties, representations, or conditions of any kind, whether express or implied. The responsibilities and liabilities of Amazon regarding Amazon MWS and SP-API are controlled by Amazon’s MWS and SP-API agreements (including the Amazon Selling Partner API Developer Agreement or the Amazon Selling Partner API License Agreement), and this document is not part of, nor does it modify, any agreement between Amazon and any party.

© 2022 Amazon.com Services LLC or its affiliates. All rights reserved.