Overview

Security is one of the most important aspects of using Usage Engine. This document outlines some of the basic security considerations that should be upheld when using the service. Security defines several areas of interacting with data that are important in a given aspect:

• Protection from unauthorized access
• Handling of user data
• Ensuring that technical specifications and guidelines are met

Information security is a fundamental aspect integrated across every stage of Usage Engine's software development and operational processes. Digital Route follows stringent security practices, which are rooted in the Open Web Application Security Project (OWASP) Top 10 project. To validate compliance with the OWASP Top 10 objectives, routine penetration testing is conducted by external and independent vendors. By adhering to these practices, Usage Engine attains industry-leading standards and practices, ensuring the utmost protection and meeting all enterprise security requirements.

Security principles are divided into two main types: Rules (mandatory requirements) and Recommendations (optional considerations). Each of them is mandated through a specific principle. An outline of their roles in relation to the security aspect is:

• Rules – These are mandatory actions that need to be followed to run the service as intended. Many of them are implemented directly via technical specifications and certifications.
• Recommendations – These are best practices that are not mandatory, but are considered practical in maintaining a secure environment.
  

Vulnerabilities in the software undergo a triage process, where they are evaluated and prioritised based on severity and potential impact. This enables the implementation of targeted mitigation strategies to address the most critical vulnerabilities promptly, ensuring a strong security posture and protection against potential threats.

Privacy 

Usage Engine is a highly configurable service that can support various business models and processes. Data privacy requirements are to be fulfilled by configuring system interfaces, data structures, and relevant security settings.

Consent for the service is implicit as the business use requires captured personal data to complete transactions, for example in payment processes. Additionally, in Usage Engine it is possible for end-users to build scenarios where the processed data contains personal information that is collected or forwarded across national borders.

It is the responsibility of the end-users to ensure that the configured scenarios comply with legal requirements.

Running deployments may store records that contain personal information in logs that are available to end-users. Deployments do not store individual records by default and the behavior is determined by the user-configured streams. The deployment logs are deleted after a period of 90 days. If you need the data to be removed before the expiry period, please submit your request to DigitalRoute Support.

Secure Keys Management

Secrets Wallet depends on a secure infrastructure that is carefully designed to provide a secure environment. All private operations are handled using a set of encryption keys that are used to authorize and authenticate Usage Engine operations. These keys are based on hardware security modules that use the FIPS 140-2 standard for protection. 

For security reasons, there is an automatic security keys expiration and renewal process that ensures that the best practices are met according to international standards. 

OAuth2 Implementation

The Usage Engine platform service includes support for OAuth2 in the HTTP client Function. It is implemented by following the RFC 6749 specifications and creates a secure authorization layer intended to provide restricted resources. This functionality is developed to aid integration with other services and stream interaction. During the authentication process, as defined in the RFC, additional client-side and server-side data flow interactions can take place – the use of TLS and HTTP redirection.

The use of OAuth2 creates a more secure environment and allows for heightened security to be used with complex streams where connections to an API server are required.

Best practices

Shared responsibility model

As a Software-as-a-Service provider, we follow the shared responsibility model over the security of the solution, together with its tenants.

DigitalRoute is responsible for securing the infrastructure and Usage Engine platform from external threats, ensuring data segregation between the solutions and tenants, and maintaining its availability.

Tenant is responsible for using and operating the provided solution and its functionality in a secure manner. This includes:

• Understanding product’s security and access model.
• Conducting access management according to the least privilege principle, thereby limiting the use of administrative and high-privilege accounts.
• Following password practices and account security hygiene.
• Using appropriate functions and modules within the product to make sure the intermediate processing does not expose the data to users who are not authorized or are not supposed to see it.
• Utilizing various optional security features of Usage Engine components to improve the security posture of product integrations and data processing.

These guidelines imply how to handle data and important resources within Usage Engine, and are not considered mandatory rules by the system. They are highly recommended and help to ensure that a secure environment is maintained.

Password/Credentials Guidelines

Passwords are a specially designed secret value that serves to authorize access to a given resource. In most cases, they are used alongside other identifiers to identify users and allow access to certain service sections. To combat risks involved with weak security, there are specific NIST (USA National Institute of Standards and Technology) requirements that provide the best practices and guidelines as to how a secure password can be chosen:

• Length – Passwords should be at least 8-characters long, having enough complexity as to not allow for dictionary-based attacks.
• Complexity – A high-complexity password should be used to minimize the risk of it being guessed by potential attackers.
• Validity – Best security practices delegate passwords are changed over a given set of intervals.
• Considerations – Passwords should be set unique to each application. In case of potential breaches or misuse, they should not be reused again. It is generally accepted that using dictionary words, repeating or sequential characters, as well as context-specific words significantly lowers the password strength. In case of any potential issues, the passwords are to be changed and never reused.

Account Access Precautions

An important security aspect is a way through which the service is accessed. Unauthorized access can happen due to low security on the device from which Usage Engine is accessed. In this regard, there are significant risks that should be minimized to prevent access from unauthorized parties. 

Usage Engine has three roles by design: Admin, User, and Guest, each with its own set of permissions. Both the User and Guest roles have access to streams, logs, metrics, and groups, allowing them access to production data and configuration options. This means that Guest access should be supervised and only trusted users should be granted these rights. All Usage Engine users should be aware of the Security provisions and best practices to ensure that the data is managed in accordance with the defined security principles by the Usage Engine service owners. 

To prevent abuse and potential weak security scenarios, you can protect the end-user device by following these recommendations:

• Rely on password managers – They are a safe and convenient option for storing passwords and various types of credentials. They provide password management and the option to generate secure passwords, as well as report breaches and potential issues when handling the input data.
• Rely on adequate security software – It is highly recommended that firewall, anti-virus, and anti-malware solutions are installed, updated, and used on devices accessing the Usage Engine service. This will prevent any unauthorized access via malware such as Trojans.
• Ensure needed privacy – This applies to administrators. Always set up the relevant service in accordance with the set non-disclosure agreements. Provide configuration options and details to the company via an agreed procedure.

Functions Usage and Associated Security Considerations

When using the individual function nodes, it is possible to apply some security considerations and best practices that can help set up a protected environment. Following these examples will mitigate some risks related to data leakage:

• HTTP Functions — Functions such as the HTTP or HTTP Server can be configured to handle secure connections by using the HTTPS protocol. Always strive to use them, thereby enabling an encrypted stream connection. 
• SFTP Keys Access — Authentication in the SFTP can be done either by using a password or private key access. We recommend that the private key approach is used as it constitutes a more complex approach that minimizes some risks associated with man-in-the-middle attacks and other attack scenarios. 
• Email Attachment — We advise users to enable the “TLS Only” option which keeps a secure connection from and to the relevant email server. 
• Email Notification — We advise users to enable the “TLS Only” option which keeps a secure connection from and to the relevant email server. 
• Encryption, Decryption, and Hash – We recommend that the default algorithm option of AES-256–GCM be used. 

Data Leakage Prevention

Like in any other service, data leakage can be a significant risk to the security domain. This is considered a substantial threat and there are several types of data leakage consequences: 

• Theft of personal information 
• Theft of intellectual property 
• Sensitive and classified information transfer to an unauthorized third party 

It is possible that all of these categories of data leakage can be performed on Usage Engine installations if proper security procedures are not followed. The three stages of data leakage can be accessed via the cloud access provided to users across all system-defined roles: access to the Usage Engine system, data retrieval, and data sharing. 

As preview data functions and function configuration elements can be used to access and show sensitive information including classified data, extra caution should be taken to address individual responsibility. All users that have an assigned access role to the system must be instructed on how to handle this information. Data access and Usage Engine service operations must be made in accordance with the “need to know” basis to minimize the associated risks. 

Data and Log Data Handling

Usage Engine has extensive support for both audit of the running streams and a Log Function that enables in-depth monitoring of the designated processes. Such data can be saved onto local storage and thus made accessible to everyone that has access to that location. For this reason, the security of the local storage medium should be mandated. Also note that Beta functions when in use may not have implemented a proper security model, for this reason, any information specified in these functions should be treated as insecure. 

It is also recommended to use the Usage Engine service in accordance with some of the privacy considerations. Examples of some good rules to follow are as follows: 

• Ensure monitor privacy – When working with the Usage Engine service make sure that no unauthorized people can view your screen. Manipulation of streams, input data, and credentials access should be carefully hidden from people that may guess the input based on keyboard entry or mouse movement. 
• Management of log files – Every time a Usage Engine file is saved onto a local computer or on external storage, discretion and adequate security should be managed. Files with sensitive data should be encrypted and delegated with access using passwords and other types of measures. 
• Log data analysis – When data is being imported into another application for review, it is recommended to strip down potentially sensitive information if other users have access to the stored data. 

Input/Output Data Validation Considerations

Data validation as part of the system’s JSON verification node functionality can be potentially abused by the system. There are comprehensive instructions on how this can be mitigated in the official Validate function documentation. We recommend that users be aware of the important security considerations before entering JSON schema in the system. 

Certifications 

ISO 27001 

DigitalRoute became ISO 27001 certified in 2018. This proves to our customers and partners that we are continuously managing the security of our information and data. We conduct ISO 27001 re-audits every year and a new audit every third year.

SOC 2 Type II 

Since January 2021, DigitalRoute is SOC 2 Type II certified. An independent auditor has evaluated our security controls to ensure they are suitably designed to meet service commitments and system requirements, and are operationally effective over a period of time (12 months).

ISO 9001 

DigitalRoute became ISO 9001 certified in 2020. ISO 9001 is a standard that defines the requirements for a quality management system (QMS). The standard helps businesses and organizations be more efficient and improve customer satisfaction.

PCI/DSS 

DigitalRoute Cloud Edition is not in scope of PCI/DSS as it acts as an intermediary. DigitalRoute does not process Payment card industry data nor does it offer any specialized capabilities in this area. It is each tenant responsibility to ensure that data processing routines are set according to the nature of processed data.

Useful Links

NIST Special Publication 800-63Bregarding password security. This is the policy defined by the USA National Institute of Standards and Technology, responsible for many IT standards used worldwide. 

JSON Schema Validation NSA Security Guidelines used during validation.