Guidance to address key security controls in SP-API integration

Guidance for developers to address ten key security controls when integrating with Selling Partner API and correlation of these controls to the applicable Data Protection Policy (DPP)

by Ronaldo N., Solutions Architect Security, Selling Partner Developer Services, and Anuj R., Global Leader Solutions Architecture, Selling Partner Developer Services | May 3, 2022

This blog post 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 blog post 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.

1. Password Management

This control relates to Access Management and Password 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 are required to enable password complexity and specify a minimum password length of 8 characters and a mix of upper-case letters, lower-case letters, numbers, and special characters. Password expiry should be set to 90 days. It is recommended to implement the following password controls: Password minimum age of 1 day, Consecutive invalid login attempts by should be set to 4 before the automatic lock of the account/node until released either by an administrator or automatically after 24 hours. A Session idle time-out/screensaver launch should be set to 5 minutes of inactivity.

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.

2. 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 hire a third-party company specialized in vulnerability scanning and penetration tests to conduct assessments. Alternatively, developers can run Kali Linux, Nessus and Burp Suite to conduct their own tests. 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 and/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 or penetration tests at least every 180 days and scan code for vulnerabilities before each release. Furthermore, Developers must control changes to the storage hardware by testing, verifying changes, approving changes, and restricting access to who may perform those actions.

3. Encryption and Storage

This control relates to the Encryption at Rest policy in “Additional Security Requirements” specified in Amazon Data Protection Policy. Once developers understand the sensitivity of data they are working with, then the proper level of encryption can be applied where applicable.

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 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 encrypt all PII at rest (e.g., when the data is persisted) using industry best practice standards (e.g., using either AES-128, AES-256, or RSA with 2048-bit key size (or higher). The cryptographic materials (e.g., encryption/decryption keys) and cryptographic capabilities (e.g., daemons implementing virtual Trusted Platform Modules and providing encryption/decryption APIs) used for encryption of PII at rest must be only accessible to the Developers processes and services.

4. Removable Media Controls

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

How to address: Developers should implement controls that prohibit storage of PII data onto removable media devices and public unsecured storage systems. You can achieve this approach by disabling or locking USB ports and restricting organization access to store PII on public file systems. Also, developers can refrain from printing PII materials and set up secure disposition mechanisms such as shredding boxes for printed documents.

Developers must not store PII in removable media (e.g., USB) or unsecured public cloud applications (e.g., public links made available through Google Drive). Developers must securely dispose of any printed documents containing PII.

5. 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 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 laptops, 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 (e.g., when the data is persisted) using industry best practice standards (e.g. using either AES-128, AES-256, or RSA with 2048-bit key size (or higher). The cryptographic materials (e.g., encryption/decryption keys) and cryptographic capabilities (e.g., 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.

6. Data Destruction and 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. Once 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 only for, and as long as is necessary to fulfill orders (no longer than 30 days after order shipment) or to calculate/remit taxes. If a developer is required by law to retain archival copies of PII for tax or other regulatory purposes, PII must be stored as a "cold" or offline encrypted backup (e.g., not available for immediate or interactive use).

7. 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 (e.g., Amazon VPC subnet/Security Groups, network firewalls) to deny access to unauthorized IP addresses and public access must be restricted only to approved users. Developers must implement anti-virus and anti-malware software on end-user devices. Developers must restrict public access only to approved users.

8. 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 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 6 months.

Developers must create and maintain a plan and/or runbook to detect and handle Security Incidents.

9. 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 implement baselining mechanisms to ensure that all times only the required user accounts access Amazon information. Developers must review the list of people and services with access to Amazon Information regularly (at least quarterly), and remove accounts that no longer require access.

10. 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 may 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 of failure of the event, date and time, access attempts, data changes, and system errors. Developers must implement this logging. mechanism on all channels (e.g., service APIs, storage-layer APIs, administrative dashboards) providing access to Information. All logs must have access controls to prevent any authorized 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. 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 (e.g., multiple unathorized calls, unexpected request rates, data retrieval volume, and access to canary data records). Developers must implement monitoring alarms to detect if Information is extracted from its protected boundaries. Developers should investigate when monitoring alarms are triggered, which should be documented in the Developer's Incident Response Plan.

Conclusion

This blog post outlined key security controls in Seller Partner API implementations and examples of tools that can be considered when applying the Data Protection Policy.

The Amazon Data Protection Policy lays out the requirements that developers need to implement to protect customer PII data. The list of issues analyzed above is not exhaustive. For more information, refer to the Amazon Data Protection Policy.

👍

Have feedback on this post?

If you have questions or feedback on this post, we'd like to hear from you! Please vote and leave a comment using the tools at the bottom of this page.

Subscribe to updates via RSS feed.


Did this page help you?