Security in Systems
Four Key Steps to Address Security Threats in Embedded Systems
To address security, we must treat everything as connected—in systems of systems. This will require both cultural and technical rethinking of how systems are not only maintained and secured, but also so that they are developed and designed to make this possible.
DOMINIC TAVASSOLI, IBM RATIONAL
Page 1 of 1
A piece of pop trivia: In the Rebooted series, what was so special about the Battlestar Galactica spaceship that it survived the initial Cylon attack and went on to lead the survivor fleet? Ironically, it was the outdated, unnetworked computer systems. It wasn’t vulnerable to the attack via hacking of embedded sensor networks and control systems. Thus, humanity is nearly wiped out in the show via embedded security flaws.
The security question is definitely one that our industries need to consider. For example, vulnerabilities in medical devices were brought to light when a white hat hacker demonstrated how insulin pumps could be tampered with at the Black Hat security conference in Las Vegas this past summer. Even after thirty years of device telemetry use, there are no known issues of malicious tampering. However, the possibility is there, at our door.
As embedded systems become increasingly interconnected in our smarter planet, each device, vehicle, piece of equipment becomes interconnected and is an endpoint in its own right (Figure 1). This system of systems presents myriad vulnerabilities where one failure could have an unforeseen domino effect throughout the chain, just as a single power line issue cascaded into the San Diego blackout in September of this year.
The networked health care environment is an example of a large system that is built up of many component systems, which are themselves made up of connected nodes and devices.
The answer isn’t to outlaw the interconnection of our devices. We are relying on a network of things to make our game-changing ideas possible for the future: the Smart Grid, intelligent traffic networks, smart payments and healthcare, to name a few. Machine-to-machine interaction is opening up new opportunities for innovation, new streams of revenue for embedded manufacturers, and the opportunity to collect usage data to improve the user experience (read “loyalty”) and product quality. Meanwhile, new threats are appearing, along with a variety of hackers from black hat hackers (malicious types), hacktivists (promoting a political goal), script kiddies (juvenile vandalism) and cyberterrorists to simple, disgruntled employees who happen to have the right access. This makes the menace to embedded security all the more complicated.
We are starting to see security features called out in recent software and hardware component releases. These are steps in the right direction, although they only address a few pieces of the complete system of systems, which is continually evolving. Each industry has different needs and risks, with very few experts who understand the full picture. In his statement to the U.S. Senate on cybersecurity in March 2009, Dr. Joseph Weiss declared that he “believe[d] there are less than 100 people worldwide who truly know and understand control-system cybersecurity.” This needs to change within each organization if this major business risk is to be addressed. Let’s take a look at steps to take to address this challenge:
Step One: Build a Culture of Design for Security
The first step for organizations is to modernize the way they develop software, hardware and systems. High levels of security require increasingly sophisticated functionality in embedded devices, to monitor access (e.g., check who is operating the system), integrity (check that the software performing energy distribution on the grid is not malicious), and authenticity (confirm which nuclear reactor the system is talking is to).
Organizations also need to develop and enforce security practices, as there are no all-encompassing standards or readily available best practice libraries today. This involves investing in proper requirements management and traceability to ensure all security constraints are taken into account, as well as the development of “secure” design patterns across chips, hardware and software. Application Lifecycle Management and Design Management solutions will help engage all stakeholders, including testing and operations, in a discussion powered by social media. The objective is to encourage the discussion around the design for security, but also to record this in a knowledge base. All projects should have a continual “post-mortem” discussion to identify and record possible security flaws, and communicate to the team, ideally as part of a component reuse initiative.
Step Two: Deploy a Service Management Solution
Designing more secure endpoints and devices is not sufficient. Organizations need to manage them and the existing systems that they build upon. Remotely exploitable vulnerabilities in embedded devices are often the result of using outdated protocols, libraries or insufficiently tested custom code. The difficulty in applying patches (factory recalls, firmware flashing, necessary vendor intervention or simply lack of information) means that these systems are rarely updated, even when vulnerabilities are detected. The situation hasn’t changed much since 1999 when businesses were looking at their elevators, factories or vehicles and wondering if they would survive Y2K, not knowing what to look for, where, or how to fix it.
Integrated Service Management should be rolled out to ensure real-time understanding of where assets are, what versions of hardware and software are involved, and to enable configuration management and patch management of the devices. Likewise, network-based security technologies, such as vulnerability assessments, Web application scanning and intrusion prevention, will allow organizations to assess and address threats to the endpoints.
Step Three: Bridge the Chasm between Development and Operations
The need for rapid threat responses and a continually evolving landscape are driving development and operations closer together (Figure 2). This is already becoming a reality in IT where DevOps is integrating the full lifecycle. This is arguably more easily done when there is only one owner of the ecosystem, e.g., the bank is responsible for development of the software but also the deployment and operations. Teams are also only dealing mainly with software deployments.
Gone are the days when developers could sign off on their creations and be content supplying patches and upgrades. Today, the development process needs to be closely connected with operations by anticipating the maintenance needs in the development process and being able to seamlessly service the deployed systems.
Agile development initiatives help teams produce prioritized, quality solutions that are more quickly aligned with business needs, and therefore suitable for producing patches and updates. Delivering updated, fixed software is useless if it can’t be rolled out at the same level of speed and confidence. Not only does the lifecycle handoff from development to operations need to be automated, but the end device or system needs to be designed with this connection in mind. Embedded design teams need to take the maintenance and upgrade requirements into account as a top priority, ensuring that this new functionality doesn’t add security flaws of its own (e.g. hacking of the firmware update door).
Conversely, as security flaws are suspected, development teams can struggle to reproduce the problem. The stronger linkage between operations and development should also translate into a recording and transfer of operational parameters, as well as the implementation of virtual testing environments that make it possible to simulate the full system of systems in ideal conditions. Today, advances in cloud technology are a key enabler in setting up the right test environments faster and cheaper.
The good news is that today’s modern development platforms enable new levels of discussion and interaction between globally distributed teams from multiple domains. The social media functionality in software and systems development platforms, such as IBM’s Jazz, allow development, security experts and in-service maintenance teams to participate in discussions around design and functionality. This increased level of interaction is a must for any organization wanting to address security and deployment issues early, mitigating the financial, customer retention and brand image risks of security flaws.
Step Four: Lead the Way for Industry-Specific Security Standards
There is an enormous market opportunity for embedded and real-time systems companies. We are seeing everyday products become “smart products,” from Wi-Fi body scales to networked sensors in cars and roads, to the ubiquitous, multifunction smartphone. Vendors will not only be able to profit from this game-changing opportunity to sell new types of products, but also retrofit existing installations if they actively contribute to growing confidence in this market. Customers will get skittish and organizations will prefer the more “traditional” options if there are no security standards that guarantee safe interoperability, data safeguarding, and protection from intrusion.
The most forward thinking representatives from each industry will benefit from setting aside their rivalries and collaborating to produce industry-specific security standards. For instance, in medical devices, where a bug or security flaw and subsequent litigation hurts the industry as a whole, all organizations benefit from an agreement on standards for embedded security that reassure end users and investors alike. This will also create the opportunity to share experiences, best practices, and improve the maturity of development and operations lifecycles across the board.
We are at a turning point. Software-driven innovation and leveraging embedded and real-time systems, are changing the world in which we live. We may have different hopes of profit, quality of life and becoming more environmentally friendly, but the fact is much hinges on our ability to secure our systems against new types of threats every day. By actively improving the way we develop and maintain our systems and their endpoints, and developing industry standards, we’ll help that future come true.
Corporate security officers will need the authority to ask the embarrassing questions and mandate additional development effort, even if it means a short-term increase in cost and time-to-market. Steps like these will help ensure that malicious hacking of medical devices will remain as potential CSI script twists, but also allow us to embrace the future.