SECURITY ONTOLOGY CONSTRUCTION AND INTEGRATION

Tomasz Boi´nski, Piotr Orłowski, Julian Szyma´nski and Henryk Krawczyk

Department of Computer Architecture, Faculty of Electronics, Telecommunications and Informatics

Gdansk University of Technology, Gdansk, Poland

Keywords:

Ontology design, Ontology integration, Security ontology.

Abstract:

There are many different levels on which we can examine security. Each one is different from others, all of

them are dependent on the context. Hence the need to bear additional knowledge enabling efﬁcient utilization

of the knowledge by the computers. Such information can be provided by ontologies. The paper presents

gathered requirements needed to be taken into account when creating an onthology. The method of ontology

creation and the criteria for keywaords selection are presented. Ontology created in such way should provide

means for interoperability with other systems.

1 INTRODUCTION

The Universal Polish Language Dictionary (Dubisz,

2008) deﬁnes security as “state of non-danger, tran-

quility, conﬁdence.” Experts related to international

relationships (

Zukrowska and Gra¸cik, 2006) and mil-

itary (Nowakowski, Z. and Szafran, H., 2009) all

agree with that statement. Experts from other ﬁelds,

like (Anderson, 2005) or (Borgosz-Koczwara and

Herlender, 2008) usually provide a deﬁnition that is

similar but just more detailed.

The meaning of the term security is greatly inﬂu-

enced by the context it is used in. Security will be

understood differently when we are talking about a

personal computer, going on a vacation to some un-

stable country and when we are talking about a nu-

clear plant. There are many different layers on which

we can examine security, each differs with possible

risks and outcomes.

(

Zukrowska and Gra¸cik, 2006) distinguishes two

different types of security dependent on the source of

threat:

• external security – security related to external fac-

tors,

• internal security (safety) - security related to in-

ternal factors.

(Kim et al., 2005) marks that the creation of anno-

tations describing the security of network resources

allows better service allocation. (Herzog et al., 2009)

adds that accepting one, common set of terms and re-

lations between those terms is good for any type of or-

ganization, as any misunderstanding in terms of secu-

rity can be costly and time consuming. Unfortunately

many terms in security have vague deﬁnitions. It is

also worth mentioning that in 2003 (Donner, 2003)

raised a need of creation of single, common ontology

for network resources description. Such appeal was

later raised again by European Network and Informa-

tion Security Agency (ENISA) (ENISA, 2006).

Such common ontologies start to emerge but often

speciﬁc aspects of a given problem makes it unusable

without some changes or additions or even creation

of new ontology. It is however important to perform

such modiﬁcations or creation of a new ontology in a

way that will allow future integration with other solu-

tions. Such process will be described in further chap-

ters of this paper.

2 SECURITY ONTOLOGY

DESIGN

The method used for the creation of the presented on-

tology is a combination of the best practices from

the solutions proposed by researchers working in

this ﬁeld. Creation of an ontology characterized by

good quality, extendability and usability in applica-

tions and research, like OCS project (Boi´nski et al.,

2009)(Boi´nski et al., 2010a), was a priority. The

method was based on works of (Noy et al., 2001),

mainly extended by aspects from NeOn (Su´arez-

Figueroa et al., 2009b)(Su´arez-Figueroaet al., 2009a)

and UPON (De Nicola et al., 2009) methodologies.

In initial phase gathering and analysis of require-

369

Boi

nski T., Orłowski P., Szyma

nski J. and Krawczyk H..

SECURITY ONTOLOGY CONSTRUCTION AND INTEGRATION.

DOI: 10.5220/0003636003690374

In Proceedings of the International Conference on Knowledge Engineering and Ontology Development (KEOD-2011), pages 369-374

ISBN: 978-989-8425-80-5

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

ments for the ontology was made. As a result On-

tology Requirement Speciﬁcation Document was cre-

ated. Before implementation requirement analysis

was performed and available solutions were checked.

Ontology development started with analysis and

selection of basic concepts as it inﬂuences further in-

teroperability (Boi´nski et al., 2010b). Using selected

basic concepts a model in descriptive logic was cre-

ated. After this step further development was per-

formed.

2.1 Ontology Requirement Speciﬁcation

Document

Creation of this document was based on a template

proposed for NeOn project (Su´arez-Figueroa et al.,

2009b). Some elements were taken from (De Nicola

et al., 2009) and second edition of the book Hand-

book on Ontologies (Sure et al., 2009). The docu-

ments goals were:

• describe the reason for creating the ontology,

• describe its boundaries,

• ﬁnd its applications,

• speciﬁcation of requirements that need to be real-

ized by the ontology.

Additionally it contained:

• list of technical requirements for the ontology,

• list of quality requirements,

• list of other requirements needed by the client of

the ontology,

• proposition of list of knowledge sources about the

ontology domain,

• list of other ontologies that can be used,

• list of questions that should be answered by the

ﬁnal ontology.

2.2 The Reason for Creating the

Ontology

The goal for the ontology is creation of common, un-

ambiguous semantic model of terms from security do-

main, providing means for easy extension and usabil-

ity in research projects. The ontology will be devel-

oped in OCS ontology editor. Currently OCS sup-

ports all languages provided by OWL API 2.1.1 (Hor-

ridge and Bechhofer, 2009), like RDF, RDFS and

OWL 1.1. OWL 2.0 will be supported in future ver-

sions of OCS. Because of this limitation OWL 1.1 was

selected as language of the ontology in its DL dialect.

As ﬁle representation rdf/owl was selected, what en-

sures its portability. Also the ontology need to have

one namespace, as owl:imports are not yet supported

by OCS.

2.3 Boundaries of the Ontology

The created ontology in general should contain sub-

jects from the following areas:

• general meaning of security and safety,

• domains closely related with security but in lim-

ited scope.

In detail the ontology should contain:

• basic and general terms in the ﬁeld of security,

• terminology from the domain of information

safety and security,

• the most important terms from other ﬁelds of se-

curity, e.g.:

– road trafﬁc,

– national and international,

– energetic, etc.

To further limit the wide scope of the ontology it

was decided that it will contain general security and

safety terminology and detailed terminology describ-

ing security and reliability of computer systems. In-

formation security is close to other ﬁelds of security

and is generally understood by people from ﬁeld of

computer science.

Following knowledge bases were selected as basic

sources of knowledge:

• NIST Glossary (Kissel, 2006),

• ENISA risk management glossary (Enisa, 2010),

• Ian Sommerville book “Software Engineer-

ing” (Sommerville, 2006).

Such selection allows capture of different ap-

proaches to security and safety. First of them shows

American approach to security, second shows Euro-

pean aspects of the problem and the third one shows

approach represented by software engineers.

Additionally to the above sources, it was decided

to extend the ontology by the following taxonomies:

• IEEE computer security taxonomy (Avizienis

et al., 2004),

• Firesmith security requirements taxonomy (Fire-

smith, 2005a)(Firesmith, 2005b).

Those two publications are well formalized so

moving contained in them informationto the ontology

should be easily doable. Unfortunately there are no

publicly available ontologies based on those sources.

KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development

370

2.4 End Users

Target users of the created ontology are:

1. researchers and students interested in topics re-

garding security, safety, ontologies or just are in

need of security ontology,

2. software developersthat need security ontology to

create semantic annotations to their web services

or other applications,

3. agent systems or search systems utilizing data pre-

viously annotated by the security ontology.

2.5 Intended Usage

The ontology was created for following usages in

mind:

1. scientiﬁc targets, including testing and extension

of OCS system,

2. creation of a WWW page simplifying learning by

the students topics connected to security,

3. applications created with ubiquitous program-

ming in mind,

4. applications related with developed by Gda nsk

University of Technology system for trafﬁc man-

agement,

5. search engines and agent systems,

6. other applications related to Semantic Web.

It is also recommended that created domain ontol-

ogy should be so called general purpose ontology so

that it will be usable in other applications.

2.6 Nonfunctional Requirements

1. The ontology should support both polish and En-

glish language.

2. Concept and properties deﬁnitions should come

from renown sources or standards.

3. Knowledge sources should be clearly provided.

4. The ontology should be expandable.

5. The ontology should be adaptable.

6. Concepts and properties should be described in a

way that should be human readable to allow their

easy understanding.

7. The ontology should be consistent.

8. The ontology should be complete.

9. The ontology should be portable.

10. The ontology should work with OCS system.

11. Classiﬁcation operation should last no more than

one second.

2.7 Functional Requirements

Functional requirements, as suggested by (Su´arez-

Figueroa et al., 2009b), were presented in form of

competency questions (Table 1).

Table 1: Functional requirements.

Question Expected answer

What is a risk? Probability of a loss.

What type of attacks can

be performed against com-

puter systems?

DoS, unauthorized access,

etc.

What is an internal safety? State of internal threats.

What are attributes of exter-

nal security?

Accessibility, integrity,

conﬁdentiality.

What is an attack? Violent usage of force

against somebody.

2.7.1 Ontology Architecture

It was decided that the ontology should be divided

into modules according to ODP (ODP Portal, 2011).

Due to lack of owl:imports support by OCS system

target ontology must be merged into one ﬁle with

common namespace. Three modules are planned: ba-

sic core module, security and reliability module and

security requirements module.

2.7.2 Naming Convention

Naming convention proposed by (Schober et al.,

2007) was applied to the ontology. It forces usage

of context free and human readable names. It forbids

usage of names that are negations. Additionally, inde-

pendently from the naming convention, it was decided

to use camel case for multi word names. Names of

classes and individuals will start with uppercase (e.g.

SampleClassName) and names of properties will start

with lowercase (e.g. samplePropertyName).

2.7.3 Evaluation and Veriﬁcation of the

Ontology

To verify consistency, completeness and adaptabil-

ity of created ontology tests need to be performed.

For that reason Prot´eg´e Ontology Tests, included into

version 3.4.4 of Prot´eg´e editor (Knublauch et al.,

2004), were used. Tests should be performed for

each module separately as well as for the whole

combined ontology and they were based on ques-

tions deﬁned in Table 1. To ﬁnd answers for that

questions Prot´eg´e plugin called DL Query was used.

Achieved results were compared with the ones that

were expected. Completeness tests required involve-

ment of domain experts and was performed manually

SECURITY ONTOLOGY CONSTRUCTION AND INTEGRATION

371

as there are currently no means of automatic coverage

checks (Krawczyk, 2007)(Tartir, 2009).

2.8 Basic Concepts

Basic concepts are necessary for creation of ontology

core. Their selection inﬂuences further interoperabil-

ity (Boi´nski et al., 2010b) of the ﬁnal ontology. To

choose proper set of basic concepts external sources

were checked for common terms and important top-

ics.

2.8.1 The Most Important Concepts in Security

Engineering

When describing security (Anderson, 2005) concen-

trates on targets and attributes of security: conﬁden-

tiality, integrity and availability. For description of

security itself he uses the following concepts: system,

subject, participant, identity, trusted, reliable, privacy,

secrecy, anonymity, authenticity, vulnerability, threat,

security breach, security, security proﬁle.

The terms system, subject and participant can be

connected with organization’s assets. Terms vulnera-

bility, threat and security were mentioned both in ISO

model as well as in Fenz and Herzog ontologies. Rest

of the concepts in their ontology are treated either as

security attributes (conﬁdentiality, integrity, availabil-

ity) or as not signiﬁcant.

2.8.2 Security in Software Engineering

As a main subjects connected with internal safety

Sommerville (Sommerville, 2006) states: incident,

threat, harm, level of threat, probability of risk, risk.

As main subjects connected with external security

the author states: exposure, vulnerability, threat and

surveillance. Additionally he connects security with

reliability, availability and credibility.

2.8.3 Basic Concepts in Field of International

Security

Zukrowska (

Zukrowska and Gra¸cik, 2006) deﬁnes ba-

sic concepts in context of international relations. Pro-

posed lists differs substantially form previously pre-

sented and includes: defense (readiness to repel the

attack, and a synonym for security guarantees), neu-

trality (not to engage in situations and organizations,

which can cause conﬂicts), budget (military), na-

tional interest, raison d’etat, strategic sectors, strate-

gic reserves, interdependence, cooperation, globaliza-

tion. Defense and neutrality can be connected to rem-

edy measures. Military budget, strategic sectors and

strategic reserves are directly connected with national

treasury.

2.8.4 Basic Concepts in Field of Energetic

Security

Czerpak (

Zukrowska and Gra¸cik, 2006) as main con-

cepts related to energetic security states the following:

availability, threat, security policy.

All concepts from above sources were combined

with each other and as a result following basic con-

cepts were selected: security, safety, security at-

tribute, vulnerability, security policy, risk, harm, safe-

guard, threat, protected subject.

3 ONTOLOGY CONSTRUCTION

Target ontology was implemented in an iterative and

incremental manner. The design decision was that

the ontology will be implemented in three modules,

which in the ﬁnal stage will be merged into one mono-

lithic ontology.

The core module was created form three small on-

tologies each counting less than 100 classes. Those

ontologies were designed during research on basic

concept selection (Boi´nski et al., 2010b). Those on-

tologies were combined into single OWL ﬁle. Secu-

rity and reliability module contains one average sized

ontology based on Aviˇzienis taxonomy (Avizienis

et al., 2004). Security requirements module also con-

tains one ontology created in respect to Firesmith tax-

onomy (Firesmith, 2005a)(Firesmith, 2005b). Each

of those ontologies was created according to proce-

dure described in previoussections of this paper using

Prot´eg´e 4.0.2 editor (Gennari et al., 2002)(Noy et al.,

2000).

(Noy et al., 2001) methodology after extension

with UPON and NeOn aspects contained the follow-

ing steps:

• Lexicon Creation. This step involves selection

of concepts form chosen knowledge sources (both

glossaries and taxonomies),

• Concept Selection. Each subject included into

the lexicon automatically becomes a member of

concept set. Additionally from deﬁnition of

those concepts proper names and more signiﬁ-

cant nouns were selected. Such set of concepts

was converted into OWL classes. When available

those classes were annotated with their descrip-

tion taken form the glossary or taxonomy,

• Concept Hierarchy Creation. Each occurrence

in glossary or taxonomy of statements similar to

KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development

372

“expression A is of type B” was converted into

OWL subclassOf relation. In taxonomies such re-

lations usually are presented graphically as inher-

itance which speeds up its conversion to the on-

tology,

• Selection of Disjoint Concepts and Synonyms.

In case of classes which names are clearly disjoint

like AccidentalBreakdown and NonAccidental-

Breakdown disjointWith relation was introduced.

In other cases disjointness was added manually

basing on human experience and descriptions in

chosen glossaries. Same procedure applies in case

of synonyms,

• Relations Identiﬁcation and Selection. As base

for relations verbs were selected from concept

deﬁnitions. If such verb connects any two selected

concepts than it is transformed into a relation be-

tween those concepts. In taxonomies often aggre-

gation relations are presented graphically. Such

relations were converted into “has part” relation,

• Creation of Relation Hierarchy. Relations sim-

ilar in respect of verbs in their names were

grouped.

• Reﬁning of the Relations. Domains and counter

domains of all relations was added to the ontol-

ogy. Where possible relations were marked as

(non)functional, (non)transitive etc.

• Ontology Integration. Ontologies were com-

bined ﬁrst within modules and later into one

monolithic ontology.

Comparing the security and reliability and secu-

rity requirements modules the basic core module one

can see that to much greater extent they resemble tax-

onomies. They describe their area more strongly at

the same time. During construction process each on-

tology got it’s own namespace and URI address.

4 ONTOLOGY INTEGRATION

Ontology integration using PROMPT, Ontology

Module Composition orContent Map didn’t provide

satisfactory results so hybrid, partially manual ap-

proach was undertaken. Ontologies were combined in

parts of two. Given pair was compared using Falcon-

AO tool (Jian et al., 2005). Result of such comparison

was than manually implemented using Prot´eg´e editor

by means of subClassOf or subPropertyOf relations.

Following rules were applied during integration:

• if concept deﬁnitions allows statement that one of

the concepts is more general than the other one

than subsumption relation is used,

• if both concepts have identical deﬁnitions and

classes (properties) related to them in both ontolo-

gies does not have subclasses (subproperties) than

one of them was either removed from integrated

ontology or equivalentClass (equivalentProperty)

was used, when there were subclasses (subproper-

ties) related to them than equivalentClass (equiv-

alentProperty) was always used,

• when concepts are different than they were con-

nected by closes, common super class (super

property), when necessary such generalizing con-

cept/property was created.

When applicable combined classes were sufﬁced

by a token identifying source of their deﬁnition as

advised by Ontology Design Patterns (ODP Portal,

2011). As a result one big ontology was created. It

contains 757 classes and properties. After merging

those ontologies the namespace and URI was uni-

ﬁed. Such combined ontology proved to implement

all planed requirements.

5 ONTOLOGY SHARING

According to basic deﬁnition of ontology (Gruber

et al., 1993), for a highly formalized data model has

become the ontology, it must also be shared. For this

reason the created ontology was placed into the OCS

portal. In the future the ontology can became part

of one of the services developed using that system.

Each registered user will be able to track and inﬂu-

ence changes in the ontology. Changes will be how-

ever applied only by speciﬁed experts. OCS also sup-

ports versioning of ontologies so every change, can

always be reversed or the ontology can be developed

as many, concurrent versions of the same core idea.

6 CONCLUSIONS

Way how ontologies are created is very important.

Both the process itself and even selection of basic

concepts can inﬂuence how and even if the ontology

will be usable outside its primary application or will

it be suitable for integration with other ontologies.

In this paper we shown that an ontology can be de-

signed and created in a way that will make it suitable

for interoperability and integration. In near future we

would like to extend our works to include automatic

ad hoc ontology integration eliminating manual as-

pects form presented steps in ontology design.

SECURITY ONTOLOGY CONSTRUCTION AND INTEGRATION

373

ACKNOWLEDGEMENTS

This work was ﬁnanced by National Science Center.

REFERENCES

Anderson, R. (2005). In˙zynieria zabezpiecze´n.

Avizienis, A., Laprie, J., Randell, B., and Landwehr, C.

(2004). Basic concepts and taxonomy of dependable

and secure computing. Dependable and Secure Com-

puting, IEEE Transactions on, 1(1):11–33.

Boi´nski, T., Budnik, Ł., Jakowski, A., Mrozi´nski, J., and

Mazurkiewicz, K. (2009). OCS – Domain Oriented

Ontology Creation System. In SMI’09, 4th Interna-

tional Conference ’Congress of Young IT Scientists’.

HARD Olsztyn.

Boi´nski, T., Jaworska, A., Kleczkowski, R., Kunowski, P.,

and Szama´nski, J. (2010a). Zespołowa budowa on-

tologii z wykorzystaniem systemu OCS oraz edytora

Prot´eg´e. Zeszyty Naukowe Wydziału ETI Politechniki

Gda´nskiej, 19:101–105.

Boi´nski, T., Orłowski, P., Szpryngier, P., and Krawczyk, H.

(2010b). Inﬂuence and selection of basic concepts on

ontology design. In KEOD2010, pages 364–369.

Borgosz-Koczwara, M. and Herlender, K. (2008). Bez-

piecze´nstwo energetyczne a rozw´oj odnawialnych

´zr´odeł energii. Energetyka, pages 194–197.

De Nicola, A., Missikoff, M., and Navigli, R. (2009). A

software engineering approach to ontology building.

Information Systems, 34(2):258–275.

Donner, M. (2003). Toward a security ontology. IEEE Se-

curity and Privacy, pages 6–7.

Dubisz, S. (2008). Uniwersalny słownik je¸zyka polskiego.

Wydawnictwo Naukowe PWN.

ENISA (2006). Risk management: implementation princi-

ples and inventories for risk management/risk assess-

ment methods and tools. Technical report.

Enisa (2010). Enisa: a European Union

Agency - Glossary of Risk Management.

http://www.enisa.europa.eu/act/rm/cr/risk-

management-inventory/glossary.

Firesmith, D. (2005a). A Taxonomy of safety-related re-

quirements. In International Workshop on High As-

surance Systems (RHAS’05).

Firesmith, D. (2005b). A taxonomy of security-related re-

quirements. In International Workshop on High As-

surance Systems (RHAS’05). Citeseer.

Gennari, J. H., Musen, M. A., Fergerson, R. W., Grosso,

W. E., Crubzy, M., Eriksson, H., Noy, N. F., and Tu,

S. W. (2002). The evolution of Protege: An environ-

ment for knowledge-based systems development. Stan-

ford Medical Institute, Stanford.

Gruber, T. et al. (1993). A translation approach to

portable ontology speciﬁcations. Knowledge acqui-

sition, 5:199–199.

Herzog, A., Shahmehri, N., and Duma, C. (2009). An on-

tology of information security. International Journal

of Information Security.

Horridge, M. and Bechhofer, S. (2009). The OWL API:

a Java API for working with OWL 2 ontologies.

In Proc. of the 5th Int. Workshop on OWL: Experi-

ences and Directions (OWLED 2009), CEUR Work-

shop Proceedings, pages 23–24.

Jian, N., Hu, W., Cheng, G., and Qu, Y. (2005). Falcon-

AO: Aligning ontologies with Falcon. In Integrating

Ontologies Workshop Proceedings. Citeseer.

Kim, A., Luo, J., and Kang, M. (2005). Security ontology

for annotating resources. On the Move to Meaningful

Internet Systems 2005: CoopIS, DOA, and ODBASE,

pages 1483–1499.

Kissel, R. (2006). Glossary of key information security

terms. Glossary, National Institute of Standards and

Technology, US Department of Commerce.

Knublauch, H., Fergerson, R., Noy, N., and Musen, M.

(2004). The Prot´eg´e OWL plugin: An open develop-

ment environment for semantic web applications. The

Semantic Web–ISWC 2004, pages 229–243.

Krawczyk, H. (2007). Ontology engineering and its appli-

cations. Department of Computer System Architec-

ture, ETI Faculty, Gda´nsk University of Technology.

Nowakowski, Z. and Szafran, H. (2009). Bezpiecze´nstwo

w XXI wieku : strategie bezpiecze´nstwa narodowego

Polski i wybranych pa´nstw. Wydawnictwo Politech-

niki Rzeszowskiej.

Noy, N., McGuinness, D., et al. (2001). Ontology develop-

ment 101: A guide to creating your ﬁrst ontology.

Noy, N. F., Fergerson, R. W., and Musen, M. A. (2000). The

knowledge model of Protege-2000: Combining inter-

operability and ﬂexibility. In Lecture Notes in Com-

puter Science. Springer-Verlag.

ODP Portal (2011). Ontology Design Patterns.

http://ontologydesignpatterns.org/wiki/Main Page.

Schober, D., Kusnierczyk, W., Lewis, S., Lomax, J., et al.

(2007). Towards naming conventions for use in con-

trolled vocabulary and ontology engineering. Pro-

ceedings of BioOntologies SIG, ISMB07, pages 29–

32.

Sommerville, I. (2006). Software Engineering. 8th. Harlow,

UK: Addison-Wesley.

Su´arez-Figueroa, M. et al. (2009a). D5. 4.2: Revision

and extension of the neon methodology for build-

ing contextualized ontology networks. NeOn project.

http://www. neon-project. org.

Su´arez-Figueroa, M., G´omez-P´erez, A., and Villaz´on-

Terrazas, B. (2009b). How to write and use the On-

tology Requirements Speciﬁcation Document. On the

Move to Meaningful Internet Systems: OTM 2009,

pages 966–982.

Sure, Y., Staab, S., and Studer, R. (2009). Handbook on

Ontologies. Springer.

Tartir, S. (2009). Ontology-driven Question Answering and

Ontology Quality Evaluation. PhD thesis, University

of Georgia.

Zukrowska, K. and Gra¸cik, M. (2006). Bezpiecze´nstwo

mie¸dzynarodowe: teoria i praktyka. Szkoła Gł´owna

Handlowa w Warszawie.

KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development

374