No. Being hosted locally at the customer’s site on a closed network, the MiR system must be operated and managed locally. However, the MiR Technical Support team, your distributor, or your integrator can in certain cases provide remote support to help troubleshoot a given issue remotely. This requires the local operator to make the robot available for remote access. For increased security, a robot should be available for remote access only during the remote support session and in as short a time span as possible.

Figure 1.1 shows how the MiR solution integrates into a customer’s infrastructure.

Figure 1.1. The figure illustrates how the MiR robot and MiR Fleet are deployed in a customer's infrastructure. Robots communicate wirelessly with the MiR Fleet via a WiFi infrastructure available on-site. Users interact with the robot or fleet via a browser.

Being hosted locally at the customer’s site, it is the responsibility of the integrator or distributor and customer to establish disaster recovery plans and maintenance plans. The MiR system has various ways to backup and restore configurations and data that can be used to build the appropriate disaster recovery for the given customer and usage.

The MiR System contains simple ways to handle in-system back-ups and restores. MiR Fleet and robots support point-in-time recovery, enabling customers to restore robot and fleet to a previous configuration. Backups are automatically generated before software updates and rollbacks but can also be manually generated through the user interface or triggered via REST API. Backups created by the MiR Fleet are stored in a way that enables customers to enroll the backups in an external backup system.

The MiR System as such does not include features related to failover or redundancy, except from the in-system back-up and restore functionality. MiR Fleet Server uses Docker to leverage the benefits of containerization to enable the software to be hosted on a variety of host operating systems. However, MiR Fleet Server does not support any kind of managed container technology like Kubernetes, Docker Swarm, or similar.

The distributor or customer is fully responsible for updating and maintaining the application after commissioning. MiR delivers software updates, including security updates, on a regular basis, making them available for download for MiR distributors. The distributor or customer is fully responsible for deciding whether to apply, and when to apply, available updates. The availability of software updates may depend upon the service level acquired from MiR by the distributor or customer.

No. Software updates are installed locally on-site. Robots are updated individually, requiring physical or local access to the product.

MiR uses the Major.Minor.Patch.Hot fix format to version our software releases. For example, 2.8.1.1 means that the software is based on the second major release, the eighth minor release of the major version, the first patch release of the minor version, and, in this example, a single hot fix is included too.

• Major releases include the most significant changes that affect the entire software.

• Minor releases often include new features and smaller changes that only affect parts of the software.

• Patch releases focus on solving small issues in the software and introducing quality improvements.

• Hot fix releases are only created when a patch release has introduced a critical issue that needs to be fixed immediately.

It is not possible to install additional software on the MiR robots. The robot is an embedded system whose integrity is the sole responsibility of MiR and the distributor or integrator servicing the system. Unauthorized modification of the embedded system will invalidate the warranty. The stability and performance of the entire system may suffer if modified unauthorizedly. If the customer runs MiR Fleet Server Solution, the host OS (on which the Docker client runs) can be configured with anti-malware or similar systems if the added software doesn’t block or alter traffic between the fleet system and the robots.

MiR applies the following policy when distributing security patches for the underlying platform (operating system) and third-party software used by the MiR system:

• New security patches are distributed per every minor release.

• All patch releases under a minor release also include the security patches. Meaning, if you chose not to install the first software version in a minor release, such as version 2.9.0, the security patches will still be installed when you update to 2.9.1 or higher.

• The security patches are an integral part of the MiR software releases. Security patches are also made available in a separate file to allow customers to apply the security patches without updating to the most recent software version.

At MiR, the responsibility for information security is divided into two areas: Internal IT security, and IT security on product and application level.

Internal IT security is the responsibility of the MiR CFO, focusing on hardening the internal IT infrastructure (network, workplace IT equipment, physical access, malware protection, training) and raising the awareness and readiness to deal with security incidents as a MiR employee.

IT security on the product and application level is the responsibility of the CTO, focusing on the IT security of our products and how to ensure that they are safe and without severe vulnerabilities that could pose a threat to users or infrastructure at the user’s site.

MiR doesn’t adhere to ISO 27001 or similar standards. When deployed, our products are not hosted nor otherwise managed by MiR. The operation and hosting is the responsibility of the customer or a trusted third-party. Consequently, security standards like ISO 27001 are not considered relevant in a MiR context. MiR takes all measures that we find necessary to protect our premises, property, and infrastructure, from hazards related to cyber security. MiR expects the customer or operator to do likewise to protect their installation of the MiR system.

The MiR internal security policy describes how MiR deals with aspects of internal measures towards increased IT security. This policy is therefore irrelevant for the implementation and operation of the MiR system at the customer.

MiR will inform our partners accordingly if security issues are observed that need to be mitigated by taking measures locally at the customer’s installation. The distributor or integrator will subsequently engage with the customer to agree on which measures to take at the customer’s site to mitigate the specific risk(s). If necessary, MiR will update the affected software and release a software patch to be applied in order to patch the product(s) affected. MiR partners are informed accordingly and are expected to take the necessary action towards the customer in order to decide how and when to apply a software update.

Answer: The software development in MiR doesn’t formally adhere to a specific SDL. However, MiR is aware of the thorough work that has been done in this area by Microsoft and promoted by OWASP. MiR products are intended for deployment in controlled environments and on closed networks and should never be exposed directly on the internet or on networks outside corporate control. Therefore, SDL has not been a matter of the highest attention to MiR.

MiR is aware that IT security is of growing concern to the automation business in general and acknowledges the need for a more formalized approach in the area. Therefore, MiR is actively working in the following areas to improve our software with regards to IT security:

• A thorough IT security risk assessment of MiR products is performed and is continuously maintained and revised. The risk assessment is used to prioritize and initiate mitigative actions in software or otherwise to ensure a higher level of security. MiR uses the IT security risk assessment to take mitigative actions in ways that are proportional to the risk.

• Increased awareness about IT security among MiR employees, distributors, and end customers.

• The underlying platform used by the MiR products is patched on a regular basis to ensure that security issues at the platform level are handled as soon as possible. Security patches are included in MiR software releases to ensure installation in network environments that are unable to access resources on the internet.

Software development in MiR follows a process with QA as an integrated part. In short, the process describes that:

• Tasks must be well defined prior to development.

• When completed, tasks must be demoed to ensure that results match the requirements.

• Besides guidelines for applying automated tests during development, the development teams are also responsible for performing manual tests prior to moving the task further in the process.

• A release gets thoroughly regression tested.

• The results of the regression test are presented to the release manager who investigates the regression test, manual tests, feedback from involved departments and teams before deciding whether to approve the release or not.

• Finally, the software is released on the MiR Distributor website to be downloaded by MiR distributors.

MiR is considering ways to automate the scanning for security vulnerabilities as an automated step in our build pipeline.

The MiR system comes predefined with three default users with predefined passwords for you to start using. These are described in the MiR Robot Reference Guide and MiR Fleet Reference Guide along with instructions to create new users, user groups, and passwords. MiR advises its users to change the default password for all predefined users for increased security. Administrators can create dedicated user accounts under the relevant user group for each person accessing the product. MiR recommends that user accounts are private. Do not let users share the same account!

Users are provisioned and managed entirely in the internal user store of the MiR system. User administration is performed by the appointed local administrator.

No. The application offers authentication through a username with a password or a PIN code, as configured by the user administrator. Once the user is logged in to the system, access is granted corresponding to the access level defined by the user group.

The MiR system does not enforce any password policies. MiR encourages our users to define strong passwords for the various users on the system to meet the required level of IT security in the environment where the MiR solution is deployed. Users can change their own password, and privileged users can change the password of other less privileged users.

The user session doesn’t time out once the user has signed into the system. A user account isn’t locked or otherwise disabled in case of multiple incorrect sign-in attempts. Consequently, the application does not prevent brute-force attempts to gain access to a user account. Please note that MiR products are intended for deployment in controlled environments and on closed networks and should never be exposed directly on the internet or on networks outside corporate control.

The application does not keep a formal audit log (or audit trail) of changes to the system, the user accounts, or the configuration of the system. However, the robot and fleet systems collect a detailed system log which is used in case of system failure to aid the service-partner or MiR Technical Support in troubleshooting.

The MiR system does not support authenticating users via SAML, OAuth, or LDAP. Users are authenticated through a username and a password. Users are stored and managed in the internal user storage, which is an integral part of the MiR system.

The party or partner responsible for commissioning the MiR system is responsible for ensuring that the entire system is secured to meet the standards of the customer. This involves ensuring that user accounts used by the commissioning or servicing partner to set up and subsequently service and maintain the system is protected by a strong password to prevent unintended use.

Since July 2020, MiR robots are shipped with unique passwords for the following system parts:

• SICK safety system. The password gives access to the SICK PLC and the SICK safety scanners.

• The robot's WiFi access points.

• Remote access via Linux.

The MiR system comes predefined with three default users with predefined passwords for accessing the MiR user interface. It is the responsibility of the distributor or integrator to ensure that these default user accounts are secured by strong and unique passwords.

The MiR system supports the usage of TLS. The communication between MiR Fleet and individual robots is encrypted using TLS 1.2. Also, the communication from web interface to the product’s system is encrypted, as are communication to the REST-based API. The usage of TLS is a configuration of the MiR system to be applied during system setup and is not enabled by default.

Passwords are hashed using SHA256 before stored by MiR software.

Certificates are used by the system to enable encrypted message transport using TLS 1.2. Customers will have to supply their own certificates to configure the usage of TLS. Consequently, it’s up to the customer to decide which type of certificates to use and how to manage the certificates.

The robots have Ethernet, USB, antenna, power, and safety cable connections accessible from the robot. Depending on the product, these connections may be covered or used by a top module. An adversary with unlimited and unattended access to the MiR robot may be able to harm your product or otherwise alter the product configuration to cause production stop or invalidate the robot safety system. MiR advises customers to review the physical surroundings where the robots will be operating to assess if untrusted personnel will have access to the system. If additional measures should be taken to protect the robots from unauthorized physical access, please contact MiR Technical Support for advice.

MiR is aware of the works by the OWASP Foundation in general and more specifically the “Top 10 Web Application Security Risks”. MiR products are intended for deployment in controlled environments and on closed networks and should never be exposed directly on the internet or on networks outside corporate control. Consequently, MiR uses the work by OWASP to inspire our own risk-based approach in dealing with IT security in the MiR products. The OWASP approach to application security directly influences the risk assessment of our products.

The MiR solution is not a cloud-based solution, nor is the solution in any way hosted by MiR. The system will be hosted and deployed locally at the customer’s site on a network that is secured appropriately and is not accessible from the open internet. MiR does not currently engage with external or independent parties to perform penetration tests or otherwise assess the security. Instead, MiR uses the work by OWASP (and others) to inspire our own risk-based approach in dealing with IT security in MiR products. A risk assessment of our products is used to prioritize and initiate mitigative actions in our software, on the underlying software platform, or other components to reduce the risk of security incidents in our products. The IT security risk assessment is used to prioritize and commence mitigative actions in ways that are proportional to the risk.

The MiR system stores the following data, which, according to GDPR, is considered personal data: personal name, email address, and username of individuals who are users of the MiR system.

The data is stored in the database of each robot and in the database of the MiR Fleet system. The database is not encrypted, nor is the personal data encrypted. The MiR system is hosted locally by the customer or by a trusted third-party. Adhering to the GDPR regulation is the responsibility of the party managing the personal data. The data never leaves the MiR system unless the operator explicitly extracts a system log, which is used in case of system failure to aid the service-partner or MiR Technical Support in troubleshooting. If the log file is handed over to another party (MiR or a distributor), that party must adhere to GDPR regulations accordingly.