An Ontology-Based Approach to Information Systems Security Management - Computer Network Security - page 157

3.2 Security Ontology
In this section, we define a generic Security Ontology (SO), as “ an ontology that ela-
borates on the security aspects of a system ”. In the sequel, the terms “Security Onto-
logy” and “Ontology” will be used interchangeably.
Ontology languages such as OWL [18] provide for formal logic support like De-
scription Logics, a particular decidable fragment of first order logic (i.e. OWL DL
version), which has desirable computational properties for reasoning systems. It is true
that, OWL comparing to pure formal logic models expressing security issues may lack
in expressiveness (issue which is expected to be supported with the evolution of tools
compliant with OWL Full version), but ontologies have several advantages: a) ontolo-
gies are more close to human mentality expressing a world model, in contradiction
with formal languages which are difficult to understand and use by humans, b) the
formal models deal with access control issues mainly which can be expressed mathe-
matically and they lack support for more soft actions such as countermeasure selection,
c) comparing to formal languages, ontologies are more well-suited for expressing ap-
proximations and decision support systems via semantic support and inferencing
mechanisms, d) the query mechanisms which can be applied to OWL ontologies.
Our SO extends CIM meta-model in order to capture the security requirements of
an arbitrary IS. The SO is formulated as a CIM extension schema enriched with onto-
logical semantics, modeling the security management information; in addition, it is
linked with the legacy CIM concepts in order to access the already modeled informa-
tion for the IS resources. The SO acts as a container for the IS security requirements
(“ What ”), as they will be extracted from the available information sources. While
there is no standard method for ontology development [19], we followed the col-
laborative approach for ontology design described in [20]. The idea is to build an on-
tology by a group of people in an iterative way, improving the ontology in every
round. During design, well-known security standards and the design criteria in [5] we-
re taken into account. SO development is achieved through the following steps:
Step 1 - Consideration of ontology design criteria [1] as a framework for the deve-
lopment process ;
Step 2 - Identification of core security concepts from security standards and best
practice ; from a literature review of wide-accepted standards such as ISO/IEC
17799 [8], British Standard 7799 Part 2 [21], Australian Standard Handbook of
Information Security Risk Management (AS/NZS 4360) [22], and Common
Criteria framework [23], follows that there are recurrent and common used
concepts including threats, vulnerabilities, risks, controls, assets, and impacts.
Step 3 - Normalization of security vocabulary ; although recurrent and common used
entities and concepts exist in all standards, the vocabulary of risk and security
concepts in several cases is not identical (or even corresponding). Further-
more, different relationships between similar concepts exist, e.g. in AS/NZS
4360 vulnerabilities are linked directly to assets, whereas in CC vulnerabili-
ties are linked to assets through risks. Thus, focusing to provide a common
model for these informally recurrent concepts, a common vocabulary is estab-
lished which will be used for the SO definition.
Step 4 - Development of concept-centric partial ontologies ; in this step, in order to
facilitate understanding, we developed partial ontologies which include a cen-