The following information is a snippet of data on our corporate Compliance & Security page. Please refer back to it for any additional questions.
The Query product allows Single Sign-On with your organization through popular identity providers such as Google, Microsoft, Okta and others. We also support Google SSO via OAuth 2.0. This is done through our utilization of the Auth0 product to effectively create a "Bring your Own Authentication" scenario. This ensures you have control over the users who have access to Query in much the same fashion as you do in your enterprise, and can ensure they meet your organizations password requirements.
Query uses an industry recognized password complexity standard. We will not document the exact standard here, as that would give hackers looking to password spray our login page a roadmap on how to structure their attack. Our “out of the box” configuration is for an organization to use their identity provider to log into Query, via SSO.
Query makes use of client API's to communicate with customer security tools to facilitate its primary business value. Query uses AWS Secrets Manager to store client API information. To ensure the confidentiality of this API information, Query implemented a mechanism whereby when a user runs a query, the programmatic function that is invoked makes a call to Secrets Manager, which then passes the API key to the programmatic function over a TLS connection. This function is also managed by an IAM policy to ensure that only the client's API information is retrieved. Once the programmatic function is complete, it is terminated and thus has no stored knowledge of the API credentials. This ensures that neither the programmatic function, nor any unauthorized party sniffing network traffic is able to hi-jack the credential.
The best way to describe Query in this capacity is as a data broker that acts as a go between for your security analyst, threat hunters, and other team members who would search security relevant data and the security technologies they need to complete their job. To this end, Query DOES NOT store any customer data.
Query utilizes its "Metadata" service to retain customer configurations, including which organizations you are a part of, user settings, and other non-sensitive information that is used to enhance the user experience of the platform. Query also utilizes a short term caching mechanism that is used to perform follow on searches. This information has a short TTL (Time to Live), and is destroyed between user sessions, which is also used for user experience enhancements.
As mentioned, this is only a snippet of all the security controls Query puts in place to protect its product and customer data. Query has a comprehensive set of controls that have been reviewed by auditors and attested to in our SOC2 report, and will continue to pursue industry leading compliance frameworks throughout our existence. And while compliance, does not equal security, we hope that by merging our "security by design" culture of software development with meeting & exceeding compliance expectations, we can assure confidence to our user base and display through our actions how we are different from other cyber security companies.
Updated about 1 month ago
Please feel free to visit the Compliance and Security page for more detailed information on our security posture.