Security and Compliance
Jan 1 2022 at 12:00 AM
Introduction
The purpose of this page is to describe common questions related to security and compliance measures currently in place at IoT.nxt®. The document is structured in the following manner:
- Regulatory environment – a section describing how we deal with certain regulations.
- Security at IoT – how we manage security at the IoT.nxt® offices.
- IoT.nxt® solution security – how we secure our solution.
Table of contents
- TOC
Regulatory environment
General privacy statement
Refer to Data Protection and Privacy Policy.
Cookies and logging
Cookies may enable us to improve our service to you, estimate our audience size and usage patterns, store information about your preferences and recognise when you return to our website. When you access our website, information is automatically received and stored on our server logs, which information may include your location, IP address, cookie information and the relevant pages you have requested. We may also obtain information about your general internet usage by using a cookie file which is stored on the hard drive of your computer. You can adjust your browser settings to refuse the use of cookies. Some examples of the data collected using automated links include time spent on our website, the objects that were clicked on details of the website where you were referred from. We will not share this information with anybody.
Technical cookie details
The Commander currently makes use of 6 cookies, namely:
- .AspNetCore.Antiforgery: This cookie is used by ASP.net to protect against cross-site request forgery attacks.
- .AspNetCore.Identity.Application: This cookie is used by ASP.net to store a session token related to identity management.
- __cfduid: This cookie used by Cloudflare to provide security features.
- auth_route: Session variable for authentication route information (typically used for sign-in purposes).
- dapi_route: Session variable related to a dapi route (typically used to call APIs from Javascript).
- idserv.session: A cookie created by IdentitiyServer for user session management.
Minors
We do not intend to directly or indirectly market to children, and this website, our applications and general business offering have not been designed for use by or intended for children. Minors, therefore, require the consent of a competent person, and persons under the age of 16 years in Europe require the consent of their parent or trustee.
ISO Accreditation
Refer to ISO Accreditation.
Security at IoT.nxt®
Physical security
Mandatory access control is enforced when entering the office part through manned access gates. Guards are stationed at building entrances to control visitor access. Access to the office is protected using fingerprint scanners and RFID access tokens. Server room access also controlled using fingerprint scanner and RFID access tokens – only administrators are allowed access. Security cameras are placed at strategic locations within the building, and a sign-in system is in place where visitors need to register.
We do not host our Commander™ or V-Raptor™ in our server room – the platform is hosted in AWS. Please refer to AWS physical security for more information.
Employees
Screening
Employees are currently screened based on work experience and skill levels. Security background checks are not currently performed.
Access procedure
A person is only granted access to the IoT.nxt® network after all legal paperwork has been completed and signed. This includes signing a non-disclosure agreement. Access granted on the principle of least privilege and uses receive the minimal amount of permissions needed to fulfil their duties. An employee’s network and office access are terminated on his/her last day at IoT.nxt®.
Operations
Removeable media
Most of our important business assets are in the cloud. Tools such as SharePoint and Azure DevOps allow the team members to function without having to use removable storage media.
Document management
Our documents, email and other Office systems are hosted by Microsoft. The solution provided by Microsoft offers authentication, authorisation and document versioning capabilities. Microsoft provided an extensive writeup about their cloud security capabilities.
Document access control
Role-based access control (RBAC) is enforced to control access to documents. Users are assigned the minimum amount of permissions needed to fulfil their duties. Documents are stored in O365 SharePoint. Access control enforced, and users are granted access to documents when access is required by them to fulfil their duties.
Network security
Firewall
The IoT.nxt® Centurion office is protected by a Cisco Firepower firewall. The advanced threat detection, malware detection and URL filtering modules are all enabled to protect our office from network-based cyber threats.
Intrusion detection
At our office, we monitor network traffic to detect patterns that are consistent with patterns associated with known viruses using an intrusion detection system (IDS). IDS logs are monitored daily to detect and respond to network-based threats quickly.
Network separation
At the office, the network is segmented into various VLANs, based on business requirements.
Endpoint protection
We currently use endpoint protection software provided by Webroot to protect devices used by our staff.
Remote access
We do have a VPN that can be used by employees for remote access. Valid VPN credentials (password protected private key and certificate) required to obtain access to the VPN.
Vulnerability assessments
We perform weekly vulnerability scans on all devices connected to our network. Vulnerability assessments are also performed when network changes are introduced.
Password policies
Password strength requirements
A password consists of eight or more characters. Three out of four of the following is required:
- Lowercase characters.
- Uppercase characters.
- Numbers.
- Symbols.
Brute-force attacks are blocked using a “smart lockout” feature. The smart lockout blocks offending hosts from performing brute-force attacks while ensuring that legitimate users can still access their accounts. The use of compromised passwords is not allowed. Microsoft maintains a list of compromised passwords and passwords are tested against the list.
Multi-factor authentication
Multi-factor authentication is enforced for all Office365 account, Azure ActiveDirectory (Azure via Azure ActiveDirectory) and AWS.
Development processes
Testing
Changes are tested by developers. Once developers are done testing the changes, then changes are tested formally in QA. The release in QA is signed off by a quality control manager.
Development, QA, and production environments currently exist. Data is not shared between these environments.
Source control
All source files are managed by Azure DevOps. Strict access control is enforced, and developers are only granted access to source files that they require access to in order to fulfil their duties. All checked-in source files undergo a thorough code inspection before being merged into a release.
Release management
Releases are performed in three-week cycles. Clients are notified of new releases before the release and notified again after a release. Emergency releases are performed under certain conditions (an example may include the discovery of a high-risk vulnerability by our security team). Under such conditions, the clients will be notified before and after the release.
Penetration tests
Penetration tests and vulnerability assessments performed by the IoT.nxt® security team to ensure that vulnerabilities are not present that can be exploited by attackers, malware and viruses. External penetration tests are also performed by reputable firms.
Security vulnerabilities are documented and addressed according to severity. Important security vulnerabilities related to production versions are communicated to customers as soon as possible. See security patch process for more information.
Incident response
The IoT.nxt® incident response team consists of members with suitable qualifications and years of incident response experience. A forensic investigation is conducted, and all findings are documented. Corrective measures are implemented according to shortcoming discovered during finding.
IoT.nxt® solution security
Commander™ (provided as a service)
This section describes the use-case where the Commander is provided as a service to the client. With this model, IoT.nxt® manages the solution on behalf of the client.
Multi-tenancy
The Commander™ is deployed in AWS in a shared environment or private AWS environment, based on the agreement that the client negotiated with IoT.nxt®. In a shared model, the client shares space with other tenants. All tenants use separate databases meaning that it is not possible for any tenant to access the data of any other tenant.
In a private AWS environment, no other tenants are running in the same AWS environment as the client’s tenant.
Hosting
The Commander™ is hosted using AWS in Frankfurt.
Network security
The Commander is protected by network security groups within AWS. Only ports are exposed that are explicitly required for service delivery. The Commander™ is based on a microservice architecture and all services run in containers. Containers are not directly exposed to the internet and all public-facing traffic pass through ingress controllers to reach containers. Database access not possible at the ingress controller. Distributed denial-of-service protection (DDOS) provided by Cloudflare.
Patch management
Operating systems in virtual machines are configured to automatically download and apply security patches.
Support
The Commander™ is supported by the team at IoT.nxt® using Rancher. Direct SSH access to containers not possible.
Data storage
The Commander™ stores data in Mongo databases. The Mongo databases are in Frankfurt. The volumes used to store the data can be configured to be encrypted when a tenant is deployed.
Personal information
The following personal information is stored for account management purposes: first name, last name, email address and telephone number. Refer to our privacy policy for more information.
Backups
Cloud infrastructure backups are stored in AWS. The backups stay in the cloud and are not transferred over the network.
Cryptography
All data in transit is encrypted with TLSv1.2 or better.
Authentication and authorisation
The Commander™ supports OAuth-based authentication provided by IdentityServer. Role-based access control is enforced. Integration with 3rd party OAuth providers (such as Azure AD) possible and can be configured when a client’s tenant is built.
Passwords
It is possible to configure the password policy used per tenant. The configuration is done when the tenant is created.
Logging
The Commander maintains a detailed audit log of user actions. Login, logout, user management and configuration change events are logged.
Commander™ (self-hosted)
This section describes the use-case where the Commander is hosted on client infrastructure.
Multi-tenancy
Self-hosted instances are not shared with other tenants.
Hosting
The Commander™ can be hosted on-site or in the client’s cloud instance.
Network security
It is the responsibility of the client to ensure that enough network protection mechanisms (firewalls, intrusion detection systems, etc.) are in place to provide adequate protection from network threats.
Patch management
The client should ensure that all virtual machines and operating systems are configured to automatically apply security patches.
Support
Support to the platform is provided by the client’s support team or by IoT.nxt®, depending on the agreement in place.
Data storage
The Commander™ stores data in Mongo databases. The Mongo databases are typically stored at the data centre hosting the Commander™ (but may be located elsewhere, according to the client’s requirements).
Personal information
The following personal information is stored for account management purposes: first name, last name, email address and telephone number. The information is stored in the Mongo database in the client data centre.
Backups
It is the responsibility of the client to ensure that backups are created of operational data.
Cryptography
All data in transit is encrypted with TLSv1.2 or better.
Authentication and authorisation
The Commander™ supports OAuth-based authentication provided by IdentityServer. Role-based access control is enforced. Integration with 3rd party OAuth providers (such as Azure AD) possible and can be configured when the client’s tenant is created.
Passwords
It is possible to configure the password policy used per tenant. The configuration is done when the tenant is created.
Logging
The Commander™ maintains a detailed audit log of user actions. Login, logout, user management and configuration change events are logged.
Raptor™
Hosting
The Raptor™ is hosted on-site by the client.
Network security
The Raptor™ is hosted on a site controlled by the client. The client needs to ensure that adequate network protection is in place to protect the Raptor™ from network-based threats.
Patch management
The Ubuntu Core and Ubuntu Snap system automatically download and applies the latest software used by the Raptor™.
Support
Raptor™ support is provided by IoT.nxt® using SSH.
Data storage
The Raptor™ has not been designed to store data for extended periods of time. However, the Raptor™ does have a caching feature where telemetry data received from sensors are temporarily cached if the Commander™ cannot be reached (due to networking issues). The cached data is transmitted once the Commander™ is reachable again. The cached telemetry data are received from the sensors and will not contain personal data (unless the sensors sending data to the Raptor capture personal data).
Personal information
The Raptor™ does not require any personal information from users.
Backups
Cloud infrastructure backups are stored in AWS. The backups stay in the cloud and are not transferred over the network.
Cryptography
All data in transit is encrypted with TLSv1.2 or better.
Authentication and authorisation
The Raptor™ configuration portal uses role-based access control. Only support and administrator users can edit the Raptor™ configuration settings.
Passwords
Passwords are used to protect the Raptor web management interface and the SSH client. Password composition policies are not currently applied by the Raptor web management interface.
Logging
The Raptor™ maintains a log of system events that occurred.
V-Raptor™ (provided as a service)
Hosting
The V-Raptor™ is hosted in the IoT.nxt® AWS instance.
Network security
The Commander™ is protected by network security groups within AWS. Only ports are exposed that are explicitly required for service delivery. The Commander™ is based on a microservice architecture and all services run in containers. Containers are not directly exposed to the internet and all public-facing traffic pass through ingress controllers to reach containers. Database access not possible at the ingress controller.
Patch management
V-Raptor software updated during each release cycle.
Support
The V-Raptor™ is supported by the team at IoT.nxt® using Rancher. Direct SSH access to containers is not possible.
Data storage
The V-Raptor™ has not been designed to store data for an extended period. However, the Raptor™ does have a caching feature where telemetry data received from sensors are temporarily cached if the Commander™ cannot be reached (due to networking issues). The cached data is transmitted once the Commander™ is reachable again. The cached telemetry data are received from the sensors and will not contain personal data (unless the sensors sending data to the Raptor™ capture personal data).
Personal information
The V-Raptor™ does not require any personal information from users.
Backups
The V-Raptor™ does not store any data. As such, data backup not strictly required.
Cryptography
All data in transit is encrypted with TLSv1.2 or better.
Authentication and authorisation
The V-Raptor™ supports OAuth-based authentication provided by IdentityServer. Role-based access control is enforced.
Passwords
It is possible to configure the password policy used per tenant. The configuration is done when the tenant is created.
Logging
The V-Raptor maintains a log of system events that occurred.
V-Raptor™ (self-hosted)
Hosting
The Commander™ can be hosted on-site or in the client’s cloud instance.
Network security
It is the responsibility of the client to ensure that enough network protection mechanisms (firewalls, intrusion detection systems, etc.) are in place to provide adequate protection from network threats.
Patch management
V-Raptor™ software updated during each release cycle.
Support
Support to the platform is provided by the client’s support team or by IoT.nxt®, depending on the agreement in place.
Data storage
The V-Raptor™ has not been designed to store data for extended periods of time. However, the Raptor™ does have a caching feature where telemetry data received from sensors are temporarily cached if the Commander™ cannot be reached (due to networking issues). The cached data is transmitted once the Commander™ is reachable again. The cached telemetry data are received from the sensors and will not contain personal data (unless the sensors sending data to the Raptor™ capture personal data).
Personal information
The V-Raptor™ does not require any personal information from users.
Backups
The V-Raptor™ does not store any data. As such, data backup not strictly required.
Cryptography
All data in transit is encrypted with TLSv1.2 or better.
Authentication and authorisation
The V-Raptor™ supports OAuth-based authentication via the Commander™ IdentityServer. Role-based access control is enforced.
Passwords
It is possible to configure the password policy used per tenant. The configuration is done when the tenant is created.
Logging
The V-Raptor™ maintains a log of system events that occurred.