Can We Ever Create Systems which are Secure-by-design?

I am lucky enough to be invited to discussions with government, and recently I was involved in a discussion around the “Secure by design” consultation [here]. It was perhaps fitting that our meeting was in the place which holds so much data on our past (The Dome in New Register House, Edinburgh):

There was a strange feeling, there we were talking about the next generation of electronic devices, and which had artificial intelligence built into them, whilst around as circulated the books of our previous generations.

So here are the 10 guiding principles that would be involved within a security marking scheme:

1. No default passwords. All IoT device passwords must be unique and not resettable to any universal factory default value.
2. Implement a vulnerability disclosure policy. All companies that provide internet-connected devices and services must provide a public point of contact as part of a vulnerability disclosure policy in order that security researchers and others are able to report issues. Disclosed vulnerabilities should be acted on in a timely manner.
3. Keep software updated. All software components in internet-connected devices should be securely updateable. Updates must be timely and not impact on the functioning of the device. An end-of-life policy must be published for end-point devices which explicitly states the minimum length of time for which a device will receive software updates and the reasons why. The need for each update should be made clear to consumers and an update should be easy to implement. For constrained devices that cannot physically be updated, the product should be isolatable and replaceable.
4. Securely store credentials and security-sensitive data. Any credentials must be stored securely within services and on devices. Hard-coded credentials in device software are not acceptable.
5. Communicate securely. Security-sensitive data, including any remote management and control, should be encrypted when transiting the internet, appropriate to the properties of the technology and usage. All keys should be managed securely.
6. Minimise exposed attack surfaces. All devices and services should operate on the “principle of least privilege”; unused ports must be closed, hardware should not unnecessarily expose access, services should not be available if they are not used and code should be minimised to the functionality necessary for the service to operate. Software should run with appropriate privileges, taking account of both security and functionality.
7. Ensure software integrity. Software on IoT devices must be verified using secure boot mechanisms. If an unauthorised change is detected, the device should alert the consumer/administrator to an issue and should not connect to wider networks than those necessary to perform the alerting function.
8. Ensure that personal data is protected. Where devices and/or services process personal data, they should do so in accordance with data protection law. Device manufacturers and IoT service providers must provide consumers with clear and transparent information about how their data is being used, by whom, and for what purposes, for each device and service. This also applies to any third parties that may be involved (including advertisers). Where personal data is processed on the basis of consumers’ consent, this must be validly and lawfully obtained, with those consumers being given the opportunity to withdraw it at any time. Consumers should also be provided with guidance on how to securely set up their device, as well as how they may eventually securely dispose of it.
9. Make systems resilient to outages. Resilience must be built in to IoT services where required by the usage or other relying systems, such that the IoT services remain operating and functional.
10. Monitor system telemetry data. If collected, all telemetry such as usage and measurement data from IoT devices and services should be monitored for security anomalies within it.

In the discussion we talked about whether consumers would actually want and care about cyber security marking on IoT devices, and whether they would actually be willing to pay extra for more security. For me, you can have guidelines, but you need to have proper testing too, and that consumers should be able to see that a device has been through some for of minimum standard for testing, and which can be replicated.

Conclusions

Go get involved in the debate!

Personally I know that vendors will always try to make it easy for things to get setup, and that Cyber Security just gets in the way. So we still have major hurdles to cross … can we make devices which are easy to setup and use, but which are secure by design.

Here’s some of the risks involved: