This document governs the security practices at MagicBus. This is a public document, open to review by MagicBus customers. New employees will review this policy with their hiring managers, and all employees will review this policy on at least an annual basis.
MagicBus will follow generally accepted security best practices. MagicBus will also implement new compliance measures and certifications. This means the policy will update over time. Updates to this document will be timely and transparent available on MagicBus.io.
This document was last edited August 24, 2017.
Customer Data is data input into MagicBus' API and SDKs, and includes end user data such as names, emails, and addresses. Production Data includes customer trip requests, customer subscription plan, and customer payment identification on top of Customer Data. Application logs are also production data.
Each customer will have access to MagicBus' services such that their data is identified and separate from other customers. MagicBus will restrict access such that only a customer who input customer data has access to retrieve that data.
When Production Data is in transit, communication should be secured using industry standard methods such as SSH Client/Server, SSL, VPN and SSL/VPN. This includes all communication between clients and servers, such as API clients & SDK to production application servers. This also includes database clients in application servers connecting to databases. Web console access to any production system management tools must be over HTTPS.
Production data will be stored on encrypted disks when at rest. This includes both development machines and hosted database services. Database backups should be encrypted. Software security patches must be implemented upon discovery including database updates, operating system updates, and other application updates.
MagicBus systems require active processing of data. This includes things like in-memory data stores, in-memory processing, and actively changing database tables. Data in use will not be encrypted. All access to systems processing data in use will be limited and any transfer of this data is covered by the data in transit policy above.
When feasible, MagicBus will leverage managed solutions for hosting and data storage. This ensures high reliability, performance, and adherence to the goals of our security policy. Current providers include Stripe, Intercom, Twilio, AWS, and Heroku. Hosted systems provide immediate software library and operating system security patches and updates.
Local devices including desktops, laptops, cell phones and tablets will be used to access MagicBus email and other services for MagicBus for development and testing.
Development and testing will occur on MagicBus hardware, with exceptions requiring direct approval. Two factor authentication should be used when available. All devices should have a password or lock code, and should use two factor authentication when available on third party services. MagicBus approved hardware should have encrypted hard drives. In the event that a MagicBus device is lost or stolen, it should be remotely wiped if possible.
New employee hires will be trained in the MagicBus Security Policy. Training involves reviewing the policy with the employee's hiring manager. New hires must sign a confidentiality and invention assignment agreement. Consultants and contractors will be treated like full time employees. New hires will be given full background checks through MagicBus' current provider. MagicBus' current provider as of August 24, 2017 is Checkr.
Employee candidates who will be responsible for production systems will have an assessment of security knowledge and experience as part of their interview process.
New hires who require access to production data will have access provisioned as part of onboarding by the CEO, Chris Upjohn. Only this provisioning process will allow people access to production systems. In the interests of business continuity, other administrators may be designated to complete this process.
MagicBus will deploy a shared secret management system to secure access to system tokens and passwords. The current management system is 1Password. Where possible, systems that support two factor authentication will be used.
Upon termination, any employee with access to production systems and data will have that access revoked. Access to MagicBus email and other communications channels will also be revoked. Machines (desktops, laptops, smart phones, etc) which have connected to MagicBus email or services must be cleared of MagicBus data and code.
Employees who knowingly violate this policy will face disciplinary action including termination of his or her employment.
If a security breach occurs, report the incident immediately to Chris Upjohn. Determine the severity of the breach. Notify affected customers of the breach within a timely manner, in at most 48 hours. Notification should include description of the incident, whose data was affected, and the status of remedies.
Immediately shut down access and revoke tokens and passwords that have been compromised. If necessary, shut down the live application until the breach has been contained and a security patch has been implemented. Verify customer identity before restoring access to customers.
When we have confirmed or reasonably believe that an incident was caused by a malicious attack, evidence must be properly collected and maintained. No log files should be deleted and no data backups should be deleted. The current state of the application code must be identified with the ability to rollback to the state of the application code at the time of the incident.
MagicBus will implement regulatory and legal security requirements. Such requirements change over time and across different geographies. MagicBus will routinely review and update the security policy based upon these changes.
As of August 24, 2017, MagicBus is exploring compliance with the European Union Data Protection Directive. MagicBus will likely execute the European Commission Standard Contractual Clauses, but this process is currently being reviewed.
MagicBus is built upon the trust our customers have in our systems. The only acceptable use of processing customer data is to improve quality, reliability, and performance of MagicBus' service. MagicBus is not a data broker: MagicBus may not sell or license customer data. Only third parties required to provide MagicBus' services will access customer data; notable examples include third party server and database hosts such as AWS and Heroku.
MagicBus customers create user accounts to access MagicBus services. The passwords associated with these user accounts must be stored using an industry standard password hashing mechanism as recommended by the NIST.
MagicBus production access tokens must be stored as environment variables in the secured servers. Access to third party services for testing should use testing specific passwords and access tokens that do not have access to production services or data. Test tokens may be embedded in code, such as production testing infrastructure without access to production systems.
All production systems are hosted off site, so all production system access is remote access. Data centers are managed by hosting service providers such as AWS and other providers. They are housed in non-descript facilities, and critical facilities have extensive setback and military grade perimeter control berms as well as other natural boundary protection. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, state of the art intrusion detection systems, and other electronic means. Authorized staff must pass two factor authentication no fewer than three times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.
Physical access to MagicBus' office will be restricted to authorized personnel. Office access is locked during non-business hours including nights and weekends.
Changes to process must be reviewed and approved by Chris Upjohn, or an employee designated by Chris. This document will be reviewed annually, and may be updated. Customers should be notified of updates to this document.
New services and tools that are used must comply with the terms of this document. Any new services or applications that violate this document must be reported and reviewed by Chris Upjohn.