TALKS

Misconfiguration, whether by accident or malicious activity, is a major cause of security breaches.

The more actors that need to be involved in configuring a system, whether that’s people or other systems through automation, the more complex the problem both in terms of the security (more rules to configure and manage) and operationally (understanding the impact that a change from A have on an overlapping change from B).

A distributed IoT system adds a further layer of complexity to configuration management. Such systems are often mobile and frequently offline creating a weakness for configuration drift from a centralised system.

And complexity is generally the enemy of resilient and secure systems. We give resilience equal billing with security because it’s no longer enough to design against known threats: systems must also be designed to deal with, and recover easily from, compromise. AI-driven automation, for example, can be less predictable than people and has the potential to become a new class of attack vector.

Most systems present their configuration interfaces as complex API, with a correspondingly complex set of rules to control who is allowed to change what. Declarative approaches such as those employed in DevOps workflows can help in some areas, but they typically create a single authorisation body, exposed to internal threat vectors.
At Configured Things we take a different approach which both removes much of the complexity and reduces the overall attack surface. Each actor has their own interface, limiting the changes they are allowed to make and keeping their changes fully independent from those of any other actor.

Our approach is based on a “zero trust” paradigm where neither the source or transport is trusted. It does not require any inbound connections to the system, removing a large part of the system’s attack surface. Authorisation to make a change is based on policies that can require multi party approval, addressing the internal threat vector.

The key to providing resilience is to focus on managing the changes rather than the resulting configuration. We treat all changes as ephemeral, so it is possible at any time to remove one or more changes and derive a new configuration from the remaining changes. In this way the person or system requesting a change does not have to take into account the current state of the system. Neither do they have to work out how to undo a specific change, the impact of which may have subsequently been modified by other changes. If a system is found to have been misconfigured or compromised the changes from that source can simply be negated and the remaining valid changes reapplied. This is much more powerful than the simple rollback mechanism approach of other declarative approaches and is essential to supporting multi-tenancy, since it allows the different actors to act independently when making and removing changes.

The management of changes is not restricted to the external interface of the system; The same approach is also used internally to pass changes to both local subsystems and remote devices, and can manage configuration changes across security domains. Each device only needs its initial safe base state and details of how to connect to receive the current set of changes. This makes it possible for devices to recover from errors and compromise, and can ensure that devices always restart in a known and safe configuration and eliminates configuration drift.

This approach, which developed with guidance from the NCSC and other Government agencies, has been developed as part of an InnovateUK funded project and is currently part of a trial system with a Local Authority.