See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/220350192
`
`Modeling and analysis of security trade-offs – A goal oriented approach
`
`Article  in  Data & Knowledge Engineering · July 2009
`
`DOI: 10.1016/j.datak.2009.02.004 · Source: DBLP
`
`CITATIONS
`44
`
`2 authors, including:
`
`Eric Yu
`Southern University of Science and Technology
`
`273 PUBLICATIONS   11,766 CITATIONS   
`
`SEE PROFILE
`
`READS
`82
`
`Some of the authors of this publication are also working on these related projects:
`
`Conceptual Modeling View project
`
`hiBPM Process Architecture Modeling View project
`
`All content following this page was uploaded by Eric Yu on 29 March 2019.
`
`The user has requested enhancement of the downloaded file.
`
`Juniper Ex. 1041-p. 1
`Juniper v Huawei
`
`

`

`Modeling and Analysis of Security Trade-Offs – A Goal
`Oriented Approach
`
`Golnaz Elahi1, Eric Yu2
`1Department of Computer Science, University of Toronto, Canada, M5S 1A4
`gelahi@cs.toronto.edu
`2 Faculty of Information, University of Toronto, Canada, M5S 3G6
`eric.yu@utoronto.ca
`
`Abstract. In designing software systems, security is typically only one design
`objective among many. It may compete with other objectives such as
`functionality, usability, and performance. Too often, security mechanisms such
`as firewalls, access control, or encryption are adopted without explicit
`recognition of competing design objectives and their origins in stakeholders’
`interests. Recently, there is increasing acknowledgement that security is
`ultimately about trade-offs. One can only aim for “good enough” security,
`given the competing demands from many parties. This paper investigates the
`criteria for a conceptual modeling technique for making security trade-offs. We
`examine how conceptual modeling can provide explicit and systematic support
`for modeling and analyzing security trade-offs. We examine several existing
`approaches for dealing with trade-offs and security trade-offs in particular.
`From analyzing the limitations of existing methods, we propose an extension to
`the i* Framework for security trade-off analysis, taking advantage of its multi-
`agent and goal orientation. The method was applied to several case studies used
`to exemplify existing approaches. The resulting models developed using
`different approaches are compared.
`
`Keywords: Security Trade-offs, Trade-off Analysis, Conceptual Modeling,
`Goal Modeling, Goal Model Evaluation.
`
`1 Introduction
`
`“Security is about trade-offs, not absolutes.”
`
`
`
`
`
`Ravi Sandhu
` In designing software systems, security is typically only one design objective
`among many. Security safeguards may conflict with usability, performance, and even
`functionality. For example, if usability concerns are not addressed in the design of a
`secure system, users respond by circumventing security mechanisms [1, 2]. Achieving
`a balance between the intrusiveness of security mechanisms [3] and usability goals is
`an important consideration in designing successful secure software systems. Security
`goals can have their own contradictions because confidentiality, integrity, privacy,
`accountability, availability, and recovery from security attacks often conflict
`fundamentally. For example, accountability requires a strong audit trail and end-user
`authentication, which conflicts with privacy needs for user anonymity [3].
`
`Juniper Ex. 1041-p. 2
`Juniper v Huawei
`
`

`

`Ultimately, security is about balancing the trade-offs among the competing goals of
`multiple actors to achieve a “good enough” security. In current practice, security
`designers often adopt security mechanisms such as firewalls, access control, or
`encryption without explicit recognition of, and systematic treatment of competing
`design objectives originating from various stakeholders. While risk assessment
`methods such as [4, 5] address balancing the costs and effects of security solutions to
`achieve good-enough security, assuming security costs and benefits are measurable,
`this paper focuses on qualitatively analyzing trade-offs that security goals and
`alternative security solutions impose on other quality objectives.
`This question then arises: what conceptual modeling techniques can be used to help
`designers analyze security trade-offs to achieve “good enough” security? To our
`knowledge, existing conceptual modeling techniques for modeling security-related
`information and trade-off analysis techniques do not raise and answer this question.
` The remaining parts of this paper are structured as follows. In Section 2, we
`consider the criteria for a suitable conceptual modeling technique for dealing with
`security trade-offs. In Section 3, a number of existing approaches to security trade-off
`analysis are reviewed and compared to the introduced criteria. From analyzing the
`limitations of existing methods, in Section 4, we propose a conceptual modeling
`technique for modeling and analyzing security trade-offs in a multi-actor setting. The
`meta-model of security concepts is introduced as well. In Section 5, we describe the
`goal model evaluation and trade-off analysis technique. Section 6 summarizes the
`results of some case studies. Finally, Section 7 discusses the results and limitations of
`the approach.
`
`2 Conceptual Modeling Criteria for Security Trade-offs Analysis
`
`Trade-off analysis is a systematic examination of the advantages and disadvantages
`of requirements and/or design choices for a system to achieve the right balance among
`several competing goals [6]. When some goals are not sufficiently satisfied, designers
`need to explore further alternatives that can better achieve those goals, without
`detrimentally hurting the others. Each potential solution can have positive effects on
`the achievements of some goals while having negative effects on others. A careful
`and systematic process for security trade-off analysis can be very challenging,
`because to resolve security trade-offs one need to consider competing goals of
`multiple stakeholders, risk of attacks, security countermeasure, and their impacts.
`In this context, we ask: what are the criteria for a proper conceptual modeling
`technique for dealing with security trade-offs? What concepts need to be modeled,
`and how are they involved in the trade-off analysis? In many engineering disciplines,
`trade-offs are analyzed using detailed mathematical models. However, in designing
`secure software systems, multiple stakeholders with diverse, incommensurable, and
`competing goals impose security trade-offs that cannot be reduced easily to
`mathematical functions. Conceptual modeling techniques, on the other hand, offer the
`possibility of analyzing the factors that contribute to trade-offs and their structural
`compositions and relationships.
`
`Juniper Ex. 1041-p. 3
`Juniper v Huawei
`
`

`

`The conceptual foundation for trade-off modeling needs to convey the idea that
`attempting to improve one quality can adversely affect other quality objectives.
`Therefore, the conceptual modeling technique needs to provide conceptual constructs
`to express 1) Design goals and objectives, alternative operationalizations to achieve
`the objectives, and the impacts of alternative operationalizations on goals and
`solutions; 2) Actors who seek alternative design solutions to achieve their individual
`goals and objectives. Furthermore, security objectives are not affected only by
`alternative security solutions and operationalizations of quality goals. In case of
`security goals, the trade-off constructs need to express; 3) Threat of external/internal
`actors and vulnerabilities that impact security and other requirements.
`1) Design Goals and Objectives: Security and other trade-offs take root from
`conflicts among design objectives that originate from stakeholder goals. While
`selecting a security solution among alternatives is difficult, the more fundamental
`problem is that designers need to decide about alternate security mechanisms subject
`to multiple factors such as cost, time-to-market, various non-functional requirements
`(NFRs), security policies, standards, and individual goals of various stakeholders.
`Therefore, the conceptual foundation for expressing trade-offs needs to provide means
`for modeling stakeholders’ goals and design objectives. By modeling the alternative
`solutions
`that operationalize
`the objectives and structuring
`the
`impact of
`operationalizations on the goals, one can analyze what causes trade-offs among
`objectives. To resolve the trade-offs, the model needs to express the extents to which
`design objectives are satisfied or denied. The extents or measures could be
`quantitative or qualitative. Quantitative approaches can greatly simplify decision
`making, but can be difficult to apply due to lack of agreed metrics, subjective quality
`requirements, or unavailability of accurate measures in the early stages of the system
`development. The modeling technique should be able to support analysis despite
`inaccurate, incomplete, or subjective knowledge about goals as well.
`2) Actors: Design objectives typically originate from multiple sources and
`stakeholders such as the system’s users, administrators, top managers, project
`managers, and customers. The conceptual modeling technique needs to consider
`multiple actors that impose competing goals on the designer. The modeling technique
`should be able to model trade-offs that occur within a single actor or across multiple
`actors.
`3) Security Specific Concepts: Security requirements are needed because of the
`threat of malicious actors. Achievement of security objectives are affected by threats
`of internal or external actors and existence of vulnerabilities in system design. Trade-
`offs cannot be resolved without relating the impacts of attacks and exploitation of
`vulnerabilities on the systems functionality and quality objectives. Therefore, the
`conceptual modeling technique for modeling security trade-off needs to model
`security specific concepts such as threats and vulnerabilities. In addition, decision
`makers need an expression of the security benefits of the solutions [7] to compare
`their trade-offs. Hence, the modeling technique should provide means to model to
`what extent attacks are successful, how attacks affect stakeholders’ and design goals,
`and how countermeasures protect the stakeholders’ goals against the threats.
`
`Juniper Ex. 1041-p. 4
`Juniper v Huawei
`
`

`

`3 Existing Approaches to Security Modeling and Trade-offs
`
`Security requirements engineering frameworks derive security requirements based
`on security-specific concepts such as assets, threats, and vulnerabilities, taken from
`the security engineering domain. To incorporate security-related aspects into the
`requirements engineering and software design processes, different approaches tackle
`the security requirements from different viewpoints.
`Attack Modeling Techniques. Some approaches such as Attack Tree [8] and
`Attack Graph [9] focus on modeling attacks and adversaries. Approaches such as
`misuse cases invert the normal functionalities of the system to express the misuses
`and malicious behavior. As proposed by Sindre and Opdahl [10], a misuse case is a
`use case from the point of view of a hostile actor which poses a threat to the system.
`They claim that looking at systems from a misuser perspective increases the chance of
`discovering threats that would otherwise be ignored.
`The misuse case approach is adopted by Alexander [6] for trade-off analysis.
`Alexander asserts that the misuse case approach accurately visualizes the structure of
`the situation in a way that emphasizes the essential points of conflicts and trade-offs;
`therefore, use/misuse case representation may make trade-off analysis and human
`judgments more informed and systematic. Another similar approach is the notion of
`abuse case, proposed by McDermott and Fox [11], which helps to model a type of
`interaction between a system and actors where the results of the interaction are
`harmful to the system.
`Another example of inverting normal behavior for analyzing security attacks is the
`notion of anti-goals. Van Lamsweerde [12] proposes a goal-oriented framework for
`generating and resolving obstacles to achieve goals. The malicious obstacles, called
`anti-goals, are set up by the attackers to threaten security goals. The anti-goals are
`refined to form a threat tree, in which the leaf nodes are either software vulnerabilities
`or anti-requirements. New
`security
`requirements are
`then obtained as
`countermeasures.
`
`Security Goals and Requirements Modeling. Some approaches focus on
`modeling security-related information, security requirements, and security goals. The
`UMLsec modeling language [13] is an example of a security-specific conceptual
`modeling approach for modeling security requirements and security-specific
`information. The main uses of this approach are first, to encapsulate knowledge and
`make it available to developers in the form of a widely-used design notation, and
`secondly, to provide formal evaluation to check if the constraints associated with the
`UMLsec stereotypes are fulfilled in a given specification.
`SecureUML is another UML-based modeling language for the model-driven
`development of secure distributed systems. SecureUML takes advantage of Role-
`Based Access Control (RBAC) for specifying authorization constraints by defining a
`vocabulary for annotating UML models with information relevant to access control
`[14]. The SecureUML meta-model is defined as an extension of the UML meta-
`model, and the concepts of RBAC are represented directly as meta-model types.
`
`Goal and Agent Oriented Modeling and Analysis. In addition to attacks and
`protection aspects, security requirements are derived from analysis of interactions and
`
`Juniper Ex. 1041-p. 5
`Juniper v Huawei
`
`

`

`dependencies of social actors in the organizational contexts [17, 18]. Such
`considerations to derive security requirements bring other related issues such as trust,
`ownership, permission and delegation among actors to the security requirements
`modeling and analysis process [19, 20].
`Agent and goal oriented approaches describe systems as intentional agents that
`depend on each other or compete to achieve their goals. In recent years, such
`approaches in requirements engineering have emerged for analyzing and designing
`complex information systems. Examples of goal oriented frameworks are KAOS [21]
`and the NFR framework [22]. Agent oriented approaches include the i* [23] and
`Tropos [24] frameworks. Several approaches such as [17, 18, 19, 25, 26, 27] propose
`frameworks for modeling and analyzing security concepts by taking advantage of
`agent and goal oriented techniques. The majority of these approaches employ
`qualitative goal evaluation, while [25] suggests a quantitative approach for analyzing
`security requirements.
`
`Risk Analysis and Decision Making. Risk analysis has been considered as an
`important activity of security requirements engineering and secure software design.
`The risk-based security requirements engineering framework in [15] is concerned
`with integrating requirements engineering practices with security engineering and
`interleaving requirements and architecture design by adopting risk analysis practices
`as a key activity. The approach aims to analyze the impacts of threats on the business
`by linking the risk impacts with the business value.
`The CORAS framework [4] provides another UML profile for risk assessment. The
`proposed profile defines UML stereotypes and rules for specialized UML diagrams to
`support of model-based risk assessment. Asset diagram is proposed to identify assets;
`threat diagram captures unwanted incidents causing loss in asset value. State analysis
`diagram is proposed to estimate and document the frequency and consequence of the
`unwanted incidents, and treatment diagrams are models extended with specialized use
`cases representing treatments.
`Another approach for deciding on security requirements and design is proposed in
`[16], where probabilistic inference on security influence diagrams and Bayesian
`Networks are used to support trade-off analysis. In this work, authors discuss the
`criteria of the language for security requirements modeling and analyzing. They assert
`that the language should be able to represent decision's maker goals, domain of
`control, and causal relation between goals (indirect and controlled).
`
`The above survey of security-related modeling notations and security requirements
`frameworks reveals that existing security conceptual modeling techniques do not
`consider trade-offs between security and other quality objectives explicitly. While
`trade-off analysis is considered in the misuse case approach of Alexander [6],
`use/misuse cases do not express quality requirements, their operationalizations, and
`impacts. More generally, trade-off analysis has been considered in a few software
`engineering research efforts. Trade-offs are mostly considered between alternative
`architecture and design solutions in contributions such as Architecture Tradeoff
`Analysis Method (ATAM) [28] and Cost-Benefit Architecture Analysis (CBAM)
`[28], Aspect-Oriented Risk-Driven Development (AORDD) [29], and Security
`Verification and security solution Design Trade-off analysis (SVDT) [7]. Although
`
`Juniper Ex. 1041-p. 6
`Juniper v Huawei
`
`

`

`these approaches do not provide a conceptual modeling framework for expressing
`trade-offs, studying the decision making process in these approaches is of interest for
`extracting the criteria for a conceptual modeling framework that enables trade-off
`analysis.
`In what follows, we study Architecture Tradeoff Analysis Method (ATAM) and
`Cost Benefit Analysis Method (CBAM) [28] as general purpose and widely used
`architectural trade-off analysis methods which consider security as one of the quality
`scenarios. SVDT and AORDD are studied as security-specific methods and the
`representatives of quantitative analysis methods based on probabilistic reasoning.
`Since the proposal for security trade-offs modeling and analysis in this paper is based
`on expressing competing goals of multiple actors, we finally study whether the
`existing agent and goal oriented approaches provide the required conceptual modeling
`basis for expressing trade-offs.
`
`3.1 ATAM and CBAM essence
`
`Bass et al. [28] introduce a framework for modeling quality attributes and
`architectural alternative designs using the notion of scenarios and tactics respectively.
`A quality attribute scenario is a quality-attribute-specific requirement, and consists of
`six parts: Source of stimulus, Stimulus, Environment, Artifact, Response, and
`Response measure. Achievement of quality scenarios relies on tactics.
`ATAM is a labor-intensive evaluation method to analyze whether an architecture
`decision satisfies particular quality goals. ATAM helps designers to prioritize
`scenarios and evaluate alternative tactics using a “Quality Attribute Utility Tree”.
`Scenarios that have at least one high priority of importance or difficulty are chosen
`for a detail analysis to examine if the selected tactics satisfy the scenario.
`The result of the ATAM analysis is an “Architectural Approach Analysis” table for
`each quality scenario. In this table, evaluators identify and record sensitivity, tradeoff,
`risks and non-risks points of alternative tactics for satisfying a scenario. Sensitivity
`and tradeoff points are architectural decisions that have effect on one or more quality
`attributes, the former positively and the latter negatively. In ATAM, a risk is defined
`as an architectural decision that may lead to undesirable consequences. Similarly, a
`nonrisk is an architectural decision that, upon analysis, is considered safe. The
`conceptual elements related to trade-offs in ATAM may be captured in a meta-model
`as in Fig. 1.
`CBAM [28] picks up where ATAM leaves off. It takes ATAM outputs as input and
`adds cost factors to the trade-off analysis. CBAM uses scenarios as a way to
`concretely express specific quality attributes. Stakeholders vote for scenarios to select
`the top priority scenarios for further analysis. Stakeholders assign the value for
`calculating stimulus-response utility per each scenario, which helps to create the
`utility-response curves. The utility is based on the importance of each scenario and its
`response value. The overall utility is combined with the project cost of an
`architectural strategy to calculate the final Return On Investment (ROI) measure. The
`ROI value for each architectural strategy is the ratio of the total benefit to the cost.
`Using the ROI value, the architectural strategies can be rank-ordered and compared,
`and a final decision made.
`
`Juniper Ex. 1041-p. 7
`Juniper v Huawei
`
`

`

`Fig. 1. A Meta-model of trade-off elements in the ATAM.
`
`
`
`3.2 SVDT and AORDD Approach
`
`
`Houmb et al. [7] propose the Security Verification and security solution Design
`Trade-off analysis (SVDT) approach using UMLsec for modeling security solutions
`and Bayesian Belief Network
`(BBN) as
`the basis of
`trade-off analysis
`implementation. UMLsec is used to verify if the design solutions satisfy the security
`requirements. Design solutions that pass the verification are then evaluated using
`security solution design trade-off analysis.
`The SVDT approach is a complementary work on Aspect-Oriented Risk-Driven
`Development (AORDD) framework [29]. AORDD framework provides risk
`assessment process and cost-benefic trade-off analysis. Both SVDT and AORDD
`trade-off analysis methods compute Return on Security Investment (RoSI) using
`BBN. Fig. 2 illustrates the relationship between the main concepts involved in
`AORDD risk assessment, which specifies the structure of the inputs to the AORDD
`cost-benefit trade-off analysis and the topology of the BBN.
`The result of risk assessment is a list of misuses which need security treatments.
`This list and a list of alternative security treatments are fed into the BBN to compute
`the RoSI. RoSI is computed using a set of trade-off parameters, such as priorities,
`security risk acceptance criteria, standards, laws and regulations, policies, business
`goals, budget, and time-to-market. RoSI for a particular solution is derived by
`evaluating the effect and cost of the solution against the security requirements, and
`the misuse impact and frequency [7].
`
`Juniper Ex. 1041-p. 8
`Juniper v Huawei
`
`

`

`Fig. 2. ARODD risk assessment main concepts and relation [29]
`
`
`
`3.3 Secure Tropos/i*
`
`The proposed approaches in [17, 18, 19, 26, 27] take advantage of the i* and
`Tropos frameworks for modeling and analyzing security requirements. In these
`approaches, systems are modeled as intentional agents collaborating or competing
`with each other to achieve their goals. Security issues arise when some actors, while
`striving to achieve their own goals, intentionally or unintentionally threaten other
`actors’ goals; therefore, agent and goal oriented approaches provide a suitable basis
`for dealing with security.
`The approach in [17] suggests using relationships among strategic actors for
`analyzing security requirements. In [17], potential attackers of the systems are
`distinguished from other actors. Liu et al. [18] analyze attackers, dependency
`vulnerabilities among actors, countermeasure, and access control using the i*
`modeling framework. In [19], a framework known as Secure Tropos for modeling
`and analyzing security requirements based on the notions of trust, ownership, and
`permission delegation is developed. In [26, 27], the “threat” and “security constraint”
`modeling elements are added to the i* meta-model. Threat elements are employed in
`the “security diagram” to express potential violation against the security goals, and
`security constraints are used to impose security requirements on actors’ dependencies.
`The meta-model of related concepts to the Tropos goal model, which is the core of all
`these approaches, is depicted in Fig. 3.
`
`Juniper Ex. 1041-p. 9
`Juniper v Huawei
`
`

`

`Fig. 3. Part of Tropos meta-model for goals and related concepts [30]
`
`
`
`3.4 Discussion and Limitations of the Surveyed Approaches
`
`ATAM and CBAM provides a labor-intensive method for deciding on alternative
`architecture design, and AORDD and SVDT are designed for comparing alternative
`security solutions based on the solution costs and benefits, potential misuse effects
`and probability, and trade-off parameters. In these two groups of work, trade-offs are
`expressed at different levels of explicitness. In the ATAM and CBAM approaches,
`trade-offs are listed in a table rather than expressed by models, formulas, or a
`computation mechanism. Trade-offs are analyzed by an architecture expert who
`evaluates each design tactic in terms of its costs and benefits. In the AORDD and
`SVDT methods, the trade-off model is developed by the BBN designer instead of the
`target system designers and analysts. In this way, a single fixed formulation of
`relationships between trade-off parameters are reused for multiple projects.
`
`In the ATAM approach, trade-offs among quality scenarios and tactics in the
`“Architectural Approach Analysis” table are expressed indirectly and implicitly. In
`this table, for each scenario alternative tactics are analyzed. However, the impacts of
`tactics are analyzed on one specific scenario rather across multiple scenarios.
`Moreover, ATAM does not incorporate the degree of sensitivity or trade-off between
`tactics and qualities in the analysis procedure, since the “Architectural Approach
`Analysis” table does not provide means for expressing the impact of tactics on stimuli
`(attacks) and does not specify the consequences of applying a solution on other
`quality scenarios. The ATAM process does not separately capture the impact of each
`tactic on stimuli of security scenarios (attacks).
`ATAM does not consider cost as a trade-off factor that usually has the highest
`priority over the other factors. CBAM is proposed to address this weakness. The
`CBAM approach to trade-off analysis requires the designer to obtain accurate
`quantitative measures of current response and expected response of architectural
`strategies for each affected scenarios. The major obstacle toward applying CBAM
`would be unavailability and inaccuracy of such measures in the early stages of
`development and lack of agreement on metrics and measurement methods.
`
`Juniper Ex. 1041-p. 10
`Juniper v Huawei
`
`

`

`CBAM relies on the utility values gathered from votes of various stakeholders
`through consensus. In this way, CBAM resolves the conflict of goals among
`stakeholders by computing the ROI of each strategy based on their votes for utility of
`each strategy. However, the accuracy and reliability of the utility values and
`stakeholders’ confidence in their votes is an issue in validity of CBAM analysis.
`Finally, the ATAM and CBAM methods are not designed for security trade-off
`analysis and the impact of other forces such as attacks and vulnerabilities are not
`explicitly incorporated into the analysis.
`
`SVDT and AORDD are specifically designed for making security trade-offs,
`relying on a pre-defined probabilistic reasoning model of trade-offs in the form of a
`BBN. This requires the software designers to obtain quantitative measures or
`qualitative scales of the impacts of the misuses and solutions . The major limitation is
`the inaccuracy or unavailability of quantitative data on the impact of misuses and
`solutions especially in the early stages of the development lifecycle.
`Generally, the suggested BBN topologies in [7] do not consider a general source of
`trade-off inputs such as NFRs and functionalities. The single value of RoSI does not
`indicate what quality objectives are achieved or failed. The input trade-off parameters
`of the designed BBN are limited to factors such as budget, time-to-market, laws and
`regulation, which had been designed and incorporated into the BBN topology. It is
`assumed that a single topology that is designed for trade-off analysis would be
`applicable in every context.
`The final result of the trade-off analysis is a number (RoSI), indicating the return
`on investment for each security solution. Although automatic computation of RoSI
`using the trade-off inputs and parameters fed into the BBN is efficient and desirable,
`the designers and analysts do not have explicit traces to follow what aspects of the
`design caused the difference in the final result of RoSI. In other words, the only
`metric to compare two alternative security solutions is the RoSI values for those
`solutions, which makes it difficult to judge the impact of multiple contributing factors
`of alternative different design solutions. In addition, if the system designers and
`analysts need to trace the impact of changes in BBN parameters, they need to learn
`about the topology of the BBN which they have not designed.
`
`Table 1 summarizes a comparison of the ATAM/CBAM and AORDD/SVDT
`approaches based on the evaluation criteria discussed in section 2. The third column
`compares the conceptual modeling constructs that agent and goal oriented approaches
`provide for expressing trade-offs among design objectives.
`
`
`Agent and goal oriented approaches such as [17, 18, 19, 26, 27] provide the
`conceptual basis for security trade-off modeling and analysis. However, a mechanism
`for security trade-offs analysis is not elaborated in these frameworks. The method in
`[18] lacks a direct and explicit way to model the competition among malicious and
`non-malicious actors’ goals. In this approach, trade-off modeling among goals is
`limited to the non-malicious actors. The proposed framework in [19] does not support
`modeling malicious behavior. In [26, 27], threats are modeled in the security diagram,
`but the model does not trace security goals or threats to the source actors. This
`approach does not consider modeling the relation between countermeasures and
`
`Juniper Ex. 1041-p. 11
`Juniper v Huawei
`
`

`

`attacks. Although security trade-offs can be expressed by the goal oriented methods,
`the approaches overviewed do not consider security trade-offs explicitly.
`
`Table 1. A comparison of existing approaches based on the criteria of the conceptual modeling
`technique for security trade-off analysis
`
`Method/
`Requirements
`Design objectives
`and goals
`Relations between
`objectives
`
`ATAM/CBAM
`Expressed in terms of
`scenarios
`Not considered
`explicitly
`
`Alternative design
`solutions
`
`Expressed in terms of
`tactics
`
`Utility tree in ATAM
`doesn’t capture the
`contributions of
`scenarios on each other/
`CBAM considers by
`utility and side effects
`of an architectural
`strategy
`Not considered in
`ATAM/ Expressed in
`terms of Utility-
`Response Curves in
`CBAM
`
`Is not dealt with
`
`Expressed implicitly by
`multiple stimuli sources
`in ATAM. In CBAM
`multiple stakeholders
`votes are taken into
`account
`Not considered
`
`Impacts of
`objectives and
`solutions on each
`other
`
`Extents of
`objectives’
`achievement
`
`Inaccurate or
`incomplete
`knowledge
`
`Multiple actors
`
`Security specific
`forces
`
`SVDT/AORDD
`Considered by fixed
`BBN parameters
`Considered in the fixed
`BBN topology
`Each alternative security
`solution is analyzed by
`the UMLsec reasoning
`and BBN cost benefit
`analysis
`
`i*/Tropos
`
`Modeled by goals
`Modeled by
`contribution links
`One goal model
`can express and
`evaluate
`alternative design
`solutions
`
`Encoded in the BBN
`topology
`
`Modeled by
`contribution links
`
`Expressed by parameters
`fed into the BBN and
`mostly quantitatively
`
`In terms of probability
`density functions (pdf) in
`BBN
`
`Expressed
`qualitatively by
`goal model
`evaluation labels
`Expressed by
`contribution type
`Unknown
`
`The BBN topology can
`contain parameters from
`multiple actors’ point of
`interest
`
`In terms of
`agents, actors,
`roles, and
`positions
`
`Some concepts are
`modeled
`
`Some concepts
`are modeled
`
`4 The Security Trade-offs Modeling Notation
`
`We propose a meta-model of security concepts for systematically addressing
`security trade-offs, considering the limitations of existing approaches and reviewing
`well known security knowledge sources such as NIST guidelines, standards like [31],
`CERT [32], and widely used textbooks such as [33, 34]. Fig. 4 depicts the meta-
`
`Juniper Ex. 1041-p. 12
`Juniper v Huawei
`
`

`

`model of security concepts where the core concepts are actors and goals. Actors
`employ mechanisms or attacks to achieve