Int. J. Ad Hoc and Ubiquitous Computing, Vol. 18, Nos. 1/2,

Transcription

1 Int. J. Ad Hoc and Ubiquitous Computing, Vol. 18, Nos. 1/2, A quantitative and knowledge-based approach to choosing security architectural tactics Suntae Kim Department of Software Engineering, Chonbuk National University, 567 Baekje-daero, deokjin-gu, Jeonju-si, Jeollabuk-do, , Republic of Korea Fax: stkim@jbnu.ac.kr Abstract: This paper presents a quantitative approach to choosing security architectural tactics using architectural tactic knowledge base. An architectural tactic is an architectural design building block pertaining to a software quality. The tactic knowledge base is a tactic repository composing of architectural tactic specifications defined in role based metamodelling language (RBML) and their relationships expressed in a feature model. In this paper, a cost of an architectural tactic is estimated by using the use case points method, and a level of tactic contribution for non-functional requirements (NFRs) is predicted by the analytic hierarchy process (AHP) and sensitivity analysis. Then, the proposed approach suggests the best possible fit which is likely to satisfy NFRs. We applied the approach to choosing security architectural tactics for building software architecture of an online trading system. Keywords: security architectural tactics; secure software architecture; quantitative tactic selection; architectural tactic knowledge base. Reference to this paper should be made as follows: Kim, S. (2015) A quantitative and knowledgebased approach to choosing security architectural tactics, Int. J. Ad Hoc and Ubiquitous Computing, Vol. 18, Nos. 1/2, pp Biographical notes: Suntae Kim is an Assistant Professor of the Department of Software Engineering at Chonbuk National University. His research focuses on software architecture, design patterns, requirements engineering and mining software repository. This paper is a revised and expanded version of a paper entitled A quantitative approach to selecting architectural tactics using tactic knowledge base presented at International Conference on Computers, Networks, Systems and Industrial Applications (CNSI 2012), Jeju, South Korea, Introduction Software architecture is intended to fulfil non-functional requirements (NFRs) regarding security, availability, and performance of diverse systems ranging from enterprise systems to embedded systems at the earlier phase of software development Bass et al. (2003). It is used not only for shaping the structure of software, but also for organising development teams, predicting development cost and planning integration of components. A poorly designed software architecture causes a system to be vulnerable and unavailable for providing its services. As modification of the software architecture at the late phase of software development is very costly, it is essential for a successful project to select proper architectural solutions and establish the software architecture based on them at the beginning. However, selection of architectural solutions has been mostly carried out in an ad-hoc manner due to its abstract and informal nature. This leaves selecting solutions largely depending on the knowledge and intuition of software architects in reality (Falessi et al., 2011). There has been several work to facilitate the decision of architectural solutions (see Bass et al. (2003), Al-Naeem et al. (2005), Clements et al. (2001), Kazman et al. (2001), Lee et al. (2009), Svahnberg et al. (2003a), Svahnberg et al. (2003b), Reza et al. (2005), Babu et al. (2011) and Zayaraz and Thambidurai (2005)). There are two research streams. One is the process based approach that suggests several activities and artifacts for deciding better architectural solutions. However, it is hardly used without skilled architects due to the lack of suggestion of concrete solutions. Others propose a quantitative approach to measuring cost of each architectural solution by using the analytic hierarchy process (AHP) (Saaty, 1980). Those have a shortcoming that software architects should estimate the cost heavily relying on their experience without considering in-depth complexity of each solution. In order to address the above issues, we propose a quantitative approach to choosing security architectural solutions based on the architectural tactic knowledge base, which is our previous work Kim et al. (2009, 2010). An architectural tactic as the one of the architectural solutions is Copyright 2015 Inderscience Enterprises Ltd.

2 46 S. Kim an architectural design building block pertaining to software quality (e.g., security) (Bass et al., 2003). The tactic knowledge base is a tactic knowledge repository composing of structural and behavioural specifications of architectural tactics, and their relationships expressed in a feature model (Kang et al., 1990). In this paper, we enhance the architectural tactic knowledge base by additionally specifying semantics of new security tactics and defining their relationships. Then, a cost of each security tactic is predicted by using the use case points method (Anda et al., 2001) that consists of weight of use case model elements and technical factors of each architectural tactic. Then, the tactic appropriate for the each NFR is selected after computing a selection factor to choose a tactic with the minimal cost and high NFR satisfaction. At last, validation of the selected tactics is carried out in sensitivity analysis (Zhu et al., 2005) to increase confidence for the selection. We have applied the approach to choosing architectural tactics for an online trading system to demonstrate our approach. The remainder of this paper is structured as follows. Section 2 presents the use case points method as a background. Section 3 introduces architectural tactic knowledge base containing an enhanced set of security architectural tactics. Section 4 presents an approach for quantifying effort of each architectural tactic and selecting tactics in a quantitative manner. Section 5 shows a case study of an online trading system and Section 6 presents related work to support selecting architectural solutions. Section 7 concludes this paper. 2 Background: the use case points method In this section, we present the use case points method (Anda et al., 2001) which will be used to estimate a cost of each architectural tactics. The use case points method is one of the approaches to estimating software cost by utilising a use case model, which is a popular method to analyse and specify software requirements (Group, n.d.). The output of the method is the use case points for all requirements analysed in a use case model. In order to compute the use case point, we need to compute three factors in turn: unadjusted use case point (UUCP) technical complexity factor (TCF) environmental factor (EF). To calculate the UUCP as the first step, actors and use cases are classified into simple, average and complex types depending on how to interact with the system and the number of transactions respectively as shown in Table 1. When an actor interacts with a system with application programming interface (API) call, its type is simple with weighting factor 1. Also, a use case within 6 transactions (i.e., interactions between an actor and the system) is classified into the average type with weighting factor 2. UUCP is obtained by adding all actors and use cases weights. A TCF is an index to quantify the technical complexity of each architectural solutions for a system, while an EF is a measure of organisational environment of a development team and its members. Tables 2 and 3 show its factors and weights. For each factor, a five-point scale value is assigned and multiplied with its weight. Then, TCF is computed with T F actor, and EF is obtained from ( 0.3 EF actor), where T F actor and EF actor are summations of multiplications of a weight and a value of each factor from the technical factor and the environmental factor tables respectively. Finally, the use case point of the system is computed with UUCP TCF EF. Table 1 Actor and use case types and w (weighting factor) Actor Use case Type Interaction w (No. of transaction) w Simple API Average Network Complex GUI(Web) 3 >= 7 15 Table 2 Technical complexity factors and weights Factor Description Weight T1 Distributed system 2 T2 High response time 2 T3 End-user efficiency 1 T4 Complex processing 1 T5 Reusable code 1 T6 Easy to install 0.5 T7 Easy to use 0.5 T8 Portable 2 T9 Easy to change 1 T10 Concurrent 1 T11 Security features 1 T12 Access for third parties 1 T13 Special training required 1 Table 3 Environmental factors and weights Factor Description Weight E1 Familiar with RUP 1.5 E2 Application experience 0.5 E3 Object-oriented experience 1 E4 Lead analyst capability 0.5 E5 Motivation 1 E6 Stable requirements 2 E7 Part-time workers 1 E8 Difficult programming language 2 3 Enhancement of architectural tactic knowledge base for security An architectural tactic is a fine-grained reusable architectural building block that provides an architectural solution built from experience for achieving a software quality attribute (Bachmann et al., 2002; Bass et al., 2003). In our previous approach, we analysed its structure and behaviours of 20 tactics for security, performance and availability quality

3 A quantitative and knowledge-based approach to choosing security architectural tactics 47 Figure 1 Security architectural tactic feature model attributes, and specified their collaborative relationships in the architectural tactic feature model (Kim et al., 2009, 2010). In this paper, we enhanced the tactic knowledge base by additionally specifying security tactics. Figure 1 shows the enhanced architectural tactic feature model for security. While two groups, one sub-group and five security tactics were introduced in our previous work, this paper presents three groups, two sub-groups and 14 tactics in the security tactic feature model, and their structural and behavioural aspects are specified in UML meta-model level. The security tactics can be classified into resisting attacks, detecting attacks, and recovering from attacks (Bass et al., 2003). The Resisting attacks tactic includes several tactics for protecting the system from malicious users, containing the most various tactics among security tactic groups. In the tactic group, the authenticate users tactic is analysed as a mandatory feature, which contains four authentication methods such as ID/Password, onetime password, biometric scheme, and digital certificate. Figure 2 shows the specification of the ID/Password tactic which checks the validity of clients credential (i.e., id and password) in the authenticator component of the server. This relation is specified in the tactic specification using RBML (France et al., 2002) at the UML meta model level. In the tactic specification, the clients and the authenticator component are captured by the Client and Authenticator roles in the figure respectively where in front of each classifier denotes a role. The behavioural aspect of the tactic is expressed in the AuthenticateID/Password interaction fragment. The realisation multiplicity (the number on the right shoulder of each classifier) denotes the number of instances that play the role at the UML model level. Thus, the figure says that at least one component which plays the authenticator role should exist in the real software architecture. The omitted realisation multiplicity denotes 1..* meaning at least one or plenty of components can play the role at the model level. Similar to the ID/Password tactic, the digital certificate tactic is another approach for an authenticator to establish the client s credential by electronically proving clients identity with a digital certificate issued by a credible authority. The authority issues keys by signing their keys to guarantee its validity. Figure 3 shows the authentication process using the digital certificate tactic where clients, an authenticator and an authority are expressed in the Client, Authenticator and Authority roles respectively. The tactic includes the Maintain Data Confidentiality tactic which is a method to encrypt and decrypt data in communication. The relationship between the two tactics is expressed in the ref: M. D. Confidentiality fragment in the behavioural specification and the required constraint in the security architectural tactic feature model (see Figure 1). Figure 2 The ID/Password tactic The limit access tactic controls allowance of clients with filtering out invalid clients access to the service component depending on the condition. The representative implementation of the limit access tactic is a firewall to protect a system from invalid port access of the system. The

4 48 S. Kim system only accepts requests passed through the firewall. The semantics is described in Figure 4, where the firewall system can be represented in the ServiceFilter role. tactic enables the system to mitigate the possibility of denial of service through controlling the system usage. This tactic composes of clients and a limit controller as shown in Figure 5. Figure 3 The digital certificate tactic Figure 5 The limit exposure tactic Figure 4 The limit access tactic In addition, the AuthoriseUsers tactic group contains the RBAC, DAC and MAC tactics to ensure that an authorised user has the right to access or modify either data or services (Ramachandran, 2002). They can be combined together to make hybrid access control system (Kim et al., 2011), which is the reason why the three tactics are expressed in the inclusive-or relationship. The detecting attacks tactic includes the intrusion detection tactic that is a common approach to detecting attacks by comparing current usage patterns to historic usage patterns stored in a database. The recovering from attacks feature group includes the identification feature for identifying an attacker by maintaining an audit trail, and the restoration feature for restoring the system to a correct state using several availability tactics (Bass et al., 2003; Kim et al., 2009). The tactic specifications for the one time password, restoration, maintain data confidentiality tactics are presented in Appendix A. 4 A quantitative and knowledge-based approach to choosing architectural tactics The limit exposure tactic is an approach to controlling the number of clients to manage stress of the system. Using this The approach for selecting tactics comprises three steps as shown in Figure 6. It starts with the tactic knowledge base and estimates a cost of each tactic using the use case points method. The second step computes a selection factor (SF) of each candidate tactic for each NFR by predicting the minimised cost and maximised NFR satisfaction. The last step validates the

5 A quantitative and knowledge-based approach to choosing security architectural tactics 49 Figure 6 An overview for selecting tactics SFs with sensitivity analysis in order to increase confidence of the selections. Finally, the approach produces architectural tactics that are likely to satisfy the NFRs in association with tactic realisation cost. 4.1 Tactic cost estimation A tactic cost is a cost to realise an architectural tactic. We adopt the use case points method (Anda et al., 2001) to estimate the tactic cost, which has been used in conjunction with use case driven software development methods. As the tactic knowledge base does not contain a use case model, we should identify a use case model from each architectural tactic specification. The architectural tactic semantics from the knowledge base is considered as an analysis model describing components and their interactions, which is considered as the next step artifact rather than a use case model. Thus, we reversely extract a use case model from tactic specification with the following guidelines. values into technical factors of the ID/Password (ID/PW) and digital certificate (DC) tactics and computed the TFactors as shown in Table 4. Two tactics are operated in the distributed environment (T1), and we expect general response time (T2) and end-user efficiency (T3) from the two tactics. However, the DC tactic needs more complex processing (T4), and its implementation should be more modifiable (T9) than the ID/PW tactic because the authority can be changed depending on the situation. As the authentication method using ID and password is a very fundamental approach, its security feature (T11) is estimated to normal. In addition, T12 and T13 of the DC tactic have higher scores than those from the ID/PW tactic because its implementation should interact with the authority. Based on the score, TCFs of the tactics are computed as 0.93 and 1.05 respectively. Figure 7 A use case model for the ID/Password tactic (see online version for colours) G1: a client component is transformed into an actor G2: an external collaborative component is transformed into an actor G3: a timer actor should be identified if there are a time-based or regular interactions G4: an interaction fragment in the behavioural specification is converted into a use case G5: all messages in an interaction fragment are considered as transactions of a use case. Figure 8 A use case model for the digital certificate tactic (see online version for colours) After applying the guidelines into the ID/Password and digital certificate tactics, we identify use case models as shown in Figures 7 and 8 respectively. The actor Client in Figure 7 is identified according to G1, an use case authenticate ID/Password is extracted based on G4. All actors of these tactics interact with the system through a network call. Particularly, G3 has been applied to identifying the actor authority in Figure 8. Also, the numbers of transactions of each tactic are counted by the guideline G5 respectively. As the second step, a TCF for each tactic is computed to take the technical aspect into account. According to the characteristics of each tactic, we assigned five-point scaled As an EF is a consideration on project specific environments (e.g., application experience, stable requirements, etc.). However, we do not handle project specific variables in this paper. Nonetheless, this factor may be tailored for the sake of accuracy. We obtain by assigning the mid-value to each EF (see Anda et al. (2001) for specifics). Based on the equation of the use case points, the tactic use case points (TUCP) of the ID/PW and DC tactics are computed as Table 5. The Hours of Effort is obtained by multiplying TUCP and 28, which is the statistical average hour to realise use case point 1. In this way, TUCPs of all architectural tactics are computed and stored in the architectural tactic knowledge base.

6 50 S. Kim Table 4 Technical complexity factors of the two tactics 4.3 Sensitivity analysis Factor Description ID/PW DC T1 Distributed system 5 5 T2 High response time 3 3 T3 End-user efficiency 3 3 T4 Complex processing 1 3 T5 Reusable code 0 0 T6 Easy to install 3 3 T7 Easy to use 3 3 T8 Portable 3 3 T9 Easy to change 0 2 T10 Concurrent 3 3 T11 Security features 3 5 T12 Access for third parties 1 4 T13 Special training required 0 3 TCF Table 5 Tactic use case points (TUCP) of the ID/PW and DC tactics Factor ID/PW DC UUCP (Actor + use case weight) 12 (2 + 10) 19 (4 + 15) TCF EF TUCP Hours of effort Computing selection factors This step is intended to choose the best possible tactics which are likely to satisfy NFRs with the minimal cost. It includes three sub-steps, starting with choosing candidate architectural tactics for the given NFRs by consulting the architectural tactic feature model (see Figure 1). Figure 9(a) shows the relationship between NFR and tactics. Then, architects predict the architectural tactic contribution factors (ATCFs) for each candidate tactic indicating how much the tactic can contribute to achieve the give NFR. It is measured by AHP (Saaty, 1980) that estimates the relative contribution rate in a quantitative manner with pare-wise comparison between candidate tactics as shown in Figure 9(b). Figure 9 NFR-tactic relationships and AHP: (a) NFR-tactic relationship and (b) AHP for contribution measure Finally, the SFs of ith tactic for a NFR are computed with equation (1), where n is the number of candidate tactics for the NFR. The equation implies that the tactic with the minimum cost and high contribution to the NFR has a high selection factor. Thus, the tactic that has the highest selection factor is selected as the best contributable tactic for the NFR. SF i = ATCF i ( 1 TUCP i j=n j=1 TUCP j ). (1) The weakness of the previous step is a subjective measure of ATCF with AHP, which has potential to have wide variants. In order to mitigate the weakness and increase confidence of the measure, we applied the sensitivity analysis (Zhu et al., 2005) into estimating ATCF. Sensitivity analysis computes the minimal value that guarantees the selection. Equation (2) shows a formula to calculate sensitivity of ATCF Tk for the kth tactic among n candidate tactics for a NFR. Suppose that there is a selected tactic with the 0.8 ATCF for a specific NFR, and the result of the sensitivity analysis is 0.6. It can be understood as the tactic is always selected, if the architect assigns over 0.6 to the tactic. In this way, the sensitivity analysis can increase the confidence of the subjective measure of ATCF. Sens ATCF(Tk ) = MAX(SF T i..sf Tk 1, SF Tk+1..SF Tn ) 1 TUCP Tk / j=n j=1 T UCP. (2) j 5 Case study: online trading system In this section, we demonstrate how the security tactics can be quantitatively selected to satisfy NFRs of an online trading system (OTS) with respect to tactic cost and NFR satisfaction. The OTS is an online stock trading system that provides realtime services for checking current prices of stocks, placing buy or sell orders and reviewing traded stock volume. It sends orders to the stock exchange system (SES) for trading and receives the settlement information from the SES. The system can also trade options and futures. In addition to the functional requirements, the system has the following NFRs for security. NFR1. Only authenticated users can access the system. The user credentials must not be seen to unauthorised personnel while transmitting the information to the system. NFR2. The system shall protect itself from malicious attempt (e.g., distributed denial of service (DDos)) for the open services such as market price inquiry. The NFRs require secure services of the system during operating the system. For the NFRs, all tactics or combination of the tactics presented in security architectural tactic feature model can be selected as candidate tactics. As the NFR 1 is related to the authenticate users tactic group, we have identified the ID/Password, digital certificate, One-Time Password, and a combination of the ID/Password and maintain data confidentiality tactics as candidate tactics. After choosing the candidate tactics for the NFRs, the tactic use case point (TUCP) of each tactic is automatically obtained from the architectural tactic knowledge base. Then, an architect or team members have assigned an ATCF into each tactic with quantifying how much the NFR can be satisfied with AHP. Table 6 shows selection factors and sensitivity analysis for the NFRs. The selection factor of each tactic has been computed based on equation (1). The digital certificate tactic is expected as the most contributable tactic for the NFR1 with 0.90 ATCF. However, due to its high cost (19.85), the

7 A quantitative and knowledge-based approach to choosing security architectural tactics 51 Table 6 Selection factors and sensitivity analysis for the NFRs NFRs Tactics ATCF TUCP Selection factor Sensitivity NFR1 NFR2 ID/Password ID/Password + M. D. Confidentiality digital certificate One-time password Limit exposure Limit access Limit exposure + Limit access combination of the ID/Password and M.D. Confidentiality as the second highest ATCF has been selected with the selection factor The sensitivity value computed by equation (2) says that the selection of the tactic is guaranteed if the ATCF is over Also, for the NFR2, the limit exposure, limit access and the combination of the two tactics have been selected as candidate tactics to protect the system against DDos attack. The highest ATCF (0.95) has been assigned into the combination of the two tactics. Although its cost (TUCP) is higher than two tactics, the combination of the two tactics has been selected as the best solution for the NFR. In addition, the sensitivity value implies that the tactic combination is always selected if the ATCF is over Related work There has been some work for choosing appropriate architectural solutions. Clements et al. (2001) suggested software architecture analysis method (SAAM) to evaluate and improve software architecture using diverse scenarios to achieve quality goals. After then, they newly introduced architecture tradeoff analysis method (ATAM) (Bass et al., 2003) that allows one to check relations between quality attributes. The shortcoming of this approach is that it largely relies on participants subjective opinion without concrete guidelines to fulfil quality scenarios. Kazman et al. (2001) suggested Cost Benefit Analysis Method (CBAM) that is built upon ATAM. In this approach, stakeholders estimate costs and benefits of each architectural approachwithvariables. Basedonit, returnoninvestment(roi) of each solution is computed. However, a single variable benefit forvariousqualityattributeshardlycoversolution scontribution. Inaddition,thereisnowaytocalibratesubjectivemeasuresinthe approach.thisapproachcanbeclassifiedintothescenariobased and quantitative approaches because they quantified several elementsinassociatedwithatam. Lee et al. (2009) improved a method to compute the benefit variable from CBAM. In CBAM, the benefit of each scenario is estimated separately though the benefits of all scenarios are interrelated each other. To improve this shortcoming, they tried to measure relations between benefits of each scenario using AHP (Saaty, 1980) and analytic network process (ANP) (Satty, 2005), and increase the confidence of the measure. While this approach improved an approach to estimating the benefit variable, it also has limitation not to suggest a concrete approach to achieve the quality scenarios. Reza et al. (2005) presented an approach to selecting architectural styles based on scenarios, design principles and NFRs. In their approach, they built the mapping tables for representing relationship between software qualities and design principles, and between design principles and architectural styles. Quality-related scenarios are selected at first, then the best possible fit architectural style is selected based on the proposed tables. Although this approach seems to be systematic, rationale of the derived relationships is not clear and ad-hoc so that it is not realistic. Svahnberg et al. (2003a) tried to quantify candidate solutions contribution to quality requirements by using AHP. However, the approach assumes that there already exist many candidate architectures for handling NFRs so that it is difficult to apply this approach to selecting fine-grained architectural solutions. Similarly, Al-Naeem et al. (2005) tried to quantify the support of each architectural solution to each NFR using AHP, then searched optimised solutions that can minimise costs and time by applying Integer Programming Anderson et al. (2002). This approach heavily relies on experts experience and knowledge to elicit architectural approaches. Babu et al. (2011) suggested ANP and zero-one goal programming (ZOGP) Lee and Kim (2000) based approach to select appropriate architectural styles. They suggested seven selection criteria including performance, configurability and portability, analysed their interdependency with ANP, and formulated it with ZOGP to select architectural styles. They assumed that there is no interdependence between criteria and architectural styles. However, this assumption is not valid because many materials on software architecture point at the strength and weakness of the architectural styles in terms of the criteria (Bass et al., 2003; Buschmann et al., 1996). Zayaraz and Thambidurai (2005) also proposed a quantitative approach to selecting architecture styles in consideration of various stakeholders quality expectations to the system. They also depicted relationships between software quality and architectural styles. While they tried to capture all stakeholder s quality concerns, they illustrated their approach with hypothetical architecture styles. 7 Conclusion In this paper, we have presented an enhanced architectural tactic knowledge base for security quality attribute, and the approach to selecting security architectural tactics. This

8 52 S. Kim approach enables quantitative selection among architectural tactics from the tactic knowledge base in association with tactic cost and NFR satisfaction. Tactic cost estimation provides a mechanism to consider multiple aspects for tactic realisation. The equations for deciding appropriate tactics and sensitivity analysis facilitate to formalise tactic selection and increase confidence for the selected tactics. We believe that the suggested approach can be applied into selecting architectural tactics for diverse secure software systems such as enterprise systems as well as embedded systems (Shi and Perrig, 2004). Please note that all architectural solutions are not covered by the tactic knowledge base due to the evolution of the solution space. However the tactics specified in the tactic knowledge base can be automatically instantiated by using our previous work and tool support (Kim et al., 2009, 2010). Acknowledgement This research was supported by Next-Generation Information Computing Development Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Science, ICT & Future Planning (NRF- 2014M3C4A ). References Al-Naeem, T., Gorton, I., Babar, M.A., Rabhi, F. and Benatallah, B. (2005) A quality-driven systematic approach for architecting distributed software applications Proceedings of the 27th International Conference on Software Engineering, St. Louis, MO, pp Anda, B., Dreiem, H., Sjoberg, D.I. and Jorgensen, M. (2001) Estimating software development effort based on use cases experiences from industry, Proceedings of the Unified Modeling Language, Torento, Canada, pp Anderson, D., Sweeny, D. and Williams, T. (2002) An Introduction to Management Science: Quantitative Approaches to Decision Making, South-Western Educational Publishing, OH, USA. Babu, K.D., Govindarajulu, P., Reddy, A.R. and Kumari, A.A. (2011) ANP-GP approach for selection of software architecture styles, Internal Journal of Software Engineering(IJSE), Vol. 1, No. 5, pp Bachmann, F., Bass, L. and Llein, M. (2002) Illuminating the Fundamental Contributors to Software Architecture Quality, Technical Report CMU/SEI-2002-TR-025, Software Engineering Institute, Carnegie Mellon University. Bass, L., Clements, P. and Kazman, R. (2003) Software Architecture in Practice, 2nd ed., Addison Wesley, USA. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. and Stal, M. (1996) Pattern-Oriented Software Architecture: A System of Pattern, John Wiley, Chichester, UK. Clements, P., Kazman, R. and Klein, M. (2001), Evaluating Software Architectures: Methods and Case Studies, Addison Wesley Professional, USA. Falessi, D., Cantone, G., Kazman, R. and Kruchten, R. (2011), Decision-making techniques for software architecture design: a comparative survey, ACM Computing Surveys, Vol. 43, No. 4, pp.33:1 33:28. France, R., Kim, D., Song, E. and Ghosh, S. (2002) Role-Based Modeling Language (RBML) Specification V1.0, Technical Report , Computer Science Department, Colorado State University, Fort Collins, CO. Group, O.M. (n.d.) Unified Modeling Language, Kang, K., Cohen, S., Hess, J., Nowak, W. and Peterson, S. (1990) Feature-Oriented Domain Analysis (FODA) Feasibility Study, Technical Report CMU/SEI-90-TR-021. Kazman, R., Asundi, J. and Klein, M. (2001) Quantifying the costs and benefits of architectural decisions, Proceedings of the 23rd International Conference on Software Engieering, Toronto, Canada, pp Kim, S., Kim, D. and Park, S. (2010) Tool support for quality-driven development of software architectures, Proceedings of the 25th International Conference on Automated Software Engieering, Antwerp, Belgium, pp Kim, S., Kim, D., Lu, L. and Park, S. (2009) Quality-driven architecture development using architectural tactics, Journal of Systems and Software, Vol. 82, No. 8, pp Kim, S., Kim, D., Lu, L., Park, S. and Kim, S. (2011) Featurebased modeling approach for building hybrid access control systems, The 5th International Conference on Secure Software Integration and Reliability Improvement(SSIRI), Jeju, Korea, pp Lee, J. and Kim, S. (2000) Using analytic network process and goal programming for interdependent information system project selection, Computers and Operation Research, Vol. 27, No. 4, pp Lee, J., Kang, S. and Kim, C. (2009) Software architecture evaluation methods based on cost benefit analysis and quantitative decision making, Empirical Software Engineering, Vol. 14, No. 4, pp Ramachandran, J. (2002) Designing Security Architecture Solutions, Jonh Wiley, Chichester, UK. Reza, H., Jurgens, D., White, J., Anderson, J. and Perterson, J. (2005) An architectural design selection tool based on design tactics, scenarios and nonfunctional requirements, Proceedings of IEEE International Conference on Electro Information Technology(EIT), Lincoln, NE, pp Saaty, T. (1980) The Analytical Hierarchical Process, McGraw-Hill, New York, USA. Satty, T. (2005) Theory and Applications of the Analytic Network Process, 3rd ed., RWS Publications, PA, USA. Shi, E. and Perrig, A. (2004) Designing secure sensore networks, IEEE Wireless Communications, Vol. 11, No. 6, pp Svahnberg, M., Wholin, C. and Lundberg, L. (2003a) A quality driven decision-support method for identifying Software architecture candidates, International Journal of Software Engineering and Knowledge Engineering, Vol. 13, No. 5, pp Svahnberg, M., Wohlin, C., Lundberg, L. and Mattsson, M. (2003b) A quality-driven decision-support method for identifying software architecture candidates, International Journal of Software Engineering and Knowledge Engineering, Vol. 13, No. 5, pp Zayaraz, G. and Thambidurai, P. (2005) Software architecture selection framework based on quality attributes, Proceedings of IEEE Indicon, Chennai, India, pp Zhu, L., Aurum, A., Gortorn, I. and Jeffery, R. (2005) Tradeoff and sensitivity analysis in software architecture evaluation using analytic hierarchy process, Software Quality Journal, Vol. 1, No. 4, pp

9 A quantitative and knowledge-based approach to choosing security architectural tactics 53 Appendix A: Tactic specifications The One Time Password tactic is intended to support authentication by generating highly secure one-time password in the server and client at the same time (see Figure 10(a)). In the tactic, the authenticator generates a secure value when an authentication request is received, and shares the value with the client. Then, the client and authenticator use the same secure value to generate the same password. In this tactic, the client and authenticator are assumed to have the same algorithm for generating a password. The restoration tactic helps to restore a system from the crashed state. To restore the system, administrated data is maintained and restored separately from user data. In this way, administrative data can be better protected, and so is the system. The restoration tactic uses the state resynchronisation availability tactic, but separately for administrative data and user data as shown in the RestoreAdminState and RestoreUserData tactic semantics. The process is presented in Figure 10(b). The maintain data confidentiality tactic protects data from unauthorised modifications using encryption and decryption. Figure 10(c) shows the specification of the Maintain Data Confidentiality tactic. The MaintainDataConfidentiality semantic in the figure describes that an encryptor encrypts data before sending, and a decryptor decrypts once the encrypted data is received. This tactic is often used together with the ID/Password tactic to protect the login information. Figure 10 The one time password, restoration and maintain data confidentiality tactics: (a) the one time password tactic; (b) the restoration tactic and (c) the maintain data confidentiality tactic