Effective day August 14, 2018
Our infrastructure and security team includes people who’ve played lead roles in designing, building, and operating highly secure Internet facing systems at companies ranging from startups to large public companies.
Best PracticesIncident Response Plan
We have implemented a formal procedure for security events and have educated all our staff on our policies.
When security events are detected they are escalated to our emergency alias, teams are paged, notified and assembled to rapidly address the event.
After a security event is fixed we write up a post-mortem analysis.
The analysis is reviewed in person, distributed across the company and includes action items that will make the detection and prevention of a similar event easier in the future.
Seller Labs will promptly notify you in writing upon verification of a security breach of the Seller Labs services that affects your data. Notification will describe the breach and the status of Seller Labs’ investigation.
Build Process Automation
We have functioning, frequently used automation in place so that we can safely and reliably rollout changes to both our application and operating platform within minutes.
We typically deploy code dozens of times a day, so we have high confidence that we can get a security fix out quickly when required.
All of our services run in the cloud. Seller Labs does not run our own routers, load balancers, DNS servers, or physical servers.
All of our services and data are hosted in AWS facilities in the USA and protected by AWS security, as described at http://aws.amazon.com/security/sharing-the-security-responsibility. Seller Labs services have been built with disaster recovery in mind.
All of our infrastructure is spread across 3 AWS data centers (availability zones) and will continue to work should any one of those data centers fail unexpectedly. Amazon does not disclose the location of its data centers. As such, Seller Labs builds on the physical security and environmental controls provided by AWS. See http://aws.amazon.com/security for details of AWS security infrastructure.
All of our servers are within our own virtual private cloud (VPC) with network access control lists (ACL’s) that prevent unauthorized requests getting to our internal network.
Seller Labs uses a backup solution for datastores that contain customer data.
All customer data is stored in the USA.
Customer data is stored in multi-tenant datastores; we do not have individual datastores for each customer. However strict privacy controls exist in our application code that are designed to ensure data privacy and to prevent one customer from accessing another customer’s data (i.e., logical separation). We have many unit and integration tests in place to ensure these privacy controls work as expected. These tests are run every time our codebase is updated and even one single test failing will prevent new code being shipped to production.
Each Seller Labs system used to process customer data is adequately configured and pathed using commercially-reasonable methods according to industry-recognized system-hardening standards.
Seller Labs engages certain subprocessors to process customer data. These subprocessors are listed at https://www.sellerlabs.com/third-parties, as may be updated by Seller Labs from time to time.
All data sent to or from Seller Labs is encrypted in transit using 256-bit encryption.
Our API and application endpoints are TLS/SSL only and score an “A+” rating on SSL Labs’ tests. This means we only use strong cipher suites and have features such as HSTS and Perfect Forward Secrecy fully enabled.
Seller Labs is served 100% over https. Seller Labs runs a zero-trust corporate network.
There are no corporate resources or additional privileges from being on Seller Labs’ network.
We have two-factor authentication (2FA) and strong password policies on GitHub, Google, AWS MongoDB and Seller Labs to ensure access to cloud services are protected.
Permissions and Admin Controls
Seller Labs enables permission levels to be set for any employees with access to Seller Labs.
Permissions and access can be set to include app settings, billing, user data, or the ability to send/edit manual messages and auto messages.
On an application level, we produce audit logs for all activity, ship logs to our service providers for analysis, and use S3/Glacier for archival purposes.
All access to Seller Labs applications is logged and audited.
Bastion hosts are used to login to devices.
All actions taken on production consoles or in the Seller Labs application are logged.
Security Audits and Certifications
We bi-annually engage with well-regarded third-party auditors to audit our code-base, and work with them to resolve potential issues.
We use technologies to provide an audit trail over our infrastructure and the Seller Labs application. Auditing allows us to do ad-hoc security analysis, track changes made to our setup and audit access to every layer of our stack.
Information about AWS security certifications and obtaining copies of security reports from AWS is available at http://aws.amazon.com/compliance/pci-data-privacy-protection-hipaa-soc-fedramp-faqs/
Seller Labs, Inc. complies with the Cloud Security Alliance (CSA) published best practices. See https://cloudsecurityalliance.org/star-registrant/Seller Labs-inc/for more information.
All payment instrument processing for purchase of the Seller Labs services is performed by Stripe. For more information on Stripe’s security practices, please see https://stripe.com/docs/security/stripe.
Managing your own user accounts and roles from within the Seller Labs services.
Compliance with the terms of your services agreement with Seller Labs, including with respect to compliance with laws.
Promptly notifying Seller Labs if a user credential has been compromised or if you suspect possible suspicious activities that could negatively impact security of the Seller Labs services or your account.
You may not perform any security penetration tests or security assessment activities without the express advance written consent of Seller Labs.