Data Protection and Handling Policy

1. General Security Requirements

Consistent with industry-leading security, Dash Applications LLC DBA MixShift (“The Company”) will maintain physical, administrative, and technical safeguards, and other security measures (i) to maintain the security and confidentiality of Information accessed, collected, used, stored, or transmitted by the Company, and (ii) to protect that his Information from known or reasonably anticipated threats or hazards to its security and integrity, accidental loss, alteration, disclosure, and all other unlawful forms of processing. Without limitation, the Company will comply with the following requirements:

1.1 Data Governance. MixShift’s privacy and data handling policy governs the appropriate conduct and technical controls that is applied in managing and protecting information assets. MixShift keeps inventory of software and physical assets (e.g. computers, mobile devices) with access to PII, and update regularly. A record of data processing activities such as specific data fields and how they are collected, processed, stored, used, shared, and disposed for all PII Information should be maintained to establish accountability and compliance with regulations. MixShift, according to the privacy policy, can rectify, erase, or stop sharing/processing the customers information where applicable.

1.2 Encryption and Storage. All PII is encrypted at rest using using industry best practice standards (AES-128, AES-256, or RSA with 2048-bit key size (or higher), this depends on particular server configuration. The cryptographic materials (e.g., encryption/decryption keys) and cryptographic capabilities used for encryption of PII at rest is only accessible to the processes and services. PII is not stored in removable media (e.g., USB) or unsecured public cloud applications (e.g., public links made available through Google Drive). Any printed documents containing PII should be securely disposed.

1.3 Access Management. MixShift assigns a unique ID to each person with computer access to Information. MixShift does not create or use generic, shared, or default login credentials or user accounts. MixShift implements baselining mechanisms to ensure that at all times only the required user accounts access Information. Mixshift reviews the list of people and services with access to Information at least quarterly, and remove accounts that no longer require access. MixShift restricts employees and contractors from storing Information on personal devices. MixShift maintains and enforces “account lockout” procedures by detecting anomalous usage patterns and log-in attempts, and disabling accounts with access to Information as needed.

1.4 Password Management. The Company establishes minimum password requirements for personnel and systems with access to Information. Password requirements include a minimum of eight (8) characters, contain upper and lower case letters, contain numbers, contain special characters, and rotated at least quarterly.

1.5 Least Privilege Principle. MixShift has implemented fine-grained access control mechanisms to allow granting rights to any party using the Application (e.g., access to a specific set of data at its custody) and the Application’s operators (e.g., access to specific configuration and maintenance APIs such as kill switches) following the principle of least privilege. Application sections or features that vend PII must be protected under a unique access role, and access should be granted on a “need-to-know” basis.

1.6 Logging and Monitoring. MixShift gathers logs to detect security-related events (e.g., access and authorization, intrusion attempts, configuration changes) to the Application and systems. MixShift implements this logging mechanism on all channels (e.g., service APIs, storage-layer APIs, administrative dashboards) providing access to Amazon Information. All logs must have access controls to prevent any unauthorized access and tampering throughout their lifecycle. Logs themselves should not contain PII and must be retained for at least 90 days for reference in the case of a Security Incident. MixShift has 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). MixShift should perform investigation when monitoring alarms are triggered, and this should be documented in the Incident Response Plan.

1.7 Network Protection. MixShift has implemented network protection controls to deny access to unauthorized IP addresses and public access must be restricted only to approved users.

1.8 Access Management. MixShift assigns a unique ID to each login with computer access to Amazon Information. MixShift reviews the list of people and services with access to Amazon Information on a regular basis (at least quarterly) and removes accounts that no longer require access. MixShift restricts employees from storing Amazon data on personal devices. MixShift will maintain and enforce “account lockout” by detecting anomalous usage patterns and log-in attempts, and disabling accounts with access to Amazon Information as needed.

1.9 Encryption in Transit. MixShift encrypts all Amazon Information in transit (e.g., when the data traverses a network, or is otherwise sent between hosts). This is accomplished using HTTP over TLS (HTTPS). MixShift enforces this security control on all applicable external endpoints used by customers as well as internal communication channels (e.g., data propagation channels among storage layer nodes, connections to external dependencies) and operational tooling. MixShift disables communication channels which do not provide encryption in transit even if unused (e.g., removing the related dead code, configuring dependencies only with encrypted channels, and restricting access credentials to use of encrypted channels). MixShift uses data message-level encryption where channel encryption (e.g., using TLS) terminates in untrusted multi-tenant hardware (e.g., untrusted proxies).

1.10 Incident Response Plan. MixShift holds and maintains a plan and/or runbook to detect and handle Security Incidents. Such plans 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. The Company reviews and verifies 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. The Company notifies Amazon (via email to 3p-security@amazon.com) within 24 hours of detecting Security Incident or suspecting that a Security Incident has occurred. The Company investigates each Security Incident, and documents the incident description, remediation actions, and associated corrective process/system controls implemented to prevent future recurrence. The Company maintains the chain of custody for all evidences or records collected, and such documentation will be made available to Amazon upon request (if applicable). If a Security Incident occurrs, The Company 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 for each Security Incident, and documents the incident description, remediation actions, and associated corrective process/system controls implemented to prevent future recurrence.

1.11 Request for Deletion or Return. MixShift within no more than 72 hours after Amazon’s request permanently, and securely delete (in accordance with industry-standard sanitization processes, e.g., NIST 800-88) or return Amazon Information upon and in accordance with Amazon’s notice requiring deletion and/or return. MixShift also permanently and securely deletes all live (online or network accessible) instances of Amazon Information within 90 days after Amazon’s notice.

2. Additional Security Requirements Specific to Personally Identifiable Information

The following additional Security Requirements will be met for Personally Identifiable Information (“PII”). PII is granted to The Company for select tax and merchant fulfilled shipping purposes, on a will-have basis. If an Amazon Services API contains PII, or PII is combined with non-PII, then the entire data store will comply with the following requirements:

2.1 Data Retention. The Company 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, or (iv) meet legal requirements, including tax or regulatory requirements. If the Company is required by law to retain archival copies of PII for tax or other regulatory purposes, PII will be stored as a “cold” or offline encrypted backup (e.g., not available for immediate or interactive use).

2.2 Data Governance. The Company will create, document, and abide by a privacy and data handling policy for their Applications or services, which govern the appropriate conduct and technical controls to be applied in managing and protecting information assets. A record of data processing activities such as specific data fields and how they are collected, processed, stored, used, shared, and disposed for all PII should be maintained to establish accountability and compliance with regulations. The Company will establish a process to detect and comply with privacy and security laws and regulatory requirements applicable to their business and retain documented evidence of their compliance. The Company will establish and abide by their privacy policy for customer consent and data rights to access, rectify, erase, or stop sharing/processing their information where applicable or required by data privacy regulation.

2.3 Asset Management. The Company will 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 PII will abide by all of the requirements set forth in this policy. The Company will 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. The Company will securely dispose of any printed documents containing PII.

2.4 Encryption at Rest. The Company will 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 will be only accessible to the Developer’s processes and services.

2.5 Secure Coding Practices. The Company will not hardcode sensitive credentials in their code, including encryption keys, secret access keys, or passwords. Sensitive credentials will not be exposed in public code repositories. The Company will maintain separate test and production environments.

2.6 Logging and Monitoring. The Company will 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. The Company will implement this logging mechanism on all channels (e.g., service APIs, storage-layer APIs, administrative dashboards) providing access to Information. All logs will have access controls to prevent any unauthorized access and tampering throughout their lifecycle. Logs will not contain PII unless the PII is necessary to meet legal requirements, including tax or regulatory requirements. Logs will be retained for at least 90 days for reference in the case of a Security Incident. The Company will 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). The Company will implement monitoring alarms to detect if Information is extracted from its protected boundaries. The Company should perform investigation when monitoring alarms are triggered, and this should be documented in the Developer’s Incident Response Plan.

2.7 Vulnerability Management. The Company will create and maintain a plan and/or runbook to detect and remediate vulnerabilities. The Company will protect physical hardware containing PII from technical vulnerabilities by performing vulnerability scans and remediating appropriately. The Company will conduct vulnerability scanning or penetration tests at least every 180 days and scan code for vulnerabilities prior to each release. Furthermore, The Company will control changes to the storage hardware by testing, verifying changes, approving changes, and restricting access to who may perform those actions.

3. Audit and Assessment

The Company will maintain all appropriate books and records reasonably required to verify compliance with the Acceptable Use Policy, Data Protection Policy, and Amazon Services API Developer Agreement during the period of this agreement and for 12 months thereafter. Upon Amazon’s written request, The Company will certify in writing to Amazon that they are in compliance with these policies. Upon request, Amazon may, or may have an independent certified public accounting firm selected by Amazon, audit, assess and inspect the books, records, facilities, operations, and security of all systems that are involved with the Company’s Application in the retrieval, storage, or processing of Information. The Company will cooperate with Amazon or Amazon’s auditor in connection with the audit or assessment, which may occur at the Company’s facilities and/or subcontractor facilities. If the audit or assessment reveals deficiencies, breaches, and/or failures to comply with our terms, conditions, or policies, the Company will, at its sole cost and expense, and take all actions necessary to remediate those deficiencies within an agreed-upon timeframe. Upon request, the Company will provide remediation evidence in the form requested by Amazon (which may include policy, documents, screenshots, or screen sharing of application or infrastructure changes) and obtain written approval on submitted evidence from Amazon before audit closure.