The Internet of things is set to worm its way into many areas of our lives, but as our cars and domestic appliances become connected how can we be certain that they're secure? We've already seen issues with cars being hacked and do you really want to be installing security software on your fridge?
We spoke to Lev Lesokhin, Executive Vice President, Strategy and analytics, of software analysis and measurement specialist CAST to find out how developers of IoT products can keep them secure and retain consumer confidence.
BN: Many IoT devices are made by companies not traditionally involved in computing. Are they being caught out by lack of experience?
LL: Absolutely. It's a double whammy. Not only are these companies suddenly having to put together a software capability, where the market for software engineers is more and more demand-constrained, but they have to figure out how to manage software delivery. That's a long journey. Also, the traditional embedded software developers still haven’t caught up to the practices needed to develop internet-connected applications -- from a security, reliability and performance efficiency standpoint.
BN: Where in the product lifecycle does security need to be addressed?
LL: About 50 percent of security flaws are in the design and the architecture of an information system. Security needs to be addressed at the start of the design phase, making requirement tradeoffs as necessary. During code construction (i.e. development), security needs to be baked in that process all the way through. Security is then tested at the end of the development process. Security must be foundational -- it cannot be regarded as a mere 'bolt on'.
BN: Security is an ongoing process, how can companies deal with this and does it risk early obsolescence of devices?
LL: It may be counterintuitive, but it's actually the opposite. CAST Research Labs, in their latest research report (CRASH), found that security is highly correlated to software robustness. In fact, it may take a little bit more time upfront to build robust software, and it takes more management oversight, paying attention to their analytics about structural quality. But, as a result you have more secure and robust software -- which is actually more reliable and easier to maintain. So it will actually have a longer shelf life.
BN: Isn’t the answer to keep critical infrastructure devices isolated from the internet?
LL: You can have a solution to operate on secure subnets, but these will by definition be restricted to the other users of the same subnet. That may work for some business models, but for anyone that wants to access the worldwide market that’s on the internet, this won’t be a solution. As a result, embedded software components have to interact with internet-facing components in a safe way. This makes it much more difficult, because now the developers have to understand how these components will interact to ensure security, reliability and efficiency. This is a common problem in IT, but new in device software development.
BN: Won't IoT devices in the home be protected by being behind a firewalled router?
LL: The short answer is no. Some of the router security mechanisms can prevent novice hackers from entering home devices, but this is not failsafe. If we don't want an army of refrigerators creating DDoS attacks on critical infrastructure, we need to make sure the software onboard these devices is built with security in mind.
BN: Do device manufacturers need to be more open about why their devices are going online, what data they’re collecting and where it's being stored?
LL: Yes. The 'bad guys' will figure that out anyway. It's important for manufacturers to share this information with each other. It's also important for the consumer to know what information is being retained and/or broadcast by their devices. Manufacturers will also have to build in privacy options that can be invoked at the expense of additional functionality. This comes back to the first question about designing security in during the requirements phase of software development.
BN: What standards are in place which help businesses and developers meet specific goals for software quality?
LL: Software quality standards have existed for a long time. The traditional standard has been ISO 9126. Now that has been reworked into ISO 25010. The trouble with the ISO standards is they are vague and general. They specify the categories of 'what' should be measured, but they don’t specify 'how' to actually measure these criteria. There is also a standard being published by the Consortium for IT Software Quality (CISQ), the Object Management Group (OMG), and the Software Engineering Institute (SEI). It's aligned with ISO 25010, but gets into a great deal of detail as to 'how' these characteristics should be measured. Once this standard is rolled out, CISQ has made statements that they will provide a certification process in order to officially show that software follows the standard.
BN: In addition to measurement and analytics, what else needs to be a priority for manufacturers and developers?
LL: Keeping up with latest technologies, frameworks and coding practices. On the one hand, there are not enough experienced developers to go round, the flip side is that technical knowledge is among the quickest of all forms of learning to go stale. Managing this paradox is among the essentials of managing a development team. The best solution is to keep training all developers in the latest technology trends and practices. The best way of learning is on the job, and the best developers are the ones who feel they are being invested in.
Image credit: Gustavo Frazao / Shutterstock