Catalyst is a B2B SaaS company building a software platform for customer success organizations. Catalyst is based out of NYC and funded by Accel, True Ventures, Ludlow Ventures, Compound, Work-Bench.
Not at the moment. We will be implementing a formal service in the coming months
All data assets are encrypted in transit and at rest. All data assets in transit are encrypted via TLS 1.2 using 256-bit encryption. All data assets at rest are encrypted using AES-256 encryption.
At the load balancer. Internally, traffic is encrypted and certificates between load balancer and application servers are validated.
We use ActiveRecord in Rails as our ORM, which has SQL injection sanitizing cleaning included.
OpenID Connect / OAuth2 Login in the form of Google Apps OAuth.
The built-in methods and filters of the Rails framework protects us from SQL injection. With the use of ActiveRecord, we do not apply manually constructed queries.
Yes, we only load third party content from trusted third parties enforced by our content security policy.
Yes, and if the user reaches our site in HTTP, we redirect to HTTPS
Yes, the authentication cookies are marked with the secure attribute.
Rails framework has a built-in XSS protection mechanism which automatically HTML escapes all the data being transferred from Rails to HTML.
Yes, we take great care to set this, knowing that otherwise we might be introducing XSS vulnerabilities.
To connect to the systems holding the data(databases), the user is required to use TLS connections with username and password. The password must be:
Yes, both SAML and Google Apps.
We have daily automated backups of our databases and retain it for 30 days.
Yes, backups are encrypted using AES-256 using regularly rotated keys.
Once the contract is cancelled we purge the client’s data from production in the following 30 days. Once the data is gone from production the data is still in backups for an additional 30 days. After 30 days the data is gone from our system.
Reporting an Incident
All database tables with user data includes an customer_id column and all the data that belongs to the same customer is marked with the same customer_id.
All changes are first tested in a local environment. Then it must pass a code review from a different engineer. We use continuous integration to ensure that every commit triggers automated unit and functional tests before it is merged into the `staging` branch. Once the code is merged into the `staging` branch, it is deployed onto a staging environment for further automated and manual testing. Finally, the `staging` branch is merged into the `master` branch, deployed to the production environment, and then another set of automated tests are executed.
Access to customer data is only granted to trained employees as needed to perform authorized job functions. Access is easily revokable and all activity is logged.
Yes. The mock data is in the development database and the code acts as if this mock data is production data. We don't share the mock data with the production database.
Our network, servers, and databases are hosted by cloud providers.
Google Cloud Platform (GCP) and Amazon Web Services (AWS)
All API queries are made with HTTPS so data in transit is encrypted.
The United States.
TLS 1.2 is used for any network communication.
Yes, SSLv3 is disabled.
The session ID is generated using SecureRandom.hex which generates a random hex string using platform specific methods (such as OpenSSL, /dev/urandom or Win32 CryptoAPI) for generating cryptographically secure random numbers. It is not possible to brute-force Rails' session IDs.
Sessions (cookies) expire after 7 days of inactivity.
Yes. A CSRF sceurity token is transmitted between client and server and validated on every state changing request.
We protect against clickjacking using X-Frame-Options: SAMEORIGIN
We use SSH to login into the publicly accessible servers. We use SSH with certificate only and we have disabled SSH with user and password.
Version: OpenSSH_7.6p1, LibreSSL 2.6.2
We delete or disable un-needed users as soon as possible.
Yes. Each user has a unique user ID and uses his or her ssh keys.
Yes, we have a set process for revoking access to customer data from PEL employees. Once the administrator is notified, they will remove the employee from all servers that are relevant.
All data is backed up and are systems are fully restorable in the case of disaster. We regularly test our process for disaster recovery.
Our business continuity plan consists of three phases: i) Activitation and Notification, ii) Recovery, and iii) Reconstitution. Training and testing of this plan is conducted on a regular basis.
Our internal procedures for data spills follow the Report, Analyze & Assess, Clean & Rectify, Document & Learn stepwise process.
First, engineering identifies the owner(s) of the spilled data, and reports the level of the spill. Second, engineering analyzes the nature of the spilled data and potential access to determine impact. Based on this analysis, the engineering organization moves to remedy the spill using the relevant sanitization technologies. Also when necessary, engineering will notify the account management team so that impacted customers will be notified as soon as possible. Lastly a post-mortem is performed, and all prior findings are documented to then be embedded in ongoing security training and education program.
All engineering staff are put through a security education program as part of onboarding, specifically around key management, endpoint security, and other topics.
All staff who have access to customer data are subject to NDAs.