Security

SOC 2 Report

We work with an independent auditor to maintain a SOC 2 report, which objectively certifies our controls to ensure the continuous security of our customers’ data.

Developed by the Assurance Services Executive Committee (ASEC) of the AICPA, the Trust Services Criteria is the set of control criteria to be used when evaluating the suitability of the design and operating effectiveness of controls relevant to the security, availability, or processing integrity of information and systems, or the confidentiality or privacy of the information processed by the systems at an entity, a division, or an operating unit of an entity. Our SOC 2 report is available for review upon request.

Encryption and Hashing

• All data is encrypted in transit using TLS, utilizing strong ciphers and key-lengths.
• All data is encrypted at rest. We currently use AES-256-GCM as a cipher.
• Encryption keys for data are generated and stored in AWS Key Management Service (KMS) which prevents access to underlying keys.
• User passwords are salted and hashed with bcrypt when stored, ensuring they cannot be retrieved.
• API tokens (to access OpsLevel) are also salted and hashed with bcrypt. OpsLevel does not store raw API tokens, only their hash for authentication.
• OpsLevel can integrate with third party services like Slack and GitHub / GitLab. Access tokens for these services are stored in our primary db along with other customer data. To prevent tokens from being stored “in the clear” in the db, all access keys / tokens are additionally encrypted with AES-256-GCM before being stored in the db.

Tenant Isolation

OpsLevel provides strict logical segregation of customer data.

Customer data is stored in multi-tenant datastores and assigned a unique tenant token for ownership. Processing of customer data validates that tenant token against authentication and access control information for the requesting session or process.

Threat Modeling

Threat modeling is incorporated into the design and implementation of all software at OpsLevel to understand specific risks associated with the intended change as well as the system as a whole.

OpsLevel performs threat modeling utilizing STRIDE, PASTA, Persona non Grata, Attack Trees, and CVSS scoring.

Vulnerability Management

OpsLevel employs automated vulnerability scanning on all libraries and components on deployed systems.

Engineering leadership meets biweekly to review our systems’ operational health and security, including review and triage of open vulnerabilities as detected by our dependency scanning tools. We implement patch SLAs based on the criticality of the vulnerability. Software patches are released as part of our continuous deployment process.

SSO and SAML

OpsLevel supports SAML for user authentication. This allows us to integrate with various identity providers (idPs) and allows our customers to directly control access and authentication to OpsLevel. We allow SAML initiated user provisioning and access management. SAML authentication can be used in conjunction with other authentication methods (e.g, username/password) or as the only available authentication method.

Access to Customer Data

OpsLevel enforces the principles of least privilege and need-to-know. Access to customer data is limited to only those users with a strict business requirement to do so and at the lowest allowable access level.

OpsLevel maintains separate environments for production (for customer data) and staging / integration (for OpsLevel internal testing).

Accessing the production environment containing customer data requires authentication and authorization, including MFA. Access to this environment is monitored and logged for security purposes.

Customer data is strictly prohibited from exiting the production environment, except in very limited circumstances such as in support of a customer request.

Monitoring and Alerting

OpsLevel monitors its production systems and critical infrastructure for security and operational events using a variety of open source and commercial tools.

Metrics and logging information is centrally collected for a variety of concerns (e.g., API calls, OS system calls, authentication and authorization failures). This data is fed through a system of custom rules designed to identify errant, malicious, or unapproved behavior.

OpsLevel practices service ownership. We maintain a 24/7 on-call team that is trained to handle unexpected events and incidents.

Data Centers and Physical Security

OpsLevel is hosted on AWS. OpsLevel does not maintain physical servers and all production access is remote.

AWS maintains one of the most secure data centers on Earth. These data centers are SOC 1 & 2 and ISO certified, and utilize the most secure physical security technologies, such as biometrics. Physical access is monitored by professional security staff at the perimeter and at building ingress points using video surveillance, state of the art intrusion detection systems, and other electronic means. Authorized staff must pass two factor authentication no fewer than three times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.

OpsLevel is a fully remote company and does not have a centralized office.

Security Training and Awareness

At OpsLevel, we strongly believe that security is everyone’s responsibility.

All OpsLevel employees and contractors undergo security awareness training as part of their onboarding when they join and annually thereafter. Training is tracked and monitored.

OpsLevel’s security training program weaves security into technical and non-technical roles with the goal of reducing risk by making trust decisions explicit.

Software developers at OpsLevel undergo additional security training around secure practices for coding and application development (e.g., OWASP Top 10).

OpsLevel's security posture is documented and monitored and can be viewed on our trust page.

Change Management Process

OpsLevel’s software development lifecycle aligns with Agile principles. Security is applied throughout the Agile release cycle to catch security-oriented software defects as early as possible to decrease the likelihood of a security issue and improve the mean response time for security vulnerabilities.

OpsLevel practices continuous integration and delivery. All code changes are tested with an automated suite of thousands of unit, integration, and end-to-end tests. All code changes require code review and approval from peers and management before being deployed to the production environment.

Our infrastructure is represented in code and is also updated through a version-controlled continuous deployment system.

All deployed changes are logged with the author, reviewer, and timestamp.

Incident Management

OpsLevel monitors its production systems for operational and security events and maintains a 24/7 on-call rotation to respond to incidents. Incident severity is classified based on customer impact and duration of the incident.

OpsLevel largely follows PagerDuty’s Incident Response and Security Incident Response process, which our founding team contributed to. After an incident is resolved, we run a formal post mortem and implement action items.

Hiring Practices

OpsLevel performs a variety of checks prior to hiring any new employee, including employment, references, visa verification, and criminal background. All personnel at OpsLevel are bound by a confidentiality agreement.

All OpsLevel employees and contractors undergo security awareness training as part of their onboarding when they join and annually thereafter. Training is tracked and monitored.

As part of our Device Security and Encryption Policy, all laptops / workstations require full-disk encryption and strong credentials.