Query Security Protocols

SOC2

Developed by the American Institute of CPA’s (AICPA), SOC2 defines criteria for managing customer data based on five “trust service principles”:

• Security
• Availability
• Processing Integrity (Quality Assurance & Monitoring)
• Confidentiality
• Privacy

While Query is SOC2 certified, we will also, transparently, outline for you below the controls and drivers behind each of these principles as we have implemented them. Query also adheres to the fundamental principle that “compliance does not equal security”. Therefore, where possible, we have gone above and beyond the required principles to adhere to our value of “security by design” on our journey to achieve compliance. We recognize that many third party risk management teams, customers, and auditors value numerous compliance frameworks around the globe and our goal is to adhere to those secondarily as we maintain a strong security posture first and foremost.

User Authentication

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.

Role Based Access Controls (RBAC)

In-line with our core value of transparency, we do not currently support RBAC in our product, but this is a product feature that is slated for QX-202X.

Password and Credential Storage

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.

Uptime

Query maintains a 99.99% uptime. Detailed information on our site reliability is below in our Cloud Security section.

Query is a Software as a Service (SaaS) product that is hosted in Amazon Web Services (AWS). As such, many of our controls utilize native, built-in AWS controls where it makes sense to ensure security, availability, and integrity of IT systems and data.

Physical Security & Data Hosting

Query utilizes AWS data centers in the US. Currently we are only hosting our of “us-east-1”, however have the capability to deploy to other regions based on our scalability and growth, in addition to AWS Federal to support FEDRAMP requirements.

Dedicated Security Team

Query’s security team is led by a Chief Information Security Officer that sets, oversees and executes the security strategy in accordance with industry landscape changes and business demands. Additionally, the Query security team is on call 24/7 to respond to security events, alerts, and other security activities. The security team is also reachable through a dedicated email address: security[@]query.ai to address any security, data, or privacy concerns.

Intrusion Detection & Prevention

Query utilizes a “defense in depth” strategy when deploying its systems. At each of these layers there is security monitoring in place to detect anomalous activity. For non-temporary cloud infrastructure, such as EC2 instances, we utilize EDR capabilities as a line of defense for detection & prevention. For web based traffic to the Query application, we leverage unique architecture to validate web requests sent to the back end. Front loading these requests is a Web Application Firewall (WAF), where we utilize a combination of best practice rules in addition to fine tuned rules that go through a security review before being applied to the WAF. When security events match predetermined thresholds, our 24×7 security team investigates and determines if a security event has become an incident that must be addressed.

DDoS Mitigation

Query utilizes a multilayer combination of technologies for our approach to DDoS protection & mitigation. By utilizing AWS CloudFront, we are able to implement AWS Shield as well. This provides always-on network flow monitoring, which inspects incoming traffic to AWS services and applies a combination of traffic signatures, anomaly algorithms, and other analysis techniques to detect malicious traffic in real time. AWS’s in-line attack mitigations are applied in real time to reduce latency impact. Additionally, we have WAF rules in place to do rate limiting on front end requests.

Logical Access

Access to the Query Production Network (QPN) is restricted by an explicit “need-to-know” (aka: least privileged) principle. However, it doesn’t stop there. The Query development, testing, staging, and production environments are all independent AWS organizations that are managed by their own IAM policy groups. This access is frequently audited and monitored by the security and technology organization, with ultimate accountability falling to the CISO & CTO respectively. Access to each of these organizations is restricted based on business need and enforced through our password policy and OTP multi-factor authentication (no SMS based MFA authorized), in addition to finely tuned IAM policies in our identity provider. No individual in the organization has a user account within any AWS organization directly, regardless of its risk level. Additionally, the AWS root account password is randomized, and “deleted” meaning no one has access to the root account (emergency procedures covered under our DR plan). Developers, through the environments “least privilege” IAM policies can only push code to their respective environments through our Infrastructure as Code (IaC) methodology, and only in accordance with their permission levels (see Application Security).

Failover and Disaster Recovery (DR)

Query was built with disaster recovery in mind. Our architecture is deployed via IaC (Infrastructure as Code) meaning that it can be triggered via automation when the disaster recovery plan is initiated and deployed to another region rapidly. Our infrastructure is currently only spread across one availability zone, however that was a risk accepted decision. We have tested our DR plan, and could deploy to additional availability zones as we scale our business.

Virtual Private Cloud

All of Query’s infrastructure is in their own AWS organization (development, testing, staging, & production), and in their own Virtual Private Cloud. Additionally, almost all of Query’s infrastructure is containerized. Network based access control lists (ACL’s) are utilized within each organization, and each VPC, to ensure authorized network based traffic is only allowed to authorized network segments.

Backups and Monitoring

Query monitors numerous activities across its application and teams. All activity in AWS is logged via CloudWatch and stored via S3 buckets for archival purposes. Security relevant data is analyzed via the security teams, and performance data is analyzed by the application and operation teams. All authentication (success & failures) to all production infrastructure are logged, monitored, and audited.

Query does not store any customer data. Period. Therefore, there is no customer data to back up.

Permissions and Authentication

Query makes use of client API to communicate with security tools to facilitate its primary business value. Query makes use of 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 and 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.

Encryption

Query does not store any customer data. API information is stored in AWS via the AWS Secrets Manager, that has been audited and certified with multiple accreditations, including DoD Cloud Computing Requirements. Additionally all traffic to and from the Query application is encrypted with TLS that has achieved an “A” grading from Qualys SSL labs testing. link here

Penetration Testing & Vulnerability Scanning

Query conducts penetration testing annually, as part of our SOC2 requirement. As we release major versions of our application, we may conduct “spot” penetration testing depending on the changes to our code base that require it. These penetration tests are done by an outside firm that must pass strict requirements to ensure that the penetration test is not mistaken for a “vulnerability report” and meets industry demands for a comprehensive test. Query utilizes a combination of methods for vulnerability scanning. As a large majority of our application is containerized, we leverage AWS Inspector heavily to identify vulnerabilities in our ECR as they are pushed to their respective deployment zones. We also utilize Github enterprise security features to identify security related vulnerabilities in code as commits are being made. These vulnerabilities, based on severity and an internal risk management process, are addressed prior to code being pushed to production. Query will never make available raw penetration testing or vulnerability scanning reports. Those are classified internally as “Company Sensitive” for obvious reasons and will not be shared outside of Query.