Following the February launch of the new IoT Security Assured certification, IASME has been working with the Open Connectivity Foundation (OCF) to map the scheme to OCF’s own framework. We asked Kyle Haefner, Chair of the OCF security oversight working group to tell us more about some of the challenges in IoT security and to help us understand the common ground between the two standards.
What is the story behind the Open Connectivity Foundation (OCF)? What is the motivation for the work you do?
There are already billions of IoT devices connected to the network and all predictions point toward billions and billions more. I find this simultaneously an exciting and terrifying prospect. Exciting because it will bring about new services and capabilities across many industries. New levels of automation and sensing capabilities, combined with recent advances in machine learning and A.I. has the potential to advance and enhance humanity at nearly every level. It is terrifying for many of the same reasons. These devices will integrate into our daily lives and become ubiquitous and indispensable. The opportunity for them to be abused is enormous and the security and privacy repercussions are grave. This is why securing these devices is so important and this is where OCF comes in. OCF is the amalgamation of several other IoT centric standards such as UPnP, the Allseen Alliance and Open Interconnect Consortium. OCF’s goal is to create a single standard that provides reliable device discovery and secure interoperable connectivity across OSs and platforms. What is great, is that the OCF specification is now a mature and internationally recognised standard.
How did you hear about the IASME IoT Security Assured Scheme?
The IASME scheme was brought forward by one of our diamond level members that had recently received IASME certification.
What are your thoughts about the scheme?
The IASME scheme is comprehensive, with logical groupings of the requirements. As we mapped OCF’s security clauses to the requirements, we found the guidance notes helpful in understanding and clarifying the intention of the requirement.
What are the similarities and differences between the IASME scheme and the OCF certification?
They are complimentary. I like to think of the IASME scheme and OCF certification as parts of a Venn diagram. IASME has some security requirements that can only be addressed by a physical device implementation or are specific to device manufacturers. The OCF certification is the result of a device passing hundreds of specific interoperability tests with many of those being security centric. The section in the middle where the two align is the interesting part. To this end the Security Oversight Working Group (which is the security policy arm of OCF) reviewed the IASME scheme and we mapped each requirement to a specific clause in the OCF specification. We marked each requirement as met, unmet or not applicable where we felt the requirement was not applicable to a device centric specification. This mapping is published on the OCF website, and I think it is a testament to both the robustness of the OCF protocol and the attention to detail of the IASME scheme.
Can you tell me more about the importance of secure interoperability of IoT devices for consumers, businesses and industries, and how this can be achieved?
As a consumer, there is nothing more frustrating to me when I am purchasing a device and need to do extensive research to see if the device will work with my other devices. On top of that, it feels like, for 50 IoT devices, there are 50 different ways of adding them to your home network, 50 different apps you need to install to control them. Will they work with each of the several different types of smart speakers that I have in my house? Secure interoperability is a boon for everyone involved. Consumers would have a less frustrating experience with their devices while manufacturers can develop to a single standard and not have to expend the extra cost and labour to develop and test against several different ecosystems. Then everyone, including businesses and consumers, would know that the devices they purchase will have a highly tested baseline of security.OCF does all of these things and with the open-source code for devices and the cloud implementation it is easy for anyone to get up to speed.
The UK is planning to bring in legislation around the security of consumer IoT devices. I understand other countries have legislation that is already in place, with some security laws very comprehensive. How many of your members are motivated by becoming compliant with existing or upcoming laws in their countries?
I can’t imagine that any manufacturer of IoT devices is turning a blind eye to current and up-and-coming IoT legislation. The expectation for some time has been that devices will need to conform to some security baselines. The challenge, I think for manufacturers will be navigating laws that vary by state, country and region.
Is there legislation around IoT security in place in the US?
There are several IoT-centric laws that are in place in states with more on the way. California was the first with SB-327 which is a broadly scoped law that dictates that security be appropriate to the function of the device including the information that the device collects and transmits. Oregon has a similar law stating that devices must have “reasonable security features”. Several other states have considered IoT security bill, but to my knowledge none of them have been enacted.Federally, the big news is the Internet of Things Cybersecurity Improvement Act of 2020. This law is targeted at purchases made by the federal government; however, I expect consumer ecosystems to follow similar requirements. The National Institute for Standards and Technology (NIST) is required to develop a set of minimum-security requirements, this is currently out in draft form in the document NISTIR 8259D.
What else motivates manufacturers to put security in place in their products?
In listening to companies that manufacture products, the biggest factor for them in building security into their products is cost. The good news here is that we are starting to see chips show up on the marketplace that support verified boot of firmware, trusted execution environments, and hardware cryptographic acceleration that are more and more cost effective. It is a good bet that as demand increases for these features, costs will come down even more.
Does the OCF produce resources or support material to help manufacturers build security into the design of their products?
Yes, OCF has a developer program that includes examples, documentation, videos, tools, and a developer kit to get started.