Rencore Governance Security Overview

Index

• Data Access Policies, Security, and Infrastructure 

   º Information Security Policy

   º Roles and Responsibilities 

   º Infrastructure

   º Application

   º Access Control

   º Secure Development and Change Management

   º Data Privacy

   º Availability

Technical overview

   º Cloud components

   º Solution technology

Data Access Policies, Security, and Infrastructure

This section elaborates on our data access policies, security measurements, and high-level overview of components used in our infrastructure.

Information Security Policy

Where can I find a copy of your Information Security Policy?

Where can I find a copy of your Master Service Agreement or SLA?

Roles and Responsibilities

Who can access data and systems at Rencore?

Only senior qualified staff in the Technical Operations team have access to our production cloud environments and subscriptions.

What level of access do subcontractors or third-party partners have to your cloud systems?

No access. Subcontractors and third-party partners do not have access to any
production- or cloud environments.

Infrastructure

How do customers connect securely to your solution?

The web portal interface is always enforced over SSL (https). Any communication with data
storage happens from the web portals backend and applies an additional layer of security as
described later in this document.

How do you secure your infrastructure and the services in Azure?

Rencore Platform is hosted in a separate Azure subscription. Nobody has access to this
subscription except for the IT team, which has access to the cloud infrastructure. No inherent
access to customer data or encryption keys is allowed anyone at Rencore unless specifically
granted.

All resources in the Rencore Platform infrastructure are deployed into a specific Virtual Network, where firewalls are enabled by default across all services. Requests are automatically denied unless the requests are coming from a service within the virtual network. No external requests are allowed, even if they were authenticated. Only the Web Application allows external requests from users on the frontend.

We make use of Azure Key Vault for storing sensitive information, configuration, and encryption keys. The Azure Key Vault is only accessible to the Rencore Platform services, all running in the same limited Virtual Network. No person or other service can make requests to the Azure Key Vault.

Processing data from a customer tenant (connecting to, downloading, and analyzing data),
happens from inside Azure Container Instances. Every ACI is isolated in the network and is
uniquely deployed for each customer. We destroy each container when the analysis has finished, and therefore we can never re-use containers.

Does your infrastructure adhere to any compliance standards policies?

We are not certified for any standard. However, the Azure Security Center reports for the
following compliance reports indicate we have a very good security posture across our Rencore
Platform subscription.

RC_FactSheet-802x251

Application

If your system or application is web-based and connects to a database, what measures have been taken to mitigate SQL Injection?

We only use No-SQL and have no inherent risk of injection attacks for SQL type databases in our systems.

Have you tested your system or application against OWASP Top 10 issues, and other security
vulnerabilities?

We executed OWASP ZAP (Zed Application Proxy) attacks against the solution, ensuring none of the OWASP threats were successful.

Access Control

Please elaborate on how you manage tenant access and authorization to your solution.

We use multi-tenant Azure AD applications. Customers consent to these AAD apps to grant the
Rencore Platform access to the data required to perform analysis and monitoring.

Customers can at any point revoke the App-Only or Delegated permissions granted to our
applications.

Secure Development and Change Management

Do you utilize any form of SDL (Security Development Lifecycle) in your code development
framework?

We do not have any specific process for SDL. We have made use of vulnerability scanners and
security analyzers on the codebase.

Please explain how you handle defects and describe the process for bug handling.

Bugs and requests for improvements and changes are reported by customers to our support
team. They classify and escalate accordingly to the Product team for verification,
implementation, and roll-out.

If it is a security-related defect, it is automatically flagged as a high severity and all teams are
engaged.

In your Quality Assurance Testing, do you make use of automated and manual testing?

We have a growing set of automated functional UI tests.

In your Quality Assurance Testing, do you verify the performance aspects of the application?

Yes. We run automated functional UI tests, and we perform performance tests to understand
where there may exist bottlenecks. We also investigate the performance recommendations of
the services running in Azure.

Our service is limited by the hosted services we analyze (Office 365). The performance of
the analysis is therefore always limited to that of the Microsoft online services throttling
restrictions.

In your Quality Assurance Testing, do you check for security vulnerabilities?

We utilize the OWASP ZAP tools to execute OWASP Top 10 attacks against the application to
check for vulnerabilities.

Data Privacy

Please elaborate where to find your data privacy information.

Please provide information on where or at which datacenter the customer data will reside.

Microsoft Azure datacenters in West Europe.

If your system or application contains privacy data at rest, does the system encrypt this data, and how?

Yes. All information is encrypted.

Azure Storage Accounts have built-in support for encryption at rest, and in-transit. In addition to this, we add another layer of cryptographic AES 256-bit industry-standard encryption around the data before it is transmitted to the storage.

If your system is designed to process, store or transmit privacy data is it compliant with the EU
General Data Protection Regulation.

Yes. We are GDPR compliant.

How do you ensure that GDPR can be complied with, with regards to the stored customer data?

By default, usernames and e-mail addresses are anonymized. We also store URLs, title and other metadata of the collected data like Site Collections, Sites, Lists, Teams, etc. The collected
customer data can be removed at any time by removing the encrypted storage tables belonging to the customer.

Any PII information is also encrypted.

Customers can request to our support to have all their data deleted.

When a customer terminates its business arrangements with you, how long after the termination do you hold or keep customer data before it is completely purged?

The customers can delete their accounts in Rencore Governance portal which immediately
(within max. 10 minutes) deletes all stored data.

What data leaves the client, and when? (both in transit, and at-rest)

Depending on the configured inventories and checks in Rencore Governance, during the scan of an Office 365 tenant, we collect for instance information about site collections and child
elements (sites, lists, files, customizations), teams, O365 groups, etc. This data is validated by our governance rules and we store information about violated rules in our backend.

Is data leaving the client encrypted?

Yes. We utilize all the built-in capabilities of encryption in transit (SSL) and encryption at rest
(Azure Storage Encryption). To add to this, we apply an additional layer of industry standard
256-bit encryption for all customer data.

How is it prevented that third parties access data leaving the customer? Including Rencore.

Limited staff at Rencore has access to our cloud environments in production. Full audit logging
and alerts are enabled for all administrators. All data stored in the Rencore Platform system is
encrypted, and protected behind firewalls in Azure, disallowing any requests not residing from
inside the protected virtual network.

Availability

Do you have any SLA’s regarding availability?

No.

Is the application limited to use in certain regions?

No. We allow requests from all regions to our applications.

Technical Overview

This section describes, at a high-level, what Azure cloud components we utilize, and what components and technology the solution is built on.

Cloud Components

What components of the Azure Cloud do you use?

The Rencore Platform service relies on the modern cloud capabilities of Microsoft's public
cloud, Azure.

  • Virtual Networks
    • Subnet for Container workloads
      • The containers connect to this subnet.
    • Subnet for App Service workloads
      • The Web Apps and Function Apps connect to this subnet.
  • Managed Identity
    • We use User Assigned Managed Identity to grant the Functions and Web Apps
      access to resources like the Azure Key Vault.
  • Azure Storage Accounts
    • Storing the system data required for operating the solution.
    • Saving the customer data necessary to provide accurate reports.
    • The firewall is enabled and only allows traffic through the dedicated subnets. No
      external traffic is permitted.
  • Azure App Services
    • Azure Function Apps
    • Web Apps
  • Azure Key Vault
    • Secrets and sensitive data are protected.
    • The firewall is enabled and allows traffic through the dedicated subnets. No
      external traffic is permitted.
  • Azure Container Instances
    • Isolated Docker containers, per-customer, without reachable endpoints or ports.
      Secured behind the internal networks.
    • Used to retrieve data securely from customer tenants and process in the solution,
      fully isolated on a per-analysis, per-customer base. We destroy containers after
      each analysis.
    • Resides in the protected virtual network, in the container subnet.
  • Azure Application Insights
    • We send telemetry and diagnostics to an Application Insights instance, enabling
      us to monitor the solution's health.

Solution technology

Can you describe the macroscopic solution architecture at a high level?

The solution uses the latest version of .NET Core. Currently, this is .NET Core 3.1 with
LTS (Long-Term Support) from Microsoft. We upgrade and patch the system regularly
when there are updates to the dependencies and frameworks used by .NET Core.

Rencore Platform design looks like this, at a high level:

  • Docker containers: Built on the latest version of .NET Core base images from
    Microsoft.
  • Web Application: Built on the latest version of Blazor, for ASP.NET Core.
  • Function Apps: Built on the latest version of .NET Core, and running the latest
    version in Azure.

How do you handle data security in the solution?

We rely on the built-in security mechanisms of Microsoft and their industry-standard
data protection layers in-transit and at rest. However, we take this one step further by
adding another security layer around any data in our systems.

  • At rest: We use all the built-in encryption mechanisms of Microsoft Azure. We
    extend this with an additional layer of cryptography using AES 256-bit industry-standard encryption algorithms in the solution code.
  • In transit: We use SSL for all communication, and before being sent, we encrypt all
    data using the additional AES 256-bit industry-standard encryption algorithms.