# An Approach to Analyze Vulnerability of Information Flow in Software Architecture
## 4 Case Study
### Result Analysis and Threats to Validity
#### 4.5.2 Results Analysis and Discussion  
From the results of the vulnerability analysis of information flow in architecture under the goal of confidentiality conducted in the case, it can be seen that the vulnerability was \(\text{S}_{7}\to\text{S}_{0}\) (detailed descriptions of \(\text{S}_{7}\) and \(\text{S}_{0}\) are provided in Appendix A), which violated the first security policy of information flow under this goal. By analyzing the architecture design specifications with the help of domain experts, we learned that when verification service returned an error value to the login service, user and ticket information could be leaked, which could cause leakage of users' private information such as name and itinerary. In addition, malicious attackers could use this vulnerability to try logging in to the system, for example by inputting erroneous information on purpose, and obtain return values of the system, which could be used to guess users' passwords. If the login succeeded, they could imitate users to modify ticket information or conduct other operations in the system. According to the analysis above, we provided this feedback on architecture vulnerability to the developers and suggested that they modify the architecture. Specifically, we suggested that the developers bind the verification service with a login service in order to make sure that users' identities can be verified when they attempt to login, rather than after their information is saved, as in this system. From the result of the vulnerability analysis of information flow in architecture under the goal of integrity conducted in the case study, it can be seen that the vulnerabilities were \(\text{S}_{10}\to\text{S}_{3}\) and \(\text{S}_{10}\to\text{S}_{9}\) (detailed descriptions of \(\text{S}_{3}\), \(\text{S}_{9}\) and \(\text{S}_{10}\) are provided in Appendix B), which violated the fourth security policy of information flow under the goal of integrity. By analyzing the architecture design specifications, we learned that \(\text{S}_{10}\) was a monitoring service that could monitor and intervene in \(\text{S}_{3}\) and \(\text{S}_{9}\) by collecting their runtime information. However, in the design specifications, it was not stated clearly that \(\text{S}_{10}\) needed a specific transmission protocol such as virtual private network  
Figure 10: Output of vulnerability determination algorithm under the goal of integrity. (VPN) to transfer data, nor was an encryption mechanism mentioned for data receipt and sending. What is worse, there was no permission or access control mechanism for the monitoring service. As a result, in operation, malicious attackers could modify, intercept, or delete data in S3 and S9 by attacking the monitoring service. This analysis result conforms to the reality that most software systems nowadays, especially complex software systems have integrated monitoring services, and because of the complex functional, performance, and accuracy requirement of the monitoring function, many designers tend to neglect security requirements when implementing the monitoring function, which could pose significant threats to the operation of software systems [63]. According to the analysis above, we provided feedback on these vulnerabilities to the developers and suggested that they modify the architecture. For example, we suggested employing VPN and data encryption for data transfer between the monitoring service and the main system, and the monitor service should not have operation privileges for the system. To further demonstrate the effectiveness of the proposed method, we compare the vulnerability analysis results with common security vulnerabilities from famous vulnerability databases, including Common Vulnerabilities and Exposures (CVE), Open Web Application Security project (OWAP), and National Vulnerability Database (NVD). Common categories of vulnerabilities in these databases are listed in Table 11.  
In Table 11, we marked four categories of vulnerabilities in Italic form.