Common Criteria Related Security Design Patterns—Validation on the Intelligent Sensor Example Designed for Mine Environment

The paper discusses the security issues of intelligent sensors that are able to measure and process data and communicate with other information technology (IT) devices or systems. Such sensors are often used in high risk applications. To improve their robustness, the sensor systems should be developed in a restricted way to provide them with assurance. One of assurance creation methodologies is Common Criteria (ISO/IEC 15408), used for IT products and systems. The contribution of the paper is a Common Criteria compliant and pattern-based method for the intelligent sensors security development. The paper concisely presents this method and its evaluation for the sensor detecting methane in a mine, focusing on the security problem of the intelligent sensor definition and solution. The aim of the validation is to evaluate and improve the introduced method.


Introduction
The paper concerns the intelligent sensor security development methodology compliant with ISO/IEC 15408 Common Criteria (CC) [1]. This standard provides assurance for the designed information technology (IT) product or system. Assurance means that the product or system meets its security objectives. In other words, it means that the implemented measures will be able to counter threats when they occur. The sources of assurance are the rigor applied during development and manufacturing processes, independent third-party evaluations as well as operation and maintenance OPEN ACCESS according to the obtained certificate. These specially developed and evaluated IT products (hardware, software, firmware) and systems can be applied in a higher risk environment. The CC methodology has been broadly used for years. More than a thousand certification processes were completed and the certificates deal with varied products or systems [2].
Generally, sensors are devices that measure a physical quantity and convert it into a signal, which can be read by an observer or instrument. A number of such devices contain actuators. Intelligent sensors are able to process measured values and may be organized in sensor systems. They use network technology for integration, including the wireless one. With respect to the CC methodology, intelligent sensors can be considered as IT products. They have hardware and software components, co-operate with other IT systems and, first and foremost, the IT inherent risks should be considered for them.
The number of intelligent sensors implementations is growing, though the number of finalized Common Criteria certification processes of these IT products is relatively low. The intelligent sensor systems application can be discussed as one of the emerging application domains of the Common Criteria standard.
The motivation of this paper is to provide the developers with knowledge and a set of validated design patterns related to the application of the Common Criteria methodology to the intelligent sensors development. This can help them in a broader use of this methodology in dependable sensor solutions, including sensors designed for the mine environment.
This paper is a continuation of [3], which includes:  the primer of the Common Criteria standard designed for sensor systems developers;  the review of the author's earlier researches leading to the elaboration of a CC-based, IT security development method focused on the intelligent sensors and sensor systems;  the discussion of architectures, applications and security issues of intelligent sensors and sensor systems; reviewed security works, focused on attack analysis and an advanced security mechanism, do not provide a method of implementation of these mechanisms with the use of assurance methods, for example Common Criteria; this discussion allows to propose two models: a generalized intelligent sensor model and, related to it, CC-compliant intelligent sensor security model;  the Common Criteria related security design patterns, elaborated on the basis of the exhaustive analysis of security features and behaviors of different kinds of sensors working within varied operational environments; these patterns can be used to fulfil the security model with contents specific to a given sensor;  the validation of this set of patterns on the intelligent medical sensor example elaborated on the basis of the [4] paper. The elaborated Common Criteria related security design patterns (shortly: "CC-related patterns") [3] should be validated on varied sensors projects to optimize this set and its particular items. The set should contain necessary and sufficient items to express common security features and behaviors of intelligent sensors in their most representative application domains. Particular items should have a general, universal meaning, allowing their use in a broad range of applications. Thanks to introduced operations on patterns (called "enhanced generics", explained later), like: refinement, parameterization or iteration, different details can be added to their contents, allowing them to address very specific security issues. To elaborate an adequate, optimized set of patterns, different validations on varied projects are planned. More optimized patterns improve the usability and quality of designs.
The contribution of the paper, related to the [3] contribution, is to provide a CC-compliant, pattern-based IT security development method focused on intelligent sensors.
The objectives of the paper are:  to provide a complete, concise description of the pattern-based method,  method validation on the example of the intelligent sensor detecting methane in a mine,  method improvement based on the validation results.
The indirect, far-reaching objective is to provide such improved, ordered patterns and related knowledge to a broader group of developers of intelligent sensors or sensor systems designed for high risk environments.
The elaboration of CC-related patterns requires validations on varied projects. Currently, two validations are being finalized: the motion sensor of digital tachographs [5] and the medical sensor remotely monitoring patients [3]. This paper presents another project example-the intelligent sensor detecting methane in the coal mine environment.
The paper includes the following key sections. Section 2 provides a general introduction to the Common Criteria IT security development process, presenting the CC methodology background and the author's researches on the automation of this process. Section 3 reviews the author's provided CC-compliant method of intelligent sensors security development. The section presents a general sensor model, its security model and a set of predefined Common Criteria related security design patterns to fulfil this security model with contents specific to the elaborated type of the sensor. The central part of the paper is Section 4 which presents a method validation on the intelligent sensor detecting methane. It is shown how the predefined patterns can be applied to work out the intelligent sensor security specification. Section 5 concludes the validation example and summarizes the methodology as a whole.

Common Criteria Compliant IT Security Development
The security patterns evaluated here are closely related to the assurance methodology specified in the Common Criteria standard (ISO/IEC 15408). This methodology can be applied to provide dependable IT products or systems for applications, where the assessed, IT inherent risk is significant.
Assurance, measurable in the range EAL1 to EAL7, is identified as the confidence that an IT product or system meets security objectives specified for it. In other words, it means that the built-in security functions related to these objectives and representing measures will work effectively whenever a threat occurs. The source of assurance is rigorous development and independent evaluation, so these IT products or systems are called TOE (target of evaluation). The development encompasses two processes.
The first process, called the IT security development, summarized in the security target (ST) specification includes seven stages [1]/Part 1, but the following five are most relevant:  Work-out of the "ST introduction", containing different identifiers, informal TOE overview and TOE description;  Security problem definition (SPD); SPD specified threats, OSPs (organizational security policies) and assumptions for the TOE and its operational environment;  Solution of this problem by specifying security objectives (SO)-for the TOE and its operational environment;  Work-out of the security functional requirements (SFRs) specification on the security objectives basis, and the set of security assurance requirements (SARs) which are derived mainly from the declared EAL;  Creating the TOE summary specification, including the TOE security functions derived from the SFRs; they are implemented in the TOE on the claimed EAL during the TOE development process. The paper concerns the first three issues and discusses how to specify elaborated TOE on general level, how to specify the security problem and its solution using the predefined CC-related patterns. Please note that the security target for the TOE [1]/Part 1 can be considered as a security model of the developed IT product or system. Here discussed security patterns concern SPD and SO. For security functions some patterns are predefined too, but only briefly mentioned in the paper. Security functional components [1]/Part 2 and security assurance components [1]/Part 3 play a role of patterns for the security requirements (SFRs, SARs).
The second above mentioned development process, called the TOE development process, is responsible for the implementation and documentation of the elaborated security functions (specified in the ST) on the claimed EAL. Evidences deal with:  TOE architecture, its functional specification, design, security policy, implementation,  life 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 TOE, ST, and related documentation (evidences) are provided for the independent evaluation process, finalized by getting a CC certificate for the IT product or system with respect the claimed EAL [2]. More information about the CC methodology can be found in [2], [3]/Section 3 and in the books [6,7]. Table 1 contains the explanation of the terms and acronyms often used in the paper.  trusted IT product An IT product other than the TOE which has its security functional requirements administratively coordinated with the TOE and which is assumed to enforce its security functional requirements correctly (e.g., by being separately evaluated).
trusted path A means by which a user and a TSF can communicate with necessary confidence.
The paper is related to the author's more extensive works aiming at the improvement and automation of the CC methodology by introducing a semiformal description, supporting software tools and by using the knowledge engineering methodology, discussed also in [3]. First, a Common Criteria compliant, UML/OCL-based IT security development framework (ITSDF) [7][8][9] was elaborated. The framework encompasses:  models of data structures and processes of IT security development stages,  models of the specification means used for these IT security development stages, including CC components and the author's defined semiformal enhanced generics. The introduced enhanced generics play a role of here discussed CC-related design patterns. They are derived from "generics" commonly used by developers, but are more formalized and can be implemented in software tools. An enhanced generic is defined as a mnemonic name expressing common features, behaviors or actions related to the IT security development process, i.e., subjects and other active entities, assets and other passive entities, 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.
There are about 350 predefined enhanced generics and they can be applied for commonly used IT products or systems, but the intelligent sensors or their systems, as specific IT products, are not represented there. The CC-related design patterns for this emerging domain of the Common Criteria standard application has been elaborated [3,5], and this paper discusses their validation on the intelligent methane sensor for mines.

Use of the Common Criteria Related Security Design Patterns for the Intelligent Sensors Development-Concise Method Presentation
The term "Common Criteria related security design patterns", introduced in [3], needs certain explanation to distinguish them from commonly used design patterns or security design patterns. The CC-related patterns are security design patterns of specific character. They are focused on Common Criteria compliant IT security development, not on IT secure solutions.
Generally, design patterns are reusable, proven solutions to problems with respect to a specific context. They are often used by engineers in many technology domains, including IT-and IT security domains. The patterns provide knowledge and are related to the process that allows achieving the expected solution. Numerous patterns concern software architecture. The patterns are specified in a formalized way, e.g., using UML (Unified Modeling Language) optionally supported by OCL (Object Constraints Language), using different kinds of codes, ontologies, formalized descriptors, etc.
The general overview of the software security patterns is presented in [10], which is focused rather on the survey of approaches to security patterns than on the presentation of patterns for given applications. Security patterns are categorized with respect to the software life cycle phases:  the requirements phase-patterns, e.g., for assets valuation, vulnerabilities and threats assessment, for supporting identification of the security requirements being a part of the system requirements,  the design phase-patterns related to decisions on conceptual architecture, allowing to select solution variants, concerning: identification, access control, data transfer, audit, non-repudiation, etc.  the implementation phase-to develop secure software without implementation flaws; secure coding techniques and specialized knowledge are provided, which can be considered as security patterns too. Categorized software patterns, including security patterns, may be placed into repositories available for software developers. In the paper [10] the patterns effectiveness, usability, quality, sufficiency for designs are discussed as well.
The book [11] summarizes researches on the UML extension called UMLsec, providing a unified approach to security features description during the secure systems development. UMLsec can be used to evaluate UML specifications against vulnerabilities. The established formal rules of security engineering can be encapsulated, and hence made available to a wider group of developers. UMLsec allows definition of the UML patterns that encapsulate the design knowledge in the form of recurring design problems, and consist of the "pattern name", "problem description", "problem solution" and "consequences". These patterns deal with many security engineering solutions, like: secure channel, TLS Internet protocol, electronic purse, secure Java programs, bank applications, biometric authentication systems, electronic signature, etc. These works focus on modeling IT security features and behavior within the system, and not on the IT security development process compliant with the Common Criteria standard. Relationships between CC-related patterns presented by the author of this paper and the UMLsec patterns defined in [11] are discussed in the monograph [7]. Please note that patterns are a commonly used term in the UML world.
The book [12] presents security design patterns related software solutions, which can be mostly considered as architectural patterns. These solutions, mainly related to enterprise management applications, may concern e.g., 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. Regarding the Common Criteria methodology, this kind of security design patterns is related to the security functions implemented within an IT product or system.
Here discussed security patterns and the method of their implementation are closely related to the risk issue, i.e., assets, legal subjects, attackers, threats, security policies, assumptions and security objectives, of the Common Criteria compliant IT security development process.
To sum up, the presented Common Criteria related security design patterns can be considered as a specialized kind of design patterns because:  they concern the design process (called here IT security development),  they can be used in many projects (i.e., they are reusable) but in a certain context (i.e., in the CC-methodology context). Generally, the patterns represented by the enhanced generics (Section 2) can be applied for different kinds of IT products or systems but the paper is focused only on the patterns subset related to sensors and sensor networks.

General Intelligent Sensor Model
The CC methodology needs a subject for discussion, i.e., an IT product or system being analyzed and secured during the IT security development process. This "subject" is expressed by the generalized IT product or system model, here the "intelligent sensor model", characterizing a broader group of such sensors.
The initial stage of the IT security development process is the "ST introduction", containing:  the "TOE overview", presenting the "TOE Usage and major security features", "TOE type" and "Required hardware-, software-or firmware elements in the TOE environment",  the "TOE description" presenting the "Physical scope of the TOE" and "Logical scope of the TOE". The discussed intelligent sensors security development method should present how to specify these issues for a broader class of these devices. Reviewing scientific and technical papers, standards, security targets of certified products, technical documentations of leading providers and application notes, the common features of the intelligent sensors and sensor systems are identified and specified in the form of a general intelligent sensor model co-operating with other hardware or software entities of its operational environment. This way, a general, block scheme level model is developed, which creates the context for further security analyses leading to the security functions work-out. The considered general model of the intelligent sensor includes the following elements ( Figure 1    "microcontroller, equipped with a specialized operating system, communication and application software, different devices, such as memories, including non-volatile memories, interfaces, timers, counters, sometimes other coprocessors (e.g., crypto-processors, network processors and other specialized processors), interfaces to external memories, and other devices (I 2 C, SPI),  low-power transducers (varied sensing/controlling devices),  communication facilities, including low-power wireless facilities or traditional/industrial network interfaces (wired, optical facilities),  power source (battery, solar, external sources)".
Please note that the intelligent sensor is able to measure physical values, process them and communicate with other co-operating nodes and end-user applications. Optionally, intelligent sensors are provided with actuators. Restricted resources related to processing, transmission and energy should be considered during security analyses, because restrictions influence negatively the sensor capability.
The general model can be used as a reference model for a broader class of considered intelligent sensors. The important issue is to identify what parts belong to the TOE (it depends on the project) and what parts co-operate with the TOE, being elements of its operational environment. This abstract level should be enough to present boundaries of the TOE, which elements are parts of the TOE, and which are parts of its operational environment. Moreover, this model can be used as a background to present the basic TOE user's functionality, protected assets, their owners, intruders, threats, security policies, connectivity aspects, and security objectives.

Notation of the CC-Related Security Design Patterns
The author's defined enhanced generics [7][8][9] play a role of CC-related security design patterns. This notation concerns all kinds of IT products or systems, not only intelligent sensors. To make the reading of this paper easier, let us refer to the enhanced generics notation from [3], which is very similar to the notation of the security components (SFR/SAR) specified in the [1] standard.
In comparison with the patterns specification in [3], the following changes of the enhanced generics semantics were provided:  the "TOE IT environment" is understood as the "TOE operational environment", including IT-, physical-, personnel-and organizational aspects of this environment;  the former "TOE physical environment" concerns the development-, manufacturing-and maintenance processes performed within the certain "site", which may be distributed or not.
The TOE operational environment encompasses technical and procedural facilities in the TOE neighborhood, enabling the TOE operation, including measures assisting the TOE in correctly providing its security functionality [1]/Part1.
The "site" can be considered as the certain TOE environment, placed "far from the TOE" but logically related to it, because the TOE was developed and manufactured there and the TOE can be maintained there. The site can be distributed or not and it encompasses technical and procedural facilities enabling the TOE development-, manufacturing-and maintenance processes. It should include measures protecting these processes. Removing vulnerabilities related to the site processes, influences positively the TOE in the operational environment.
This revision improves generally the compatibility with the latest Common Criteria 3.1 version, according to which the ST security analyses are focused on the TOE and its operational environment only. Different security issues related to the development-, manufacturing-and maintenance processes should not be explicitly specified, as in the older security targets, e.g., [13,14].
In the presented method, the security issues dealing with the site processes can be specified optionally, being useful in the security models considering all phases of the life cycle model, not only the operational phase. The full life cycle model is convenient for the IT products like RFID/smart cards and sensors, and is compliant with the latest researches on the site certification [15]. It is useful to consider the security issues related to the site e.g., assets, threats, assumptions, etc., or sometimes it is even required for the above mentioned IT products. Unsolved security problems in the site may cause security problems for the TOE. The optionally identified security problems concerning the development-, manufacturing-and maintenance processes are considered in the TOE development process with respect to the assurance requirements included in the assurance families: ALC_DVS (Life-cycle-Development security) and AVA_VAN (Vulnerability assessment-Vulnerability analysis) Due to the performed changes, a complete, revised specification of the enhanced generics is here provided (denoted in author's project as the "Enhanced generics rev.3.0"). An enhanced generic consists of four textual fields separated by dots, and the fourth field Refinement is optional:

Field Expressing Generics Family
There are several items in the Family field. Each security model issue, like: assets, subjects, threats, etc., has its own possible values. Families are represented by particular mnemonic prefixes.
The CC-defined functional paradigm [1]/Part 2 says that an asset represents a passive entity within the considered system. The Family field for assets (data, services, software, IT infrastructure, documents, etc.) begins with "D", and the following values are allowed (the symbol "|" means "or"): Family ::= DTO | DEO | DES. Family semantics for passive entities is defined in Table 2. Table 2. Family field defining assets and other passive entities.
The following prefixes are defined for threats: Family ::= TDA | TEO | TES. Family semantics for threats are presented in Table 4. Table 4. Family field defining threats.

Prefix
Meaning "TDA" "direct attacks against the TOE" "TEO" (former "TIT") "attacks against the TOE operational environment" "TES" (former "TPH") "attacks against the TOE site" Assumptions, addressed to the TOE operational environment and optionally to the site, have prefixes, expressing aspects: Family ::= ACN | APR | APH. Family semantics related assumptions are defined in Table 5. Table 5. Family field concerning assumptions.
It should be noted that enhanced generics may express security functions as well. The paper does not discuss their elaboration, but they will be included below in Table 7 to present a complete set of predefined enhanced generics used as CC-related design patterns. Prefixes of the security functions begin with the letter "S", and further include a CC functional class name which the given function deals with, e.g., for the "FAU" class (audit), the security functions have the "SFAU" prefix. For the security functions the following prefixes are defined: Family ::= SFAU |SFCO |SFCS |SFDP |SFIA |SFMT |SFPR |SFPT |SFRU |SFTA |SFTP. Family semantics for security functions are described in Table 7. Table 7. Family field related to the security functions.

Prefix
Meaning "SFAU" "security functions dealing with audit" "SFCO" "security functions dealing with communication" "SFCS" "security functions dealing with cryptographic support" "SFDP" "security functions dealing with user data protection" "SFIA" "security functions dealing with identification and authentication" "SFMT" "security functions dealing with security management" "SFPR" "security functions dealing with privacy issues" "SFPT" "security functions dealing with the protection of the TSF" "SFRU" "security functions dealing with resource utilization" "SFTA" "security functions dealing with the TOE access" "SFTP" "security functions dealing with trusted path/channels"

Field Expressing the Mnemonics of a Generic
The second enhanced generics field, developers-defined Mnemonic, expresses very briefly, in a few letters, the generic meaning (see examples below in Tables 8-16).

Field Presenting Description (Meaning) of the Generics
The Description field presents concisely, in one or few sentences, the generic meaning, i.e., the security features, behavior or actions. This field may have parameters in square brackets representing any asset [Dparam] or any subject [Sparam]. Parameters may be left empty (meaning: "any possible") or substituted (symbol: "<=") by an appropriate asset or subject generic. Parameterization enables to perform the iteration of enhanced generics. In this case the given generics can be placed many times into the specifications with different parameters substituted, and presenting different aspects of the same issue. For example, the threat item with intruders of different potential attacking the same asset, or the threat with one intruder attacking different assets in a different way. Particular instances of the iterated enhanced generic are numbered and their consecutive numbers are in brackets.

Field Refinement Supplementing Description of Generics
Please note that the content of the Description field is predefined for enhanced generics placed in a tool library or knowledge base. If the given generics are used in the project, some extra information can be added on the project level by means of the last, optional field, called Refinement. As it was the case with CC components, this word is placed below the generic description as an underlined word Refinement, which will be shown in the examples below (subsections: 4.2−4.4).

The CC-Related Security Design Patterns Defined for the Intelligent Sensor Application Domain
The above presented enhanced generics notation is used for generics of different application domains and these generics can be considered here as CC-related design patterns for a given domain.
The CC-related design patterns for the intelligent sensor and sensors system domain were defined in the paper [3] and validated on the medical sensor example. Different security issues were analyzed and generalized into the form of particular generics. The following inputs discussed there in details were used:  broad range of publications discussing the WSN (Wireless Sensor Networks) specific problems and solutions, like: known methods of attacks, resource limitations, architectures and software constraints, application specific issues for MANET (Mobile Ad-hoc Network) and VANET (Vehicular Ad-hoc Networks),  publications presenting emerging Common Criteria applications dealing with airplane health monitoring systems, safety-critical assets distribution systems, motion sensors of digital tachographs, SCADA (Supervisory Control And Data Acquisition) related products and specialized firewalls used in control and automation systems, co-operating with sensor networks,  publications concerning intelligent sensors working autonomously or integrated using the traditional network technology (a cooper wire, a fibre optic),  security targets of certified IT product or systems, used life cycle models for different IT products,  papers and security targets devoted to the smartcard and RFID (Radio Frequency Identification) technologies; this is a mature domain of the Common Criteria application but security problems are very similar to the intelligent sensors domain, considered as an emerging one. On this basis, a set of Common Criteria related security design patterns were elaborated. They are grouped according to categories existing in the IT security development process, i.e., assets, subjects, threats, etc., presented in separate subsections below.

Patterns Expressing Assets and Other Passive Entities
According to the CC functional paradigm [1]/Part 2, assets are passive entities which should be protected by the TOE. Assets can be included in the TOE, e.g., secret key within the sensor microcontroller internal register, or can be placed outside of the TOE, e.g., the data sampled by sensors and stored in the data base placed in the WSN base station. Assets are managed by authorized active entities (owners, users, administrators) or attacked by unauthorized active entities (intruders)-both entities represented in the method by subjects-discussed in the next subsection. Assets may have values assigned to assess risk (optional) when threats occur. Assets are used as parameters values in other generics, except subjects, especially in threats and OSPs. Assets may be sampled, processed, stored or transmitted data, services provided, IT elements or physical elements.  Table 8 presents enhanced generics expressing different kinds of intelligent sensor assets:  basic assets, i.e., data sampled, processed, stored and transmitted, and the provided services,  assets whose availability allows the right operation of sensors (please note the restricted resources-energy, processing-and transmission capability),  security-related data,  assets placed within the TOE operational environment, encompassing all co-operating and mutually related IT entities,  assets related to the TOE development-, manufacturing-and maintenance processes, encompassed by the life cycle model, placed "somewhere far" from the TOE, i.e., in the site (considered optionally).

Patterns Expressing Subjects and Other Active Entities
According to the CC functional paradigm [1]/Part 2, the active entities are distinguished. They express varied "actors" operating around the TOE. Most of them are subjects, having their own logical representations within the TOE, i.e., legal users/asset owners (human users, or non-human users, e.g., processes). Apart from legal users, the intruders trying to breach or destroy the protected assets are identified. Legal users may also breach assets, intentionally or not. Additionally, special kinds of intruders representing non-human entities, events or actions causing incidents are considered.
The most important subject related to the intelligent sensor system represents a sensor user, who/which can take different forms depending on the user's nature. The personnel, considered as the sensor user, communicates with the sensor indirectly through the base station and the network where the sensor works. Sometimes the sensor user can be considered as a process communicating directly with the sensor to get some data or to perform some operations. Moreover, the administrator of the network assets and applications is distinguished and -optionally -other roles in different phases of the life cycle in the site.  Table 9 presents enhanced generics expressing different kinds of active entities related to the intelligent sensor, i.e.:  legal users of the sensor or sensor system,  legal actors participating in the life cycle processes performed within the site,  intruders,  intruders relevant to the site processes.

Patterns for Threats Representation
The enhanced generic representing a threat consists of three elements:  a threat agent, which adversely acts on an asset, e.g., hacker, user, developer, process, force majeure, failure; in the presented methodology it can be expressed by the Sparam parameter substituted by a subject-type generic from Table 9;  attacked asset (has value for its owner, so it needs protection), e.g., data, provided IT service, ability to use the IT equipment; in the presented methodology it can be expressed by the Dparam parameter substituted by an asset-type generic from Table 8;  adverse action performed on an asset by a threat agent who exploits existing vulnerabilities (a threat scenario). The given threat can be placed into the specification with different parameters substituted or refined in a different way. It enables iterations providing more compact and precise specifications.
The threats specification is the key part of the security problem definition. Threats should be countered by the TOE, i.e., the intelligent sensor, or by its operational environment, both partitioned by the TOE boundaries described in the TOE description (please note the logical/physical scopes). The third group of threats, related to the development-, manufacturing-and maintenance environments, influences indirectly the TOE.
The first, main group of threats (Table 10) encompasses direct attacks against the TOE:  related to the data sampled/measured by the intelligent sensor,  related to the data stored, processed and transferred by the intelligent sensor,  exploiting vulnerabilities concerning sensors restricted resources,  aimed at the sensor identity,  trying to breach the security-related data,  aiming at the sensor integrity,  related to different cases of unforeseen natural catastrophes, emergencies and failures.  The intelligent sensor operational environment encompasses IT elements, like neighbor sensors, network nodes, etc. with their hardware and software co-operating with the TOE. Attacks against the TOE operational environment, shown in Table 11, can impact the TOE indirectly. With respect to the life cycle model, the above two groups of threats concern the TOE operation. Other phases of the life cycle model are expressed by the third group, generally concerning the site and its development-, manufacturing-and maintaining processes (Table 12). They indirectly impact the TOE.

Patterns Related to the Organizational Security Policies
According to the Common Criteria methodology [1]/Part 1, the Organizational Security Policies (OSPs) encompass security rules, procedures or guidelines, existing or imposed to implement in the TOE operational environment by the organization which deploys the TOE. Generally, the OSPs are enforced by the TOE or the TOE operational environment. Optionally the OSPs enforced in the site can be specified.
Please note that OSPs are varied. Sometimes they can express simple information flow rules or access to asset rules, e.g., DAC-Discretionally Access Control, MAC-Mandatory Access Control, sometimes they imply standard-or regulations compliance or the use of certain procedures. Table 13 shows the Organizational Security Policies related to the TOE, its operational environment and site processes. The security developers' experiences show that the threats-based security problem definition gives more compact and concise specifications influencing the developed IT product or system quality. "The protection against the identified threats" is preferable by developers. The OSPs are used to specify issues hard to express by threats, as those listed in Table 13.

Patterns Representing Assumptions
Assumptions are specified for the TOE operational environment in order to show what conditions should be satisfied to enable the TOE security functionality. If the TOE placed in a certain operational environment does not meet these assumptions, the TOE may not be able to provide all of its security functionalities any more [1]/Part 1. Assumptions express personnel-, physical-and connectivity aspects of the operational environment, though for the intelligent sensors only these expressing the personnel (including organizational ones) aspects (APR) have been defined up until now (Table 14). Assumptions can never be made on the TOE behavior. Optionally, some assumptions are predefined for site processes. Assumptions are transformed to the appropriate security objectives for the operational environment that upheld these assumptions. Generally, the efficacy of the countering threats and the efficacy of the enforcing OSPs depend on satisfying assumptions addressed to the TOE operational environment. Assumptions for site processes represent certain developer demands concerning site processes and are transformed into security objectives related to the site.

Patterns for Security Objectives
The security objective represents a concise and abstract statement of the intended solution of the given elementary problem defined in the security problem definition of the security target. Security objectives, formulated in a natural language, should be understandable to knowledgeable potential consumers of the TOE [1]/Part 1/. The specified intended solution partially deals with:  the TOE, specified as the TOE security objectives,  the TOE operational environment, expressed by the security objectives for the operational environment,  the TOE site (optionally), specified with the use of security objectives concerning mainly the site processes. Table 15 contains appropriate groups of the security objectives enhanced generics concerning:  mainly the TOE,  mainly the TOE operational environment,  the development-, manufacturing-, and maintenance processes performed in the site.
The word "mainly" says that using the given item depends on the situation, the project character.  TOE security objectives express how the TOE counters threats and/or enforces OSPs. Later, these objectives are transformed to the security functional requirements and are implemented in the TOE security functions. Security objectives for the operational environment express how the threats are countered, OSPs are enforced and assumptions are upheld in this environment.

Patterns for Security Requirements
The security requirements encompass two groups:  the security functional requirements (SFRs), derived from the TOE security objectives, i.e., these objectives are translated into the standardized, semiformal CC language (SFR components) components [1]/Part 2;  the security assurance requirements (SARs), presenting how assurance is to be gained that the TOE meets SFRs; SARs are usually implied by claimed EAL and expressed by the semiformal SAR components [1]/Part 3. There is no difference between approaches to the intelligent sensors security requirements and other IT product or systems.
The SFR-and SAR components can be considered as the CC-related patterns to specify requirements for intelligent sensors. There are no specific issues related to the considered here Common Criteria domain of application.

Patterns for TOE Security Functions
The TOE security functions (TSFs) specified in the TSS, i.e., the TOE summary specification (the final part of the ST) expresses how the TOE satisfies the SFRs. The TSS provides the general technical mechanisms that the TOE uses for this purpose [1]/Part 1. This paper, as well as [3], does not discuss the full security target elaboration, showing only two initial and application specific stages, which often make difficulties for developers. The enhanced generics of the TSFs, presented in Table 16 can be considered as examples of definitions, rather than patterns. They concern the intelligent motion sensor example of digital tachograph compliant with the directive [14], still being able to express some key issues of other kinds of sensors. This part of the presented method needs further researches.

Validation of the CC-Related Design Patterns and Related Security Development Method
The subject of validation concerns the mining applications of intelligent sensors. Mining sensors are specific in comparison with industry sensors, like [17,18]. Rock and methane outbursts, as well as rock bumps, are the most dangerous and still poorly predictable phenomena in hard coal mining. Early detection of such hazards is extremely important for the mine crew safety and the mine operation. The robust, dependable IT-based solutions should be applied in this domain. The intelligent sensors which are key-importance elements of hazards early detection systems, and these systems as such, are IT based and designed for high risk applications, so the Common Criteria methodology can be applied for them.
There are different kinds of systems developed for mine environment monitoring, equipped with varied sensors, like methane detectors, carbon monoxide analyzers, smoke detectors, oxygen meters, air temperature sensors, anemometers, seismic sensors, coal dust detectors, etc. Monitoring systems can work autonomously but usually they are integrated in a broader IT system co-operating with the mine telecommunications system, including loud speaking communication and alarm signaling, and the mine SCADA system which monitors varied safety and production parameters in the mine. Such systems and different types of intelligent sensors have been developed and offered by the author's organization for years [19].
The paper [20] presents two variants of mine monitoring systems. The first allows the monitoring of varied safety and production parameters of a mine, for early detection of a fire, to support ventilation service, to switch off electric power in the mine monitored area in the case of an emergency or breakdown. The second, more complex, is integrated with an alarm-loud-speaking/signaling system and is connected to the mine SCADA system. In both cases, the further discussed intelligent sensor can be considered as one of the sensors working at the lowest level of the system hierarchy.
The paper [21] discusses an intelligent, integrated sensor detecting methane and rock outbursts, measuring methane concentration, pressure wave in the excavation and the acoustic effects of the outburst simultaneously. The paper analyzes transient states of air parameters considering input data sampled during two serious, real events related to methane and rocks outbursts which have occurred in Polish mines recently. The results of analyses are used to develop the integrated sensor. Early detection of higher concentration of methane requires right dynamic parameters of the applied pellistor-type methane measurement element. The model of the integrated sensor, its technical data and construction tests are discussed in this paper.
The CC-related security development method presented in the paper is validated on the intelligent sensor example designed for early detection and signaling of methane hazards in coal mines. This intelligent sensor, operating in a high risk environment, integrated with a broader monitoring system, represents a new class of IT product, which can be designed with the use of the Common Criteria methodology. Besides, the safety issues, including IT security issues, are important for such devices, because one cannot disregard threats inherent to the applied IT solutions in the sensor and threats related to the IT systems co-operating with the sensor.
The aim of the validation is to determine whether the predefined security design patterns can be applied for the considered design case. Validations should optimize the set of patterns and improve its particular items. During the validation, the predefined design patterns will be used to express the security problem definition and its solution. To build the security specifications, i.e., threats-, OSPs-, assumptions specification, etc., first the best matching enhanced generics from the predefined ones will be identified. To express specific issues, they can be refined. If a given elementary security problem or its elementary solution cannot be expressed this way, a new enhanced generic should be defined and added to the set of patterns. An important issue is to avoid defining redundant patterns.
The example deals with the Methane Early Detection Intelligent Sensor (MEDIS), working within the broader Mine Monitoring System (MMS), controlling different safety and production parameters, e.g., physical parameters, chemical composition of air, as well as the condition and working parameters of ventilation equipment, machines and process-line equipment. MMS is designed for mines with methane and coal-dust explosion hazards. The MMS system co-operates with the mine SCADA and integrates MEDIS devices and other sensors measuring different mine atmosphere parameters. MMS allows detecting and signaling of natural hazards, particularly methane-and fire hazards, high-energy rock bursts, along with other hazards related to production processes. In the case of an event, the energy supplied for the mining equipment in the monitored zone is switched off. MMS can be integrated with the alarm and communication system of the mine, enabling automatic transmission of voiced alarm and evacuation messages which inform the personnel about the existing danger and evacuation ways. MMS should comply with the ATEX directive and mining regulations.
The validation is focused on the selected issues of the elaborated security target (ST) of MEDIS, considered here as the target of evaluation (TOE). The validation is based on the general model and the security model (i.e., ST) of the intelligent sensor presented in [3]. The MEDIS security target is elaborated with the use of here validated, predefined design patterns.
The example discusses how to elaborate key parts of the MEDIS security targets. First the "ST introduction", defining the TOE, its parts and its operational environment is shown. On this basis the security problem definition, embracing threats, policies and assumptions, will be formulated. The security problem is solved by specifying security objectives, which are later transformed into security requirements, encapsulated in the security functions implemented within the intelligent sensor. Please note that the example concerns not only the security problem definition but also its solution, and these issues are presented here together, in a slightly different way as in the real security targets. To better explain the presented issues, the security objectives (elementary solutions) are specified immediately when a given elementary security problem (threat, OSP, or assumption) is identified. The security target documents are rather extensive [2]. The full ST for the intelligent sensor cannot be discussed here in detail. The paper discusses within the selected issues how to elaborate it.

Identifiers and Informal IT Product Description Included in the "ST Introduction"
The "ST introduction" contains:  the TOE identifier, e.g., "MEDIS-Methane Early Detection Intelligent Sensor, ver. 0.9",  the ST identifier, e.g., "ST for the MEDIS ver. 0.8",  the "TOE overview" and more detailed "TOE description", where the basic TOE features and components are described. For the discussed MEDIS sensor, the TOE description can be expressed as follows: "The MMS system (Figure 2) is designed for distance, on-line monitoring of mine atmosphere, including methane. The mining environment, especially ways and long walls are equipped with different kinds of sensors, such as: methane sensors (i.e., the MEDIS type-TOE), carbon monoxide analyzers, smoke detectors, oxygen meters, anemometers, air-temperature meters, etc.  One of important issues is to present what the TOE is and what is in the TOE operational environment, defining the TOE logical/physical components and the TOE boundary, e.g., (continuation of the "TOE description"): "The TOE (target of evaluation) (Figure 3)

Security Problem Definition-Protected Assets
An important issue is to identify what should be protected. At the beginning of the security problem definition process, different kinds of passive entities, i.e., assets requiring protection, should be identified. Please note that assets may be placed within the TOE or in its environment. To elaborate the assets specifications, the predefined generics from Table 8 can be selected. To express the given issue more adequately, the refinement operation can be applied.
The basic asset is data sampled by the intelligent sensor, which can be expressed by the previously defined enhanced generic, here refined: Data measured, stored, processed, or transmitted by an intelligent sensor and data related to the network services. Refinement: Data related to the methane concentration sampled in time intervals. The thresholds values related to the alarm generation and the energy switch-off, settable with the use of the calibration keyboard, are also included.
The mine environment requires that the gas monitoring should be permanent (in defined time intervals), so continuity aspects are also very important. The MEDIS operations, i.e., measurement, processing and transferring results to the MMS central unit, and the generation of local warnings (voice, light) can be considered as certain services whose continuity and quality can be considered as an asset: Services provided by a sensor: measuring, sampling, processing, transferring data, and displaying its status. Refinement: Sending/receiving the communication protocol messages, the security related data and generating acoustic alarm signals are included.
Please note that the sensor data and operations are important to ensure the safety of the mine personnel and the mine equipment.
An important issue is the sensor identity protection to avoid the sensor replacement by a falsified device. For this reason, the MEDIS sensors are equipped with unique identifiers, which are registered and securely inserted during the manufacturing phase. These identifiers should be protected, so they are considered as an auxiliary asset (assets used to protect other assets): Unique identification number of an intelligent sensor.
The processing resources are not critical because the sensor microcontroller is well balanced to the required speed of operation and this speed is almost constant. Additionally, the transmission resources are considered as not critical because the sensor can work autonomously and redundant sensors are applied. The basic critical resource is energy which can be expressed in the following way: MEDIS co-operates closely with the supervising entity which stores sampled data and issues commands to the sensor (local mode of operation, though possible, is atypical and less effective). This entity can be considered as an external asset: The entity supervising and/or monitoring sensors.
The MEDIS sensor co-operates with two kinds of specialized equipment (the calibration keyboard and a special energy switch to control the power of the mine machines), absent in previous validations. For this reason, the predefined set of CC-related patterns is extended by a new enhanced generic DEO.Co-operatEquip (should be added to the Table 8): The specialized equipment co-operating with the TOE.
(Note: the presented validation shows the need to define this item and add it to the set of patterns.) Thanks to the iteration and refinement operations [3] allowed for enhanced generics, both devices can be expressed by one generic only, but twice iterated and each time differently refined: DEO.Co-operatEquip (1).
The specialized equipment co-operating with the TOE. Refinement: The calibration keyboard used by service personnel to check the sensor and set alarm thresholds.
The specialized equipment co-operating with the TOE. Refinement: The central power switch of the mining machinery (longwall) and lighting.
Because such an IT product as MEDIS may influence the safety of the mine personnel and equipment, the evaluation assurance level (not discussed there) declared for it will be probably EAL3 or above. In this case the security of the development process ought to be considered on a more detailed level according to the DVS (Development security) assurance family of the ALC (Life-cycle support) assurance class [1]/Part 3. For this reason, all design related data should be precisely identified and expressed, e.g., with the use of the previously defined item: Sensitive project data and documentation. Refinement: Logical, physical design data of the TOE hardware, software specifications, code and other related documentation, development aids, test data, user data related documentation, material for software development and manufacturing process.
Careful and rigorous design, deployment and management of mine monitoring systems improve mine safety and productivity.

Security Problem Definition-Identification of Active Entities
Active entities embrace different actors, including legal users and intruders. They also represent different roles defined in the TOE life-cycle model (ALC class [1]/Part 3). Such models have different phases (e.g., development, manufacturing, maintenance/operation, end of life), activities of particular phases (e.g., hardware component manufacturing, assembling, repairing, security data insertion) and transitions between phases and activities (e.g., product delivery to service workshop, product component delivery for testing). To elaborate the specification of the MEDIS subjects and other active entities, the predefined enhanced generics from Table 9 can be used.
There are two kinds of direct users of the MMS system and its MEDIS sensors. First, there are the underground mining personnel (miners, supervisors, technical maintenance, mining authority), expressed by the first instance of the SAU.IntellSensorUser generic: SAU.IntellSensorUser (1).
Authorized entity (user, process) who/which directly or indirectly uses the intelligent sensor. Refinement: The underground mine personnel, i.e., miners, supervisors, technical maintenance, mining authority.
The second group of users embraces mine dispatchers (please note the second instance of the SAU.IntellSensorUser generic) and system administrators, who are mainly the surface personnel: SAU.IntellSensorUser (2).
Authorized entity (user, process) who/which directly or indirectly uses the intelligent sensor. Refinement: The surface personnel-mine dispatcher.

SAU.SensorNetAdmin.
Authorized administrator of the sensor network and applications.
The third group of generics expresses the authorized personnel engaged in the development-, manufacturing-and service processes running outside the MEDIS operational environment: Apart from authorized entities, the intruders can be considered. The experience (aftermath catastrophes analyses) shows that the mining personnel in the operational environment should also be considered as intruders. Please note that they are expressed by SAU.IntellSensorUser (1).
Some intruders may operate on the monitoring system level. They can get illegal access and make breaches locally or through other entities co-operating with the MMS systems (e.g., if they are hacked). They can be expressed by the standard enhanced generic:

SNA.HighPotIntruder.
Attacker having high level skills, enough resources and deep motivation to perform a deliberate attack.
Numerous and varied non-human, technical or natural causes of harmful events should be taken into account in the mine environment. Generally, they are hard to predict and preventing measures are usually applied against them (represented by security objectives, discussed later). All these causes are expressed by one enhanced generic: With respect to the design data, intruders operating within the development-, manufacturing-and maintenance environment can be also identified and expressed (optionally) using the predefined generic: Industry spy or intruder trying to get or counterfeit the design data.

Security Problem Definition-Identification of Threats
The TOE security problem is mainly expressed by threats. Three kinds of threats can be distinguished:  threats encompassing direct attacks against the TOE-drawn from Table 10;  threats related to the operational environment, especially attacks focused on the sensor operations (services) and data sampled, stored, processed and transmitted by the intelligent sensor-drawn from Table 11;  threats related to the development-, manufacturing-and maintenance processes (specified optionally)-drawn from Table 12. For each of the identified threats expressing an elementary security problem, the solution is proposed in the form of security objectives countering this threat (selected from Table 15) and specified for the TOE, its operational environment and, optionally, for its site.
Aftermath investigations of methane explosions in mines and mine authority inspections show that the sensor tampering, manipulations and negligence can be considered as causes of catastrophes. A very important issue for right monitoring the mine environment is the sensors placement with respect to the physical properties of methane, conditions in a given location and ventilation system. The first threat concerns a direct attack against data sampled (measured) by sensors, though without breaching the sensor integrity. An enhanced generic, presenting this issue, is additionally refined by adding some details specific to the mine environment. The manipulations may concern: the wrong location of the sensor with respect to the predicted methane concentration (e.g., in the air stream enforced by the ventilation system), clogging up the sensor gas entry.
A tampering attack can be very dangerous. An intruder may intentionally compromise the physical or logical TOE integrity to counterfeit or destroy the sensor data (any kind of data) and/or disrupt the intelligent sensor operation: Please note that the MEDIS sensor is an element of the mine safety system. Any sensor security problem may cause a mine safety problem, and the safety of the mine personnel and equipment is the key issue. It can be expressed by the threat: The threat related to the node replacement by a counterfeited one should also considered. The last threats deal with development, manufacturing and service. The design-related data can be eavesdropped and abused in different ways, e.g., to prepare attacks in the TOE operational environment or to get know-how by dishonest competitors:

Security Problem Definition-Organizational Security Policies (OSPs)
The security problem definition can be expressed by specifying organizational security policies (OSPs), e.g., using predefined items from Table 13 (supplemented by new defined items). In practice, the main security problem is expressed by threats and OSPs, having auxiliary, supporting meaning. OSPs are used to express issues which are very specific and hard to express by threats. Generally, such an approach allows to get more precise and compact security targets. For each of the identified OSPs expressing an elementary security problem, a solution is proposed in the form of security objectives enforcing the OSP (selected from Table 15) and specified for the TOE, its operational environment, and optionally, for its site processes.
With respect to the methane and coal-dust explosion hazards in the MEDIS operation environment, three OSP rules concerning legal or technical compatibility are specified.

PINT.IntrinsicSafe.
The intelligent sensor should be intrinsically safe.
Security objective enforcing the OSP within the TOE: OINT.IntrinsicSafe. The intelligent sensor should be intrinsically safe.
(Note: the presented validation shows the need to define this item and add it to the set of patterns.)
(Note: the presented validation shows the need to define this item and add it to the set of patterns.); the ATEX concerns equipment and protective systems used in potentially explosive atmospheres [22].

Resume Concerning Declared Security Objectives
As was mentioned earlier (subsection 4.4), the particular security objectives express elementary solutions of the elementary security problems.
Some security objectives are declared for the TOE and then the TOE is responsible for a given elementary solution, i.e., countering the threat and/or enforcing the OSP. These TOE security objectives are transformed later to security functional requirements (SFRs) expressed with the use of functional components from Part 2 of [1], and later implemented in the security functions within the TOE on the claimed EAL, and evaluated. Thirteen TOE security objectives are identified and around them security functions will be developed. These are the following:  ten items countering threats: OINT. TamperResistance During the evaluation related to the Common Criteria certification, the TOE operational environment objectives and the TOE site objectives are considered as dogmas.

Validation Summary
The validation of the CC-related design patterns on the MEDIS sensor example shows that most of the identified security issues can be expressed with the use of predefined patterns, though several new items were defined to express specific issues related to the considered domain of application. The following seven patterns are defined as a result of the performed validation:  to add to Table 8 as an asset related to the sensor operational environment: Generally, this method has open character-new security patterns can be always added, still the author's experience shows that uncontrolled extension of the existing set of patterns decreases coherency and quality of the elaborated specifications. Instead of defining numerous items, the enhanced generics features are used, like parameterization, refinement and iteration. The quantity of patterns should be necessary and sufficient to describe security features of a given domain of application. To achieve this aim, the method validation on several design examples will be suitable. Each validation means new experience allowing to complete a given set of patterns for an additional kind of sensors as well as to improve quality and preciseness of security specifications provided by the method. These improvements allow applying the knowledge engineering methodology and tools. The next, planned step is to develop an ontology of the CC-related security design patterns and knowledge base supporting the intelligent sensors developers. The initial version of this knowledge base restricted to the motion sensors is presented in [16].
The presented intelligent sensors development patterns-based method is focused on the use of the matured but still improved Common Criteria methodology providing assurance for IT products or systems, including sensor systems. The formalized, rigorous development and independent security evaluation are the basis of this assurance. IT products or systems can get worldwide recognized certificates and can be used in higher risk applications.
Elaborating a Common Criteria compliant method dedicated for the intelligent sensors should become widespread in the secure intelligent sensors applications. The review of this application domain was provided in [3]. The most relevant currently running researches concern:  airplane health monitoring systems,  safety-critical assets distribution systems,  motion sensors of digital tachographs,  SCADA (Supervisory Control And Data Acquisition) related products,  specialized firewalls used in control and automation systems, co-operating with sensor networks, but the most numerous group of the certified solutions [5,16] concerns digital tachograph applications, e.g., [13]. In the near future new certification processes in this domain are expected because the document [14] has been recently revised. The Common Criteria methodology use allows to avoid shortage related to risk factors in the operational and development environments. First and foremost, threats and vulnerabilities are exhaustively identified and analyzed if they are properly countered. Independent evaluation supports these activities.