Policies

Please see the PDF attached at the end of this article.

Delegation of security features

In most places we leverage existing security solutions by industry-leading 3rd party providers, such as Google Cloud platform. This removes the majority of exploitable vulnerabilities in cloud-based web apps of similar nature to our product. We refer you to their documentation in those instances below, but we provide an overview of where and how those solutions are implemented.

Some Industry best practices adhered to:

• Principle of least privilege

• All data is encrypted in transit and at rest, see our article on Encryption

• Dependency Scanning

• Container Scanning

• Web Security Scanning

• Proactive Data Loss Prevention Scanning

• Web Security Scanning

• Offsite Backups (Data-loss prevention)

• All nodes are Private, they are not allocated Public Addresses

• Automated Key Rotation

Database Admin Access and Credentials

Our database is provisioned by the Google Cloud Platform, in particular, the Firebase suite of products. Read / write access to the data is restricted to administrative service accounts with private key credentials (x509).

Only our own back-end servers perform read / write via these admin service accounts, and no other services or 3rd parties are privy to these credentials. We ensure these keys are never exposed through:

• We avoid creating static copies/downloads of private keys and rely on Google's run-time environment to automatically manage admin credentials in cloud server deployments

• Exclusion from code repositories and version management systems (Github, Git)

Role-based management of our app ensures that only our development team (and not, for example, sales) has access to these keys to download or use.

Client authentication and Firewall

We ensure that only our web-browser app can successfully perform REST requests to our server API. This is done through both client authentication, as well as a firewall on our server.

In client authentication, we mint and sign JWTs (JSON Web Tokens) for a limited duration session. Clients must provide this authentication token on all HTTPS requests to our servers, and must refresh them regularly. The signing and verification of tokens is entirely handled by a Google Firebase Authentication server. (https://firebase.google.com/products/auth/).

Development versions of our app are subject to a Google-provisioned Firewall to prevent requests from outside our development team. (https://cloud.google.com/appengine/docs/standard/python/creating-firewalls).

We do not store any employee passwords, as authentication happens through federated providers (Microsoft, Google) through SSO (see Client Roles below).

Federated Provider Access Tokens

In performing 3rd party calendar and HRIS integration, we obtain access/refresh tokens or API keys with the right to read customers' HRIS data or calendars organization-wide. These tokens/keys are stored securely (encrypted) in a secondary database. In order to make requests to Google Calendar, Outlook Calendar or HRIS vendor APIs with these tokens, we decrypt these credentials at runtime.

Tokens or keys must always be accompanied by a secondary credential, typically client secret or username/password respectively. We ensure that the tokens/keys and their respective secondary credential are stored in separate environments, accessed by different admin service accounts.

Client access and roles

Users login to our web app with their organization's Outlook or Gmail credentials. If you have single-sign-on (SSO) enabled, this will work with these credentials automatically.

Only a customer's program administrators have the right to access the program administrator portal, which contains information regarding mentor/mentee matches, feedback given by employees, and other information sensitive across employees in the organization. All other employees only have access to pages and features in the web app for managing their own mentorship experience.

In the case of employees leaving or joining a customer's organization, we rely on two factors to expire or grant access to the platform and their account:

• They must be able to provide their identity through Outlook or Gmail login, thus their email and password must be valid

• They must be deemed an active employee in the organizational data provided by the customer