We practice “defense in depth” with many layers of protection between a potential attacker and customer data. Our hosting provider uses network-based intrusion detection to identify and mitigate threats before they reach the dedicated Interact production environment. They’re also prepared to mitigate any denial-of-service attacks. A firewall rejects all inbound traffic other than HTTPS and HTTP. Hosts behind the firewall can only be reached by VPN through the firewall. We configure all hosts in the production environment to meet our secure baseline standard. Administrative access to the hosts containing customer data requires 1) key- and password-based authentication to the firewall’s VPN, 2) key-based authentication to the web server, and 3) key-based authentication to the data server.
Researchers discover security vulnerabilities often, and we frequently apply patches to our hosts to address those vulnerabilities. We also use network vulnerability scanning tools to find problems in our environment.
Our hosting provider takes all reasonable measures to prevent unauthorized physical access to the Interact production environment. The facility is staffed by qualified engineers at all times (24/7/365), and is protected by closed-circuit cameras, and biometric and card access systems. There are multiple checkpoints to controlled areas, and all equipment is housed in locking cabinets, cages, or suites. They regularly complete SSAE 16 Type II audits to ensure these controls are maintained.
“Defense in depth” also permeates our web application. Data is encrypted in transit and at rest in our database. HTTP traffic is redirected to use HTTPS; all communication between our customers and our platform is encrypted in transit. Access to customer data requires authentication with a username and a password that conforms to our strong-password policy. Brute-force authentication attacks are mitigated with temporary account locking. After you authenticate, our platform provides fine-grained control over access to data; you can apply read, write, and administrative permissions to individuals or teams.
New features in our platform are reviewed for security considerations before approval, and secure design and development practices are used to implement these features. We use penetration testing to find vulnerabilities in our platform, and work immediately to remove them.
Our web application uses Stripe to accept payments online. This allows us to avoid storing any credit numbers in our production environment, reducing the financial incentive for an intrusion.
We maintain a detailed disaster-recovery plan covering many possible issues that may affect our service, and we test it regularly. The current recovery point objective is 24 hours (i.e. no issue will cause more than 24 hours of lost data). The recovery time objectives for the various possible problems range from 0 to 48 hours (6-12 hours for the most probable issues).
Customer data is backed up to a secure environment at a remote facility every night. All customer data is considered confidential, and is stored only in the production and backup environments. Any storage media that contained customer data at any time is sanitized (physical destruction, degaussing, or repeated random overwriting) upon removal from either the production or backup environments.