Computer-Aided Sensor Development Focused on Security Issues

The paper examines intelligent sensor and sensor system development according to the Common Criteria methodology, which is the basic security assurance methodology for IT products and systems. The paper presents how the development process can be supported by software tools, design patterns and knowledge engineering. The automation of this process brings cost-, quality-, and time-related advantages, because the most difficult and most laborious activities are software-supported and the design reusability is growing. The paper includes a short introduction to the Common Criteria methodology and its sensor-related applications. In the experimental section the computer-supported and patterns-based IT security development process is presented using the example of an intelligent methane detection sensor. This process is supported by an ontology-based tool for security modeling and analyses. The verified and justified models are transferred straight to the security target specification representing security requirements for the IT product. The novelty of the paper is to provide a patterns-based and computer-aided methodology for the sensors development with a view to achieving their IT security assurance. The paper summarizes the validation experiment focused on this methodology adapted for the sensors system development, and presents directions of future research.


Introduction
The paper is focused on the security aspects of intelligent sensors. Generally, sensors are devices for measuring certain physical quantities and converting results into signals readable format for the observer or instrument. Additionally, intelligent sensors are able to process measured values. Intelligent sensors include sensor-, processing-, communicating facilities, and sometimes actuators. They can work autonomously or can be connected forming complex structures like sensor networks or systems. A sensor system can be a part of a more complex IT system. Apart from intelligent sensors, there are also smart sensors. To review the topic of how to distinguish intelligent sensors from smart ones [1], in this paper the author focuses on sensors which have IT product attributes, i.e., the ability to process, store and transfer information. Such devices are equipped with microcontrollers. For these specific IT products information security is the key issue. Sensor and sensor system complexity and maturity have been growing and new sensor applications are emerging all the time. Intelligent sensors and sensor systems are extremely important to fulfil social and business objectives, including security-and safety-related objectives in many application domains, such as patient monitoring [2], the Internet of Things [3], smart cities [4], etc. Apart from public areas, like health services, services offered by the government, border control, communal applications, these solutions are crucial for high risk environments in the military sector,

Basic Common Criteria Methodology Terms Used in the Article
The Common Criteria methodology uses specific terms. An IT product is called a target of evaluation (TOE). It can be a hardware, software or IT system.
The second part of [6] contains components representing elementary security functional requirements (SFRs). They are used to express the behaviour of the TOE security functions, which represent countermeasures. The third part of [6] includes components expressing elementary security assurance requirements (SARs) for these security functions. Both sets of components, grouped by families, and families by classes, constitute a semiformal "language" to uniformly express security requirements for IT products.
Assurance is measured with the use of evaluation assurance levels (in the range EAL1 to EAL7). The assurance depends on the rigour applied to the security development process. The more rigorous is this process, the more precise are the applied engineering good practices (security analyses, testing, documentation), and the better is the organization of the development/production/maintenance environment-the more assurance has the IT product (the CC assurance paradigm). The given EAL represents the coherent package of security assurance requirements. The Common Criteria methodology [6] comprises three basic processes:

‚
The IT security development process, focused on the security analyses; the document called ST (security target) for the given TOE is worked out; the ST contains: TOE overview and description sections; Security problem definition (SPD), which specifies: the protected assets, subjects, threats, organizational security policies (OSPs), and security assumptions for the TOE; Security objectives (SO) presenting how the security problem specified by the SPD is solved; the SO expresses generally the proposed security measures; Security requirements (SFRs and SARs) present these solutions using the semiformal CC components; TOE security functions for ST (TSF); they are the SFR implementation on the claimed EAL level; ‚ The TOE development process, focused on the elaboration of the CC-specific IT product documentation, embracing: TOE architecture, its functional specification, design, security policy, implementation; Live cycle definition, configuration management, product delivery, development process security, used tools and their options; Tests specification, test depth and coverage; Product manuals and procedures; Vulnerability assessment of the TOE and its development site; ‚ The IT security evaluation process; it is performed by an independent, accredited security lab and finalized by certification; during this process the TOE and its evidences, i.e., ST and the TOE documentation, are evaluated according to the CC methodology against the claimed EAL.
A protection profile (PP) can be considered a generic form of a security target. It provides an implementation independent specification of information assurance security requirements. Its content is similar to that of ST (SPD, SO, SFRs/SARs, no TSF), but more general. PPs are evaluated and registered. Security targets are developed on their basis.

Current State of the Research Field
The review is focused on three basic issues related to the paper:

‚
Common Criteria application in sensors and sensors systems development; ‚ Patterns in security development; ‚ Computer support of the Common Criteria methodology.
During the review the author identified papers and reports related to the Common Criteria methodology used in the sensors and sensors networks development and a certain number of examples. The most relevant of them concern: ‚ General sensors network security aspects; ‚ Healthcare systems; ‚ Aircraft health monitoring systems; ‚ Safety-critical assets distribution systems; ‚ Transport, including motion sensors of digital tachographs; ‚ Products related to SCADA (Supervisory Control And Data Acquisition); ‚ Specialized firewalls used in control and automation systems, co-operating with sensors networks.
Reference [16] concerns the analysis of wireless sensor network (WSN) security, based on the regulations intended for wireless communication devices, like EN 50150 and MIL STD-188-220. It discusses WSN attacks, security measures countering these attacks, and provides a security evaluation and classification methodology for WSN protocols. The Common Criteria methodology is proposed as the validation methodology of security countermeasures in WSN systems. The countermeasures sufficiency (SFRs-based) and correctness (SARs-based) are evaluated. The countermeasures, identified as security objectives, are expressed with the use of the selected SFRs, e.g., "Source and destination identifier in each message" countermeasure is represented by the component of the CC families: FCO_NRO (Non-repudiation of origin), and "Membership control-bus guardian" by FIA_UID (User identification).
A book chapter [17] is focused on the security and privacy issue in healthcare systems, including sensors and wireless sensors networks. The security and privacy threats are mapped to the commonly used countermeasures. The countermeasures are discussed with respect to the limitation of the sensors networks, for which it is difficult to apply advanced cryptographic techniques. It was remarked that assurance relies on engineering practices, development processes, operational issues, and can be evaluated according to the Common Criteria methodology.
The first group of examples deals with e-Enabled aircraft [18]. The e-Enabled approach concerns the latest generation of airplanes and is applied to improve the safety and efficiency of air travel. Common Criteria is used for the security analysis of an EDS system, identifying threats, deriving security objectives, requirements and security functions. This way the electronic distribution of software, cryptographic key and data between airplane and ground systems is secured. The system is based on the Public Key Infrastructure (PKI) services and digital signatures.
The paper [19] focuses on the use of wireless sensor networks (WSNs) for AHMMS. AHMMS is used:

‚
To monitor the health of airplane structures and board systems, which use embedded sensors; ‚ To give timely feedback to the flight control computer working on the board and to the airline ground server for health assessment.
The paper [20] concerns the Airplane Assets Distribution System (AADS). Assets encompass an authorized software (e.g., safety standards compliant software, firmware for intelligent sensors) and contents (data, security related data, unique identifiers, cryptographic keys, etc.) exchanged between airplanes and manufacturers, owners and servicers. Common Criteria is used for the security analysis of the communication channel between airplanes systems and between the airplane and the ground system. Similar communication channels are used in the automotive industry to load assets, i.e., software or contents, to different embedded electronic control units in vehicles [21], tachographs, their motion sensors [22], etc.
The Common Criteria methodology can help to solve some difficult problems identified during research [21], like: building of the specialized high-assurance PKI, the use of formal methods for an end-to-end analysis of assets distribution systems, removing vulnerabilities and analyzing the impact of security on safety.
The digital tachograph system [22,23] consists of a vehicle unit, motion sensor and a smart card used to log in to this unit. The Common Criteria standard is used to evaluate the security of tachograph systems [24][25][26].
The presentation [27] concerns protection against mileage frauds in cars and features a concept how to solve this problem. The Common Criteria methodology will be used to secure a communication channel from the ABS sensor to the car cockpit. The protection profile for an odometer is planned.
The paper [28] discusses a new generation of SCADA systems used to control virtual utilities, aggregating distributed resources, like microgrids, wind farms, fuel cells, etc. into single, centralized energy systems. Intelligent sensors can be used in control systems (field controllers) cooperating with SCADA. The author suggests that SCADA products should be evaluated with the use of the Common Criteria standard to avoid compromising the security or safety by these products. Security problems of SCADA are growing because SCADA products are often parts of critical information infrastructures.
The National Institute of Standards and Technology (NIST), in coordination with the Process Control Security Requirements Forum (PCSRF), initiated a research programme aimed at the risk reduction in industrial control systems based on the Common Criteria methodology [29]. The research results were IT security specifications for process control systems in the shape of a protection profile "System Protection Profile-Industrial Control Systems Version 1.0" [30].
The Common Criteria methodology is used in motion sensors [22]. For the above mentioned examples Common Criteria is used to secure systems co-operating with sensors systems.
The Common Criteria methodology is rarely used in the sensor and sensor system certification process directly. Among many certified IT products (more than 2000) and registered protection profiles (more than 300) only few concern directly sensors and sensors systems, i.e., motion sensors for digital tachographs and industrial control systems including sensors. There are also IT products indirectly related to sensors (the TOE does not comprise sensors), e.g., sensors systems supporting an IT product or working in its environment. Apart from these, the Common Criteria methodology is used for non-commercial purposes, but they are not well documented.
The Common Criteria methodology is used as a development and evaluation methodology of sensors-related IT solutions, including very responsible products. Relevant examples were shown above. This situation is enforced by the current stage of the market development and is typical of the emerging domains of application of the Common Criteria methodology. The above mentioned papers present a need to use Common Criteria in the sensors systems development process. None of them presents the complete, CC-based development process. They do not mention evidence patterns or computer support either.
Design patterns can be understood as reusable, proven solutions to problems with respect to a specific context in the given domain of application [31]. The patterns include knowledge how to get this expected solution. The patterns are also used in the information technology, including its security. They may concern requirements, design and implementation [32]. They are specified in a formalized way, using different kinds of codes, models, ontologies, formalized descriptors, etc.
In [10,11] the author has defined the term "Common Criteria related security design patterns", in compliance with the general patterns definition, but expressing the CC-specific issues, i.e., different specification items, like CC-defined SFR/SAR components, as well as semiformal enhanced generics introduced by author. The CCMODE project [15] uses these patterns and introduces new ones, related to the evaluation evidences (documents) implied by SARs. Such a comprehensive set of patterns was a novel element, allowing for the automation of the evidences elaboration process.
The paper [33] discusses the extension of the problem frame method to perform the CC-related security analyses. The supporting tool, based on UML/OCL (Unified Modeling Language/Object Constraint Language), is used (UML4PF) to perform modelling and analyses. The attacker model considering different attacker types was introduced. The method is focused on the security problem definition, and on this basis, the security objectives identification.
Generally, to elaborate security targets, protection profiles and other evidences, developers are equipped with some guidelines, like: ISO/IEC 15446 [34]-for ST/PP or BSI guide [35]-for evidences up to EAL5. Some valuable practical hints about the evidence preparation, co-operation with external experts, work valuations and the certification itself are available in [9]. However, these guidelines have a general character and do not give any patterns to prepare the evidences.
There are a few software tools which support the development of evidences. The first and most known is Common Criteria (CC) Toolbox TM [36], supporting the security target and protection profiles development.
GEST-a similar generator of security target templates is presented in [37]. It is based on the evaluated and certified security targets.
Trusted Labs Security Editing Tool (TL SET) [38] helps the developer in writing and maintaining the security target and protection profiles according to CC. It also allows one to automatically generate documents in different formats.
Please note that these tools are focused on the ST and PP preparation only and do not support the elaboration of other evidence, e.g., dealing with the TOE design, life cycle, guidance, testing, vulnerability assessment. They are based on text processing and data bases and do not use advanced modelling or knowledge bases.
The sensors and sensors systems developers do not make sufficient use of the Common Criteria methodology. The sensors systems development is an emerging CC domain of application. In the emerging domains there are different barriers, like a lack of knowledge, tools and exemplars, low market demand, etc. Developers need some support. It can be provided by computer-aided specialized tools.

Research Motivation and Directions
The research presented in the paper is placed in the mainstream of research focused on the CC methodology implementation and improvement. This methodology is mature but is still being improved in the range of raising the design quality, facilitating the development and evaluation processes, decreasing the development cost and time. The general motivation of the author's works is:

‚
To improve the IT security development process, thanks to the patterns-based approach; ‚ To minimize the barriers for developers, related to the lack of knowledge, methods and exemplars of evidences, etc.; But the works presented in the paper are focused on the secure sensors and sensors systems development. The research presented in the paper uses three kinds of input:

‚
Theoretical foundation included in the author's monograph [39], which includes the UML extension (stereotypes) to specify models of the IT security development framework in a formal way (syntax and semantics defined on mathematical principles), and the security models related to this framework (data and activity diagrams);

‚
The CCMODE project products [15]: methodology, tool and knowledge, to adapt them for the sensors systems domain of application; ‚ The research results from [10][11][12], to elaborate a library of predefined semiformal specification means for this domain.
The developed patterns-based, computer-aided methodology for sensor development is a novelty of this paper. The first kind of patterns encompasses evidences required by particular security assurance components on different EAL levels. The patterns are structured documents with predefined fields ready to be filled in with content related to the IT product and required by the Common Criteria standard. The developer is guided in elaborating evidence on the pattern basis. The second kind of patterns embraces predefined specification items-semiformal Common Criteria language-including not only components for the security requirements specification stage, but also enhanced generics defined by the author for other development stages. Thanks to the patterns, the evidence elaboration is easier and the evidence quality rises. Additional advantages are obtained by the automation of the evidence elaboration. The evidence content is introduced by the developer or is generated by the specialized document generator, which uses data from analytic/design aiding tools, knowledge base and the CC-related project management software. The software tool accelerates the evidence development and ensures the content reusability.
The paper contributes to the sensors systems development by providing specialized, means and tools which comply with Common Criteria and rise quality and security assurance in this domain, particularly:

‚
Patterns and tools to implement this methodology, adapted to the sensors development domain; ‚ Knowledge concerning the Common Criteria assurance methodology and the sensors security.
The paper contains four sections: Section 1, above, discusses the Common Criteria basic issues, state of the art in the research domain, existing gaps and motivation for research. Section 2-the experimental section of the paper-presents the context and course of the validation experiment. Section 3 summarizes the achieved research results. Section 4 contains the conclusions of the paper.

Experimental Section
The experimental section provides a short introduction to the validation experiment, presenting shortly CCMODE Tools, implemented evaluation documents patterns and specification means patterns, the adaptation of the tool to sensor domain of application, and the validation plan. The validation experiment encompasses the tool setup according to the sensor project needs and the computer-aided ST development. The section concludes next steps to obtain a full design of the intelligent sensor. The validation experiment refers to the MEDIS sensor project described in [11].

General Features of CCMODE Tools
CCMODE Tools is a specialized Computer-Aided Engineering (CAE) system focused on the Common Criteria-based IT product development. It supports even the most laborious and difficult operations in the IT product development process. Figure 1 shows the basic modules of CCMODE Tools [15]. "Environment Management Tool" (EMT) is the main module and the central entry point to CCMODE Tools. This is a specialized project manager focused on the Common Criteria related projects. It is responsible for the initialization/configuring of projects and their management in the life cycle. The project configuration complies with the chosen EAL package. The right evaluation evidence patterns (considering the additional or substituted SARs) are attached and the needed external tools are connected. Based on the Lightweight (Directory Access Protocol/Active Directory DAP/AD) EMT manages roles and users. For each project the life cycle, its phases, and processes are defined with the use of the predefined templates. EMT manages different project data, elaborated evidences, and different artefacts, e.g., implementation representation (code, electronic schemes), documentation, regulations, subcontractors, etc. This is also the entry point to other components shown in Figure 1. Using the D2RQ [40] technology, EMT integrates logically all CCMODE Tools components.
The "Knowledge base" module manages the project knowledge and the CC-related knowledge. It includes the Common Criteria contents stored in the structured way, systems dictionaries, predefined patterns, security models, predefined life cycle models, and project-related data. It provides a context-sensitive help.
The "GenDoc-Evidences generation" (Microsoft Word ® -based) module is designed to work out evidences on the basis of predefined patterns. The patterns are implemented as MS Word templates supported by software. GenDoc is the basic developer's application. The developer, guided by the system, uses it directly and introduces basic contents to the given pattern to produce the corresponding evidence. A very helpful feature is that the contents can be loaded from the "Environment Management Tool" (EMT) is the main module and the central entry point to CCMODE Tools. This is a specialized project manager focused on the Common Criteria related projects. It is responsible for the initialization/configuring of projects and their management in the life cycle. The project configuration complies with the chosen EAL package. The right evaluation evidence patterns (considering the additional or substituted SARs) are attached and the needed external tools are connected. Based on the Lightweight (Directory Access Protocol/Active Directory DAP/AD) EMT manages roles and users. For each project the life cycle, its phases, and processes are defined with the use of the predefined templates. EMT manages different project data, elaborated evidences, and different artefacts, e.g., implementation representation (code, electronic schemes), documentation, regulations, subcontractors, etc. This is also the entry point to other components shown in Figure 1. Using the D2RQ [40] technology, EMT integrates logically all CCMODE Tools components.
The "Knowledge base" module manages the project knowledge and the CC-related knowledge. It includes the Common Criteria contents stored in the structured way, systems dictionaries, predefined patterns, security models, predefined life cycle models, and project-related data. It provides a context-sensitive help.
The "GenDoc-Evidences generation" (Microsoft Word ® -based) module is designed to work out evidences on the basis of predefined patterns. The patterns are implemented as MS Word templates supported by software. GenDoc is the basic developer's application. The developer, guided by the system, uses it directly and introduces basic contents to the given pattern to produce the corresponding evidence. A very helpful feature is that the contents can be loaded from the knowledge base and/or external systems (predefined values, analyses results). GenDoc allows to print the elaborated evidences or to generate empty patterns in the Microsoft Word ® format, which can be used outside GenDoc.
The "Security analysis/modelling" module is based on a plugin developed for Sparx Systems Enterprise Architect ® (EA). EA is a broadly used UML tool. The EA-plugin is used for security analyses and security modelling. The results are injected to the elaborated security targets or protection profiles. In addition, the EA-plugin provides input to evidences related to the decomposition, interfaces and tests of the IT product.
The "Artefact versioning" module is based on the Subversion/SVN software [41]. It is responsible for versioning the project artefacts (including evidences). It supports configuration management according to the given EAL.
The "Bug tracking/Flaw remediation" module is based on the Redmine software [42]. It is used for bug tracking during the project progress and for flaws remediation according to Common Criteria (implementation of the ALC_FLR family requirements) after certification.
The "Test management" module is based on the Testlink software [43]. It is used for the tests development and management. It contains test plans and scenarios. It helps to specify functional tests and evidences related to the test depth and coverage.
The "Self-Assessment" module includes full implementation of the Common Criteria Evaluation Methodology (CEM). It can be used as a self-assessment, auxiliary tool by developers or it can be used separately by evaluators. It also contains auditing facilities which allow to assess conformance of the development environments with different standards, including CC.
CCMODE Tools supports traditional CC-related projects as well as site certification [44] projects.

Evaluation Evidences Patterns Implemented in CCMODE Tools
Developers should submit an IT product (TOE) and a set of evidences to an independent evaluation lab supervised by one of the Common Criteria certification bodies, which operates according to the Common Criteria Recognition Arrangement (CCRA) [7].
Evaluation evidences embrace: ‚ Documentation, e.g., configuration management plan; ‚ Documented results of independent investigations or observations conducted by the evaluators, e.g., a TOE vulnerability analysis report; ‚ Described behaviour or activities of people according to their roles in the TOE life cycle.
CCMODE Tools is equipped with a set of evaluation evidences patterns for all assurance components. Table 1 lists patterns related to the IT security development process. The most important is the Security Target pattern. It will be used as the basis for any sensor/sensors system project. The TOE development process is based on two groups of patterns: those related to the environment (Table 2) where the IT product is developed and those related to the IT product itself (Table 3). Please note that Tables 2 and 3 specify pattern families only, each SAR component has a dedicated pattern and the pattern names comply with assurance family names [6].   The items specified in Tables 2 and 3 can be considered a short review of issues embraced by the Common Criteria standard.
Some of these patterns will be exemplified during validation.

Specification Means Patterns Implemented in CCMODE Tools
The above patterns specify structured documents whose elaboration is guided by the tool. Most of these patterns are filled in with a text with tables and graphics, however patterns shown in Table 1 need, additionally, semiformal specification means, i.e., SFRs and SARs from CC and other descriptors defined by users and called "generics". The author proposes [39] "enhanced generics". They are defined as mnemonic names expressing common features, behaviours or actions related to IT security issues, like: subjects, objects, threats, assumptions, security policies, security objectives, and functions. They are "enhanced" since they are semiformal and have features comparable to CC components, allowing such operations as: parameterization, derivation, iteration, and refinement.
An enhanced generic consists of four textual fields separated by dots, and the fourth field Refinement is optional: Family.Mnemonic.Description.Refinement The Family field expresses the generics taxonomy. The following groups are distinguished: ‚ Assets representing passive entities within the considered system, divided into subcategories: -TOE related assets-marked DTO, -Assets within the TOE operational environment (DEO), ‚ Subjects, representing active entities related to the TOE or its operational environment, including: -Authorized subjects (SAU), e.g., user, administrator, process, -Unauthorized entity (SNA), e.g., intruder, -Non-human malicious entity (SNH), e.g., force majeure, failure, This version is marked "Enhanced generics rev.3.1". When compared with the rev.3.0 [11], the new version has the generics related to the development site and security functions removed.
The Mnemonic field expresses very briefly, in a few letters, the generic meaning.
The Description field contains one or a few sentences about the generic meaning, i.e., the security features, behaviours or actions. Description can be supplemented by the optional Refinement field, e.g., DTO.SensorID.Unique identification number of an intelligent sensor.Identifier stored in a distinguished register written during the manufacturing process.
Please note that the fields are separated by dots.
The Description field may have parameters in square brackets which represent any asset [Dparam] or any subject [Sparam]. The parameters may be left empty (meaning: "any possible") or substituted (symbol: "<=") by an appropriate asset or subject generic. Such parameterization enables iteratation of the enhanced generics. Here the given generics can be placed many times into the specifications with different parameters substituted which present different aspects of the same security issue. For example, a threat item with different-potential intruders attacking the same asset, or a threat with one intruder who attacks different assets, each one differently. Particular instances of the iterated enhanced generic are numbered with consecutive numbers placed in brackets.
The paper [10] was focused on the identification of security issues for different kinds of sensors and sensors systems, according to the needs of the Common Criteria methodology. These issues encompass:

‚
Different kinds of protected assets: -Basic assets, i.e., sampled, processed, stored and transmitted data, and provided services, -Assets whose availability allows the right operation of sensors (please note the restricted resources: energy, processing-and transmission capability), -Security-related data, e.g., cryptographic keys, passwords, credentials, secrets, -Assets placed within the TOE operational environment, encompassing all co-operating and mutually related IT entities, e.g., network gateways, monitoring central unit, common data base, ‚ Active entities (subjects): -Legal users of a sensor or sensor system, user, admin, process, -Legal actors participating in the life cycle processes performed within the site, service personnel, All identified elementary issues were expressed by the enhanced generics, which play a role of specification items (in a form of a library) for sensor development, considered one of the CC application domains. The developers choose the right, project-relevant subset of the enhanced generics, refine them by substituting values with parameters values and by adding additional explanations related to the project context. The paper presents one of possible examples of the sensors-related generics, selected for a concrete IT product (MethSens). The example is based on the existing design presented in the paper [11]. Please note that only project-relevant items were used.
Examples of enhanced generics can be found in [10][11][12], and their ontological representations in the [12,25]. Enhanced generics defined for the intelligent sensors domain [11] will be implemented in the CCMODE Tools adaptation.

Adaptation of CCMODE Tools to Sensors and Sensors Systems Domain of Applications
The Common Criteria standard and CCMODE Tools can be used for a broad range of IT products. With respect to evidences, no adaptation is required-the configuration according to the EAL requirements and the used external tools are enough. It was assumed that for the validation purpose the Redmine and Testlink tools will not be connected.
The adaptation is focused on the elaboration of the set of enhanced generics dedicated to intelligent sensors. Most of them were defined in the paper [11,12] (the author encourages reading these papers and taking into consideration the proposed taxonomy and nomenclature of the enhanced generics) and these will be the basis for the CCMODE Tools implementation. In CCMODE Tools generics are included in the knowledge base and the EA-plugin is used to operate on them. EA-plugin is based on ITSDO [12], but uses the Simple Knowledge Organization System (SKOS) [45] technology allowing decision support during the IT security development process, e.g., to propose the most adequate countermeasures to cover the given threat. It will be exemplified during the validation experiment.

Range of the Validation Experiment
The validation concerns the MethSens sensor which refers to the Methane Early Detection Intelligent Sensor (MEDIS) presented in [11]. The validation is focused on the key issues related to the IT security development of the MethSens: ‚ CCMODE Tools configuration for the MethSens project; ‚ IT security modeling of the MethSens with the use of EA-plugin; ‚ Injecting this model to the MethSens Security Target using GenDoc application.

CCMODE Tools Configuration for the MethSens Project
To start security analyses and the elaboration of evidences, CCMODE Tools should be configured (setup) according to the project needs. The MethSens project setup encompasses the following actions:

‚
Introducing basic information about the project, like: project type, TOE name and acronym, involved organizations, project roles and actors, subcontractors, etc.; ‚ Configuring connections and working parameters of external modules, like SVN, EA, MS Word, Redmine, Testlink; some tools are optional; ‚ Selecting the right evaluation assurance level (EAL) for the TOE; components of the EAL are automatically joined to the project; it is possible to perform substitution (replacing one or more components of the given EAL by more rigorous ones) and augmentation (adding one or more component to these implied by the EAL); these two cases are distinguished by "+", e.g.,: EAL2+; developers can define their own components; ‚ Defining the IT product life cycle and its phases, processes, actors; some life cycles are predefined in the tool; for MethSens a standard life cycle (with phases: Development, Manufacturing, Operation and maintenance, End of life) was applied; ‚ Specifying software tools and hardware tools, especially those whose configuration parameters influence the IT product; concerns the "ALC_TAT-Tools and techniques" family requirements [6]; ‚ Specifying tools related to the TOE configuration management; concerns the ALC_CMC, ALC_CMS families [6]; ‚ Setting repository paths pointing at different project artefacts, e.g.,: source files, configuration lists and their items, regulations, etc. Figure 2 shows screenshots examples of the MethSens project configuration using the tool. Please note the horizontal menu on the left and the vertical ones-both presenting different project operations. For the MethSens TOE, EAL2 is applied. The listed EAL2 SARs can be augmented and/or substituted. On the second, red-framed window, evidences for MethSens/EAL2 are listed along with CC components corresponding to them. During the project these evidences will be worked out, i.e., filled in with the contents elaborated by the user or by supporting tools, like EA, EMT. The paper is focused on the security target elaboration (the last position on the evidences list).
The security target elaboration in GenDoc is preceded by the MethSens security model building, verification and justification with the use of the EA-plugin.
Please note the horizontal menu on the left and the vertical ones-both presenting different project operations. For the MethSens TOE, EAL2 is applied. The listed EAL2 SARs can be augmented and/or substituted. On the second, red-framed window, evidences for MethSens/EAL2 are listed along with CC components corresponding to them. During the project these evidences will be worked out, i.e., filled in with the contents elaborated by the user or by supporting tools, like EA, EMT. The paper is focused on the security target elaboration (the last position on the evidences list). The security target elaboration in GenDoc is preceded by the MethSens security model building, verification and justification with the use of the EA-plugin.

Security Model of the MethSens Device
The security model, after development, justification and verification will be injected into the security target document. The model includes the basic artefacts created during the IT security development: security problem definition (SPD), security objectives (SO), security functional requirements (SFR) and TOE security functions (TSF).
The paper shows how the MethSens security model development is supported by the EA-plugin. Enterprise Architect is a well-known UML modelling tool. The CCMODE EA-plugin extends its functionality:

Security Model of the MethSens Device
The security model, after development, justification and verification will be injected into the security target document. The model includes the basic artefacts created during the IT security development: security problem definition (SPD), security objectives (SO), security functional requirements (SFR) and TOE security functions (TSF).
The paper shows how the MethSens security model development is supported by the EA-plugin. Enterprise Architect is a well-known UML modelling tool. The CCMODE EA-plugin extends its functionality:

Security Problem Definition (SPD)-Threats, Organizational Security Policies and Assumptions
The security problem definition encompasses identification of threats impacting the TOE, organizational security policies (OSPs) which the TOE should comply with to be secure, and assumptions for the TOE operational environment. It is preceded by the identification of assets protected by the TOE and different subjects operating on the TOE and its operational environment. To build the security model, the enhanced generics and the relationships between them (like: threatens, counters, covers, upheld, etc.) will be used, defined in according to Common Criteria [11,12].
The general view of the elaborated security model is shown in the middle of Figure 3, more precisely, only a part of the security problem definition is presented (SPD_MethSensorST diagram). The parts of the security target, like security objectives, security requirements and TOE security functions are placed on other, logically connected diagrams (SO_MethSensorST, SFR-TSF_MethSensorST). On the left part of the window, the developer's toolbox is shown. It includes the UML class stereotypes (rectangles) and relationships (arrows) predefined for the Common Criteria development. They can be drag-and-dropped on the diagram and then refined. On the right part of the figure, the MethSens model artefacts are listed, like diagrams and their elements.
The presented model is rather complicated (seven protected assets marked "D", six subjects marked "S", nine threats "T", four OSPs, and three assumptions "A", let alone derived security objectives, requirements and functions). It is impossible to present the entire project here. The paper exemplifies the key issue of the security model development only. Please note that to comply with the version 3.1 of Common Criteria, only the generics related to the operation phase of the sensor life cycle are considered in the MethSens project (selected from the MEDIS sensor project [11]). The generics related to the development phase and compliant with the CC ver. 2.x are omitted.
Please note the TOE:MethSensor class on the top and four protected assets belonging to it: DTO.SensorData, DTO.SensorService, DTO.NodePowerRes, DTO.SensorID (please refer to their descriptions in the paper [11]). The assets: DTO.CentralUnit, DTO.Co-operatEquip(2), DTO.Co-operatEquip(2) belong to the ENV:MethSens class representing the TOE environment (not shown). Each asset class has two optional and auxiliary classes D F and D T representing the assets form (shared, presented, stored, processed, produced, transmitted) and type (e.g.,: data protected by the product, user's private data, hardware, software, user's identification data, events log of the product, cryptographic key, and many others). These additional attributes, together with the threats, OSPs, and assumptions properties, are used to propose adequate security objectives by the knowledge engine.
Two threats related to the TOE will be discussed here on a more detailed level. They represent elementary security problems, whose resolution will be shown later.

Example 1
The TOE asset DTO.SensorData categorized as D F "processed" and D T "data protected by product" is threatened by the unauthorized SNH.HighPotIntruder according to the TOE direct attack TDA.Access threat scenario. Figure 3 presents relations between UML stereotyped classes representing generics (marked with thick red lines), like st_form, st_threatens and st_has. Figure 4, in turn, shows properties of these generics. Please note the threat scenario and two risk-related parameters: Likelihood of the threat and Possible loss when the threat occurs ( Figure 4A). Together with Value of protected asset ( Figure 4C), they allow to calculate risk, i.e., and in the consequence they allow to rank the threats by risk. Using this rank security objectives is more adequate to solve the security problem (will be discussed later).
The DTO.SensorData generic includes detailed description as well-please compare it with [11]. The unauthorized SNH.HighPotIntruder subject ( Figure 4B) has a description expressing the role of the intruder (a threat agent in the CC nomenclature) in the risk scenario, and three parameters Potential, Knowledge, Motivation characterizing the agent. These issues are important when the TOE vulnerability is assessed by evaluators (AVA_VAN family [6]).

Example 2
The second example is very similar and concerns an attack against the sensor identifier, which leads to spoofing. DTO.SensorID categorized as D F "stored" and D T "product identification data" is also threatened by SNH.HighPotIntruder according to the TDA.ReplaceNode threat scenario. Please note the relations in Figure 3 (marked with thick green lines) between classes representing generics. Figure 5 shows properties of these generics.
The above mentioned threat generics were selected from the list of items predefined for sensors. The EA-plugin allows to create threat generics semi-automatically, based on dialogue forms. The developer is asked about different features of the threat, threatened asset and threat agent. On this basis a complete scenario is made and, finally, the generic is placed on a diagram. This option will not be discussed in this paper. Sensors 2016, 16, x   The DTO.SensorData generic includes detailed description as well-please compare it with [11]. The unauthorized SNH.HighPotIntruder subject ( Figure 4B) has a description expressing the role of the intruder (a threat agent in the CC nomenclature) in the risk scenario, and three parameters Potential, Knowledge, Motivation characterizing the agent. These issues are important when the TOE vulnerability is assessed by evaluators (AVA_VAN family [6]).

Example 2
The second example is very similar and concerns an attack against the sensor identifier, which leads to spoofing. DTO.SensorID categorized as DF "stored" and DT "product identification data" is also threatened by SNH.HighPotIntruder according to the TDA.ReplaceNode threat scenario. Please note the relations in Figure 3 (marked with thick green lines) between classes representing generics. Figure 5 shows properties of these generics.
The above mentioned threat generics were selected from the list of items predefined for sensors. The EA-plugin allows to create threat generics semi-automatically, based on dialogue forms. The developer is asked about different features of the threat, threatened asset and threat agent. On this basis a complete scenario is made and, finally, the generic is placed on a diagram. This option will not be discussed in this paper.

Security Objectives (SO)-Solving the Security Problem
Security objectives express the proposed security measures by means of semiformal descriptors-enhanced generics. To build the SO specification, one can use ready-made generics from the library or generics defined semi-automatically on the basis of threats, OSPs, assumptions (only for the operational environment), subjects and assess their properties. This selection is based on the CCMODE ontology (SKOS) implemented within EA-plugin.  Each security objective generic has associated different properties related to its character (means/ways to solve a security problem, e.g., access control) and properties inherited from the countered threat, enforced OSP, upheld assumption, related assets (specified by DT, DF) and subjects (subject_type). Using the set of properties, the SKOS-type ontology proposes a ranked list of security objectives to be used to solve the given problem. Figure 6 shows the security objective selection supported by the SKOS ontology implemented in EA-plugin. Please note some propositions, some

Security Objectives (SO)-Solving the Security Problem
Security objectives express the proposed security measures by means of semiformal descriptors-enhanced generics. To build the SO specification, one can use ready-made generics from the library or generics defined semi-automatically on the basis of threats, OSPs, assumptions (only for the operational environment), subjects and assess their properties. This selection is based on the CCMODE ontology (SKOS) implemented within EA-plugin.
Each security objective generic has associated different properties related to its character (means/ways to solve a security problem, e.g., access control) and properties inherited from the countered threat, enforced OSP, upheld assumption, related assets (specified by D T , D F ) and subjects (subject_type). Using the set of properties, the SKOS-type ontology proposes a ranked list of security objectives to be used to solve the given problem. Figure 6 shows the security objective selection supported by the SKOS ontology implemented in EA-plugin. Please note some propositions, some more preferable (score = 2), some less (score = 1). Figure 7 shows the SO_MethSensorST diagram presenting how the security problem is solved by selecting right security objectives for the TOE and its environment. Generally, the TOE objectives (marked "O") counter threats and/or cover OSPs. The TOE environment objectives (marked "OE"), which support the TOE objectives, counter threats and/or cover OSPs and/or uphold assumptions [6].

Security Functional Requirements (SFR)-Semiformal Representation of the Security Objectives
Security objectives describe the solution of the security problem in an informal developer's language, with the use of enhanced generics. Generics are semiformal but they contain informal descriptors of security measures, which may be subjective, because descriptors are created by particular developers. To describe any security measure in a non-subjective, unified way, semiformal SFR components are defined in the Common Criteria standard.
Each security objective should be translated (mapped) to one or more SFR components selected from Part 2 of the Common Criteria standard [6]. Figure 8 presents the mapping process of security functional requirements to security objectives. All SFRs are implemented in the CCMODE knowledge base in the form of a hierarchical tree: classes-families-components, i.e., in the same way as they are placed in the Common Criteria SFRs catalogue ([6]/Part 2). As it was mentioned earlier, the given security objective has many properties associated, including means and ways of the security problem solution, e.g., access control, inherited properties of a countered threat or an enforced OSP, even inherited properties of involved assets and subjects. Based on these security objectives, security functional components are proposed, selected from the hierarchical tree.
To the given security objective a right component is assigned with some dependent components (if they exist and are required in the given circumstances). Please note that for the OACC.Access objective the FDP_ACC.1 (Subset access control) component is selected. It has a dependent component FDP_ACF.1 (Security attribute based access control) which requires its own dependent component to be selected, i.e., FMT_MSA.3 (Static attribute initialization) [6]. This selection is strongly supported by CCMODE Tools. The developer selects some dependencies for implementation and rejects others as irrelevant in the given circumstances. When all security objectives have SFRs mapped and their dependencies are solved, the security functional requirements specification is ready. At this stage the security model needed for the protection profile is finalized. For the security target the next step is required. The SFRs are grouped and assigned to the defined TOE security functions (TSFs) to be implemented in the IT product at the claimed EAL level. This way the TOE summary specification (TSS) is worked out. It is shown on Figure 9 as well. The particular TSFs are expressed by rectangles embracing their relevant SFRs.    The TSS preparation completes the security model elaboration needed for the security target.

MethSens Security Target Elaboration
The security model of the sensor can be injected into the right sections of the security target evidence elaborated on the pattern basis. Figure 10 shows a part of the model representing security objectives to be injected to the relevant section of the ST. Please note the structure of the pattern (and the evidence) on the left.      Figure 11. Part of the security target automatically elaborated on the basis of the security model with the use of the CCMODE GenDoc application. Figure 11. Part of the security target automatically elaborated on the basis of the security model with the use of the CCMODE GenDoc application.
During the evidence elaboration the developer can check how this evidence will be evaluated in the security testing lab. This checking is called here self-evaluation, CCMODE Tools includes the full implementation of the Common Evaluation Methodology for Information Technology Security (CEM) [46].
According to the Common Criteria standard each SAR component includes three kinds of elements: The evaluation application is presented in Figure 12. On the left side there is a tree with the assessed work units implied by particular evaluators' actions elements. Each of 61 work units should have a verdict assigned with justification. Possible verdicts are: pass, fail, inconclusive. They are shown on the statistics diagram. The assessed section of the security target is displayed in the central bottom part. Above, the corresponding work unit (on the left) and the relevant SAR component (on the right) are shown-precisely, the contents and presentation element. Please note that the evaluator is equipped with complete information allowing to assign a verdict.

Other Evaluation Evidences for the MethSens Device
Other required evidences implied by the EAL are elaborated in the same way but this issue is beyond the scope of the paper. These evidences cover the TOE development process and concern:  TOE architecture, its functional specification, design, security policy, implementation (ADV class);  Life cycle definition, configuration management, product delivery, development process security, used tools and their options (ALC class);  Tests specification, test depth and coverage (ATE class);  Product manuals and procedures (AGD class); Vulnerability assessment of the TOE and its development site (AVA class).

Results and Discussion
The Common Criteria standard presents a renowned and matured security assurance methodology used for different categories of IT products and systems. The most popular CC certified products are: smart cards and devices related to them, network devices, multifunction devices, operating systems, boundary devices, and digital signature devices [7]. The developers representing these CC application domains are very experienced, and equipped with supporting methods and tools. There are some specific IT products and systems which are problematic for their developers, and the number of evaluated/certified solutions is very low. This is due to existing barriers and generally low experience in the use of Common Criteria by IT product developers. Simply, the developers find it difficult to transform the specific technical language of the IT product domain to the specific language of Common Criteria which is used to elaborate the evaluation evidences as the input in the certification process. The intelligent sensors and sensors systems domain is an example of such IT products domain (a niche domain) and the use of the CC methodology in it is very scarce (Section 1.2).
Sensor developers need some help, including the knowledge how to understand the CC nomenclature and to use it as well as supporting tools and design patterns to overcome most of the Self-evaluation of the MethSens security target presented by the CCMODE GenDoc application.
The statistics show progress of the evaluation process. This application is designed for evaluation labs, although developers can use it optionally.

Other Evaluation Evidences for the MethSens Device
Other required evidences implied by the EAL are elaborated in the same way but this issue is beyond the scope of the paper. These evidences cover the TOE development process and concern: ‚ TOE architecture, its functional specification, design, security policy, implementation (ADV class); ‚ Life cycle definition, configuration management, product delivery, development process security, used tools and their options (ALC class); ‚ Tests specification, test depth and coverage (ATE class); ‚ Product manuals and procedures (AGD class); Vulnerability assessment of the TOE and its development site (AVA class).

Results and Discussion
The Common Criteria standard presents a renowned and matured security assurance methodology used for different categories of IT products and systems. The most popular CC certified products are: smart cards and devices related to them, network devices, multifunction devices, operating systems, boundary devices, and digital signature devices [7]. The developers representing these CC application domains are very experienced, and equipped with supporting methods and tools. There are some specific IT products and systems which are problematic for their developers, and the number of evaluated/certified solutions is very low. This is due to existing barriers and generally low experience in the use of Common Criteria by IT product developers. Simply, the developers find it difficult to transform the specific technical language of the IT product domain to the specific language of Common Criteria which is used to elaborate the evaluation evidences as the input in the certification process. The intelligent sensors and sensors systems domain is an example of such IT products domain (a niche domain) and the use of the CC methodology in it is very scarce (Section 1.2).
Sensor developers need some help, including the knowledge how to understand the CC nomenclature and to use it as well as supporting tools and design patterns to overcome most of the existing difficulties. The CCMODE Tools suite [15] offers such support for typical IT products or systems. This is a specialized, Common Criteria compliant, patterns-and knowledge engineering-based, computer-aided engineering system. There is no straightforward answer to the question whether this suite can be helpful in the sensor domain. To settle it, the validation experiment was planned and performed. The aim of the validation experiment is to assess:

‚
If it is possible to adapt this suite for the specific sensors application domain in order to support sensors developers; ‚ Whether the extended customized suite could be useful for intelligent sensors and systems developers.

Validation Context
This assessment is performed through the validation experiment, discussed in Section 2. The main experiment was preceded by a short presentation of the customized tool and the context of the experiment. The CCMODE Tools suite was configured to enable the following: The test manager (Testlink) and the bug tracking tool (Redmine) were not used in the experiment, but generally there is no obstacle to use it in sensors projects. The validation experiment was based on the MethSens sensor with well identified project data, based on the MEDIS sensor project described in [11].
EAL2 was claimed for the MethSens device, as mentioned above. The validation experiment is focused on the security target (ST) elaboration, as the most important evaluation evidence and the basis for other TOE-related evidences. The security target is the same (the same ASE class components) for any of the EAL2-EAL7 levels. From the perspective of the validation experiment, the claimed EAL is irrelevant, because the EAL does not influence the TSFs shape, but the developed TSFs should be implemented on the claimed EAL. The claimed EAL influences the TOE-related evidences-not discussed, only mentioned in the paper. Generally, the EAL selection for the IT product is a much more complicated issue. Different factors may influence this selection:

‚
Law enforcement-some products, especially for government-like applications, should have the given EAL (an arbitrary decision); ‚ Market requirements (trade-off based on market-related factors).
When EAL is selected for an IT product which is to be placed on the market, the trade-off between cost and assurance should be done. A higher EAL means higher rigour is applied (more assurance components which include more rigour), and the higher rigour means a higher cost of development and evaluation. In addition, the product range and complexity influence this cost. Customers may not accept such a high price of the product.
On the other hand, the customers may refuse to acquire IT products for responsible applications (high value of protected assets, high risk) with too low claimed assurance levels. The customers may not accept such products because they do not meet their needs.

Conclusion 1
The range of the experiment encompassed all typical developers' activities. The assumed EAL2 is rather low, though according to the author's subjective opinion, it is adequate (security assurance vs. costs) for many sensors applications. Apart from the security target (ASE), it implies 10 evidence documents related to: the sensor architecture (ADV_ARC), decomposition (ADV_TDS), interfaces (ADV_FSP), configuration management (ALC_CMC, ALC_CMS), delivery procedures (ALC_DEL), preparative procedures (AGD_PRE), operational user guidance (AGD_OPE), functional tests (ATE_FUN), test coverage (ATE_COV), which ought to be delivered by the developers. From the research perspective the most difficult and interesting is the security target, others concern rather routine and practical issues.
The object of the validation experiment, i.e., MethSens, is representative but not trivial. MethSens comprises many diversified security issues: diversified architecture, assets, threats, policies, objectives, requirements and functions. For this reason the validation can be considered comprehensive and representative for the discussed domain of application.

Range of Development Suite Customization
Considering the evidences patterns, there is no need to perform any adaptation, because patterns are implied by assurance components and do not depend on the category of the IT product or system. The CCMODE offers transparent, domain-independent patterns.
A more complex situation emerges with specification means patterns. There are two groups of them. The first group encompasses security functional requirements which are defined in the CC standard and are directly implemented in the CCMODE knowledge base. No adaptation is needed either.
The second, very diversified group of specification means, depends strongly on the IT product category. There were no sensors-specific generics implemented in the CCMODE. There was a need to define and include in the knowledge base the generics specific for intelligent sensors and sensors systems. Such generics were identified in the author's previous work [11]. During the validation these generics were verified, sometimes modified (all changes were marked in violet in Figure 3, Figure 7) and introduced into the CCMODE knowledge base. This way CCMODE Tools was prepared to be used in a new domain of application.

Conclusion 2
The adaptation of CCMODE Tools was restricted to the implementation of enhanced generics specific for sensors. The specialized domain library of generics was implemented.

Course of Validation Experiment
The paper does not present the elaboration of all EAL2 evidences but only the most important and difficult elements of the security target. The developers usually have trouble with security analyses, modelling, rationale, and with the right contents and coherency of evidences. The first issue is solved by applying the EA-plugin, the second by evidence patterns and GenDoc, supported by other CCMODE Tools components.
All IT security development process stages were exemplified by means of the EA-plugin. In addition, it was shown how to specify particular issues using enhanced generics or CC components, how to solve the security problem, how to express the problem solution by security functional requirements, how to work out security functions, and how to justify particular development stages. The developed security model was injected into the security target by the GenDoc application. Each change within the model was also illustrated on line in the elaborated evidence. Each evidence is implied by its pattern and the pattern is compliant with the corresponding security assurance requirements. This way the developer, guided by software, is fully focused on the IT product and does not preoccupy with the composing evidences the scratch. It was shown on the example related to the security objectives justification.

Conclusion 3
The validation experiment encompasses all activities considered difficult or laborious by developers. These activities were supported by the software tool which made these activities much more easier. The data common for all evidences, e.g., different names, identifiers, are managed by EMT. Project artefacts are versioned and stored by SVN. The analyses/modelling/justifications are supported by the EA-plugin. The evidences are semi-automatically generated by GenDoc.

Self-Assessment-Useful Optional Step
The validation experiment pays attention to an optional activity-the developer is able to perform the evaluation of his/her work in the similar way as it will be done later in the evaluation lab. It is called here self-assessment and it usually encompasses issues which are difficult and require proper interpretation. The developer has direct access to the relevant evaluation work units and can see how the given issue will be assessed by evaluators according to CEM [46]. It was shown on some examples related to the security objectives rationale.

Conclusion 4
The validation experiment encompasses an optional step related to the self-assessment of the given issue of the elaborated evidence. This is a general, non-sensor specific functionality of CCMODE Tools. The validation experiment stimulates the supplementation of CCMODE Tools with elements allowing its application in the sensor domain. The IT security development and the TOE development processes are fully supported by this suite.

Conclusions
The paper concerns security assurance in the context of intelligent sensors and sensor systems. Security assurance is understood here according to the paradigm expressed by the Common Criteria methodology. This methodology is mature, broadly used, but still improving, because some parties consider it difficult, laborious, costly and generating huge documentation. The discussion seems to be endless, but in fact, no other methodology is able to replace Common Criteria now, or even to simplify it. Efforts to enhance it, to support it, to make it more friendly for developers seem to be still purposeful. This paper follows this statement.
There are about 2089 CC-certified IT products and 173 registered protection profiles now [7] but their distribution by product categories is irregular. Some application domains can be considered niche domains. Sensors are one of them. The answer to the question "why?" may be complicated. The causes may be: low market demand, no strong requirements implied by laws, difficulties in applying the CC methodology in this specific domain of application, low security awareness, low CC-related knowledge among the sensors developers, etc.
Additionally, the review of the research field (Section 1.2) shows that the Common Criteria applications for sensors and sensors networks are scarce but they embrace very important cases, like: healthcare systems, aircraft health monitoring systems, safety-critical assets distribution systems, transport, including motion sensors of digital tachographs, and SCADA-related products.
This shows that the sensors systems development is an emerging CC domain of application. There exist different barriers in such emerging domains. To overcome them, it is necessary to disseminate knowledge about Common Criteria in the sensor developer community, provide the developers with dedicated methods, design patterns and tools.
At the beginning of the research the author assumed that it is possible to design a Common Criteria compliant security assurance suite dedicated to the development of intelligent sensors and sensors systems. The author's motivation was to help the sensors systems developers in the implementation of the Common Criteria methodology.
The objectives of the research presented in the paper were: ‚ To adapt the general-purpose CCMODE methodology and its supporting tools to the needs of the intelligent sensors and sensors networks domain; ‚ To disseminate CC-related knowledge in this domain.

Research Findings and Implications
To assess the feasibility of the above mentioned concept the validation experiment was performed. It was assumed that:

‚
The development suite dedicated for sensors will be based on the general purpose, ready-made platform-CCMODE Tools;

‚
The feasibility study will be based on the representative sensor MethSens/EAL2.
The validation experiment embraces three basic Common Criteria processes, though only some essential issues were exemplified in the paper.
For the IT security development process, the most important and difficult activities were performed to assess the concept feasibility:

‚
The security modelling and rationale-supported by the EA-plugin;

‚
The patterns-and tools-based semi-automatic generation of evidences (replacing the old laborious, manual elaboration of evidences)-the MethSens security target generated by the GenDoc application; ‚ The sensors-specific security specification work out-a set of enhanced generics was predefined in the CCMODE knowledge base and some of them were used to specify the MethSens security model.
The TOE development process embraces the elaboration of different evidences documents. They were generated as empty documents on the basis of patterns of the EMT application according to EAL2 (Figure 2). The TOE development process evidences were not fully exemplified because they are less complicated than the above discussed security target.
The TOE evaluation process is performed in accredited evaluation labs. CCMODE Tools includes the CEM implementation which is able to perform similar evaluation, but understood as self-evaluation. The developers can check optionally how certain evidences or their parts will be evaluated with the use of CEM work units.
The conclusion is that CCMODE Tools can be adapted to the sensor domain of application mainly by the extensions of the specification means library (sensor-specific enhanced generics). The adapted suite can support sensor developers in all development activities. The knowledge acquired during the validation experiments can be used by sensor developers in their projects.

Paper Contribution and Future Research
The paper contribution embraces the adapted patterns-based computer-aided methodology for the sensors development. This methodology has an innovative character and goes beyond the sensors domain. It concerns any IT product development, improves the product quality and security assurance. It is achieved by:

‚
Better project management-thanks to the Common Criteria compliant, IT security development framework equipped with the domain knowledge base, design patterns, defined development processes, life cycle models, supporting tools, and communication facilities; ‚ Automation of IT product development process-complex and laborious activities are supported by software tools; this way it is possible to achieve the project reusability and other advantages similar to those gained in the CAE systems.
The CCMODE Tools suite was used for several kinds of IT products, like: data diodes [47], different sensors, RFID devices. The CCMODE Tools suite is very useful in the development processes, though it needs more validation in different application domains. The CCMODE Tools methodology is still enhanced based on the feedback from running projects and validations.
The author is involved in research going beyond the Common Criteria methodology, especially research on new security assurance paradigms, including the Trustless Computing initiative [48]. It is "a global initiative for the creation, from existing open components, of the World's most user trustworthy general-purpose end-2-end computing service platform, lifecycle, open ecosystem and international certification body, aggregating world class partners and advisors." The author's research objective is to consider how to extend the CCMODE methodology by new security assurance paradigms.