Research is needed to address the relatively immediate security needs of legacy systems, as these systems will be with us for a long time to come.
It is worthwhile to expend some significant effort to create new systems and networks that are explicitly designed to be secure, at least for critical systems whose compromise would have high consequences. Research on clean-slate designs for secure and attack-resilient architectures will show what can be achieved when these efforts are relieved of the need to fit into an insecure existing framework, and it may be that new design approaches will make it possible to achieve performance, cost, and security goals simultaneously.
Research effort should be explicitly focused on easing the transition path for users of today’s information technology applications to migrate to secure-by-design systems in the future—a path that is likely to take years or decades to accomplish even after such “from-the-start secure” systems are designed and initially deployed. (Box 8.1 presents further discussion of this point.)
One key issue in the security of legacy systems is patch management. Tinkering with existing legacy systems—for whatever reason—can result in severe operational problems that take a great deal of time and effort to resolve, but fixing security problems almost always requires tinkering. Therefore, operational managers are often faced with choosing between the risk of installing a fix to some vulnerability (that is, the installation of the patch may disrupt operations or even introduce a new vulnerability) and the risk of not installing it (that is, attackers might be able to exploit the vulnerability). Further, the installation of a patch generally necessitates a set of new tests to ensure both that the vulnerability has been repaired and that critical operational functionality has not been lost. If it has been lost, a new cycle of patch-and-test is needed. These cycles are both costly and inherently time-consuming, and consequently many systems managers avoid them if at all possible. Such dilemmas are exacerbated by the fact that it is often the very release of a fix that prompts an attack.1
One area of research thus suggested is the development of a methodology that will help operational managers decide how to resolve this dilemma.
This paradoxical situation results from the fact that the release of a fix is publicized so that it can be disseminated as widely as possible. The publicity about the fix can alert would-be attackers to the existence of the vulnerability in the first place, and the fix itself can usually be “disassembled” in order to reveal the nature of the original vulnerability. Because some installations will not install the fix, would-be attackers gain opportunities that would not otherwise become available.