Approach
TERESA Repository ApproachThe proposed approach is to use a model-based repository of security and dependability patterns:
- Application sector trust models are defined as profiles (e.g. UML, SysML profiles), based on a common trust meta-model
- Security and dependability platform independent patterns are identified and defined for each application sectors (some patterns could be used by several application sectors)
- Formal properties on security and dependability are defined and validated for patterns belonging to application sectors requiring that level of assurance
- Platform dependent implementation of the patterns are of the patterns are guided with very precise requirements
The engineering process for resource constrained embedded systems will be validated in four application sectors: automotive systems, home control systems, industry control, and metering.
Defining an engineering discipline for trust that is adapted to resource constrained embedded systems must take into account the described trend (i.e. not all RCES have the same needs). TERESA proposed approach is to use a model-based repository of security and dependability patterns.
Patterns are widely used today to specify architecture and design aspects. They refer to templates describing a solution to solve a commonly occurring problem. Most importantly, they can be provided by security and dependability experts which might not be always available in companies involved in the development of RCES.
Models are abstractions which are closer to particular domain concepts and decoupled from than implementation concepts. Model-driven engineering is widely used in embedded systems where assurance requirements get important. This allows implementation independent validation of models for instance, generally considered as an important assurance step. TERESA vision is that security and dependability patterns that are derived from / associated with domain specific models will help application developers to integrate application building blocks with security and dependability building blocks. This is the reason why we are advocating the use of a model-based repository, where patterns are clearly related to domain models: - a common trust meta-model will serve as the foundation of the whole repository. Trust meta-models have been studied in the ITEA TECOM project (www.tecom-itea.org)
- domain specific trust models based on the common trust meta-model will be defined, i.e. they cope with specific needs of a given application sector. Well known trust models are the Clarke-Wilson Model (integrity oriented), Bell-la Padula or Biba Model (confidentiality oriented), Role-based access, ... Trust models will generally focus on the specification of policies to protect access to assets (e.g. who has the right to download software in au automotive control electronic). Domain specific trust models to protect vehicle intrusion are being studied in the ITS EVITA project (www.evita-project.org) which will be input to TERESA. The resulting application sector trust models should be defined as profiles of well known modelling languages (e.g. UML, SysML).
- Security and dependability patterns, are not only defined from a platform independence viewpoint (i.e. they are independent from the implementation), but they are also expressed in a consistent way with domain specific trust models. Consequently, they will be much easier to understand and validate by application designers in a specific area.
Depending on the assurance requirements for a pattern, formal verification or security and dependability patterns could also be needed. This work has been carried out within the serenity project for the evaluation and validation of TPM based solutions. In TERESA formal properties on security and dependability will be defined and validated for each pattern belonging to a domain area where this is required. TERESA Resulting Trust Engineering ApproachOnce the repository is available, it must serve an underlying trust engineering process that must also be domain specific. To this end, TERESA will also define a trust engineering meta-model from which domain specific trust engineering models can be defined. The association of a trust engineering meta-model with guidelines to define domain specific trust model can be considered as the overarching contribution of TERESA. The resulting engineering approach for resource constrained embedded systems will be validated in four application sectors: automotive systems, home control systems, industry control, and metering. In other words the trust engineering meta-model will be associated with four validated trust engineering models. For each individual domain application we will have
- A trust model based on a common trust meta-model, associated with a number of security and dependability patterns. If required by the domain application the pattern will be formally verified and validated.
- A trust engineering model based on a common trust engineering meta-model. Trust engineering models and trust models are associated as part of the same domain specific ontology.
- A resulting documented and tool supported domain specific trust engineering process supported by the repository as well as a number of guidelines help to allow (1) the populating of the repository with further security and dependability or S&D patterns, and (2) to use transform the S&D patterns into platform dependent specifications. When a pattern has been formally validated implementations, automatic derived guidelines for platform dependent implementation of the patterns will be available.
The common trust engineering meta-model will have to recognize the need to separate expertise on applications (represented by an application designer), expertise on security and dependability (represented by an security and dependability engineer), and expertise on repository development (represented by a model-driven and pattern engineer). As a result, individual application domains could have different trust engineering processes (e.g. supposedly, a domain where application engineers do not use model-driven engineering should have a more decoupled interaction with the model/pattern repository).
|