2009 International Conference on Availability, Reliability and Security
An Efficient Measurement of Object Oriented Design Vulnerability
Alka Agrawal Shalini Chandra
Raees Ahmad Khan
Department of Information Technology Babasaheb Bhimrao Ambedkar University Lucknow, India
[email protected],{nupur_madhur, khanraees}@ yahoo.com tool to minimize vulnerabilities at design level. The work is a step towards the same. A vulnerability measure, Vulnerability Propagation (VP), has been proposed. The VP computes number of classes affected because of a vulnerable class in an Inheritance hierarchy of an object oriented design. On the basis of VP, Vulnerability Propagation Factor (VPF) for the design is calculated. The rest of the paper is organized as follows: Next section discusses vulnerabilities and incidents due to vulnerabilities. Section 3 discusses background of the work. Section 4 suggests an approach to identify vulnerable classes. Section 5 defines Vulnerability Propagation. Section 6 discusses Inheritance and its role in propagation of vulnerability. Section 7 provides an algorithm to compute Vulnerability Propagation Factor (VPF) of an object oriented design with example. Succeeding sections discuss interpretation, advantages and limitations. Paper concludes in section 10.
Abstract—As foundation is to building, design phase is to software because in this phase ideas start converting into actuality. Effects of vulnerabilities introduced in this phase manifest with ongoing software life cycle. Even detection and correction of these vulnerabilities seem to be difficult in absence of any efficient method or automated tool. This paper suggests an approach to identify vulnerable classes in object oriented design. The method proposed also investigates whether transitive nature of Inheritance contributes to propagation of vulnerabilities from one class to another or not. An algorithm for computing Vulnerability Propagation Factor (VPF) has been developed, which measures number of vulnerable classes because of the vulnerability in some classes of an object oriented design. Keywords- Design Phase; Inheritance; Vulnerability Propagation; Vulnerability Propagation Factor;
I.
INTRODUCTION
Inadequate requirement specification, insecure design, and poor coding practices may introduce vulnerabilities in software. Vulnerable software can be exploited at any point of time by attackers leading to undesired consequences [1]. Security of the software is measured in terms of number of existing vulnerabilities [2]. Gary McGraw characterizes vulnerabilities into two classes one is design time vulnerability called flaw and the other is implementation time vulnerability called bugs [3]. Literature survey reveals that detection and correction of vulnerabilities in design phase of development life cycle are important as making changes in the phase are much easier than to make them at the end [4]. Plenty of tools and approaches are available to detect and remove implementation time vulnerabilities. ITS4 [5], FLF Finder [6], MOPS [7], Penetration Testing [8] are to be named a few. But, approaches for detection and removal of vulnerabilities at design level [9, 4] are very few. In addition to it, almost negligible work has been done to address security issues in design phase of object oriented system [10]. Undoubtedly, vulnerability detection and correction processes in design phase are still almost manual which consume more time, resources and efforts [11]. Even tools to detect and remove design level vulnerabilities do not exist till date [12]. This leads the necessity to develop a 978-0-7695-3564-7/09 $25.00 © 2009 IEEE DOI 10.1109/ARES.2009.130
II.
SOFTWARE VULNERABILITY
Vulnerabilities are the weaknesses of a system which could be exploited at any point of time and tend to violate security policies. Many software failures causing loss in terms of money and reputation were reported because of the vulnerability. The loss due to Code Red Worm has been estimated to $2.6 billion and due to Nachi Worm, operations at Air Canada and CSX railroad were affected very badly[13].Efforts in this direction have been started but the statistics shows that the problem is still growing[14]. Total 4129 vulnerabilities were reported to CERT Coordination Center in 2003, this was 70 percent increase over 2002 and almost fourfold increase since 2001[15]. Currently, the rate of reporting vulnerabilities to CERT Coordination Center is 4,000 per year [16]. Though, most of the organizations are using antivirus and firewall, but these are also of little use. In 2004, CSI/FBI Computer Crime and Security Survey concluded that 98 percent of the participants were using firewall and 99 percent were using antivirus, still most of them suffered virus attack, system penetration and unauthorized access to information [17]. This shows that some other approach is also needed in addition to firewall and antivirus. Learning from the different incidents of security failure, it is now believed that instead of wondering for
618
nothing, root cause of the security problem, the vulnerability, should be mitigated early in the development [17, 4]. III.
•
Some mechanism is required on urgent basis to compare and comprehend software project in order to identify less attack prone software. It is almost impossible to completely safeguard the software; the only effort one can make to secure software is to reduce its vulnerability [25].
BACKGROUND
By the occurrence of various security related incidents, it has been realized that application security is not enough to fight against vulnerabilities and threats [15, 17]. Because of this, researchers and practitioners are repeatedly advocating the need for vulnerability detection and correction at each phase of Software Development Life Cycle (SDLC) [18, 15, 19]. Wide range of tools/ techniques/ approaches for detection and correction of vulnerabilities have been developed [5-8, 20]. But unfortunately, they all are of later stage tools especially of coding and implementation phases. Literature on software vulnerability reveals that a little amount of effort has been made for detection and correction of design vulnerabilities. Moreover, automated tools for vulnerability detection in design phase are missing [12]. This strengthens the need for developing a tool to minimize vulnerabilities in design. It has been noticed that researchers are developing Vulnerability Discovery Models (VDM). These models use the fact that vulnerabilities are the subset of defects and are based upon existing software reliability growth models [21]. Some of the vulnerability models include Anderson Thermodynamic Model (AT), AlhazmiMalaiya Logistic Model (AML), Rescola Linear Model (RL), Rascorla Exponential Model (RE), and Logarithmic Poisson Model (LP) [22]. These models operate on historical data including systems release date, system usage information and the date on which vulnerability is discovered [21]. These existing models are applicable in implementation stage and are estimating discovery of future vulnerabilities on the basis of historical data. This gives an idea of developing a model to predict vulnerabilities early before implementation. Moreover, the prediction mechanism should not be dependent on the previous history of data. The fact motivated the authors developing a methodology to be implemented in design phase to discover and mitigate vulnerabilities there itself. Similar to defect density, a measure termed Vulnerability Density is introduced by researchers [23]. It is calculated by the number of vulnerabilities per unit of code size. Also, another run time metric, an attackability metric [24], measuring attack surface of software, is developed. With the help of these metrics vulnerability and attackability of two versions of the same software can be compared. This fact gives strength to the authors developing such a measure to be used to compare two design hierarchies early in the development. Further, the following facts strengthen the idea of developing efficient measures for object oriented design vulnerabilities for which the authors have approached: • There is a need of developing a tool to minimize vulnerabilities; • Design time implementation of such a tool is in heavy demand in order to discover and mitigate vulnerabilities;
IV.
IDENTIFYING VULNERABLE CLASSES IN DESIGN PHASE
In broader perspectives, software vulnerabilities can be classified into two basic categories namely design time vulnerability and implementation time vulnerability. There are many tools available to detect implementation time vulnerability. On the other hand, detecting design time vulnerability is mostly carried out manually [3]. The fact validates the reason detecting and correcting design level vulnerabilities are difficult. The process is time consuming, resource consuming and error prone too [11]. Researchers and practitioners emphasize on the need of enhancing security in design phase itself. Their suggestions, when aggregated [12, 26] with respect to object oriented design perspective, may yield the steps as shown in “fig. 1”. At the first step, risk analysis is performed in design phase to uncover assets, threats, attacks and risks [3]. This helps to extract sensitive classes i.e. classes having both data members and methods attack prone. Hence these classes are suspected to be attacked. Second step attempts to secure these sensitive classes using security mechanisms. At the end, classes are assumed to be secure merely just applying security mechanisms. But, as a matter of fact, sensitive classes even after shielded with security mechanisms may not be completely secure. The simple reason is that no mechanism can guarantee absolute security [12]. Sensitive classes are secure till vulnerabilities in security mechanisms applied, are not targeted for attack. The proposed work depends on the fact that sensitive classes will always be in the eyes of attackers even though they are shielded with security mechanisms. Some of the facts behind vulnerability [27] of sensitive classes (when no security mechanism applied) are listed below: • It provides entry points for external application • It processes confidential information • It involves in internal network communication • It allows user authentication and control
Risk Analysis •Asset Identification •Threat Modeling •Risk Identification •Risk Prioritization
Sensitive Classes
Secure Classes
Security Mechanism
Figure 1. Securing OO Classes: General Approach
619
reusability [29]. There are mainly two types of Inheritance; Single Inheritance and Multiple Inheritance. When a class is allowed to have only one super class, it is called Single Inheritance. If a class is allowed to have multiple super classes, it is called Multiple Inheritance. Inheritance graph of a class hierarchy H of n classes is a directed graph H = (V, E) where V corresponds to the set of total number of classes and E is the set of total number of Inheritances in the class hierarchy. So, mathematically, Inheritance Graph G = (V, E) such that V= {C1, C2, C3, C4………Cn}, and E = {Ci → Cj, where i, j are arbitrary numbers and i, j € {1, 2, 3, 4….}}. Graphical representation of Single, multiple and hybrid (follow both rules i. e. single & multiple) Inheritances are given in “fig. 2”. Inheritance plays an important role in increasing reusability of design and code or of overall software; hence it also reduces effort and cost of software development. But at the same time, it has been noticed that Inheritance is also responsible for spreading vulnerability from one class to another, because of its transitivity property [29]. If a design supports Inheritance then all of the methods and variables defined for the parent class automatically become available for all of its subclasses, as well as for any subclass of these classes recursively down the hierarchy [10]. This characteristic of Inheritance easily spreads vulnerability among the classes.
Similarly, some of the facts behind vulnerability of secure classes (even after security mechanisms are applied to sensitive classes) [28] are: • Cryptographic protocol design errors • Reliance on non secure abstractions • Security / usability trade off • Absence of strict logging scheme From the foregoing discussion and with the evidences from literature survey, it has been concluded that a class would be vulnerable if both of its data members and methods are sensitive irrespective of the implementation of security mechanism. Therefore, presence of vulnerability is always there. The only effort one can make is to reduce its propagation through different artifacts including Inheritance, Encapsulation, Coupling and Cohesion. Authors have made an effort to minimize its propagation through Inheritance. V.
VULNERABILITY PROPAGATION (VP)
In general, propagation means flow of something from one place to another. In object oriented design perspective, spreading of vulnerability from one vulnerable class to another is termed as Vulnerability Propagation. Mathematically, Vulnerability Propagation (VP) of a class C, denoted by VP(C), is set containing classes in the hierarchy which directly or indirectly inherit class C. Therefore,
VII. VULNERABILITY PROPAGATION FACTOR
VP(C) = {Ci: Ci € set of classes in hierarchy}
COMPUTATION
An Inheritance hierarchy may contain no class or one or more vulnerable classes. Also, there are more than one Inheritance hierarchies present in a design. So, calculation of Vulnerability Propagation Factor (VPF) of a design requires calculation of Vulnerability Propagation due to each vulnerable class Ci in Inheritance hierarchies present in the design. Then, union of Vulnerability Propagation due to each vulnerable class will give overall Vulnerability Propagation in design. Now, using “(1)” vulnerability propagation factor of design can be calculated through proposed algorithm.
Cardinality of set VP(C) represents the number of classes which have become vulnerable due to class C. Therefore, Number of vulnerable classes due to class C = |VP(C)| Alternatively, Vulnerability Propagation of a class C is the total number of classes which directly or indirectly inherit class C. Since a design may be considered as the collection of modules which are again collection of class hierarchies. So, the motive behind calculating Vulnerability Propagation of a class in Inheritance hierarchy is to use the parameter to calculate Vulnerability Propagation Factor (VPF) of design. If M is the number of vulnerable classes in a design and VP (1), VP (2)….VP(M) are the Vulnerability Propagations of these classes respectively, then VPF may be defined mathematically as follows: VPF = |VP (1) U VP (2)….U VP (M)| / M
A. Algorithm The algorithm for calculating Vulnerability Propagation Factor for a design uses the principle of Breadth First Search (BFS) algorithm. It takes identified vulnerable classes in a queue VUL [1...M] and an array H [N] of Inheritance graphs as input, where M is the total number of identified vulnerable classes and N is the number of Inheritance hierarchies in the design.
(1)
A
VI.
B
A
A
VULNERABILITY PROPAGATION THROUGH INHERITANCE
B
It is well established fact that object oriented paradigm reduces software cost and increases software extensibility, flexibility and reusability. Inheritance is a prominent feature of object oriented paradigm which provides
C
C
B
Figure 2. Single, Multiple, Hybrid Inheritance
620
C
D
For an Inheritance graph H = (V, E) and a distinguished vulnerable vertex vul, algorithm explores the edges of H to obtain every vertex that is reachable from vul. The algorithm creates trees corresponding to each vulnerable vertex vul and at the same time counts all vertices of the trees. Finally, it produces Vulnerability Propagation Factor of design, using count. To verify the progress, the algorithm shows status of each vertex as unknown, known and traversed. Initially the vertex is unknown and becomes known when it is discovered. Later, it becomes traversed when all of its adjacent vertices become known. The algorithm assumes that Inheritance graphs H = (V, E) are represented using adjacency lists. It maintains several additional data structures with each vertex in Inheritance graphs. The status of each vertex u € V is stored in the variable status [u], predecessor of u is stored in the variable p [u]. The algorithm uses two FIFO queues, VUL containing all vulnerable vertices and Q managing a set of all known vertices. The algorithm is described as: VPF (VUL [1...M], H [N]) 1. vp = 0 2. for [i =1; i≤ M; i++] 3. status [VUL[i]] = known 4. for [i =1; i≤ M; i++] 5. vul ← Head (VUL) 6. count = 0 7. for [j=1; j≤ N; j++] 8. if vul € H[j] 9. Call VP (H[j], vul) 10. Exit 11. dequeue (VUL) 12. vp = vp + (count-1) 13. vpf_design = vp/ M
class vulnerable. Hence in cases where one class inherits two or more vulnerable classes, it will appear in tree corresponding to only one of those vulnerable vertices. This will help to avoid repetition. The status variable keeps track of these vertices so that they can not be counted twice or more. The algorithm proceeds as follows: for each vulnerable vertex, status is set as known. Then it is checked to which hierarchy it belongs to. Further VP (H[j], vul) algorithm is called to find out all of the vertices directly or indirectly inheriting this vulnerable vertex. The VP (H[j], vul) algorithm produces trees corresponding to each vulnerable vertex as root node and number of vertices in each tree. Finally, VPF of design is computed. In detail; step1 of VPF sets variable vp to 0. Steps 2 to 3 set status variable for each vulnerable (grayed in “Fig. 3”) vertex to known. In for loop from step 4 to12, each time a vulnerable vertex is assigned to variable vul from the head of the VUL, its count variable is set to 0. Algorithm VP is called for each vul(step 9), which generate a tree corresponding to each vul and count number of nodes in the tree using count variable. At the exit of the algorithm VP, VUL is dequeued so that next vertex may occupy head of the VUL; count is decremented by 1 and is added to vp to yield cumulative Vulnerability Propagation due to each vulnerable class. Finally, step13 results as a Vulnerability Propagation Factor. The algorithm VP(H[j], vul) called in step 9 of VPF works as follows: In the for loop from step 9.1 to 9.4, the status variable of each vertex except vul is examined to know whether it has been already included in a tree corresponding to some other vulnerable vertex vul of that Inheritance graph. If it is not the case (status variable is Nil), status variable of vertex is set as unknown and parent p as Nil. In step 9.5, parent of vertex vul is set to Nil as now it becomes root vertex. Step 9.6 puts vul in Q. The while loop from step 9.7 to 9.16 iterates till Q is not empty. Each time, head of the Q is assigned to a variable u. Status of all vertices adjacent to u are set known and parent p is u( if the status variable is unknown) and these adjacent vertices are inserted into Q. The Q is now dequeued so that the next vertex in Q may occupy the head position. Status of u is set as traversed to indicate that all of its adjacent vertices are explored. Finally, count is incremented by 1 to show increment in the Vulnerability Propagation.
Where VP (H[j], vul) is defined as follows: VP (H[j], vul) 9.1 for each vertex u € V (H[j]) – vul 9.2 if status [u] = Nil 9.3 then do status[u] ← unknown 9.4 p[u] ← Nil 9.5 p[vul] ← Nil 9.6 Q ← vul 9.7 While Q ≠ Ø 9.8 do u ← head (Q) 9.9 for each v € adj [u] 9.10 do if status[v] ← unknown 9.11 then status[v] ← known 9.12 p [v] ← u 9.13 enqueue (Q, v) 9.14 dequeue (Q) 9.15 status [u] ← traversed 9.16 count ← count + 1
C.
A try out example In order to understand better the VPF algorithm, an example has been taken to explain. Three Inheritance hierarchies in a design are given, whose graphical representation is shown in “Fig. 3a” as H [1], H [2], and H [3]. The vulnerable vertices are grayed to distinguish them from normal vertices. The VUL in “Fig. 3b” contains these vulnerable vertices. This forms input to the algorithm. “Fig. 4” contains trees corresponding to each vulnerable vertex C2, C9, C10 and C19. Now, VPF of the design is calculated as: vpf_design = vp/ M = 7/4 = 1.75
B. Implementation Since, a vertex becomes vulnerable whether it inherits one vulnerable class or more. So, it does not matter how many vulnerable classes are there at the root in making a
621
•
C1
C9
C3
C4
C11
C10
C16
C17
C18
C6
C5
C15
C8
C2
It may establish comparison between design of different versions of software or designs of different software. • It may help to choose some alternative design decisions to improve existing design. On the other hand, effort of measuring vulnerability of an Inheritance hierarchy and hence an object oriented design is at very young stage. So, lacunas are obvious. One of the major limitations of the work is its applicability to only object oriented software. Also, only one aspect of object oriented design has been considered when calculating VPF i. e. Inheritance, while other aspects including Encapsulation, Polymorphism, and Coupling etc. should also be taken into account.
C12
C20 C19 C21
C13
C7 H[1]
C14 H[3]
H[2] 3(a)
VUL
C2
C9
C10
C19
X.
3(b)
Since design is called skeleton of software, it is comparatively easy to implement security at this phase. At the same time, if security aspects are ignored at this phase, the resulting design might become vulnerable [30, 31]. Even a single flaw in design will manifest in next phases of software life cycle and it will become harder and harder to diagnose this vulnerability as the software life cycle proceeds. The work investigates the role of Inheritance in vulnerability propagation. A measure called VPF has been introduced as the major contribution to the work. VPF reveals the fact that how a single vulnerable class can manifest itself in class hierarchy, as well as in design to make whole software vulnerable.
Figure 3. Inheritance Hierarchies & Vulnerable Vertices: Inputs to Algorithm C2 C4
C5
C9
Count = 5
C19
C6 C12 C13
C7
C10
C14
Count = 4
Count = 1
CONCLUSION
Count = 1
REFERENCES Figure 4: Resulting Vulnerable Trees & Their Counts
[1]
VIII. INTERPRETATION If P is the total number of classes in design, the numerator in “(1)” would lie between 0 and P. i.e.
[2]
0 ≤ |VP (1) U VP (2)….U VP (M)| ≤ P
[3]
So using above inequality the value of VPF of a design will always be greater than or equal to1.i.e.
[4]
VPF ≥0
[5]
Considering above value of VPF, an inference can be drawn for vulnerability of a design as: (Higher the VPF, higher the vulnerability in design). This may serves as an aid to remediate vulnerabilities and achieve target level of security. IX.
[6]
ADVANTAGE AND LIMITATION
[7]
Advantages of VPF of an object oriented design are three fold: • It can be used to measure vulnerability of a given design.
[8] [9]
622
F. Farahmand, S. B. Navathe, G.P. Sharp, and P.H. Enslow, “Managing vulnerabilities of information systems to security incidents,” Proc. ACM Conf. Electronic Commerce(ICEC 03), ACM, 30 Sep -03 Oct 2003 , pp. 348 – 354, doi: acm.org/10.1145/948005.948050. M. Essafi, L. Labed, and H. B. Ghezala, “S2D- ProM: A strategy oriented process model for secure software develoment,” Proc. IEEE Conf. Software Engineering Advances (ICSEA 07), IEEE, 25-31 Aug 2007, pp.24 – 24, doi: 10.1109/ICSEA.2007.59. D. Verdon, and G. McGraw, “Risk analysis in software design,” IEEE Security and Privacy, vol. 2, July 2004, pp. 79 – 84, doi: ieeecomputersociety.org/10.1109/MSP.2004.55. P. Torr, “Demystifying the threat-modeling process,” IEEE Security & Privacy, vol. 3, Sep-Oct 2005, pp. 66-70. doi: 10.1109/MSP.2005.119. J. Viega, J. T. Bloch, T. Kohno, and G. McGraw, “ITS4: A static vulnerability scanner for C and C++ code,” Proc. IEEE Conf. Computer Security Applications (ACSAC’00), IEEE, 11-15 Dec 2000, pp. 257-267,doi: 10.1109/ACSAC.2000.898880. D. DaCosta, C. Dahn, S. Mancoridis, and V. Prevelakis, “Characterizing the ‘security vulnerability likelihood’ of softawre functions,” Proc. IEEE Conf. Software Maintenance, (ICSM’03), IEEE, 22-26 Sep. 2003, pp. 266 – 274, doi:.ieeecomputersociety.org/10.1109/ICSM.2003.1235429. H. Chen, amd D. Wanger, “MOPS: An infrastructure for examining security properties of software,” Proc. ACM Conf. Computer and Communications Security (CCS’02), ACM, 18–22 Nov, 2002, pp. 235-236, doi: acm.org/10.1145/586110.586142. M. Bishop, “About penetration testing,” IEEE Security & Privacy, vol. 5, Nov-Dec 2007, pp. 84- 87, doi: 10.1109/MSP.2007.159. M. A. Hadavi, H. M. Sangehi, V. S. Hamishagi, H. Shirazi, “Software security: A vulnerability – activity revisit”, Proc. IEEE
[10] [11]
[12] [13]
[14]
[15] [16] [17]
[18]
[19] [20]
[21] [22]
[23]
[24]
[25] [26]
[27] [28]
Conf. Availability, Reliability and Security (ARES’08), IEEE, 4-7 Mar 2008, pp. 866-872, Doi: 10.1109/ARES.2008.200. D. L. Spooner, “The impact of inheritance on security in objectoriented database systems,” Available at: http://www.cs.rpi.edu/research/ps/88-27.ps N. Moha, “Detection and correction of design defects in object oriented architectures,” Proc. Workshop. Object Oriented Reengineering(WOOR’03), 21 July 2003, pp. 949 – 950, available at: http://www.etud.iro.umontreal.ca/~mohanaou/paper/ECOOP06/M oha06-DS_ECOOP.pdf G. McGraw, “From the ground up: The DIMACS software security workshop,” IEEE Security & Privacy, vol. 1, Mar-Apr 2003, pp. 59 – 66, doi: 10.1109/MSECP.2003.1193213. S. Ardi, D. Byres and N. Shahmehri, “Towards a structured unified process for software security,” Proc. ACM, ICSE Workshop on Software Engineering for Secure Systems (SESS’06), ACM, 20-21 May 2006, pp. 3-9, doi: acm.org/10.1145/1137627.1137630. Z. Lin, X. Jiang, D. Xu, B. Mao and L. Xie, “Auto PaG: Towards automated software patch generation with source code root cause identification and repair,” Proc. ACM Symp. Information, Computer and Communications Security (ASIACCS'07), ACM, 20-22 Mar 2007, pp. 329-340, doi: acm.org/10.1145/1229285.1267001. G. McGraw, “Software security,” IEEE Security & Privacy, vol. 2,Jan-Feb 2004, pp. 80-83., doi: 10.1109/MSECP.2004.1281254. R. A. Khan and K. Mustafa “Software vulnerability life cycle”, Developer IQ, vol. 8, 2008, pp.27-30. Alka Agrawal and R A Khan, “Securing vulnerable software: A Checklist Approach,” Proc. Conf. Advanced Computing and Computation Technologies for High Performance Applications, 24-26 Sep 2008, pp. 302-309. S. Ardi, and N. Shahmehri, “Integrating a security plug-in with the Open UP/ basic development process,” Proc. IEEE Conf. Availability, Reliability and Security(ARES’08), IEEE, 4-7 Mar 2008, pp. 284-290,Doi: 10.1109/ARES.2008.132. A. Agrawal, R A khan and S. Chandra, “Software security processdevelopment life cycle perspective,” CSI communications, Aug 2008, pp.39-42. J.-E. J. Tevis, and J. A. Hamilton, Jr., “Methods for the prevention, detection and removal of software security vulnerabilities,” Proc. ACM Conf. Southeast Conference (ACMSE’04), ACM, 2-3 Apr, 2004, pp. 197- 202, doi:acm.org/10.1145/986537.986583. A. Ozment, “Improving vulnerability discovery models,” Proc. ACM Workshop. Quality of Protection (QoP’07), ACM, 29 Oct 2007, pp. 6-11, doi:acm.org/10.1145/1314257.1314261 O. H. Alhazmi and Y.K. Malaiya, “Modeling the vulnerability discovery process,” Proc. IEEE Symp. Software Reliability Engineering (ISSRE’05), IEEE, 8-11 Nov 2005, pp. 1-10, doi: 10.1109/ISSRE.2005.30. O. A. Alhazmi, Y. K. Malaiya and I. Ray, “Security vulnerabilities in software systems: A quantitative perspective”, Data and Applications Security 2005, LNCS 3654, pp. 281-294, doi:10.1007/11535706. P. Manadhata, and J. M. Wing, “An attack surface metric”, CMUCS-05-155, July 2005. Available at: http://www.cs.cmu.edu/%7Ewing/publications/CMU-CS-05155.pdf. J. A. Foss, and S. Barbosa, “Assessing computer security vulnerability,” ACM SIGOPS Operating Systems Review, vol. 29, 1995, pp. 3-13, doi:acm.org/10.1145/206826.206829. I. M- Ruffin, D. Umphress, J. Hamilton, and J. G. Gilbert, “Quantitative software security risk assessment model,” Proc. Workshop Quality of Protection (QoP’07), ACM, 29 Oct 2007, pp. 31-33, doi: acm.org/10.1145/1314257.1314267. J. Zadeh, and D. DeVolder, “Software development and related security issues,” Proc. Conf. SoutheastCon’07, IEEE, 22-25 Mar 2007, pp. 746- 748, doi: 10.1109/SECON.2007.343000. F. Piessens, “A Taxonomy (with examples) of causes of software vulnerabilities in Internet software,” Report CW 346, August 2002.
Available at: www.cs.kuleuven.be/publicaties/rapporten/cw/CW346.ps.gz [29] C.M. Chung, C. C. Wang, and M. C. Lee, “Class hierarchy based metric for object oriented design,” Proc. Conf. Frontiers of Computer Technology (TENCON’94), IEEE, 22-26 Aug 1994, pp. 986- 991, doi: 10.1109/TENCON.1994.369163. [30] R. Scandariato, B. D. Win, and W. Joosen “Towards a measuring framework for security properties of software,” Proc. ACM Workshop(QoP’06), ACM, Oct 2006, pp.27-30, doi: acm.org/10.1145/1179494.1179500. [31] S. Chandra and R. A. Khan, “Object oriented software security estimation life cycle - Design phase perspective,” Journal of Software Engineering, vol. 2, 2008, pp. 39-46. Available at: http://www.scialert.net/abstract/?doi=jse.2008.39.46&sess=jJghHk jfd76K8JKHgh76JG7FHGDredhgJgh7GkjH7Gkjg57KJhT&userid =jhfgJKH78Jgh7GkjH7Gkjg57KJhT68JKHgh76JG7Ff
623
