Defending Network-Centric Systems Using Backdoors

Liviu Iftode, Arati Baliga, Aniruddha Bohra, Stephen Smaldone, Florin Sultan
2005 Infotech@Aerospace   unpublished
As computing systems are increasingly depending on networking, they are also becoming more vulnerable to networking malfunctioning or misuse. Human intervention is not a solution when computer system monitoring and repairing must be done fast and reliably regardless of scale, networking availability, or system impairing. Future network-centric systems must be built around a defensive architecture that allows computers to take care of themselves. In this paper, we argue that the solution to
more » ... ing self-defending computer architectures is a Backdoor, which can support automated observation and intervention on a computer system's memory without involving its operating system. Backdoors can therefore execute even when the functionality of the operating system of a critical system has been severely compromised and the system is no longer accessible through the primary network. Backdoors can be realized in hardware over a programmable network interface or in software over a virtual machine monitor. I. Motivation and Goals Despite decades of work on verification techniques, fault tolerance and security, computers and networks continue to remain vulnerable to failures and attacks. Increasing system complexity certainly does not help, even worse, it makes humanassisted monitoring, maintenance and intervention not only prohibitively costly but, more dramatically, unacceptably slow and sometimes ineffective. This problem is only going to become worse in the future, as the number of computing devices per person will increase while the vision of pervasive computing approaches its realization. In response to these trends, research focus has recently started to shift from eliminating failures towards designing systems that can withstand them and recover fast. 1 What makes computers ultimately and persistently vulnerable? We believe that the ultimate cause of computer vulnerability is the computer architecture itself. Placing trust in the operating system is not a guarantee for dependability as long as the operating system executes from the main memory, which can be accidentally or intentionally violated. Moreover, although operating systems have been extensively crafted to be safe, holes continue to exist and will always exist. A common source of failures, operating system extensibility, has been recently addressed by projects like Nooks. 2 More recent research has suggested to move the trust from software to hardware. 3 The problem with this approach is that it requires a modified processor architecture, not trivial to deploy across the huge computing infrastructure operational today. The question is whether we can improve computer and network dependability in the presence of failures and attacks by strengthening rather than replacing the existing architectural framework. A recent example of technological prowess, the remote repair of one of the Mars rover computers, holds, in our opinion, the answer. In the Mars rover case, a computer hung and then entered a pattern of periodic reboots because it ran out of flash memory due to an excessive, unanticipated, accumulation of logged data. What made repair possible was a provision that allowed remapping of the memory used during reboot from flash memory to RAM, creating an alternate execution path that bypassed the faulty computer resource. 4 This example suggests building systems capable of automated monitoring and intervention when their main functionality is compromised by faults or attacks. However, unlike the rover computer, the solution must be cost-effective and easy to deploy on the existing computing platforms, by using only conventional processor, system, and OS architectures. In this paper, we argue for augmenting existing computer systems and networks with trusted, multi-layered "last lines of defense." A last line of defense provides a last resort for access to and action on resources of a computer even when
doi:10.2514/6.2005-7101 fatcat:kt4s32gzwfcjrllv7o7nim54hu