Figure 1: Security Analysis Diagram
It’s a Brave New World
Time was when smart embedded devices needed little or no security. They were, for the vast majority, disconnected devices that performed simple dedicated functions. Now, however, it seems everything is connected over the web. Washing machines are connected over the web[1]. This allows unprecedented capabilities for both consumers to connect and manage their lives and for vendors to improve services, monitor usage patterns, deliver updates, and address emerging markets. It is not, however, without risk.
There is a device search engine called Shodan (Shodanhq.io) that continuously crawls the web looking for devices. It has found in excess of 500,000,000 connected devices and services. These include traffic lights, security cameras, control systems for a water park, hotel wine coolers, garage doors, evaporative coolers, pressurized water heaters, a few million printers, servers and other control devices to name just a few. Researchers have even found command and control systems for nuclear power plants with Shodan. The vast majority of these devices either require no credentials at all for access or use only the default password (such as “1234” or “admin”). Recently, cyber researchers have claimed that they can access flight controls via the supposedly separated networks on operating aircraft (although this is denied by the airlines at this time).
This is profoundly troubling. Most of these devices can be easily accessed and not a few of them can be accessed by ne’re-do-wells for nefarious purposes. Certainly, information can be read. This information can be used in surprisingly creative and criminal ways, such as the reading water meters to determine usage (to plan for burglary) or to change the usage amount for what amounts to a denial of (electrical) services to potential millions of consumers.
Even more troubling is when system behavior can be changed. Researchers looked a different threat vectors in an automobile, such as Bluetooth, radio data system, telematics, remote keyless entry, and tire pressure sensors. What they found was that every threat vector could be easily exploited and gain them access to the internal CAN bus; and once there, they could do pretty much anything they wanted, including disabling the brakes, opening the doors, countermanding steering, and turning on or off the engine. Scary stuff.
What is this “Security” thing?
Security (“freedom from intrusion, interference, and theft”) is one of the three pillars of system dependability, along with safety (“freedom from harm”) and reliability (“the availability of services”). Cybersecurity gets the most press but physical security can also be important for physical devices. Security is best achieved with a combination of approaches. Physical isolation or limitations of connections is best for security (but also decreases the depth of collaboration possible with the device). Explicitly requiring security features is a way to get “security by design” but this usually addresses only known or common threats. Having said that, Mitre’s Common Weakness Enumeration (CWE) site[2] is a great place to find the common software vulnerabilities and threat vectors. It’s very extensive and is a powerful resource for those wanting to secure their systems. Security can be enhanced through the application of security-relevant design patterns such as those found in Security Patterns in Practice: Designing Secure Architectures using Software Patterns[3], such as using cryptography, firewalls, and secure broker.
Another security approach is explicit and fuzz testing to ferret out vulnerabilities that have escaped into the design. A very common thing is source code analysis through tools such as IBM’s AppScan that parse the code looking for signs of vulnerable software.
Securing the T of the IoT
I focus primarily of 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:
Security Workflow
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.
Threat Modeling
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[4]. 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.
Security Requirements
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
The system shall require two independent-factor authentication to access the system configuration feature, patient data, or system delivery initiation.
No unencrypted patient data shall be transmitted.
If the user makes more than three unsuccessful log in attempts, the system shall lock up for a minimum of five minutes and notify the system administrator.
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.
Security Testing
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.
Incidence Response
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.
Comments