1. Network Infrastructure Survivability

1.1 Topological Survivability

Topological Survivability has been widely researched in military fields for a long time, with the objective of enhancing network survivability against threat from physical attack. The state of the art is to balance topological structure by making all nodes and link resources be equal important to maintain the network topology integrity, thus enhance survivability.

However, the normal practice of civil network design focuses only on how to fulfill function requirements, without taking into consideration of the topology survivability. It is therefore urgently necessary to awaken civil network designers the importance of topology survivability, and to transfer practice of military networks to development of civil information systems in critical fields such as banking and transportation industries. A detail designing procedure that includes metrics measuring topology balance for civil purpose will need to be developed and circulated.

1.2 Network Operating System

Network operating system such as UNIX or Windows NT is one of COTS (Commercial-Off-The-Shelf) software. Reliance of information infrastructure on COTS software is going to be a potentially severe compromise to information survivability and even national security. Because nobody can guarantee that COTS software is secure, reliable and free from backdoors or logical bombs. Unfortunately, information survivability of many critical network systems and national security of countries are heavily relying on COTS software. Furthermore, if various American software vendors were to be involved in an aggressive global information warfare strategy of the United States, other countries would face extremely tough situations when protecting their national security.

Normally, there are three approaches to eliminate or mitigate the threat originating from COTS software:

1. Software testing techniques such as black box test, system-level test and software failure injection. But they cannot provide a satisfactory solution. For example, even though Microsoft has employed so many professional testing engineers, there are still many bugs in its software ever shipped. Without source codes, the effectiveness of software test will be worse.

2. A watch-dog utility is used to wrap/monitor the operating system. However, this approach is expensive and difficult. Lots of money and high level of expertise are needed to develop the utility, and the cost of deployment and maintenance is high too.

3. Source code review, integrated with white box test technique. Source codes of compilers need to be reviewed also! This approach can work, though it is not cheap either. Unfortunately, the source codes will not be easily available. So, technology just cannot make this approach successful. How to get source codes? It depends. It was reported that China has reviewed source codes of HP-UX for deploying them in critical systems [2].

Furthermore, how to handle with analogous threat from hardware platforms?

1.3 Routing Facility

When critical (e.g. military, banking and transportation) information infrastructure is based on the Internet, the routing facility becomes one of the most important links to information survivability. Some researchers even remark the routing facility as the heart of network operation. Recently, researchers have begun to address the importance of securing routing protocols. Some good works have been done to add reasonable authentication mechanisms to routing protocols [3]. Unfortunately, it is difficult to apply their research results to facilities-on-field immediately. The main and most urgent threats to routing facilities originate from two sources:

1. Internal attacks. Internal attacks against routing protocols are very destructive. For example, Routing Information Protocol (RIP) is the most widely used internal routing protocol, but it is a weak protocol. It is easy for internal attackers to cause severe attacks against RIP, such as denial of service, man-in-the-middle, redirecting of all network traffic and etc. Therefore, there is a great need for an anomaly detection system that can detect abnormal behaviors of routing facilities.

2. Implementation vulnerability. As a potential replacement of the widely used routed daemon, Gated [4] is a huge routing daemon that has implemented many protocols. It is prone to be a vulnerability pool like sendmail. Researchers have demonstrated several attacks against its OSPF (Open Shortest Path First) protocol implementation, such as table overflow attack, age field attack and sequence number attack.

1.4 The Threat from Insider Attacks

Many Intrusion Detection System (IDS) prototypes/products detect only external attacks. However, it is very important for information survivability to prevent from insider attacks. When insider misuse becomes insider attack, for example, when a mole with high level of technology expertise starts his attacks, the situation is bad. Sometimes, it is even impossible to track his traces! In military systems, this kind of insider attacks would be a severe compromise to information survivability and national security.

It is more difficult to detect internal attacks than external attacks, especially in the routing security case discussed above. An anomaly detection approach that models normal behaviors of systems will enhance capabilities of existed IDS software which detect intrusions just by matching known intrusion signatures.

2. Reactive Survivability

The necessity when upon attack is the capability of prompt responsiveness, which should include:

1. Defense. All weapons of information warfare have always been in precautionary status when they are deployed. Obviously, the best defense is to continuously attack enemies until destroying them.

2. Prompt logistic supply of weapons. When software codes become weapons such as rifles, tanks and missiles, supply of software becomes an important part of information logistics as a military discipline. What this paper highlights here is not supply of floppies, CD-ROMs or hard disks where existed software are stored, but rapid supply of software solutions to fulfill impromptu and sudden requirements of information battlefield.

Rapid supply of software solutions (including software patches) will enhance reactive survivability of information systems. The concurrent engineering approach to software development [5] is a methodology we have developed to enhance rapid response to software market requirements. It is also capable of satisfying the need of the battlefield of information warfare, where rapid prototype methods cannot work well enough.

Analogous to the integration of rapid prototyping with software development, the Concurrent Engineering philosophy from manufacturing automation is employed in our approach to parallel software development activities within one development process. Instead of detailing all of requirement analysis, followed by all of design, coding and testing, we emphasize to continue all follow-up development activities once enough (NOT ALL) information is available. Thus, a development process will be gradually divided into several activity streams, each of which covers all kinds of activities ranging from analysis (upstream) to test (downstream). The development team is accordingly divided into several multifunctional groups and one coordinating group. Each multifunctional group consists of designing, coding and testing engineers, and it is responsible for one activity stream. Members of the coordinating group include the project manager, leader of each multifunctional group and user representative(s). They are responsible for spawning development activity streams and orchestrating the project organization and management. All groups share dynamically one overall architecture view of the project and its progress. Thus, requirement analysis, designing, coding and testing activity are concurrently performed with cooperative teamwork. The final step of the procedure is system integration, integration testing and system-level testing.

Different from other methodologies coming from ivory towers, our concurrent engineering approach has been abstracted from hands-on development experience of many software projects that range from small to large scales. Though it might be criticized as 'lacking theoretical foundation' or something else, the concurrent engineering approach to software development is intuitively reasonable. Factually, the basic concepts of Concurrent Engineering do originate from human beings' commonsense. And as a matter of the fact, our approach extends the idea of Òdesign a little, coding a littleÓ advocated by G. Booch in his object-orientation methodology.

When working as co-founder of Beijing EasySoft Studio, a software company, the author with colleagues has ever successfully delivered several software solutions to customers in China ahead of schedule, following the software concurrent engineering approach. With its time-priority feature, the approach can play an effective role in satisfying battlefield requirements, too. It is always said that 'Market is another battlefield', isn't it?

Personal Backgrounds

This short position paper represents personal viewpoints of the author only.

Acknowledgements

Reference

1. Proceeding of the 1997 Information Survivability Workshop (ISW'97), IEEE Computer Society, 1997

2. China Computer World Weekly, 1998. ( Sorry, I forgot the date of publication)

3. Proceedings of the 1997 Symposium on Network and Distributed System Security, Internet Society , 1997

4. http://www.gated.org

5. Jianxin Yan, et al., The Concurrent Engineering Approach to Software Development, in Proceeding of the International Symposium on Future Software Technology(ISFST-96), Japan Software Engineer Association & The United Nations University/International Institute for Software Technology, 1996 ( A revised and more easily available version please refer to: Jianxin Yan, et al., A New Software Development Methodology in Concurrent Engineering, Proceeding of the International Conference on Manufacturing Automation 1997 (ICMA'97), The Hong Kong University & ASME, 1997)

Back to the Table of Contents
   [44]