# Developing Security Assurance Metrics to Support Quantitative Security Assurance Evaluation
## 3 Our Methodological Approach
### Security Assurance Evaluation Model  
Given a complex IT system, direct measurement of its assurance level is generally not possible. Thus, the overall goal of the SA modeling is to transform SA evaluation into measurable works. In this respect, our modeling approach follows a five-level hierarchy, in which each node represents a distinct assurance component, as shown in Figure 1. In our model, security assurance components constitute the essential parts of assurance metrics calculation. The assurance target is the product or system that is the subject under security assessment, such as an information system, part of a system or product, or a cloud ecosystem. The evaluation serves to validate claims made about the assurance target. One core principle behind our proposal is that the confidence in the system security is quantified through two critical assurance perspectives: the protection side and the weakness side of the assurance target. Each perspective is composed of one or more criteria, and each criterion is composed of one or several elements until reaching the lowest level (i.e., assurance conditions). Thereafter, the overall score of an assurance target is estimated from the test results of the assurance conditions and the criteria/elements of the evaluation model applied. These estimates are aggregated continuously in conjunction with predefined algorithms to arrive at a more fine-tuned final estimate at the top-level assurance target. The concepts for each component are described below. For simplicity of presentation, we use \"assurance\" in short to represent the term \"security assurance\" for all component names in the model. **Assurance Perspective. ** Assurance perspectives describe the interrelation or relative significance in which an assurance target is evaluated. In our approach, two perspectives on cyber security are taken in the evaluation: security requirements and vulnerabilities. The former addresses the positive side of system security while the latter considers the negative side that involves looking inside the system for structural flaws and weaknesses. We assume that, on the one hand, fulfilling security requirements through implementing countermeasures and checking its correct functionality will give protection against unintentional errors. On the other hand, with proper identification and addressing of vulnerabilities, it can go a long way toward reducing the probability and impact of threats materializing in the system. We argue that even if security mechanisms are properly elucidated at the requirement stage, they could result in weakness if they are inappropriately implemented or deployed. Consequently, while evaluating security assurance, security requirement improves the assurance posture; contrarwise, the existence of vulnerabilities leads to a reduction in the assurance level. Such concepts will be inherited by the rest of the assurance components. **Assurance Criteria. ** Assurance criteria are the specific properties that will be selected, tested, and measured to confirm the sufficiency of system security to be offered to users. The term assurance criteria as used in this model refers to a higher, more abstract level of  
Figure 1: Compositions of the security assurance evaluation model. meaning that can be thought of as a standard in the assurance target's application domain. These criteria are part of the \"target\" that the work is planned to achieve (or eliminate in the perspective of vulnerabilities). In our quantitative security assurance approach, assurance criteria play an especially important role in the assurance evaluation, which provides a basis for comparison among different assurance targets; a reference point against which another system can be evaluated. In Table 1, we give exemplary criterion sets for an assurance target in the domain of web applications, in which the content is extracted from the OWASP Application Security Verification Standard (ASVS) [13] (in defining security requirement criteria) and OWASP Top 10 [24] (in defining vulnerability criteria).