From the Editors: Toward a Security Ontology
[This editorial was published originally in "Security & Privacy" Volume 1 Number 3 May/June 2003]
There comes a point in the life of any new discipline when it realizes that it must begin to grow up. That time has come to the security field, as this magazine's founding indicates. Many things come with adulthood — some desirable and some less so. If we're to establish a place in the engineering community for ourselves as practitioners with expertise in security and privacy issues, we must be clear about what it is that we do and what we don't do; what can be expected of us and the boundaries of our capabilities.
Today, far too much security terminology is vaguely defined. We find ourselves confused when we communicate with our colleagues and, worse yet, we confuse the people we're trying to serve. Back in the bad old days, it seemed clearer. The Orange Book (see the related sidebar) was new and seemed relevant, and the industry agreed on the nature of the security problem. Today, we find the Orange Book, developed near the end of mainframes' golden age and before the widespread networking of everything with a program counter, less helpful.
In the midst of a security incident, we have a responsibility to communicate clearly and calmly about what's happening. We must be able to explain during incidents (and at other times) to fellow security experts, to other technologists, and to the general public in a clear and effective way just what it is that we do, how we do it, and how they benefit from our work. For this conversation, simple appeals for better security are too trivial, but detailed analyses of cryptographic key lengths are too fine-grained.
There have been several attempts at assembling glossaries of terms in the field. Although these have been useful contributions, glossaries are inherently unable to give form and direction to a field. A glossary is generally a collection of known terms and should be inclusive in scope. This means that it naturally includes contradictory or subtly overlapping terms, leaving it to the reader to decide which to use and which to discard. Independent practitioners will innocently make different choices, and suddenly we're in comp.tower.of.babel.
It is the nature of an active technical field that there be continuing change. New systems are built, old ones are modified, and both have new vulnerabilities. Attacks are developed that exploit these vulnerabilities, letting bad guys wreak a certain amount of havoc before we can mobilize and close them off. Some of these exploits are not conceptually new: we've seen them before and we can classify them with other like things. This helps us predict outcomes and set expectations. Other things truly are new: we must name them so that we can talk about them later. What's missing is a broader context that we can use to organize our thinking and discussion.
What the field needs is an ontology — a set of descriptions of the most important concepts and the relationships among them. Such an ontology would include at least these concepts: data, secrecy, privacy, availability, integrity, threats, exploits, vulnerabilities, detection, defense, cost, policy, encryption, response, value, owner, authorization, authentication, roles, methods, and groups. It should also contain these relationships: "owns," "is an instance of," "acts on," "controls," "values," "characterizes," "makes sets of," "identifies," and "quantifies." A good ontology will help us organize our thinking and writing about the field and help us teach our students and communicate with our clients. A great ontology will help us report incidents more effectively, share data and information across organizations, and discuss issues among ourselves. Just as students of medicine must learn a medical ontology as part of their education, to avoid mistakes and improve the quality of care, so ultimately should all information technologists learn the meanings and implications of these terms and their relationships.
There has been a substantial amount of good work along the lines of developing an ontology, starting at least with the Orange Book. However, recent rapid growth in the field has left the old ontology behind; as a result, it increasingly feels like we're entering the precincts of the Tower of Babel. We need a good ontology. Maybe we can set the example by building our ontology in a machine-usable form in using XML and developing it collaboratively. Is there a Linnaeus, a father of taxonomy, for our field waiting in the wings somewhere?
[Here is a PDF file of the original editorial.]
There comes a point in the life of any new discipline when it realizes that it must begin to grow up. That time has come to the security field, as this magazine's founding indicates. Many things come with adulthood — some desirable and some less so. If we're to establish a place in the engineering community for ourselves as practitioners with expertise in security and privacy issues, we must be clear about what it is that we do and what we don't do; what can be expected of us and the boundaries of our capabilities.
Today, far too much security terminology is vaguely defined. We find ourselves confused when we communicate with our colleagues and, worse yet, we confuse the people we're trying to serve. Back in the bad old days, it seemed clearer. The Orange Book (see the related sidebar) was new and seemed relevant, and the industry agreed on the nature of the security problem. Today, we find the Orange Book, developed near the end of mainframes' golden age and before the widespread networking of everything with a program counter, less helpful.
In the midst of a security incident, we have a responsibility to communicate clearly and calmly about what's happening. We must be able to explain during incidents (and at other times) to fellow security experts, to other technologists, and to the general public in a clear and effective way just what it is that we do, how we do it, and how they benefit from our work. For this conversation, simple appeals for better security are too trivial, but detailed analyses of cryptographic key lengths are too fine-grained.
There have been several attempts at assembling glossaries of terms in the field. Although these have been useful contributions, glossaries are inherently unable to give form and direction to a field. A glossary is generally a collection of known terms and should be inclusive in scope. This means that it naturally includes contradictory or subtly overlapping terms, leaving it to the reader to decide which to use and which to discard. Independent practitioners will innocently make different choices, and suddenly we're in comp.tower.of.babel.
It is the nature of an active technical field that there be continuing change. New systems are built, old ones are modified, and both have new vulnerabilities. Attacks are developed that exploit these vulnerabilities, letting bad guys wreak a certain amount of havoc before we can mobilize and close them off. Some of these exploits are not conceptually new: we've seen them before and we can classify them with other like things. This helps us predict outcomes and set expectations. Other things truly are new: we must name them so that we can talk about them later. What's missing is a broader context that we can use to organize our thinking and discussion.
What the field needs is an ontology — a set of descriptions of the most important concepts and the relationships among them. Such an ontology would include at least these concepts: data, secrecy, privacy, availability, integrity, threats, exploits, vulnerabilities, detection, defense, cost, policy, encryption, response, value, owner, authorization, authentication, roles, methods, and groups. It should also contain these relationships: "owns," "is an instance of," "acts on," "controls," "values," "characterizes," "makes sets of," "identifies," and "quantifies." A good ontology will help us organize our thinking and writing about the field and help us teach our students and communicate with our clients. A great ontology will help us report incidents more effectively, share data and information across organizations, and discuss issues among ourselves. Just as students of medicine must learn a medical ontology as part of their education, to avoid mistakes and improve the quality of care, so ultimately should all information technologists learn the meanings and implications of these terms and their relationships.
Conclusion
There has been a substantial amount of good work along the lines of developing an ontology, starting at least with the Orange Book. However, recent rapid growth in the field has left the old ontology behind; as a result, it increasingly feels like we're entering the precincts of the Tower of Babel. We need a good ontology. Maybe we can set the example by building our ontology in a machine-usable form in using XML and developing it collaboratively. Is there a Linnaeus, a father of taxonomy, for our field waiting in the wings somewhere?
[Here is a PDF file of the original editorial.]
Comments
Post a Comment