Cyberterror, Embedded Systems, and the Second Shoe -

Cyberterror, Embedded Systems, and the Second Shoe

In response to a post 9/11 column I wrote about security on our heavily traveled “information superhighway,” some of you said you were not surprised that the al Qaeda had attacked the Twin Towers for the second time. What surprised you was that the attackers had not gone for our net-centric computing infrastructure.

The phrase I used then to describe your state of mind was “waiting for the second shoe to drop.” In other words, you, as I did, expected the terrorists, after their attack on the physical infrastructure would go for a target in our information superstructure that would really hurt us economically and bring us to our knees.

When that did not happen, concerns about cyber-terror faded into the background, buried amid stories on how to improve electronic security at airports and public spaces, how to use electronics to sniff out biological agents and how to build machines that would find bombs and weapons hidden in suitcases or in the shoes of suspicious airline passengers.

However, in the last few weeks, news stories in the Washington Post and National Public Radio and a few other news outlets indicate that the al Qaeda indeed had a sophisticated effort under way to penetrate our cyber-defenses. As far as I know, the targets of this effort, and the vehicles by which the terrorists expected to attack, are totally different from what was expected.

Rather than attack our information superstructure itself, the second shoe that the al Qaeda was going to drop was to use it as the conduit by which to penetrate any of the thousands of water facilities; gas, oil and water distribution systems; electric power distribution systems, conventional and nuclear power plants or municipal waste processing systems.

And the specific agents of that destruction were to be any of the literally millions of embedded microcontrollers that populate such facilities. Given the terrorists' penchant for wanting to impose physical damage and loss of life, we should not have been that surprised.

According to a report by Barton Gellman in the Washington Post, U.S. government analysts believe that if al Qaeda had been able to penetrate one of these systems, and disable or take control they could have caused much damage and death, in the billions of dollars and many more casualties than Sept. 11. At the very least, even just one such an attack, if only partially successful and resulted in no damage, would have had a profound impact of the public's sense of security.

The initial focii of their efforts, according to Defense analysts, are the distributed control systems (DCS) and supervisory control and data acquisition (SCADA) systems. Investigators in California found that unknown browsers were exploring the systems that managed utilities in the San Francisco Bay area. And investigations by the FBI for the Department of Defense found multiple instances of attempted penetration or passive monitoring of critical sites that were routed through telecom and network switches in Pakistan, Indonesia and Saudi Arabia.

Most embedded developers I have talked to have not placed security issues very high on their agendas. The excuse I hear most often is that such penetrations of embedded controllers and processor is not likely. Unlike Windows, which is on the majority of desktops around the world, making it an easy target, most embedded controllers use operating systems and software that are not commonly available or accessible.

But those less well known architectures and operating systems are precisely the ones that al Qaeda seems to be interested in. Operatives spend much time on sites that offer software and programming information for the digital control systems hardware and software used in a variety of power, water, transport, and communications grids. The fact that they were not as easily accessible, or as understandable, as a Windows platform does not seem to have bothered them.

Besides trying to get information about the embedded control devices, systems, and software at various types of physical facilities, it is also clear from reports by various governmental agencies that the al Qaeda operatives are working to improve their knowledge and sophistication with relation to the security mechanisms that currently protect our information superhighway. According to Gellman, computers linked to al Qaeda appear to have had access to cracking tools used to search out networked computers scan for security flaws and exploit them to gain entry. And the results of investigations by the FBI indicate the group is also interested in hiring hackers to speed their access to the appropriate capabilities, either through education or through hacking “work for hire.” Despite the perceptions in the embedded marketplace and the small footprint iappliance segment that these devices were not likely targets for serious cyber warfare, some RTOS and embedded tool vendors have begun to take note of the possibility of such intrusions.

Some companies, such as Wind River, support a variety of a variety of security tools and add-ons. Others such as Lynuxworks, Green Hills Software, the Microware division of Radisys Corp., and Wind River Systems Inc., are promoting to developers the advantages of the memory segmentation and memory protection of their RTOSes, not necessarily as a way to prevent security intrusions, but as a way to isolate the problems they cause to just one application or thread.

Because such mechanisms only work in a relatively memory rich 32-bit embedded and small footprint iappliance environment, a number of vendors are looking for ways to make their small footprint RTOSes less susceptible.

Green Hills has a minimalist version of its Integrity RTOS, for example, in which features that are used to control the amount of time an application or thread remains in memory and the amount of space it requires are used to guard against code viruses and worms. These features take advantage of the fact that viruses often use such mechanisms to wreak their havoc. Alternatively, Microware's RTOS allows users to make use of a versioning feature in which code modules incorporate special ID codes that allow the right version of the RTOS to match with the right version of the driver or code module. A virus or worm, without such an identifying header, can be recognized as such relatively quickly and expunged.

I can't help thinking, though, that a hacker or terrorist dedicated to subverting the systems in which such embedded processors and controllers are used could find less obvious methods of causing damage. For example, in many embedded operations, especially in control, determinism and real time interrupt response are critical to correct operation. How much code and sophistication would it take, for example, to cause slight delays in a microcontroller's deterministic response characteristics, or to alter slightly, the priority scheduling mechanism in such devices, or to slightly stress the system so that switching between tasks or threads is slowed down?

While RTOSes have found wide use outside their traditional domain in embedded control and computing applications, the fact of the open environment of net-centric computing, in which there is no longer any such thing as an isolated application, is changing things fundamentally. The new realities of building a net-centric computing infrastructure in a world of hackers and cyber-terrorists may require fundamental changes in the way such operating systems will be built, all the way down to the kernel level.

I also have qualms about many of the security add-ons that embedded tool vendors are supplying with their RTOSes and within their integrated development environments. Most seem to be modifications and adaptations of tools and procedures developed for the desktop computer. Even in the small footprint, mostly 32-bit processor based non-embedded iappliances in which RTOSes and embedded tools are used, such tools and add-ons stretch the capacity of memory and CPU constrained devices.

Aside from memory and processor footprint issues, the issues facing developers in this environment are perhaps even more complex than in larger systems. What price do they want to pay for security? What are the greatest security concerns for device connectivity? What are the performance issues associated with adding security to a networked device? What are the costs associated with security risks vs. an application's bill of materials?

Designing the best security solution in such an environment would seem to involve looking at issues such authentication, privacy and integrity in a much different way than on the desktop.

What do you think? Do you have solutions or ideas about providing enhanced security in embedded and small footprint iappliances? Do you think we have to rethink our underlying assumptions about security in a network computing environment? And what are the implications to how we do things will such a mindset change entail?

Bernard Cole is the managing editor for embedded design and net-centric computing at EE Times. He welcomes contact. You can reach him at or 928-525-9087.

Reader Feedback

The only thing to fear is fear itself.

The biggest terrorists are our own government which continue to scare us with 'suspected' packages and 'possible' threats, nearly all being just that. Was Pearl Harbour that long ago that we forget that we live in the very country that let the attack happen, and all for a greater purpose, to get into a war where more of our men could die.

It is the same this time around.

George Hill

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.