Building a Security Framework for the Internet of Things
Author:Rex Johnson and Suresh Mandava, CSC
Major initiatives are underway now to connect infrastructure (telecommunication systems, electrical grids), machines (industrial control systems, supply chains) and “things” (home security systems, appliances, cars, wearables) to one another and to the Internet. Indeed, this network of physical objects that collect and exchange data adds new capabilities and ease to performing jobs and gaining overall efficiencies.
But while cyber-to-physical and machine-to-machine systems do offer benefits, they can also bring the risk of unauthorized or malicious access to data and infrastructure — risks that could even, at the extreme, endanger human life. This report, Building a Secure IoT Framework, explores the risks related to IoT and the framework for securing systems and data.
Open to attack
On July 21, 2015, Wired published an article about how a pair of hackers took control of a 2014 automobile using a laptop and mobile phone. The hackers, who were actually researchers, developed a software program that allowed them to take over the steering, transmission, brakes and other functions of the vehicle, demonstrating their ability to hack into vehicles with an Internet-connected entertainment feature.
Though this example received much public attention, the art of car hacking is nothing new. It has been a discussion point at Black Hat information security conferences since 2010. And although some may argue that we don’t yet live in a world where hackers can crash our cars, engineers widely agree we're heading in that direction — if we don’t take necessary security measures.
Beyond the connected car, the growth in the number of connected devices has been truly extraordinary. With fewer than 5 billion connected devices worldwide today, the number could quadruple in the next five years to 20.8 billion by 2020. The field could grow to support total services spending of $3 trillion by 2020.
Already, people interact with IoT to heat and cool their homes remotely, count their steps, use voice commands to play their favorite song and do even more mundane tasks. The presence of the IoT in everyday life will only grow, as will its application in the workplace and specific industries.
While IoT products continue to flood the markets, security measures remain behind the curve. A recent Forrester Report indicated that while most hardware and networking IoT technologies are in the “growth” or “equilibrium” phase, security standards for IoT are in the “creation” phase, with no established products. The report estimates that standards will be at least three years away.
News articles have showcased the results of this lag, from vulnerabilities in a teddy bear that chats with children to Barbie dolls that can be hacked to act like a surveillance device. IoT systems — even in children’s toys — are complex, which makes securing them a challenge. Developers need to consider all layers — from the device to the gateway, network to application — and appropriately address the end-to-end system threat matrix, which changes industry to industry and in each use case.
While much has been made about malicious IoT vulnerabilities (those initiated by hackers), risks are not limited to this arena. Edge failures caused by loss of power, signal or unintentional damage, such as a forklift ramming an RFID reader, can take down critical operations. And a failure in the human response could be problematic.
Developing security measures
By mitigating security concerns — what U.S. Federal Trade Commission chairwoman Edith Ramirez has named one of the “key challenges” for IoT — enterprises may encourage consumers to take full advantage of what these technologies offer. Some measures are starting to be developed.
In 2012, the National Highway Traffic Safety Administration (NHTSA) modified its own research to identify risks in vehicle electronics and cybersecurity. The organization identified three main areas: electronics reliability, automotive cybersecurity and automated vehicles.
NHTSA’s Vehicle Research and Test Center (VRTC) has been performing tests on the three interfaces with the hope of building a cybersecurity knowledge base to support the development of industrial standards, guidelines and best practices. The organization also plans to research the acceptable minimum technical requirements and help establish cybersecurity policies and regulations.
On July 21, 2015, Senators Edward Markey and Richard Blumenthal introduced a bill known as the Security and Privacy in Your Car Act (SPY Car Act). This legislation, the first of its kind, would direct the NHTSA and the Federal Trade Commission (FTC) to establish federal standards for the connected car.
The bill includes a cybersecurity section that covers requirements for hacking prevention. All entry points to the electronic system must be equipped with reasonable measures to protect them from attacks, the bill says. This includes prevention of unauthorized access, as well as capabilities for detecting, reporting and stopping unauthorized attempts to intercept driving data or control the vehicle.
The SPY Car Act makes sure drivers who don’t want their data collected can still enjoy the convenience of the connected technology with access to navigation and other features. The bill also limits the manufacturer’s ability to use collected data for marketing purposes without the express consent of the owner or lessee.
It’s clear that security needs to be a key factor in every phase of the development cycle for IoT technology, whether it supports cars, home security systems, smart grids or even toys. When properly considered, security can even propel innovation.
The secure development life cycle
The secure development life cycle (SDL) allows the considerations of safety and security to work hand-in-hand with the development and release of a connect product. It should be used in the design, development and implementation of any IoT technology.
Not a new concept, the SDL has been discussed in the security arena for the past seven years or more. And while organizations such as Microsoft have developed their own versions, the process is available to the public and covers everything from presecurity training to the requirements and design phases, implementation, verification and release. A final phase looks back at the SDL process and considers adjustments.
A simple cycle for SDL would work like this
- Security Training and Certification. The first step is to ensure that those working on the security of a system are qualified. There are a number of certifications that security professionals can attain. Most of these require ongoing training and an annual renewal of certifications. This should be an ongoing phase that ensures developers are up to current standards.
- Requirements. As with all development, there are requirements. Security requirements consider what the risks would be to the connected car or another IoT technology and take into consideration previous case studies. The requirements phase develops the preventive measures and controls to mitigate the risk of breach, denial of service (DoS), data loss or remote control of the technology by malicious users. Additionally, security should include physical security requirements to address risks with design.
- Design. Working alongside the development team, the security team would build the requirements from the previous phase into the design of the system.
- Implementation. The security measures are implemented as the technology is manufactured.
- Verification. Verification is the testing phase to ensure that risks are appropriately mitigated. Security professionals would perform a number of tests to determine ethical hacking, penetration testing, testing for DoS, data leakage, physical risks, as well as attempts to control or compromise the system. While in this phase, the development team can look to mitigate such vulnerabilities prior to release.
Every electronic feature would be measured against three levels:
a. Failure Mode and Effects Analysis (or FMEA Engineering Analysis)
b. Hazard Assessment using ISO 26262 standard
c. Threat Analysis and Risk Assessments (TARA)
- Release. As the technology is released, this phase ensures that consumers and other users have a means for reporting security issues that occur postdeployment, including the ability to send secure feedback via the technology back to the developer.
- Security Servicing and Response Execution. Over time, new vulnerabilities will likely be discovered. Developers should be prepared to respond to these threats and allow for patching or possible recall of these systems. The patches need to be securely installed, whether this is over the air (OTA) or by returning the product for repairs.
Preparing for new cybermandates
One argument against SDL is the cost and risk of making a system more secure than is necessary. However, with breaches becoming more common, consumers expect higher levels of security in exchange for convenience. Additionally, the cost of implementing secure fixes post-release has proven to be more expensive than including them in the product development cycle.
For example, the practice of sending out USB drives to patch software in connected vehicles has been criticized by security professionals, who have long warned computer users against plugging in USB sticks sent by mail. The USB mailer approach potentially paves the way for a future attacker to create spoof mailers and trick users into installing malware on their cars or trucks.
Often, the costs to remediate issues prove to be more expensive than including the solution in the product or system development. High costs, coupled with a data leak or negative news about potential vulnerabilities, can damage an organization’s reputation, as well as its bottom line.
Just as groups such as the U.S. National Institute of Standards and Technology (NIST) have set cybersecurity requirements for SCADA systems, critical infrastructure and other technologies, expect requirements for IoT to follow. Recent action by the U.S. President may push manufacturers toward a solution that includes implementing security measures through product development and release. In February 2016, President Obama announced a $19 billion cybersecurity action plan, recognizing the threats posed by a rapidly evolving connected world. As U.S. Director of National Intelligence James Clapper has warned, “new systems that rely on artificial intelligence can open doors to hackers.”
By implementing an SDL through the entire development cycle, organizations can start to mitigate risks. Standards are available through NHTSA, NIST and other sources. As governments look to impose these standards, manufacturers should consider investing proactively in security measures. In doing so, they can increase their opportunity to successfully and safely extend IoT systems across products and operations.