Securing the Internet of Things. Part 2 - Securing the ‘Things’ of the IoT
JonChard 270002099N Visits (9759)
Bruce Powel Douglass, Ph.D.
Chief Evangelist, IBM Analytics
In my last post I discussed the overall challenges of securing the Internet of Things. In this post I focus primarily on the ‘Things’ of the Internet of Things. Certainly securing the cloud end is important as well, but there has always been far more emphasis on cloud security than on device security. I think there are a number of essential aspects of a development environment for designing secure systems:
First, the product team needs to have a process workflow that supports and encourages security throughout the development cycle. This means that there will be some initial security analysis leading to security-relevant requirements, on-going security assessment of architecture and design decisions, explicit evaluation of designs and implementations against common weakness such as those found in the CWE, explicit security testing, and security monitoring and assessment of operationally deployed systems. This needs to be the normal development workflow for any system that has security concerns – which these days, is pretty much everything.
Many of you recognize my name as being associated with modeling, as one of the contributors to both the UML and SysML standards. Unsurprisingly, I’m a big fan of explicitly modeling of threats, vulnerabilities, and countermeasures. I even developed a UML profile for security threat modeling, something I talk about in my book Real-Time UML Workshop for Embedded Systems. Now I’m a member of a task force in the Object Management Group submitting a proposal for a standard profile for threat modeling. Figure 1 shows a typical example of a security analysis diagram from my security profile regarding the protection of patient data (the asset at the bottom of the diagram), expressed vulnerabilities, attacks against those vulnerabilities, and design countermeasures. Such modeling allows us to reason about the combinations of events and conditions that could lead to security violations.
Figure 1: Threat modeling in the UML Security Analysis Profile
One of the outcomes of security analysis and threat modeling is a set of requirements around the system security. For example, a systems specification might have requirements such as
Not only do security requirements result in explicit design mechanisms to enhance security, they encourage security awareness, something absent in far too many systems projects today.
Secure Design Patterns
Design patterns are old hat these days. A design pattern is nothing more (or less) than a generalized solution to a commonly occurring problem. People have developed design constructs to address many different security concerns. It just makes sense to avail yourself of these solutions and see how they might work in your specific system.
A caution: design patterns are really all about system optimization. As such, every pattern has both benefits (primarily the things you want the pattern to provide) and costs (complexity, time, assumptions, etc.). You should perform a trade study of different security patterns to find the patterns that provides the security you need at a cost you’re willing to pay.
Most testing focuses, appropriately, on functionality. However, various quality of service (QoS) concerns such as performance, reliability, and security should also be well represented in tests. One of the advantages of security requirements are they provide an explicit element on which to hang test cases, so missing security testing can be identified.
Beyond the explicit requirement testing, fuzz testing is often employed as well. Fuzz testing means testing random, out-of-range, and unexpected inputs to a system. In addition, a tester familiar with security testing can apply tests inspired by CWE even if they go beyond strict requirements-based testing.
One of the disadvantages of the IoT is the security vulnerability of connected systems. One advantage is that because the systems are connected, they can be monitored for security violations automatically and report to a central server. This allows security holes to be identified in fielded systems. Even better, many such deployed devices can be automatically or semi-automatically patched with security updates once security concerns are identified.
Continuous Security Assessment
Finally, it is important to understand that security is not something you do once, in one development activity, and then you’re done. Secure systems only come about through committed consistent application of security thinking, methods, and practices.
The IBM Internet of Things Continuous Engineering Solution is designed to help you create smart connected devices for the Internet of Things. Find out more at: ibm.