## 5 Feasibility and Evaluation
### Architectural Comparison  
This section provides a comparison of EDAS with traditional security architectures and corresponding controls. They are grouped into the following categories based on their architecture, however irrespective of the particular prevention and detection methods they utilize:  
* Host-based: controls that manage security locally on an end-user machine, e.g., an anti-virus, host IDS, firewalls, _etc._
* Endpoint: controls that protect end-user machines, but are managed by a central entity, e.g., Endpoints in Microsoft System Endpoint Protection.  
* Agent-based: controls that protect and manage the monitored environment based on the information gathered by specialized agents; for example, an agent-based IDS.
* Centralized: controls that provide security as a central stand-alone entity; for instance, an enterprise firewall or a network-based IDS.
* Distributed: a security architecture that utilizes various prevention or detection systems distributed over a network to facilitate advanced security analysis; for example, a distributed firewall or IDS.  
The objective is to highlight whether the concept of EDAS as an event-driven security architecture and adaptive security solution adds value to an IoT-based service, such as eHealth. There is comprehensive work concerning system and software architecture evaluation, e.g., [26, 27]. However, we present a simple comparison based on the architectural concept and on the prototyping exercise we performed to reflect on the extent to which these candidates qualify or support a given architecture quality attribute in the IoT-eHealth context.  
One can find an extensive list of these attributes in the literature. However, we have selected a list of architecture quality attributes from [28, 29, 30, 31], which covers most of these attributes. Furthermore, we have used selected attributes from these sources as some of them, though having little differences, can be defined interchangeably. For instance, attributes like modifiability, evolvability, adaptability, configurability, reusability and customizability can be accumulated for a change in a system for which a single and, more common, word, maintainability, can be used, which we have adopted. Some attributes are intentionally dropped as they are more focused on software architecture as opposed to system architecture, e.g., portability in [28]. Hence, the attributes used here are considered and defined in a system perspective and not in a software context. Furthermore, we have added a few functional attributes, such as monitoring scope and threat detection accuracy, to reflect on a candidate aptitude as a security solution. These attributes are described in Table 3. Table 4 depicts the comparison where (++) implies that an attribute is positively qualified or supported, a (+) indicates partial qualification or support of the attribute indicating that there is some design dependency involved, and (-) indicates an absence of the attribute.  
\begin{table}
\begin{tabular}{c c c c c} \hline \hline  & **S.No** & **Attributes** & **Ref.** & **Description** \\ \hline \multirow{4}{*}{_S.No_} & 1 & Interoperability & [29, 30, 31] & The ability of a system to be utilized in diverse environments \\ \cline{2-5}  & 2 & Reliability & [28, 29, 30, 31] & The ability of a system to continue intended operations over time \\ \cline{2-5}  & 3 & Usability & [29, 31] & The measure of how well the user requirements are met for using the system (in terms of the user’s security requirements) \\ \cline{2-5}  & 4 & Latency & [28, 29, 30, 31] & The reaction time of a system to an event/incident/threat \\ \cline{2-5}  & 5 & Throughput & [28, 29, 30, 31] & The number of events/threats/incidents responded to in a given time interval \\ \hline \hline \end{tabular}
\end{table}
Table 3: System architecture quality attributes.