Common Criteria Related Security Design Patterns for Intelligent Sensors—Knowledge Engineering-Based Implementation

1.1. Common Criteria Methodology and Its Extensions

The reader is encouraged to browse the Common Criteria primer [3](Section 3), extended in [4](Section 2) and supplemented there by the Common Criteria related terms and acronyms. More information about this methodology can be found in [2,6,7]. The Common Criteria (CC) methodology encompasses three main processes:

• the IT security development process, generally leading to the elaboration of the security specification called security target (ST), which defines the TOE built-in security functions;

• the TOE development process, related to the IT product or system development with the use of an assumed technology, including its security functions implementation at the claimed EAL level; the elaborated documentation, later used as evaluation evidences, comprises: the TOE development and guidance documentation, life-cycle definition, configuration management, delivery, flaw remediation, development security, testing, and vulnerability assessment issues;

• the IT security evaluation process, performed by an independent body, leading to certification.

The paper concerns the first process, which consists of the following stages: the security problem definition, security objectives, security requirements and the TOE security functions work-out. The CC standard provides the security functional (SFR) and assurance (SAR) components as the specification means for security requirements. Specification means for other stages, which are called generics, are defined by developers in a different way that causes problems for the common understanding and preciseness of the specification means. The author has introduced semiformal generics, called “enhanced generics”, which do not have this limitation, enabling to create more precise and compact security specifications [7–9]. Enhanced generics, expressing common security features and behaviours, have features similar to those of CC components, allowing parameterization, derivation, refinement and iteration. These works concern the UML/OCL-based IT security development framework (ITSDF) encompassing models of data structures and subprocesses related to the IT security development process. The ITSDF framework was implemented in the computer tool supporting IT security developers. The author’s defined enhanced generics and CC-defined components can be considered the Common Criteria related security design patterns (shortly: “CC-related patterns”), which are discussed in [3,4] in the context of intelligent sensors. Please note that these patterns concern the means used in the security specification building.

1.2. Security Design Patterns and Common Criteria Related Security Design Patterns

Engineers from different technology domains, including information technology, elaborate, use and improve their own design patterns, which are considered reusable, proven solutions to problems with respect to a given context. The author’s defined CC-related patterns, focused on the Common Criteria compliant IT security development, are more specific than the commonly used “design patterns” or “security design patterns”. The latter concern IT solutions, including security related solutions.

An extensive discussion of security design patterns can be found in [10]. These architectural patterns for software application concern different issues like: the enterprise security and risk management, identification and authentication, access control models and systems or operating system access control, accounting facilities, firewall architecture, secure Internet applications, IP telephony, and cryptographic key management.

The effectiveness of the use of security patterns with respect to design phases is discussed in [11]. The book [12] presents the UML extension called UMLsec, providing a unified approach to the security features description during the secure IT system development. UMLsec can be used to define different kinds of patterns, e.g.,: secure channel, TLS Internet protocol, electronic purse, secure Java programs, bank applications, biometric authentication systems, electronic signature, etc. The patterns defined there can be analyzed with the use of the method provided by [7] with respect to the CC methodology.

The above discussed security patterns, most similar to the patterns introduced in the paper, are related to the security features of IT solutions, especially software architectural solutions. Please note that they do not concern the CC methodology. The patterns presented here can be considered their extensions.

1.3. Knowledge Engineering Approach in IT Security Domain

Patterns encapsulate engineering knowledge and experiences, and the specific knowledge is needed to use them to achieve the expected solution of a design problem. A natural way is to use the knowledge engineering methodology to manage design-related knowledge. It allows one to obtain additional advantages offered by the knowledge engineering approach.

Knowledge bases may be elaborated with the use of ontologies. In computer science and information science “an ontology is a formal representation of the knowledge by a set of concepts within a domain and the relationships between those concepts. It is used to reason about the properties of that domain, and may be used to describe the domain” [13]. Ontologies have recently found application in many disciplines where “a common understanding”, “a common taxonomy” or “reasoning” are important, including: web-based applications, medicine, public administration, biology, and information security. Similar needs exist in the IT security development/evaluation domain. For this reason the research on applying the ontology-based method in this domain may bring new advantages.

The presentation of the knowledge engineering principles and the elaboration of ontologies and related knowledge bases is included in the paper [14] and in the documentation available free of charge together with the Protégé tool [5].

The first results of the author’s research in this field were presented in [15], discussing selected issues concerning the Specification Means Ontology (SMO). The paper [16] presents the SMO validation on the firewall example, while [17] concerns its validation on the motion sensor example. SMO was extended to the IT Security Development Ontology (ITSDO), expressing the IT security and TOE development (evidences) processes. ITSDO is equipped with a rather huge number of enhanced generics (ca. 350 items). They have general character and can be used for typical IT products or systems.

The experiences gained during the validation show that it would be more convenient to define subsets of generics for specific application domains. The paper is focused on defining and implementing the first of them—the subset for intelligent sensors development, elaborated on the results of the papers [3,4]. The previously elaborated CC-related design patterns will be here implemented as knowledge base items.

The introduced CC-related design patterns base on the specialized security ontology. A short overview of research works on security ontologies will provide suitable background for the presented research and development focused on the ontological approach to the discussed domain.

The first group of reviewed R&D works, most relevant to the presented paper, concern the ontological approach to the Common Criteria (ISO/IEC 15408) implementation:

• the paper [18] discusses an ontological model of the CC functional components mapped to the security objectives with the use of a specialized tool; it concerns only one stage of the IT security development process, omitting others;

• the paper [19] presents an ontological model of the CC assurance components and a query-based tool which supports evaluators in planning the evaluation process, retrieving relevant documents or creating reports; it is focused on the IT security evaluation process only, omitting the IT security development.

The above papers do not consider the entire IT security- and TOE development processes and are not focused on the elaboration of CC-related design patterns specific for some kinds of products or systems, such as intelligent sensors.

Some existing ontology-related research works deal with risk management issues: the work [20] discusses the quantitative risk analysis, the work [21] concerns the ontology-based selection of controls, while the paper [22] focuses on an ontology-centred technology risk management architecture for banking applications. The monograph chapter [23] introduces an ontology and knowledge base related to the advanced security trade-off methods which allow to classify these methods, to order their properties and to help select a right method for the given application.

Some papers are strongly related to the information security management systems, especially those compliant with ISO/IEC 27001 [24], or business continuity management systems compliant with BS 25999 [25].

Additionally, many common security issues ontologies [26–30] are elaborated, specifying different security terms and relationships between them, like: threats, attacks, policies, security of services, security agents, information objects, security algorithms, assurance and credentials, etc. A good example of this kind of work is the paper [31], discussing security and trust ontologies which encompass risk analysis issues, security algorithm taxonomy, security functions, attacks and defence, and trust. The number of elaborated security ontologies is growing and they cover all security relevant issues. None of these works is focused on the CC-related security design patterns, especially those for the intelligent sensors applications.

1.4. Paper Contents—A Continuation of the Previous Research

The paper is based on the author’s previous research works on IT security of sensors. The work [3] discusses architectures, applications and security issues, including the analysis of threats specific for sensors and their systems. On this basis a generalized intelligent sensor model and, related to it, CC-compliant intelligent sensor security model were elaborated. With respect to these models the CC-related security patterns were defined, expressing basic security features and behaviours of intelligent sensors. The set of patterns was validated on the intelligent medical sensor example and improved on this basis. The work [4] provides an improved notation of patterns and their semantics. Another revision of patterns was done on the basis of the validation on other design example. This time the validation concerned an intelligent methane detecting sensor for mines. Summing up, the works [3,4], allow one to properly define the CC-related security patterns and validate them on varied intelligent sensor projects.

Applying knowledge engineering methods in different application domains usually brings advantages such as better design preciseness, common understanding of terms, improved design reusability and automation, and better project knowledge representation. The paper considers the possibility to achieve these advantages with respect to the Common Criteria application domain.

The paper’s contribution can be expressed as the knowledge engineering methodology application for the intelligent sensors security development. The research and development objectives of the paper are:

• to provide a complete, ontological representation of the CC-related patterns;

• to provide a method to use them as knowledge base items for the security specifications elaboration;

• to evaluate these results on some examples.

The indirect, far-reaching objective is to provide such improved patterns, and the related knowledge how to use them, to a broader group of developers of intelligent sensors and sensor systems.

The Common Criteria IT security development process is complicated, needs specialized knowledge and is poorly supported by specialized software tools. Better support of this process and improvement of its effectiveness with respect to the time and cost are still considered challenges. Different efforts and research works in this area are in progress [32]. The author’s works concern these challenges but are restricted to a specific kind of IT products—intelligent sensors and their systems. The novelty of the paper related to the knowledge engineering methodology application in the Common Criteria standard domain concerns two main elements:

• CC-related patterns for sensors expressed as knowledge base items to specify completely security models for sensors, validated on a real methane detecting sensor in a mine;

• validation of the ontological model of the IT security development process as contribution to develop a professional tool for IT security developers.

The author provides a new category of security design patterns—the CC-related items, defined as knowledge base items, which can be used to specify security properties and behaviours of any intelligent sensor or sensors system. The ontological representation of these patterns creates new possibilities to build security specifications: developers obtain a set of predefined, optimized, sensors-focused specification items supplementing the CC-defined components. Generally, such patterns improve the IT security development process because developers are provided with well defined and ready-made solutions of elementary security issues. The CC-related patterns for intelligent sensors and sensors systems have not been developed yet. They encompass all IT security development stages (not only the selected ones, as presented in [18,19]) and the sensors-related domain is considered one of the emerging applications in the Common Criteria standard. Introducing ontological representation of these patterns gives additional advantages related to better automation and intelligence of this process.

The author’s research aims generally at the elaboration of a software tool to support IT security developers. The paper presents research works on the knowledge engineering methodology application to build such a tool. The research area has an innovative character—so far one knowledge base system for IT security development process has been elaborated [33], however it does not use any ontology. Besides, only two CC-related ontologies were elaborated (Section 1.3, [18,19]) but they represent only selected parts of the IT security development process. The empirical evaluation of the ontology-based model of the entire IT security development process was not performed before. For the empirical evaluation the well known Protégé tool is used. It allows one to create fast prototypes, to check different variants, to assess these variants, to experiment, and to obtain a lot of other useful information on the ontological model properties and behaviour. It is convenient for ontology developers’ experimentations but not for IT security developers as end-users. The aim of this evaluation with the use of Protégé tool, summarized at the end of the paper, is to work out some input to develop a software tool supporting IT security developers [34].

The paper contains two key sections. Section 2 discusses the ontology and knowledge base development process. Section 3 shows some examples presenting the ontology, related knowledge base and their use in the intelligent sensors security development. The additional, last section concludes the applied approach and planned works.

2.1. Definition of the Ontology Domain and Scope, and Competency Questions

The domain of the ITSDO ontology is constituted by the Common Criteria compliant IT security development and the TOE development processes, but the paper concerns the former process only and focuses on the security patterns for sensors. ITSDO provides common taxonomy for specified items, allowing one to better understand them and better express relationships between them. Important issues concerning the ontology domain are competency questions [14] which are defined as questions that the ontology related knowledge base is able to answer. These answers define the scope of the ontology. Please note that ontologies and their knowledge bases are developed incrementally, and after exceeding “a critical mass” a knowledge base allows to get answers to more and more advanced questions. The ITSDO knowledge base prototype is able to provide answers to basic questions related to the security development of any IT product or system though examples presented in the paper are focused on sensors.

The UML activity diagram shown in Figure 1 presents particular stages (subprocesses) of the CC-compliant IT security development process. The research is focused on the four most complicated stages where the ontological approach can be most suitable, i.e., the security problem definition, security objectives, security requirements and the TOE security functions work-out. The key requirements for the ITSDO ontology domain are:

• The ITSDO ontology should be able to express the entire IT security development process aimed at the elaboration of the security target (ST) specification for any IT product or system (TOE), i.e., it encompasses the entire Common Criteria applications domain. ITSDO includes the ST hierarchical structure, expressing its parts and relations between them, e.g., the security problem definition, security objectives, security functional and assurance requirements, and of course their parts, e.g., threats, OSPs and assumptions as the security problem definition (SPD) parts, etc. These “parts” play the role of containers for security-related data for different IT products or systems. It implies the need to define the second group of terms used as the specification means for these containers;

• The ITSDO ontology should be able to express the specification means for a given family of IT products or systems, here: “the intelligent sensors and sensors systems”. The Common Criteria specification means include: general-purpose functional and assurance components (defined in the CC) and TOE security specific generics: for threats, security policies, assumptions, objectives and functions description (i.e., the here discussed CC-related patterns for intelligent sensors and systems);

• The ontology should express two kinds of relationships existing in the IT security model of an IT product or system. The vertical relationships express relations between particular ST parts (containers) and specification means, placed into these containers. For example, we can put threat-type generics as specification means into the threats specification, which is considered a container. The horizontal ones express relations between specification means belonging to the neighbour levels of the security model, e.g., between any threat-type generic and a security objective-type generic which counters it;

• The ITSDO ontology should be able to demonstrate generally the ability to retrieve knowledge within the domain to assess the needs and expectations of IT security developers with respect to this issue, mostly the ability to retrieve all relationships within the project between any elementary security problem (threat, OSP, assumption) and its solutions, refined step by step—starting from security objectives, through functional requirements, to security functions implementing the requirements (and to evidences showing their implementation—not discussed in this paper). Retrieving may also concern finding some items of given characteristics to solve any security issue or to refine a given security issue. The retrieving allows to compare different solutions or their parts, helps to assess the completeness of solutions or find redundant solutions, etc. Generally, the retrieving should be able to support IT security developers in typical activities;

• The ITSDO ontology should be able to implement the reasoning possibility in the future to research IT security developers’ needs and expectations with respect to this issue. To ensure this and to make the elaborated models more precise in the future, the OWL-DL is preferred;

• ITSDO work-out should allow:

  • experimentations on the model of the IT security development process, on sensors example—to identify the basic concepts concerning this process and the relations between them.

  • the elaboration of the ontological model of the sensor/sensors systems domain, its validation in the sense of an adequate ontological representation of this domain, and finally its application in the elaborated software tool supporting sensors systems developers.

• ITSDO will be implemented in the Protégé environment;

• The self explanatory names of classes, properties and instances allow developers (humans) to better understand the terms during experimentations on security models.

2.2. Considering the Possible Reuse of Existing Ontologies

Reusing (integrating) the existing ontologies into the created one can speed up the ontology development process, can extend the ontology scope and the range of its applications. During the review of the paper-related R&D works (Section 1.3) two reusable ontologies [18,19] were encountered. The integration may be restricted to the Common Criteria components only, but reusing cannot be considered here because these ontologies are not publicly available.

2.3. Identifying Important Terms in the Ontology

The basic set of important terms encompassed by the ITSDO ontology was identified during the ontology domain analysis performed while the UML/OCL models of the ITSDF framework were elaborated [7]. With respect to the intelligent sensors domain of application the basic terms expressing threats, security policy rules, assumptions, security objectives and functions are identified in the papers [3,4]. The identified terms are used here to define the ontology classes and their properties.

2.4. Definition of Classes (Concepts) and the Class Hierarchy

ITSDO is developed iteratively with the use of a typical top-down approach with certain bottom-up activities. The right knowledge representation, as the sensors security patterns, requires the analyses of terms and relations between terms to properly express such relations as: class-instance, class-subclass and class-superclass, and to decide what should be expressed by a class and what by a property, what by abstract classes and what by classes which have instances [14]. While elaborating the ontology class hierarchy, the possibility of its future evolution should be considered. Most class names are self explanatory, though their lengths should be limited.

2.5. Definition of Class Properties and Their Restrictions

Classes can have some properties assigned. Three kinds of properties can be distinguished [14]:

• object-type properties (also called “instance-type properties”) are used to express “complex properties”, i.e., relationships between an instance of the given class (the object) and other instances; the two following situations are typical: the first one occurs when the given instance consists of other instances, the second one when the instance points to other instances; an instance-type property is attached to the classes which are called a domain; the classes indicated by this property are called a range;

• data-type properties are used to express “simple properties” or “attributes”, i.e., intrinsic or extrinsic properties of the instances of the most elementary classes; these properties are expressed by data types commonly used in modelling or programming, e.g.,: integer, byte, float, time, date, enumeration, string, etc.;

• annotation, RDF-based (RDF means Resource Description Framework) properties, are used to document different ontology items (classes, properties, instances); the most known example of this property is the rdfs:comment property which gives more explanation of the given ontology item.

For properties, the restrictions can be defined. They specify or limit a set of possible values for the given property. The ITSDO ontology uses all types of properties (it will be exemplified in Section 3). The defined properties are also self-explanatory. The properties contents expresses the features of the sensors design patterns.

2.6. Creating Instances and Filling in Their Properties

Instances represent non-abstract class members. For ITSDO the instances are defined mainly for the classes of the lowest hierarchy level. The instances with filled-in properties represent the key Common Criteria methodology artefacts, like CC components, CC-related design patterns and evaluation evidences. The instances with their properties expressing relationships constitute the ITSDO-related knowledge base. Some auxiliary instances of abstract meaning are used to organize the knowledge base. The instances of classes representing threats, security policy rules (OSPs), assumptions, security objectives, and functions represent sensors-specific design patterns. The instances of the functional and assurance CC components have general meaning and can be used for any IT products or systems.

2.7. Testing and Validation of the Developed Ontology

During its elaboration, the ITSDO ontology was tested—to avoid commonly known errors discussed in [14], and validated—to assess its usability. The Protégé environment provides some facilities to support these experiments. Testing is done with the use of menu options: “Checking consistency” and “Run ontology tests”. Certain tests are performed manually in the form of ontology inspections supported by OWLViz—a built-in visualization tool (plug-in). During the validation process the user checks if the right structures of instances are composed, if they have assumed properties, if the needed information can be retrieved properly by queries from the knowledge database, and if the forms are properly defined. The ITSDO ontology validation encompasses the basic scenarios of the ontology use.

4.1. Summary of Validation Example

The Methane Early Detection Intelligent Sensor (MEDIS), discussed in the paper [4], was chosen as the object of validation. The reader can compare both variants of the applied IT security development process:

• performed manually, but patterns-based, described in [4], and,

• the ontology-based variant, discussed here

The presented validation shows how the key security issues can be expressed using the ontological representation of the CC-related security patterns. During the validation, the MEDIS security target was developed step by step. The security problem definition (SPD) requires to identify the threats, organizational security policies and assumptions for the TOE. In the same way, the method proposed here allows to specify the active entities (legal subjects, threat agents) and passive entities (protectedand threatened assets). Both these entities can be used as parameters values for the SPD items. For each elementary security issue its elementary solution in the shape of a security objective was formulated. Then particular security objectives were transformed into security functional components. Their implementation, in the form of technology-dependent security functions, was shown as well.

All these issues were specified precisely and concisely with the patterns defined as the ITSDO knowledge base items (instances) and the relations between these items (properties). The basic examples of these relationships are:

• the parameter and the value substituted to it; for example, most of the threat patterns have parameters: Sparam [4], representing a threat agent and Dparam [4], representing a threatened asset; the given threat pattern expresses a certain group of similar malicious behaviours (attack methods); using the threat pattern, the developer can specify the concrete threat case by substituting these parameters with concrete subjects and/or assets and by adding optionally the TOE-specific details as the threat refinement; the parameter value substitution is implemented with the use of an object type property (Figure 4, the hasThreatAgent and threatenedAsset properties); refinement is expressed, for example, by a data property (Figure 3, threatsRefinem);

• the elementary solution to the elementary security problem; it may concern the assignment of one or more security objectives (for the TOE and/or for the TOE operational environment) to any threat, OSP and/or assumption; it is implemented by non-functional (i.e., having multiple values possible) object properties (Figure 4, the isCounteredBy property, Figure 6, the countersThreat property);

• transforming TOE security objectives into security functional requirements (Figure 6, the isAddressedBySFR property), as well as the implementation of the SFR within the TOE security functions (Figure 7, isImplementedIn) are very similar issues to the above mentioned mapping of the elementary solution to the elementary security problem;

• miscellaneous relations example, like: assigning the EAL level to the TOE design, assigning the implied evidences to the claimed EAL, expressing the security assurance requirements (components) of the given EAL package, and many others.

The data properties are as useful as the object properties. The data properties are used especially to assign textual descriptors to the main ontology items. The refinement operation is based on this property type too (Figures 3 and 5). The MEDIS security target does not use iteration though this operation is possible. The iteration is carried out by placing into the security specification many instances of the same pattern with different parameter values substituted and/or with different refinements.

The validation, focused on the MEDIS security target, concludes that all issues of this security target can be expressed with the knowledge base items derived from the ITSDO ontology. Generally, two IT security development processes variants, i.e., the one based on patterns [4] and the other based on the ontological representation of the patterns, are convergent, but the latter one offers extra advantages related to the ontological approach discussed in the next subsection. The ontological approach allows to elaborate the conceptual security model of the sensor with the use of patterns and relations between them. This model facilitates security analyses supporting the security target work-out.

The ITSDO ontology was shown from the ontology development tool perspective. The readers can see domain concepts and relations through the rather friendly GUI (Graphical User Interface) of this tool. It is good for the experimentations on ontologies (different variants can be checked) but it cannot be used directly by the sensors and security developers (uncontrolled data change possibility). In reality the tool is based on the formal specification of the ontology expressed in the OWL language. To exemplify the ITSDO ontology representation, the paper is supplemented by two simple examples. The readers should be familiar with the basics of the XML, RDF, RDFS (RDF Schema) and OWL notations.

Example 8. The ontology TEO_Generic class representation (please refer to Figure 2, The Class Browser).

A part of the ITSDO ontology presenting the TEO_Generic class is listed below (starting from the <owl:Class rdf:ID=“TEO_Generic”> tag, ending at the </owl:Class> tag). This class is a subclass of TgrGeneric, representing any kind of threat. The class has 2 comments assigned, the first one says that it concerns attacks against the TOE environment, while the second one that formerly this class was called “TIT”. Further we can see that this class is disjointed with the TES_Generic and the TDA_Generic, described elsewhere.

• <owl:Class rdf:ID=“TEO_Generic”>

•   <rdfs:subClassOf>

•   <owl:Class rdf:ID=“TgrGeneric”/>

•   </rdfs:subClassOf>

•   <rdfs:comment rdf:datatype= http://www.w3.org/2001/XMLSchema#string

• >Threats against the TOE operational environment</rdfs:comment>

•   <rdfs:comment rdf:datatype=“ http://www.w3.org/2001/XMLSchema#string”

• >former TIT</rdfs:comment>

•   <owl:disjointWith>

•   <owl:Class rdf:ID=“TES_Generic”/>

•   </owl:disjointWith>

•   <owl:disjointWith>

•   <owl:Class rdf:ID=“TDA_Generic”/>

•   </owl:disjointWith>

• </owl:Class>

Example 9. The hasThreatAgent object property representation (please refer to Figure 4 to see this property).

Please note that this property expresses the relation between any threat (the TgrGeneric class—a domain) and its threat agent, being any subject-type generic (the SgrGeneric class—a range). This relation is inverse to the usedAsThreatAgent relation. The discussed relation belongs to a broader group of relations called objects4SpecMeans.

• <owl:ObjectProperty rdf:about=“#hasThreatAgent”>

• <rdfs:domain rdf:resource=“#TgrGeneric”/>

• <rdfs:range rdf:resource=“#SgrGeneric”/>

• <owl:inverseOf rdf:resource=“#usedAsThreatAgent”/>

• <rdfs:subPropertyOf rdf:resource=“#objects4SpecMeans”/>

• </owl:ObjectProperty>

4.2. Summary Concerning the Elaborated Ontology

The paper presents multidisciplinary research and development works encompassing mainly the security engineering and knowledge engineering domains. The paper presents works focused on the sensor and sensors system security development. The motivation of the paper was to improve the CC-compliant IT security development by applying the knowledge engineering methodology and to support the Common Criteria application in the intelligent sensors development domain, including collaborative sensors applications.

The mentioned improvement may concern the preciseness, consistency and reusability of the CC-compliant IT security development, better design knowledge management and providing this knowledge for developers. All of them are related to the typical advantages brought by the ontological approach [14]:

• The elaborated ITSDO ontology, in the same way as many others, enables common understanding of the terms in the ontology domain, i.e., terms related to the Common Criteria methodology. The paper concerns the IT security development process only, though this ontology is broader and encompasses the evidences and their elaboration as well as management. With respect to the IT security development process, ITSDO defines precisely the security specification structures and the specification means represented here by the CC related security patterns. The relationships between these patterns, like: “counters”, “enforces”, “upholds”, “addresses”, ”implements”, etc. are important too. This common understanding of the structure of information concerns mostly people (i.e., IT security engineers, evaluators, users and other stakeholders, called CC consumers).

• Generally, ontologies facilitate the reuse of domain knowledge. In the considered case, the CC related security patterns (CC—defined components and author’s defined enhanced generics) can be used for other sensors projects. The ITSDO knowledge base can be considered a library of predefined patterns for sensor and sensor system applications.

• ITSDO, similarly to many other ontologies, allows to make explicit assumptions for a domain. It deals mainly with predefined relationships facilitating the security target development, e.g.: mapping a typical solution to the given elementary security problem, mapping typical security functional requirements (SFRs) to the given security objective, proposed implementation of the given SARs by the security function. The predefined relationships are based on the experience gained with previous projects. The developer can use these relationships or can add new ones. These assumptions made with respect to the intelligent sensors security features can be considered an important kind of design knowledge. Generally, the IT security development process is supported by disseminating this experiences-based knowledge to other developers.

• The considered ontology is able to separate domain knowledge (items related to specification means as a whole, designed to use in many different projects) from operational knowledge (how to use this domain knowledge to compose a new security target or protection profile document). It facilitates the automation of the most repeatable activities of the IT security development process.

• ITSDO, as many other ontologies, supports the analyses of the domain knowledge, like supporting a simple risk analysis to consider some variants of security solutions. Generally, it facilitates the automation of the most difficult activities of the IT security development process, though this issue needs further research.

4.3. Future Development and Implementation

The ITSDO ontology and related knowledge base are still under development. This is an iterative and incremental process, beginning with the basic concepts and properties. As more complicated concepts, properties and restrictions are added, the ontology is getting more matured and is able to express more sophisticated relationships and to get answers to more advanced competency questions. These initial efforts are considerable but further automation effects, reusability and preciseness, balance these efforts. Currently the R&D activities are focused on:

• the extension of the reasoning capabilities allowing more sophisticated competency questions;

• the elaboration of subsets of patterns for domains of application other than sensors;

• the ontological representation of the evaluation evidences patterns, concerning evidences elaborated on the ST basis during the IT product or system (TOE) development and provided for the IT security evaluation process.

The validation of the IT security development process ontology-based model with the use of the Protégé tool and the intelligent sensors security domain shows that:

• all advantages and possibilities offered by the ontological approach, summarized in this section, may be achieved with respect to the IT security development process;

• the ontology-based model of the IT security development process fully expresses the developers’ needs and expectations (precise modelling of the complex domain, possibility to elaborate the security target for a given sensor completely, retrieving data to build the TOE security model, reusability); although the ontology encompasses the entire development process and sufficient specification means, the reasoning has not been developed yet but it will be possible in the next version thanks to OWL-DL; requirements related to the reasoning need further research.

The elaboration of the ontology-based model of the IT security development process with the use of the general purpose Protégé tool, along with the experimentation on the model and the intelligent sensors domain, were elements of the feasibility study allowing to define assumptions for the currently elaborated knowledge-base software supporting IT security developers. The readers, such as sensors developers and security developers who are not familiar with the knowledge engineering basics, get an exemplification of their well known security issues in the environment which is quite new for them.

The experimentations with security ontologies are based on the Protégé 3.x version, because it was stable when the experimentation started and it had sufficient possibilities for this purpose. Other OWL-based tools can be used as well, like: Protégé 4.x [5], Semantics works [37], NeOn Toolkit [38], TopBraid Composer [39].

The ITSDO ontology was developed using the tutorial [14] and other documentations of the Protégé community, like [40]. The author wants to point out other references concerning the ontology development, e.g., Staab et al. [41] (the formal basis, tools, approaches in different ontology application domains), W3C consortium documents concerning the semantic web [42] (standards, drafts) and many other publicly available papers and guides on the above mentioned ontology-related tools.

Currently the ITSDO ontology is used as a conceptual model for the CCMODE (Common Criteria compliant, Modular, Open IT security Development Environment) R&D project [34]. The objective of the project, co-financed by the EU within the European Fund of Regional Development, is to work out a CC-compliant methodology and tools to develop and manage development environments of IT security-enhanced products and systems for the purposes of their future certification. The basic products of the CCMODE project will be the following: knowledge, patterns (including documentation, procedures, evidences, specification means, etc.), methodology and tools used to create and manage development environments by different business organizations. The IT products and systems developed in these environments, having measurable assurance (EAL), can be certified and used in high risk applications.

The CCMODE project assumptions and first achieved results were presented at the 11th International Common Criteria Conference [35]. Providing IT security developers with the Common Criteria related security design patterns and knowledge how to use them allows to:

• facilitate and speed up the IT security development process;

• improve the quality of evidences, because they are more consistent and include all details required by the considered assurance components and best practices;

• computer support of the IT security development process.

The results of the R&D on ITSDO are used in the CCMODE project, especially to elaborate knowledge engines, evaluation evidences patterns, and supporting tools. Additionally, these results are used in other IT security related projects to provide solutions which could mitigate risk and ensure business continuity in an organization.

The CCMODE tool will be based on the D2R platform [43] and the broker technology. It allows uniform access to different specialized knowledge bases—one of them will support the IT security development process, others concern the IT product or system elaboration and their evaluation evidences, site-certification issues, selecting the right EAL for the TOE, and the internal organization and management of the entire development environment. The IT security development process is expressed by stereotyped UML classes in the Enterprise Architect tool [44], based on the data (enhanced generics—here discussed, components) retrieved from the knowledge base and dedicated plugin, and provided through the broker. The CCMODE different data are specified in RDF, RDFS, OWL and are identified with the use of URI (Uniform Resource Identifier). Ontologies as the upper layer have been elaborated using the Semantic works [37] tool—the whole system is implemented in the Java technology.

Summing up, the major contribution of the paper is to provide an ontology-based method and tool to elaborate and manage the specific security design patterns for the Common Criteria compliant IT security development. By applying a knowledge engineering approach to the Common Criteria domain, the author’s works aim at providing developers with: design patterns, methodology, tools and related knowledge, which all help to elaborate required security specifications.

The Common Criteria related design patterns were elaborated through the generalization of sensors functionality, architecture, known attacks, policies, etc. [3]. The set of design patterns for security specifications (enhanced generics) was validated on a few examples of sensors. The validations give input for the optimization of this set. Currently it encompasses representative items which are enough to specify security issues of intelligent sensors and sensors collaborating with each other in broader IT systems, though this set is open to new security problems, their solutions and technological advances. The introduced ontological representation of these patterns gives extra advantages brought by this approach. The security of sensors and sensors systems enables their new applications, where risk issues are important.