|
| Property | Description |
|
| Adaptation |
| Object to adapt | Generic solution. Authors mention security mechanisms for authentication, authorization, encryption, and fault tolerance. |
| Adaptation timing | Runtime and reactive. It is possible to achieve proactive adaptation by the means of threat monitoring service. The service acts like the IDS (Intrusion Detection System), which reveals ongoing attacks. However, these monitoring services are not described in more detail, and how the results of these services will be utilised. |
| Monitoring and analyses | The Context subsystem performs monitoring and analyses by means of dedicated services. The Context subsystem offers the following: trust level, threat level, availability, memory usage, and bandwidth usage. The internal design of these services is not described. |
| Planning and execution | Planning and execution are performed inside the security subsystem by means of ECSA Policy manager. The specific action is executed when corresponding event occurs and certain condition is true. Hence, the planning is static; that is, actions are defined beforehand. |
| Knowledge | Inside the monitoring services and ECSA policies. |
| Self-properties | Authors describe their proposal to self-managing and self-adaptive. By using terms described in Section 3, the approach offers self-protection by using self-configuration and self-optimization.
Context-awareness by means of services in the Context subsystem. |
|
| Security |
| Attributes | Generic solution. Authors emphasise authentication, authorization, confidentiality, integrity, and availability |
| Mechanisms | Generic solution |
| Protected asset | Generic solution |
| Threats | Generic solution |
|
| Lifecycle |
| Architecture | All elements, related to security and adaptation, are located on the middleware layer under the application layer. The structure of architecture is clearly described, but mutual behaviour of subsystems and components is not described. |
| Extensibility | The clearly defined architecture ensures that the approach can be extended easily. It is possible to bring new security mechanisms into the Security subsystem and new monitoring services into the Context subsystem. However, possibilities on how to extend the ECSA Policy manager are not described. |
| Flexibility | The defined architecture also supports flexibility. Applying the approach in different domains requires at least new policies. Based on the existing research papers it seems that there are no restrictions to add new policies afterwards. |
| Reusability | The approach is not tight into the application logic or particular security mechanisms. Thus, reusing will be a straightforward process. Reusing the whole adaptation approach requires that the presented middleware layer is implemented under the application layer. This might be challenging for the existing applications. Reusing monitoring services inside the Context subsystem will be easy. |
| Maturity | The approach is not validated from the security adaptation viewpoint. Existing papers do not describe how to build security adaptation by means of the approach. Several examples of ECSA policies are given, but implementation of the policy manager is not described.
The latest article with the security viewpoint in 2009, and the latest article from ECSA policies in 2011. The software community or code libraries are not available. |
|
