Security

Infer’s Data Security

Security is our top priority at Infer. We know how valuable data is to our users (of course - we love data!), and we want to make sure that you feel maximally safe and reassured when it comes to using our product and understanding how we use your data. Outlined below are all of the details showing our end-to-end view of making Infer the securest platform possible, using modern best practices for both applicational and operational (people) security in mind.

SOC 2 Type II Compliance

As part of our commitment to data security, we are currently partnering with Drata to complete our SOC 2 Type II audit. Drata is a security and compliance automation platform that continuously monitors and collects evidence of a company’s security controls, while streamlining compliance workflows end-to-end to ensure audit readiness.

The SOC 2 Type II audit requires at least 3 months of monitoring processes, which means we expect this to be fully completed in early Q2 2023. After that, these security processes will be continuously monitored and updated using Drata to ensure full compliance in perpetuity.

Secure by Design with In-Memory Data Processing and No-Low Persistence

Infer’s SQL-inf language directly queries your data source, i.e. your data warehouse (BigQuery, Snowflake, etc) or applications connected to your warehouse like dbt. Infer processes the query in-memory using the SQL-inf API, and returns the result in the platform of execution - your data warehouse, dbt, or the Infer platform (app.getinfer.io). Infer only accesses the data necessary to execute the query - nothing more, nothing less.

With Infer, the user has full control over what is or isn’t persisted. By default, our design uses no or low persistence, depending on what is appropriate for the task at hand.

If the user has connected their data warehouse via dbt, their files are persisted only in that data warehouse, and are never stored by Infer (no persistence).

For queries executed on the Infer platform, the results are persisted for only as long as the user keeps the query in their query list (low persistence). This is to allow the user to be able to access their results without having to re-run the query. By deleting this query, all relevant data will be removed (no persistence). Similarly, by deleting a project all data related to that project, including data files, queries and results, will be deleted.

Users can themselves delete their account using the Account Settings page. The deletion of an account results in the irretrievable deletion of all data related to that account, including projects, data files and results.

In terms of caching, we perform in-memory least-recently-used cacheing for our text analysis commands, where we temporarily store text embeddings (numerical representations of text) that cannot be accessed nor decoded, to speed up the analysis of the most recently used ~65k segments of text.

Account Security

For login and sign up, we allow the option for single-sign-on (SSO) with trusted third-party login providers, Google and LinkedIn. This allows users to take advantage of their numerous security properties, like multi-factor authentication.

For traditional login, see our section on Encryption for security measures taken.

Encryption

Any data uploaded to the Infer platform is encrypted at rest. The encryption keys are managed and rotated automatically by Amazon Web Services. For sensitive information used, like data source credentials (BigQuery, dbt, etc), we use AES-256-GCM encryption layer before they are stored in our database.

Data transmission from users to Infer and vice versa is encrypted using Transport Layer Security (TLS). This ensures browser requests are never unencrypted and guarantees secure, encrypted communication between your browser and the Infer platform.

Data Source Access and Privileges

Currently Infer only supports single-user accounts, so no data sources, queries, or results can be accessed beyond the single user. Later when we will add multi-user accounts with different levels of privileges and access to data sources and results.

Privacy Policy

See our Privacy Policy here.

Employee Access

Infer follows the DevOps best practice of using a policy of least privilege. This is done using AWS IAM roles. Using this setup means that only the relevant users who need access to your data for their work can access it.

Code Review

Any changes to the underlying Infer code must undergo a thorough code review process by relevant engineering peers, as well as passing all of our automated testing that checks for potential issues in the code. Once approved, changes will only be applied to a staging environment, and require another level of approval to move these changes to the production environment.

Customer Support

Technical support is available via email ([email protected]) and in-app via Intercom. Organisations can also request a personal Slack channel for more fluid communication.