Resumen de A Trust-by-Design Framework for the Internet of Things
Davide Ferraris
Our framework ensures that trust and other domains are considered during the whole System-Development-Life-Cycle (SDLC) of an IoT devices. The framework comprises a K-Model and seven transversal activities: documentation, traceability, risk management, threat modeling, decision making, metrics, and gates. The K-Model has seven phases, plus the context.
In the first phase, it is essential to have clear in mind the architecture in which the intended IoT entity will be used. Furthermore, all the stakeholders give their input about their specific needs collected by the developers, which will elicit the proper requirements in the second phase of the SDLC according to these needs. We define seven types of requirements (i.e., trust, usability, security, availability, privacy, identity, and safety), proposing a JSON-based requirement elicitation method: the TrUStAPIS approach.
Following it, developers can elicit the proper requirements according to the stakeholder needs. Therefore, for each domain, we have highlighted a set of characteristics that must be taken into consideration in eliciting the requirements. Another important feature of the method is traceability that enables the connections among requirements providing a holistic view of the IoT entity. Moreover, traceability guarantees control, avoiding domino effects in the case of relaxing requirements. After this phase is completed, it is possible to proceed to the model phase.
About it, we have proposed a model-driven approach that considers trust-related domains. About trust, we consider the distinction between evaluation and decision models to model the proper features related to trust stereotypes. Then, we enhance and extend UML and SysML diagrams and proposing new ones. The former helps developers highlight each possible context and its related domains to consider the different functionalities belonging to an IoT entity. The latter is needed to control the connection among the other diagrams and helps developers avoid domino effects due to modification of connected diagrams.
After the model phase, there is the development phase where developers will examine the documentation produced in the previous phases in order to write the proper code that will define the behaviour of the IoT entity. To suggest a systematic way to complete this phase, we propose two approaches to implement functionalities and contexts: a top-down approach (FDBS) and a bottom-up approach. Besides, to merge and consider together the top-down and bottom-up approaches, we present a block development. This development style is useful for the developers in order to consider all particularities of contexts and functionalities in single blocks of code according to contexts and functionalities.
After the development phase is completed, we have the verification phase. It is useful to guarantee that all the functionalities are correct. Basically, in this phase, the developers will verify that the functionalities reflect the requirements and the models performing verification tests. Then, during the validation phase, the developers will check that the right entity has been built, analyzing how the developed IoT entity performs in its intended environment.
In the final phase, the IoT entity will interact with other IoT entities and be placed in its intended network architecture (i.e., a smart home).
