CRAC++: Risk-Based Confidentiality Requirements Specification for Outsourced IT Systems

Content

1. Introduction

For any company it is important to maintain control over their information technology (IT) assets. For companies involved in outsourcing this is an additional challenge, because the IT infrastructure of the provider of the services usually differs from that of the client (Morali & Wieringa, 2010). The effect of this is that the service level agreement (SLA) between the provider and client need specific requirements to protect security of their information and prevent disclosure of unauthorized agents.

Security requirements are further categorized as non-functional requirements. Within security requirements confidentiality is considered the most difficult aspect (Gürses et al., 2005). Confidentiality receives various definitions throughout literature, although the essence of the definitions is the same. In the paper of Onabajo and Jahnke (2006a, p.1) confidentiality is defined as: “an aspect of a system’s security requirements aimed at preventing unauthorized use of personal corporate data.” Due to initial requirements analysis often being of insufficient quality, an increasing amount of security violations has been reported (Gürses et al., 2005). According to their research, this can be put down to a lack of systematic methods for this analysis. In a situation with outsourced IT assets, the challenge of preventing disclosure of confidential information becomes greater.

Morali, Zambon, Etalle and Wieringa (2009) from the University of Twente developed the Confidentiality Risk Assessment and Comparison (CRAC) method. This in turn is extended into the CRAC++ method by Morali and Wieringa (2010). The main difference between CRAC and CRAC++ is that the latter has an extra focus on identifying confidentiality requirements that are not implied by both provider and client, resulting in a specific list of valuable requirements for future SLA’s.

CRAC++’s origin has an academic background, based on several papers published by members of the University of Twente. Morali is a PhD? student at the University of Twente. The CRAC++ method ultimately resulted in a PhD? dissertation by Morali (2010). Wieringa is a professor at the University of Twente, further active at the University as head of the Computer Science Department and as member of the Information Systems Group.

The primary use of the CRAC++ method is performing confidentiality risk analysis on information flow and unauthorized access of the network between two IT infrastructures. It is based on the risk of unauthorized access to confidential information. The CRAC++ method consists of the following four steps: Step 0: Elicit Input Data. The goal of this step is to collect the data necessary to support the following steps of the method. This process describes an organization’s IT architecture and its assets and components. Furthermore, it looks at the known vulnerabilities and threat agents, and the current confidentiality requirements.

Step 1: Assessing Total Impact of Disclosure per Component Information Flow Graphs (IFG’s) are created to give a visual representation of the information flows through the networks of the organization. All the IFG’s combined give an overview of the available information per component. This way, an assessment can take place on the value of the information that resides in a particular component. Step 2: Assessing Protection Level per Component This step investigates the ease for a threat agent to disclose information from a component. This is done by creating an Attack Propagation Graph (APG) for each threat agent. The APG’s depict how an attacker can access information on components by taking paths through the network. Step 3: Determining Candidate Confidentiality Requirements In the final step of the method, confidentiality requirements not yet known by both parties of the SLA are being investigated to determine whether they should be added to future SLAs. This is performed by comparing the protection levels of the components assessed in Step 1 by the likelihood that threat agents access those components (Step 2). The necessary confidentiality requirements for the SLA can be formulated. The main roles or stakeholders during the procedure of this method could consist of a company’s security officer, system architect and security architect. Furthermore, a confidentiality expert is required in order to make quality judgments during several activities.

2. Example

To show how the CRAC++ method can be utilized, an example will be shown in this chapter. First, a plan has to be created together with a company on applying CRAC++ in an outsourcing environment. The process will be undertaken step by step according to the steps described in the introduction.

The process starts with Step 0 of CRAC++, in which data is gathered in preparation for the other steps. This data includes classified information assets with instances, threat agents, IT architectural components, relevant vulnerabilities and confidentiality requirements. A relevant vulnerability can for example be a weak authentication system on end user computers that the company is aware of. The list of the confidentiality requirements concerns existing requirements from the company, as well as from the client that this method is utilized with.

In Step 1, IFG’s are created to depict how information flows through the networks (figure 1). A node (e.g. N1) stands for a component that contains valuable information. The connecting arrows or edges between the nodes show the information flows. For instance, if N1 would be a client database and N6 an end user computer, the client information first has to flow through the server (N3) before it is received by the end user computer. Combinations of the IFG’s are used to analyze which information is capable of existing in a certain component. The confidentiality expert and stakeholders have to estimate the value of the information of a component, also referred to as the total impact. This total impact gives an indication of the value of the information in a situation where it would be lost or disclosed through unauthorized access. The deliverable of this step is a list of confidentiality-critical components, which are components with a value over a specified critical threshold.

Figure 1: Information Flow Graph	Figure 2: Attack Propagation Graph

Step 2 is in place to determine the likelihood that a situation from Step 1 would occur, based on the existing confidentiality requirements. This will be assessed by the confidentiality expert and stakeholders of the company. APG’s are created for the threat agents listed in Step 0 (figure 2). They depict the paths a threat agent can take to reach valuable information. The nodes represent components such as a server or database. The components are given a confidentiality level, expressed in a range from very low to very high. The threat agents can be structured in groups, such as insiders or malicious insiders. The protection level for the threat agents is expressed in fractions, such as ½ or ¾. The graph starts at an entry point, in this example N8. This means that a possible attacker begins his attack at this component, for instance on an end user computer. The attacker then has to go through several nodes before reaching the end goal, which is accessing the valuable node (N1) at the top. The numbers on the edges indicate the difficulty for the attacker to go from one node to another (vl = very low, l = low, m = medium etc.). This assessment can determine which components require a higher protection level.

Step 3 is the main changed step from CRAC to CRAC++. It looks into the confidentiality requirements from the client or provider that are not yet recognized by existing confidentiality requirements from the other party for possible inclusion of future SLAs. The confidentiality expert can now compare the critical information components from Step 1 with the chances of occurring from Step 2. At the end of the process CRAC++ provides the client with the right information regarding confidentiality that supports decisions on confidentiality requirements.

3. Process-Deliverable Diagram

In figure 1 a Process-Deliverable Diagram (PDD) is shown, which depicts the CRAC++ method from Morali and Wieringa (2010). The PDD is drawn according to the modeling conventions described in Weerd and Brinkkemper (2008) and is used to display the meta-model of CRAC++. Within the PDD, the following four steps of CRAC++ can be found in the four open activities on the left:

• Step 0: Elicit Input Data
• Step 1: Assessing Total Impact of Disclosure per Component
• Step 2: Assessing Protection Level per Component
• Step 3: Determining Candidate Confidentiality Requirements

Each step or activity has several sub activities, which are placed within the open activities. The roles for an activity are displayed under the activity name, unless it is not clear which roles perform the activity. The sub activities represent parts of the steps from CRAC++. They create deliverables, which are displayed on the right side of the PDD as the concepts of the model. The activities and concepts are given further descriptions in their respective tables. These can be found in this document after the PDD.

ARCHITECTURAL INFORMATION is drawn as an open concept. Being the final deliverable of the CRAC++ method, it consists of most of the data created by the other concepts. If the method is performed correctly it contains sufficient information to reason the consequences of including or dropping a certain confidentiality requirement from an SLA.

Further note that the data from the concept COMPONENT is used throughout Step 3 and Step 4. Due to limited drawing possibilities and the importance of overview in the PDD, these arrows are not drawn. The data from COMPONENT is input for the process of constructing APG’s in Step 3, as well as determining the needed confidentiality requirements in Step 4. A template for the concept COMPONENT is given in Appendix A.

Figure 3: Process-Deliverable Diagram of the CRAC++ method by Morali & Wieringa (2010)

3.1 Activity Table of CRAC++

The activity table represents all activities from the left side of the PDD model in figure 1. The activities are divided in sub activities which each have their own description, including which concept they create.

Activity	Sub activity	Description
Elicit Input Data	Identify confidentiality requirements	List identified confidentiality requirements from the client and provider as CONFIDENTIALITY REQUIREMENT
	Identify relevant vulnerabilities	Identify vulnerabilities that need to be mitigated according to outsourcing requirements as a VULNERABILITY
	Classify threat agents	Potential attackers who access information assets unauthorized are identified and classified as a THREAT AGENT
	Identify IT architectural components	Identify hardware, software or network locations as a COMPONENT
	Classify Information Assets	Valuable functional and organizational data are identified and classified in the concept INFORMATION ASSET
Assessing Total Impact of Disclosure	Construct Information Flow Graphs	Use data from COMPONENT and INFORMATION ASSET to construct an INFORMATION FLOW GRAPH
	Assess total impact	Assess impact of disclosing information on a component as TOTAL IMPACT
	Identify confidentiality-critical components	Components for which unauthorized access would create a critical impact are identified as CONFIDENTIALITY-CRITICAL COMPONENTS
Assessing Protection Level	Assess ease of exploiting vulnerabilities	Assess ease for a THREAT AGENT to exploit a VULNERABILITY as EASE OF EXPLOITING VULNERABILITIES
	Assess ease of accessing one component	Assess VULNERABILITY of a COMPONENT as EASE OF ACCESSING ONE COMPONENT
	Construct Attack Propagation Graphs	Create an ATTACK PROPAGATION GRAPH for the attack paths of each THREAT AGENT
Determining Candidate Confidentiality Requirements	Identify unmitigated vulnerabilities	Identify vulnerabilities that are not covered by current requirements as a UNMITIGATED VULNERABILITY
	Identify needed confidentiality requirements	Identify requirements based on a UNMITIGATED VULNERABILITY into NEEDED CONFIDENTIALITY REQUIREMENT

Table 1: Activity Table

3.2 Concept Table of CRAC++

The concept table represents all concepts from the right side of the PDD model (figure 1). The concepts are explained with a description and linked to each other when applicable. Most of the descriptions are based on definitions found in the paper by Morali & Wieringa (2010). In some cases a description is formed based on understanding of the explanation of the concept.

Concept	Description
CONFIDENTIALITY REQUIREMENT	An aspect of a system's security requirements aimed at preventing unauthorized use of personal or corporate data (Onabajo & Jahnke, 2006).
VULNERABILITY	A vulnerability that needs to be mitigated or dealt with according to the requirements (Morali & Wieringa, 2010).
INFORMATION ASSET	An INFORMATION ASSET is valuable functional or organizational data that is stored on a system COMPONENT (Morali & Wieringa, 2010).
COMPONENT	COMPONENT refers to IT architectural components such as hardware, software or a network location (Morali & Wieringa, 2010) A template of COMPONENT is added in Appendix A.
THREAT AGENT	A THREAT AGENT is a potential attacker who may access an INFORMATION ASSET without authority (Morali & Wieringa, 2010).
INFORMATION FLOW GRAPH	A directed and rooted graph that represents flow of instances of an information asset from an information source (Morali & Wieringa, 2010).
TOTAL IMPACT	The total value of information on a COMPONENT (Morali & Wieringa, 2010).
CONFIDENTIALITY-CRITICAL COMPONENT	COMPONENTS for which unauthorized access would create a TOTAL IMPACT higher than a critical threshold (Morali & Wieringa, 2010).
EASE OF EXPLOITING VULNERABILITY	The ease for a THREAT AGENT to make use of a VULNERABILITY (Morali & Wieringa, 2010).
EASE OF ACCESSING ONE COMPONENT	The ease of accessing a COMPONENT and the effectiveness of preventive measures (Morali & Wieringa, 2010).
ATTACK PROPAGATION GRAPH	A graph representing all paths an attacker can take to a valuable COMPONENT (Morali & Wieringa, 2010).
UNMITIGATED VULNERABILITY	A VULNERABILITY that is not migitated and that the client wants to defend itself against (Morali & Wieringa, 2010).
NEEDED CONFIDENTIALITY REQUIREMENT	Confidentiality requirements that the outsourcing provider must satisfy (Morali & Wieringa, 2010).
ARCHITECTURAL INFORMATION	Information regarding confidentiality requirements for the IT architecture needed to conduct SLA requirements negotiations (Morali & Wieringa, 2010).

Table2: Concept Table

4. Literature perspective

The origin of CRAC++ does not go back very far. The purpose of the method is based on trust-related topics, such as the conference paper from Sabherwal (1999) which includes a quote on outsourcing from a former Kodak executive: “You can’t write a contract on spirit and culture” (Sabherwal, 1999, p. 80), further recommending balancing trust with structural control, pointing at control requirements. Huang & Goo (2009) noted that this balance is difficult to operationalize in practice. This all relates to the difficulties that arise within outsourcing regarding requirements that tend to be excluded, confidentiality requirements being one example.

Research on confidentiality requirements started to expand in the late 2000’s. Gürses et al. (2005) introduced the CREE method (Confidentiality Requirement Elicitation and Engineering). The basic principle of this method is similar to CRAC++, in the way that it approaches the security of a system through individual stakeholders that can each have their own confidentiality requirements. CREE however was purely aimed at internal protection of confidentiality. Research continued within the field of confidentiality requirements (Onabajo & Jahnke, 2006a; Onabajo & Jahnke, 2006b) and in the field of CREE by Onabajo and Weber-Jahnke (2008). Huang and Goo (2009) further investigated ways to align SLAs in outsourcing relationships, but did not come up with a specific model to apply this research. Also they did not specifically go into confidentiality but focused more on strategic use.

Gritzalis et al. (2007) developed a probabilistic model, called Insurance Contacts, to define security requirements based on incidents which already occurred in a company. According to Morali and Wieringa (2009) this is not realistic to use for confidentiality requirements because confidentiality incidents cannot be monitored in a reliable way. A framework to define security requirements was developed by Haley et al. (2008). This framework was formed around defining security requirements as constraints on functional requirements. However, the CRAC++ method is focused on confidentiality requirements and makes a clear difference between these two, stating that they are independent of each other (Morali & Wieringa, 2010).

In 2009 CRAC is introduced by Morali et al. (2009) and they kept expanding their research in this field. The CRAC++ method is introduced in the conference paper “Risk-Based Confidentiality Requirements Specification for Outsourced IT Systems” by Morali and Wieringa (2010). In the paper from Morali (2010), CRAC++ is compared to similar methods such as RiskREP? , which is a combined method between CRAC++ and MOQURE. However, the CRAC++ method is not found in any literature outside of literature originating from the University of Twente.

5. Conclusion

Before the development of the CRAC++ method, no practical method existed that could help business companies with specifying confidentiality requirements for SLAs. It can be concluded that it is a relatively young entrance to the field of security requirement methods. However, it is a pioneer in the field of creating clarity for including confidentiality requirements in SLAs, and so far has not been adapted by research of other parties. This also means it is not very well known, and there is no evidence of further case studies outside of the paper from Morali and Wieringa (2010). Another critical point is the way how a large part of the method has to be performed by a confidentiality expert who on several occasions has no choice but to estimate rough values, as opposed to a more numeric approach.

6. References

Gritzalis, S., Yannacopoulos, A. N., Lambrinoudakis, C. D., Hatzopoulos, P., & Katsikas, S. K. (2007). A probabilistic model for optimal insurance contracts against security risks and privacy violation in IT outsourcing environments. International Journal of Information Security, 6(4), 197-211, doi: 10.1007/s10207-006-0010-x

Gürses, S., Jahnke, J., Obry, C., Onabajo, A., Santen, T., & Price, M. (2005). Eliciting Confidentiality Requirements in Practice. Proceedings of the 2005 conference of the Centre for Advanced Studies on Collaborative research (CASCON '05), Toronto, Canada, 106-116.

Haley, C. B., Laney, R., Moffett, J. D., & Nuseibeh, B. (2008). Security Requirements Engineering: A Framework for Representation and Analysis. IEEE Transactions on Software Engineering, 34(1), 133-153, doi: 10.1109/TSE.2007.70754

Huang, C.D., & Goo, J.. (2009). Rescuing IT Outsourcing: Strategic Use of Service-Level Agreements. IT Professional 11(1), 50-58. doi: 10.1109/MITP.2009.15

Morali, A. (2010). IT Architecture Based Confidentiality Risk Assessment in Networks of Organizations. Unpublished doctoral dissertation, University of Twente, the Netherlands. Retrieved February 17, 2012, from http://doc.utwente.nl/76717/, doi: 10.3990/1.9789036531658

Morali, A., Zambon, E., Etalle, S., & Wieringa, R. (2009). CRAC: Confidentiality Risk Analysis and IT-Architecture Comparison of Business Networks. Unpublished article, University of Twente, the Netherlands. Retrieved February 15, 2012, from http://eprints.eemcs.utwente.nl/16067/02/MZSW10_extended.pdf

Morali, A., Zambon, E., Etalle, S., & Wieringa, R. (2010). CRAC: Confidentiality Risk Assessment and IT-Infrastructure Comparison. 2010 International Conference on Network and Service Management (CNSM), Niagara Falls, ON, CAN, 322-325, doi: 10.1109/CNSM.2010.5691222

Morali, A., & Wieringa, R. (2010). Risk-Based Confidentiality Requirements Specification for Outsourced IT Systems. Proceedings of the 18th IEEE International Requirements Engineering Conference (2010), Sydney, Australia, 199-208, doi: 10.1109/RE.2010.30

Onabajo, A., & Jahnke, J. (2006a). Modelling and Reasoning for Confidentiality Requirements in Software Development. Proceedings of the 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems (ECBS’06), Potsdam, Germany, 460-467, doi: 10.1109/ECBS.2006.50

Onabajo, A., & Jahnke, J. (2006b). Properties of Confidentiality Requirements. Proceedings of the 19th IEEE Symposium on Computer-Based Medical Systems (CBMS'06), Salt Lake City, UT, USA, 841-846, doi: 10.1109/CBMS.2006.133

Onabajo, A., & Weber-Jahnke, J. (2008). Stratified Modelling and Analysis of Confidentiality Requirements. Proceedings of the 41st Hawaii International Conference on System Sciences - 2008, Hawai, USA, 232, doi: 10.1109/HICSS.2008.414

Sabherwal, R. (1999). The role of trust in outsourced IS development projects. Communications of the ACM, 42(2), Feb. 1999, (pp. 80-87) New York, NY, USA

Weerd, I. van de, & Brinkkemper, S. (2008). Meta-Modeling for Situational Analysis and Design Methods. In M. Syed & S. Syed (Eds.), Handbook of Research on Modern Systems Analysis and Design Technologies and Applications, (pp. 35-54). Hershey: Idea Group Publishing.

Downloads

File description	Download
Draft paper	Click here to download
Final paper	Click here to download
Templates	Click here to download
Presentation	Click here to download

MachielSchonbeck - 13 Apr 2012