7 critical security requirements for modern IoT troubleshooting systems

In order to ensure the confidentiality of intellectual property, secrets, user data, and day-to-day operations, all information should be stored and transmitted encrypted. Confidentiality can be achieved by ensuring all network communication happens over Transport Layer Security (TLS) and that all devices use disk encryption, including edge devices, cloud servers, and user laptops. For encryption to work effectively, it is crucial to safeguard the encryption keys. Proper key management routines², limitations on how and where keys are used, using secret management solutions, and security hardware³ can help with this.

With hardware security, cryptographic keys are stored to make them easy to use for signing and encryption but almost impossible to copy or extract. As a result, it is very difficult for an attacker to steal the keys and impersonate the device. There is a high level of trust in the signatures and encryption performed by these keys.

As with authentication, it is strongly recommended that widely available, well-tested, and trusted cryptographic algorithms and libraries are leveraged instead of relying on a bespoke or alternative solution.

Once strong authentication, network protections, and encryption are established, the weakest link becomes human users. In a system with many users, it is reasonable to assume one of them will eventually be compromised. Social engineering, phishing, or exposed credentials commonly target the human user as the weakness and system entry point.

The principle of least privilege⁴ is used to limit access within software, systems, and services. At its core, it means that access should be limited as much as possible – only the people who need access should have it, and they should only have the level of access they need. The principle of least privilege provides two main benefits: limiting the access and capabilities of an attacker using a compromised account and preventing legitimate users from accidentally making damaging changes.

Access should be separated into at least three levels:

• Level 1 – Read (Default): View basic information about devices and groups of devices.
• Level 2 – Write: Level of access needed to make changes. For remote troubleshooting, users could log into devices and make changes. However, access is still restricted, and users cannot make any changes; users are only granted access to make changes that are typically needed, for example, by engineers or support staff.
• Level 3 – Admin: The highest level of access should only be given to a limited number of trusted users. This includes access to significant and potentially disruptive changes to the system and functionality, which is not needed by engineers or support staff on a day-to-day basis, such as:
  1. Managing other users and roles
  2. Managing integrations
  3. Global settings and defaults
  4. Access to view or manage secrets

Splitting access according to this three-way separation, at a minimum, is a standard practice. However, it is easy to see the benefits of splitting access up further:

• Dividing read access: Read access could be split into basic read access and access to some more valuable information, such as security or compliance related logs.
• Dividing write access: Similarly, write access for running terminal commands could distinguish between a shell user with limited access versus a root or sudo user with access to everything on the device.
• Partial admin access: Some admin actions could be split into separate roles, especially if they are needed more frequently or executed by people who don't need access to the other admin-level commands, such as adding users.

Beyond this, limiting which devices a user or role can access is also beneficial for larger organizations with many devices across different teams and departments. Users can be grouped based on geographical location (such as facility, state, country, or continent), specific hardware, product line, responsible team, or different classes of devices (such as production, test, and development prototypes).

Additionally, it is important to have routines and systems for updating and revoking access, for example, when an employee leaves the company. If the employee had access to secrets (such as passwords, tokens, and keys), these should also be revoked or rotated. If all communication with devices, or at least the authentication step, goes through a centralized system, it makes it very easy to lock out users, for example, during a security incident or after the employee leaves the company.

The method of setting up access, roles, and users requires some planning and forethought. It considers what makes sense for the specific environment while also ensuring the final state is efficient and easy to maintain. The goal should be to minimize the risk of human errors in access management and operational overhead.

When users log into devices, their commands should be logged. Similarly, changes to access, users, and groups, among other things, should also be logged. Whenever a user changes something, at a minimum, log when the change happened, who performed it, and what they changed or which command they ran.

In the case of a security incident or audit, the audit log allows you to review precisely what actions happened leading up to the event. These logs should not be stored on the device, and they should be hard or close to impossible for an attacker to delete.

Remote access systems are a high-value target for an adversary; a compromised system could give them remote access to run commands on the entire device fleet. As such, establishing a method to monitor for drastic changes in usage patterns and suspicious activity or utilizing other intrusion detection methods to be alerted if the system is being used maliciously is also critical for device security.

A system implementing all of these features – such as centralized authentication, encryption, logging, and monitoring – will rely on a combination of different libraries, components, or products.

Security should consider the maintenance complexity, especially related to custom code or configuration files that require writing, editing, or maintenance, as well as separate systems or user interfaces (UIs) that require manual work.

Beyond the initial investment, system usage – requirements to add users, user training and adoption, machine installation or configuration requirements, etc. – should also be considered. If any parts of using the system are unintuitive or require clarification, these things should be documented for users to access easily.

Managing the complexity of ongoing maintenance and configuration requirements is central to a strong security posture. Even if a system is initially set up securely, lapses in its maintenance or configuration errors create vulnerabilities an adversary could exploit.

Dedicated resources are required to verify and improve the security of your product, the remote access solution, or networked software in general. There are many options to assess security, using both internal and external resources.

It can be beneficial to work with security researchers to perform realistic penetration tests where they attempt to break into the system or device as an attacker. Internal engineers can also test the software, use scanning tools, or analyze the source code to find vulnerabilities. Bug bounty programs exist to allow individuals online to search for weaknesses to exploit, and companies only pay for confirmed vulnerabilities. A security-focused organization will want to rely on a combination of these and other approaches to ensure its products and systems are not easily breached.

Any software of significant size has bugs and vulnerabilities; software authors or maintainers release new versions to fix these issues. Ensuring software is on the latest version is a central component of security. If a device is stuck on an older version, it will be exposed to bugs (which have already been fixed in newer versions) and vulnerabilities (which have been publicly announced). Older or outdated versions will, in some cases, be easy to exploit.

The remote access software, its dependencies, the operating system, and other software on the device must be kept up to date with the latest security patches. A secure and reliable update mechanism enables frequent software updates while minimizing the risk of disruption or downtime due to an update error or unintended consequences. Most of the same IoT troubleshooting security requirements listed are also applicable to software updates.

It is essential to secure your IoT devices – ensuring they remain available to users who should have access and are inaccessible to attackers while preserving the integrity and confidentiality of data and communication. Developing and maintaining the solution needed to achieve your security and compliance requirements needs resources, even if using ‘free’ software tools and components. But in today’s digitally-dependent and connected world, security is paramount. And the risks of the alternative or potential consequences of lacking security – a successful cyberattack, data breach, device disruption, or downtime – far outweigh investing in security upfront.

To start to bolster your security, leverage a best-in-class, security-oriented, remote troubleshooting solution that encompasses and facilitates the top 7 critical security requirements. Updates, automation, remote access, configuration, monitoring, reporting, and more are best practices across security disciplines and should be embedded within individual solutions and the overall architecture supporting your products. By implementing these features and functions in a secure way, organizations can rest assured their infrastructure and devices are secure and focus resources on developing the differentiating aspects of their product.