Research Article A Quantitative Assessment...

12
Hindawi Publishing Corporation Mathematical Problems in Engineering Volume 2013, Article ID 165029, 11 pages http://dx.doi.org/10.1155/2013/165029 Research Article A Quantitative Assessment Approach to COTS Component Security Jinfu Chen, 1 Yansheng Lu, 2 Huanhuan Wang, 1 and Chengying Mao 3 1 School of Computer Science and Telecommunication Engineering, Jiangsu University, Zhenjiang 212013, China 2 School of Computer Science and Technology, Huazhong University of Science and Technology, Wuhan 430074, China 3 School of Soſtware and Communication Engineering, Jiangxi University of Finance and Economics, Nanchang 330013, China Correspondence should be addressed to Jinfu Chen; [email protected] Received 28 August 2012; Revised 26 December 2012; Accepted 31 December 2012 Academic Editor: Huaguang Zhang Copyright © 2013 Jinfu Chen et al. is is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. e vulnerability of soſtware components hinders the development of component technology. An effective assessment approach to component security level can promote the development of component technology. us, the current paper proposes a quantitative assessment approach to COTS (commercial-off-the-shelf) component security. e steps of interface fault injection and the assessment framework are given based on the internal factors of the tested component. e quantitative assessment algorithm and formula of component security level are also presented. e experiment results show that the approach not only can detect component security vulnerabilities effectively but also quantitatively assess the component security level. e score of component security can be accurately calculated, which represents the security level of the tested component. 1. Introduction In the area of soſtware engineering, component-based soſt- ware engineering (CBSE) has currently become a research point. e various development technologies of components further improve the development efficiency and performance of components, but the problems on the reliability and security of components have not yet been resolved. Current component testing approaches have focused on component functionality testing, which, to some extent, guarantees the correctness and integrity of component functionality. How- ever, component security testing is rarely researched as a special subject. Component security testing mainly involved in testing the vulnerabilities of component which can be exploited to crack soſtware component. ere are some gen- eral component vulnerabilities such as memory leakage, stack overflow, access beyond boundary, and access protected page. In addition, the special difficulties for the security testing of COTS component are as follows. Firstly, the source codes are unavailable. Secondly, e general security pattern is difficult to attain by analyzing the general classification model of soſtware vulnerability. Finally, e COTS component is very independent, which results in some problems such as gaining the effective component information and running the independent component. On the other hand, the assessment of component security has not been solved. Research on the quantitative assessment of component security level is rather rare. In the field of soſtware testing, quantitatively assessing the security level of the component system not only guarantees and enhances the system’s reliability and security but also conducts a quantitative assessment level to soſtware developers and facilitates users in selecting soſtware products based on its security to reduce the risk of attack. Nevertheless, component security vulnerabilities are usu- ally studied, but the quantitative assessment of component security is not common. Most scholars only research on the theoretical description of security assessment, but practical implementation methods are not presented. A basic assess- ment approach was given in the literature [1]. Based on the knowledge of information security, the main approach is dividing the component security vulnerability into several ranks [2]. e security level of components is assessed using the soſtware testing technology. e relevant experiments were conducted but were not studied in depth. Enough internal information should be collected before assessing the security level for the soſtware component. But,

Transcript of Research Article A Quantitative Assessment...

Hindawi Publishing CorporationMathematical Problems in EngineeringVolume 2013 Article ID 165029 11 pageshttpdxdoiorg1011552013165029

Research ArticleA Quantitative Assessment Approach toCOTS Component Security

Jinfu Chen1 Yansheng Lu2 Huanhuan Wang1 and Chengying Mao3

1 School of Computer Science and Telecommunication Engineering Jiangsu University Zhenjiang 212013 China2 School of Computer Science and Technology Huazhong University of Science and Technology Wuhan 430074 China3 School of Software and Communication Engineering Jiangxi University of Finance and Economics Nanchang 330013 China

Correspondence should be addressed to Jinfu Chen jinfuchenujseducn

Received 28 August 2012 Revised 26 December 2012 Accepted 31 December 2012

Academic Editor Huaguang Zhang

Copyright copy 2013 Jinfu Chen et al This is an open access article distributed under the Creative Commons Attribution Licensewhich permits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

The vulnerability of software components hinders the development of component technology An effective assessment approach tocomponent security level can promote the development of component technology Thus the current paper proposes a quantitativeassessment approach to COTS (commercial-off-the-shelf) component security The steps of interface fault injection and theassessment framework are given based on the internal factors of the tested component The quantitative assessment algorithmand formula of component security level are also presented The experiment results show that the approach not only can detectcomponent security vulnerabilities effectively but also quantitatively assess the component security level The score of componentsecurity can be accurately calculated which represents the security level of the tested component

1 Introduction

In the area of software engineering component-based soft-ware engineering (CBSE) has currently become a researchpoint The various development technologies of componentsfurther improve the development efficiency and performanceof components but the problems on the reliability andsecurity of components have not yet been resolved Currentcomponent testing approaches have focused on componentfunctionality testing which to some extent guarantees thecorrectness and integrity of component functionality How-ever component security testing is rarely researched as aspecial subject Component security testing mainly involvedin testing the vulnerabilities of component which can beexploited to crack software component There are some gen-eral component vulnerabilities such asmemory leakage stackoverflow access beyond boundary and access protected pageIn addition the special difficulties for the security testing ofCOTS component are as follows Firstly the source codesare unavailable Secondly The general security pattern isdifficult to attain by analyzing the general classificationmodelof software vulnerability Finally The COTS component isvery independent which results in some problems such as

gaining the effective component information and running theindependent component On the other hand the assessmentof component security has not been solved Research onthe quantitative assessment of component security level israther rare In the field of software testing quantitativelyassessing the security level of the component system not onlyguarantees and enhances the systemrsquos reliability and securitybut also conducts a quantitative assessment level to softwaredevelopers and facilitates users in selecting software productsbased on its security to reduce the risk of attack

Nevertheless component security vulnerabilities are usu-ally studied but the quantitative assessment of componentsecurity is not common Most scholars only research on thetheoretical description of security assessment but practicalimplementation methods are not presented A basic assess-ment approach was given in the literature [1] Based on theknowledge of information security the main approach isdividing the component security vulnerability into severalranks [2] The security level of components is assessed usingthe software testing technology The relevant experimentswere conducted but were not studied in depth

Enough internal information should be collected beforeassessing the security level for the software component But

2 Mathematical Problems in Engineering

it is usually very difficult to obtain the internal informationfor COTS (commercial-off-the-shelf) components becauseits source codes are unavailable In order to obtain moreinformation about COTS component it is necessary thatsome data are inputted the tested component to drive thecomponent runningWhen the tested component is runningsome internal information including some security informa-tion can be collected by monitoring the running state ofthe tested component The data-driven method can obtaininternal security information for COTS component In thecurrent research we propose a feasible approach to assessthe component security level quantitatively through usingdata-drivenmethod and learning from relevant statistical andprobabilistic methods The exceptional component informa-tion monitored by the dynamic monitoring system can beobtained by the testing system of component vulnerability[3] Relevant security factors are assigned to appropriatesecurity exceptions according to the classification of thevulnerability in the Common Vulnerabilities and Exposures(CVE) vulnerability library Each of the exceptional vulner-ability factor values can be obtained from the triggeringcauses of software security vulnerabilities which is a harmfuldegree combined with the characteristics of the componentsecurity vulnerabilities Finally six commercial componentsin which security vulnerabilities exist are collected forexperimental analysis in the CVE Web site and are assessedby the proposed approach The number of each interfaceand methods used for each interface can be obtained bydynamically executing the tested components The executedprobabilities of each interface and methods used for eachinterface can be determined by statistical method At thesame time fault injection operators and the logical predictionrules of exceptional database (PRED) are proposed accordingto the component security exceptions commonly used Thisapproach not only can assess the component security level butalso effectively assess the security level of each interface thusproviding better assessment capabilities

2 Related Work

At present commercial-off-the-shelf (COTS) componentssuch as military mechanization financial components andso on are used by more and more commercial softwareincluding some crucial security software COTS securitytakes an important part in component systems because thesecurity of the whole software system is determined by itTherefore assessing the security level of the component isused to test the security of the entire software system whichhas become an essential part in component testing To thebest of our knowledge research on assessing the softwarecomponent security mainly focuses on component secu-rity requirements and assessment approaches vulnerabilityassessment and quantitative risk assessment

Han and Zheng [4] and Jabeen and Jaffar-Ur Rehman[5] studied the security requirements and security assessmentmethods of components but did not give the specific relevantassessment methods Md Khan et al examined the securitytesting description and component assessment [6ndash8] Models

of the user data security component security framework andsecurity assessment model of software were proposed Khanand Han developed an assessment scheme for the securityproperties of software components The assessment schemeprovided a numeric score that indicates the relative strengthof the security properties of the component [8] However theapproach consists of two prerequisites (1) a security require-ment specification of the candidate component and (2) acomponent-specific security rating The approach requiresthe source codes of candidate component to be availableThesecurity property descriptions of the components based onthe security assessment standards of information technologywere proposed by Khan et al [9] The main attributes ofresource allocation user data protection and communica-tions were included The model was based on the activeinterface which could provide the basis for reasoning andassessing a componentrsquos security to meet certain securityrequirements of a particular application Common criteria(CC) provide a schema for evaluating information systemand enumerate the specific security requirements for suchsystems [10]The functional requirements in CC describe thesecurity behavior or functions expected of an informationsystem to counter threats but not all the requirements in CCmay be applicable directly to software components becauseof the distributed nature of software components and theircompositional complexity

Alhazmi and Malaiya proposed a time-based model forthe total vulnerabilities and an alternative model which isanalogous to the software reliability growth models [11]However this model cannot quantitatively assess the securitylevel of software Zhang et al presented a vulnerabilityrisk assessment method based on the attack tree modeland Bayesian network model [12] The analysis method canassess the risk probability of the software system but not itssecurity level The security risk assessment was introducedto the classical MDA (Model-Driven Architecture) frame-work [13] The extension offers early assessment and earlyvalidation of security requirements However the improvedframework still has not provided the quantitative mechanismof the software security A systematic methodology wasproposed for some software vulnerability assessment andsecurity function verification [14] A scalable and adaptableautomatic test system was implemented to test hundreds ofsoftware releases but the security assessment of softwarereleases was not implemented The state of the architecture-based approach to reliability assessment of component-basedsoftware was presented [15] The common requirementsof the architecture-based models were identified and theclassification was proposed However the approach only gavea framework for the reliability assessment of component-based software

Idongesit proposed a quantitative risk assessment modelbased on annualized loss expectancy and the exposure factorwhich is the percentage of asset loss due to the potentialthreat [3] The model can assess the potential threats toa development effort and rank these threats based on therisk metric calculation The Common Vulnerability ScoringSystem (CVSS) [16] provides an open framework for commu-nicating the characteristics and effects of IT vulnerabilities Its

Mathematical Problems in Engineering 3

quantitative model ensures repeatable accurate measurementwhile enabling users to see the underlying vulnerabilitycharacteristics used to generate the scores However CVSSmeasures software vulnerability based on the external factorsof software system Occasionally the result cannot preciselyrepresent the software vulnerability

In summary we propose a new quantitative assess-ment of component security (QACS) approach to representmore accurately the security level of the COTS componentbased on the internal factors of software component Theinternal factors of software component are some importantinformation inside the component instead of the outsideenviornment There are some main internal factors such asthe component objects component interfaces componentmethods and component attributes These internal factorsreflect more accurate security features for the tested compo-nent

3 A Quantitative Assessment Framework forComponent Security

With the further development of component-based softwareengineering COTS components have become frequentlyused in software systems The source codes of the COTScomponent are unavailable and highly independent Thetraditional testing approach of interface mutation is suitablefor system integration testingThat is mutation operators areonly effective at the interface between the module and thesubsystem Therefore the traditional method is unsuitablefor testing the COTS component system Interface mutationtesting which is suitable for the COTS component caninject faults at the component interface level by extending themutation operators in the program mutation and increasingthe mutation operators at the component interface level Thedefects of components can be identified through observationand analysis of the testing result of the system Figure 1 showsthe quantitative assessment framework of the componentsecurity level

The interface fault injection operators of the COTS com-ponent include irregular input parameter operatorsmutationoperators based on program language mutation operatorsbased on interface specifications [17] andmutation operatorsbased on interface definition language (IDL) [18] The faultinjection operators which are commonly used are as followsboundary value parameter parameter beyond the lengthparameter attribute replaced parameter swap parameterchange parameter assignment parameter set null and so on

The test cases of fault injection can be generated throughthe selection of a suitable fault injection operator basedon parameter types and number of component methods inthe interface information The test scripts can be generatedaccording to the test cases The component can be runwith the test scripts The running state can be monitoredthrough the dynamic monitoring mechanism Componentvulnerability of the interface methods can be determinedby the running state of the component security predictionmechanism prediction rules and vulnerability factor invariousmethodsThe vulnerable score can be obtained under

Test cases implemented

System state

Rules library

Security level assessment

Fault injectionoperator

Componentinterface

information

Vulnerability factor value Probabilitymatrix

Security anomaly assessment

Component 119862

Figure 1 A quantitative assessment framework

certain running environments in terms of the vulnerabilityassessment method of component C The vulnerability scorewhich can assess the security of component C is called thesecurity level of component

31 Fault Injection Operator of the Component Vulnerability

Definition 1 Fault injection operator prod is the rule thatgenerates a number of fault injection test cases namelyprod rarr

Ψ1 Ψ2 Ψ

119899 Ψ119894denotes a fault injection test case A class

of fault injection test cases can be implemented by one faultinjection operator

Definition 2 Interface fault injection operation 119874 is a binaryrelation 119874(prod 119875) where 119875 is a class of interface parameters119874(prod 119875) = (Ψ

119894 119901119894) isin Ψ

1 Ψ2 Ψ

119899times119875 Fault injection test

case which is implemented by fault injection operatorprod actson the interface parameter 119901

119894 where119874(prod 119875) can be short for

119874 only if it does not cause confusion

Whether the generated test cases of fault injection arerepresentative is the key to designing the fault injection oper-ator that is whether the generated test cases of fault injectioncan trigger the componentrsquos security vulnerability as greatlyas possible Two errors namely environmental errors andinterface parameter errors can trigger component securityvulnerabilities in a component system The first error whichis discussed in the previous paper [1] does not repeat it againThe focus of the current paper is the interface parameterfault injection The errors in the interface parameter includethree types IDL description errors boundary value errorsand irregular input errors In detail they are the methoderrors defined by the IDL description all boundary valueand irregular input value errors respectively Based on thecause of triggering software security vulnerabilities in prac-tical experience 18 fault injection operators of componentvulnerability are specifically designed by comprehensivelyanalyzing the interface mutation operators and the opera-tors of parameter fault injection These operators are PAS

4 Mathematical Problems in Engineering

Table 1 Exceptional predication rules and vulnerability factors

ID Predication rules Description VC01 General exception The general exception code is detected or throw an exception 05

02 Access out of range Running a thread attempts to read or write the memory address buthas no corresponding access authority 1

03 Matrix visited beyond scope A thread tries to access an array element beyond scope 1

04 Access the memory page not exiting The file system returns a read error resulting in page fault whichcan-not meet the requirements 08

05 Visit the protected page A thread tries to access memory page that has the attribute ofPAGE GUARD 1

06 Stack of thread is overflow A thread runs out of all stack space assigned to it 1

07 Execute illegal instruction A thread running an instruction that is not allowed in the currentthread or executing an invalid instruction 1

08 Divisor is 0 A thread tries to divide an integer or a float by 0 08

09 Operation out of range An operation result exceeds the specified range values 08

10 Floating-point stack overflow Stack overflow or underflow because of floating-point operations 1

11 Buffer overflow Written contents beyond the buffer length resulting in written datacovering the original return address and destroying the program stack 1

12 Memory leakageMonitoring the input and output values of malloc() free() realloc()functions and making a statistical analysis to achieve a memoryleakage check

1

13 Format string exceptions Format or parameter mismatch when using printf() function such asldquonnsdrdquo 1

(Parameter Attribute Swap) PSN (Parameter Set Null) IPO(Insert Parameter Operator) PFB (Parameter Flip Bit) PRI(Parameter Reverse-probability Input) IIV (integer IrregularValue) FIV (Float Irregular Value) CIV (Char IrregularValue) BIV (Boolean Irregular Value) RSV (Random StringValue) LSV (Long String Value) FSV (Format String Value)DSV (Directory String Value) USV (URL and string valueof file directory) CSV (System Command String Value) SSV(SQL string injection) and CSS (Cascading Style Sheet) Thenew security vulnerabilities found in components can also beadded

In addition the reverse distribution function of theparameter input domain is generated using the input operatorPRI of the parameters of reverse probability distributionThe parameters of reverse probability distribution are thengenerated The experimental result shows that componentsecurity exception can be effectively triggered through theirregular value of input domain The input distributionfunction which is usually difficult to obtain is a probabilitydensity functionThe one dimensional andmultidimensionalfunctions are the two commonly used kinds Q is assumedthe input distribution function of which the value is in theinterval [0 1] and the value 0 indicates the probability ofselection input field is 0 The algorithm of reverse probabilitydistribution 1198761015840 is given in the literature [19]

A number of models have been designed to facilitatethe automatic management of the fault injection operatorsuch as the automatic learning model of the fault injectionoperator adaptive model topic model intelligent vulnerabletrees among others They can automatically increase andmanage the operator libraries of fault injection

32 Exceptional Predication Rules and Vulnerability Factors

Definition 3 The component exceptional predication rule isa set of all the possible exceptions that may arise under theexceptional circumstances

Definition 4 The vulnerability factor of the component rep-resents the degree of the component security vulnerabilitiesresulting from exceptions The maximum value is 1 and theminimum value is 0 Table 1 shows the component excep-tional predication rules and relative vulnerability factorsused to assess the component security level Each of thefactor value of exceptional security vulnerability which canobjectively describe the component security level is obtainedfrom the triggering causes of software security vulnerabilitieswhich is a harmful degree combined with the characteristicsof component security vulnerabilities based on experiencesoftware engineering

4 Component Security Assessment Algorithm

Suppose 119862 is a component and 119868 is a set of interface in119862 Let 119901

119894represent the execution probability of interface 119894

and119872119894is a method properties set of interface 119894 Meanwhile

119901119894119898

is the executable probability in method 119898 of interface 119894Suppose |119868| = 119873 |119872

119894| = 119878 119909 is the input parameter of the

method attribute in 119862 119879 is vulnerable error test cases set and119879 = 119905

1 1199052 1199053 119905

119899 Δ is all the input set of component

119862 1198761015840 is the reverse probability distribution of Δ PRED isthe logical prediction rules of exceptional database VC isthe vulnerability factor of exceptional function Before the

Mathematical Problems in Engineering 5

vulnerability assessment method of component is given thefollowing definitions should be introduced first

Definition 5 Let 119875 represent an 119873 times 119878 probability matrixthat can be described as 119875 = (119901

119894119895)119899times119904

row 119894 represents theinterface number of component 119862 and column 119895 representsthe method number of interface 119894 The element 119901

119894119895states

the executable probability for function 119895 at interface 119894 ofcomponent 119862 where 119901

119894119895= 119901119894times 119901119895

Definition 6 Interface method coverage (MC) where MC =

(the number of methods executed at least oncethe totalnumber methods 119878) times 100 is used to measure the sufficientdegree of the interface method during component testing

Definition 7 Interface coverage (IC) where IC = (the numberof interfaces executed at least oncethe total number interface119873) times 100 is used to measure the sufficient degree of theinterface test during component testing

Definition 8 Component test adequacy CA can be measuredby a two-tuple (ie MC and IC) Generally the value isdetermined by the total score of MC and IC that is CA =

[sum119894=1119873

(MC119894)]119873+IC A greater value of CA indicates amore

comprehensive test the relationship between MC and IC isparallel

Suppose Sum 119872 represents the number of test meth-ods cnt represents the number of vulnerability methods incomponent 119862 and VC

119894represents the vulnerability factors of

exceptional method The value of vulnerability factor VC119894is

assigned to 0 in case the interface method has no securityexceptions The execution probability of the vulnerabilitymethod 119894 is labeled 119875

119894 The component vulnerability assess-

ment formula is given as follows

Vul119888= 1 minus

cntprod119894=1

(1 minus 119875119894times VC119894) (1)

The value 1 minus Vul119888 the security level of the component

119862 can be derived from the Formula (1) The vulnerabilityassessment formula of the component has the followingproperties

Property 9 (0 le Vul119888le 1)

Proof For any vulnerability method 1 ge 119875119894ge 0 and 1 ge

VC119894ge 0 can be determined according to the definition of

VCTherefore 1 ge 119875119894timesVC119894ge 0 1 ge 1minus119875

119894timesVC119894ge 0 and 0 le

prodcnt119894=1(1 minus 119875

119894times VC119894) le 1 are derived that is 0 le Vul

119888le 1

Property 9 shows that the value of any componentrsquosvulnerability index is between 0 and 1 with a larger valueindicating a higher vulnerability index

Property 10 (Vul119888ge max(119875

119894times VC119894) ge 0)

Proof For any vulnerability method 1 ge 119875119894ge 0 and 1 ge

VC119894ge 0 can be determined according to the definition of VC

Therefore max(119875119894timesVC119894) ge 0 In addition 1 ge 1minus119875

119894timesVC119894ge 0

and 1minusVul119888= prod

cnt119894=1(1minus119875119894timesVC119894) can be derived fromFormula

(1)prodcnt119894=1(1 minus 119875

119894timesVC119894) = (1 minus 119875

1timesVC1) times (1 minus 119875

2timesVC2) times sdot sdot sdot

times (1 minus max(119875119894times VC119894)) times sdot sdot sdot times (1 minus 119875cnt times VCcnt) therefore

prodcnt119894=1(1 minus 119875

119894times VC119894) le (1 minus max(119875

119894times VC119894)) and 1 minus Vul

119888le

(1minusmax(119875119894timesVC119894)) are derived that is Vul

119888ge max(119875

119894timesVC119894)

Thus Vul119888ge max(119875

119894times VC119894) ge 0 can proved correct

Property 10 shows that the vulnerability index of any onecomponent is not less than the peak value of the methodsrsquovulnerability indexes of the component All situations ofthe vulnerability methods of component are syntheticallyconsidered by the index of the vulnerability of component

Based on the component vulnerable assessment methodbased on the analysis of the interface the algorithm of thecomponentrsquos security assessment level is given as follows

The input probability matrix 119875 in Algorithm 1 is not onlyderived from the component requirement specifications orequal probability but is also statistically calculated after thecomponent is practically executed The vulnerability factorVC119894119895is assigned to 0 given that the component has no security

exceptional interface method We usually set the value of120575 and 120579 from 0 to 1 according to the complexity of testedcomponent and the testing requirement If the number ofinterfaces and methods of tested component is no more than200 we usually let the value of 120575 and 120579 to be 1 to ensurea complete testing of COTS In addition the test cases ofinterface parameters are generated using the TGSM [20 21]algorithm First the test cases of the interface parameter fault-injection expressed in matrix form are generated in termsof fault injection operator The K-factor coverage solutionmatrix is generated by the TGSM algorithm which is basedon the parameter set of the matrix form The fault injectiontest cases are composed of row data of the solution matrixTest cases generated by the TGSM algorithm not only greatlyreduce the scale of the test cases but also have certaincoverage The algorithm can trigger most of the securityexceptions with fewer test cases

Cnt is the number of vulnerability methods of the com-ponent 119862 in the algorithm results Vul

119894119895is the vulnerability

ratio of the method 119895 at the interface 119894 of the component 119862Vul119888represents the vulnerability level of the component 119862

1 minus Vul119894119895 the security level of the component 119862 represents

the security of the method 119895 in the interface 119894 of component119862

5 Experiment Analysis

To validate the effectiveness of the proposed approachthe approach was implemented in our component securitytesting system (CSTS) platform [22]The component securitytesting and assessing system based on interface fault injection(CSTASboIFT) was implemented using C language in theMicrosoft NET platform It is used as a subsystem of theCSTS platform Figure 2 shows the function flow chart ofCSTASboIFT

In the experiment six commercial components (Table 2)in which security vulnerabilities exist were collected forexperimental analysis in the CVE Web site Several group

6 Mathematical Problems in Engineering

Input Interface information XML file Fault injection operator Prediction rules PREDProbability matrix 119875 MCrsquos threshold and ICrsquos threshold value 120575 and 120579Output The security level of the whole component01 02 Read XML file03 MC = 0 IC = 0 119894 = 0 cnt = 0 cnt is the number of component vulnerability methods04 While IC lt 120575 do For each interface 119894 in 11986805

06 119894 = 119894 + 1 119895 = 007 While MC lt 120579 do For each method119898 in119872

119894

08

09 119895 = 119895 + 1 119895 is the number of the testing methods10 Generate method parameter values set according to fault injection operators11 Call testing cases generating algorithm TGSM() call the generation algorithm of the

minimum 119870 factors combined cover test case based on solution matrix12 Running 119862 and119872

119894119895

13 If (the output after running 119862 and119872119894119895satisfies PRED)

14

15 increment cnt16 Vul

119894119895= VC

119894119895times 119875119894119895 the vulnerability level of the method 119895 in the interface 119894

17

18 MC = 11989511987819

20 IC = 11989411987321

22 Vul119888= 1 minus prod

cnt119894=1(1 minus 119875

119894times VC

119894)

23 (Output) 1 minus Vul119888

24

Algorithm 1 QACS (quantitative assessment of component security) algorithm

Tested component

Interface analysis

Component interface

Implement test cases

Fault injectionoperator

Compile driven execution

Dynamic monitor

Probabilitymatrix

Vulnerability factor value Probabilitymatrix

Security levelassessment report

information (XML file)

Monitor loginformation

Assessmentrule library119875

Figure 2 The function flow chart of CSTASboIFT

experiments were conducted for these components A com-ponent composed of six interfaces and each interface consist-ing of eight methods were assumed so that the componentcould be regarded as a 6 times 8 matrix The first group of

experiments tested the condition of 119875119894119895assigned to a fixed

matrix and VC119894119895divided into interval descending As VC

119894119895

changed the 1 minus Vul119888was affected That is only the level of

vulnerability factors affected the component security levelThe second group of experiments tested the condition ofVC119894119895assigned to a fixed matrix and 119875

119894119895divided into interval

descending As 119875119894119895changed 1 minus Vul

119888was affected That is

only the executed probability affected the component securitylevel The last group of experiments considered the effect on1minusVul

119888 as both vulnerability factor and executed probability

simultaneously changed

51 Experiment One Thevulnerability factor value is dividedinto intervals based on the knowledge of security vulner-ability provided by the CVE Web site 119875

119894119895represents the

executable probability of the method 119895 at the interface 119894VC119894119895represents the vulnerability factors of the method 119895 at

the interface 119894 and Vul119888represents the vulnerability level of

component 119862 1 minus Vul119888is the security level of component 119862

The first experiment assumes that 119875119894119895is a 6 times 8 fixed

matrix which is made up of random values For everyinterval 119875

119894119895is the same matrix VC

119894119895is divided into 10

intervals [000 009] [010 019] [020 029] [030 039][040 049] [050 059] [060 069] [070 079] [080 089]and [090 100] The tests were done about ten times withdifferent random values of 119875

119894119895and VC

119894119895 respectively in the

experiment and then the value 1minusVul119888was got by calculating

Mathematical Problems in Engineering 7

Table 2 The six typical tested components

Component ID Component name Component information01 ThunderAgent 005dll An ActiveX control in Thunder 5 Component version is 10011 Thunder version is 55225202 AcroPDFdll An AcroPDF ActiveX control in Adobe Reader and Acrobat Component version is 708003 GLItemComdll An ActiveX control in OURGAMEWORLD game software Component version is 270804 pdg2dll An ActiveX control in SUPERSTART READER software Component version is 390005 GomWeb3dll An ActiveX control in GOM Player GOM Player is a media player widely used in Korea06 Vulndll A third-party tested component Component version is 1012

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

VC119894

1minusVu

L 119888

(a) cnt = 5

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(b) cnt = 10

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(c) cnt = 15

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(d) cnt = 20

Figure 3 The comparison for different VC119894and cnt

the average result Under the condition that 119875119894119895is regarded as

a 6 times 8matrix at every interval of VC119894119895 VC119894119895affects the value

1 minus Vul119888

When Vul119894119895is equal to 119875

119894119895times VC119894119895 as 119875119894119895is a fixed value

the values of Vul119888and Vul

119894119895are proportional to the value of

VC119894119895 The value of 1 minus Vul

119888is reversely proportional to VC

119894119895

A larger VC119894119895value indicates a lower security level As the

vulnerability number increases the security level decreasesslowly The results are shown in Figure 3 The testing resultsshow that the proposed assessment Formula (1) is effective

52 Experiment Two VC119894119895is assumed a 6 times 8 fixed matrix

made up of random values in the second experiment Then119875119894119895

is divided into 10 intervals [000 009] [010 019][020 029] [030 039] [040 049] [050 059] [060 069][070 079] [080 089] and [090 100] The tests were doneabout ten times with different random values of 119875

119894119895and VC

119894119895

respectively in the experiment and then the value 1minusVul119888was

got by calculating the average result Under the condition thatVC119894119895is regarded as a 6 times 8 matrix at every interval of 119875

119894119895 119875119894119895

affects the value of 1 minus Vul119888

When VuL119894119895is equal to 119875

119894119895times VC119894119895 as the value of VC

119894119895

is fixed the values of Vul119888and VuL

119894119895are proportional to the

value of 119875119894119895 The value of 1 minus Vul

119888is reversely proportional

to VC119894119895 A larger 119875

119894119895value indicates a lower security level

That is the component is more insecure As the number ofcnt increases the decline rate of the security level is initiallyfast and then becomes slow The results as presented inFigure 4 show that the proposed assessment Formula (1) iseffective

53 Experiment Three Both parameters 119875119894and VC

119894are

assumed to influence the value of 1 minus Vul119888in Experiment

three The two parameters are randomly divided into 10

8 Mathematical Problems in Engineering

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(a) cnt = 5

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(b) cnt = 10

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(c) cnt = 15

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(d) cnt = 20

Figure 4 The comparison for different 119875119894and cnt

intervals The effect on the value of 1 minus VuL119888when the

two parameters changed simultaneously was observed Theresults show that when 119875

119894is proportional to VC

119894 the value

of 1 minus Vul119888changes significantly as shown in (a) and (b)

of Figure 5 When 119875119894is inversely proportional to VC

119894 the

value of 1 minus Vul119888changes indistinctly as shown in (c) and

(d) of Figure 5 As the vulnerability number cnt increasesthe security level decreases Results are shown in Figure 5The values of 119875

119894and VC

119894are based on the main 119910-axis values

(the left axis) and the value of the 1 minus Vul119888is based on the

secondary 119910-axis values (the right axis) The testing resultsshow that the proposed assessment Formula (1) is suitable forassessing the COTS component

54 Experiment Four The components were assessed inTable 3 based on Algorithm 1 The value of IC and MC is setto 1 119875

119894can be determined by executing the tested component

100 times or moreDuring the system testing process the test cases of fault

injection can be implemented by testing the componentinformation and fault injection operators The testing statecan be recorded through the dynamic monitoring mecha-nism after running the tested component The vulnerabilitytype of the componentmethod and vulnerability factor can bederived from comparing the testing state with the componentinformation record in PRED The execution probability 119875

119894

of each method in the component can be determined byrunning the tested component 100 times respectively Thenthe component security level can be determined using For-mula (1)The testing results are shown in Table 3 Because dif-ferent components have different method parameters whichhave different parameter types such as integer string andboolean we select suitable fault injection factors to test thecomponent security based on the above presented 18 faultinjection operators of component in Table 3

A higher level of security indicates better relative securityof the component The component is secure if and only ifthe component security level is 1 Otherwise it has securityvulnerability In contrast to the test results in Table 3 the levelof security is closer to the vulnerability information publishedin the CVE Web site The values of execution probabilityand vulnerability factors have been proved to affect thecomponent security The results agree with the previousexperimental results further confirming the feasibility andeffectiveness of this approach

55 Experimental Comparison Table 4 shows the compar-ison with other assessment approaches The related assess-ment approaches have various merits as shown in theanalysis of Table 4 Our QACS approach mainly focuseson quantitatively assessing the security level of the COTScomponent The source codes of the COTS component are

Mathematical Problems in Engineering 9

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(a) cnt = 5

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(b) cnt = 10

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(c) cnt = 15

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(d) cnt = 20

Figure 5 The comparison for different 119875119894 VC119894 and cnt

generally unknownThe internal factors of the component areconsidered in QACSThe QACS approach is implemented inthe CSTASboIFT that is integrated into our CSTS [22] systemdeveloped to test the security of the COTS component

Aside from the above-mentioned approaches CVSS is awidely used quantitative assessment approach for softwarecomponent Khan and Han developed an assessment schemefor the security properties of software components Theassessment scheme provided a numeric score that indicatesthe relative strength of the security properties of the compo-nent [8] Results of the comparison with the CVSS approachand Khaled approach are shown in Table 5 In addition thesecurity level of six tested components is also listed accordingto the reported empirical data of securityWeb sites in Table 5The initial CVSSBase Score is calculated by theCVSS formula[16]

Analyzing Table 5 the QACS approach is found to beclose to the empirical data reported on some security Websites regarding the security of the tested COTS componentsThe security score of the QACS approach is more accuratethan that of others because the internal factors of the tested

component are considered The assessment process of theQACS approach is objective without human interventionNevertheless the CVSS approach ismainly focused on assess-ing the vulnerability of the general software componentIf an assessor is not familiar with the assessed softwarethe vulnerability score becomes inaccurate because of theassessorrsquos subjectivity in the assessment process On the otherhand the Khaled approach is an approximate assessmentapproach based on the assumed component environment Inaddition presently there are no more effective assessmentapproaches for the security level of software componentaccording to our studies

6 Conclusion

In component-based software development andmaintenanceactivities the assessment of the component reliability andsecurity level is essential in the third-party componentResearch on an effective quantitative assessment methodfor component security level is valuable in the CBSE The

10 Mathematical Problems in Engineering

Table 3 Testing results for six tested components

ID Fault injectionfactor

The number ofvulnerabilities and its 119875

119894

Test result Security level

01 IIV 2(013 013)

ThunderAgent 005dll has two methods calling(GetInfoStruct() GetTaskInfoStruc()) neglected the inputparameter exception and generated security vulnerability Thenthey resulted in program breakdown

07569

02 CIV LSV RSV 5(01 02 01 015 02)

AcroPDFdll did not correctly deal with the string parameterssent to function setPageMode() LoadFile() setLayoutMode()and setNamedDest() and the attribute src It triggered memorydestroyed and resulted in security vulnerability for executingany instruction

04406

03 LSV RSV FSV 1(064)

The function SetInfo() of GLItemComDLL ActiveX overtrusted user input and did not check parameterrsquos length Itresulted in the point the virtual function covered

036

04 LSV RSV FSV 1(01)

Pdg2dll did not deal with the sent parameter to Register () ifuser sends the string over 256 bytes it can trigger stack overflowand execute any code

09

05 LSV RSV USV 1(015)

GomManager object did not collectively deal with the firstparameter of OpenURL() in IGomManager interface Iftransmitting the long parameters over 500 bytes it can triggerstack overflow to result in visiting the memory exception

085

06 PSN CIV PIVLSV USV

5(015 015 015 015 015)

5 methods of component existed security exception The testcase parameters implemented by input fault injection operatorwould result in buffer overflow visiting beyond the scope andmemory leakage

04437

Table 4 The comparison with related assessment approaches

Assessment approach Assessment object Assessment aspect Is the internalfactor considered

Qualitative orquantitative

Is there supportingtool

Khan and Han [8] Software component Security No Quantitative NoAlhazmi and Malaiya[11] Operating system Vulnerability Yes Quantitative No

Zhang et al [12] Software system Risk No Quantitativequalitative

No

Goseva-Popstojanovaand Trivedi [15] Software system Reliability No Quantitative No

Mkpong-Ruffin [3] Software Risk No Quantitative Yes

CVSS [16] Software component Vulnerability No Quantitative Yes

QACS COTS component Security Yes Quantitative Yes

Table 5 The comparison with CVSS and Khaled approaches

ComponentID

InitialCVSS base

score

Convertedsecurity score

of CVSS

Securitylevel ofQACS

The reportedempirical data(security level)

01 58 042 07569 B+

02 19 081 04406 Cminus

03 6 04 036 D+

04 7 03 09 A

05 36 064 085 Aminus

06 19 081 04437 Cminus

current paper proposes theQACS approach for quantitativelyassessing component security which is based on the interfacefault injection of the componentThe fault injection operatorsof the component vulnerability and PRED are defined anddiscussedThe assessment framework and algorithm for com-ponent security are proposed as wellThe testing effect provesexcellent in practical application QACS has the followingmain advantages (1) the security exceptional assessmentrules and vulnerability factors of the component are givenproviding the basis for security assessment (2) QACS canassess the security level of the third-party component andthe score of component security can be accurately calculated(3) QACS has better operability

Mathematical Problems in Engineering 11

Acknowledgments

We would like to thank Professor T Y Chen for his con-structive suggestions and valuable discussion in this paperwriting In addition this work was supported partly bythe National Natural Science Foundation of China (NSFC)under Grants no 61202110 and no 61063013 Natural ScienceFoundation of Jiangsu Province under Grant no BK2012284and the Research Fund for the Doctoral Program of HigherEducation of China under Grant no 20103227120005

References

[1] J Chen Y Lu and X D Xie ldquoComponent security testingapproach by using interface fault injectionrdquo Journal of ChineseComputer Systems vol 31 no 6 pp 1090ndash1096 2010

[2] S Gudder andRGreechie ldquoUniqueness and order in sequentialeffect algebrasrdquo International Journal of Theoretical Physics vol44 no 7 pp 755ndash770 2005

[3] I O Mkpong-Ruffin Quantitative risk assessment model forsoftware security in the design phase of software development[PhD thesis] Auburn University Auburn Ala USA 2009

[4] J Han and Y Zheng ldquoSecurity characterization and integrityassurance for component-based softwarerdquo in Proceedings of theInternational Conference on Software Methods and Tools (SMTrsquo00) pp 61ndash66 IEEE Computer SocietyWollongong Australia2000

[5] F Jabeen and M Jaffar-Ur Rehman ldquoA framework for objectoriented component testingrdquo in Proceedings of the IEEE Inter-national Conference on Emerging Technologies (ICET rsquo05) pp451ndash460 Islamabad Pakistan September 2005

[6] K Md Khan J Han and Y Zheng ldquoCharacterizing userdata protection of software componentsrdquo in Proceedings of theSoftware EngineeringConference pp 3ndash11 CanberraAustralian2000

[7] K M Khan and J Han ldquoA security characterisation frame-work for trustworthy component based software systemsrdquo inProceedings of the 27th Annual International Computer Softwareand Applications Conference (COMPSAC rsquo03) pp 164ndash169November 2003

[8] K M Khan and J Han ldquoAssessing security properties ofsoftware components a software engineerrsquos perspectiverdquo inProceedings of the Australian Software Engineering Conference(ASWEC rsquo06) pp 199ndash208 Sydney Australia April 2006

[9] K Khan J Han and Y Zheng ldquoA framework for an activeinterface to characterise compositional security contracts ofsoftware components rdquo in Proceedings of the Australian SoftwareEngineering Conference (ASWEC rsquo01) pp 117ndash126 2001

[10] ldquoCommon criteria projectISO Common criteria for informa-tion technology security evaluationrdquo version 21 (ISOIEC Inter-national Standard 15408) NIST USA and ISO Switzerland1999 httpcsrcnistgovcc

[11] O H Alhazmi and Y K Malaiya ldquoQuantitative vulnerabilityassessment of systems softwarerdquo in Proceedings of the AnnualReliability andMaintainability Symposium (RAMS rsquo05) pp 615ndash620 January 2005

[12] Y-K Zhang S-Y Jiang Y-A Cui B W Zhang and H Xia ldquoAqualitative and quantitative risk assessment method in softwaresecurityrdquo in Proceedings of the 3rd International Conference onAdvanced Computer Theory and Engineering (ICACTE rsquo10) ppV1534ndashV1539 Chengdu China August 2010

[13] X Tang and B Shen ldquoExtending model driven architecturewith software security assessmentrdquo in Proceedings of the 3rdIEEE International Conference on Secure Software IntegrationReliability Improvement (SSIRI rsquo09) pp 436ndash441 ShanghaiChina July 2009

[14] X Wang H Shi T Y W Huang and F C Lin ldquoIntegratedsoftware vulnerability and security functionality assessmentrdquoin Proceedings of the 18th IEEE International Symposium onSoftware Reliability Engineering (ISSRE rsquo07) pp 103ndash108 Troll-hattan Sweden November 2007

[15] K Goseva-Popstojanova and K S Trivedi ldquoArchitecture-basedapproach to reliability assessment of software systemsrdquo Perfor-mance Evaluation vol 45 no 2-3 pp 179ndash204 2001

[16] ldquoNVD Common Vulnerability Scoring System (CVSS)rdquohttpnvdnistgovcvsscfm

[17] Y Jiang G M Xin J-H Shan L Zhang B Xie and F-Q YangldquoMethod of automated test data generation for web servicerdquoChinese Journal of Computers vol 28 no 4 pp 568ndash577 2005

[18] M E Delamaro J C Maldonado and A P Mathur ldquoInterfacemutation an approach for integration testingrdquo IEEE Transac-tions on Software Engineering vol 27 no 3 pp 228ndash247 2001

[19] J M Voas and K W Miller ldquoPredicting softwarersquos minimum-time-to-hazard andmean-time-to-hazard for rare input eventsrdquoin Proceedings of the 6th International Symposium on SoftwareReliability Engineering pp 229ndash238 October 1995

[20] J Chen Y Lu andX Xie ldquoA fault injectionmodel of componentsecurity testingrdquo Computer Research and Development vol 46no 7 pp 1127ndash1135 2009

[21] J Chen Y LuW Zhang andXD Xie ldquoA fault injectionmodel-oriented testing strategy for component securityrdquo Journal ofCentral South University of Technology vol 16 no 2 pp 258ndash264 2009

[22] J Chen Y Lu X Xie et al ldquoDesign and implementation of anautomatic testing platform for component securityrdquo ComputerScience vol 35 no 12 pp 229ndash233 2008

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

2 Mathematical Problems in Engineering

it is usually very difficult to obtain the internal informationfor COTS (commercial-off-the-shelf) components becauseits source codes are unavailable In order to obtain moreinformation about COTS component it is necessary thatsome data are inputted the tested component to drive thecomponent runningWhen the tested component is runningsome internal information including some security informa-tion can be collected by monitoring the running state ofthe tested component The data-driven method can obtaininternal security information for COTS component In thecurrent research we propose a feasible approach to assessthe component security level quantitatively through usingdata-drivenmethod and learning from relevant statistical andprobabilistic methods The exceptional component informa-tion monitored by the dynamic monitoring system can beobtained by the testing system of component vulnerability[3] Relevant security factors are assigned to appropriatesecurity exceptions according to the classification of thevulnerability in the Common Vulnerabilities and Exposures(CVE) vulnerability library Each of the exceptional vulner-ability factor values can be obtained from the triggeringcauses of software security vulnerabilities which is a harmfuldegree combined with the characteristics of the componentsecurity vulnerabilities Finally six commercial componentsin which security vulnerabilities exist are collected forexperimental analysis in the CVE Web site and are assessedby the proposed approach The number of each interfaceand methods used for each interface can be obtained bydynamically executing the tested components The executedprobabilities of each interface and methods used for eachinterface can be determined by statistical method At thesame time fault injection operators and the logical predictionrules of exceptional database (PRED) are proposed accordingto the component security exceptions commonly used Thisapproach not only can assess the component security level butalso effectively assess the security level of each interface thusproviding better assessment capabilities

2 Related Work

At present commercial-off-the-shelf (COTS) componentssuch as military mechanization financial components andso on are used by more and more commercial softwareincluding some crucial security software COTS securitytakes an important part in component systems because thesecurity of the whole software system is determined by itTherefore assessing the security level of the component isused to test the security of the entire software system whichhas become an essential part in component testing To thebest of our knowledge research on assessing the softwarecomponent security mainly focuses on component secu-rity requirements and assessment approaches vulnerabilityassessment and quantitative risk assessment

Han and Zheng [4] and Jabeen and Jaffar-Ur Rehman[5] studied the security requirements and security assessmentmethods of components but did not give the specific relevantassessment methods Md Khan et al examined the securitytesting description and component assessment [6ndash8] Models

of the user data security component security framework andsecurity assessment model of software were proposed Khanand Han developed an assessment scheme for the securityproperties of software components The assessment schemeprovided a numeric score that indicates the relative strengthof the security properties of the component [8] However theapproach consists of two prerequisites (1) a security require-ment specification of the candidate component and (2) acomponent-specific security rating The approach requiresthe source codes of candidate component to be availableThesecurity property descriptions of the components based onthe security assessment standards of information technologywere proposed by Khan et al [9] The main attributes ofresource allocation user data protection and communica-tions were included The model was based on the activeinterface which could provide the basis for reasoning andassessing a componentrsquos security to meet certain securityrequirements of a particular application Common criteria(CC) provide a schema for evaluating information systemand enumerate the specific security requirements for suchsystems [10]The functional requirements in CC describe thesecurity behavior or functions expected of an informationsystem to counter threats but not all the requirements in CCmay be applicable directly to software components becauseof the distributed nature of software components and theircompositional complexity

Alhazmi and Malaiya proposed a time-based model forthe total vulnerabilities and an alternative model which isanalogous to the software reliability growth models [11]However this model cannot quantitatively assess the securitylevel of software Zhang et al presented a vulnerabilityrisk assessment method based on the attack tree modeland Bayesian network model [12] The analysis method canassess the risk probability of the software system but not itssecurity level The security risk assessment was introducedto the classical MDA (Model-Driven Architecture) frame-work [13] The extension offers early assessment and earlyvalidation of security requirements However the improvedframework still has not provided the quantitative mechanismof the software security A systematic methodology wasproposed for some software vulnerability assessment andsecurity function verification [14] A scalable and adaptableautomatic test system was implemented to test hundreds ofsoftware releases but the security assessment of softwarereleases was not implemented The state of the architecture-based approach to reliability assessment of component-basedsoftware was presented [15] The common requirementsof the architecture-based models were identified and theclassification was proposed However the approach only gavea framework for the reliability assessment of component-based software

Idongesit proposed a quantitative risk assessment modelbased on annualized loss expectancy and the exposure factorwhich is the percentage of asset loss due to the potentialthreat [3] The model can assess the potential threats toa development effort and rank these threats based on therisk metric calculation The Common Vulnerability ScoringSystem (CVSS) [16] provides an open framework for commu-nicating the characteristics and effects of IT vulnerabilities Its

Mathematical Problems in Engineering 3

quantitative model ensures repeatable accurate measurementwhile enabling users to see the underlying vulnerabilitycharacteristics used to generate the scores However CVSSmeasures software vulnerability based on the external factorsof software system Occasionally the result cannot preciselyrepresent the software vulnerability

In summary we propose a new quantitative assess-ment of component security (QACS) approach to representmore accurately the security level of the COTS componentbased on the internal factors of software component Theinternal factors of software component are some importantinformation inside the component instead of the outsideenviornment There are some main internal factors such asthe component objects component interfaces componentmethods and component attributes These internal factorsreflect more accurate security features for the tested compo-nent

3 A Quantitative Assessment Framework forComponent Security

With the further development of component-based softwareengineering COTS components have become frequentlyused in software systems The source codes of the COTScomponent are unavailable and highly independent Thetraditional testing approach of interface mutation is suitablefor system integration testingThat is mutation operators areonly effective at the interface between the module and thesubsystem Therefore the traditional method is unsuitablefor testing the COTS component system Interface mutationtesting which is suitable for the COTS component caninject faults at the component interface level by extending themutation operators in the program mutation and increasingthe mutation operators at the component interface level Thedefects of components can be identified through observationand analysis of the testing result of the system Figure 1 showsthe quantitative assessment framework of the componentsecurity level

The interface fault injection operators of the COTS com-ponent include irregular input parameter operatorsmutationoperators based on program language mutation operatorsbased on interface specifications [17] andmutation operatorsbased on interface definition language (IDL) [18] The faultinjection operators which are commonly used are as followsboundary value parameter parameter beyond the lengthparameter attribute replaced parameter swap parameterchange parameter assignment parameter set null and so on

The test cases of fault injection can be generated throughthe selection of a suitable fault injection operator basedon parameter types and number of component methods inthe interface information The test scripts can be generatedaccording to the test cases The component can be runwith the test scripts The running state can be monitoredthrough the dynamic monitoring mechanism Componentvulnerability of the interface methods can be determinedby the running state of the component security predictionmechanism prediction rules and vulnerability factor invariousmethodsThe vulnerable score can be obtained under

Test cases implemented

System state

Rules library

Security level assessment

Fault injectionoperator

Componentinterface

information

Vulnerability factor value Probabilitymatrix

Security anomaly assessment

Component 119862

Figure 1 A quantitative assessment framework

certain running environments in terms of the vulnerabilityassessment method of component C The vulnerability scorewhich can assess the security of component C is called thesecurity level of component

31 Fault Injection Operator of the Component Vulnerability

Definition 1 Fault injection operator prod is the rule thatgenerates a number of fault injection test cases namelyprod rarr

Ψ1 Ψ2 Ψ

119899 Ψ119894denotes a fault injection test case A class

of fault injection test cases can be implemented by one faultinjection operator

Definition 2 Interface fault injection operation 119874 is a binaryrelation 119874(prod 119875) where 119875 is a class of interface parameters119874(prod 119875) = (Ψ

119894 119901119894) isin Ψ

1 Ψ2 Ψ

119899times119875 Fault injection test

case which is implemented by fault injection operatorprod actson the interface parameter 119901

119894 where119874(prod 119875) can be short for

119874 only if it does not cause confusion

Whether the generated test cases of fault injection arerepresentative is the key to designing the fault injection oper-ator that is whether the generated test cases of fault injectioncan trigger the componentrsquos security vulnerability as greatlyas possible Two errors namely environmental errors andinterface parameter errors can trigger component securityvulnerabilities in a component system The first error whichis discussed in the previous paper [1] does not repeat it againThe focus of the current paper is the interface parameterfault injection The errors in the interface parameter includethree types IDL description errors boundary value errorsand irregular input errors In detail they are the methoderrors defined by the IDL description all boundary valueand irregular input value errors respectively Based on thecause of triggering software security vulnerabilities in prac-tical experience 18 fault injection operators of componentvulnerability are specifically designed by comprehensivelyanalyzing the interface mutation operators and the opera-tors of parameter fault injection These operators are PAS

4 Mathematical Problems in Engineering

Table 1 Exceptional predication rules and vulnerability factors

ID Predication rules Description VC01 General exception The general exception code is detected or throw an exception 05

02 Access out of range Running a thread attempts to read or write the memory address buthas no corresponding access authority 1

03 Matrix visited beyond scope A thread tries to access an array element beyond scope 1

04 Access the memory page not exiting The file system returns a read error resulting in page fault whichcan-not meet the requirements 08

05 Visit the protected page A thread tries to access memory page that has the attribute ofPAGE GUARD 1

06 Stack of thread is overflow A thread runs out of all stack space assigned to it 1

07 Execute illegal instruction A thread running an instruction that is not allowed in the currentthread or executing an invalid instruction 1

08 Divisor is 0 A thread tries to divide an integer or a float by 0 08

09 Operation out of range An operation result exceeds the specified range values 08

10 Floating-point stack overflow Stack overflow or underflow because of floating-point operations 1

11 Buffer overflow Written contents beyond the buffer length resulting in written datacovering the original return address and destroying the program stack 1

12 Memory leakageMonitoring the input and output values of malloc() free() realloc()functions and making a statistical analysis to achieve a memoryleakage check

1

13 Format string exceptions Format or parameter mismatch when using printf() function such asldquonnsdrdquo 1

(Parameter Attribute Swap) PSN (Parameter Set Null) IPO(Insert Parameter Operator) PFB (Parameter Flip Bit) PRI(Parameter Reverse-probability Input) IIV (integer IrregularValue) FIV (Float Irregular Value) CIV (Char IrregularValue) BIV (Boolean Irregular Value) RSV (Random StringValue) LSV (Long String Value) FSV (Format String Value)DSV (Directory String Value) USV (URL and string valueof file directory) CSV (System Command String Value) SSV(SQL string injection) and CSS (Cascading Style Sheet) Thenew security vulnerabilities found in components can also beadded

In addition the reverse distribution function of theparameter input domain is generated using the input operatorPRI of the parameters of reverse probability distributionThe parameters of reverse probability distribution are thengenerated The experimental result shows that componentsecurity exception can be effectively triggered through theirregular value of input domain The input distributionfunction which is usually difficult to obtain is a probabilitydensity functionThe one dimensional andmultidimensionalfunctions are the two commonly used kinds Q is assumedthe input distribution function of which the value is in theinterval [0 1] and the value 0 indicates the probability ofselection input field is 0 The algorithm of reverse probabilitydistribution 1198761015840 is given in the literature [19]

A number of models have been designed to facilitatethe automatic management of the fault injection operatorsuch as the automatic learning model of the fault injectionoperator adaptive model topic model intelligent vulnerabletrees among others They can automatically increase andmanage the operator libraries of fault injection

32 Exceptional Predication Rules and Vulnerability Factors

Definition 3 The component exceptional predication rule isa set of all the possible exceptions that may arise under theexceptional circumstances

Definition 4 The vulnerability factor of the component rep-resents the degree of the component security vulnerabilitiesresulting from exceptions The maximum value is 1 and theminimum value is 0 Table 1 shows the component excep-tional predication rules and relative vulnerability factorsused to assess the component security level Each of thefactor value of exceptional security vulnerability which canobjectively describe the component security level is obtainedfrom the triggering causes of software security vulnerabilitieswhich is a harmful degree combined with the characteristicsof component security vulnerabilities based on experiencesoftware engineering

4 Component Security Assessment Algorithm

Suppose 119862 is a component and 119868 is a set of interface in119862 Let 119901

119894represent the execution probability of interface 119894

and119872119894is a method properties set of interface 119894 Meanwhile

119901119894119898

is the executable probability in method 119898 of interface 119894Suppose |119868| = 119873 |119872

119894| = 119878 119909 is the input parameter of the

method attribute in 119862 119879 is vulnerable error test cases set and119879 = 119905

1 1199052 1199053 119905

119899 Δ is all the input set of component

119862 1198761015840 is the reverse probability distribution of Δ PRED isthe logical prediction rules of exceptional database VC isthe vulnerability factor of exceptional function Before the

Mathematical Problems in Engineering 5

vulnerability assessment method of component is given thefollowing definitions should be introduced first

Definition 5 Let 119875 represent an 119873 times 119878 probability matrixthat can be described as 119875 = (119901

119894119895)119899times119904

row 119894 represents theinterface number of component 119862 and column 119895 representsthe method number of interface 119894 The element 119901

119894119895states

the executable probability for function 119895 at interface 119894 ofcomponent 119862 where 119901

119894119895= 119901119894times 119901119895

Definition 6 Interface method coverage (MC) where MC =

(the number of methods executed at least oncethe totalnumber methods 119878) times 100 is used to measure the sufficientdegree of the interface method during component testing

Definition 7 Interface coverage (IC) where IC = (the numberof interfaces executed at least oncethe total number interface119873) times 100 is used to measure the sufficient degree of theinterface test during component testing

Definition 8 Component test adequacy CA can be measuredby a two-tuple (ie MC and IC) Generally the value isdetermined by the total score of MC and IC that is CA =

[sum119894=1119873

(MC119894)]119873+IC A greater value of CA indicates amore

comprehensive test the relationship between MC and IC isparallel

Suppose Sum 119872 represents the number of test meth-ods cnt represents the number of vulnerability methods incomponent 119862 and VC

119894represents the vulnerability factors of

exceptional method The value of vulnerability factor VC119894is

assigned to 0 in case the interface method has no securityexceptions The execution probability of the vulnerabilitymethod 119894 is labeled 119875

119894 The component vulnerability assess-

ment formula is given as follows

Vul119888= 1 minus

cntprod119894=1

(1 minus 119875119894times VC119894) (1)

The value 1 minus Vul119888 the security level of the component

119862 can be derived from the Formula (1) The vulnerabilityassessment formula of the component has the followingproperties

Property 9 (0 le Vul119888le 1)

Proof For any vulnerability method 1 ge 119875119894ge 0 and 1 ge

VC119894ge 0 can be determined according to the definition of

VCTherefore 1 ge 119875119894timesVC119894ge 0 1 ge 1minus119875

119894timesVC119894ge 0 and 0 le

prodcnt119894=1(1 minus 119875

119894times VC119894) le 1 are derived that is 0 le Vul

119888le 1

Property 9 shows that the value of any componentrsquosvulnerability index is between 0 and 1 with a larger valueindicating a higher vulnerability index

Property 10 (Vul119888ge max(119875

119894times VC119894) ge 0)

Proof For any vulnerability method 1 ge 119875119894ge 0 and 1 ge

VC119894ge 0 can be determined according to the definition of VC

Therefore max(119875119894timesVC119894) ge 0 In addition 1 ge 1minus119875

119894timesVC119894ge 0

and 1minusVul119888= prod

cnt119894=1(1minus119875119894timesVC119894) can be derived fromFormula

(1)prodcnt119894=1(1 minus 119875

119894timesVC119894) = (1 minus 119875

1timesVC1) times (1 minus 119875

2timesVC2) times sdot sdot sdot

times (1 minus max(119875119894times VC119894)) times sdot sdot sdot times (1 minus 119875cnt times VCcnt) therefore

prodcnt119894=1(1 minus 119875

119894times VC119894) le (1 minus max(119875

119894times VC119894)) and 1 minus Vul

119888le

(1minusmax(119875119894timesVC119894)) are derived that is Vul

119888ge max(119875

119894timesVC119894)

Thus Vul119888ge max(119875

119894times VC119894) ge 0 can proved correct

Property 10 shows that the vulnerability index of any onecomponent is not less than the peak value of the methodsrsquovulnerability indexes of the component All situations ofthe vulnerability methods of component are syntheticallyconsidered by the index of the vulnerability of component

Based on the component vulnerable assessment methodbased on the analysis of the interface the algorithm of thecomponentrsquos security assessment level is given as follows

The input probability matrix 119875 in Algorithm 1 is not onlyderived from the component requirement specifications orequal probability but is also statistically calculated after thecomponent is practically executed The vulnerability factorVC119894119895is assigned to 0 given that the component has no security

exceptional interface method We usually set the value of120575 and 120579 from 0 to 1 according to the complexity of testedcomponent and the testing requirement If the number ofinterfaces and methods of tested component is no more than200 we usually let the value of 120575 and 120579 to be 1 to ensurea complete testing of COTS In addition the test cases ofinterface parameters are generated using the TGSM [20 21]algorithm First the test cases of the interface parameter fault-injection expressed in matrix form are generated in termsof fault injection operator The K-factor coverage solutionmatrix is generated by the TGSM algorithm which is basedon the parameter set of the matrix form The fault injectiontest cases are composed of row data of the solution matrixTest cases generated by the TGSM algorithm not only greatlyreduce the scale of the test cases but also have certaincoverage The algorithm can trigger most of the securityexceptions with fewer test cases

Cnt is the number of vulnerability methods of the com-ponent 119862 in the algorithm results Vul

119894119895is the vulnerability

ratio of the method 119895 at the interface 119894 of the component 119862Vul119888represents the vulnerability level of the component 119862

1 minus Vul119894119895 the security level of the component 119862 represents

the security of the method 119895 in the interface 119894 of component119862

5 Experiment Analysis

To validate the effectiveness of the proposed approachthe approach was implemented in our component securitytesting system (CSTS) platform [22]The component securitytesting and assessing system based on interface fault injection(CSTASboIFT) was implemented using C language in theMicrosoft NET platform It is used as a subsystem of theCSTS platform Figure 2 shows the function flow chart ofCSTASboIFT

In the experiment six commercial components (Table 2)in which security vulnerabilities exist were collected forexperimental analysis in the CVE Web site Several group

6 Mathematical Problems in Engineering

Input Interface information XML file Fault injection operator Prediction rules PREDProbability matrix 119875 MCrsquos threshold and ICrsquos threshold value 120575 and 120579Output The security level of the whole component01 02 Read XML file03 MC = 0 IC = 0 119894 = 0 cnt = 0 cnt is the number of component vulnerability methods04 While IC lt 120575 do For each interface 119894 in 11986805

06 119894 = 119894 + 1 119895 = 007 While MC lt 120579 do For each method119898 in119872

119894

08

09 119895 = 119895 + 1 119895 is the number of the testing methods10 Generate method parameter values set according to fault injection operators11 Call testing cases generating algorithm TGSM() call the generation algorithm of the

minimum 119870 factors combined cover test case based on solution matrix12 Running 119862 and119872

119894119895

13 If (the output after running 119862 and119872119894119895satisfies PRED)

14

15 increment cnt16 Vul

119894119895= VC

119894119895times 119875119894119895 the vulnerability level of the method 119895 in the interface 119894

17

18 MC = 11989511987819

20 IC = 11989411987321

22 Vul119888= 1 minus prod

cnt119894=1(1 minus 119875

119894times VC

119894)

23 (Output) 1 minus Vul119888

24

Algorithm 1 QACS (quantitative assessment of component security) algorithm

Tested component

Interface analysis

Component interface

Implement test cases

Fault injectionoperator

Compile driven execution

Dynamic monitor

Probabilitymatrix

Vulnerability factor value Probabilitymatrix

Security levelassessment report

information (XML file)

Monitor loginformation

Assessmentrule library119875

Figure 2 The function flow chart of CSTASboIFT

experiments were conducted for these components A com-ponent composed of six interfaces and each interface consist-ing of eight methods were assumed so that the componentcould be regarded as a 6 times 8 matrix The first group of

experiments tested the condition of 119875119894119895assigned to a fixed

matrix and VC119894119895divided into interval descending As VC

119894119895

changed the 1 minus Vul119888was affected That is only the level of

vulnerability factors affected the component security levelThe second group of experiments tested the condition ofVC119894119895assigned to a fixed matrix and 119875

119894119895divided into interval

descending As 119875119894119895changed 1 minus Vul

119888was affected That is

only the executed probability affected the component securitylevel The last group of experiments considered the effect on1minusVul

119888 as both vulnerability factor and executed probability

simultaneously changed

51 Experiment One Thevulnerability factor value is dividedinto intervals based on the knowledge of security vulner-ability provided by the CVE Web site 119875

119894119895represents the

executable probability of the method 119895 at the interface 119894VC119894119895represents the vulnerability factors of the method 119895 at

the interface 119894 and Vul119888represents the vulnerability level of

component 119862 1 minus Vul119888is the security level of component 119862

The first experiment assumes that 119875119894119895is a 6 times 8 fixed

matrix which is made up of random values For everyinterval 119875

119894119895is the same matrix VC

119894119895is divided into 10

intervals [000 009] [010 019] [020 029] [030 039][040 049] [050 059] [060 069] [070 079] [080 089]and [090 100] The tests were done about ten times withdifferent random values of 119875

119894119895and VC

119894119895 respectively in the

experiment and then the value 1minusVul119888was got by calculating

Mathematical Problems in Engineering 7

Table 2 The six typical tested components

Component ID Component name Component information01 ThunderAgent 005dll An ActiveX control in Thunder 5 Component version is 10011 Thunder version is 55225202 AcroPDFdll An AcroPDF ActiveX control in Adobe Reader and Acrobat Component version is 708003 GLItemComdll An ActiveX control in OURGAMEWORLD game software Component version is 270804 pdg2dll An ActiveX control in SUPERSTART READER software Component version is 390005 GomWeb3dll An ActiveX control in GOM Player GOM Player is a media player widely used in Korea06 Vulndll A third-party tested component Component version is 1012

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

VC119894

1minusVu

L 119888

(a) cnt = 5

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(b) cnt = 10

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(c) cnt = 15

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(d) cnt = 20

Figure 3 The comparison for different VC119894and cnt

the average result Under the condition that 119875119894119895is regarded as

a 6 times 8matrix at every interval of VC119894119895 VC119894119895affects the value

1 minus Vul119888

When Vul119894119895is equal to 119875

119894119895times VC119894119895 as 119875119894119895is a fixed value

the values of Vul119888and Vul

119894119895are proportional to the value of

VC119894119895 The value of 1 minus Vul

119888is reversely proportional to VC

119894119895

A larger VC119894119895value indicates a lower security level As the

vulnerability number increases the security level decreasesslowly The results are shown in Figure 3 The testing resultsshow that the proposed assessment Formula (1) is effective

52 Experiment Two VC119894119895is assumed a 6 times 8 fixed matrix

made up of random values in the second experiment Then119875119894119895

is divided into 10 intervals [000 009] [010 019][020 029] [030 039] [040 049] [050 059] [060 069][070 079] [080 089] and [090 100] The tests were doneabout ten times with different random values of 119875

119894119895and VC

119894119895

respectively in the experiment and then the value 1minusVul119888was

got by calculating the average result Under the condition thatVC119894119895is regarded as a 6 times 8 matrix at every interval of 119875

119894119895 119875119894119895

affects the value of 1 minus Vul119888

When VuL119894119895is equal to 119875

119894119895times VC119894119895 as the value of VC

119894119895

is fixed the values of Vul119888and VuL

119894119895are proportional to the

value of 119875119894119895 The value of 1 minus Vul

119888is reversely proportional

to VC119894119895 A larger 119875

119894119895value indicates a lower security level

That is the component is more insecure As the number ofcnt increases the decline rate of the security level is initiallyfast and then becomes slow The results as presented inFigure 4 show that the proposed assessment Formula (1) iseffective

53 Experiment Three Both parameters 119875119894and VC

119894are

assumed to influence the value of 1 minus Vul119888in Experiment

three The two parameters are randomly divided into 10

8 Mathematical Problems in Engineering

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(a) cnt = 5

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(b) cnt = 10

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(c) cnt = 15

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(d) cnt = 20

Figure 4 The comparison for different 119875119894and cnt

intervals The effect on the value of 1 minus VuL119888when the

two parameters changed simultaneously was observed Theresults show that when 119875

119894is proportional to VC

119894 the value

of 1 minus Vul119888changes significantly as shown in (a) and (b)

of Figure 5 When 119875119894is inversely proportional to VC

119894 the

value of 1 minus Vul119888changes indistinctly as shown in (c) and

(d) of Figure 5 As the vulnerability number cnt increasesthe security level decreases Results are shown in Figure 5The values of 119875

119894and VC

119894are based on the main 119910-axis values

(the left axis) and the value of the 1 minus Vul119888is based on the

secondary 119910-axis values (the right axis) The testing resultsshow that the proposed assessment Formula (1) is suitable forassessing the COTS component

54 Experiment Four The components were assessed inTable 3 based on Algorithm 1 The value of IC and MC is setto 1 119875

119894can be determined by executing the tested component

100 times or moreDuring the system testing process the test cases of fault

injection can be implemented by testing the componentinformation and fault injection operators The testing statecan be recorded through the dynamic monitoring mecha-nism after running the tested component The vulnerabilitytype of the componentmethod and vulnerability factor can bederived from comparing the testing state with the componentinformation record in PRED The execution probability 119875

119894

of each method in the component can be determined byrunning the tested component 100 times respectively Thenthe component security level can be determined using For-mula (1)The testing results are shown in Table 3 Because dif-ferent components have different method parameters whichhave different parameter types such as integer string andboolean we select suitable fault injection factors to test thecomponent security based on the above presented 18 faultinjection operators of component in Table 3

A higher level of security indicates better relative securityof the component The component is secure if and only ifthe component security level is 1 Otherwise it has securityvulnerability In contrast to the test results in Table 3 the levelof security is closer to the vulnerability information publishedin the CVE Web site The values of execution probabilityand vulnerability factors have been proved to affect thecomponent security The results agree with the previousexperimental results further confirming the feasibility andeffectiveness of this approach

55 Experimental Comparison Table 4 shows the compar-ison with other assessment approaches The related assess-ment approaches have various merits as shown in theanalysis of Table 4 Our QACS approach mainly focuseson quantitatively assessing the security level of the COTScomponent The source codes of the COTS component are

Mathematical Problems in Engineering 9

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(a) cnt = 5

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(b) cnt = 10

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(c) cnt = 15

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(d) cnt = 20

Figure 5 The comparison for different 119875119894 VC119894 and cnt

generally unknownThe internal factors of the component areconsidered in QACSThe QACS approach is implemented inthe CSTASboIFT that is integrated into our CSTS [22] systemdeveloped to test the security of the COTS component

Aside from the above-mentioned approaches CVSS is awidely used quantitative assessment approach for softwarecomponent Khan and Han developed an assessment schemefor the security properties of software components Theassessment scheme provided a numeric score that indicatesthe relative strength of the security properties of the compo-nent [8] Results of the comparison with the CVSS approachand Khaled approach are shown in Table 5 In addition thesecurity level of six tested components is also listed accordingto the reported empirical data of securityWeb sites in Table 5The initial CVSSBase Score is calculated by theCVSS formula[16]

Analyzing Table 5 the QACS approach is found to beclose to the empirical data reported on some security Websites regarding the security of the tested COTS componentsThe security score of the QACS approach is more accuratethan that of others because the internal factors of the tested

component are considered The assessment process of theQACS approach is objective without human interventionNevertheless the CVSS approach ismainly focused on assess-ing the vulnerability of the general software componentIf an assessor is not familiar with the assessed softwarethe vulnerability score becomes inaccurate because of theassessorrsquos subjectivity in the assessment process On the otherhand the Khaled approach is an approximate assessmentapproach based on the assumed component environment Inaddition presently there are no more effective assessmentapproaches for the security level of software componentaccording to our studies

6 Conclusion

In component-based software development andmaintenanceactivities the assessment of the component reliability andsecurity level is essential in the third-party componentResearch on an effective quantitative assessment methodfor component security level is valuable in the CBSE The

10 Mathematical Problems in Engineering

Table 3 Testing results for six tested components

ID Fault injectionfactor

The number ofvulnerabilities and its 119875

119894

Test result Security level

01 IIV 2(013 013)

ThunderAgent 005dll has two methods calling(GetInfoStruct() GetTaskInfoStruc()) neglected the inputparameter exception and generated security vulnerability Thenthey resulted in program breakdown

07569

02 CIV LSV RSV 5(01 02 01 015 02)

AcroPDFdll did not correctly deal with the string parameterssent to function setPageMode() LoadFile() setLayoutMode()and setNamedDest() and the attribute src It triggered memorydestroyed and resulted in security vulnerability for executingany instruction

04406

03 LSV RSV FSV 1(064)

The function SetInfo() of GLItemComDLL ActiveX overtrusted user input and did not check parameterrsquos length Itresulted in the point the virtual function covered

036

04 LSV RSV FSV 1(01)

Pdg2dll did not deal with the sent parameter to Register () ifuser sends the string over 256 bytes it can trigger stack overflowand execute any code

09

05 LSV RSV USV 1(015)

GomManager object did not collectively deal with the firstparameter of OpenURL() in IGomManager interface Iftransmitting the long parameters over 500 bytes it can triggerstack overflow to result in visiting the memory exception

085

06 PSN CIV PIVLSV USV

5(015 015 015 015 015)

5 methods of component existed security exception The testcase parameters implemented by input fault injection operatorwould result in buffer overflow visiting beyond the scope andmemory leakage

04437

Table 4 The comparison with related assessment approaches

Assessment approach Assessment object Assessment aspect Is the internalfactor considered

Qualitative orquantitative

Is there supportingtool

Khan and Han [8] Software component Security No Quantitative NoAlhazmi and Malaiya[11] Operating system Vulnerability Yes Quantitative No

Zhang et al [12] Software system Risk No Quantitativequalitative

No

Goseva-Popstojanovaand Trivedi [15] Software system Reliability No Quantitative No

Mkpong-Ruffin [3] Software Risk No Quantitative Yes

CVSS [16] Software component Vulnerability No Quantitative Yes

QACS COTS component Security Yes Quantitative Yes

Table 5 The comparison with CVSS and Khaled approaches

ComponentID

InitialCVSS base

score

Convertedsecurity score

of CVSS

Securitylevel ofQACS

The reportedempirical data(security level)

01 58 042 07569 B+

02 19 081 04406 Cminus

03 6 04 036 D+

04 7 03 09 A

05 36 064 085 Aminus

06 19 081 04437 Cminus

current paper proposes theQACS approach for quantitativelyassessing component security which is based on the interfacefault injection of the componentThe fault injection operatorsof the component vulnerability and PRED are defined anddiscussedThe assessment framework and algorithm for com-ponent security are proposed as wellThe testing effect provesexcellent in practical application QACS has the followingmain advantages (1) the security exceptional assessmentrules and vulnerability factors of the component are givenproviding the basis for security assessment (2) QACS canassess the security level of the third-party component andthe score of component security can be accurately calculated(3) QACS has better operability

Mathematical Problems in Engineering 11

Acknowledgments

We would like to thank Professor T Y Chen for his con-structive suggestions and valuable discussion in this paperwriting In addition this work was supported partly bythe National Natural Science Foundation of China (NSFC)under Grants no 61202110 and no 61063013 Natural ScienceFoundation of Jiangsu Province under Grant no BK2012284and the Research Fund for the Doctoral Program of HigherEducation of China under Grant no 20103227120005

References

[1] J Chen Y Lu and X D Xie ldquoComponent security testingapproach by using interface fault injectionrdquo Journal of ChineseComputer Systems vol 31 no 6 pp 1090ndash1096 2010

[2] S Gudder andRGreechie ldquoUniqueness and order in sequentialeffect algebrasrdquo International Journal of Theoretical Physics vol44 no 7 pp 755ndash770 2005

[3] I O Mkpong-Ruffin Quantitative risk assessment model forsoftware security in the design phase of software development[PhD thesis] Auburn University Auburn Ala USA 2009

[4] J Han and Y Zheng ldquoSecurity characterization and integrityassurance for component-based softwarerdquo in Proceedings of theInternational Conference on Software Methods and Tools (SMTrsquo00) pp 61ndash66 IEEE Computer SocietyWollongong Australia2000

[5] F Jabeen and M Jaffar-Ur Rehman ldquoA framework for objectoriented component testingrdquo in Proceedings of the IEEE Inter-national Conference on Emerging Technologies (ICET rsquo05) pp451ndash460 Islamabad Pakistan September 2005

[6] K Md Khan J Han and Y Zheng ldquoCharacterizing userdata protection of software componentsrdquo in Proceedings of theSoftware EngineeringConference pp 3ndash11 CanberraAustralian2000

[7] K M Khan and J Han ldquoA security characterisation frame-work for trustworthy component based software systemsrdquo inProceedings of the 27th Annual International Computer Softwareand Applications Conference (COMPSAC rsquo03) pp 164ndash169November 2003

[8] K M Khan and J Han ldquoAssessing security properties ofsoftware components a software engineerrsquos perspectiverdquo inProceedings of the Australian Software Engineering Conference(ASWEC rsquo06) pp 199ndash208 Sydney Australia April 2006

[9] K Khan J Han and Y Zheng ldquoA framework for an activeinterface to characterise compositional security contracts ofsoftware components rdquo in Proceedings of the Australian SoftwareEngineering Conference (ASWEC rsquo01) pp 117ndash126 2001

[10] ldquoCommon criteria projectISO Common criteria for informa-tion technology security evaluationrdquo version 21 (ISOIEC Inter-national Standard 15408) NIST USA and ISO Switzerland1999 httpcsrcnistgovcc

[11] O H Alhazmi and Y K Malaiya ldquoQuantitative vulnerabilityassessment of systems softwarerdquo in Proceedings of the AnnualReliability andMaintainability Symposium (RAMS rsquo05) pp 615ndash620 January 2005

[12] Y-K Zhang S-Y Jiang Y-A Cui B W Zhang and H Xia ldquoAqualitative and quantitative risk assessment method in softwaresecurityrdquo in Proceedings of the 3rd International Conference onAdvanced Computer Theory and Engineering (ICACTE rsquo10) ppV1534ndashV1539 Chengdu China August 2010

[13] X Tang and B Shen ldquoExtending model driven architecturewith software security assessmentrdquo in Proceedings of the 3rdIEEE International Conference on Secure Software IntegrationReliability Improvement (SSIRI rsquo09) pp 436ndash441 ShanghaiChina July 2009

[14] X Wang H Shi T Y W Huang and F C Lin ldquoIntegratedsoftware vulnerability and security functionality assessmentrdquoin Proceedings of the 18th IEEE International Symposium onSoftware Reliability Engineering (ISSRE rsquo07) pp 103ndash108 Troll-hattan Sweden November 2007

[15] K Goseva-Popstojanova and K S Trivedi ldquoArchitecture-basedapproach to reliability assessment of software systemsrdquo Perfor-mance Evaluation vol 45 no 2-3 pp 179ndash204 2001

[16] ldquoNVD Common Vulnerability Scoring System (CVSS)rdquohttpnvdnistgovcvsscfm

[17] Y Jiang G M Xin J-H Shan L Zhang B Xie and F-Q YangldquoMethod of automated test data generation for web servicerdquoChinese Journal of Computers vol 28 no 4 pp 568ndash577 2005

[18] M E Delamaro J C Maldonado and A P Mathur ldquoInterfacemutation an approach for integration testingrdquo IEEE Transac-tions on Software Engineering vol 27 no 3 pp 228ndash247 2001

[19] J M Voas and K W Miller ldquoPredicting softwarersquos minimum-time-to-hazard andmean-time-to-hazard for rare input eventsrdquoin Proceedings of the 6th International Symposium on SoftwareReliability Engineering pp 229ndash238 October 1995

[20] J Chen Y Lu andX Xie ldquoA fault injectionmodel of componentsecurity testingrdquo Computer Research and Development vol 46no 7 pp 1127ndash1135 2009

[21] J Chen Y LuW Zhang andXD Xie ldquoA fault injectionmodel-oriented testing strategy for component securityrdquo Journal ofCentral South University of Technology vol 16 no 2 pp 258ndash264 2009

[22] J Chen Y Lu X Xie et al ldquoDesign and implementation of anautomatic testing platform for component securityrdquo ComputerScience vol 35 no 12 pp 229ndash233 2008

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Mathematical Problems in Engineering 3

quantitative model ensures repeatable accurate measurementwhile enabling users to see the underlying vulnerabilitycharacteristics used to generate the scores However CVSSmeasures software vulnerability based on the external factorsof software system Occasionally the result cannot preciselyrepresent the software vulnerability

In summary we propose a new quantitative assess-ment of component security (QACS) approach to representmore accurately the security level of the COTS componentbased on the internal factors of software component Theinternal factors of software component are some importantinformation inside the component instead of the outsideenviornment There are some main internal factors such asthe component objects component interfaces componentmethods and component attributes These internal factorsreflect more accurate security features for the tested compo-nent

3 A Quantitative Assessment Framework forComponent Security

With the further development of component-based softwareengineering COTS components have become frequentlyused in software systems The source codes of the COTScomponent are unavailable and highly independent Thetraditional testing approach of interface mutation is suitablefor system integration testingThat is mutation operators areonly effective at the interface between the module and thesubsystem Therefore the traditional method is unsuitablefor testing the COTS component system Interface mutationtesting which is suitable for the COTS component caninject faults at the component interface level by extending themutation operators in the program mutation and increasingthe mutation operators at the component interface level Thedefects of components can be identified through observationand analysis of the testing result of the system Figure 1 showsthe quantitative assessment framework of the componentsecurity level

The interface fault injection operators of the COTS com-ponent include irregular input parameter operatorsmutationoperators based on program language mutation operatorsbased on interface specifications [17] andmutation operatorsbased on interface definition language (IDL) [18] The faultinjection operators which are commonly used are as followsboundary value parameter parameter beyond the lengthparameter attribute replaced parameter swap parameterchange parameter assignment parameter set null and so on

The test cases of fault injection can be generated throughthe selection of a suitable fault injection operator basedon parameter types and number of component methods inthe interface information The test scripts can be generatedaccording to the test cases The component can be runwith the test scripts The running state can be monitoredthrough the dynamic monitoring mechanism Componentvulnerability of the interface methods can be determinedby the running state of the component security predictionmechanism prediction rules and vulnerability factor invariousmethodsThe vulnerable score can be obtained under

Test cases implemented

System state

Rules library

Security level assessment

Fault injectionoperator

Componentinterface

information

Vulnerability factor value Probabilitymatrix

Security anomaly assessment

Component 119862

Figure 1 A quantitative assessment framework

certain running environments in terms of the vulnerabilityassessment method of component C The vulnerability scorewhich can assess the security of component C is called thesecurity level of component

31 Fault Injection Operator of the Component Vulnerability

Definition 1 Fault injection operator prod is the rule thatgenerates a number of fault injection test cases namelyprod rarr

Ψ1 Ψ2 Ψ

119899 Ψ119894denotes a fault injection test case A class

of fault injection test cases can be implemented by one faultinjection operator

Definition 2 Interface fault injection operation 119874 is a binaryrelation 119874(prod 119875) where 119875 is a class of interface parameters119874(prod 119875) = (Ψ

119894 119901119894) isin Ψ

1 Ψ2 Ψ

119899times119875 Fault injection test

case which is implemented by fault injection operatorprod actson the interface parameter 119901

119894 where119874(prod 119875) can be short for

119874 only if it does not cause confusion

Whether the generated test cases of fault injection arerepresentative is the key to designing the fault injection oper-ator that is whether the generated test cases of fault injectioncan trigger the componentrsquos security vulnerability as greatlyas possible Two errors namely environmental errors andinterface parameter errors can trigger component securityvulnerabilities in a component system The first error whichis discussed in the previous paper [1] does not repeat it againThe focus of the current paper is the interface parameterfault injection The errors in the interface parameter includethree types IDL description errors boundary value errorsand irregular input errors In detail they are the methoderrors defined by the IDL description all boundary valueand irregular input value errors respectively Based on thecause of triggering software security vulnerabilities in prac-tical experience 18 fault injection operators of componentvulnerability are specifically designed by comprehensivelyanalyzing the interface mutation operators and the opera-tors of parameter fault injection These operators are PAS

4 Mathematical Problems in Engineering

Table 1 Exceptional predication rules and vulnerability factors

ID Predication rules Description VC01 General exception The general exception code is detected or throw an exception 05

02 Access out of range Running a thread attempts to read or write the memory address buthas no corresponding access authority 1

03 Matrix visited beyond scope A thread tries to access an array element beyond scope 1

04 Access the memory page not exiting The file system returns a read error resulting in page fault whichcan-not meet the requirements 08

05 Visit the protected page A thread tries to access memory page that has the attribute ofPAGE GUARD 1

06 Stack of thread is overflow A thread runs out of all stack space assigned to it 1

07 Execute illegal instruction A thread running an instruction that is not allowed in the currentthread or executing an invalid instruction 1

08 Divisor is 0 A thread tries to divide an integer or a float by 0 08

09 Operation out of range An operation result exceeds the specified range values 08

10 Floating-point stack overflow Stack overflow or underflow because of floating-point operations 1

11 Buffer overflow Written contents beyond the buffer length resulting in written datacovering the original return address and destroying the program stack 1

12 Memory leakageMonitoring the input and output values of malloc() free() realloc()functions and making a statistical analysis to achieve a memoryleakage check

1

13 Format string exceptions Format or parameter mismatch when using printf() function such asldquonnsdrdquo 1

(Parameter Attribute Swap) PSN (Parameter Set Null) IPO(Insert Parameter Operator) PFB (Parameter Flip Bit) PRI(Parameter Reverse-probability Input) IIV (integer IrregularValue) FIV (Float Irregular Value) CIV (Char IrregularValue) BIV (Boolean Irregular Value) RSV (Random StringValue) LSV (Long String Value) FSV (Format String Value)DSV (Directory String Value) USV (URL and string valueof file directory) CSV (System Command String Value) SSV(SQL string injection) and CSS (Cascading Style Sheet) Thenew security vulnerabilities found in components can also beadded

In addition the reverse distribution function of theparameter input domain is generated using the input operatorPRI of the parameters of reverse probability distributionThe parameters of reverse probability distribution are thengenerated The experimental result shows that componentsecurity exception can be effectively triggered through theirregular value of input domain The input distributionfunction which is usually difficult to obtain is a probabilitydensity functionThe one dimensional andmultidimensionalfunctions are the two commonly used kinds Q is assumedthe input distribution function of which the value is in theinterval [0 1] and the value 0 indicates the probability ofselection input field is 0 The algorithm of reverse probabilitydistribution 1198761015840 is given in the literature [19]

A number of models have been designed to facilitatethe automatic management of the fault injection operatorsuch as the automatic learning model of the fault injectionoperator adaptive model topic model intelligent vulnerabletrees among others They can automatically increase andmanage the operator libraries of fault injection

32 Exceptional Predication Rules and Vulnerability Factors

Definition 3 The component exceptional predication rule isa set of all the possible exceptions that may arise under theexceptional circumstances

Definition 4 The vulnerability factor of the component rep-resents the degree of the component security vulnerabilitiesresulting from exceptions The maximum value is 1 and theminimum value is 0 Table 1 shows the component excep-tional predication rules and relative vulnerability factorsused to assess the component security level Each of thefactor value of exceptional security vulnerability which canobjectively describe the component security level is obtainedfrom the triggering causes of software security vulnerabilitieswhich is a harmful degree combined with the characteristicsof component security vulnerabilities based on experiencesoftware engineering

4 Component Security Assessment Algorithm

Suppose 119862 is a component and 119868 is a set of interface in119862 Let 119901

119894represent the execution probability of interface 119894

and119872119894is a method properties set of interface 119894 Meanwhile

119901119894119898

is the executable probability in method 119898 of interface 119894Suppose |119868| = 119873 |119872

119894| = 119878 119909 is the input parameter of the

method attribute in 119862 119879 is vulnerable error test cases set and119879 = 119905

1 1199052 1199053 119905

119899 Δ is all the input set of component

119862 1198761015840 is the reverse probability distribution of Δ PRED isthe logical prediction rules of exceptional database VC isthe vulnerability factor of exceptional function Before the

Mathematical Problems in Engineering 5

vulnerability assessment method of component is given thefollowing definitions should be introduced first

Definition 5 Let 119875 represent an 119873 times 119878 probability matrixthat can be described as 119875 = (119901

119894119895)119899times119904

row 119894 represents theinterface number of component 119862 and column 119895 representsthe method number of interface 119894 The element 119901

119894119895states

the executable probability for function 119895 at interface 119894 ofcomponent 119862 where 119901

119894119895= 119901119894times 119901119895

Definition 6 Interface method coverage (MC) where MC =

(the number of methods executed at least oncethe totalnumber methods 119878) times 100 is used to measure the sufficientdegree of the interface method during component testing

Definition 7 Interface coverage (IC) where IC = (the numberof interfaces executed at least oncethe total number interface119873) times 100 is used to measure the sufficient degree of theinterface test during component testing

Definition 8 Component test adequacy CA can be measuredby a two-tuple (ie MC and IC) Generally the value isdetermined by the total score of MC and IC that is CA =

[sum119894=1119873

(MC119894)]119873+IC A greater value of CA indicates amore

comprehensive test the relationship between MC and IC isparallel

Suppose Sum 119872 represents the number of test meth-ods cnt represents the number of vulnerability methods incomponent 119862 and VC

119894represents the vulnerability factors of

exceptional method The value of vulnerability factor VC119894is

assigned to 0 in case the interface method has no securityexceptions The execution probability of the vulnerabilitymethod 119894 is labeled 119875

119894 The component vulnerability assess-

ment formula is given as follows

Vul119888= 1 minus

cntprod119894=1

(1 minus 119875119894times VC119894) (1)

The value 1 minus Vul119888 the security level of the component

119862 can be derived from the Formula (1) The vulnerabilityassessment formula of the component has the followingproperties

Property 9 (0 le Vul119888le 1)

Proof For any vulnerability method 1 ge 119875119894ge 0 and 1 ge

VC119894ge 0 can be determined according to the definition of

VCTherefore 1 ge 119875119894timesVC119894ge 0 1 ge 1minus119875

119894timesVC119894ge 0 and 0 le

prodcnt119894=1(1 minus 119875

119894times VC119894) le 1 are derived that is 0 le Vul

119888le 1

Property 9 shows that the value of any componentrsquosvulnerability index is between 0 and 1 with a larger valueindicating a higher vulnerability index

Property 10 (Vul119888ge max(119875

119894times VC119894) ge 0)

Proof For any vulnerability method 1 ge 119875119894ge 0 and 1 ge

VC119894ge 0 can be determined according to the definition of VC

Therefore max(119875119894timesVC119894) ge 0 In addition 1 ge 1minus119875

119894timesVC119894ge 0

and 1minusVul119888= prod

cnt119894=1(1minus119875119894timesVC119894) can be derived fromFormula

(1)prodcnt119894=1(1 minus 119875

119894timesVC119894) = (1 minus 119875

1timesVC1) times (1 minus 119875

2timesVC2) times sdot sdot sdot

times (1 minus max(119875119894times VC119894)) times sdot sdot sdot times (1 minus 119875cnt times VCcnt) therefore

prodcnt119894=1(1 minus 119875

119894times VC119894) le (1 minus max(119875

119894times VC119894)) and 1 minus Vul

119888le

(1minusmax(119875119894timesVC119894)) are derived that is Vul

119888ge max(119875

119894timesVC119894)

Thus Vul119888ge max(119875

119894times VC119894) ge 0 can proved correct

Property 10 shows that the vulnerability index of any onecomponent is not less than the peak value of the methodsrsquovulnerability indexes of the component All situations ofthe vulnerability methods of component are syntheticallyconsidered by the index of the vulnerability of component

Based on the component vulnerable assessment methodbased on the analysis of the interface the algorithm of thecomponentrsquos security assessment level is given as follows

The input probability matrix 119875 in Algorithm 1 is not onlyderived from the component requirement specifications orequal probability but is also statistically calculated after thecomponent is practically executed The vulnerability factorVC119894119895is assigned to 0 given that the component has no security

exceptional interface method We usually set the value of120575 and 120579 from 0 to 1 according to the complexity of testedcomponent and the testing requirement If the number ofinterfaces and methods of tested component is no more than200 we usually let the value of 120575 and 120579 to be 1 to ensurea complete testing of COTS In addition the test cases ofinterface parameters are generated using the TGSM [20 21]algorithm First the test cases of the interface parameter fault-injection expressed in matrix form are generated in termsof fault injection operator The K-factor coverage solutionmatrix is generated by the TGSM algorithm which is basedon the parameter set of the matrix form The fault injectiontest cases are composed of row data of the solution matrixTest cases generated by the TGSM algorithm not only greatlyreduce the scale of the test cases but also have certaincoverage The algorithm can trigger most of the securityexceptions with fewer test cases

Cnt is the number of vulnerability methods of the com-ponent 119862 in the algorithm results Vul

119894119895is the vulnerability

ratio of the method 119895 at the interface 119894 of the component 119862Vul119888represents the vulnerability level of the component 119862

1 minus Vul119894119895 the security level of the component 119862 represents

the security of the method 119895 in the interface 119894 of component119862

5 Experiment Analysis

To validate the effectiveness of the proposed approachthe approach was implemented in our component securitytesting system (CSTS) platform [22]The component securitytesting and assessing system based on interface fault injection(CSTASboIFT) was implemented using C language in theMicrosoft NET platform It is used as a subsystem of theCSTS platform Figure 2 shows the function flow chart ofCSTASboIFT

In the experiment six commercial components (Table 2)in which security vulnerabilities exist were collected forexperimental analysis in the CVE Web site Several group

6 Mathematical Problems in Engineering

Input Interface information XML file Fault injection operator Prediction rules PREDProbability matrix 119875 MCrsquos threshold and ICrsquos threshold value 120575 and 120579Output The security level of the whole component01 02 Read XML file03 MC = 0 IC = 0 119894 = 0 cnt = 0 cnt is the number of component vulnerability methods04 While IC lt 120575 do For each interface 119894 in 11986805

06 119894 = 119894 + 1 119895 = 007 While MC lt 120579 do For each method119898 in119872

119894

08

09 119895 = 119895 + 1 119895 is the number of the testing methods10 Generate method parameter values set according to fault injection operators11 Call testing cases generating algorithm TGSM() call the generation algorithm of the

minimum 119870 factors combined cover test case based on solution matrix12 Running 119862 and119872

119894119895

13 If (the output after running 119862 and119872119894119895satisfies PRED)

14

15 increment cnt16 Vul

119894119895= VC

119894119895times 119875119894119895 the vulnerability level of the method 119895 in the interface 119894

17

18 MC = 11989511987819

20 IC = 11989411987321

22 Vul119888= 1 minus prod

cnt119894=1(1 minus 119875

119894times VC

119894)

23 (Output) 1 minus Vul119888

24

Algorithm 1 QACS (quantitative assessment of component security) algorithm

Tested component

Interface analysis

Component interface

Implement test cases

Fault injectionoperator

Compile driven execution

Dynamic monitor

Probabilitymatrix

Vulnerability factor value Probabilitymatrix

Security levelassessment report

information (XML file)

Monitor loginformation

Assessmentrule library119875

Figure 2 The function flow chart of CSTASboIFT

experiments were conducted for these components A com-ponent composed of six interfaces and each interface consist-ing of eight methods were assumed so that the componentcould be regarded as a 6 times 8 matrix The first group of

experiments tested the condition of 119875119894119895assigned to a fixed

matrix and VC119894119895divided into interval descending As VC

119894119895

changed the 1 minus Vul119888was affected That is only the level of

vulnerability factors affected the component security levelThe second group of experiments tested the condition ofVC119894119895assigned to a fixed matrix and 119875

119894119895divided into interval

descending As 119875119894119895changed 1 minus Vul

119888was affected That is

only the executed probability affected the component securitylevel The last group of experiments considered the effect on1minusVul

119888 as both vulnerability factor and executed probability

simultaneously changed

51 Experiment One Thevulnerability factor value is dividedinto intervals based on the knowledge of security vulner-ability provided by the CVE Web site 119875

119894119895represents the

executable probability of the method 119895 at the interface 119894VC119894119895represents the vulnerability factors of the method 119895 at

the interface 119894 and Vul119888represents the vulnerability level of

component 119862 1 minus Vul119888is the security level of component 119862

The first experiment assumes that 119875119894119895is a 6 times 8 fixed

matrix which is made up of random values For everyinterval 119875

119894119895is the same matrix VC

119894119895is divided into 10

intervals [000 009] [010 019] [020 029] [030 039][040 049] [050 059] [060 069] [070 079] [080 089]and [090 100] The tests were done about ten times withdifferent random values of 119875

119894119895and VC

119894119895 respectively in the

experiment and then the value 1minusVul119888was got by calculating

Mathematical Problems in Engineering 7

Table 2 The six typical tested components

Component ID Component name Component information01 ThunderAgent 005dll An ActiveX control in Thunder 5 Component version is 10011 Thunder version is 55225202 AcroPDFdll An AcroPDF ActiveX control in Adobe Reader and Acrobat Component version is 708003 GLItemComdll An ActiveX control in OURGAMEWORLD game software Component version is 270804 pdg2dll An ActiveX control in SUPERSTART READER software Component version is 390005 GomWeb3dll An ActiveX control in GOM Player GOM Player is a media player widely used in Korea06 Vulndll A third-party tested component Component version is 1012

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

VC119894

1minusVu

L 119888

(a) cnt = 5

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(b) cnt = 10

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(c) cnt = 15

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(d) cnt = 20

Figure 3 The comparison for different VC119894and cnt

the average result Under the condition that 119875119894119895is regarded as

a 6 times 8matrix at every interval of VC119894119895 VC119894119895affects the value

1 minus Vul119888

When Vul119894119895is equal to 119875

119894119895times VC119894119895 as 119875119894119895is a fixed value

the values of Vul119888and Vul

119894119895are proportional to the value of

VC119894119895 The value of 1 minus Vul

119888is reversely proportional to VC

119894119895

A larger VC119894119895value indicates a lower security level As the

vulnerability number increases the security level decreasesslowly The results are shown in Figure 3 The testing resultsshow that the proposed assessment Formula (1) is effective

52 Experiment Two VC119894119895is assumed a 6 times 8 fixed matrix

made up of random values in the second experiment Then119875119894119895

is divided into 10 intervals [000 009] [010 019][020 029] [030 039] [040 049] [050 059] [060 069][070 079] [080 089] and [090 100] The tests were doneabout ten times with different random values of 119875

119894119895and VC

119894119895

respectively in the experiment and then the value 1minusVul119888was

got by calculating the average result Under the condition thatVC119894119895is regarded as a 6 times 8 matrix at every interval of 119875

119894119895 119875119894119895

affects the value of 1 minus Vul119888

When VuL119894119895is equal to 119875

119894119895times VC119894119895 as the value of VC

119894119895

is fixed the values of Vul119888and VuL

119894119895are proportional to the

value of 119875119894119895 The value of 1 minus Vul

119888is reversely proportional

to VC119894119895 A larger 119875

119894119895value indicates a lower security level

That is the component is more insecure As the number ofcnt increases the decline rate of the security level is initiallyfast and then becomes slow The results as presented inFigure 4 show that the proposed assessment Formula (1) iseffective

53 Experiment Three Both parameters 119875119894and VC

119894are

assumed to influence the value of 1 minus Vul119888in Experiment

three The two parameters are randomly divided into 10

8 Mathematical Problems in Engineering

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(a) cnt = 5

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(b) cnt = 10

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(c) cnt = 15

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(d) cnt = 20

Figure 4 The comparison for different 119875119894and cnt

intervals The effect on the value of 1 minus VuL119888when the

two parameters changed simultaneously was observed Theresults show that when 119875

119894is proportional to VC

119894 the value

of 1 minus Vul119888changes significantly as shown in (a) and (b)

of Figure 5 When 119875119894is inversely proportional to VC

119894 the

value of 1 minus Vul119888changes indistinctly as shown in (c) and

(d) of Figure 5 As the vulnerability number cnt increasesthe security level decreases Results are shown in Figure 5The values of 119875

119894and VC

119894are based on the main 119910-axis values

(the left axis) and the value of the 1 minus Vul119888is based on the

secondary 119910-axis values (the right axis) The testing resultsshow that the proposed assessment Formula (1) is suitable forassessing the COTS component

54 Experiment Four The components were assessed inTable 3 based on Algorithm 1 The value of IC and MC is setto 1 119875

119894can be determined by executing the tested component

100 times or moreDuring the system testing process the test cases of fault

injection can be implemented by testing the componentinformation and fault injection operators The testing statecan be recorded through the dynamic monitoring mecha-nism after running the tested component The vulnerabilitytype of the componentmethod and vulnerability factor can bederived from comparing the testing state with the componentinformation record in PRED The execution probability 119875

119894

of each method in the component can be determined byrunning the tested component 100 times respectively Thenthe component security level can be determined using For-mula (1)The testing results are shown in Table 3 Because dif-ferent components have different method parameters whichhave different parameter types such as integer string andboolean we select suitable fault injection factors to test thecomponent security based on the above presented 18 faultinjection operators of component in Table 3

A higher level of security indicates better relative securityof the component The component is secure if and only ifthe component security level is 1 Otherwise it has securityvulnerability In contrast to the test results in Table 3 the levelof security is closer to the vulnerability information publishedin the CVE Web site The values of execution probabilityand vulnerability factors have been proved to affect thecomponent security The results agree with the previousexperimental results further confirming the feasibility andeffectiveness of this approach

55 Experimental Comparison Table 4 shows the compar-ison with other assessment approaches The related assess-ment approaches have various merits as shown in theanalysis of Table 4 Our QACS approach mainly focuseson quantitatively assessing the security level of the COTScomponent The source codes of the COTS component are

Mathematical Problems in Engineering 9

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(a) cnt = 5

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(b) cnt = 10

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(c) cnt = 15

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(d) cnt = 20

Figure 5 The comparison for different 119875119894 VC119894 and cnt

generally unknownThe internal factors of the component areconsidered in QACSThe QACS approach is implemented inthe CSTASboIFT that is integrated into our CSTS [22] systemdeveloped to test the security of the COTS component

Aside from the above-mentioned approaches CVSS is awidely used quantitative assessment approach for softwarecomponent Khan and Han developed an assessment schemefor the security properties of software components Theassessment scheme provided a numeric score that indicatesthe relative strength of the security properties of the compo-nent [8] Results of the comparison with the CVSS approachand Khaled approach are shown in Table 5 In addition thesecurity level of six tested components is also listed accordingto the reported empirical data of securityWeb sites in Table 5The initial CVSSBase Score is calculated by theCVSS formula[16]

Analyzing Table 5 the QACS approach is found to beclose to the empirical data reported on some security Websites regarding the security of the tested COTS componentsThe security score of the QACS approach is more accuratethan that of others because the internal factors of the tested

component are considered The assessment process of theQACS approach is objective without human interventionNevertheless the CVSS approach ismainly focused on assess-ing the vulnerability of the general software componentIf an assessor is not familiar with the assessed softwarethe vulnerability score becomes inaccurate because of theassessorrsquos subjectivity in the assessment process On the otherhand the Khaled approach is an approximate assessmentapproach based on the assumed component environment Inaddition presently there are no more effective assessmentapproaches for the security level of software componentaccording to our studies

6 Conclusion

In component-based software development andmaintenanceactivities the assessment of the component reliability andsecurity level is essential in the third-party componentResearch on an effective quantitative assessment methodfor component security level is valuable in the CBSE The

10 Mathematical Problems in Engineering

Table 3 Testing results for six tested components

ID Fault injectionfactor

The number ofvulnerabilities and its 119875

119894

Test result Security level

01 IIV 2(013 013)

ThunderAgent 005dll has two methods calling(GetInfoStruct() GetTaskInfoStruc()) neglected the inputparameter exception and generated security vulnerability Thenthey resulted in program breakdown

07569

02 CIV LSV RSV 5(01 02 01 015 02)

AcroPDFdll did not correctly deal with the string parameterssent to function setPageMode() LoadFile() setLayoutMode()and setNamedDest() and the attribute src It triggered memorydestroyed and resulted in security vulnerability for executingany instruction

04406

03 LSV RSV FSV 1(064)

The function SetInfo() of GLItemComDLL ActiveX overtrusted user input and did not check parameterrsquos length Itresulted in the point the virtual function covered

036

04 LSV RSV FSV 1(01)

Pdg2dll did not deal with the sent parameter to Register () ifuser sends the string over 256 bytes it can trigger stack overflowand execute any code

09

05 LSV RSV USV 1(015)

GomManager object did not collectively deal with the firstparameter of OpenURL() in IGomManager interface Iftransmitting the long parameters over 500 bytes it can triggerstack overflow to result in visiting the memory exception

085

06 PSN CIV PIVLSV USV

5(015 015 015 015 015)

5 methods of component existed security exception The testcase parameters implemented by input fault injection operatorwould result in buffer overflow visiting beyond the scope andmemory leakage

04437

Table 4 The comparison with related assessment approaches

Assessment approach Assessment object Assessment aspect Is the internalfactor considered

Qualitative orquantitative

Is there supportingtool

Khan and Han [8] Software component Security No Quantitative NoAlhazmi and Malaiya[11] Operating system Vulnerability Yes Quantitative No

Zhang et al [12] Software system Risk No Quantitativequalitative

No

Goseva-Popstojanovaand Trivedi [15] Software system Reliability No Quantitative No

Mkpong-Ruffin [3] Software Risk No Quantitative Yes

CVSS [16] Software component Vulnerability No Quantitative Yes

QACS COTS component Security Yes Quantitative Yes

Table 5 The comparison with CVSS and Khaled approaches

ComponentID

InitialCVSS base

score

Convertedsecurity score

of CVSS

Securitylevel ofQACS

The reportedempirical data(security level)

01 58 042 07569 B+

02 19 081 04406 Cminus

03 6 04 036 D+

04 7 03 09 A

05 36 064 085 Aminus

06 19 081 04437 Cminus

current paper proposes theQACS approach for quantitativelyassessing component security which is based on the interfacefault injection of the componentThe fault injection operatorsof the component vulnerability and PRED are defined anddiscussedThe assessment framework and algorithm for com-ponent security are proposed as wellThe testing effect provesexcellent in practical application QACS has the followingmain advantages (1) the security exceptional assessmentrules and vulnerability factors of the component are givenproviding the basis for security assessment (2) QACS canassess the security level of the third-party component andthe score of component security can be accurately calculated(3) QACS has better operability

Mathematical Problems in Engineering 11

Acknowledgments

We would like to thank Professor T Y Chen for his con-structive suggestions and valuable discussion in this paperwriting In addition this work was supported partly bythe National Natural Science Foundation of China (NSFC)under Grants no 61202110 and no 61063013 Natural ScienceFoundation of Jiangsu Province under Grant no BK2012284and the Research Fund for the Doctoral Program of HigherEducation of China under Grant no 20103227120005

References

[1] J Chen Y Lu and X D Xie ldquoComponent security testingapproach by using interface fault injectionrdquo Journal of ChineseComputer Systems vol 31 no 6 pp 1090ndash1096 2010

[2] S Gudder andRGreechie ldquoUniqueness and order in sequentialeffect algebrasrdquo International Journal of Theoretical Physics vol44 no 7 pp 755ndash770 2005

[3] I O Mkpong-Ruffin Quantitative risk assessment model forsoftware security in the design phase of software development[PhD thesis] Auburn University Auburn Ala USA 2009

[4] J Han and Y Zheng ldquoSecurity characterization and integrityassurance for component-based softwarerdquo in Proceedings of theInternational Conference on Software Methods and Tools (SMTrsquo00) pp 61ndash66 IEEE Computer SocietyWollongong Australia2000

[5] F Jabeen and M Jaffar-Ur Rehman ldquoA framework for objectoriented component testingrdquo in Proceedings of the IEEE Inter-national Conference on Emerging Technologies (ICET rsquo05) pp451ndash460 Islamabad Pakistan September 2005

[6] K Md Khan J Han and Y Zheng ldquoCharacterizing userdata protection of software componentsrdquo in Proceedings of theSoftware EngineeringConference pp 3ndash11 CanberraAustralian2000

[7] K M Khan and J Han ldquoA security characterisation frame-work for trustworthy component based software systemsrdquo inProceedings of the 27th Annual International Computer Softwareand Applications Conference (COMPSAC rsquo03) pp 164ndash169November 2003

[8] K M Khan and J Han ldquoAssessing security properties ofsoftware components a software engineerrsquos perspectiverdquo inProceedings of the Australian Software Engineering Conference(ASWEC rsquo06) pp 199ndash208 Sydney Australia April 2006

[9] K Khan J Han and Y Zheng ldquoA framework for an activeinterface to characterise compositional security contracts ofsoftware components rdquo in Proceedings of the Australian SoftwareEngineering Conference (ASWEC rsquo01) pp 117ndash126 2001

[10] ldquoCommon criteria projectISO Common criteria for informa-tion technology security evaluationrdquo version 21 (ISOIEC Inter-national Standard 15408) NIST USA and ISO Switzerland1999 httpcsrcnistgovcc

[11] O H Alhazmi and Y K Malaiya ldquoQuantitative vulnerabilityassessment of systems softwarerdquo in Proceedings of the AnnualReliability andMaintainability Symposium (RAMS rsquo05) pp 615ndash620 January 2005

[12] Y-K Zhang S-Y Jiang Y-A Cui B W Zhang and H Xia ldquoAqualitative and quantitative risk assessment method in softwaresecurityrdquo in Proceedings of the 3rd International Conference onAdvanced Computer Theory and Engineering (ICACTE rsquo10) ppV1534ndashV1539 Chengdu China August 2010

[13] X Tang and B Shen ldquoExtending model driven architecturewith software security assessmentrdquo in Proceedings of the 3rdIEEE International Conference on Secure Software IntegrationReliability Improvement (SSIRI rsquo09) pp 436ndash441 ShanghaiChina July 2009

[14] X Wang H Shi T Y W Huang and F C Lin ldquoIntegratedsoftware vulnerability and security functionality assessmentrdquoin Proceedings of the 18th IEEE International Symposium onSoftware Reliability Engineering (ISSRE rsquo07) pp 103ndash108 Troll-hattan Sweden November 2007

[15] K Goseva-Popstojanova and K S Trivedi ldquoArchitecture-basedapproach to reliability assessment of software systemsrdquo Perfor-mance Evaluation vol 45 no 2-3 pp 179ndash204 2001

[16] ldquoNVD Common Vulnerability Scoring System (CVSS)rdquohttpnvdnistgovcvsscfm

[17] Y Jiang G M Xin J-H Shan L Zhang B Xie and F-Q YangldquoMethod of automated test data generation for web servicerdquoChinese Journal of Computers vol 28 no 4 pp 568ndash577 2005

[18] M E Delamaro J C Maldonado and A P Mathur ldquoInterfacemutation an approach for integration testingrdquo IEEE Transac-tions on Software Engineering vol 27 no 3 pp 228ndash247 2001

[19] J M Voas and K W Miller ldquoPredicting softwarersquos minimum-time-to-hazard andmean-time-to-hazard for rare input eventsrdquoin Proceedings of the 6th International Symposium on SoftwareReliability Engineering pp 229ndash238 October 1995

[20] J Chen Y Lu andX Xie ldquoA fault injectionmodel of componentsecurity testingrdquo Computer Research and Development vol 46no 7 pp 1127ndash1135 2009

[21] J Chen Y LuW Zhang andXD Xie ldquoA fault injectionmodel-oriented testing strategy for component securityrdquo Journal ofCentral South University of Technology vol 16 no 2 pp 258ndash264 2009

[22] J Chen Y Lu X Xie et al ldquoDesign and implementation of anautomatic testing platform for component securityrdquo ComputerScience vol 35 no 12 pp 229ndash233 2008

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

4 Mathematical Problems in Engineering

Table 1 Exceptional predication rules and vulnerability factors

ID Predication rules Description VC01 General exception The general exception code is detected or throw an exception 05

02 Access out of range Running a thread attempts to read or write the memory address buthas no corresponding access authority 1

03 Matrix visited beyond scope A thread tries to access an array element beyond scope 1

04 Access the memory page not exiting The file system returns a read error resulting in page fault whichcan-not meet the requirements 08

05 Visit the protected page A thread tries to access memory page that has the attribute ofPAGE GUARD 1

06 Stack of thread is overflow A thread runs out of all stack space assigned to it 1

07 Execute illegal instruction A thread running an instruction that is not allowed in the currentthread or executing an invalid instruction 1

08 Divisor is 0 A thread tries to divide an integer or a float by 0 08

09 Operation out of range An operation result exceeds the specified range values 08

10 Floating-point stack overflow Stack overflow or underflow because of floating-point operations 1

11 Buffer overflow Written contents beyond the buffer length resulting in written datacovering the original return address and destroying the program stack 1

12 Memory leakageMonitoring the input and output values of malloc() free() realloc()functions and making a statistical analysis to achieve a memoryleakage check

1

13 Format string exceptions Format or parameter mismatch when using printf() function such asldquonnsdrdquo 1

(Parameter Attribute Swap) PSN (Parameter Set Null) IPO(Insert Parameter Operator) PFB (Parameter Flip Bit) PRI(Parameter Reverse-probability Input) IIV (integer IrregularValue) FIV (Float Irregular Value) CIV (Char IrregularValue) BIV (Boolean Irregular Value) RSV (Random StringValue) LSV (Long String Value) FSV (Format String Value)DSV (Directory String Value) USV (URL and string valueof file directory) CSV (System Command String Value) SSV(SQL string injection) and CSS (Cascading Style Sheet) Thenew security vulnerabilities found in components can also beadded

In addition the reverse distribution function of theparameter input domain is generated using the input operatorPRI of the parameters of reverse probability distributionThe parameters of reverse probability distribution are thengenerated The experimental result shows that componentsecurity exception can be effectively triggered through theirregular value of input domain The input distributionfunction which is usually difficult to obtain is a probabilitydensity functionThe one dimensional andmultidimensionalfunctions are the two commonly used kinds Q is assumedthe input distribution function of which the value is in theinterval [0 1] and the value 0 indicates the probability ofselection input field is 0 The algorithm of reverse probabilitydistribution 1198761015840 is given in the literature [19]

A number of models have been designed to facilitatethe automatic management of the fault injection operatorsuch as the automatic learning model of the fault injectionoperator adaptive model topic model intelligent vulnerabletrees among others They can automatically increase andmanage the operator libraries of fault injection

32 Exceptional Predication Rules and Vulnerability Factors

Definition 3 The component exceptional predication rule isa set of all the possible exceptions that may arise under theexceptional circumstances

Definition 4 The vulnerability factor of the component rep-resents the degree of the component security vulnerabilitiesresulting from exceptions The maximum value is 1 and theminimum value is 0 Table 1 shows the component excep-tional predication rules and relative vulnerability factorsused to assess the component security level Each of thefactor value of exceptional security vulnerability which canobjectively describe the component security level is obtainedfrom the triggering causes of software security vulnerabilitieswhich is a harmful degree combined with the characteristicsof component security vulnerabilities based on experiencesoftware engineering

4 Component Security Assessment Algorithm

Suppose 119862 is a component and 119868 is a set of interface in119862 Let 119901

119894represent the execution probability of interface 119894

and119872119894is a method properties set of interface 119894 Meanwhile

119901119894119898

is the executable probability in method 119898 of interface 119894Suppose |119868| = 119873 |119872

119894| = 119878 119909 is the input parameter of the

method attribute in 119862 119879 is vulnerable error test cases set and119879 = 119905

1 1199052 1199053 119905

119899 Δ is all the input set of component

119862 1198761015840 is the reverse probability distribution of Δ PRED isthe logical prediction rules of exceptional database VC isthe vulnerability factor of exceptional function Before the

Mathematical Problems in Engineering 5

vulnerability assessment method of component is given thefollowing definitions should be introduced first

Definition 5 Let 119875 represent an 119873 times 119878 probability matrixthat can be described as 119875 = (119901

119894119895)119899times119904

row 119894 represents theinterface number of component 119862 and column 119895 representsthe method number of interface 119894 The element 119901

119894119895states

the executable probability for function 119895 at interface 119894 ofcomponent 119862 where 119901

119894119895= 119901119894times 119901119895

Definition 6 Interface method coverage (MC) where MC =

(the number of methods executed at least oncethe totalnumber methods 119878) times 100 is used to measure the sufficientdegree of the interface method during component testing

Definition 7 Interface coverage (IC) where IC = (the numberof interfaces executed at least oncethe total number interface119873) times 100 is used to measure the sufficient degree of theinterface test during component testing

Definition 8 Component test adequacy CA can be measuredby a two-tuple (ie MC and IC) Generally the value isdetermined by the total score of MC and IC that is CA =

[sum119894=1119873

(MC119894)]119873+IC A greater value of CA indicates amore

comprehensive test the relationship between MC and IC isparallel

Suppose Sum 119872 represents the number of test meth-ods cnt represents the number of vulnerability methods incomponent 119862 and VC

119894represents the vulnerability factors of

exceptional method The value of vulnerability factor VC119894is

assigned to 0 in case the interface method has no securityexceptions The execution probability of the vulnerabilitymethod 119894 is labeled 119875

119894 The component vulnerability assess-

ment formula is given as follows

Vul119888= 1 minus

cntprod119894=1

(1 minus 119875119894times VC119894) (1)

The value 1 minus Vul119888 the security level of the component

119862 can be derived from the Formula (1) The vulnerabilityassessment formula of the component has the followingproperties

Property 9 (0 le Vul119888le 1)

Proof For any vulnerability method 1 ge 119875119894ge 0 and 1 ge

VC119894ge 0 can be determined according to the definition of

VCTherefore 1 ge 119875119894timesVC119894ge 0 1 ge 1minus119875

119894timesVC119894ge 0 and 0 le

prodcnt119894=1(1 minus 119875

119894times VC119894) le 1 are derived that is 0 le Vul

119888le 1

Property 9 shows that the value of any componentrsquosvulnerability index is between 0 and 1 with a larger valueindicating a higher vulnerability index

Property 10 (Vul119888ge max(119875

119894times VC119894) ge 0)

Proof For any vulnerability method 1 ge 119875119894ge 0 and 1 ge

VC119894ge 0 can be determined according to the definition of VC

Therefore max(119875119894timesVC119894) ge 0 In addition 1 ge 1minus119875

119894timesVC119894ge 0

and 1minusVul119888= prod

cnt119894=1(1minus119875119894timesVC119894) can be derived fromFormula

(1)prodcnt119894=1(1 minus 119875

119894timesVC119894) = (1 minus 119875

1timesVC1) times (1 minus 119875

2timesVC2) times sdot sdot sdot

times (1 minus max(119875119894times VC119894)) times sdot sdot sdot times (1 minus 119875cnt times VCcnt) therefore

prodcnt119894=1(1 minus 119875

119894times VC119894) le (1 minus max(119875

119894times VC119894)) and 1 minus Vul

119888le

(1minusmax(119875119894timesVC119894)) are derived that is Vul

119888ge max(119875

119894timesVC119894)

Thus Vul119888ge max(119875

119894times VC119894) ge 0 can proved correct

Property 10 shows that the vulnerability index of any onecomponent is not less than the peak value of the methodsrsquovulnerability indexes of the component All situations ofthe vulnerability methods of component are syntheticallyconsidered by the index of the vulnerability of component

Based on the component vulnerable assessment methodbased on the analysis of the interface the algorithm of thecomponentrsquos security assessment level is given as follows

The input probability matrix 119875 in Algorithm 1 is not onlyderived from the component requirement specifications orequal probability but is also statistically calculated after thecomponent is practically executed The vulnerability factorVC119894119895is assigned to 0 given that the component has no security

exceptional interface method We usually set the value of120575 and 120579 from 0 to 1 according to the complexity of testedcomponent and the testing requirement If the number ofinterfaces and methods of tested component is no more than200 we usually let the value of 120575 and 120579 to be 1 to ensurea complete testing of COTS In addition the test cases ofinterface parameters are generated using the TGSM [20 21]algorithm First the test cases of the interface parameter fault-injection expressed in matrix form are generated in termsof fault injection operator The K-factor coverage solutionmatrix is generated by the TGSM algorithm which is basedon the parameter set of the matrix form The fault injectiontest cases are composed of row data of the solution matrixTest cases generated by the TGSM algorithm not only greatlyreduce the scale of the test cases but also have certaincoverage The algorithm can trigger most of the securityexceptions with fewer test cases

Cnt is the number of vulnerability methods of the com-ponent 119862 in the algorithm results Vul

119894119895is the vulnerability

ratio of the method 119895 at the interface 119894 of the component 119862Vul119888represents the vulnerability level of the component 119862

1 minus Vul119894119895 the security level of the component 119862 represents

the security of the method 119895 in the interface 119894 of component119862

5 Experiment Analysis

To validate the effectiveness of the proposed approachthe approach was implemented in our component securitytesting system (CSTS) platform [22]The component securitytesting and assessing system based on interface fault injection(CSTASboIFT) was implemented using C language in theMicrosoft NET platform It is used as a subsystem of theCSTS platform Figure 2 shows the function flow chart ofCSTASboIFT

In the experiment six commercial components (Table 2)in which security vulnerabilities exist were collected forexperimental analysis in the CVE Web site Several group

6 Mathematical Problems in Engineering

Input Interface information XML file Fault injection operator Prediction rules PREDProbability matrix 119875 MCrsquos threshold and ICrsquos threshold value 120575 and 120579Output The security level of the whole component01 02 Read XML file03 MC = 0 IC = 0 119894 = 0 cnt = 0 cnt is the number of component vulnerability methods04 While IC lt 120575 do For each interface 119894 in 11986805

06 119894 = 119894 + 1 119895 = 007 While MC lt 120579 do For each method119898 in119872

119894

08

09 119895 = 119895 + 1 119895 is the number of the testing methods10 Generate method parameter values set according to fault injection operators11 Call testing cases generating algorithm TGSM() call the generation algorithm of the

minimum 119870 factors combined cover test case based on solution matrix12 Running 119862 and119872

119894119895

13 If (the output after running 119862 and119872119894119895satisfies PRED)

14

15 increment cnt16 Vul

119894119895= VC

119894119895times 119875119894119895 the vulnerability level of the method 119895 in the interface 119894

17

18 MC = 11989511987819

20 IC = 11989411987321

22 Vul119888= 1 minus prod

cnt119894=1(1 minus 119875

119894times VC

119894)

23 (Output) 1 minus Vul119888

24

Algorithm 1 QACS (quantitative assessment of component security) algorithm

Tested component

Interface analysis

Component interface

Implement test cases

Fault injectionoperator

Compile driven execution

Dynamic monitor

Probabilitymatrix

Vulnerability factor value Probabilitymatrix

Security levelassessment report

information (XML file)

Monitor loginformation

Assessmentrule library119875

Figure 2 The function flow chart of CSTASboIFT

experiments were conducted for these components A com-ponent composed of six interfaces and each interface consist-ing of eight methods were assumed so that the componentcould be regarded as a 6 times 8 matrix The first group of

experiments tested the condition of 119875119894119895assigned to a fixed

matrix and VC119894119895divided into interval descending As VC

119894119895

changed the 1 minus Vul119888was affected That is only the level of

vulnerability factors affected the component security levelThe second group of experiments tested the condition ofVC119894119895assigned to a fixed matrix and 119875

119894119895divided into interval

descending As 119875119894119895changed 1 minus Vul

119888was affected That is

only the executed probability affected the component securitylevel The last group of experiments considered the effect on1minusVul

119888 as both vulnerability factor and executed probability

simultaneously changed

51 Experiment One Thevulnerability factor value is dividedinto intervals based on the knowledge of security vulner-ability provided by the CVE Web site 119875

119894119895represents the

executable probability of the method 119895 at the interface 119894VC119894119895represents the vulnerability factors of the method 119895 at

the interface 119894 and Vul119888represents the vulnerability level of

component 119862 1 minus Vul119888is the security level of component 119862

The first experiment assumes that 119875119894119895is a 6 times 8 fixed

matrix which is made up of random values For everyinterval 119875

119894119895is the same matrix VC

119894119895is divided into 10

intervals [000 009] [010 019] [020 029] [030 039][040 049] [050 059] [060 069] [070 079] [080 089]and [090 100] The tests were done about ten times withdifferent random values of 119875

119894119895and VC

119894119895 respectively in the

experiment and then the value 1minusVul119888was got by calculating

Mathematical Problems in Engineering 7

Table 2 The six typical tested components

Component ID Component name Component information01 ThunderAgent 005dll An ActiveX control in Thunder 5 Component version is 10011 Thunder version is 55225202 AcroPDFdll An AcroPDF ActiveX control in Adobe Reader and Acrobat Component version is 708003 GLItemComdll An ActiveX control in OURGAMEWORLD game software Component version is 270804 pdg2dll An ActiveX control in SUPERSTART READER software Component version is 390005 GomWeb3dll An ActiveX control in GOM Player GOM Player is a media player widely used in Korea06 Vulndll A third-party tested component Component version is 1012

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

VC119894

1minusVu

L 119888

(a) cnt = 5

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(b) cnt = 10

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(c) cnt = 15

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(d) cnt = 20

Figure 3 The comparison for different VC119894and cnt

the average result Under the condition that 119875119894119895is regarded as

a 6 times 8matrix at every interval of VC119894119895 VC119894119895affects the value

1 minus Vul119888

When Vul119894119895is equal to 119875

119894119895times VC119894119895 as 119875119894119895is a fixed value

the values of Vul119888and Vul

119894119895are proportional to the value of

VC119894119895 The value of 1 minus Vul

119888is reversely proportional to VC

119894119895

A larger VC119894119895value indicates a lower security level As the

vulnerability number increases the security level decreasesslowly The results are shown in Figure 3 The testing resultsshow that the proposed assessment Formula (1) is effective

52 Experiment Two VC119894119895is assumed a 6 times 8 fixed matrix

made up of random values in the second experiment Then119875119894119895

is divided into 10 intervals [000 009] [010 019][020 029] [030 039] [040 049] [050 059] [060 069][070 079] [080 089] and [090 100] The tests were doneabout ten times with different random values of 119875

119894119895and VC

119894119895

respectively in the experiment and then the value 1minusVul119888was

got by calculating the average result Under the condition thatVC119894119895is regarded as a 6 times 8 matrix at every interval of 119875

119894119895 119875119894119895

affects the value of 1 minus Vul119888

When VuL119894119895is equal to 119875

119894119895times VC119894119895 as the value of VC

119894119895

is fixed the values of Vul119888and VuL

119894119895are proportional to the

value of 119875119894119895 The value of 1 minus Vul

119888is reversely proportional

to VC119894119895 A larger 119875

119894119895value indicates a lower security level

That is the component is more insecure As the number ofcnt increases the decline rate of the security level is initiallyfast and then becomes slow The results as presented inFigure 4 show that the proposed assessment Formula (1) iseffective

53 Experiment Three Both parameters 119875119894and VC

119894are

assumed to influence the value of 1 minus Vul119888in Experiment

three The two parameters are randomly divided into 10

8 Mathematical Problems in Engineering

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(a) cnt = 5

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(b) cnt = 10

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(c) cnt = 15

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(d) cnt = 20

Figure 4 The comparison for different 119875119894and cnt

intervals The effect on the value of 1 minus VuL119888when the

two parameters changed simultaneously was observed Theresults show that when 119875

119894is proportional to VC

119894 the value

of 1 minus Vul119888changes significantly as shown in (a) and (b)

of Figure 5 When 119875119894is inversely proportional to VC

119894 the

value of 1 minus Vul119888changes indistinctly as shown in (c) and

(d) of Figure 5 As the vulnerability number cnt increasesthe security level decreases Results are shown in Figure 5The values of 119875

119894and VC

119894are based on the main 119910-axis values

(the left axis) and the value of the 1 minus Vul119888is based on the

secondary 119910-axis values (the right axis) The testing resultsshow that the proposed assessment Formula (1) is suitable forassessing the COTS component

54 Experiment Four The components were assessed inTable 3 based on Algorithm 1 The value of IC and MC is setto 1 119875

119894can be determined by executing the tested component

100 times or moreDuring the system testing process the test cases of fault

injection can be implemented by testing the componentinformation and fault injection operators The testing statecan be recorded through the dynamic monitoring mecha-nism after running the tested component The vulnerabilitytype of the componentmethod and vulnerability factor can bederived from comparing the testing state with the componentinformation record in PRED The execution probability 119875

119894

of each method in the component can be determined byrunning the tested component 100 times respectively Thenthe component security level can be determined using For-mula (1)The testing results are shown in Table 3 Because dif-ferent components have different method parameters whichhave different parameter types such as integer string andboolean we select suitable fault injection factors to test thecomponent security based on the above presented 18 faultinjection operators of component in Table 3

A higher level of security indicates better relative securityof the component The component is secure if and only ifthe component security level is 1 Otherwise it has securityvulnerability In contrast to the test results in Table 3 the levelof security is closer to the vulnerability information publishedin the CVE Web site The values of execution probabilityand vulnerability factors have been proved to affect thecomponent security The results agree with the previousexperimental results further confirming the feasibility andeffectiveness of this approach

55 Experimental Comparison Table 4 shows the compar-ison with other assessment approaches The related assess-ment approaches have various merits as shown in theanalysis of Table 4 Our QACS approach mainly focuseson quantitatively assessing the security level of the COTScomponent The source codes of the COTS component are

Mathematical Problems in Engineering 9

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(a) cnt = 5

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(b) cnt = 10

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(c) cnt = 15

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(d) cnt = 20

Figure 5 The comparison for different 119875119894 VC119894 and cnt

generally unknownThe internal factors of the component areconsidered in QACSThe QACS approach is implemented inthe CSTASboIFT that is integrated into our CSTS [22] systemdeveloped to test the security of the COTS component

Aside from the above-mentioned approaches CVSS is awidely used quantitative assessment approach for softwarecomponent Khan and Han developed an assessment schemefor the security properties of software components Theassessment scheme provided a numeric score that indicatesthe relative strength of the security properties of the compo-nent [8] Results of the comparison with the CVSS approachand Khaled approach are shown in Table 5 In addition thesecurity level of six tested components is also listed accordingto the reported empirical data of securityWeb sites in Table 5The initial CVSSBase Score is calculated by theCVSS formula[16]

Analyzing Table 5 the QACS approach is found to beclose to the empirical data reported on some security Websites regarding the security of the tested COTS componentsThe security score of the QACS approach is more accuratethan that of others because the internal factors of the tested

component are considered The assessment process of theQACS approach is objective without human interventionNevertheless the CVSS approach ismainly focused on assess-ing the vulnerability of the general software componentIf an assessor is not familiar with the assessed softwarethe vulnerability score becomes inaccurate because of theassessorrsquos subjectivity in the assessment process On the otherhand the Khaled approach is an approximate assessmentapproach based on the assumed component environment Inaddition presently there are no more effective assessmentapproaches for the security level of software componentaccording to our studies

6 Conclusion

In component-based software development andmaintenanceactivities the assessment of the component reliability andsecurity level is essential in the third-party componentResearch on an effective quantitative assessment methodfor component security level is valuable in the CBSE The

10 Mathematical Problems in Engineering

Table 3 Testing results for six tested components

ID Fault injectionfactor

The number ofvulnerabilities and its 119875

119894

Test result Security level

01 IIV 2(013 013)

ThunderAgent 005dll has two methods calling(GetInfoStruct() GetTaskInfoStruc()) neglected the inputparameter exception and generated security vulnerability Thenthey resulted in program breakdown

07569

02 CIV LSV RSV 5(01 02 01 015 02)

AcroPDFdll did not correctly deal with the string parameterssent to function setPageMode() LoadFile() setLayoutMode()and setNamedDest() and the attribute src It triggered memorydestroyed and resulted in security vulnerability for executingany instruction

04406

03 LSV RSV FSV 1(064)

The function SetInfo() of GLItemComDLL ActiveX overtrusted user input and did not check parameterrsquos length Itresulted in the point the virtual function covered

036

04 LSV RSV FSV 1(01)

Pdg2dll did not deal with the sent parameter to Register () ifuser sends the string over 256 bytes it can trigger stack overflowand execute any code

09

05 LSV RSV USV 1(015)

GomManager object did not collectively deal with the firstparameter of OpenURL() in IGomManager interface Iftransmitting the long parameters over 500 bytes it can triggerstack overflow to result in visiting the memory exception

085

06 PSN CIV PIVLSV USV

5(015 015 015 015 015)

5 methods of component existed security exception The testcase parameters implemented by input fault injection operatorwould result in buffer overflow visiting beyond the scope andmemory leakage

04437

Table 4 The comparison with related assessment approaches

Assessment approach Assessment object Assessment aspect Is the internalfactor considered

Qualitative orquantitative

Is there supportingtool

Khan and Han [8] Software component Security No Quantitative NoAlhazmi and Malaiya[11] Operating system Vulnerability Yes Quantitative No

Zhang et al [12] Software system Risk No Quantitativequalitative

No

Goseva-Popstojanovaand Trivedi [15] Software system Reliability No Quantitative No

Mkpong-Ruffin [3] Software Risk No Quantitative Yes

CVSS [16] Software component Vulnerability No Quantitative Yes

QACS COTS component Security Yes Quantitative Yes

Table 5 The comparison with CVSS and Khaled approaches

ComponentID

InitialCVSS base

score

Convertedsecurity score

of CVSS

Securitylevel ofQACS

The reportedempirical data(security level)

01 58 042 07569 B+

02 19 081 04406 Cminus

03 6 04 036 D+

04 7 03 09 A

05 36 064 085 Aminus

06 19 081 04437 Cminus

current paper proposes theQACS approach for quantitativelyassessing component security which is based on the interfacefault injection of the componentThe fault injection operatorsof the component vulnerability and PRED are defined anddiscussedThe assessment framework and algorithm for com-ponent security are proposed as wellThe testing effect provesexcellent in practical application QACS has the followingmain advantages (1) the security exceptional assessmentrules and vulnerability factors of the component are givenproviding the basis for security assessment (2) QACS canassess the security level of the third-party component andthe score of component security can be accurately calculated(3) QACS has better operability

Mathematical Problems in Engineering 11

Acknowledgments

We would like to thank Professor T Y Chen for his con-structive suggestions and valuable discussion in this paperwriting In addition this work was supported partly bythe National Natural Science Foundation of China (NSFC)under Grants no 61202110 and no 61063013 Natural ScienceFoundation of Jiangsu Province under Grant no BK2012284and the Research Fund for the Doctoral Program of HigherEducation of China under Grant no 20103227120005

References

[1] J Chen Y Lu and X D Xie ldquoComponent security testingapproach by using interface fault injectionrdquo Journal of ChineseComputer Systems vol 31 no 6 pp 1090ndash1096 2010

[2] S Gudder andRGreechie ldquoUniqueness and order in sequentialeffect algebrasrdquo International Journal of Theoretical Physics vol44 no 7 pp 755ndash770 2005

[3] I O Mkpong-Ruffin Quantitative risk assessment model forsoftware security in the design phase of software development[PhD thesis] Auburn University Auburn Ala USA 2009

[4] J Han and Y Zheng ldquoSecurity characterization and integrityassurance for component-based softwarerdquo in Proceedings of theInternational Conference on Software Methods and Tools (SMTrsquo00) pp 61ndash66 IEEE Computer SocietyWollongong Australia2000

[5] F Jabeen and M Jaffar-Ur Rehman ldquoA framework for objectoriented component testingrdquo in Proceedings of the IEEE Inter-national Conference on Emerging Technologies (ICET rsquo05) pp451ndash460 Islamabad Pakistan September 2005

[6] K Md Khan J Han and Y Zheng ldquoCharacterizing userdata protection of software componentsrdquo in Proceedings of theSoftware EngineeringConference pp 3ndash11 CanberraAustralian2000

[7] K M Khan and J Han ldquoA security characterisation frame-work for trustworthy component based software systemsrdquo inProceedings of the 27th Annual International Computer Softwareand Applications Conference (COMPSAC rsquo03) pp 164ndash169November 2003

[8] K M Khan and J Han ldquoAssessing security properties ofsoftware components a software engineerrsquos perspectiverdquo inProceedings of the Australian Software Engineering Conference(ASWEC rsquo06) pp 199ndash208 Sydney Australia April 2006

[9] K Khan J Han and Y Zheng ldquoA framework for an activeinterface to characterise compositional security contracts ofsoftware components rdquo in Proceedings of the Australian SoftwareEngineering Conference (ASWEC rsquo01) pp 117ndash126 2001

[10] ldquoCommon criteria projectISO Common criteria for informa-tion technology security evaluationrdquo version 21 (ISOIEC Inter-national Standard 15408) NIST USA and ISO Switzerland1999 httpcsrcnistgovcc

[11] O H Alhazmi and Y K Malaiya ldquoQuantitative vulnerabilityassessment of systems softwarerdquo in Proceedings of the AnnualReliability andMaintainability Symposium (RAMS rsquo05) pp 615ndash620 January 2005

[12] Y-K Zhang S-Y Jiang Y-A Cui B W Zhang and H Xia ldquoAqualitative and quantitative risk assessment method in softwaresecurityrdquo in Proceedings of the 3rd International Conference onAdvanced Computer Theory and Engineering (ICACTE rsquo10) ppV1534ndashV1539 Chengdu China August 2010

[13] X Tang and B Shen ldquoExtending model driven architecturewith software security assessmentrdquo in Proceedings of the 3rdIEEE International Conference on Secure Software IntegrationReliability Improvement (SSIRI rsquo09) pp 436ndash441 ShanghaiChina July 2009

[14] X Wang H Shi T Y W Huang and F C Lin ldquoIntegratedsoftware vulnerability and security functionality assessmentrdquoin Proceedings of the 18th IEEE International Symposium onSoftware Reliability Engineering (ISSRE rsquo07) pp 103ndash108 Troll-hattan Sweden November 2007

[15] K Goseva-Popstojanova and K S Trivedi ldquoArchitecture-basedapproach to reliability assessment of software systemsrdquo Perfor-mance Evaluation vol 45 no 2-3 pp 179ndash204 2001

[16] ldquoNVD Common Vulnerability Scoring System (CVSS)rdquohttpnvdnistgovcvsscfm

[17] Y Jiang G M Xin J-H Shan L Zhang B Xie and F-Q YangldquoMethod of automated test data generation for web servicerdquoChinese Journal of Computers vol 28 no 4 pp 568ndash577 2005

[18] M E Delamaro J C Maldonado and A P Mathur ldquoInterfacemutation an approach for integration testingrdquo IEEE Transac-tions on Software Engineering vol 27 no 3 pp 228ndash247 2001

[19] J M Voas and K W Miller ldquoPredicting softwarersquos minimum-time-to-hazard andmean-time-to-hazard for rare input eventsrdquoin Proceedings of the 6th International Symposium on SoftwareReliability Engineering pp 229ndash238 October 1995

[20] J Chen Y Lu andX Xie ldquoA fault injectionmodel of componentsecurity testingrdquo Computer Research and Development vol 46no 7 pp 1127ndash1135 2009

[21] J Chen Y LuW Zhang andXD Xie ldquoA fault injectionmodel-oriented testing strategy for component securityrdquo Journal ofCentral South University of Technology vol 16 no 2 pp 258ndash264 2009

[22] J Chen Y Lu X Xie et al ldquoDesign and implementation of anautomatic testing platform for component securityrdquo ComputerScience vol 35 no 12 pp 229ndash233 2008

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Mathematical Problems in Engineering 5

vulnerability assessment method of component is given thefollowing definitions should be introduced first

Definition 5 Let 119875 represent an 119873 times 119878 probability matrixthat can be described as 119875 = (119901

119894119895)119899times119904

row 119894 represents theinterface number of component 119862 and column 119895 representsthe method number of interface 119894 The element 119901

119894119895states

the executable probability for function 119895 at interface 119894 ofcomponent 119862 where 119901

119894119895= 119901119894times 119901119895

Definition 6 Interface method coverage (MC) where MC =

(the number of methods executed at least oncethe totalnumber methods 119878) times 100 is used to measure the sufficientdegree of the interface method during component testing

Definition 7 Interface coverage (IC) where IC = (the numberof interfaces executed at least oncethe total number interface119873) times 100 is used to measure the sufficient degree of theinterface test during component testing

Definition 8 Component test adequacy CA can be measuredby a two-tuple (ie MC and IC) Generally the value isdetermined by the total score of MC and IC that is CA =

[sum119894=1119873

(MC119894)]119873+IC A greater value of CA indicates amore

comprehensive test the relationship between MC and IC isparallel

Suppose Sum 119872 represents the number of test meth-ods cnt represents the number of vulnerability methods incomponent 119862 and VC

119894represents the vulnerability factors of

exceptional method The value of vulnerability factor VC119894is

assigned to 0 in case the interface method has no securityexceptions The execution probability of the vulnerabilitymethod 119894 is labeled 119875

119894 The component vulnerability assess-

ment formula is given as follows

Vul119888= 1 minus

cntprod119894=1

(1 minus 119875119894times VC119894) (1)

The value 1 minus Vul119888 the security level of the component

119862 can be derived from the Formula (1) The vulnerabilityassessment formula of the component has the followingproperties

Property 9 (0 le Vul119888le 1)

Proof For any vulnerability method 1 ge 119875119894ge 0 and 1 ge

VC119894ge 0 can be determined according to the definition of

VCTherefore 1 ge 119875119894timesVC119894ge 0 1 ge 1minus119875

119894timesVC119894ge 0 and 0 le

prodcnt119894=1(1 minus 119875

119894times VC119894) le 1 are derived that is 0 le Vul

119888le 1

Property 9 shows that the value of any componentrsquosvulnerability index is between 0 and 1 with a larger valueindicating a higher vulnerability index

Property 10 (Vul119888ge max(119875

119894times VC119894) ge 0)

Proof For any vulnerability method 1 ge 119875119894ge 0 and 1 ge

VC119894ge 0 can be determined according to the definition of VC

Therefore max(119875119894timesVC119894) ge 0 In addition 1 ge 1minus119875

119894timesVC119894ge 0

and 1minusVul119888= prod

cnt119894=1(1minus119875119894timesVC119894) can be derived fromFormula

(1)prodcnt119894=1(1 minus 119875

119894timesVC119894) = (1 minus 119875

1timesVC1) times (1 minus 119875

2timesVC2) times sdot sdot sdot

times (1 minus max(119875119894times VC119894)) times sdot sdot sdot times (1 minus 119875cnt times VCcnt) therefore

prodcnt119894=1(1 minus 119875

119894times VC119894) le (1 minus max(119875

119894times VC119894)) and 1 minus Vul

119888le

(1minusmax(119875119894timesVC119894)) are derived that is Vul

119888ge max(119875

119894timesVC119894)

Thus Vul119888ge max(119875

119894times VC119894) ge 0 can proved correct

Property 10 shows that the vulnerability index of any onecomponent is not less than the peak value of the methodsrsquovulnerability indexes of the component All situations ofthe vulnerability methods of component are syntheticallyconsidered by the index of the vulnerability of component

Based on the component vulnerable assessment methodbased on the analysis of the interface the algorithm of thecomponentrsquos security assessment level is given as follows

The input probability matrix 119875 in Algorithm 1 is not onlyderived from the component requirement specifications orequal probability but is also statistically calculated after thecomponent is practically executed The vulnerability factorVC119894119895is assigned to 0 given that the component has no security

exceptional interface method We usually set the value of120575 and 120579 from 0 to 1 according to the complexity of testedcomponent and the testing requirement If the number ofinterfaces and methods of tested component is no more than200 we usually let the value of 120575 and 120579 to be 1 to ensurea complete testing of COTS In addition the test cases ofinterface parameters are generated using the TGSM [20 21]algorithm First the test cases of the interface parameter fault-injection expressed in matrix form are generated in termsof fault injection operator The K-factor coverage solutionmatrix is generated by the TGSM algorithm which is basedon the parameter set of the matrix form The fault injectiontest cases are composed of row data of the solution matrixTest cases generated by the TGSM algorithm not only greatlyreduce the scale of the test cases but also have certaincoverage The algorithm can trigger most of the securityexceptions with fewer test cases

Cnt is the number of vulnerability methods of the com-ponent 119862 in the algorithm results Vul

119894119895is the vulnerability

ratio of the method 119895 at the interface 119894 of the component 119862Vul119888represents the vulnerability level of the component 119862

1 minus Vul119894119895 the security level of the component 119862 represents

the security of the method 119895 in the interface 119894 of component119862

5 Experiment Analysis

To validate the effectiveness of the proposed approachthe approach was implemented in our component securitytesting system (CSTS) platform [22]The component securitytesting and assessing system based on interface fault injection(CSTASboIFT) was implemented using C language in theMicrosoft NET platform It is used as a subsystem of theCSTS platform Figure 2 shows the function flow chart ofCSTASboIFT

In the experiment six commercial components (Table 2)in which security vulnerabilities exist were collected forexperimental analysis in the CVE Web site Several group

6 Mathematical Problems in Engineering

Input Interface information XML file Fault injection operator Prediction rules PREDProbability matrix 119875 MCrsquos threshold and ICrsquos threshold value 120575 and 120579Output The security level of the whole component01 02 Read XML file03 MC = 0 IC = 0 119894 = 0 cnt = 0 cnt is the number of component vulnerability methods04 While IC lt 120575 do For each interface 119894 in 11986805

06 119894 = 119894 + 1 119895 = 007 While MC lt 120579 do For each method119898 in119872

119894

08

09 119895 = 119895 + 1 119895 is the number of the testing methods10 Generate method parameter values set according to fault injection operators11 Call testing cases generating algorithm TGSM() call the generation algorithm of the

minimum 119870 factors combined cover test case based on solution matrix12 Running 119862 and119872

119894119895

13 If (the output after running 119862 and119872119894119895satisfies PRED)

14

15 increment cnt16 Vul

119894119895= VC

119894119895times 119875119894119895 the vulnerability level of the method 119895 in the interface 119894

17

18 MC = 11989511987819

20 IC = 11989411987321

22 Vul119888= 1 minus prod

cnt119894=1(1 minus 119875

119894times VC

119894)

23 (Output) 1 minus Vul119888

24

Algorithm 1 QACS (quantitative assessment of component security) algorithm

Tested component

Interface analysis

Component interface

Implement test cases

Fault injectionoperator

Compile driven execution

Dynamic monitor

Probabilitymatrix

Vulnerability factor value Probabilitymatrix

Security levelassessment report

information (XML file)

Monitor loginformation

Assessmentrule library119875

Figure 2 The function flow chart of CSTASboIFT

experiments were conducted for these components A com-ponent composed of six interfaces and each interface consist-ing of eight methods were assumed so that the componentcould be regarded as a 6 times 8 matrix The first group of

experiments tested the condition of 119875119894119895assigned to a fixed

matrix and VC119894119895divided into interval descending As VC

119894119895

changed the 1 minus Vul119888was affected That is only the level of

vulnerability factors affected the component security levelThe second group of experiments tested the condition ofVC119894119895assigned to a fixed matrix and 119875

119894119895divided into interval

descending As 119875119894119895changed 1 minus Vul

119888was affected That is

only the executed probability affected the component securitylevel The last group of experiments considered the effect on1minusVul

119888 as both vulnerability factor and executed probability

simultaneously changed

51 Experiment One Thevulnerability factor value is dividedinto intervals based on the knowledge of security vulner-ability provided by the CVE Web site 119875

119894119895represents the

executable probability of the method 119895 at the interface 119894VC119894119895represents the vulnerability factors of the method 119895 at

the interface 119894 and Vul119888represents the vulnerability level of

component 119862 1 minus Vul119888is the security level of component 119862

The first experiment assumes that 119875119894119895is a 6 times 8 fixed

matrix which is made up of random values For everyinterval 119875

119894119895is the same matrix VC

119894119895is divided into 10

intervals [000 009] [010 019] [020 029] [030 039][040 049] [050 059] [060 069] [070 079] [080 089]and [090 100] The tests were done about ten times withdifferent random values of 119875

119894119895and VC

119894119895 respectively in the

experiment and then the value 1minusVul119888was got by calculating

Mathematical Problems in Engineering 7

Table 2 The six typical tested components

Component ID Component name Component information01 ThunderAgent 005dll An ActiveX control in Thunder 5 Component version is 10011 Thunder version is 55225202 AcroPDFdll An AcroPDF ActiveX control in Adobe Reader and Acrobat Component version is 708003 GLItemComdll An ActiveX control in OURGAMEWORLD game software Component version is 270804 pdg2dll An ActiveX control in SUPERSTART READER software Component version is 390005 GomWeb3dll An ActiveX control in GOM Player GOM Player is a media player widely used in Korea06 Vulndll A third-party tested component Component version is 1012

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

VC119894

1minusVu

L 119888

(a) cnt = 5

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(b) cnt = 10

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(c) cnt = 15

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(d) cnt = 20

Figure 3 The comparison for different VC119894and cnt

the average result Under the condition that 119875119894119895is regarded as

a 6 times 8matrix at every interval of VC119894119895 VC119894119895affects the value

1 minus Vul119888

When Vul119894119895is equal to 119875

119894119895times VC119894119895 as 119875119894119895is a fixed value

the values of Vul119888and Vul

119894119895are proportional to the value of

VC119894119895 The value of 1 minus Vul

119888is reversely proportional to VC

119894119895

A larger VC119894119895value indicates a lower security level As the

vulnerability number increases the security level decreasesslowly The results are shown in Figure 3 The testing resultsshow that the proposed assessment Formula (1) is effective

52 Experiment Two VC119894119895is assumed a 6 times 8 fixed matrix

made up of random values in the second experiment Then119875119894119895

is divided into 10 intervals [000 009] [010 019][020 029] [030 039] [040 049] [050 059] [060 069][070 079] [080 089] and [090 100] The tests were doneabout ten times with different random values of 119875

119894119895and VC

119894119895

respectively in the experiment and then the value 1minusVul119888was

got by calculating the average result Under the condition thatVC119894119895is regarded as a 6 times 8 matrix at every interval of 119875

119894119895 119875119894119895

affects the value of 1 minus Vul119888

When VuL119894119895is equal to 119875

119894119895times VC119894119895 as the value of VC

119894119895

is fixed the values of Vul119888and VuL

119894119895are proportional to the

value of 119875119894119895 The value of 1 minus Vul

119888is reversely proportional

to VC119894119895 A larger 119875

119894119895value indicates a lower security level

That is the component is more insecure As the number ofcnt increases the decline rate of the security level is initiallyfast and then becomes slow The results as presented inFigure 4 show that the proposed assessment Formula (1) iseffective

53 Experiment Three Both parameters 119875119894and VC

119894are

assumed to influence the value of 1 minus Vul119888in Experiment

three The two parameters are randomly divided into 10

8 Mathematical Problems in Engineering

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(a) cnt = 5

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(b) cnt = 10

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(c) cnt = 15

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(d) cnt = 20

Figure 4 The comparison for different 119875119894and cnt

intervals The effect on the value of 1 minus VuL119888when the

two parameters changed simultaneously was observed Theresults show that when 119875

119894is proportional to VC

119894 the value

of 1 minus Vul119888changes significantly as shown in (a) and (b)

of Figure 5 When 119875119894is inversely proportional to VC

119894 the

value of 1 minus Vul119888changes indistinctly as shown in (c) and

(d) of Figure 5 As the vulnerability number cnt increasesthe security level decreases Results are shown in Figure 5The values of 119875

119894and VC

119894are based on the main 119910-axis values

(the left axis) and the value of the 1 minus Vul119888is based on the

secondary 119910-axis values (the right axis) The testing resultsshow that the proposed assessment Formula (1) is suitable forassessing the COTS component

54 Experiment Four The components were assessed inTable 3 based on Algorithm 1 The value of IC and MC is setto 1 119875

119894can be determined by executing the tested component

100 times or moreDuring the system testing process the test cases of fault

injection can be implemented by testing the componentinformation and fault injection operators The testing statecan be recorded through the dynamic monitoring mecha-nism after running the tested component The vulnerabilitytype of the componentmethod and vulnerability factor can bederived from comparing the testing state with the componentinformation record in PRED The execution probability 119875

119894

of each method in the component can be determined byrunning the tested component 100 times respectively Thenthe component security level can be determined using For-mula (1)The testing results are shown in Table 3 Because dif-ferent components have different method parameters whichhave different parameter types such as integer string andboolean we select suitable fault injection factors to test thecomponent security based on the above presented 18 faultinjection operators of component in Table 3

A higher level of security indicates better relative securityof the component The component is secure if and only ifthe component security level is 1 Otherwise it has securityvulnerability In contrast to the test results in Table 3 the levelof security is closer to the vulnerability information publishedin the CVE Web site The values of execution probabilityand vulnerability factors have been proved to affect thecomponent security The results agree with the previousexperimental results further confirming the feasibility andeffectiveness of this approach

55 Experimental Comparison Table 4 shows the compar-ison with other assessment approaches The related assess-ment approaches have various merits as shown in theanalysis of Table 4 Our QACS approach mainly focuseson quantitatively assessing the security level of the COTScomponent The source codes of the COTS component are

Mathematical Problems in Engineering 9

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(a) cnt = 5

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(b) cnt = 10

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(c) cnt = 15

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(d) cnt = 20

Figure 5 The comparison for different 119875119894 VC119894 and cnt

generally unknownThe internal factors of the component areconsidered in QACSThe QACS approach is implemented inthe CSTASboIFT that is integrated into our CSTS [22] systemdeveloped to test the security of the COTS component

Aside from the above-mentioned approaches CVSS is awidely used quantitative assessment approach for softwarecomponent Khan and Han developed an assessment schemefor the security properties of software components Theassessment scheme provided a numeric score that indicatesthe relative strength of the security properties of the compo-nent [8] Results of the comparison with the CVSS approachand Khaled approach are shown in Table 5 In addition thesecurity level of six tested components is also listed accordingto the reported empirical data of securityWeb sites in Table 5The initial CVSSBase Score is calculated by theCVSS formula[16]

Analyzing Table 5 the QACS approach is found to beclose to the empirical data reported on some security Websites regarding the security of the tested COTS componentsThe security score of the QACS approach is more accuratethan that of others because the internal factors of the tested

component are considered The assessment process of theQACS approach is objective without human interventionNevertheless the CVSS approach ismainly focused on assess-ing the vulnerability of the general software componentIf an assessor is not familiar with the assessed softwarethe vulnerability score becomes inaccurate because of theassessorrsquos subjectivity in the assessment process On the otherhand the Khaled approach is an approximate assessmentapproach based on the assumed component environment Inaddition presently there are no more effective assessmentapproaches for the security level of software componentaccording to our studies

6 Conclusion

In component-based software development andmaintenanceactivities the assessment of the component reliability andsecurity level is essential in the third-party componentResearch on an effective quantitative assessment methodfor component security level is valuable in the CBSE The

10 Mathematical Problems in Engineering

Table 3 Testing results for six tested components

ID Fault injectionfactor

The number ofvulnerabilities and its 119875

119894

Test result Security level

01 IIV 2(013 013)

ThunderAgent 005dll has two methods calling(GetInfoStruct() GetTaskInfoStruc()) neglected the inputparameter exception and generated security vulnerability Thenthey resulted in program breakdown

07569

02 CIV LSV RSV 5(01 02 01 015 02)

AcroPDFdll did not correctly deal with the string parameterssent to function setPageMode() LoadFile() setLayoutMode()and setNamedDest() and the attribute src It triggered memorydestroyed and resulted in security vulnerability for executingany instruction

04406

03 LSV RSV FSV 1(064)

The function SetInfo() of GLItemComDLL ActiveX overtrusted user input and did not check parameterrsquos length Itresulted in the point the virtual function covered

036

04 LSV RSV FSV 1(01)

Pdg2dll did not deal with the sent parameter to Register () ifuser sends the string over 256 bytes it can trigger stack overflowand execute any code

09

05 LSV RSV USV 1(015)

GomManager object did not collectively deal with the firstparameter of OpenURL() in IGomManager interface Iftransmitting the long parameters over 500 bytes it can triggerstack overflow to result in visiting the memory exception

085

06 PSN CIV PIVLSV USV

5(015 015 015 015 015)

5 methods of component existed security exception The testcase parameters implemented by input fault injection operatorwould result in buffer overflow visiting beyond the scope andmemory leakage

04437

Table 4 The comparison with related assessment approaches

Assessment approach Assessment object Assessment aspect Is the internalfactor considered

Qualitative orquantitative

Is there supportingtool

Khan and Han [8] Software component Security No Quantitative NoAlhazmi and Malaiya[11] Operating system Vulnerability Yes Quantitative No

Zhang et al [12] Software system Risk No Quantitativequalitative

No

Goseva-Popstojanovaand Trivedi [15] Software system Reliability No Quantitative No

Mkpong-Ruffin [3] Software Risk No Quantitative Yes

CVSS [16] Software component Vulnerability No Quantitative Yes

QACS COTS component Security Yes Quantitative Yes

Table 5 The comparison with CVSS and Khaled approaches

ComponentID

InitialCVSS base

score

Convertedsecurity score

of CVSS

Securitylevel ofQACS

The reportedempirical data(security level)

01 58 042 07569 B+

02 19 081 04406 Cminus

03 6 04 036 D+

04 7 03 09 A

05 36 064 085 Aminus

06 19 081 04437 Cminus

current paper proposes theQACS approach for quantitativelyassessing component security which is based on the interfacefault injection of the componentThe fault injection operatorsof the component vulnerability and PRED are defined anddiscussedThe assessment framework and algorithm for com-ponent security are proposed as wellThe testing effect provesexcellent in practical application QACS has the followingmain advantages (1) the security exceptional assessmentrules and vulnerability factors of the component are givenproviding the basis for security assessment (2) QACS canassess the security level of the third-party component andthe score of component security can be accurately calculated(3) QACS has better operability

Mathematical Problems in Engineering 11

Acknowledgments

We would like to thank Professor T Y Chen for his con-structive suggestions and valuable discussion in this paperwriting In addition this work was supported partly bythe National Natural Science Foundation of China (NSFC)under Grants no 61202110 and no 61063013 Natural ScienceFoundation of Jiangsu Province under Grant no BK2012284and the Research Fund for the Doctoral Program of HigherEducation of China under Grant no 20103227120005

References

[1] J Chen Y Lu and X D Xie ldquoComponent security testingapproach by using interface fault injectionrdquo Journal of ChineseComputer Systems vol 31 no 6 pp 1090ndash1096 2010

[2] S Gudder andRGreechie ldquoUniqueness and order in sequentialeffect algebrasrdquo International Journal of Theoretical Physics vol44 no 7 pp 755ndash770 2005

[3] I O Mkpong-Ruffin Quantitative risk assessment model forsoftware security in the design phase of software development[PhD thesis] Auburn University Auburn Ala USA 2009

[4] J Han and Y Zheng ldquoSecurity characterization and integrityassurance for component-based softwarerdquo in Proceedings of theInternational Conference on Software Methods and Tools (SMTrsquo00) pp 61ndash66 IEEE Computer SocietyWollongong Australia2000

[5] F Jabeen and M Jaffar-Ur Rehman ldquoA framework for objectoriented component testingrdquo in Proceedings of the IEEE Inter-national Conference on Emerging Technologies (ICET rsquo05) pp451ndash460 Islamabad Pakistan September 2005

[6] K Md Khan J Han and Y Zheng ldquoCharacterizing userdata protection of software componentsrdquo in Proceedings of theSoftware EngineeringConference pp 3ndash11 CanberraAustralian2000

[7] K M Khan and J Han ldquoA security characterisation frame-work for trustworthy component based software systemsrdquo inProceedings of the 27th Annual International Computer Softwareand Applications Conference (COMPSAC rsquo03) pp 164ndash169November 2003

[8] K M Khan and J Han ldquoAssessing security properties ofsoftware components a software engineerrsquos perspectiverdquo inProceedings of the Australian Software Engineering Conference(ASWEC rsquo06) pp 199ndash208 Sydney Australia April 2006

[9] K Khan J Han and Y Zheng ldquoA framework for an activeinterface to characterise compositional security contracts ofsoftware components rdquo in Proceedings of the Australian SoftwareEngineering Conference (ASWEC rsquo01) pp 117ndash126 2001

[10] ldquoCommon criteria projectISO Common criteria for informa-tion technology security evaluationrdquo version 21 (ISOIEC Inter-national Standard 15408) NIST USA and ISO Switzerland1999 httpcsrcnistgovcc

[11] O H Alhazmi and Y K Malaiya ldquoQuantitative vulnerabilityassessment of systems softwarerdquo in Proceedings of the AnnualReliability andMaintainability Symposium (RAMS rsquo05) pp 615ndash620 January 2005

[12] Y-K Zhang S-Y Jiang Y-A Cui B W Zhang and H Xia ldquoAqualitative and quantitative risk assessment method in softwaresecurityrdquo in Proceedings of the 3rd International Conference onAdvanced Computer Theory and Engineering (ICACTE rsquo10) ppV1534ndashV1539 Chengdu China August 2010

[13] X Tang and B Shen ldquoExtending model driven architecturewith software security assessmentrdquo in Proceedings of the 3rdIEEE International Conference on Secure Software IntegrationReliability Improvement (SSIRI rsquo09) pp 436ndash441 ShanghaiChina July 2009

[14] X Wang H Shi T Y W Huang and F C Lin ldquoIntegratedsoftware vulnerability and security functionality assessmentrdquoin Proceedings of the 18th IEEE International Symposium onSoftware Reliability Engineering (ISSRE rsquo07) pp 103ndash108 Troll-hattan Sweden November 2007

[15] K Goseva-Popstojanova and K S Trivedi ldquoArchitecture-basedapproach to reliability assessment of software systemsrdquo Perfor-mance Evaluation vol 45 no 2-3 pp 179ndash204 2001

[16] ldquoNVD Common Vulnerability Scoring System (CVSS)rdquohttpnvdnistgovcvsscfm

[17] Y Jiang G M Xin J-H Shan L Zhang B Xie and F-Q YangldquoMethod of automated test data generation for web servicerdquoChinese Journal of Computers vol 28 no 4 pp 568ndash577 2005

[18] M E Delamaro J C Maldonado and A P Mathur ldquoInterfacemutation an approach for integration testingrdquo IEEE Transac-tions on Software Engineering vol 27 no 3 pp 228ndash247 2001

[19] J M Voas and K W Miller ldquoPredicting softwarersquos minimum-time-to-hazard andmean-time-to-hazard for rare input eventsrdquoin Proceedings of the 6th International Symposium on SoftwareReliability Engineering pp 229ndash238 October 1995

[20] J Chen Y Lu andX Xie ldquoA fault injectionmodel of componentsecurity testingrdquo Computer Research and Development vol 46no 7 pp 1127ndash1135 2009

[21] J Chen Y LuW Zhang andXD Xie ldquoA fault injectionmodel-oriented testing strategy for component securityrdquo Journal ofCentral South University of Technology vol 16 no 2 pp 258ndash264 2009

[22] J Chen Y Lu X Xie et al ldquoDesign and implementation of anautomatic testing platform for component securityrdquo ComputerScience vol 35 no 12 pp 229ndash233 2008

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

6 Mathematical Problems in Engineering

Input Interface information XML file Fault injection operator Prediction rules PREDProbability matrix 119875 MCrsquos threshold and ICrsquos threshold value 120575 and 120579Output The security level of the whole component01 02 Read XML file03 MC = 0 IC = 0 119894 = 0 cnt = 0 cnt is the number of component vulnerability methods04 While IC lt 120575 do For each interface 119894 in 11986805

06 119894 = 119894 + 1 119895 = 007 While MC lt 120579 do For each method119898 in119872

119894

08

09 119895 = 119895 + 1 119895 is the number of the testing methods10 Generate method parameter values set according to fault injection operators11 Call testing cases generating algorithm TGSM() call the generation algorithm of the

minimum 119870 factors combined cover test case based on solution matrix12 Running 119862 and119872

119894119895

13 If (the output after running 119862 and119872119894119895satisfies PRED)

14

15 increment cnt16 Vul

119894119895= VC

119894119895times 119875119894119895 the vulnerability level of the method 119895 in the interface 119894

17

18 MC = 11989511987819

20 IC = 11989411987321

22 Vul119888= 1 minus prod

cnt119894=1(1 minus 119875

119894times VC

119894)

23 (Output) 1 minus Vul119888

24

Algorithm 1 QACS (quantitative assessment of component security) algorithm

Tested component

Interface analysis

Component interface

Implement test cases

Fault injectionoperator

Compile driven execution

Dynamic monitor

Probabilitymatrix

Vulnerability factor value Probabilitymatrix

Security levelassessment report

information (XML file)

Monitor loginformation

Assessmentrule library119875

Figure 2 The function flow chart of CSTASboIFT

experiments were conducted for these components A com-ponent composed of six interfaces and each interface consist-ing of eight methods were assumed so that the componentcould be regarded as a 6 times 8 matrix The first group of

experiments tested the condition of 119875119894119895assigned to a fixed

matrix and VC119894119895divided into interval descending As VC

119894119895

changed the 1 minus Vul119888was affected That is only the level of

vulnerability factors affected the component security levelThe second group of experiments tested the condition ofVC119894119895assigned to a fixed matrix and 119875

119894119895divided into interval

descending As 119875119894119895changed 1 minus Vul

119888was affected That is

only the executed probability affected the component securitylevel The last group of experiments considered the effect on1minusVul

119888 as both vulnerability factor and executed probability

simultaneously changed

51 Experiment One Thevulnerability factor value is dividedinto intervals based on the knowledge of security vulner-ability provided by the CVE Web site 119875

119894119895represents the

executable probability of the method 119895 at the interface 119894VC119894119895represents the vulnerability factors of the method 119895 at

the interface 119894 and Vul119888represents the vulnerability level of

component 119862 1 minus Vul119888is the security level of component 119862

The first experiment assumes that 119875119894119895is a 6 times 8 fixed

matrix which is made up of random values For everyinterval 119875

119894119895is the same matrix VC

119894119895is divided into 10

intervals [000 009] [010 019] [020 029] [030 039][040 049] [050 059] [060 069] [070 079] [080 089]and [090 100] The tests were done about ten times withdifferent random values of 119875

119894119895and VC

119894119895 respectively in the

experiment and then the value 1minusVul119888was got by calculating

Mathematical Problems in Engineering 7

Table 2 The six typical tested components

Component ID Component name Component information01 ThunderAgent 005dll An ActiveX control in Thunder 5 Component version is 10011 Thunder version is 55225202 AcroPDFdll An AcroPDF ActiveX control in Adobe Reader and Acrobat Component version is 708003 GLItemComdll An ActiveX control in OURGAMEWORLD game software Component version is 270804 pdg2dll An ActiveX control in SUPERSTART READER software Component version is 390005 GomWeb3dll An ActiveX control in GOM Player GOM Player is a media player widely used in Korea06 Vulndll A third-party tested component Component version is 1012

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

VC119894

1minusVu

L 119888

(a) cnt = 5

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(b) cnt = 10

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(c) cnt = 15

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(d) cnt = 20

Figure 3 The comparison for different VC119894and cnt

the average result Under the condition that 119875119894119895is regarded as

a 6 times 8matrix at every interval of VC119894119895 VC119894119895affects the value

1 minus Vul119888

When Vul119894119895is equal to 119875

119894119895times VC119894119895 as 119875119894119895is a fixed value

the values of Vul119888and Vul

119894119895are proportional to the value of

VC119894119895 The value of 1 minus Vul

119888is reversely proportional to VC

119894119895

A larger VC119894119895value indicates a lower security level As the

vulnerability number increases the security level decreasesslowly The results are shown in Figure 3 The testing resultsshow that the proposed assessment Formula (1) is effective

52 Experiment Two VC119894119895is assumed a 6 times 8 fixed matrix

made up of random values in the second experiment Then119875119894119895

is divided into 10 intervals [000 009] [010 019][020 029] [030 039] [040 049] [050 059] [060 069][070 079] [080 089] and [090 100] The tests were doneabout ten times with different random values of 119875

119894119895and VC

119894119895

respectively in the experiment and then the value 1minusVul119888was

got by calculating the average result Under the condition thatVC119894119895is regarded as a 6 times 8 matrix at every interval of 119875

119894119895 119875119894119895

affects the value of 1 minus Vul119888

When VuL119894119895is equal to 119875

119894119895times VC119894119895 as the value of VC

119894119895

is fixed the values of Vul119888and VuL

119894119895are proportional to the

value of 119875119894119895 The value of 1 minus Vul

119888is reversely proportional

to VC119894119895 A larger 119875

119894119895value indicates a lower security level

That is the component is more insecure As the number ofcnt increases the decline rate of the security level is initiallyfast and then becomes slow The results as presented inFigure 4 show that the proposed assessment Formula (1) iseffective

53 Experiment Three Both parameters 119875119894and VC

119894are

assumed to influence the value of 1 minus Vul119888in Experiment

three The two parameters are randomly divided into 10

8 Mathematical Problems in Engineering

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(a) cnt = 5

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(b) cnt = 10

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(c) cnt = 15

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(d) cnt = 20

Figure 4 The comparison for different 119875119894and cnt

intervals The effect on the value of 1 minus VuL119888when the

two parameters changed simultaneously was observed Theresults show that when 119875

119894is proportional to VC

119894 the value

of 1 minus Vul119888changes significantly as shown in (a) and (b)

of Figure 5 When 119875119894is inversely proportional to VC

119894 the

value of 1 minus Vul119888changes indistinctly as shown in (c) and

(d) of Figure 5 As the vulnerability number cnt increasesthe security level decreases Results are shown in Figure 5The values of 119875

119894and VC

119894are based on the main 119910-axis values

(the left axis) and the value of the 1 minus Vul119888is based on the

secondary 119910-axis values (the right axis) The testing resultsshow that the proposed assessment Formula (1) is suitable forassessing the COTS component

54 Experiment Four The components were assessed inTable 3 based on Algorithm 1 The value of IC and MC is setto 1 119875

119894can be determined by executing the tested component

100 times or moreDuring the system testing process the test cases of fault

injection can be implemented by testing the componentinformation and fault injection operators The testing statecan be recorded through the dynamic monitoring mecha-nism after running the tested component The vulnerabilitytype of the componentmethod and vulnerability factor can bederived from comparing the testing state with the componentinformation record in PRED The execution probability 119875

119894

of each method in the component can be determined byrunning the tested component 100 times respectively Thenthe component security level can be determined using For-mula (1)The testing results are shown in Table 3 Because dif-ferent components have different method parameters whichhave different parameter types such as integer string andboolean we select suitable fault injection factors to test thecomponent security based on the above presented 18 faultinjection operators of component in Table 3

A higher level of security indicates better relative securityof the component The component is secure if and only ifthe component security level is 1 Otherwise it has securityvulnerability In contrast to the test results in Table 3 the levelof security is closer to the vulnerability information publishedin the CVE Web site The values of execution probabilityand vulnerability factors have been proved to affect thecomponent security The results agree with the previousexperimental results further confirming the feasibility andeffectiveness of this approach

55 Experimental Comparison Table 4 shows the compar-ison with other assessment approaches The related assess-ment approaches have various merits as shown in theanalysis of Table 4 Our QACS approach mainly focuseson quantitatively assessing the security level of the COTScomponent The source codes of the COTS component are

Mathematical Problems in Engineering 9

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(a) cnt = 5

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(b) cnt = 10

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(c) cnt = 15

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(d) cnt = 20

Figure 5 The comparison for different 119875119894 VC119894 and cnt

generally unknownThe internal factors of the component areconsidered in QACSThe QACS approach is implemented inthe CSTASboIFT that is integrated into our CSTS [22] systemdeveloped to test the security of the COTS component

Aside from the above-mentioned approaches CVSS is awidely used quantitative assessment approach for softwarecomponent Khan and Han developed an assessment schemefor the security properties of software components Theassessment scheme provided a numeric score that indicatesthe relative strength of the security properties of the compo-nent [8] Results of the comparison with the CVSS approachand Khaled approach are shown in Table 5 In addition thesecurity level of six tested components is also listed accordingto the reported empirical data of securityWeb sites in Table 5The initial CVSSBase Score is calculated by theCVSS formula[16]

Analyzing Table 5 the QACS approach is found to beclose to the empirical data reported on some security Websites regarding the security of the tested COTS componentsThe security score of the QACS approach is more accuratethan that of others because the internal factors of the tested

component are considered The assessment process of theQACS approach is objective without human interventionNevertheless the CVSS approach ismainly focused on assess-ing the vulnerability of the general software componentIf an assessor is not familiar with the assessed softwarethe vulnerability score becomes inaccurate because of theassessorrsquos subjectivity in the assessment process On the otherhand the Khaled approach is an approximate assessmentapproach based on the assumed component environment Inaddition presently there are no more effective assessmentapproaches for the security level of software componentaccording to our studies

6 Conclusion

In component-based software development andmaintenanceactivities the assessment of the component reliability andsecurity level is essential in the third-party componentResearch on an effective quantitative assessment methodfor component security level is valuable in the CBSE The

10 Mathematical Problems in Engineering

Table 3 Testing results for six tested components

ID Fault injectionfactor

The number ofvulnerabilities and its 119875

119894

Test result Security level

01 IIV 2(013 013)

ThunderAgent 005dll has two methods calling(GetInfoStruct() GetTaskInfoStruc()) neglected the inputparameter exception and generated security vulnerability Thenthey resulted in program breakdown

07569

02 CIV LSV RSV 5(01 02 01 015 02)

AcroPDFdll did not correctly deal with the string parameterssent to function setPageMode() LoadFile() setLayoutMode()and setNamedDest() and the attribute src It triggered memorydestroyed and resulted in security vulnerability for executingany instruction

04406

03 LSV RSV FSV 1(064)

The function SetInfo() of GLItemComDLL ActiveX overtrusted user input and did not check parameterrsquos length Itresulted in the point the virtual function covered

036

04 LSV RSV FSV 1(01)

Pdg2dll did not deal with the sent parameter to Register () ifuser sends the string over 256 bytes it can trigger stack overflowand execute any code

09

05 LSV RSV USV 1(015)

GomManager object did not collectively deal with the firstparameter of OpenURL() in IGomManager interface Iftransmitting the long parameters over 500 bytes it can triggerstack overflow to result in visiting the memory exception

085

06 PSN CIV PIVLSV USV

5(015 015 015 015 015)

5 methods of component existed security exception The testcase parameters implemented by input fault injection operatorwould result in buffer overflow visiting beyond the scope andmemory leakage

04437

Table 4 The comparison with related assessment approaches

Assessment approach Assessment object Assessment aspect Is the internalfactor considered

Qualitative orquantitative

Is there supportingtool

Khan and Han [8] Software component Security No Quantitative NoAlhazmi and Malaiya[11] Operating system Vulnerability Yes Quantitative No

Zhang et al [12] Software system Risk No Quantitativequalitative

No

Goseva-Popstojanovaand Trivedi [15] Software system Reliability No Quantitative No

Mkpong-Ruffin [3] Software Risk No Quantitative Yes

CVSS [16] Software component Vulnerability No Quantitative Yes

QACS COTS component Security Yes Quantitative Yes

Table 5 The comparison with CVSS and Khaled approaches

ComponentID

InitialCVSS base

score

Convertedsecurity score

of CVSS

Securitylevel ofQACS

The reportedempirical data(security level)

01 58 042 07569 B+

02 19 081 04406 Cminus

03 6 04 036 D+

04 7 03 09 A

05 36 064 085 Aminus

06 19 081 04437 Cminus

current paper proposes theQACS approach for quantitativelyassessing component security which is based on the interfacefault injection of the componentThe fault injection operatorsof the component vulnerability and PRED are defined anddiscussedThe assessment framework and algorithm for com-ponent security are proposed as wellThe testing effect provesexcellent in practical application QACS has the followingmain advantages (1) the security exceptional assessmentrules and vulnerability factors of the component are givenproviding the basis for security assessment (2) QACS canassess the security level of the third-party component andthe score of component security can be accurately calculated(3) QACS has better operability

Mathematical Problems in Engineering 11

Acknowledgments

We would like to thank Professor T Y Chen for his con-structive suggestions and valuable discussion in this paperwriting In addition this work was supported partly bythe National Natural Science Foundation of China (NSFC)under Grants no 61202110 and no 61063013 Natural ScienceFoundation of Jiangsu Province under Grant no BK2012284and the Research Fund for the Doctoral Program of HigherEducation of China under Grant no 20103227120005

References

[1] J Chen Y Lu and X D Xie ldquoComponent security testingapproach by using interface fault injectionrdquo Journal of ChineseComputer Systems vol 31 no 6 pp 1090ndash1096 2010

[2] S Gudder andRGreechie ldquoUniqueness and order in sequentialeffect algebrasrdquo International Journal of Theoretical Physics vol44 no 7 pp 755ndash770 2005

[3] I O Mkpong-Ruffin Quantitative risk assessment model forsoftware security in the design phase of software development[PhD thesis] Auburn University Auburn Ala USA 2009

[4] J Han and Y Zheng ldquoSecurity characterization and integrityassurance for component-based softwarerdquo in Proceedings of theInternational Conference on Software Methods and Tools (SMTrsquo00) pp 61ndash66 IEEE Computer SocietyWollongong Australia2000

[5] F Jabeen and M Jaffar-Ur Rehman ldquoA framework for objectoriented component testingrdquo in Proceedings of the IEEE Inter-national Conference on Emerging Technologies (ICET rsquo05) pp451ndash460 Islamabad Pakistan September 2005

[6] K Md Khan J Han and Y Zheng ldquoCharacterizing userdata protection of software componentsrdquo in Proceedings of theSoftware EngineeringConference pp 3ndash11 CanberraAustralian2000

[7] K M Khan and J Han ldquoA security characterisation frame-work for trustworthy component based software systemsrdquo inProceedings of the 27th Annual International Computer Softwareand Applications Conference (COMPSAC rsquo03) pp 164ndash169November 2003

[8] K M Khan and J Han ldquoAssessing security properties ofsoftware components a software engineerrsquos perspectiverdquo inProceedings of the Australian Software Engineering Conference(ASWEC rsquo06) pp 199ndash208 Sydney Australia April 2006

[9] K Khan J Han and Y Zheng ldquoA framework for an activeinterface to characterise compositional security contracts ofsoftware components rdquo in Proceedings of the Australian SoftwareEngineering Conference (ASWEC rsquo01) pp 117ndash126 2001

[10] ldquoCommon criteria projectISO Common criteria for informa-tion technology security evaluationrdquo version 21 (ISOIEC Inter-national Standard 15408) NIST USA and ISO Switzerland1999 httpcsrcnistgovcc

[11] O H Alhazmi and Y K Malaiya ldquoQuantitative vulnerabilityassessment of systems softwarerdquo in Proceedings of the AnnualReliability andMaintainability Symposium (RAMS rsquo05) pp 615ndash620 January 2005

[12] Y-K Zhang S-Y Jiang Y-A Cui B W Zhang and H Xia ldquoAqualitative and quantitative risk assessment method in softwaresecurityrdquo in Proceedings of the 3rd International Conference onAdvanced Computer Theory and Engineering (ICACTE rsquo10) ppV1534ndashV1539 Chengdu China August 2010

[13] X Tang and B Shen ldquoExtending model driven architecturewith software security assessmentrdquo in Proceedings of the 3rdIEEE International Conference on Secure Software IntegrationReliability Improvement (SSIRI rsquo09) pp 436ndash441 ShanghaiChina July 2009

[14] X Wang H Shi T Y W Huang and F C Lin ldquoIntegratedsoftware vulnerability and security functionality assessmentrdquoin Proceedings of the 18th IEEE International Symposium onSoftware Reliability Engineering (ISSRE rsquo07) pp 103ndash108 Troll-hattan Sweden November 2007

[15] K Goseva-Popstojanova and K S Trivedi ldquoArchitecture-basedapproach to reliability assessment of software systemsrdquo Perfor-mance Evaluation vol 45 no 2-3 pp 179ndash204 2001

[16] ldquoNVD Common Vulnerability Scoring System (CVSS)rdquohttpnvdnistgovcvsscfm

[17] Y Jiang G M Xin J-H Shan L Zhang B Xie and F-Q YangldquoMethod of automated test data generation for web servicerdquoChinese Journal of Computers vol 28 no 4 pp 568ndash577 2005

[18] M E Delamaro J C Maldonado and A P Mathur ldquoInterfacemutation an approach for integration testingrdquo IEEE Transac-tions on Software Engineering vol 27 no 3 pp 228ndash247 2001

[19] J M Voas and K W Miller ldquoPredicting softwarersquos minimum-time-to-hazard andmean-time-to-hazard for rare input eventsrdquoin Proceedings of the 6th International Symposium on SoftwareReliability Engineering pp 229ndash238 October 1995

[20] J Chen Y Lu andX Xie ldquoA fault injectionmodel of componentsecurity testingrdquo Computer Research and Development vol 46no 7 pp 1127ndash1135 2009

[21] J Chen Y LuW Zhang andXD Xie ldquoA fault injectionmodel-oriented testing strategy for component securityrdquo Journal ofCentral South University of Technology vol 16 no 2 pp 258ndash264 2009

[22] J Chen Y Lu X Xie et al ldquoDesign and implementation of anautomatic testing platform for component securityrdquo ComputerScience vol 35 no 12 pp 229ndash233 2008

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Mathematical Problems in Engineering 7

Table 2 The six typical tested components

Component ID Component name Component information01 ThunderAgent 005dll An ActiveX control in Thunder 5 Component version is 10011 Thunder version is 55225202 AcroPDFdll An AcroPDF ActiveX control in Adobe Reader and Acrobat Component version is 708003 GLItemComdll An ActiveX control in OURGAMEWORLD game software Component version is 270804 pdg2dll An ActiveX control in SUPERSTART READER software Component version is 390005 GomWeb3dll An ActiveX control in GOM Player GOM Player is a media player widely used in Korea06 Vulndll A third-party tested component Component version is 1012

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

VC119894

1minusVu

L 119888

(a) cnt = 5

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(b) cnt = 10

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(c) cnt = 15

10 01 02 03 04 05 06 07 08 090

0102030405060708091

VC119894

1minusVu

L 119888

(d) cnt = 20

Figure 3 The comparison for different VC119894and cnt

the average result Under the condition that 119875119894119895is regarded as

a 6 times 8matrix at every interval of VC119894119895 VC119894119895affects the value

1 minus Vul119888

When Vul119894119895is equal to 119875

119894119895times VC119894119895 as 119875119894119895is a fixed value

the values of Vul119888and Vul

119894119895are proportional to the value of

VC119894119895 The value of 1 minus Vul

119888is reversely proportional to VC

119894119895

A larger VC119894119895value indicates a lower security level As the

vulnerability number increases the security level decreasesslowly The results are shown in Figure 3 The testing resultsshow that the proposed assessment Formula (1) is effective

52 Experiment Two VC119894119895is assumed a 6 times 8 fixed matrix

made up of random values in the second experiment Then119875119894119895

is divided into 10 intervals [000 009] [010 019][020 029] [030 039] [040 049] [050 059] [060 069][070 079] [080 089] and [090 100] The tests were doneabout ten times with different random values of 119875

119894119895and VC

119894119895

respectively in the experiment and then the value 1minusVul119888was

got by calculating the average result Under the condition thatVC119894119895is regarded as a 6 times 8 matrix at every interval of 119875

119894119895 119875119894119895

affects the value of 1 minus Vul119888

When VuL119894119895is equal to 119875

119894119895times VC119894119895 as the value of VC

119894119895

is fixed the values of Vul119888and VuL

119894119895are proportional to the

value of 119875119894119895 The value of 1 minus Vul

119888is reversely proportional

to VC119894119895 A larger 119875

119894119895value indicates a lower security level

That is the component is more insecure As the number ofcnt increases the decline rate of the security level is initiallyfast and then becomes slow The results as presented inFigure 4 show that the proposed assessment Formula (1) iseffective

53 Experiment Three Both parameters 119875119894and VC

119894are

assumed to influence the value of 1 minus Vul119888in Experiment

three The two parameters are randomly divided into 10

8 Mathematical Problems in Engineering

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(a) cnt = 5

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(b) cnt = 10

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(c) cnt = 15

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(d) cnt = 20

Figure 4 The comparison for different 119875119894and cnt

intervals The effect on the value of 1 minus VuL119888when the

two parameters changed simultaneously was observed Theresults show that when 119875

119894is proportional to VC

119894 the value

of 1 minus Vul119888changes significantly as shown in (a) and (b)

of Figure 5 When 119875119894is inversely proportional to VC

119894 the

value of 1 minus Vul119888changes indistinctly as shown in (c) and

(d) of Figure 5 As the vulnerability number cnt increasesthe security level decreases Results are shown in Figure 5The values of 119875

119894and VC

119894are based on the main 119910-axis values

(the left axis) and the value of the 1 minus Vul119888is based on the

secondary 119910-axis values (the right axis) The testing resultsshow that the proposed assessment Formula (1) is suitable forassessing the COTS component

54 Experiment Four The components were assessed inTable 3 based on Algorithm 1 The value of IC and MC is setto 1 119875

119894can be determined by executing the tested component

100 times or moreDuring the system testing process the test cases of fault

injection can be implemented by testing the componentinformation and fault injection operators The testing statecan be recorded through the dynamic monitoring mecha-nism after running the tested component The vulnerabilitytype of the componentmethod and vulnerability factor can bederived from comparing the testing state with the componentinformation record in PRED The execution probability 119875

119894

of each method in the component can be determined byrunning the tested component 100 times respectively Thenthe component security level can be determined using For-mula (1)The testing results are shown in Table 3 Because dif-ferent components have different method parameters whichhave different parameter types such as integer string andboolean we select suitable fault injection factors to test thecomponent security based on the above presented 18 faultinjection operators of component in Table 3

A higher level of security indicates better relative securityof the component The component is secure if and only ifthe component security level is 1 Otherwise it has securityvulnerability In contrast to the test results in Table 3 the levelof security is closer to the vulnerability information publishedin the CVE Web site The values of execution probabilityand vulnerability factors have been proved to affect thecomponent security The results agree with the previousexperimental results further confirming the feasibility andeffectiveness of this approach

55 Experimental Comparison Table 4 shows the compar-ison with other assessment approaches The related assess-ment approaches have various merits as shown in theanalysis of Table 4 Our QACS approach mainly focuseson quantitatively assessing the security level of the COTScomponent The source codes of the COTS component are

Mathematical Problems in Engineering 9

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(a) cnt = 5

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(b) cnt = 10

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(c) cnt = 15

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(d) cnt = 20

Figure 5 The comparison for different 119875119894 VC119894 and cnt

generally unknownThe internal factors of the component areconsidered in QACSThe QACS approach is implemented inthe CSTASboIFT that is integrated into our CSTS [22] systemdeveloped to test the security of the COTS component

Aside from the above-mentioned approaches CVSS is awidely used quantitative assessment approach for softwarecomponent Khan and Han developed an assessment schemefor the security properties of software components Theassessment scheme provided a numeric score that indicatesthe relative strength of the security properties of the compo-nent [8] Results of the comparison with the CVSS approachand Khaled approach are shown in Table 5 In addition thesecurity level of six tested components is also listed accordingto the reported empirical data of securityWeb sites in Table 5The initial CVSSBase Score is calculated by theCVSS formula[16]

Analyzing Table 5 the QACS approach is found to beclose to the empirical data reported on some security Websites regarding the security of the tested COTS componentsThe security score of the QACS approach is more accuratethan that of others because the internal factors of the tested

component are considered The assessment process of theQACS approach is objective without human interventionNevertheless the CVSS approach ismainly focused on assess-ing the vulnerability of the general software componentIf an assessor is not familiar with the assessed softwarethe vulnerability score becomes inaccurate because of theassessorrsquos subjectivity in the assessment process On the otherhand the Khaled approach is an approximate assessmentapproach based on the assumed component environment Inaddition presently there are no more effective assessmentapproaches for the security level of software componentaccording to our studies

6 Conclusion

In component-based software development andmaintenanceactivities the assessment of the component reliability andsecurity level is essential in the third-party componentResearch on an effective quantitative assessment methodfor component security level is valuable in the CBSE The

10 Mathematical Problems in Engineering

Table 3 Testing results for six tested components

ID Fault injectionfactor

The number ofvulnerabilities and its 119875

119894

Test result Security level

01 IIV 2(013 013)

ThunderAgent 005dll has two methods calling(GetInfoStruct() GetTaskInfoStruc()) neglected the inputparameter exception and generated security vulnerability Thenthey resulted in program breakdown

07569

02 CIV LSV RSV 5(01 02 01 015 02)

AcroPDFdll did not correctly deal with the string parameterssent to function setPageMode() LoadFile() setLayoutMode()and setNamedDest() and the attribute src It triggered memorydestroyed and resulted in security vulnerability for executingany instruction

04406

03 LSV RSV FSV 1(064)

The function SetInfo() of GLItemComDLL ActiveX overtrusted user input and did not check parameterrsquos length Itresulted in the point the virtual function covered

036

04 LSV RSV FSV 1(01)

Pdg2dll did not deal with the sent parameter to Register () ifuser sends the string over 256 bytes it can trigger stack overflowand execute any code

09

05 LSV RSV USV 1(015)

GomManager object did not collectively deal with the firstparameter of OpenURL() in IGomManager interface Iftransmitting the long parameters over 500 bytes it can triggerstack overflow to result in visiting the memory exception

085

06 PSN CIV PIVLSV USV

5(015 015 015 015 015)

5 methods of component existed security exception The testcase parameters implemented by input fault injection operatorwould result in buffer overflow visiting beyond the scope andmemory leakage

04437

Table 4 The comparison with related assessment approaches

Assessment approach Assessment object Assessment aspect Is the internalfactor considered

Qualitative orquantitative

Is there supportingtool

Khan and Han [8] Software component Security No Quantitative NoAlhazmi and Malaiya[11] Operating system Vulnerability Yes Quantitative No

Zhang et al [12] Software system Risk No Quantitativequalitative

No

Goseva-Popstojanovaand Trivedi [15] Software system Reliability No Quantitative No

Mkpong-Ruffin [3] Software Risk No Quantitative Yes

CVSS [16] Software component Vulnerability No Quantitative Yes

QACS COTS component Security Yes Quantitative Yes

Table 5 The comparison with CVSS and Khaled approaches

ComponentID

InitialCVSS base

score

Convertedsecurity score

of CVSS

Securitylevel ofQACS

The reportedempirical data(security level)

01 58 042 07569 B+

02 19 081 04406 Cminus

03 6 04 036 D+

04 7 03 09 A

05 36 064 085 Aminus

06 19 081 04437 Cminus

current paper proposes theQACS approach for quantitativelyassessing component security which is based on the interfacefault injection of the componentThe fault injection operatorsof the component vulnerability and PRED are defined anddiscussedThe assessment framework and algorithm for com-ponent security are proposed as wellThe testing effect provesexcellent in practical application QACS has the followingmain advantages (1) the security exceptional assessmentrules and vulnerability factors of the component are givenproviding the basis for security assessment (2) QACS canassess the security level of the third-party component andthe score of component security can be accurately calculated(3) QACS has better operability

Mathematical Problems in Engineering 11

Acknowledgments

We would like to thank Professor T Y Chen for his con-structive suggestions and valuable discussion in this paperwriting In addition this work was supported partly bythe National Natural Science Foundation of China (NSFC)under Grants no 61202110 and no 61063013 Natural ScienceFoundation of Jiangsu Province under Grant no BK2012284and the Research Fund for the Doctoral Program of HigherEducation of China under Grant no 20103227120005

References

[1] J Chen Y Lu and X D Xie ldquoComponent security testingapproach by using interface fault injectionrdquo Journal of ChineseComputer Systems vol 31 no 6 pp 1090ndash1096 2010

[2] S Gudder andRGreechie ldquoUniqueness and order in sequentialeffect algebrasrdquo International Journal of Theoretical Physics vol44 no 7 pp 755ndash770 2005

[3] I O Mkpong-Ruffin Quantitative risk assessment model forsoftware security in the design phase of software development[PhD thesis] Auburn University Auburn Ala USA 2009

[4] J Han and Y Zheng ldquoSecurity characterization and integrityassurance for component-based softwarerdquo in Proceedings of theInternational Conference on Software Methods and Tools (SMTrsquo00) pp 61ndash66 IEEE Computer SocietyWollongong Australia2000

[5] F Jabeen and M Jaffar-Ur Rehman ldquoA framework for objectoriented component testingrdquo in Proceedings of the IEEE Inter-national Conference on Emerging Technologies (ICET rsquo05) pp451ndash460 Islamabad Pakistan September 2005

[6] K Md Khan J Han and Y Zheng ldquoCharacterizing userdata protection of software componentsrdquo in Proceedings of theSoftware EngineeringConference pp 3ndash11 CanberraAustralian2000

[7] K M Khan and J Han ldquoA security characterisation frame-work for trustworthy component based software systemsrdquo inProceedings of the 27th Annual International Computer Softwareand Applications Conference (COMPSAC rsquo03) pp 164ndash169November 2003

[8] K M Khan and J Han ldquoAssessing security properties ofsoftware components a software engineerrsquos perspectiverdquo inProceedings of the Australian Software Engineering Conference(ASWEC rsquo06) pp 199ndash208 Sydney Australia April 2006

[9] K Khan J Han and Y Zheng ldquoA framework for an activeinterface to characterise compositional security contracts ofsoftware components rdquo in Proceedings of the Australian SoftwareEngineering Conference (ASWEC rsquo01) pp 117ndash126 2001

[10] ldquoCommon criteria projectISO Common criteria for informa-tion technology security evaluationrdquo version 21 (ISOIEC Inter-national Standard 15408) NIST USA and ISO Switzerland1999 httpcsrcnistgovcc

[11] O H Alhazmi and Y K Malaiya ldquoQuantitative vulnerabilityassessment of systems softwarerdquo in Proceedings of the AnnualReliability andMaintainability Symposium (RAMS rsquo05) pp 615ndash620 January 2005

[12] Y-K Zhang S-Y Jiang Y-A Cui B W Zhang and H Xia ldquoAqualitative and quantitative risk assessment method in softwaresecurityrdquo in Proceedings of the 3rd International Conference onAdvanced Computer Theory and Engineering (ICACTE rsquo10) ppV1534ndashV1539 Chengdu China August 2010

[13] X Tang and B Shen ldquoExtending model driven architecturewith software security assessmentrdquo in Proceedings of the 3rdIEEE International Conference on Secure Software IntegrationReliability Improvement (SSIRI rsquo09) pp 436ndash441 ShanghaiChina July 2009

[14] X Wang H Shi T Y W Huang and F C Lin ldquoIntegratedsoftware vulnerability and security functionality assessmentrdquoin Proceedings of the 18th IEEE International Symposium onSoftware Reliability Engineering (ISSRE rsquo07) pp 103ndash108 Troll-hattan Sweden November 2007

[15] K Goseva-Popstojanova and K S Trivedi ldquoArchitecture-basedapproach to reliability assessment of software systemsrdquo Perfor-mance Evaluation vol 45 no 2-3 pp 179ndash204 2001

[16] ldquoNVD Common Vulnerability Scoring System (CVSS)rdquohttpnvdnistgovcvsscfm

[17] Y Jiang G M Xin J-H Shan L Zhang B Xie and F-Q YangldquoMethod of automated test data generation for web servicerdquoChinese Journal of Computers vol 28 no 4 pp 568ndash577 2005

[18] M E Delamaro J C Maldonado and A P Mathur ldquoInterfacemutation an approach for integration testingrdquo IEEE Transac-tions on Software Engineering vol 27 no 3 pp 228ndash247 2001

[19] J M Voas and K W Miller ldquoPredicting softwarersquos minimum-time-to-hazard andmean-time-to-hazard for rare input eventsrdquoin Proceedings of the 6th International Symposium on SoftwareReliability Engineering pp 229ndash238 October 1995

[20] J Chen Y Lu andX Xie ldquoA fault injectionmodel of componentsecurity testingrdquo Computer Research and Development vol 46no 7 pp 1127ndash1135 2009

[21] J Chen Y LuW Zhang andXD Xie ldquoA fault injectionmodel-oriented testing strategy for component securityrdquo Journal ofCentral South University of Technology vol 16 no 2 pp 258ndash264 2009

[22] J Chen Y Lu X Xie et al ldquoDesign and implementation of anautomatic testing platform for component securityrdquo ComputerScience vol 35 no 12 pp 229ndash233 2008

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

8 Mathematical Problems in Engineering

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(a) cnt = 5

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(b) cnt = 10

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(c) cnt = 15

0010203040506070809

10 01 02 03 04 05 06 07 08 09

1

119875119894

1minusVu

L 119888

(d) cnt = 20

Figure 4 The comparison for different 119875119894and cnt

intervals The effect on the value of 1 minus VuL119888when the

two parameters changed simultaneously was observed Theresults show that when 119875

119894is proportional to VC

119894 the value

of 1 minus Vul119888changes significantly as shown in (a) and (b)

of Figure 5 When 119875119894is inversely proportional to VC

119894 the

value of 1 minus Vul119888changes indistinctly as shown in (c) and

(d) of Figure 5 As the vulnerability number cnt increasesthe security level decreases Results are shown in Figure 5The values of 119875

119894and VC

119894are based on the main 119910-axis values

(the left axis) and the value of the 1 minus Vul119888is based on the

secondary 119910-axis values (the right axis) The testing resultsshow that the proposed assessment Formula (1) is suitable forassessing the COTS component

54 Experiment Four The components were assessed inTable 3 based on Algorithm 1 The value of IC and MC is setto 1 119875

119894can be determined by executing the tested component

100 times or moreDuring the system testing process the test cases of fault

injection can be implemented by testing the componentinformation and fault injection operators The testing statecan be recorded through the dynamic monitoring mecha-nism after running the tested component The vulnerabilitytype of the componentmethod and vulnerability factor can bederived from comparing the testing state with the componentinformation record in PRED The execution probability 119875

119894

of each method in the component can be determined byrunning the tested component 100 times respectively Thenthe component security level can be determined using For-mula (1)The testing results are shown in Table 3 Because dif-ferent components have different method parameters whichhave different parameter types such as integer string andboolean we select suitable fault injection factors to test thecomponent security based on the above presented 18 faultinjection operators of component in Table 3

A higher level of security indicates better relative securityof the component The component is secure if and only ifthe component security level is 1 Otherwise it has securityvulnerability In contrast to the test results in Table 3 the levelof security is closer to the vulnerability information publishedin the CVE Web site The values of execution probabilityand vulnerability factors have been proved to affect thecomponent security The results agree with the previousexperimental results further confirming the feasibility andeffectiveness of this approach

55 Experimental Comparison Table 4 shows the compar-ison with other assessment approaches The related assess-ment approaches have various merits as shown in theanalysis of Table 4 Our QACS approach mainly focuseson quantitatively assessing the security level of the COTScomponent The source codes of the COTS component are

Mathematical Problems in Engineering 9

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(a) cnt = 5

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(b) cnt = 10

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(c) cnt = 15

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(d) cnt = 20

Figure 5 The comparison for different 119875119894 VC119894 and cnt

generally unknownThe internal factors of the component areconsidered in QACSThe QACS approach is implemented inthe CSTASboIFT that is integrated into our CSTS [22] systemdeveloped to test the security of the COTS component

Aside from the above-mentioned approaches CVSS is awidely used quantitative assessment approach for softwarecomponent Khan and Han developed an assessment schemefor the security properties of software components Theassessment scheme provided a numeric score that indicatesthe relative strength of the security properties of the compo-nent [8] Results of the comparison with the CVSS approachand Khaled approach are shown in Table 5 In addition thesecurity level of six tested components is also listed accordingto the reported empirical data of securityWeb sites in Table 5The initial CVSSBase Score is calculated by theCVSS formula[16]

Analyzing Table 5 the QACS approach is found to beclose to the empirical data reported on some security Websites regarding the security of the tested COTS componentsThe security score of the QACS approach is more accuratethan that of others because the internal factors of the tested

component are considered The assessment process of theQACS approach is objective without human interventionNevertheless the CVSS approach ismainly focused on assess-ing the vulnerability of the general software componentIf an assessor is not familiar with the assessed softwarethe vulnerability score becomes inaccurate because of theassessorrsquos subjectivity in the assessment process On the otherhand the Khaled approach is an approximate assessmentapproach based on the assumed component environment Inaddition presently there are no more effective assessmentapproaches for the security level of software componentaccording to our studies

6 Conclusion

In component-based software development andmaintenanceactivities the assessment of the component reliability andsecurity level is essential in the third-party componentResearch on an effective quantitative assessment methodfor component security level is valuable in the CBSE The

10 Mathematical Problems in Engineering

Table 3 Testing results for six tested components

ID Fault injectionfactor

The number ofvulnerabilities and its 119875

119894

Test result Security level

01 IIV 2(013 013)

ThunderAgent 005dll has two methods calling(GetInfoStruct() GetTaskInfoStruc()) neglected the inputparameter exception and generated security vulnerability Thenthey resulted in program breakdown

07569

02 CIV LSV RSV 5(01 02 01 015 02)

AcroPDFdll did not correctly deal with the string parameterssent to function setPageMode() LoadFile() setLayoutMode()and setNamedDest() and the attribute src It triggered memorydestroyed and resulted in security vulnerability for executingany instruction

04406

03 LSV RSV FSV 1(064)

The function SetInfo() of GLItemComDLL ActiveX overtrusted user input and did not check parameterrsquos length Itresulted in the point the virtual function covered

036

04 LSV RSV FSV 1(01)

Pdg2dll did not deal with the sent parameter to Register () ifuser sends the string over 256 bytes it can trigger stack overflowand execute any code

09

05 LSV RSV USV 1(015)

GomManager object did not collectively deal with the firstparameter of OpenURL() in IGomManager interface Iftransmitting the long parameters over 500 bytes it can triggerstack overflow to result in visiting the memory exception

085

06 PSN CIV PIVLSV USV

5(015 015 015 015 015)

5 methods of component existed security exception The testcase parameters implemented by input fault injection operatorwould result in buffer overflow visiting beyond the scope andmemory leakage

04437

Table 4 The comparison with related assessment approaches

Assessment approach Assessment object Assessment aspect Is the internalfactor considered

Qualitative orquantitative

Is there supportingtool

Khan and Han [8] Software component Security No Quantitative NoAlhazmi and Malaiya[11] Operating system Vulnerability Yes Quantitative No

Zhang et al [12] Software system Risk No Quantitativequalitative

No

Goseva-Popstojanovaand Trivedi [15] Software system Reliability No Quantitative No

Mkpong-Ruffin [3] Software Risk No Quantitative Yes

CVSS [16] Software component Vulnerability No Quantitative Yes

QACS COTS component Security Yes Quantitative Yes

Table 5 The comparison with CVSS and Khaled approaches

ComponentID

InitialCVSS base

score

Convertedsecurity score

of CVSS

Securitylevel ofQACS

The reportedempirical data(security level)

01 58 042 07569 B+

02 19 081 04406 Cminus

03 6 04 036 D+

04 7 03 09 A

05 36 064 085 Aminus

06 19 081 04437 Cminus

current paper proposes theQACS approach for quantitativelyassessing component security which is based on the interfacefault injection of the componentThe fault injection operatorsof the component vulnerability and PRED are defined anddiscussedThe assessment framework and algorithm for com-ponent security are proposed as wellThe testing effect provesexcellent in practical application QACS has the followingmain advantages (1) the security exceptional assessmentrules and vulnerability factors of the component are givenproviding the basis for security assessment (2) QACS canassess the security level of the third-party component andthe score of component security can be accurately calculated(3) QACS has better operability

Mathematical Problems in Engineering 11

Acknowledgments

We would like to thank Professor T Y Chen for his con-structive suggestions and valuable discussion in this paperwriting In addition this work was supported partly bythe National Natural Science Foundation of China (NSFC)under Grants no 61202110 and no 61063013 Natural ScienceFoundation of Jiangsu Province under Grant no BK2012284and the Research Fund for the Doctoral Program of HigherEducation of China under Grant no 20103227120005

References

[1] J Chen Y Lu and X D Xie ldquoComponent security testingapproach by using interface fault injectionrdquo Journal of ChineseComputer Systems vol 31 no 6 pp 1090ndash1096 2010

[2] S Gudder andRGreechie ldquoUniqueness and order in sequentialeffect algebrasrdquo International Journal of Theoretical Physics vol44 no 7 pp 755ndash770 2005

[3] I O Mkpong-Ruffin Quantitative risk assessment model forsoftware security in the design phase of software development[PhD thesis] Auburn University Auburn Ala USA 2009

[4] J Han and Y Zheng ldquoSecurity characterization and integrityassurance for component-based softwarerdquo in Proceedings of theInternational Conference on Software Methods and Tools (SMTrsquo00) pp 61ndash66 IEEE Computer SocietyWollongong Australia2000

[5] F Jabeen and M Jaffar-Ur Rehman ldquoA framework for objectoriented component testingrdquo in Proceedings of the IEEE Inter-national Conference on Emerging Technologies (ICET rsquo05) pp451ndash460 Islamabad Pakistan September 2005

[6] K Md Khan J Han and Y Zheng ldquoCharacterizing userdata protection of software componentsrdquo in Proceedings of theSoftware EngineeringConference pp 3ndash11 CanberraAustralian2000

[7] K M Khan and J Han ldquoA security characterisation frame-work for trustworthy component based software systemsrdquo inProceedings of the 27th Annual International Computer Softwareand Applications Conference (COMPSAC rsquo03) pp 164ndash169November 2003

[8] K M Khan and J Han ldquoAssessing security properties ofsoftware components a software engineerrsquos perspectiverdquo inProceedings of the Australian Software Engineering Conference(ASWEC rsquo06) pp 199ndash208 Sydney Australia April 2006

[9] K Khan J Han and Y Zheng ldquoA framework for an activeinterface to characterise compositional security contracts ofsoftware components rdquo in Proceedings of the Australian SoftwareEngineering Conference (ASWEC rsquo01) pp 117ndash126 2001

[10] ldquoCommon criteria projectISO Common criteria for informa-tion technology security evaluationrdquo version 21 (ISOIEC Inter-national Standard 15408) NIST USA and ISO Switzerland1999 httpcsrcnistgovcc

[11] O H Alhazmi and Y K Malaiya ldquoQuantitative vulnerabilityassessment of systems softwarerdquo in Proceedings of the AnnualReliability andMaintainability Symposium (RAMS rsquo05) pp 615ndash620 January 2005

[12] Y-K Zhang S-Y Jiang Y-A Cui B W Zhang and H Xia ldquoAqualitative and quantitative risk assessment method in softwaresecurityrdquo in Proceedings of the 3rd International Conference onAdvanced Computer Theory and Engineering (ICACTE rsquo10) ppV1534ndashV1539 Chengdu China August 2010

[13] X Tang and B Shen ldquoExtending model driven architecturewith software security assessmentrdquo in Proceedings of the 3rdIEEE International Conference on Secure Software IntegrationReliability Improvement (SSIRI rsquo09) pp 436ndash441 ShanghaiChina July 2009

[14] X Wang H Shi T Y W Huang and F C Lin ldquoIntegratedsoftware vulnerability and security functionality assessmentrdquoin Proceedings of the 18th IEEE International Symposium onSoftware Reliability Engineering (ISSRE rsquo07) pp 103ndash108 Troll-hattan Sweden November 2007

[15] K Goseva-Popstojanova and K S Trivedi ldquoArchitecture-basedapproach to reliability assessment of software systemsrdquo Perfor-mance Evaluation vol 45 no 2-3 pp 179ndash204 2001

[16] ldquoNVD Common Vulnerability Scoring System (CVSS)rdquohttpnvdnistgovcvsscfm

[17] Y Jiang G M Xin J-H Shan L Zhang B Xie and F-Q YangldquoMethod of automated test data generation for web servicerdquoChinese Journal of Computers vol 28 no 4 pp 568ndash577 2005

[18] M E Delamaro J C Maldonado and A P Mathur ldquoInterfacemutation an approach for integration testingrdquo IEEE Transac-tions on Software Engineering vol 27 no 3 pp 228ndash247 2001

[19] J M Voas and K W Miller ldquoPredicting softwarersquos minimum-time-to-hazard andmean-time-to-hazard for rare input eventsrdquoin Proceedings of the 6th International Symposium on SoftwareReliability Engineering pp 229ndash238 October 1995

[20] J Chen Y Lu andX Xie ldquoA fault injectionmodel of componentsecurity testingrdquo Computer Research and Development vol 46no 7 pp 1127ndash1135 2009

[21] J Chen Y LuW Zhang andXD Xie ldquoA fault injectionmodel-oriented testing strategy for component securityrdquo Journal ofCentral South University of Technology vol 16 no 2 pp 258ndash264 2009

[22] J Chen Y Lu X Xie et al ldquoDesign and implementation of anautomatic testing platform for component securityrdquo ComputerScience vol 35 no 12 pp 229ndash233 2008

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Mathematical Problems in Engineering 9

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(a) cnt = 5

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894V

C 119894

1minusVu

L 119888

(b) cnt = 10

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(c) cnt = 15

0

01

02

03

04

05

06

07

08

09

1

0

01

02

03

04

05

06

07

08

09

1

1 2 3 4 5 6 7 8 9 10

119875119894

VC119894

119875119894V

C 119894

1minusVu

L 119888

1minusVuL119888

(d) cnt = 20

Figure 5 The comparison for different 119875119894 VC119894 and cnt

generally unknownThe internal factors of the component areconsidered in QACSThe QACS approach is implemented inthe CSTASboIFT that is integrated into our CSTS [22] systemdeveloped to test the security of the COTS component

Aside from the above-mentioned approaches CVSS is awidely used quantitative assessment approach for softwarecomponent Khan and Han developed an assessment schemefor the security properties of software components Theassessment scheme provided a numeric score that indicatesthe relative strength of the security properties of the compo-nent [8] Results of the comparison with the CVSS approachand Khaled approach are shown in Table 5 In addition thesecurity level of six tested components is also listed accordingto the reported empirical data of securityWeb sites in Table 5The initial CVSSBase Score is calculated by theCVSS formula[16]

Analyzing Table 5 the QACS approach is found to beclose to the empirical data reported on some security Websites regarding the security of the tested COTS componentsThe security score of the QACS approach is more accuratethan that of others because the internal factors of the tested

component are considered The assessment process of theQACS approach is objective without human interventionNevertheless the CVSS approach ismainly focused on assess-ing the vulnerability of the general software componentIf an assessor is not familiar with the assessed softwarethe vulnerability score becomes inaccurate because of theassessorrsquos subjectivity in the assessment process On the otherhand the Khaled approach is an approximate assessmentapproach based on the assumed component environment Inaddition presently there are no more effective assessmentapproaches for the security level of software componentaccording to our studies

6 Conclusion

In component-based software development andmaintenanceactivities the assessment of the component reliability andsecurity level is essential in the third-party componentResearch on an effective quantitative assessment methodfor component security level is valuable in the CBSE The

10 Mathematical Problems in Engineering

Table 3 Testing results for six tested components

ID Fault injectionfactor

The number ofvulnerabilities and its 119875

119894

Test result Security level

01 IIV 2(013 013)

ThunderAgent 005dll has two methods calling(GetInfoStruct() GetTaskInfoStruc()) neglected the inputparameter exception and generated security vulnerability Thenthey resulted in program breakdown

07569

02 CIV LSV RSV 5(01 02 01 015 02)

AcroPDFdll did not correctly deal with the string parameterssent to function setPageMode() LoadFile() setLayoutMode()and setNamedDest() and the attribute src It triggered memorydestroyed and resulted in security vulnerability for executingany instruction

04406

03 LSV RSV FSV 1(064)

The function SetInfo() of GLItemComDLL ActiveX overtrusted user input and did not check parameterrsquos length Itresulted in the point the virtual function covered

036

04 LSV RSV FSV 1(01)

Pdg2dll did not deal with the sent parameter to Register () ifuser sends the string over 256 bytes it can trigger stack overflowand execute any code

09

05 LSV RSV USV 1(015)

GomManager object did not collectively deal with the firstparameter of OpenURL() in IGomManager interface Iftransmitting the long parameters over 500 bytes it can triggerstack overflow to result in visiting the memory exception

085

06 PSN CIV PIVLSV USV

5(015 015 015 015 015)

5 methods of component existed security exception The testcase parameters implemented by input fault injection operatorwould result in buffer overflow visiting beyond the scope andmemory leakage

04437

Table 4 The comparison with related assessment approaches

Assessment approach Assessment object Assessment aspect Is the internalfactor considered

Qualitative orquantitative

Is there supportingtool

Khan and Han [8] Software component Security No Quantitative NoAlhazmi and Malaiya[11] Operating system Vulnerability Yes Quantitative No

Zhang et al [12] Software system Risk No Quantitativequalitative

No

Goseva-Popstojanovaand Trivedi [15] Software system Reliability No Quantitative No

Mkpong-Ruffin [3] Software Risk No Quantitative Yes

CVSS [16] Software component Vulnerability No Quantitative Yes

QACS COTS component Security Yes Quantitative Yes

Table 5 The comparison with CVSS and Khaled approaches

ComponentID

InitialCVSS base

score

Convertedsecurity score

of CVSS

Securitylevel ofQACS

The reportedempirical data(security level)

01 58 042 07569 B+

02 19 081 04406 Cminus

03 6 04 036 D+

04 7 03 09 A

05 36 064 085 Aminus

06 19 081 04437 Cminus

current paper proposes theQACS approach for quantitativelyassessing component security which is based on the interfacefault injection of the componentThe fault injection operatorsof the component vulnerability and PRED are defined anddiscussedThe assessment framework and algorithm for com-ponent security are proposed as wellThe testing effect provesexcellent in practical application QACS has the followingmain advantages (1) the security exceptional assessmentrules and vulnerability factors of the component are givenproviding the basis for security assessment (2) QACS canassess the security level of the third-party component andthe score of component security can be accurately calculated(3) QACS has better operability

Mathematical Problems in Engineering 11

Acknowledgments

We would like to thank Professor T Y Chen for his con-structive suggestions and valuable discussion in this paperwriting In addition this work was supported partly bythe National Natural Science Foundation of China (NSFC)under Grants no 61202110 and no 61063013 Natural ScienceFoundation of Jiangsu Province under Grant no BK2012284and the Research Fund for the Doctoral Program of HigherEducation of China under Grant no 20103227120005

References

[1] J Chen Y Lu and X D Xie ldquoComponent security testingapproach by using interface fault injectionrdquo Journal of ChineseComputer Systems vol 31 no 6 pp 1090ndash1096 2010

[2] S Gudder andRGreechie ldquoUniqueness and order in sequentialeffect algebrasrdquo International Journal of Theoretical Physics vol44 no 7 pp 755ndash770 2005

[3] I O Mkpong-Ruffin Quantitative risk assessment model forsoftware security in the design phase of software development[PhD thesis] Auburn University Auburn Ala USA 2009

[4] J Han and Y Zheng ldquoSecurity characterization and integrityassurance for component-based softwarerdquo in Proceedings of theInternational Conference on Software Methods and Tools (SMTrsquo00) pp 61ndash66 IEEE Computer SocietyWollongong Australia2000

[5] F Jabeen and M Jaffar-Ur Rehman ldquoA framework for objectoriented component testingrdquo in Proceedings of the IEEE Inter-national Conference on Emerging Technologies (ICET rsquo05) pp451ndash460 Islamabad Pakistan September 2005

[6] K Md Khan J Han and Y Zheng ldquoCharacterizing userdata protection of software componentsrdquo in Proceedings of theSoftware EngineeringConference pp 3ndash11 CanberraAustralian2000

[7] K M Khan and J Han ldquoA security characterisation frame-work for trustworthy component based software systemsrdquo inProceedings of the 27th Annual International Computer Softwareand Applications Conference (COMPSAC rsquo03) pp 164ndash169November 2003

[8] K M Khan and J Han ldquoAssessing security properties ofsoftware components a software engineerrsquos perspectiverdquo inProceedings of the Australian Software Engineering Conference(ASWEC rsquo06) pp 199ndash208 Sydney Australia April 2006

[9] K Khan J Han and Y Zheng ldquoA framework for an activeinterface to characterise compositional security contracts ofsoftware components rdquo in Proceedings of the Australian SoftwareEngineering Conference (ASWEC rsquo01) pp 117ndash126 2001

[10] ldquoCommon criteria projectISO Common criteria for informa-tion technology security evaluationrdquo version 21 (ISOIEC Inter-national Standard 15408) NIST USA and ISO Switzerland1999 httpcsrcnistgovcc

[11] O H Alhazmi and Y K Malaiya ldquoQuantitative vulnerabilityassessment of systems softwarerdquo in Proceedings of the AnnualReliability andMaintainability Symposium (RAMS rsquo05) pp 615ndash620 January 2005

[12] Y-K Zhang S-Y Jiang Y-A Cui B W Zhang and H Xia ldquoAqualitative and quantitative risk assessment method in softwaresecurityrdquo in Proceedings of the 3rd International Conference onAdvanced Computer Theory and Engineering (ICACTE rsquo10) ppV1534ndashV1539 Chengdu China August 2010

[13] X Tang and B Shen ldquoExtending model driven architecturewith software security assessmentrdquo in Proceedings of the 3rdIEEE International Conference on Secure Software IntegrationReliability Improvement (SSIRI rsquo09) pp 436ndash441 ShanghaiChina July 2009

[14] X Wang H Shi T Y W Huang and F C Lin ldquoIntegratedsoftware vulnerability and security functionality assessmentrdquoin Proceedings of the 18th IEEE International Symposium onSoftware Reliability Engineering (ISSRE rsquo07) pp 103ndash108 Troll-hattan Sweden November 2007

[15] K Goseva-Popstojanova and K S Trivedi ldquoArchitecture-basedapproach to reliability assessment of software systemsrdquo Perfor-mance Evaluation vol 45 no 2-3 pp 179ndash204 2001

[16] ldquoNVD Common Vulnerability Scoring System (CVSS)rdquohttpnvdnistgovcvsscfm

[17] Y Jiang G M Xin J-H Shan L Zhang B Xie and F-Q YangldquoMethod of automated test data generation for web servicerdquoChinese Journal of Computers vol 28 no 4 pp 568ndash577 2005

[18] M E Delamaro J C Maldonado and A P Mathur ldquoInterfacemutation an approach for integration testingrdquo IEEE Transac-tions on Software Engineering vol 27 no 3 pp 228ndash247 2001

[19] J M Voas and K W Miller ldquoPredicting softwarersquos minimum-time-to-hazard andmean-time-to-hazard for rare input eventsrdquoin Proceedings of the 6th International Symposium on SoftwareReliability Engineering pp 229ndash238 October 1995

[20] J Chen Y Lu andX Xie ldquoA fault injectionmodel of componentsecurity testingrdquo Computer Research and Development vol 46no 7 pp 1127ndash1135 2009

[21] J Chen Y LuW Zhang andXD Xie ldquoA fault injectionmodel-oriented testing strategy for component securityrdquo Journal ofCentral South University of Technology vol 16 no 2 pp 258ndash264 2009

[22] J Chen Y Lu X Xie et al ldquoDesign and implementation of anautomatic testing platform for component securityrdquo ComputerScience vol 35 no 12 pp 229ndash233 2008

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

10 Mathematical Problems in Engineering

Table 3 Testing results for six tested components

ID Fault injectionfactor

The number ofvulnerabilities and its 119875

119894

Test result Security level

01 IIV 2(013 013)

ThunderAgent 005dll has two methods calling(GetInfoStruct() GetTaskInfoStruc()) neglected the inputparameter exception and generated security vulnerability Thenthey resulted in program breakdown

07569

02 CIV LSV RSV 5(01 02 01 015 02)

AcroPDFdll did not correctly deal with the string parameterssent to function setPageMode() LoadFile() setLayoutMode()and setNamedDest() and the attribute src It triggered memorydestroyed and resulted in security vulnerability for executingany instruction

04406

03 LSV RSV FSV 1(064)

The function SetInfo() of GLItemComDLL ActiveX overtrusted user input and did not check parameterrsquos length Itresulted in the point the virtual function covered

036

04 LSV RSV FSV 1(01)

Pdg2dll did not deal with the sent parameter to Register () ifuser sends the string over 256 bytes it can trigger stack overflowand execute any code

09

05 LSV RSV USV 1(015)

GomManager object did not collectively deal with the firstparameter of OpenURL() in IGomManager interface Iftransmitting the long parameters over 500 bytes it can triggerstack overflow to result in visiting the memory exception

085

06 PSN CIV PIVLSV USV

5(015 015 015 015 015)

5 methods of component existed security exception The testcase parameters implemented by input fault injection operatorwould result in buffer overflow visiting beyond the scope andmemory leakage

04437

Table 4 The comparison with related assessment approaches

Assessment approach Assessment object Assessment aspect Is the internalfactor considered

Qualitative orquantitative

Is there supportingtool

Khan and Han [8] Software component Security No Quantitative NoAlhazmi and Malaiya[11] Operating system Vulnerability Yes Quantitative No

Zhang et al [12] Software system Risk No Quantitativequalitative

No

Goseva-Popstojanovaand Trivedi [15] Software system Reliability No Quantitative No

Mkpong-Ruffin [3] Software Risk No Quantitative Yes

CVSS [16] Software component Vulnerability No Quantitative Yes

QACS COTS component Security Yes Quantitative Yes

Table 5 The comparison with CVSS and Khaled approaches

ComponentID

InitialCVSS base

score

Convertedsecurity score

of CVSS

Securitylevel ofQACS

The reportedempirical data(security level)

01 58 042 07569 B+

02 19 081 04406 Cminus

03 6 04 036 D+

04 7 03 09 A

05 36 064 085 Aminus

06 19 081 04437 Cminus

current paper proposes theQACS approach for quantitativelyassessing component security which is based on the interfacefault injection of the componentThe fault injection operatorsof the component vulnerability and PRED are defined anddiscussedThe assessment framework and algorithm for com-ponent security are proposed as wellThe testing effect provesexcellent in practical application QACS has the followingmain advantages (1) the security exceptional assessmentrules and vulnerability factors of the component are givenproviding the basis for security assessment (2) QACS canassess the security level of the third-party component andthe score of component security can be accurately calculated(3) QACS has better operability

Mathematical Problems in Engineering 11

Acknowledgments

We would like to thank Professor T Y Chen for his con-structive suggestions and valuable discussion in this paperwriting In addition this work was supported partly bythe National Natural Science Foundation of China (NSFC)under Grants no 61202110 and no 61063013 Natural ScienceFoundation of Jiangsu Province under Grant no BK2012284and the Research Fund for the Doctoral Program of HigherEducation of China under Grant no 20103227120005

References

[1] J Chen Y Lu and X D Xie ldquoComponent security testingapproach by using interface fault injectionrdquo Journal of ChineseComputer Systems vol 31 no 6 pp 1090ndash1096 2010

[2] S Gudder andRGreechie ldquoUniqueness and order in sequentialeffect algebrasrdquo International Journal of Theoretical Physics vol44 no 7 pp 755ndash770 2005

[3] I O Mkpong-Ruffin Quantitative risk assessment model forsoftware security in the design phase of software development[PhD thesis] Auburn University Auburn Ala USA 2009

[4] J Han and Y Zheng ldquoSecurity characterization and integrityassurance for component-based softwarerdquo in Proceedings of theInternational Conference on Software Methods and Tools (SMTrsquo00) pp 61ndash66 IEEE Computer SocietyWollongong Australia2000

[5] F Jabeen and M Jaffar-Ur Rehman ldquoA framework for objectoriented component testingrdquo in Proceedings of the IEEE Inter-national Conference on Emerging Technologies (ICET rsquo05) pp451ndash460 Islamabad Pakistan September 2005

[6] K Md Khan J Han and Y Zheng ldquoCharacterizing userdata protection of software componentsrdquo in Proceedings of theSoftware EngineeringConference pp 3ndash11 CanberraAustralian2000

[7] K M Khan and J Han ldquoA security characterisation frame-work for trustworthy component based software systemsrdquo inProceedings of the 27th Annual International Computer Softwareand Applications Conference (COMPSAC rsquo03) pp 164ndash169November 2003

[8] K M Khan and J Han ldquoAssessing security properties ofsoftware components a software engineerrsquos perspectiverdquo inProceedings of the Australian Software Engineering Conference(ASWEC rsquo06) pp 199ndash208 Sydney Australia April 2006

[9] K Khan J Han and Y Zheng ldquoA framework for an activeinterface to characterise compositional security contracts ofsoftware components rdquo in Proceedings of the Australian SoftwareEngineering Conference (ASWEC rsquo01) pp 117ndash126 2001

[10] ldquoCommon criteria projectISO Common criteria for informa-tion technology security evaluationrdquo version 21 (ISOIEC Inter-national Standard 15408) NIST USA and ISO Switzerland1999 httpcsrcnistgovcc

[11] O H Alhazmi and Y K Malaiya ldquoQuantitative vulnerabilityassessment of systems softwarerdquo in Proceedings of the AnnualReliability andMaintainability Symposium (RAMS rsquo05) pp 615ndash620 January 2005

[12] Y-K Zhang S-Y Jiang Y-A Cui B W Zhang and H Xia ldquoAqualitative and quantitative risk assessment method in softwaresecurityrdquo in Proceedings of the 3rd International Conference onAdvanced Computer Theory and Engineering (ICACTE rsquo10) ppV1534ndashV1539 Chengdu China August 2010

[13] X Tang and B Shen ldquoExtending model driven architecturewith software security assessmentrdquo in Proceedings of the 3rdIEEE International Conference on Secure Software IntegrationReliability Improvement (SSIRI rsquo09) pp 436ndash441 ShanghaiChina July 2009

[14] X Wang H Shi T Y W Huang and F C Lin ldquoIntegratedsoftware vulnerability and security functionality assessmentrdquoin Proceedings of the 18th IEEE International Symposium onSoftware Reliability Engineering (ISSRE rsquo07) pp 103ndash108 Troll-hattan Sweden November 2007

[15] K Goseva-Popstojanova and K S Trivedi ldquoArchitecture-basedapproach to reliability assessment of software systemsrdquo Perfor-mance Evaluation vol 45 no 2-3 pp 179ndash204 2001

[16] ldquoNVD Common Vulnerability Scoring System (CVSS)rdquohttpnvdnistgovcvsscfm

[17] Y Jiang G M Xin J-H Shan L Zhang B Xie and F-Q YangldquoMethod of automated test data generation for web servicerdquoChinese Journal of Computers vol 28 no 4 pp 568ndash577 2005

[18] M E Delamaro J C Maldonado and A P Mathur ldquoInterfacemutation an approach for integration testingrdquo IEEE Transac-tions on Software Engineering vol 27 no 3 pp 228ndash247 2001

[19] J M Voas and K W Miller ldquoPredicting softwarersquos minimum-time-to-hazard andmean-time-to-hazard for rare input eventsrdquoin Proceedings of the 6th International Symposium on SoftwareReliability Engineering pp 229ndash238 October 1995

[20] J Chen Y Lu andX Xie ldquoA fault injectionmodel of componentsecurity testingrdquo Computer Research and Development vol 46no 7 pp 1127ndash1135 2009

[21] J Chen Y LuW Zhang andXD Xie ldquoA fault injectionmodel-oriented testing strategy for component securityrdquo Journal ofCentral South University of Technology vol 16 no 2 pp 258ndash264 2009

[22] J Chen Y Lu X Xie et al ldquoDesign and implementation of anautomatic testing platform for component securityrdquo ComputerScience vol 35 no 12 pp 229ndash233 2008

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Mathematical Problems in Engineering 11

Acknowledgments

We would like to thank Professor T Y Chen for his con-structive suggestions and valuable discussion in this paperwriting In addition this work was supported partly bythe National Natural Science Foundation of China (NSFC)under Grants no 61202110 and no 61063013 Natural ScienceFoundation of Jiangsu Province under Grant no BK2012284and the Research Fund for the Doctoral Program of HigherEducation of China under Grant no 20103227120005

References

[1] J Chen Y Lu and X D Xie ldquoComponent security testingapproach by using interface fault injectionrdquo Journal of ChineseComputer Systems vol 31 no 6 pp 1090ndash1096 2010

[2] S Gudder andRGreechie ldquoUniqueness and order in sequentialeffect algebrasrdquo International Journal of Theoretical Physics vol44 no 7 pp 755ndash770 2005

[3] I O Mkpong-Ruffin Quantitative risk assessment model forsoftware security in the design phase of software development[PhD thesis] Auburn University Auburn Ala USA 2009

[4] J Han and Y Zheng ldquoSecurity characterization and integrityassurance for component-based softwarerdquo in Proceedings of theInternational Conference on Software Methods and Tools (SMTrsquo00) pp 61ndash66 IEEE Computer SocietyWollongong Australia2000

[5] F Jabeen and M Jaffar-Ur Rehman ldquoA framework for objectoriented component testingrdquo in Proceedings of the IEEE Inter-national Conference on Emerging Technologies (ICET rsquo05) pp451ndash460 Islamabad Pakistan September 2005

[6] K Md Khan J Han and Y Zheng ldquoCharacterizing userdata protection of software componentsrdquo in Proceedings of theSoftware EngineeringConference pp 3ndash11 CanberraAustralian2000

[7] K M Khan and J Han ldquoA security characterisation frame-work for trustworthy component based software systemsrdquo inProceedings of the 27th Annual International Computer Softwareand Applications Conference (COMPSAC rsquo03) pp 164ndash169November 2003

[8] K M Khan and J Han ldquoAssessing security properties ofsoftware components a software engineerrsquos perspectiverdquo inProceedings of the Australian Software Engineering Conference(ASWEC rsquo06) pp 199ndash208 Sydney Australia April 2006

[9] K Khan J Han and Y Zheng ldquoA framework for an activeinterface to characterise compositional security contracts ofsoftware components rdquo in Proceedings of the Australian SoftwareEngineering Conference (ASWEC rsquo01) pp 117ndash126 2001

[10] ldquoCommon criteria projectISO Common criteria for informa-tion technology security evaluationrdquo version 21 (ISOIEC Inter-national Standard 15408) NIST USA and ISO Switzerland1999 httpcsrcnistgovcc

[11] O H Alhazmi and Y K Malaiya ldquoQuantitative vulnerabilityassessment of systems softwarerdquo in Proceedings of the AnnualReliability andMaintainability Symposium (RAMS rsquo05) pp 615ndash620 January 2005

[12] Y-K Zhang S-Y Jiang Y-A Cui B W Zhang and H Xia ldquoAqualitative and quantitative risk assessment method in softwaresecurityrdquo in Proceedings of the 3rd International Conference onAdvanced Computer Theory and Engineering (ICACTE rsquo10) ppV1534ndashV1539 Chengdu China August 2010

[13] X Tang and B Shen ldquoExtending model driven architecturewith software security assessmentrdquo in Proceedings of the 3rdIEEE International Conference on Secure Software IntegrationReliability Improvement (SSIRI rsquo09) pp 436ndash441 ShanghaiChina July 2009

[14] X Wang H Shi T Y W Huang and F C Lin ldquoIntegratedsoftware vulnerability and security functionality assessmentrdquoin Proceedings of the 18th IEEE International Symposium onSoftware Reliability Engineering (ISSRE rsquo07) pp 103ndash108 Troll-hattan Sweden November 2007

[15] K Goseva-Popstojanova and K S Trivedi ldquoArchitecture-basedapproach to reliability assessment of software systemsrdquo Perfor-mance Evaluation vol 45 no 2-3 pp 179ndash204 2001

[16] ldquoNVD Common Vulnerability Scoring System (CVSS)rdquohttpnvdnistgovcvsscfm

[17] Y Jiang G M Xin J-H Shan L Zhang B Xie and F-Q YangldquoMethod of automated test data generation for web servicerdquoChinese Journal of Computers vol 28 no 4 pp 568ndash577 2005

[18] M E Delamaro J C Maldonado and A P Mathur ldquoInterfacemutation an approach for integration testingrdquo IEEE Transac-tions on Software Engineering vol 27 no 3 pp 228ndash247 2001

[19] J M Voas and K W Miller ldquoPredicting softwarersquos minimum-time-to-hazard andmean-time-to-hazard for rare input eventsrdquoin Proceedings of the 6th International Symposium on SoftwareReliability Engineering pp 229ndash238 October 1995

[20] J Chen Y Lu andX Xie ldquoA fault injectionmodel of componentsecurity testingrdquo Computer Research and Development vol 46no 7 pp 1127ndash1135 2009

[21] J Chen Y LuW Zhang andXD Xie ldquoA fault injectionmodel-oriented testing strategy for component securityrdquo Journal ofCentral South University of Technology vol 16 no 2 pp 258ndash264 2009

[22] J Chen Y Lu X Xie et al ldquoDesign and implementation of anautomatic testing platform for component securityrdquo ComputerScience vol 35 no 12 pp 229ndash233 2008

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of

Submit your manuscripts athttpwwwhindawicom

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical Problems in Engineering

Hindawi Publishing Corporationhttpwwwhindawicom

Differential EquationsInternational Journal of

Volume 2014

Applied MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Probability and StatisticsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

OptimizationJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

CombinatoricsHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Operations ResearchAdvances in

Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Function Spaces

Abstract and Applied AnalysisHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

International Journal of Mathematics and Mathematical Sciences

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Algebra

Discrete Dynamics in Nature and Society

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Decision SciencesAdvances in

Discrete MathematicsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014 Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014

Stochastic AnalysisInternational Journal of