# Developing Security Assurance Metrics to Support Quantitative Security Assurance Evaluation
## 3 Our Methodological Approach
### Security Assurance Evaluation Model
The former provides a rigorous list of security requirements for testers, developers, security professionals, and consumers, while the latter lists the ten most common web application security risks nowadays. We argue that the foundation for quantifying and analyzing metrics in SA is to understand what \"criteria\" are of interest and of \"how important\" each is expected to be. The assurance criteria are formulated depending on the objectives and functions of the assurance target. Concerning security, not all security requirements should be treated as equally important [2]. Likewise, the vulnerabilities in need of fixing must be prioritized based on which ones pose the most immediate danger. To reflect that, one must specify a numeric factor for each assurance criterion: \"Weight\" for security requirement criteria and \"Risk\" for vulnerability criteria. On the one hand, the weighing factor emphasizes the contribution of particular aspects of security requirements over others to the security assurance result, thereby highlighting those aspects in comparison to others in the SA analysis. That is, rather than each security requirement (criteria) in the whole dataset contributing equally to the result, some of the data are adjusted to make a greater contribution than others. The weight factor expresses how security is emphasized in the assurance target and it must be caried out based on the application context. For example, if authentication is necessary to make a specific API secure, that security requirement should be given particular importance, hence the weight is also high. On the other hand, from the perspective of vulnerabilities, the term risk can be defined as the probability and the consequence of an unwanted incident caused by existing vulnerabilities. That is, a risk is an impact of uncertainty on systems, organizations, etc. Several frameworks and methods have been developed for risk analysis, and organizations may choose their method depending on the type of risks they encounter, or their business area, for example, common vulnerability scoring system (CVSS) [25] and damage, reproducibility, exploitability, affected users, and discoverability (DREAD) [26]. **Assurance Element. ** Assurance criteria are narrated in detail by a set of assurance elements. As in assurance criteria, assurance elements are divided into security requirement elements and vulnerability elements. The former represents requirement items needed to be fulfilled, while the latter indicate a particular kind of vulnerability potentially existing in the assurance target. Table 2 lists the exemplary elements with the corresponding assurance criteria, extracted from OWASP ASVS as well. \begin{table}
\begin{tabular}{l l} \hline \hline
**Security Requirement Criteria** & **Vulnerability Criteria** \\ \hline Authentication & Broken Access Control \\ Access Control & Cryptographic Failure \\ Validation, Sanitization, and Encoding & Injection \\ Errors, Logging, and Auditing & Security Misconfiguration \\ Data Protection & Identification and Authentication Failure \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Exemplary assurance criteria in web applications. **Assurance Condition**. An assurance condition describes the underlying constraints (or terms) of assurance elements that need to be taken into consideration in assurance evaluation. It is specifically defined according to the organizational contexts, which include special circumstance items, such as the deployment environment, the organization's current state, and the security concerns. In addition, assurance conditions can also be represented as test cases performed to check to what extent the security requirements' conditions and the vulnerabilities' conditions are true. Table 3 represents the exemplary security requirement conditions under the element of \"Password Security\".