Table 1: Data for comparison framework.

PropertyDescription

Adaptation
Object to adaptGeneric solution. Authors mention security mechanisms for authentication, authorization, encryption, and fault tolerance.
Adaptation timingRuntime 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 analysesThe 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 executionPlanning 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.
KnowledgeInside the monitoring services and ECSA policies.
Self-propertiesAuthors 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
AttributesGeneric solution. Authors emphasise authentication, authorization, confidentiality, integrity, and availability
MechanismsGeneric solution
Protected assetGeneric solution
ThreatsGeneric solution

Lifecycle
ArchitectureAll 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.
ExtensibilityThe 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.
FlexibilityThe 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.
ReusabilityThe 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.
MaturityThe 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.