Crosser Security Overview

November 2023

About this document

This document describes security aspects related to the Crosser Streaming Analytics solution.

The Crosser Streaming Analytics solution

The Crosser Streaming Analytics solution has two main components:

Crosser Cloud - This is the configuration and management tool where end users build, test and deploy applications that will run on Crosser Nodes. Crosser Cloud is either hosted and operated by Crosser in Microsoft Azure or hosted and operated by the customer on its own infrastructure (‘on-prem’).

Crosser Node - This is the runtime environment deployed by end users and where the applications built in Crosser Cloud will be executed. Once deployed these applications will run independently of the Crosser Cloud service and no data processed in Crosser Nodes is sent to Crosser Cloud.

Crosser Solution Overview

Executive Summary - Use of Data

The following data is stored by Crosser (in Crosser Cloud):

Customer information - For each Crosser customer we store the following information:

• Email address of the assigned account owner (optionally also phone number)

• Country of origin

• License information

• Support level

User information - The email address is used to identify users when providing access to the Crosser Cloud service. 

Configuration data - The following configuration data can be created by end users and will be stored in Crosser Cloud:

• Flows - Workflows describing processing applications that can be deployed on Crosser Nodes. Built with the graphical Flow Studio design tool.

• Resources - Additional files that can be used by Flows, e.g. ML models, Python/C# scripts and PLC tag lists.

• Credentials - Access information, such as username/password or API keys, needed to connect to systems and services used by the Flows built by the end users. Credentials are stored encrypted (AES-256) and will never be available in the clear after entry into the system.

Log data - There are two types of log data stored in Crosser Cloud:

• Events - Activity traces from Crosser Cloud as well as anomalous events reported by Flows running on Nodes are captured in the event log. Events are stored for up to 30 days or 10 000 events.

• Node status - All Nodes report usage statistics (number of messages and data volume being processed) on a regular basis to monitor availability of Nodes. Aggregated node status is stored for one year.

Apart from the Customer Information, all other information is created, owned and managed by the end users. Crosser will not use or disclose this information to third parties unless specifically requested by the Customer, e.g. for support issues.

When hosted by Crosser the Cloud service is multi-tenant with common databases shared by all customers. Data is separated by an ID which is unique per customer. The only external access to data is through an API, which is protected with a secure token (JWT) that includes the ID.

Based on the above Crosser Cloud fulfills the requirements set forth in the GDPR regulations.

Note that no data processed in Crosser Nodes based on the Flows developed by the end users are stored in Crosser Cloud.

Definitions

Definitions of terms and vocabulary that will be used throughout the rest of this document:

Authentication

Authentication concerns the possibility to confidently identify the user of an application or a service. In the Crosser solution user/password pairs are used to authenticate users in the web applications, with the option to add two-factor authentication where a second security token is delivered to the user’s registered email address. In addition to Crosser’s internal authentication mechanisms it is also possible to authenticate users with an external identity provider through OpenID Connect. Signed security certificates are used to identify applications accessing the APIs.

Authorization

Authorization determines what resources and operations that can be accessed by the authenticated user. This allows authenticated users to be granted specific application and resource permissions. Crosser uses a role-based permission scheme where an authorized user is assigned permissions to different features of the system through the roles he has. Custom roles can be created by the administrators of each organization.

Integrity

Data integrity ensures that the correct and uncompromised information is always available and presented to users. In this document we will also use integrity to refer to mechanisms to avoid unauthorized access to sensitive data, e.g. never store or transfer sensitive information in clear and anonymizing data that impacts personal integrity. A key aspect of the Crosser solution is that no customer data processed by the Nodes is sent to the Cloud service, processed data is only sent to systems used by each customer.

Auditing

Auditing refers to logging security related events so that security breaches can be quickly identified and traced. Preferably, auditing tools should also help detect attempts to compromise the security of the system so that they can be blocked before a breach occurs.

Best practices

The architectures and design principles used when building web applications have evolved over the years and best practices for addressing security issues have been identified. Crosser tries to follow the most recent best practices, such as those presented by the Open Web Application Security Project (OWASP), and to use field-proven architectures and design patterns.

The Crosser solution

When implementing the Crosser solution some general principles have been applied throughout the design, in order to build a secure foundation. These are summarized below:

• No customer data stored in Crosser Cloud
  No customer data processed by the Nodes is sent to or stored in Crosser Cloud, customers have full control over where this data is used through the design of processing flows. The only customer data stored in Crosser Cloud is the email address of users, for authentication purposes, and flow configurations.
  
  

• All communication initiated at the nodes
  In many situations the distributed nodes will be deployed behind firewalls, e.g. close to machines in a factory. To avoid having to open up ports for incoming traffic in firewalls and NATs, all communication between nodes and the Crosser Cloud is initiated from the nodes. This will protect the nodes from unauthorized access, but also simplify the deployment of nodes.
  
  

• All communication encrypted
  All communication between the Crosser Cloud and external entities, such as nodes, web UI users and API access is based on HTTPS using TLS 1.2 encryption.
  
  

• Nodes identified with unique keys
  Nodes authenticate themselves with the Crosser Cloud using a JSON Web Token that has been cryptographically signed using HS265 (HMAC with SHA-256) from a secret root key used by the Crosser Cloud. Individual keys can be unregistered, to lock out nodes that have been compromised.
  
  

• Role-based permission control
  Access to individual features and operations is controlled by giving each user one or several roles. A role defines the individual permissions. Permissions are grouped by feature, such as flow design, node management and user administration. For each feature group View, Create, Change and Delete permissions (CRUD) can be assigned. When using external identity providers mappings can be defined between roles and groups in the external directory with roles in Crosser Cloud.
  
  

• Audit logging
  All activities that may have an impact on the security level of the system are logged in the Crosser Cloud. This includes, but is not limited to, logins, changes to access rights and roles, changes to user settings, changes to configuration settings, node registration changes etc.

High-level architecture of the Crosser IoT platform

Nodes

Registration

When a new node is deployed it must be registered in Crosser Cloud before any type of management or monitoring can occur. A unique node ID and cryptographically signed access key is then generated. A freshly installed node will initiate a registration process when it starts up for the first time. It will contact the Crosser Cloud Node API, which is found by DNS lookup of a common URL provided as part of the installation package.

In order to identify itself it will provide its unique key and access code. When a new key is received Crosser Cloud will check whether this is a valid key and if so, register the node and activate the regular communication flow (see below).

There are three ways to deploy the unique node keys on each node:

1. Generate the keys in the web UI of Crosser Cloud and transfer them to the nodes e.g. by downloading on a USB stick that is then mounted on the nodes, or transfering to a laptop that is connected locally to each node. This mode is intended for deployments with a small number of nodes.

2. Generate and retrieve the keys using the Cloud API on the Crosser Cloud and then transfer the obtained keys to the nodes as in 1. This mode will allow automated key deployment, as part of the node configuration in production.

3. Let the nodes retrieve the keys automatically by using the key request API. Accessing this API will require a special “global” key, that is unique per organization and with an expiration time. On the first startup of a node it will use this key to request its unique key. The “key request” key is then deleted, to prevent uncontrolled distribution of this key. This mode will allow mass production and deployment of nodes with identical initial configurations.

Communication

All communication between nodes and the Crosser Cloud is initiated from the nodes and terminates in the Node API. The protocol used is HTTPS and all communication is authenticated with a JWT that is refreshed at regular intervals.

There are three types of communication that can occur between nodes and the Crosser Cloud:

1. Status messages
   Each node will send a status message at regular intervals (by default every 10 seconds), which contains a summary of the node status. This message will also query the job queue for the node. If a waiting job is found it will be downloaded and executed on the node.

2. Events
   Events can be sent at any time, e.g. when an anomaly has been detected or when an explicit notification has been triggered in one of the flows running on the node.

3. Remote debugging
   To support interactive debugging of new flows on a distributed Node Crosser Cloud can ask the node to initiate a websocket connection (as a job), to allow two-way communication between the FlowStudio (running in the Cloud) and the node. This is a temporary connection that is terminated as soon as the debugging session ends. During remote debugging data processed in the node may be sent to Crosser Cloud for visualization.

In addition to the communication with Crosser Cloud, the nodes also communicate with data sources to get input data and either cloud-based or on-premise systems for delivering the results of the  computing. All communication with external systems is implemented as modules in the Crosser Module library. These modules implement the security mechanisms supported by the external systems.

Communication with local data sources may optionally be encrypted by TLS, if supported by the data source. In cases where the Crosser node acts as the server end of the communication, certificates must be provided and installed on each node by the users.

When a node connects to either on-premise or cloud based systems for delivering results, e.g. providing processed sensor data to cloud storage or triggering a workflow in a supply system based on some trigger condition defined on the node, the security mechanisms required by the receiving system are used. This typically involves providing credentials for authentication. See below for more information on how such credentials are managed within the Crosser IoT platform.

Central management - The Crosser Cloud

Deployment

The Crosser Cloud service, which includes the Flow Studio, for flow development, and the Edge Director, for multi-node orchestration and management, is hosted on the Microsoft Azure cloud platform. Most of the software and services are developed and managed by Crosser, with two notable exceptions:

• PostgreSQL database, where a service hosted by Azure is used. This service provides a safe and scalable storage system for critical data, by offering automatic replication and backup of all data. The database is only indirectly accessible through the APIs described below.

• Redis database, which is used as a temporary cache for internal communication.

System access

The Crosser Cloud system provides external access through APIs, used by the web UI, Nodes and integrations with external systems.

• Web UI and external integrations
  Used when accessed from a browser implementing the graphical user interfaces for the Director and FlowStudio, or when integrating Crosser Cloud with external systems.

• Username/password authentication
  Access is granted by the user/client providing a valid user name and password. Upon successful login a session is created and maintained until the user logs out, or the session times out. Two-factor authentication can be enabled per user and then a second security token will be delivered to the user’s registered email address.

• External identity provider
  Users can be authenticated by an external identity provider through OpenID Connect. This is setup at the organization level by mapping one or several domains with an external identity provider. Only domains that have been configured by Crosser are available for mapping by the customers.

• Node access
  Communication between Nodes and Crosser Cloud is protected with JWTs that are refreshed at regular intervals. A valid ID and key is required to request tokens. Node IDs can be deleted from Crosser Cloud to prevent nodes from requesting new JWTs to access the API.

External credentials

In order to allow flows running on nodes to connect to external systems and services, such as cloud storage or notification services, the nodes must have access to credentials for these services. Credentials are created in Crosser Cloud and stored in the central vault, to be used when defining flows. When these flows are deployed on nodes, the corresponding credentials must be transferred to the nodes, since the communication goes directly from the nodes to the external services. Credentials can either be entered manually in the Crosser Cloud UI or uploaded through the Cloud API. Each set of credentials is given a user-provided name and this name is used in all further references to the credentials, e.g. when configuring connectors in flows. The actual credentials are stored securely in Crosser Cloud and are only accessed indirectly through the Node API when transferring flow definition to nodes and through the Cloud API to update or delete credentials. Credentials are stored encrypted both in Crosser Cloud and the nodes, using AES-256 encryption . Only users with “Credentials” permission can add or delete credentials. Role-based permissions

The flows running on nodes can trigger actions in external systems. It is then important to prevent unauthorized users from setting up such actions, by mistake or with malicious intent. This is managed through the role-based permission control system enforced by the Crosser Cloud. The following access controls are relevant:

• Flow deployment
  Only users with the “Flow deployment” permission are allowed to deploy new or updated flows on nodes, as well as deleting flows from nodes. This permission includes starting/stopping flows on nodes and running remote debugging sessions on nodes. It is also possible to limit this permission to a subset of Nodes.

• Node management
  Only users with the “Nodes” permission can register/unregister nodes and create global keys.

• Credentials
  Only users with the “Credentials” permission can add or delete credentials in the central repository.

• Resources
  Only users with the “Resources” permission can add and delete resources in the central repository, such as machine learning files and program code, that may be referenced when building flows.