This section will show security concepts and aspects of Cumulocity, structured into physical security, network security, application security and access control. Finally, it shows how Cumulocity helps in managing the security of your IoT solution.
This section is especially intended for IT security staff and management staff. IT security expertise is required when running Cumulocity.
More information can be found in the security-related sections of the remaining documentation, like the REST implementation and User API description in the Cumulocity OpenAPI Specification. Permissions required for individual API calls are documented in the respective sections in the Cumulocity OpenAPI Specification.
Physical security
Physical security of IT systems prevents unauthorized physical access to servers, storage, and network devices.
Cumulocity Standard tenant accounts are hosted at Amazon Web Services (AWS). AWS has been certified according to ISO 27001, DSS and other standards. It features extensive physical security measures and is independently audited. Not all details are published for actual security reasons. Audit reports can be obtained directly at AWS Compliance.
Our strategic hosting partners follow up to date concepts and concepts of data security.
In IoT solutions, physical security also includes unauthorized access to IoT devices, for example, to redirect or manipulate data from devices, read credentials from devices or change a device’s configuration. We recommend you to review the physical security of the devices that you plan to use for your IoT solution and, for example, make configuration ports unavailable to unauthorized people or include tamper sensors as an additional security control within your own system.
As the operator of the Cumulocity platform we do not control internal systems of our tenants. As a tenant you must follow a powerful and carefully considered security concept for your own system.
Network security
Network security prevents unauthorized access to data transmitted over the network and tampering with or unauthorized modification of data. It also ensures that network services are available.
Cumulocity ensures that your data stays confidential and cannot be tampered with through an end-to-end implementation of HTTPS from devices to applications. It uses up-to-date encryption technology that has been independently rated “A” by SSLlabs. Any communication with Cumulocity is subject to individual authentication and authorization.
This communication architecture is illustrated below. Inside the sensor networks and from the sensor networks to agents, device- and gateway-specific protocols may be in use (such as ZigBee or Modbus). Securing these is a device-specific matter. Agents communicate with the Cumulocity platform using HTTPS to send and receive data. Similarly, IoT applications use HTTPS for communication. If an IoT application exposes own interfaces towards web browsers, it is recommended that these use HTTPS. This way, the whole path from agents to the end user is secured.
As mentioned above, Cumulocity does not require any device that might expose ports or services on the internet. This is an important feature: it not only simplifies the connection of devices to Cumulocity, but also simplifies the safety backup of these devices drastically. When deploying an IoT solution, check other services that might make a device available on the internet or expose it, such as web-based device managers or SMS-based configuration options.
Unencrypted communications
The Cumulocity platform allows old or low-power devices to connect to it over unencrypted protocols like HTTP since such devices are not capable of doing encryption or only provide weak encryption methods (for example TLSv1.0). Using old devices and unencrypted communications is discretionary and considering the risk that such communications are prone to attacks. For instance, an attacker suitably positioned to view a legitimate device’s network traffic could record and monitor their interactions with the platform and obtain any information the device supplies. Note that using a mixture of encrypted and unencrypted communications is an ineffective defense against active attackers, because they can easily remove references to encrypted resources when these references are transmitted over an unencrypted connection.
Hence, it is recommended to use transport-level encryption (SSL/TLS) to protect all communications passing between the device and the platform. The Strict-Transport-Security HTTP header should be used to ensure that devices refuse to access the platform over an insecure connection.
Application security
Application security addresses security at the software level.
Cumulocity follows standard practices for application-level hardening as making sure that only properly upgraded operating systems and web servers are in use. A number of additional “best practices” are employed to make Cumulocity secure by design.
Cumulocity supports multiple types of authentication methods, applying the best practices for each type. For more details on each type see Authentication.
“Basic authentication” features sessionless REST APIs. This means that none of the popular “session stealing” techniques will work with Cumulocity.
“OAI-Secure” provides high security, using authorization tokens to prove the identity of the user.
“Single sign-on” redirect enables the use of an external authorization provider.
Cumulocity does not use a SQL database for IoT data storage and is itself not based on a scripting language. This means that so-called “injection attacks” will not work with Cumulocity.
As discussed above, devices are clients at Cumulocity and therefore popular attacks to devices will not work.
Devices are individually connected with Cumulocity’s device registration feature. This means that if a device is stolen or tampered with, it can be individually disconnected from Cumulocity.
Application management
Cumulocity uses a versatile permission model, which consists of application access control and REST API access control. This allows to precisely define the access rules for a user.
In the Cumulocity platform, the standard applications are configured by default following the best security practices.
Important
Due to the very flexible nature of application management within Cumulocity, users can abuse certain security measures with sufficient permissions. For example, they can deploy a custom application with malicious code and make it available to the wide audience. Therefore, application management capabilities should be restricted to trusted and knowledgeable users.
Cumulocity uses a standard authentication and authorization process based on realms, users, user groups, and authorities. A realm is a database of users and user groups, who follow the same authentication and authorization policy. A user is a person or an external system entitled to access protected resources inside Cumulocity.
Cumulocity creates a new realm for each tenant to store the users of that tenant. Realms provide an own namespace for usernames, allowing users to keep the names that they are familiar with from their own enterprise IT or other IT systems. There is no conflict between usernames: A user “smith” of one particular tenant is different from a user “smith” of another tenant. This username is valid for all Cumulocity applications that a tenant subscribes to.
Each new realm is automatically populated with an initial administrator user who can create further users and user groups (that is, global roles), and who can assign permissions to them. This enables an enterprise to manage users and their permissions on their own using the Administration application.
Permissions and ownership
The ability to execute certain functionality on the system depends on two concepts: Permissions and ownership.
Permissions define explicitly what functionality can be executed by a user.
Cumulocity distinguishes read permissions and administration permissions. Read permissions enable users to read data. Administration permissions enable users to create, update and delete data. Read and administration permissions are separately available for the different types of data in Cumulocity. For example, there are read permissions for inventory data, measurements, operations and so forth.
To manage permissions more easily, they are grouped into so-called “roles”. Every user can be associated with a number of roles, adding up permissions of the user.
The following types of roles can be associated with users:
Global roles: Contain permissions that apply to all data within a tenant.
Inventory roles: Contain permissions that apply to groups of devices.
Objects in the inventory also have an owner associated with them. If you have created an object, you are the owner of it and can manage it without requiring any further permissions. Owners can always, regardless of their other permissions,
Read, update and delete the inventory objects they own.
Create, read, update and delete data associated with the objects they own.
For example, if you are the owner of a smart meter in the inventory, you can store meter readings for that smart meter even if you do not have any other measurement permissions.
The inventory also features a CREATE permission. A user having just the create permission can store new objects in the inventory, but can not read, modify or delete any other data. This is mainly relevant for devices. The CREATE permission also includes the possibility to link your object to another object as child device or child asset.
However, you cannot manage any devices or groups that you did not create yourself, unless you also have the UPDATE permission or an additional inventory role.
This concept helps to assign minimal permissions to devices.
Limiting access to managed objects
Cumulocity allows you to set global permissions that are applicable to all managed objects, measurements, events and so forth. It also allows a limitation of permits
to specific managed objects or a set of managed objects,
to a single user or a group of users,
to individual fragments.
Managing roles and assigning permissions
Global roles and inventory roles are created and managed in the Roles page of the Administration application in the UI.
A detailed description on available default roles and on creating and assigning global and inventory roles can be found in Managing permissions.
For details on permission management using the API refer to the User API in the Cumulocity OpenAPI Specification.
Globally accessible objects
It is possible to make any object accessible by any user without specific rights. To grant those rights just add a new fragment called c8y_Global to the object.
Management security
Whenever a security-relevant event occurs, it must be logged for potential auditing. Security-relevant events may happen both on application level as well as in the IoT network. A simple example of a security-relevant event on application level is a login to the application. An example of a security-relevant event on the network level is using a local software or local control on a device to manipulate the device.
To capture security-relevant events, Cumulocity offers an auditing interface. This interface enables applications and agents to write audit logs, which are persistently stored and cannot be externally modified after being written. Cumulocity itself also writes own audit records related to login and device control operations.
To receive security-related reports about the Cumulocity platform, interested parties with a maintenance contract can subscribe to Early Warnings in the Cumulocity Tech Community.
To report security incidents, please contact product support.
Summary
Cumulocity addresses security on various levels.
All business partners and service providers have recognized security certificates. Cumulocity also deals with network security aspects by individual authentication and authorization methods.
Connections from and to Cumulocity are established using HTTPS technology.
All tenants have full rights to add or terminate users and user groups. The tenant also assigns rights to agents and devices.
