Intrusion Tolerance - Security's Next Big Thing?

An anonymous reader writes "DARPA's OASIS program consists of more than 20 research projects in intrusion-tolerant systems. The basic idea is to concede that systems will be penetrated by malware and hackers, but to keep operating anyway. Other projects take a wide variety of technical approaches to providing intrusion tolerance. MIT's Automatic Trust Management uses models of trust to choose from a variety of ways to achieve system goals; Duke/MCNC's SITAR (Scalable Intrusion Tolerant Architecture) adapts tricks from fault-tolerant systems and distributes decision-making; BBN-Illinois-Maryland-Boeing's ITUA employs unpredictable adaptation. Shutting down the military while waging war is not an option, but the idea of continuing to operating critical defense systems even after known penetration by hostile hackers or damaging worms will take some getting used to."

Comments

BIological Systems

[PktLoss]

I think it is great that something like this is being looked at. Every biological system on the planet works on the same principal, yes, the system will be attacked, keep functioniong, and attempt to regain controll.

I think an interesting option for powerfull machines would be to 'fall on the sword' if complete failure was immenent.

Just My .02 USD

[Sam Nitzberg]

In general, I don't like the idea of making a concession that malware will have to be operating in a given computing environment (as stated above), and to think otherwise would simply be incorrect. OK, Windows environments may be an obvious exception ;-)

I would prefer to consider that (at least from my own philosophical viewpoint), that you can construct systems with defined patterns of behavior, even when "malware" is introduced.

From one of the links referenced above :

Successive levels in the hierarchy are linked by refinement mappings that can be shown to preserve properties of interest. This project will apply this technology to intrusion tolerance properties.

This harkens back to enforcement mechanisms (Biba Integrity Model, No Read Up, No Write down policies, Models for descriptions of multi-level secure behavior, etc...). (Aside: Amoroso's book is an excellent reference)

What this alone tells me (I didn't read all the blurbs, articles, and briefings), is that we are discussing mappings (mathematical functions), and properties (which can be mathematically tested for by use of a logic or algebraic system).

At a glance, I am thinking of some of the issues in formal methods, proven-secure-O/S kernels, and other high-reliability software engineering methods for [secure] systems.

I like the idea that mathematical theorem provers can be applied to any system so defined.

Some basic issues do arise for practical application :

- Theorem - proving aspects mean very precise use of functional requirements and mathematical specification for system behaviors. (Also, special talent and additional manpower is necessary. Also, mis-applications of the tools used, or introduced human error in the test process can subvert the efforts)

- This should be applied (I believe) to systems-of-systems and their behaviors. The systems that your system interacts with would have to had similiarly rigorous analysis and design.

- There is (I believe) a trend in military computing towards commercial, and less custom, software development. Long-term, where will the actual development of such systems be funded (beyond the initial R&D stage).

- The use of analysis of pre and post conditions in the executing environment (to ensure that violations of the underlying security policy are not permitted) is not a new concept. While I am not saying that this is an intrinsically ecessary mechanism for these methods, most current system lack such an approach, and there may be fundamental computer security issues present by the nature of the software development environment. If these methods are used, it is still highly desirable to design systems with security in mind regarding their handling of all data, traffic, and O/S vulnerability issues.

I only took a brief look at the material, but these are some thoughts. I also think that the effort itself is very worthwhile, and potentially of value. Also, looking at Dr. Lulu's credentials, there is no naivite in his software background; the basic tenents can't just be shrugged off.

Sam Nitzberg
sam@iamsam.com
http://www.iamsam.com