# A Taxonomy for Security Flaws in Event-Based Systems
## 3 Taxonomy
### Taxonomy Construction Methodology  
Although EBSs have particular attributes that general software systems do not bear, they may still inherit security issues from them. Hence, we decided to build a taxonomy upon existing taxonomies that targeted general software systems. First, we targeted the taxonomies that classify software security flaws. The advantage of this type of taxonomy lies in the convenience of creating a common language for sharing security flaws, allowing an efficient organization of security flaws across information sources, and ultimately identifying strategies to remedy security problems, which is the final goal of this research. For example, depending on the type of flaw, developers can figure out applicable solutions from among the existing ones and also for flaws that lack appropriate solutions. According to the review of security flaw taxonomies [37; 38; 134], the outdated taxonomies (i.e., before the year 2000) tend to be less elaborate than recently published ones [26; 33] or some of them have been adapted to the latest ones [25; 27; 29; 37; 38]. Thus, among the selected taxonomies, we filtered out the taxonomies published before the year 2000. The taxonomies that only focused on implementation-level errors were also excluded to consider design-oriented security flaws. Consequently, from among the remaining set of candidates, \"software security flaw taxonomy\" by [PERSON] et al. [25] was selected as the starting point to create a taxonomy, because it has been \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**D: Domain Keyword** & **A: Attribute Keyword** & **IEEE** & **ACM** & **Springer** & **Google Scholar** \\ \hline distributed event-based systems, & security vulnerability, & & & & \\ event-based systems, & security attack, & & 104 & 624 & 1188 & 3078 \\ android event, & security flaw, & & & & \\ android intent & security error & & & & \\ \hline Initially Searched & & & & 4994 & \\ \hline After 1 st Filtering & & & & 2018 & \\ \hline After 2 nd Filtering & & & & 780 & \\ \hline After Final Filtering & & & & 84 & \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Number of Collected References during Literature Review Process. designed to adequately reflect the nature of security issues in an EBS. [PERSON]'s taxonomy classifies the flaws based on genesis (i.e., how they were introduced to the system). Specifically, this taxonomy is distinguished from others due to its major division between \"intentional\" and \"inadvertent\" flaws, which is pertinent to classifying security flaws in EBS. As an EBS generally provides an extensible infrastructure, unintended external source code can be included in the system, which implies that a developer's intention is an important determinant for classifying an EBS's security flaws. For example, although the Android framework was not originally designed to contain security flaws, if an Android app, intentionally designed as malicious, is installed on the system, the system will contain \"intentional\" security flaws. We adapted [PERSON]'s taxonomy based on 84 selected literatures on security issues in EBSs [39; 40; 41; 42; 43; 44; 45; 46; 47; 127] as well as on Android security issues that originated from its event-based communication [22; 24; 45; 46; 47; 52; 56; 60; 61; 78; 12; 12; 130; 131; 132]. From those publications, we first extracted the security flaws each approach tries to address or introduce as an example. Then we clustered the flaws based on the similarity of ways they can be exploited. Finally, we examined if any of those flaws is related to its counterpart in [PERSON]'s taxonomy. The detailed process is as follows:  
According to the existing research [40; 45; 79; 87; 105; 118; 121], an EBS may contain malicious code that allows different types of external access, such as a piece of code directed to unsafe URL. These types of flaws belong in the same category as \"Trapdoor\" in [PERSON]'s taxonomy.