13 Implementation Considerations

ENPM 808s
Information Systems Survivability:
13. Implementation Considerations
- - - - - - - - - - - - - - - - - - -
Implementing and configuring for survivability: putting it all together into a coherent approach to survivable systems and networks

Recommended research directions NOTE: Final projects are due by the final class period.

A Few Remarks to Reflect On
- - - - - - - - - - - - - - - - - - -
There are no easy answers. It is a long way from theory to practice, from concept to workable implementations, from research to development. What is commercially available is mostly sorely lacking with respect to what is needed. Today's operating systems, Internet protocols, and networking are inadequate in the context of survivability requirements.

Building robust systems out of less robust components must become more viable. However, we must remember that completely flaky infrastructures may allow compromises. Thus, some trustworthy components are essential.

Generalized dependence works well for fault tolerance and pure reliability applications such as mean-time to failure. For security, wrappers, firewalls, TCBs, k/n crypto, and Byzantine security algorithms are still subject to compromises (from within and from below).

We need fully fledged prototypes that address the realistic requirements and that use the best research results. The trustworthy servers of the thin-client architecture are an important example.

We must have practical systems for real-time analysis and response. (EMERALD is an outstanding example!)

Survivability has widespread threats. We need education and awareness of government folks, developers, professors, students, media moguls, and citizens...

Simplicity is an evasive goal, especially when we are dealing with inherently complex systems that must work within inherently complex environments involving fallible or culpable people. Vitualizing simplicity makes good sense, using abstraction, encapsulation, layering, perhaps object orientation, and generally good software engineering practice.

People will always be a weak link. Good technology is vital, but do not overendow it.

Needs for the Future
- - - - - - - - - - - - - - - - - - -
Generic requirements encompassing all of the potentially critical subrequirements for survivability, which can then be instantiated for specific applications

Much more robust network and distributed system protocols. [In the lecture, I noted that there is a Y2K-like problem with IPSEC: IP version 16!!! One answer is to wrap around with a windowed approach, assuming the old versions are no longer around, although that might get into lawsuits with the guy who is suing the Y2K folks who used that technique.]

Libraries of demonstrably sound robust procedures for generalized dependence

Open-system and nonproprietary open-source architectural components compatible with survivability requirements, with interoperability, ready composability, trustworthy components as needed, trustworthy distribution, ... Possible impetus on commercial vendors?

Sound cryptographic infrastructures for authentication, integrity, confidentiality

Still much research and prototype development to be done.

There are huge educational problems, to which this course may be just one step.

Important Research Directions
- - - - - - - - - - - - - - - - - - -
Generic requirements
Robust protocols
Detailed open-system architectures and support for robust mobile code, predictable composability, trustworthy critical components
Establish reusable constructs for generalized dependence
Interoperable systems for real-time monitoring of all survivability-relevant attributes
Predictably controllable and constrained dynamic reconfiguration and dynamic system adaptability

Fundamental Lessons of History
- - - - - - - - - - - - - - - - - - -
Requirements must be sufficiently correct, consistent, complete, and precisely specified, from the outset, encompassing functional and operational requirements.

Proactive architectures are vital from the outset, as are software engineering, control and discipline in the development process.

Plans for testing, validation, verification, and acceptance should be thought out carefully in advance as well.

Requirements, design, implementation, and operational practice must anticipate iteration, evolution, and maintenance.

Specific Lessons
(Motherhood is easy, unless you are a mother.)
- - - - - - - - - - - - - - - - - - -
Identify your long-range goals up front.

Fred Brooks' "Build one to throw one away" is usually impractical. Planning for evolution is vital, but difficult.

Good software engineering practice and good system architectures are invaluable.

Short-term and local optimization are very risky.

A Few More Comments
- - - - - - - - - - - - - - - - - - -
This is not a case of Just Add Money and Stir. There is a long way to go.

Serious understanding is needed of the depths of the problems and the urgent needs for solutions.

Although progress can be made in the short term, commitment to long-term advances is essential.

Despite all of this, there will still be residual risks. [DISCUSSION]