Modeling and Quantifying the Security Attribute Confidentiality at Design Stage – An OO Software Perspective – Shalini Chandra SRMCEM, MCA Department, Tiwariganj, Faizabad Road, Lucknow, UP, India
[email protected] Raees Ahmad Khan IT Department, BBA University, Vidya Vihar, Raebareli Road, Lucknow, India
[email protected] Abstract Software having vulnerabilities may cause information loss and damages. The traditional software development process is not capable enough to minimize vulnerabilities that attackers exploit. Vulnerabilities and loopholes act as a disease in a software system, they replicate itself and they may damage the other connected systems. In order to make a secure software system or to minimize the impact of these loopholes it is required to scrutinize software architecture. The focus of the research work is to quantify security by scrutinizing software architecture and available design information. A methodology has been proposed to quantify confidentiality security attribute. As an outcome of the methodology two security metrics and a state transition model has been derived and implemented using several class diagrams. Statistical significance has been given by using other similar projects. Keywords: Software security, Security attributes, Security quantification, Object-oriented. 1. Introduction Security of the software describes the behavior of the system; and its functioning properly in the presence of attacks, vulnerabilities or other malevolent acts. Software having vulnerabilities may cause for damages and generate vulnerabilities. The traditional software development process is not capable enough to minimize vulnerabilities that attackers exploit [1]. Some of the vulnerabilities replicate itself. These vulnerabilities and loopholes act as a disease in software system and they may damage the other connected systems also. At the later stages of software development it is difficult to identify such loopholes. Only security experts may identify that existing vulnerabilities are damaging other services. In order to make a secure software system or to minimize the impact of these loopholes it is required to scrutinize software architecture. Software is assumed to be secure if software is designed to operate at a level of security. Software should be able to handle inaccuracy, information loss, alteration, unavailability or misuse to data [2]. The software is said to be secure if it posses security properties including confidentiality, integrity and availability. In order to assure that the software possess these properties, a traditional approach i.e. Threat modeling using STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege) is used [3]. To mitigate these threats corresponding security properties are authentication, integrity, non-repudiation, confidentiality, availability and authorization. In order to assess or improve the level of security, estimation is required. Estimation is a better way to assess the level of security. Confidentiality, Integrity and, Availability are three dimensions of security. Confidentiality checking an object-oriented class hierarchy has been presented in [4]. This part of the research work presents an extended version of the methodology with experimental validation. 2. Literature Survey and Problem Formulation In the early 1970’s modeling of computer security was undertaken. A model developed by Bell-La Padula was one of the earliest security models. The model is used to consider the general design problem of conceiving and constructing “secure computer systems” and able to satisfy the characteristics including descriptive capability, general mechanisms and specific solution [7]. In 1993 CTCPEC version 3.0 was published as a combination of ITSEC and TCSEC approaches. FC version 1.0 was also published in 1993, as combining concepts for evaluation criteria. The criteria were developed to deal with issues of trust and maintaining confidentiality, integrity and
availability of product from the vendor perspective [9]. In 1999, Erland Jonsson developed an integrated framework for security and dependability. The significance of the model is, it forms the basis for composite measures of security and dependability. Jonsson discusses a formal model of confidentiality, developed by D. Bell et. al.. The model describes the flow of information in a secure system, aimed at identifying paths that could lead to inappropriate disclosure of information. Biba also discussed the corresponding integrity model in 1977 [22]. For modeling and quantifying the security attributes a method has been presented by B.B. Madan in 2002. In the research work a state transition model diagram developed for the intrusion tolerant system. The model describes the dynamic behavior of an intrusion tolerant system. During the research work several probability distribution functions identified that can be used to describe attacker behavior and solved the semi-Markov process for several security related attributes [12]. In 2009, the Computational Security Analysis approach has been developed for security analysis. It provides a base for specification of security attributes in terms of data and transformation of data by programs [11]. These all research works are implemented at later stage of software development. In 2009, A. agrawal presented an approach to measure, impact of inheritance on vulnerability propagation in the design stage [13]. Bandar Alsamarri et. al. presented security metric suite to quantify software security at design stage in 2010. These security metrics identify better UML design on the basis of their object-oriented constructs including encapsulation, coupling, cohesion and inheritance etc. [14]. However, earlier security attribute quantification approaches were applicable on later stages of software development. Some recent works [13,14] focused security quantification at an early stage of development with the help of object oriented design constructs. This research work motivated researcher to develop such a methodology for quantification of security attributes including confidentiality, integrity and availability at the design stage of software development. This part of the research work is focused on quantification of confidentiality security attribute at the design stage using UML class diagrams. To improve software security engineering, a different approach for quantification and analysis of security attributes using basic concepts; a new methodology has been developed. In order to improve security level of it is required to measure its strength. Robustness of software design depends on how much it is less prone to attack and lesser loopholes. Generally software is developed in different versions. Measuring security level of application gives opportunity to select better software design. In the following sections a methodology has been developed to estimate the security level of software considering the confidentiality security aspect. Two security metrics namely CHCRF (Class Hierarchy Confidentiality Risk Factor) and SPCRF (Security pattern Confidentiality Risk Factor) and confidentiality state transition model has been developed named as CSTM. One of the important security design principle is to minimize sharing. According to this principle computer resource should be shared between functions and processes unless it is necessary to do so. Minimized sharing helps to simplify the design and implementation. The rule also concludes that no sensitive information should be shared unless that sharing has been explicitly requested and granted. In addition to this, internal sharing must be carefully designed to avoid in making loop holes [10]. In the design phase due to sharing of attributes and methods the object-oriented concepts including inheritance, coupling, and cohesion etc. state of classes get change [20]. With the help of quantification of states it is possible to measure the level of security in the design stage. CSTM follows this concept and provides an easy way to assess the security level. During development of model the main focus is to keep track of estimation of security using confidentiality states, we ignore the issues to identify or detect sensitive class or methods because tools are available to identify sensitive methods such as UMLsec. The UMLsec tool can be easily used to detect such sensitive class. CSTM considers only confidentiality security aspect. 3. Terminologies Used Before implementation of the methodology some prerequisite requirements need to be fulfilled such as a set of sensitive methods, validity check methods, non-confidential class, sensitive class etc. Following terminologies have been used in methodology with some modifications. Sensitive Methods: Methods altering any confidential / sensitive information is called a sensitive method. It may process attributes having sensitive information, modify only on the basis of its validity. If there are N classes in a class diagram then set of sensitive methods of class Ci is represented as: SM(Ci)={SMi1,SMi2…}, where i=1….n. In order to identify these methods, some suggestive checks are proposed in Table 1
Table 1: Checks to identify sensitive methods S. No.
Checks
1.
The method has attributes having sensitive information (e.g. user id, user name, card id, card no. etc.)
2.
The method has any attribute carrying encrypted code, password / passcode etc.
3.
The method has any attribute having authorization code
4.
The method has any conditional check (e.g. expiry date).
5.
The method has transaction id etc.
Y
N
Y
N
Y
N
Table 2: Checks to identify validity check methods S. No.
Checks
1.
The method process attributes having sensitive information (e.g. user id, user name, card id, card no. etc.)
2.
The method process any attribute carrying encrypted code, password / passcode etc.
3.
The method process any attribute having authorization code
4.
The method process any conditional check (e.g. expiry date).
5.
The method process transaction id etc.
Table 3: Checks to verify a risky class S. No.
Checks
1.
Class does not have any self checking method.
2.
Class is not inheriting or sharing any validity check method corresponding to their sensitive
3.
Previous classes are not safe.
4.
Any corresponding validity check method does not exists, before accessing the class.
methods.
5. Class is sharing with already declared risky class. Sensitive Class: A class having sensitive methods and needs protection or confidentiality check is said to be sensitive class. The methods of the class may not be public or disclosing information without any authentication, authorization and validity check methods. Methods of the class may be its own or inherited / coupled / aggregated to other classes. Set of sensitive class is represented as SC. Validity Check Method: A method verifying the authenticity for accessing sensitive data by implementing a conditional check is known as a validity check method. Set of validity check methods of class Ci is represented as VM(Ci) = { VMi1,VMi2…}. In order to identify these methods, some suggestive checks are proposed in Table 2. Non-Confidentiality Class: If a class doesn’t have any sensitive method nor validity check method, the class is said to be non-confidential class. A set of non-confidential classes is represented as NC. Risky Class: Class having sensitive methods without its corresponding validity check method is considered as a risky class. In order to verify risky class, a checklist has been proposed in Table 3. A set of risky classes is represented as RC. Confidential Class / Safe Class: Class having sensitive methods with corresponding validity check method is considered as confidential class. The validity check method may be of its own, inherited or coupled. A set of confidential class/safe class is represented as SF. Super class: The class from which any method or attribute has been taken or shared through coupling, inheritance,
aggregation etc. is considered as a super class/ source class. A set of all super classes for class Ci is defined as SP(Ci). Subclass: The class where the methods and attributes of the source class have been floating through inheritance, coupling, inheritance, aggregation etc. is called as a subclass/target class. A set of all subclasses for class Ci is defined as SB (Ci). During confidentiality check of class hierarchy these terminologies have been used. As limitation of the methodology identification of sensitive methods and validity check methods have been required. In order to find out these methods some prescriptive checks have been proposed. These checks are developed for a specific type of application. In broader perspective UMLsec and SPARK's annotations may be used for identification of sensitive methods and validity check methods (which keeps any sensitive information needs protection) or any other such type of tools or mechanism. Main focus of the methodology is to produce quantitative results in order to assess the security level of the software among different versions of software design and provide basis for ranking software also. 4. Research Objectives and Hypothesis Sharing of attributes and methods is an important feature of object-oriented paradigm. This property has great impact on design-level vulnerabilities. Identification and mitigation of these vulnerabilities require great expertise. During a workshop, Microsoft reported that over 50 percent of the problems it encountered during its security push were architectural in nature [5]. Recently, some metrics are developed to measure vulnerabilities of software in the design stage. These metrics are capable enough to show the impact of Object Oriented (OO) characteristics of software security [14, 15, 16, 17, 18, 19]. So, it strengthens the idea to develop such OO security metrics to measure specifically security attributes including confidentiality, integrity and availability in the design stage of software development [13,14]. During development of security metrics some objectives have been set forth. These objectives are: •
To identify security metric to define the confidentiality risk factor of the class hierarchy.
•
To identify security metric to define the confidentiality risk factor of security pattern.
•
To make it easy to understand, the impact of dynamic behavior of a class, during state transition.
This research work will test five hypotheses (the relevant null hypothesis is denoted as Hn0 and alternate hypothesis is denoted as Hn1, where n=0, 1,2..). The hypotheses are: Null Hypothesis H10: Confidentiality risk factor of hierarchy will not increase as the number of risky classes increases. Alternate Hypothesis H11: Confidentiality risk factor of hierarchy will increase as the number of risky classes increases. Null Hypothesis H20: Confidentiality risk factor of hierarchy will not decrease as the number of safe classes increase. Alternate Hypothesis H21: Confidentiality risk factor of hierarchy will decrease as the number of safe classes increase. Null Hypothesis H30: Confidentiality risk factor of hierarchy will not decrease as the number of non-confidential classes increase. Alternate Hypothesis H31: Confidentiality risk factor of hierarchy will decrease as the number of non-confidential classes increase. Null Hypothesis H40: Confidentiality risk factor of hierarchy will not increase as the number of sensitive classes increases. Alternate Hypothesis H41: Confidentiality risk factor of hierarchy will increase as the number of sensitive classes increases. Null Hypothesis H50: Sensitivity of class hierarchy does not affect confidentiality risk Alternate Hypothesis H51: Sensitivity of class hierarchy affects confidentiality. We have concentrated on quantifying confidentiality risk in the design stage using class hierarchy. In order to verify
the effectiveness and robustness of metrics, we examine the capabilities of metrics on 9 samples of application developed by three different groups of PG students. During the research work, the researcher has made an effort to analyze is there any relationship between size and security. Further, the main reasons that make software risky have been analyzed, considering the only confidentiality perspective. It has also been analyzed that is really sensitivity affect confidentiality risk factors. 5. The Methodology As early as in 1978, Peter G Neumann discusses the generalized approaches of security i.e. defensive and preventive. In this work, a preventive approach is described, to measure in the design phase and to get a secure design using specific design methodologies and specifications. Defensiveness involves security assessment when the system is in operation, and to patch around vulnerabilities. The methodology is followed preventive approach. During the confidentiality check process, the sensitivity of both, class and method must be checked. They are not to be hampered. Reliability of classes and methods is an important feature of an object-oriented paradigm, but it can lead to further instances in which access privilege is required. Therefore, it is necessary to verify any sensitive information not to be made public. Some restriction or protection is required at that point; otherwise it will act as a leakage channel. Several attributes and methods are used in a class. If any method of a class displays confidential data, then the class may be considered as a sensitive class. During the coding phase, programmers an easily check whether the information is disclosed after its validity check, by analyzing the program’s control flow. In the design phase, a class having any self checking method or inheriting any validity check method corresponding to the sensitive method may be verified. The validity check method ensures that the user has the right to get the facility of the resources. Permission may be granted to the user, depending on the application security policy. 5.1
Confidentiality Check Process
In order to check confidentiality of sensitive class, every method of class need to go through the Confidentiality Check Process (CCP). For every sensitive method, its corresponding validity check method (authentication, authorization or validation, depending on the security context), is must. The validity check method may be inherited, coupled or a method of its own class. A class having sensitive methods has been considered as sensitive class SC. Set of sensitive methods of class Ci is SMCi. For every sensitive method in SM (Ci), its corresponding validity check method should be there. It may be in the same class or in any of its superclass. SP (Ci), is the set of super classes of sensitive class Ci. If any method of SM (Ci) does not have its corresponding validity check method, the confidentiality of that method may get disturbed easily, making the class non confidential. Let,
∈ SM(Ci)} SM (Ci) = {SM (Ci) ∪ SM(SP(Ci))}
X= {SMij | SMij
Where, SM(Ci) is the set of sensitive methods of a class SCi, SM(SP(Ci)) is the set of sensitive methods of all super classes of SCi where, n is no. of classes in a class hierarchy. SMij is a sensitive method of Class SCi, needs protection from unauthorized access, where, 0 < j ≤ m , m is no. of methods in class SCi.
Y={VMik | VMik ∈ VM(Ci)}
VM(Ci)={VM(Ci) ∪ VM(SP(Ci))}
Where, VM(Ci) is the set of validity check methods of a class SCi. VM(SP(Ci)) is the set of validity check methods of all super classes of SCi where 0
