Understanding Cyber Security in RegScale

This page is intended to provide a high level understanding of the security mechanisms that underpin RegScale; especially as it relates to our Software as a Service (SaaS) platform. It describes the full lifecycle from how the software is built, the runtime environment, the continuous monitoring tools, and then the security layers within RegScale that enforce access controls.

SaaS Security Architecture

Above is a high level architecture of the RegScale Software as a Service (SaaS) environment. The overall process and tooling is described in more detail below:

• Software Build - all source code is stored in a private GitHub repository. Access is limited to RegScale employees, all of which are US Citizens who have passed a background check and are subject to unannounced drug tests. RegScale leverages "GitOps" to provide a highly automated and secure software build process where no developers have access to any of the infrastructure in the runtime environment. All builds and deployments leverage Continuous Integration (CI) and Continuous Deployment (CD) to automate the pipeline. The only user interaction is for manual code reviews, conducted by a separate manager, to ensure that only approved code makes it into the software. The tools for the build process are as follows:
  • GitHub - Source code repository and manages branches for GitOps
  • GitHub Actions - CI/CD tool for automated builds and testing
  • Sonarqube - source code analysis to detect quality issues, security problems, Section 508 compliance, and other code smells
  • Wiz.io - source code analysis and container scanning to identify security issues
  • Trivy and Snyk - container scanning to identify security vulnerabilities in the container
• Run-Time Environment - our SaaS environment runs in the Microsoft Azure Commercial environment which is certified to FedRAMP High. The RegScale platform runs in a container that is hosted in a hardened/serverless environment in Azure Container Instances. Inside the container, RegScale runs the latest version of Angular for the client side application and .NET Core for the server-side application. The container instances can auto-scale based on demand to handle customer load. For storage, all data is persisted to Azure SQL Server and Azure Blob Storage. Finally, the SaaS version always runs the latest Generally Available (GA) image that is published on Docker Hub. RegScale is not patched, it is continually rebuilt from the gold image based off the latest available in an immutable container providing a much smaller attack surface that is a constantly moving target.
• Authentication - RegScale integrates with external identity providers to ensure a secure access and authorization process that supports Multi-Factor Authentication (MFA). RegScale provides multiple options for authentication:
  • Azure AD Single Sign On - connects to the customer's provided Azure AD to support authentication, including support for MFA using Microsoft Authenticator, HSPD-12, etc.
  • AD/LDAP - outsources authentication to the customer provided directory for authentication.
  • Forms-Based Authentication - least secure method for access relying on username and password.
  • OAuth/SAML Authenication - coming soon!
• Encryption - all data to RegScale is encrypted both at rest and in transit. For at rest, the SQL Server database is configured to use Transparent Data Encryption so that all data is encrypted when stored. In addition, we add AES-256 encryption as additional protection of keys and other sensitive data that may be stored in the database. Azure Blob Storage is also fully encrypted at rest by Microsoft. All traffic is over encrypted TLS links to ensure data is encrypted in transit. Finally, the encryption and keys are all managed by Azure Key Vault and injected at run-time for each customer environment to provide complete separation of keys and data for each RegScale customer.
• Continuous Monitoring - all components of RegScale are monitored 24x7 using the latest security tools. There are multiple tools used for monitoring which are described below:
  • Datadog - monitors Application Performance Management (APM), availability, user traffic, and infrastructure health
  • Windows Defender - monitors for vulnerabilities and misconfigurations of all Azure infrastructure supporting SaaS
  • Wiz.io - monitors for vulnerabilities, misconfigurations, and compliance of all Azure infrastructure supporting SaaS
  • Microsoft Sentinel - cloud based Security Information and Event Monitoring (SIEM) solution that monitors all logs, detects security events in real-time, and provides automated detection and response for Incident Response (IR) processes

In aggregate, these tools provide a secure and modern Zero-Trust architecture for the RegScale platform that builds on top of the FedRAMP High security posture offered by Microsoft Azure. All aspects of the platform are secured and continuously monitored to provide the highest assurance to our customers for the confidentiality, integrity, and availability of their compliance data that is hosted in RegScale.

Access Control in RegScale

RegScale provides 4 layers of defense in depth around access control inside of the platform. The first level is infrastructure related and provides physical separation. The remaining three layers are logical segregations that provide multiple security configuration options to limit access based on need to know. These layers are explained below:

• Instances - each customer in our SaaS platform gets their own RegScale instance. This is completely segregated for that customer and includes their own container instance/runtime, database, file storage, and key vault. None of the infrastructure in the runtime is shared between customers. This approach allows for complete infrastructure segregation per customer to eliminate the ability to move laterally across customers.
• Tenants - within each customer instance, there can be multiple tenants each of which are logically segregated on the server side and within the database. Users are provisioned into a tenant and cannot access data across tenants. This approach allows each customer to further segregate their environment based on need to know, business units, use cases, etc. No user can access data outside of their tenant within RegScale.
• Roles - once a user is provisioned in a tenant, they are then assigned one or more roles. Roles are assigned to a JSON Web Token (JWT) upon authentication which is digitally signed on the server side to ensure it cannot be alterted/spoofed by the client. This JWT then enforces all access to customer data via the APIs in the RegScale container. The role options are described below:
  • Module Role - each module has its own role. This allows you to assign a user directly to certain modules and not to others. Multiple roles can be assigned to any given user.
  • Administrator - has full access to all capabilities in RegScale including back-end configuration
  • Maintainer - has read/write access to all general modules plus the ability to maintain catalogues, workflows, and other semi-administrative functions
  • General User - has read-write access to all general modules but cannot access back end administration or maintain catalogues, workflows, etc.
  • Readonly User - has read only access to all general modules but cannot access back end administration or maintain catalogues, workflows, etc.
• Record Level Access Control (RBAC) - assuming the user is their customer instance, provisioned to a tenant, and assigned the proper roles, access can be further restricted on the individual record level. Each record can be public (meaning any user with the correct access/roles above can see it) or private which means it is locked down to a specific group. If set to private, only administrators, the person who created the record, and individuals assigned to the group will be able to view the record. All access in RegScale is security trimmed so users will not be able to see any records they do not have access to. In addition, if you create a child record underneath an access controlled record, it will automatically inherit its parent's permission unless you overwrite them explicitly.