CARMEN: A framework for the verification and diagnosis of the specification of security requirements in cyber-physical systems

Computers in Industry 132 (2021) 103524 Contents lists available at ScienceDirect Computers in Industry jo ur nal ho me page: www.elsevier.com/locate/compind CARMEN: A framework for the verification and diagnosis of the specification of security requirements in cyber-physical systems Ángel Jesús Varela-Vacaa,∗, David G. Rosadob, Luis E. Sánchezb, María Teresa Gómez-Lópeza, Rafael M. Gascaa, Eduardo Fernández-Medinab aUniversidad de Sevilla, Escuela Técnica Superior de Ingeniería Informática, Dpto. Lenguajes y Sistemas Informáticos, Sevilla, Spain bDpto. Tecnologías y Sistemas de Información, Universidad Castilla-La Mancha, Ciudad Real, Spain a r t i c l e i n f o Article history: Received 16 April 2021 Received in revised form 9 July 2021 Accepted 14 July 2021 Available online 27 July 2021 Keywords: Cyber-physical system Cybersecurity Security Configuration models Security requirements Security verification Diagnosis a b s t r a c t In the last years, cyber-physical systems (CPS) are receiving substantial mainstream attention especially in industrial environments, but this popularity has been accompanied by serious security challenges. A CPS is a complex system that includes hardware and software components, with different suppliers and connection protocols, forcing complex data management and storage. For this reason, the construction, verification and diagnosis of security CPS become a major challenge, which involves a correct specification of security requirements, the verification of the correct system configurations, and if necessary, the diagnosis to detect the features to be modified to obtain a security configuration. In this paper, we propose a framework for the verification and diagnosis of security requirements, according to the possible correct configurations of the CPS. The framework is based on the specification of the security requirements and their analysis supported by Model-Driven Engineering and Software Product Line Engineering (SPLE) approaches. To illustrate the usefulness, the proposal has been applied to the security requirements in an Agriculture 4.0 scenario based on automated hydroponic cultivation. © 2021 The Author(s). Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). 1. Introduction Nowadays, cyber-physical systems (CPS) are drawn the attention within the industry, society and government, due to the enormous impact they have on the economy and the environment (Mörth et al., 2020), and providing citizens and businesses with a wide range of innovative applications and services (Colombo et al., 2020). The entry of the CPS in the industry allows high connectivity between the industrial systems and brought great advantages and a wide range of new opportunities to industries but also some questions and problems, such as those related to safety and security (Mokalled et al., 2019). Cybersecurity is a fundamental discipline that provides confidence in terms that CPS, their information, and supporting communications and information infrastructures are adequately safeguarded. CPS have many unique characteristics, including the ∗Corresponding author. E-mail addresses: [email protected] (Á.J. Varela-Vaca), [email protected] (D.G. Rosado), [email protected] (L.E. Sánchez), [email protected] (M.T. Gómez-López), [email protected] (R.M. Gasca), [email protected] (E. Fernández-Medina). need for real-time response and extremely high availability, predictability, and reliability, which impacts cybersecurity decisions (Ashibani and Mahmoud, 2017). Besides, an even more critical problem is that the development of these systems has been carried out without taking into account the security aspects, nor the new risks that this automation of processes implies, which put at risk the complete industrial infrastructure (Lezzi et al., 2018), and where any security breaches to these systems could have catastrophic consequences (Yaacoub et al., 2020). Taking into account the security from the earliest steps of CPS, i.e., at the design time is crucial to avoid security issues, even though it is a very challenging task (Geismann et al., 2018; Peisert et al., 2014). Therefore, security within industrial environments becomes a critical aspect that must be taken into account at all stages of information system development, by obtaining and defining, from early analysis and security requirements (Zunino et al., 2020) before the system is in place (Souag et al., 2015). Security and safety are nonetheless two key properties of CPS (Yaacoub et al., 2020) and they share the same goal, protecting CPS from failures (Pirbhulal et al., 2021). Security and safety refer to different but very important properties (Aviˇ zienis et al., 2004), in this paper just focus on those related to security properties for the CPS. https://doi.org/10.1016/j.compind.2021.103524 0166-3615/© 2021 The Author(s). Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/ 4.0/). Á.J. Varela-Vaca, D.G. Rosado, L.E. Sánchez et al. Computers in Industry 132 (2021) 103524 Although security requirements are the appropriate solution for many researchers, they are difficult to obtain, analyse and manage by their subjective nature and their description in natural language. For CPS, in addition to software security requirements, we also have physical, control and communication requirements, which make the task of identifying security requirements and translating them into the design of our CPS system even more complicated (Kim and Lee, 2020). Therefore, having a common model (or metamodel) is essential, since it facilitates the definition of security requirements for CPS where any particularity of all these elements is taken into account. The high variability of the components involved in a CPS and their possible configurations make it extremely difficult to verify the correctness of the security requirements that reduce the threats and the possible risks (Varela-Vaca et al., 2020b). To manage this complexity, we propose the use of Feature Models (FMs) (Galindo et al., 2019a) and a set of reasoning techniques (Benavides et al., 2007) to verify the correctness of the security requirements and diagnose misconfiguration of the features (Riel et al., 2018), according to a catalogue of possible correct configurations. FMs have been previously used for checking security configurations (Varela-Vaca et al., 2020a), and the diagnosis of FM configurations is a studied problem by the community (Varela-Vaca et al., 2019a). However, how it can be adapted to the specific scenario of CPS is still an open challenge (Arrieta et al., 2015) tackled in this paper. Based on the problems identified, we have developed a CARMEN framework that presents a systematic process to enable from the description of security requirements to the verification and diagnosis for CPS through variability models. CARMEN is focused on the design phase of CPS by presenting a support system for guiding the whole security requirement life-cycle: (1) creating a metamodel which enables the definition of security requirements for CPS based on security recommendations of ENISA (Baseline, 2018) and OWASP (OWASP, 2021) guidelines; (2) load and update a variability model that encompassed the catalogue of possible correct configurations for CPS; (3) map both security requirements and variability model resulting in a configuration; (4) verify the correctness of the configuration, and; (4) if it is not correct, the diagnosis of the configuration to modify for achieving a correct configuration according to requirements. To explain in detail each of these steps, the paper has been organised as follows: Section 2 reviews the most relevant papers in the area. Section 3 details a case study based on Agriculture 4.0 and introduces the possible cyber-risks to which this type of systems are subject. Section 4 presents the proposed framework for the diagnosis of this type of system. Section 5 applies the proposed framework to the case study to show its applicability; and, finally, conclusions are drawn, and future work is outlined in Section 6. 2. Related work Related works have been divided into the three areas of research addressed in the article: how feature model analysis has been used in the security field; how security requirements and ontologies can be used for the modelling of risk scenarios, and; an analysis of the standards and guidelines that have been found related to CPS/IoT. 2.1. Cyber-security and feature model analysis Feature-Oriented Domain Analysis (FODA) have become mature fields in the Software Product Line (SPL) arena in the last decades (Benavides et al., 2010). Several are the scenarios where SPLs based on feature model analysis have been applied (Galindo et al., 2019b; Varela-Vaca et al., 2019b), and different researchers highlight the advantages of these systems since the use of Model-Driven Engineering (MDE) methodology and the SPL paradigm is becoming increasingly important (Iglesias et al., 2019). The complexity and the high variability of a CPS, and how SPL can help were analysed in Arrieta et al. (2015) and Beek et al. (2018), detecting the points of variability using feature model analysis. The analysis of the variability of CPS can also support the testing (Arrieta et al., 2016). Security is an understudied field in SPL area. Different approaches have been presented to manage the variability and specify security requirements from the early stages of the product line development (Mellado et al., 2014). Similarly, other approaches addressed the idea of including the security variability into an SPL (Sion et al., 2016). In Fægri and Hallsteinsen (2006), the authors established a software architecture as a reference to develop SPL, dealing with information security aspects. SPLs are currently being targeted for application in CPS, as for some researchers, no standard provides a structured co-engineering process to facilitate the communication between security engineers (Bramberger et al., 2020). For other researchers, information security must be a top priority when engineering C-CPS as the engineering artefacts represent assets of high value, and the research is focused on the generation of new security requirements stemming from risks introduced by CPS (Biffl et al., 2019). On the other hand, there are approaches focused on security as a use case, such as in Arciniegas et al. (2006) and the methodology SecPL (Peldszus et al., 2018), where is highlighted the importance of specifying the security requirements and product-line variability. These are annotated in the design model of any system. Other researchers developed a security requirements engineering framework for CPS, which is an extension of SREP (ur Rehman et al., 2018). The capacity to support the high variability in the security context though Feature Models appeared in previous papers (Kenner et al., 2020), where the authors analysed which vulnerabilities could be used to simulate attack-defence scenarios, but these simulations were not oriented towards more complex scenarios, such as cyberphysical systems. 2.2. Ontologies and security requirements for cybersecurity As seen in the introduction, nowadays CPS require an adequate security configuration (Ashibani and Mahmoud, 2017). Therefore, some researchers are focused on the development of ontologies and security requirements (Shaaban et al., 2019a; Span et al., 2018). Some researchers have developed security tools based on ontologies capable of being integrated with the initial stages of the development process of critical systems (Shaaban et al., 2019b). On the other hand, requirements have been analysed not only from the software side but also from the hardware perspective, including sensors and network security. Therefore they propose the development of a security requirements framework for CPS, analysing the existing ones, and concluding that currently there is no suitable requirement framework for this type of systems (Rehman et al., 2018; Rehman and Gruhn, 2018). Other researchers consider that CPS have unique characteristics that limit the applicability and suitability of traditional cybersecurity techniques and strategies, and therefore propose the development of a methodology of cybersecurity requirements oriented towards weapons systems (Carter et al., 2019). This methodology allows us to discover solutions that improve dimensions (such as security, efficiency, safety, performance, reliability, fault tolerance and extensibility), being possible to use automated coding tools (Zhu and Sangiovanni-Vincentelli, 2018). Therefore, we can conclude that at present different researchers have found the need to develop requirement grammars to control the security risks associated with CPS. Moreover, derived from the 2 Á.J. Varela-Vaca, D.G. Rosado, L.E. Sánchez et al. Computers in Industry 132 (2021) 103524 complexity of the CPS, feature models have been previously used in the context of security. 2.3. Standards and guidelines for CPS/IoT Although CPS/IoT systems have been maturing for years, there are still few official standards specialised in this type of system. All of them are based on research proposals, guidelines, or crosscutting standards. Some of the most relevant standards, guidelines or other proposals are as follows: (i) the Cloud Security Alliance (CSA) that has developed some IoT oriented guides such as “Future-proofing the Connected World: 13 Steps to Developing Secure IoT Products” (Group et al., 2017), the “Identity and Access Management for the Internet of Things” (Group et al., 2016b) and the “New Security Guidance for Early Adopters of the IoT” (Group et al., 2015); (ii) the GSM Association (GSMA) also developed its own IoT-oriented guide called “IoT Security Guidelines” (Group et al., 2016a); (iii) the Industrial Internet Consortium (IIC) developed the basis of an IoT-oriented cybersecurity framework called “Industrial Internet of Things Volume G4: Security Framework” (Group et al., 2016c); (iv) the European Telecommunications Standards Institute (ETSI) has developed a guide called “ETSI EN 303 645 – Cyber Security for Consumer Internet of Things: Baseline Requirements” (ETSI, 2020) and has participated in the development of a specific standard for IoT called “oneM2M – Standards for M2M and the Internet of Things” (OneM2M, 2017); (v) Microsoft has also developed its own guide for IoT called “Cybersecurity Policy For The Internet Of Things” (Abendroth and Kleiner, 2017); (vi) the NIST has defined a guide called “Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks: NISTIR 8228” (Information Technology Laboratory, 2019), an analysis on IoT called “NIST SP 800-183 – Networks of Things” (Information Technology Laboratory, 2016), and a framework called “NIST Framework for Cyber-Physical Systems” (CPS, 2016); and (vii) finally, the ISO/IEC, counts on the standard “ISO/IEC 30141:2018 – Internet of Things (IoT) – Reference Architecture” (ISO Central Secretary, 2018), as well as the guidelines currently under development such as “ISO/IEC CD 27402.2 – Cybersecurity – IoT security and privacy – Device baseline requirements” (ISO Central Secretary, 2021a) and “ISO/IEC DIS 27400 – Cybersecurity – IoT security and privacy – Guidelines” (ISO Central Secretary, 2021b). Other organisations are also currently working on developing new proposals on the subject, such as OWASP, which has developed the “Internet of Things Top Ten”, or the EC Alliance for Internet of Things Innovation (AIOTI), the IERC European Research Cluster on the Internet of Things, and the IoT Security Foundation (IoTSF), which are developing their own guidelines on IoT. All these documents have been the basis used by ENISA to develop its own guide on IoT, which has been used to develop part of the research presented in this paper. 3. Case study The case study presented here (see Fig. 1) is a CPS system for hydroponic farming, in which various components are involved, both hardware and software. Hydroponic farming is controlled by the following physical elements: •Temperature, light and humidity sensors. They measure the existing temperature, light and humidity in the environment. •Heater, cooler, ultraviolet, nutrient injector and water pump actuators. These actuators change the characteristics of the environment by varying the temperature, the projected light, the flow of water and the injection of nutrients needed to facilitate growth and photosynthesis. All these actuators are activated or deactivated by the controller. •Controller. It is an Arduino device and web system that receives the data from all the sensors and sends it (via wireless connections) through the web system to the Big Data system for subsequent storage, analysis and display. In addition to the physical part, the controller is connected to a visualisation and control system with Big Data technologies where we have deployed the following components: •Dashboard. It allows the users to control the hydroponic farming in real-time and to consult statistics, as well as to interact with the farming sending HTTP requests to the actuators. It is also connected to the datastore that sends the necessary data for its correct visualisation. •Data handler. It is responsible for processing the sensor data, received from the controller, and storing it in the database. •Datastore. It contains a Hadoop file system (HDFS) and an HBASE database where all the values coming from the sensors are saved, as well as user data, historical data, logs and all the information needed for the Big Data system to be able to automatically control and monitor changes and act accordingly to stabilise it. 4. CARMEN framework We propose CARMEN, a framework to assist the stakeholders in the stages, from the definition of security requirements for CPS to the verification and diagnosis of them. Fig. 2 represents the step-by-step process proposed in CARMEN. Initially, it is necessary to describe the security requirements that involve the CPS components and the security aspects, that will be later verified and diagnosed. The formalisation of those requirements in the context of CPS are defined in Section 4.1. For the verification of the correctness of the defined requirements, it is necessary to provide a repository of possible correct requirement configurations according to the international standards and security best practices, that as was commented in the introduction, will be described by means of FMs. Section 4.2 provides the necessary details to know the FM proposed to cover the possible security configurations for CPS. Moreover, it is necessary the mapping the security requirement model elements and the FMs, as explains in Section 4.3. With the FM and the defined mapping, the verification of the correctness of the security requirements can be evaluated. The diagnosis must be executed when the security requirements are not correct according to the possible correct configurations, as detailed in Section 4.4. 4.1. Step 1: Define security requirements This step aims at the definition of a set of security requirements for a CPS. The security requirements should specify aspects related to the CPS components (i.e., assets) and the security features to reach, e.g., Authentication for users. Thus, the security requirements encompassed the security features for the assets in the CPS. Definition 1. Security requirements for a CPS. Let be  a set of m security requirements {sr1, sr2, . . . srm} for a CPS. (1)CPS = i sri Definition 2. A security requirement specification for a CPS. Let sribe a security requirement as a tuple AT, SF where AT represents a set of n asset types {at1, at2, . . ., atn} from the CPS, and SF is the set of m security features {sf1, sf2, . . ., sfm} related to those assets. 3 Á.J. Varela-Vaca, D.G. Rosado, L.E. Sánchez et al. Computers in Industry 132 (2021) 103524 Fig. 1. Hydroponic farming. Fig. 2. CARMEN process description. Fig. 3. View of the metamodel of security requirements for CPS. 4 Á.J. Varela-Vaca, D.G. Rosado, L.E. Sánchez et al. Computers in Industry 132 (2021) 103524 To define AT, we propose to follow the security best practices for IoT in the context of critical infrastructures formulated by the ENISA agency (Baseline, 2018). Many possible SF for CPS are obtained from OWASP (OWASP, 2021) to extract the most important concepts (e.g., encryption, protocol, network, AES, SSL/TLS, Bluetooth, range, lifetime). The CPS design (Ashibani and Mahmoud, 2017) requires tools to model the security for the different components that are managed. However, in general, the specification of security requirements is far away from the security features supported even to be implemented. In that sense, the definition of a model (metamodel) provides many benefits, the most interesting is that it enables a reusable schema with the domain-specific semantic that can be adapted to any scenario (Brambilla et al., 2017). Therefore, we have proposed a metamodel that enables to define the concepts of AT and SF based on the ENISA and OWASP. Fig. 3 shows the proposed metamodel. As aforementioned, one of the benefits on using the metamodel is to get advantage on the adaptation capabilities to other contexts (Brambilla et al., 2017) by extending the metamodel with other dialects, for instance, to consider standards or other guidelines. In our metamodel, a sriconsists of two different elements: asset types (AT) and security features (SF). The AT is composed of any kind of asset (or set of assets) presented in a CPS system, i.e., user, application, service, platform, device, infrastructure, or information. Besides, there may be relationships between AT, such as between a device and the infrastructure that supports it, considering for example the type of protocol to be used by the device or the type of network established for communication (i.e., Bluetooth sensor in PAN network). There is also a relationship between the type of infrastructure and the information that is generated and transported, considering how the information flows through the communication channels and where it passes through (e.g., temperature data is transported over a WAN network to the database). The SF represents the security aspects identified for the requirements related to the assets. Thus, we can define what security restrictions are involved for the assets (e.g., the type of encryption for information or communication assets, whether a two-factor (2FA) mechanism is used for passwords, or whether digital certificates are used), which property or properties are defined in the requirement, as well as defining a series of conditions that must be taken into account to satisfy the security requirement (for instance, bandwidth, memory capacity or response time). A security level is also defined as varying from very low (1) to very high (5). This security level can be used in many directions for instance to prioritise security requirements or to establish more or less strong restrictions or mechanisms. Some of these elements of the SF have relations between them because the values of some can restrict the values in others. For example, when the security property refers to Confidentiality or Integrity, a restriction must be defined concerning the type of encryption, or in the case of Authentication, a password policy must be defined. Despite the relations between different assets, there is a many- to-many relation between any AT and the SFs, which has defined a type of relationship that depends on the property of the feature and the set of related assets. Thus, the metamodel allows us to have several sets of AT and each one of them to be linked with different, or the same, SF (constraint, property or condition) with different types of relationship. For example, we can establish that the user (asset) access is controlled by a 2FA authentication, linking to the authentication and the password policy features, and has another set of assets such as wireless communications that are linked to the security features of confidentiality and some type of encryption. These relationships between asset types and security features can have various types of relationships, such as secure communication and user authentication. Table 1 shows the possible values of the attributes of our metamodel. These values have been defined of an initial effort to cover the maximum number of CPS components based on asset taxonomy of ENISA and OWASP. The description of any sriis based on an instantiation of the metamodel. An example for the case study of hydroponic farming is given in Fig. 4. The sr1establishes that the wireless communication between the temperature sensor and Arduino as a micro-controller must be encrypted, ensuring high confidentiality. Moreover, the requirement establishes a high-level security feature and is that communication is encrypted in compliance with confidentiality. To this end, we define the property of Confidentiality, which is implicitly associated with a type of encryption (Camellia) and a secure communication channel (HTTPS). This feature is defined for a set of assets that is the temperature sensor that communicates with the Arduino through a WLAN network whose wireless communication can be BLE or RFID. This relationship between this security feature and the set of assets is defined as “secure communication”. 4.2. Step 2: Load and update of feature model for CPS/IoT The metamodel enables to instantiate different security requirements but they cannot be validated with regard the great variability of security features. To manage the variability on the security features for the assets of a CPS, we propose to use Software the Product Line (SPL) (Benavides et al., 2010) approach including variability models, such as FMs (Galindo et al., 2019a). Therefore, we propose to use a variability model in the form of FMs which gathers all the necessary information to enable the reasoning on the correctness of the security configuration derived from the security requirements. In this step, to reduce the effort analysing the security requirements (CPS) and their possible correct configuration, we propose loading and updating the FMs for a predesigned catalogue described in (Varela-Vaca et al., 2020b). Thus, these FMs are used as the core model for the verification but they can be updated considering other relations or restrictions that are not in the model, e.g., a new security constraint related to a new asset. The use of FMs (Benavides et al., 2010) is a wide broad technique for analysing and reasoning on them. FM is a model which represents a set of products but defined by their features and their relationships. A feature is a characteristic of the systems that can be configured, for instance, to choose the protocol of communication from a bunch of alternatives. There exist several approaches to define and formalise FMs (Batory, 2005), although the most used notation is the proposed by Czarnecki et al. (2004). In this paper, a FM is defined as following. Definition 3. Feature model. Let FM be a variability model which consists of a tuple (F,R), where F is a set of n features {f1, f2, · · ·, fn}, and R is a set of relations among features {r1, r2, · · ·, rm}. Fig. 5 illustrates through an example of CPS some ATs and SFs related among them. In general, FM diagrams are composed of six types of relations (Czarnecki et al., 2004) (i.e., mandatory, optional, alternative, Or-relations, alternatives, require, exclude) between a parent feature and its child features, although there exist extensions that enable attributes and extra-functionalities for features. The automated analysis of FMs, the so-called Feature-Oriented Domain Analysis (FODA), can be achieved by formal methods (Benavides et al., 2010). Most of the approaches in the literature make a transformation from the FMs to a formal model (Dechter, 2003). This analysis of FMs enables the performance of different reasoning operations on them, e.g., to determine whether the model is valid or not, to obtain all possible configurations, or to ascertain whether it is correct or not concerning the model and based on a configuration. Thus, we can verify a concrete configuration according to an FM, if the FM is formalised and adapted to the 5 Á.J. Varela-Vaca, D.G. Rosado, L.E. Sánchez et al. Computers in Industry 132 (2021) 103524 Table 1 Values for data types of our metamodel. Type Values UserType Consumer, provider, process, third-party AppType Analytic and visualisation, device and network management, device usage PlatformType Web-based services, Cloud infrastructure and services SensorType Humidity, temperature, accoustic, pressure, motion, chemical, luminosity, flowmeter ActuatorType Hydraulic, mechanical, electric, pneumatic, magnetic, thermal, TCP/SCP ControllerType MicroController, microProcessor, FPGA DSType NFS, GPFS, HDFS DBType SQL, NoSQL, GraphDB HWType Router, Gateway, PowerSupply EcoType Interface, DeviceManage, EmbeddedSystems FirewallType Software, Hardware ServiceType CloudAuthentication, AuthenticationSystem, ID-S/IPS NetType PAN, WPAN, WAN, VPN, LAN, WLAN ProtocolType BLE, RFID, Wife, ZigBee, ZWave, CoAPP, MQTT, LoRaWAN PropertyType Identification, authentication, authorisation, confidentiality, integrity, non-repudiation, availability, privacy, trust, audit, detection PwdType Strong, weak, multi-factor CipherType AES128GCM, Camellia, ChaCha20 ChannelType SSL/TLS, HTTPS, tunneling CertType ×509, openPGP, openSSL, SAML SigType SRP, PSK HashingType SHA-2, SHA-3 RelationshipType Secure communication, encrypted information, identified user, authenticated user, authorised user, trust guaranteed, privacy guaranteed, audit guaranteed, non-repudiation guaranteed, detection system Fig. 4. Instance of security requirement (sr1). Fig. 5. (Partial) Feature model with security features. 6 Á.J. Varela-Vaca, D.G. Rosado, L.E. Sánchez et al. Computers in Industry 132 (2021) 103524 specific context of CPS according to the SRs formalised in Section 4.1. In Fig. 6, a FM was defined (Varela-Vaca et al., 2020b) for the definition of a security CPS and IoT according to the ENISA and OWASP. Once, this is just a FM proposal which encompasses the approaches of ENISA and OWASP but it can be extended or updated to support other standards and approaches. Bear in mind that several parts have been hidden for clarity as some require relations and sub-models. As can be seen, the FM is encompassed of two main parts: (1) the assets (cf., Asset) involved in the security requirement, and; (2) the security requirements (cf., Security) specification where properties, conditions, and constraints can be defined. Some of the included components are obviously related to the mentioned in the sri, but not with a one-to-one relationship, the reason why a later mapping is necessary. Derived from these two parts (Asses and Security) the Feature Model Formalisation definition (Varela- Vaca et al., 2019a) is adapted by dividing the types of features into these two subgroups (FAand FS) those can be related. The adaptation of the general definition of FM to the security requirement context will facilitate the later automation of the verification and diagnosis analysis. Definition 4. Feature model for CPS and IoT. Let CPS IoTFMF be a formalised FM consisting of the tuple F, R, where F is a set of Boolean variables {fA1, fA2, . . ., fAn, fS1, fS2, . . ., fSm} that represent the features and R as a set of relations rithat are a tuple (S,BR), where the scope S = (fi, fj) is a tuple of variables that participate in a relation and BR ⊆ Dfi× Dfjare the tuples satisfying the relation and dfkis the domain of the values of the feature fk, where fiand fj∈ {fA1, fA2, . . ., fAn, fS1, fS2, . . ., fSm}. The available CPS IoTFMF contains almost 30 features among asset types and security features and more than 100 relations. Derived from the complexity, the automatic feature model analysis (Galindo et al., 2019a) in an efficient way is necessary. The CPS IoTFMF is accessible for public use through the catalogue provided by our tool CyberSPL.1. Following with CARMEN steps, how to automate the mapping between the security requirement sr1(as the shown in Fig. 4) and the FM for CPS IoTFMF (as shown in Fig. 5) is detailed. 4.3. Step 3: Mapping between security requirements and features models The metamodel provides a mechanism to define an instantiation of security requirements (sri) but it lacks mechanisms to verify the correctness of the instances concerning a high variability of options and restrictions to be configured for CPS. For this reason, we have proposed in the previous step the use of FMs (see Step 2) to describe the variability of configurations and to provide reasoning mechanisms. However, to provide interoperability between the security requirement metamodel instances (see Step 1) and the FMs (see Step 2), we propose to use model weaving techniques (Fabro and Valduriez, 2009). Model weaving is a Model-Driven Engineering technique that enables the creation of abstract links between model elements to customise the model-to-model transformation. The main goal of our weaving approach is to obtain an artefact from an instance of the security requirement metamodel (sri) and the FM which enables us to verify the correctness of the instance (sri). An overview of the model weaving in our particular case is presented in Fig. 7. The model weaving enables to customise of the model-to-model transformation. For this reason, the model- to-model transformation (cf., M-M symbol) is fed from the security 1https://n9.cl/models requirement metamodel, the FM, and the weaving templates. The result of the model weaving is a customised model-to-model transformation that enables the generation of a Security Configuration as an artefact to be verified and diagnosed. Thus, some elements of the model weaving are taken from the security requirements and others from the feature model, being necessary some templates (i.e., weaving templates) generate some parts of the output model (i.e., Security configuration). The weaving templates capture different transformation patterns between the security requirement elements and the FM elements, pointing to both the security requirement and the FM. To illustrate the mapping an step-by-step example based on the sr1requirement is given in Figs. 8–10 . Bear in mind, there are entities in the sr1instantiation that can be automatically mapped to the features in the FM. However, other features need to be inferred since the entity or property in the sr1are not equivalent to any entity or relation in the FM and vice versa. Fig. 8 represents a partial model weaving which focuses on one asset from sr1. In this example, we highlighted in grey colour the concepts Asset Type and Temperature Sensor to be mapped, while the rest of the concepts have been skipped in white colour. As commented, there is a direct mapping between the Sensor and Asset Type objects, and the features Sensor, Temperature, and Asset from FM in yellow colour. Also as we can see, there are other features from FM as Device or CPS IoT, that are inferred due to the intrinsic relation w.r.t the automatic mapped features. In this case, the use of weaving templates to describe this pattern enables to infer that relationship among the element from both models. The complete mapping for the rest of asset types from sr1to the features of FM is shown in Fig. 9. The complete mapping is given in Fig. 10 where the security features of sr1are also mapped to the feature of the FM. As aforementioned, the weaving model enables to generate a complete model-to-model transformation and it returns the Security Configuration (sc) as the resulting artefact to be verified and diagnosed against the FM. Therefore, for each sriwe can obtain an equivalent sci. The security configuration (White et al., 2014) is a specific arrangement of features according to the specification of a security requirement. Definition 5. Security configuration as the equivalent of security requirement. Let sribe a security requirement, CPS IoTFMF the formalised feature model, and scithe equivalent security configuration resulting for the weaving using ωtas a weaving template: (2)(sri ωt↓ CPS IoTFMF ) → sci For instance, the following sc1is the resulting artefact from the mapping of sr1: sc1={CPS IoT, Asset, Device, Sensor, Temperature, Controller, microController, Infrastructure, Communications, Protocol, BLE, RFID, Network, WLAN, Security, Enforce Communications, Property, Confidentiality, Level, High, Constraint, HTTPS, Cipher, Camellia} ;1; Thus, sc1represents a particular selection of features for the CPS IoTFMF according to the sr1requirement. This security configuration is the artefact that can be verified against CPS IoTFMF. 4.4. Step 4: Verification and diagnosing security configurations As explained in previous sections, for each sria security configuration sciis derived through the mapping application. This sci represents a specific selection of features as shown in Fig. 11. As proposed in the CARMEN process, each scimust be verified according to the FM that represents the possible correct security configurations, i.e, CPS IoTFMF. 7 Á.J. Varela-Vaca, D.G. Rosado, L.E. Sánchez et al. Computers in Industry 132 (2021) 103524 Fig. 6. Feature model for CPS and security requirements. Fig. 7. Weaving models for generation of security configurations. The verification of a sriis based on the definition of a valid configuration in the security context as introduced in Varela- Vaca et al. (2019a). Thus, a configuration sci, represents an assignment of features for certain FM. For instance, a security configuration sci= {CPS I oT = true, Asset = true, Infrastructure = true, Network = false, Communications = true, . . . } represents an assignment for the reduced model in Fig. 5, where missed features are assigned to false value. The same scican be represented without the Boolean values but the same semantic, thus, sci= {CPS I oT, Asset, Infrastructure, Communications, . . . }. The verification can conclude that the sciis valid (i.e., correct) whether the selection of assigned features satisfies all the FM relations, or invalid otherwise. We revisited the definition of valid configuration (Varela-Vaca et al., 2019a) to adapt it for the context of the verification of a security configuration (sci) by considering it as a configuration to be checked. Definition 6. Verification of security configurations. Let (FM, sci) be the tuple that represents the feature model, FM : (F, R) (see Definition 4), and the security configuration, sci, respectively. Let sci be a configuration assignment of n asset types and security features {fA1, fA2, . . ., fAn, fS1, fS2, . . ., fSm} according to FM. Thereby, the sciis verified as valid when all the included features in the requirement satisfy the relation of FM: (3)verify(FM, sci) = valid ⇔ {∀rj∈ R | rj(sci) ≡ true} For instance, any sciassignment that includes Confidentiality but no Enforcement Communications and one of the features HTTPS, SSL/TLS or Tunnelling will be invalid due to the relations between those features are unsatisfied. When a sciis verified as invalid, there are some failures (no correct assignment to features) in that configuration. The minimal diagnosis represents the explanation which turns into an invalid 8 Á.J. Varela-Vaca, D.G. Rosado, L.E. Sánchez et al. Computers in Industry 132 (2021) 103524 Fig. 8. Example of weaving for mapping sr1. Fig. 9. Example of weaving for mapping sr1. configuration into a valid one. The two possible modification operations available are the elimination (∠i −) or addition (∠i +) of features into sci. For simplification reasons, a configuration could be also represented as a set of features, whose belonging to the set implies a true value in the assignment. In Fig. 5 a configuration with the set of features sci= {CPS I oT, Asset, Infrastructure, Communications, Protocol, MQTT, WLAN, . . . }, not including Network is invalid. This security configuration can be transformed into valid just including (1) Network or (2) eliminating WLAN. Additionally, in option (2), Sensor and Controller must also be included. We have revisited the diagnosis of feature models configurations in (White et al., 2010) towards the minimal diagnosis of a security configuration. Definition 7. Diagnosis of Security Misconfigurations. Let sci an invalid security configuration,  is the minimal diagnosis as the set of modification of features (i.e., inclusions or eliminations operations) to obtain a valid scm iwith regard to FM: (4)verify(FM, sci) = invalidmin . −→ verify(FM, scm i) = valid The operations to transform sciinto scm imust be minimal, that implies: sci ∠1 − −→ sc1 i ∠2 + −→ · · · ∠m−1 + −→ scm−1 i ∠m + −→ scm i(5) We assume that just one changed is produced in every modification operation (∠i ∗). Thus, the difference in the number of elements in a sck iw.r.t the next sck+1 iafter a (∠i ∗), will result in 1. Furthermore, we assume that operations are applied at invalids intermediate security configuration until a valid one is reached: ∀ksc1 i· · ·scm−1 i, verify(FM, sck i) = invalid ∧ ||sck i| − |sck+1 i|| = 1 (6) Following with the previous example, the diagnosis of {CPS I oT, Asset, Infrastructure, Communications, Protocol, MQTT, WLAN, . . . } could be: the diagnosis for the option (1) results into a 9