Saturday, November 06, 2004
New discussion about CoreTalk and data regularity in context
On the Nature of science and
cultural Polemics à
Response note from Paul Prueitt
My response as
well will be brief – I need more time to digest this.
The effective interaction between dissimilar devices in the intrusion detection environment (information security) has been a Holy Grail for as long as I can remember. There have been many failed attempts at a “common language”. This approach, CoreTalk, appears to solve that easily. But, in our work that no longer is a problem in the same sense that it has been (refusal of product manufacturers to allow their devices to communicate with other devices from other manufacturers, specifically in a language that addresses intrusion detection). Our work takes us around that requirement.
<Note from founding committee. Peter, please explain why “our” work takes
us around this requirement. Discuss what you mean by “our work”. >
However, from my perspective (again, information security only), there are a number of additional benefits here. It is not enough to have a “common Language”. There has to be a way of communicating common meaning. In cyber security we translate common meaning into common behavior – of interacting devices, of course, but more importantly, on the level of understanding what really is happening in terms of threats, vulnerabilities and attacks.
To date, for example, vulnerabilities have been treated as objects. They aren’t. A vulnerability is a system state that can be changed by the application of a threat. The attempt to change the state is an attack. If the attack is successful, we have an event or an incident. There is no consistent way, today, to discuss this. Yet another language is not the answer. We need a completely new paradigm.
In order to describe the mechanics of a cyber attack, we need to step away from the confusing jumble of terminology and return to first principles. That is the core of our work. I see application of the CoreTalk concept here, but I really need to think about it a bit more.
The key benefit I see initially is that a theory of behavioral type is available in the Cubicon language at the time of applying a theory, i.e. at the design time rather than at execute time.
(On design time verses
execute time see next bead à [23])
Once the notion of cyber attack mechanics is well-defined and well-understood, there remains the practical requirement to apply it. That application is likely to be in the form of a suite of “universal countermeasures” that have no dependence upon the specifics of an attack in order to protect against it. The question then becomes, “How does one create a practical instantiation of a suite of universal countermeasures?”
(On the use of Stephanie Forrester
and Hoffstater’s work in theoretical immunity and computer immunology systems see
next bead à [23])
Peter R. Stephenson, CISSP, CISM, FICAF
Director of Information Assurance
CeRNS - The
Center for Regional and National Security,
Eastern
Michigan University
I am going to make a quick response to the interesting suggestion made by John DeAmon. I expect a critical examination of my reply, since I am not entirely sure that my first impression is correct.
John's work has been in complier design. One can clearly see the importance of the 1976 paper, by Mickunas et al, on transforming grammars of a specific type into a second specific type. These types of papers were and continue to be common, but framed on formalism that often has hypotheticals. The mathematics is correct and interesting, but in the end the conclusions are that an approach is being developed that might one day solve the practical problem started in the title. As Peter Stephenson will agree, compiler theory does set up the model of computing regularity that one finds in a stochastic model of complier behavior, as seen in
http://www.ontologystream.com/cA/tutorials/pre-CDKB.htm
The requirement in complier theory is to produce a certain class of run time behaviors that optimized the production of executable binaries.
However, the relationship between Cubicon and any other programming language has to be considered at the "behavioral level".
Sandy can speak to this better than I.
I will say that i am intrigued by some of the work internal to the paper by Mickunas et al. In much of the work that Stephenson and I have been doing in categoricalAbstraction (cA) we are concerned about the folding of a string in such a way that the patterns present in the strong are pressed into a fold in such a fashion as to minimize the length of the "compressed string". String cutting is allowed but comes with a cost.
The eventChemistry (eC) develops once one knows what these folded pieces are and how they express into some functional whole as a means to produce a system state of some consequence.
Richard Ballard knows much more about this than I.
Peter Stephen can also speak to this a bit, as this is the key to our work on the representation of cyber attack mechanics.
I may have some misunderstanding of the paper by Mickunas et al but my sense is that Cubicon merely defines a means to program computers using behavioral icons which reflect already the patterns that one finds, the categorical Abstractions being regularly expressed because of the needs of the social/business world.
Why would one desire a means to transform C or Java into Cubicon? Just write the Cubicon once, and be sure that the encoding structures, the binary instantiation of each of the icons used, is an optimal instantiation. End of story.
Clearly I am taking a practical position on backwards “compatibility” to the existing programs. The fact is that the compatibility can be at the behavioral level. There need not be an industry formed around automating the movement of information systems into Cubicon. It is far easier to just learn the behavioral patterns and re-develop the behaviors using the iconic manipulation.
The only real issue that I can see, and I may be missing something, is in sending data between the Core Talk world and the non CoreTalk world, and Sandy has addressed this clearly in his presentations
http://www.bcngroup.org/beadgames/safeNet/CoreTalkIntro.zip