Quality-centric security pattern mutations

Abstract

Security patterns are a means to encapsulate and communicate proven security solutions. They are well-established approaches for integrating security into the software development process. The literature includes a large array of security patterns categorized into various catalogs, from which the designers can choose a pattern suitable to the problem at hand. Previous efforts to choose appropriate security patterns have only considered the different functionality of the patterns. However, the solution structure of the chosen pattern will integrate with the overall software design and therefore affect many quality attributes such as flexibility and security. Thus, non-functional requirements should also be considered when opting to add a pattern to an existing software design. This will allow the designers to choose between alternative solutions based not only on functionality but also on the quality requirements put forth by different stakeholders. We propose the concept of quality-centric security pattern mutations which are created by mutating current patterns using design refactoring rules. These mutations offer the same behavior as the initial pattern but with varying effects on quality attributes such as flexibility, reusability, extendibility, and security. We have selected two well-established access control patterns as our case studies. We have used both object-oriented quality metrics and design security assessment metrics for quality evaluation and utilized petri nets to analyze behavior preservation. Our assessments demonstrate that the newly created mutations offer varying levels of quality while preserving the original pattern functionality.

Appendix. Results for the role-based access control pattern variant

This section presents the results for the enrichment, mutation, and evaluation phases of our approach on another case study: “The role-based access control pattern.” The fine-grain details of the enrichment, mutation, and evaluation phases are similar to the guidelines in the paper and thus will not be repeated here. Figure 11 shows the initial pattern structure in the literature, and Fig. 12 illustrates the enriched version after adding the appropriate attributes, methods, and the UMLSec notation.

Fig. 11

The original role-based access control security pattern (Fernandez 2013)

Fig. 12

The enriched role-based access control security pattern

We can see the mutated versions of the enriched pattern in Figs. 13 and 14. These mutations are created using the previously mentioned guidelines of encapsulating change, favoring composition over inheritance and finding opportunities to apply GoF patterns. The first mutation, illustrated in Fig. 13, utilizes the Extract Method, Extract Class, Extract Superclass, Extract Subclass, and Replace Inheritance with Composition refactoring rules. The second mutation, illustrated in Fig. 14, utilizes the Parametrize Method, Extract Class, and Add Parameter refactoring rules.

Fig. 13

The class diagram of the first mutation

Fig. 14

The class diagram of the second mutation

The evaluation results for the QMOOD quality metrics are presented in Table 7. The normalized results are illustrated using the radar diagrams of Fig. 15 to better depict quality trends in different mutations. As can be seen, the first mutation provides better reusability and functionality than the originally enriched version of the pattern, albeit with a little less understandability and flexibility. This is yet another example of the inherent trade-offs between quality attributes discussed in the paper. Reusability and flexibility suffer far less in the second mutation (almost negligible), but as a result, there is a lesser degree of improvement in other attributes.

Table 7 Evaluation results for the QMOOD quality metrics and attributes

The evaluation results for the class security and design security metrics are presented in Table 8. The radar diagrams in Figs. 16 and 17, respectively, illustrate the normalized values of these results. As can be seen in Fig. 16, the first mutation has caused a very significant increase in the CMW and CAIW metrics, whereas the most prominent trend for the second mutation is the increase of CAAI and the decrease of the CMAI metric. Looking at the design security metrics in Fig. 17, we observe that the first mutation has caused a spike in the CSP and CMI metrics while the second mutation is not so different than the enriched version. These results clearly illustrate the difference in security attributes for the two identically behaved mutations.

Fig. 15

Normalized QMOOD evaluation results for the first and second mutation

Table 8 Evaluation results for the security assessment metrics

Fig. 16

Normalized class security evaluation results for the first and second mutation

Fig. 17

Normalized design security evaluation results for the first and second mutation