Modeling Stakeholder / Value Dependency through Mean Failure Cost Anis Ben Aissa Faculty of Sciences of Tunisia University of Tunis El Manar 2092 Tunisia +216-98-692-415
[email protected]
Robert K. Abercrombie, Frederick T. Sheldon Oak Ridge National Laboratory Oak Ridge, TN 37831 USA +1-865-241-6537/576-1339
[email protected] [email protected]
ABSTRACT In [2], Boehm et al. discuss the nature of information system dependability and highlight the variability of system dependability according to stakeholders; the dependency patterns of this model are analyzed in [5]. In [1] we present a stakeholder dependent quantitative security model, in which we quantify security for a given stakeholder by the mean of the loss incurred by the stakeholder as a result of security threats; we show how this mean can be derived from the security threat configuration (represented as a vector of probabilities that reflect the likelihood of occurrence of the various security threats). We refer to our security metric as MFC, for Mean Failure Cost. In this extended abstract, we analyze Boehm's model from the standpoint of the proposed metric, and show whether/ to what extent/ and how our metric addresses the issues raised by Boehm's Stakeholder / Value definition of system dependability [2].
General Terms
Keywords Cyber Security Metrics, Risk Management, Information Security.
1. INTRODUCTION In this extended abstract, we content ourselves with a summary presentation of the formula for MFC, with minimal explanation, referring the interested reader to [1]. MFC = ST ◦ DP ◦ IM ◦ PT Where: MFC is a vector with as many entries as there are system stakeholders, and MFC (H) is the mean failure cost of stakeholder H.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. CSIIRW '10, April 21-23, Oak Ridge, Tennessee, USA Copyright © 2010 ACM 978-1-4503-0017-9 ... $5.00.
[email protected]
ST is a matrix with as many rows as there stakeholders and as many columns as there are distinct security requirements, and ST (H,R) is the stake that stakeholder H has in satisfying requirement R. We call this the Stakes matrix.
DP is a matrix with as many rows as there are distinct security requirements and as many columns as the system in question has components, and DP(R,C) is the probability that the system fails to meet requirement R if component C is compromised. We call this the Dependability matrix.
IM is a matrix that has as many rows as the system has components and as many columns as there are security threats under consideration (similar to fault models in reliability analysis), and IM(C,T) is the probability that component C is compromised if threat T has materialized. We call this the Impact matrix.
PT is a vector that has as many entries as there are threats in our threat model, and PT (T) is the probability that threat T materializes for a unit of operation time (e.g. one hour of operation).
Algorithms, Measurement, Performance, Design, Economics, Reliability, Experimentation, Security, Theory, Verification.
Ali Mili College of Computing Sciences New Jersey Institute of Technology Newark NJ 07102-1982 USA +1 973-596-5215
Matrices DP, IM and vector PT are dimension-less probabilities, but ST entries are quantified in terms of cost per unit of operation time, say $/hour; hence so are MFC entries. We build upon quantitative model of Abercrombie et al [3, 4] and Boehm’s model [2] a comparison between ST Matrix and the top level stakeholder/ value dependency matrix in Section 2. In section 3 we discuss how and by whom each aspect of this quantitative model is derived. In this way we can assess the cost effectiveness of security measures, and judiciously allocate the cost of implementing said security .
2. CHALLENGES IN STAKEHOLDER / VALUE DAPENDENCY In [2], Boehm et al raise five issues with the stakeholder/ value model, which we review in turn and show in what sense/ to what extent our model addresses these. For the sake of discussion, we adopt Boehm's classification of stakeholders, which includes the following classes:
Information suppliers, Systems dependents,
Information brokers, Information consumers o Mission critical, o Non mission critical, System controllers, Developers, Maintainers, Administrators, Acquirers. The Stakes matrix is filled, row by row, by the corresponding stakeholders. As for PR, we discuss below how to generate it.
2.1 Variability within Stakeholder Classes The top level stakeholder/ value dependency matrix given by Boehm et al in [2] table 1, is actually very similar to our model's Stakes matrix table 2,
cost / low probability) provided they pay an annual premium (low cost/ certainty). Hence if a stakeholder knows what cost he/ she would incur in case a given security requirement is violated, and with what probability that is likely to occur, he can compute the corresponding entry of the stakes matrix using the formula of an insurance company (minus the company's margin).
2.2 Variability with Operational Context The MFC model makes no explicit distinction between normal operational contexts and exceptional operational contexts; they are all specified by requirement clauses, and each stakeholder puts a price on each relevant requirement/ clause. For this same reason, the MFC model makes no distinction between reliability and safety, because it makes no explicit distinction between low-stake clauses and high-stake clauses of the requirements.
2.3 Variability with Maslow Need Hierarchy Maslow's theory of human needs provides that needs are ranked hierarchically, and are addressed / fulfilled in a specific order, from the bottom of the hierarchy going up. This theory also provides that the layers of the hierarchy are not independent, in the sense that fulfilling a high priority need may lower its priority. This theory may be relevant to our discussion in the sense that by assigning premiums to requirement clauses, a stakeholder is essentially defining a hierarchy of needs. As it is currently modeled, the MFC infrastructure does not reflect the interactions between layers of need, since the Stakes matrix is fixed. It could model layer interactions if the following features were provided:
First, a way to control whether a particular requirement clause is satisfied, and the extent to which it is satisfied, Second, a way for the stakeholder to assign an evolving premium to a requirement clause, dependent on he extent to which the clause is satisfied. Neither of these two features is straightforward.
2.4 Orthogonality of Requirements Clauses Table 1: Top- Level Stakeholder/value Dependency
Table 2: Stake matrix: Cost of failing a security requirement stakes in $/hour
We are mindful of the fact that the requirement clauses that represent the columns of the Stakes matrix (and the rows of the Dependency matrix) are not orthogonal. As a result, the formula of MFC, which computes the weighted sum of the costs associated with the requirements clauses may provide an upper bound of the mean failure cost, rather than the exact mean. Our model makes three distinct contributions to this discussion:
except for the following differences:
The stakes matrix is not dependent on a classification of the stakeholders; we can have a row for each stakeholder. The entries are real numbers, rather than values on a discrete scale. The entries are expressed in $/hour. The Stakes matrix is filled out by stakeholders, each filling out his/ her row. The question that arises then is: how does a stakeholder compute his/ her entries for the various security requirements? There is actually a whole sector of the economy that is devoted to the task of trading a high cost / low probability event against a low cost / high probability (certainty) event: the insurance industry insures policyholders against accidents (high
First, it gives meaning to the concept of orthogonality: Because our requirements are elements of a lattice (the refinement lattice), orthogonality can be defined in terms of lattice operations, by the condition that the meet of two elements is the universal lower bound of the lattice. Second, it provides an exact formula for mean failure cost when requirement clauses are orthogonal. The difficulty of non orthogonal requirement clauses is that the associated joint costs get counted multiple time; when they are orthogonal, then by definition there are no joint costs. Third, the lattice provides a framework for decomposing arbitrary requirements clauses into elementary terms that are orthogonal. While lattice theory provides for this possibility, the difficulty we have not resolved yet is how costs are
decomposed to parallel the decomposition requirements; this is currently under investigation.
of
the
3. THE RELATIONSHIP BETWEEN SECURITY MEASURES AND SECURITY IMPACTS The MFC formula MFC = ST ◦ DP ◦ IM ◦ PT Maps a threat configuration (PT) onto a vector of mean failure costs (MFC). When a security measure is deployed, its impact can be measured by considering how it affects the threat configuration (say, PT' instead of PT) and thereby how it affects (hopefully reduce) the MFC vector (MFC' instead of MFC). In [1] we have used the MFC differential as a measure of the effectiveness of the security measure at hand. This measure can, in turn, be used to support the following decisions:
The system manager can determine whether a security measure is worthwhile by matching its deployment cost against its benefit, represented in terms of reduced MFC (and represented in monetary terms). The decision can in fact modeled as a return on investment decision and quantified by ROI functions. The system manager can also use the MFC reduction of each stakeholder as a basis for distributing the cost of the security measure on the various system stakeholders; in [1] we have discussed alternative ways to do this. The individual stakeholders can use the cost sharing formula to assess how much the security measure costs them, and use the MFC reductions to quantify their respective gains from the security measure; using this information, they can then compute their ROI and determine whether the security measure benefits them individually.
4. CONCLUDING REMARKS In this extended abstract, we have discussed how our MFC model addresses the issues raised by [2] in relation to the Stakeholder/ Value approach to system dependability.
5. REFERENCES [1] Anis Ben Aissa, Robert K. Abercrombie, Frederick. T. Sheldon, and Ali Mili, “Quantifying Security Threats and Their Potential Impact: A Case Study,” in Innovation in Systems and Software Engineering: A NASA journal, 2010. [2] Barry Boehm, Li Guo Huang, Apurva Jain Ray Madachy, “The Nature of System Dependability: A Stakeholder/ Value Approach” Technical report, University of Southern California, Centre for Systems and Software Research, 2004. [3] R. K. Abercrombie, F. T. Sheldon, and A. Mili, “Synopsis of Evaluating Security Controls Based on Key Performance Indicators and Stakeholder Mission Value,” in 11th IEEE High Assurance Systems Engineering Symposium (HASE '08), Nanjing, China, 2008, pp. 479-482. [4] F. T. Sheldon, R. K. Abercrombie, and A. Mili, “Methodology for Evaluating Security Controls Based on Key Performance Indicators and Stakeholder Mission,” in Proceedings of 42nd Annual Hawaii International Conference on System Sciences (HICSS-42), Waikoloa, HI, 2009, pp. 10. [5] Di Wu, Mei He, Barry Boehm, Ye Yang, Supannika Koolmanojwong. “Analysis of Stakeholder / Value Dependency Patterns and Process Implications: A controlled Experiment” Proceeding of the 43rd Annual Hawaii International Conference on System Sciences. January 2010
