Catalyst Security

• Users​ ​authenticate​ ​via​ ​ssh or username and password with 2-factor authentication enabled.
• To​ ​authenticate​ ​via​ ​ssh​ ​they​ ​use​ ​their​ ​username​ ​ssh​ ​key,​ ​and​ ​all​ ​users​ ​have​ ​individual user​ ​names​ ​and​ ​personal​ ​ssh​ ​keys.
• People​ ​are​ ​asked​ ​to​ ​generate​ ​4096​ ​bit​ ​key​ ​pairs.
• SSH​ ​with​ ​username​ ​and​ ​password​ ​is​ ​disabled.
• We​ ​authorize​ ​and​ ​maintain​ ​an​ ​accurate​ ​list​ ​of​ ​authorized​ ​users​ ​and​ ​ssh​ ​keys​ ​via​ GCP/AWS IAM and a secure password manager.

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.

Yes.

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:

‍

• Be a minimum of sixteen (16) characters in length.
• Be memorized; if a password is written down it must be secure.
• Be rotated quarterly.
• Contain at least one (1) character from three (3) of the following categories:

1. Uppercase letter (A-Z)
2. Lowercase letter (a-z)
3. Digit (0-9)
4. Special character (~`!@#$%^&*()+=_-{}[]\

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.

Yes.

P0 ​Process

• In​ ​the​ ​scenario​ ​where​ ​a​ ​high​ ​severity​ ​issue​ ​is​ ​identified​ ​that​ ​requires​ ​attention and​ ​resolution​ ​outside​ ​of​ ​the​ ​normal​ ​sprint​ ​process,​ ​the​ ​team​ ​has​ ​an​ ​escalation process​ ​in​ ​place.
• Specific​ ​“severity”​ ​field​ ​on​ ​tickets,​ ​when​ ​set,​ ​implements​ ​a​ ​set​ ​of​ messaging notifications​ ​that​ ​are​ ​sent​ ​to​ engineering ​staff​ ​who​ ​are​ ​on​ ​call​ ​to​ ​deal​ ​with​ ​these​ ​kinds of​ ​issues​ ​for​ ​immediate​ action.

Reporting an Incident

• Customers should report any issues or concerns through or in-application support channel. Our support team will report the issue to our engineering team for resolution and stay in constant communication with you regarding its status.
• You can always contact security@getcatalyst.io for any other issues or concerns.

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.

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)

Yes, see https://aws.amazon.com/compliance/ and https://cloud.google.com/security/compliance/.

All​ ​API​ ​queries​ ​are​ ​made​ ​with​ ​HTTPS​ ​so​ ​data​ in transit ​is​ ​encrypted.

The United States.

• Customer​ ​data​ ​is​ ​segregated​ ​via​ ​the​ customer_id ​row-level​ ​tagging​ ​approach​ ​described above.
• To​ ​segregate​ ​customer​ ​data​ ​from​ ​other​ ​clouds​ ​data​ ​we​ ​use​ an individual database instance.

TLS.

TLS 1.2 is used for any network communication.

Yes,​ ​SSL​v3​ ​is​ ​disabled.

Yes.​

Yes.

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.

Yes.

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

Yes.

Yes.

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 utilize GCP and AWS key management services.
• Our​ ​keys​ ​are​ rotated on a regular basis.

We​ ​​delete or disable​ un-needed ​users​ ​as soon as possible.

• We require 256-bit strength for symemetric keys
• People​ ​are​ ​asked​ ​to​ ​generate​ ​4096​ ​bit​ ​key​ ​pairs​ ​to​ SSH ​into​ ​the​ ​infrastructure

• Local keys are stored securely using a password manager.
  For​ ​server​ ​side​ ​keys,​ ​we​ ​use​ AWS and GCP KMS

Yes.

• Yes.​ ​The​ ​security​ ​of​ ​our​ ​wireless​ ​network​ ​connection​ ​is​ ​WPA2​ ​Personal
• All​ ​confidential​ ​communications​ ​are​ ​done​ ​using​ TLS

• The Catalyst application ​uses​ ​Google​ ​Apps​ ​SSO​ ​to​ ​authorize​ ​users​ ​into​ ​the​ ​system.
• No​ ​passwords​ ​are​ ​stored.
• There​ ​is​ ​no​ ​restore​ ​password​ ​process​ ​for​ the Catalyst application.

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.

Yes.

Yes.