1.1. Network Protection.Implement network protection controls including network firewalls, network access control lists to deny access to unauthorized IP addrsses. Implement anti-virus and anti-malware software on end-user devices. Restrict public access only to approved users.
1.2. Access Management.we must assign a unique ID to each person with computer access to Information. we must not create or use generic, shared, or default login credentials or user accounts. we must implement baselining mechanisms to ensure that at all times only the required user accounts access Information. we must review the list of people and services with access to Information every 90 days, and remove accounts that no longer require access. we must restrict employees and contractors from storing Information on personal devices. we will maintain and enforce "account lockout" by detecting anomalous usage patterns and log-in attempts, and disabling accounts with access to Information as needed.
1.3. Least Privilege Principle.we must implement fine-grained access control mechanisms to allow granting rights to any party using the Application and the Application's operators following the principle of least privilege. Access to Information must be granted on a "need-to-know" basis.
1.4. Password Management.we must establish minimum password requirements for personnel and systems with access to Information. Password requirements must be a minimum of 8 characters, contain upper and lower case letters, contain numbers, contain special characters, and rotated at least quarterly.
1.5. Encryption in Transit.we must encrypt all Information in transit with secure protocols such as TLS 1.2+, SFTP, and SSH-2. we must enforce this security control on all applicable internal and external endpoints. we must use data message-level encryption where channel encryption (e.g., using TLS) terminates in untrusted multi-tenant hardware (e.g., untrusted proxies).
1.6. Incident Response Plan.we must create and maintain a plan and/or runbook to detect and handle Security Incidents. Such plans must identify the incident response roles and responsibilities, define incident types that may affect Amazon, define incident response procedures for defined incident types, and define an escalation path and procedures to escalate Security Incidents to Amazon. we must review and verify the plan every six (6) months and after any major infrastructure or system change, including changes to the system, controls, operational environments, risk levels, and supply chain. we must notify Amazon (via email to [firstname.lastname@example.org](mailto:email@example.com)) within 24 hours of detecting Security Incident or suspecting that a Security Incident has occurred. we must investigate each Security Incident, and document the incident description, remediation actions, and associated corrective process/system controls implemented to prevent future recurrence. we must maintain the chain of custody for all evidences or records collected, and such documentation must be made available to Amazon upon request (if applicable). If a Security Incident occurred, we cannot represent or speak on behalf of Amazon to any regulatory authority or customers unless Amazon specifically requests in writing that the Developer do so.
2、Protect sensitive information
2.1. Data Retention.we 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 or to, (ii) calculate and remit taxes, and (iii) produce tax invoices. If our company is required by law to retain archival copies of PII for tax or similar regulatory purposes, PII must be stored as a "cold" or offline encrypted backup (e.g., not available for immediate or interactive use)
2.3. Asset Management.we must keep inventory of software and physical assets (e.g. computers, mobile devices) with access to PII, and update quarterly. Physical assets that store, process, or otherwise handle Amazon PII must abide by all of the requirements set forth in this policy. we must not store PII in removable media, personal devices, or unsecured public cloud applications (e.g., public links made available through Google Drive) unless it is encrypted using at least AES-128 or RSA-2048 bit keys or higher. we must securely dispose of any printed documents containing PII.
2.4. Encryption at Rest.we must encrypt all PII at rest using at least AES-128 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.
2.5. Secure Coding Practices.
we must not hardcode sensitive credentials in their code, including encryption keys, secret access keys, or passwords. Sensitive credentials must not be exposed in public code repositories. we must maintain separate test and production environments.
2.6. Logging and Monitoring.
we 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 (e.g., service APIs, storage-layer APIs, administrative dashboards) providing access to Information. All logs must have access controls to prevent any unauthorized access and tampering throughout their lifecycle. Logs must not contain PII and must be retained for at least 90 days for reference in the case of a Security Incident. we must build mechanisms to monitor the logs and all system activities to trigger investigative alarms on suspicious actions (e.g., multiple unauthorized calls, unexpected request rate and data retrieval volume, and access to canary data records). Developers must implement monitoring alarms to detect if Information is extracted from its protected boundaries. we should perform investigation when monitoring alarms are triggered, and this should be documented in the Developer's Incident Response Plan.
2.7 Vulnerability Management.
we must create and maintain a plan and/or runbook to detect and remediate vulnerabilities. we must protect physical hardware containing PII from technical vulnerabilities by performing vulnerability scans and remediating appropriately. we must conduct vulnerability scanning or penetration tests at least every 180 days and scan code for vulnerabilities prior to each release. Furthermore, we must control changes to the storage hardware by testing, verifying changes, approving changes, and restricting access to who may perform those actions.