Security quality model: an extension of Dromey’s model

Saad Zafar • Misbah Mehboob • Asma Naveed • Bushra Malik

Published online: 18 October 2013� Springer Science+Business Media New York 2013

Abstract The quantity of sensitive data that is stored, processed and transmitted has

increased many folds in recent years. With this dramatic increase, comes the need to ensure

that the data remain trustworthy, confidential and available at all times. Nonetheless, the

recent spate of high-profile security incidents shows that software-based systems remain

vulnerable due to the presence of serious security defects. Therefore, there is a clear need

to improve the current state of software development to guide the development of more

secure software. To this end, we propose a security quality model that provides a frame-

work to identify known security defects, their fixes, the underlying low-level software

components along with the properties that positively influence the overall security of the

product. The proposed model is based on Dromey’s quality model that addresses the core

issue of quality by providing explicit guidelines on how to build quality into a product.

Furthermore, to incorporate security, we have introduced several new model components

and model construction guidelines as Dromey’s model does not address security explicitly

and the model construction guidelines are not specific enough. We use well-known defects

and security controls to construct the model as a proof of concept. The constructed model

can be used by the programmers during development and can also be used by the quality

engineers for audit purposes. We also propose an automated environment in which the

model can be used in practice.

S. Zafar � B. Malik (&)Faculty of Computing, Riphah International University, Islamabad, Pakistane-mail: bushra13_tariq@yahoo.com; bushra.malik@riu.edu.pk

S. Zafare-mail: saad.zafar@riphah.edu.pk

M. MehboobInternational Islamic University, Islamabad, Pakistane-mail: mis.misbah@yahoo.com

A. NaveedFoundation University College of Liberal Arts and Science, Islamabad, Pakistane-mail: asmanaveed@fui.edu.pk

123

Software Qual J (2015) 23:29–54DOI 10.1007/s11219-013-9223-1

Keywords Security quality model � Security � Software defects � Application

security � Dromey’s quality model � Security engineering

1 Introduction

Software applications and information systems are now becoming vital in every field of

life, including health, military, business and also in social networking sectors. Organiza-

tions prefer to store important data electronically; hence, it is an important concern that

these data remain trustworthy, confidential and available. There is a need that these

applications and systems must be secure in order to build the trust of customers and

organizations to share information (Mouratidis et al. 2005). Unfortunately, the incidence of

cybercrime has increased greatly in recent years. The rising level of cybercrime is having a

severe impact on a country’s economic viability (Kshetri 2006). Several attacks have been

reported on high-profile US Websites. Besides cybercrimes, insider threats are also a major

concern for software security (Joshi et al. 2002; Tawfik et al. 2007). Accidental and

unintentional security violations by end-users also cause severe security losses (Kraemer

and Carayon 2007). For these reasons, security has become an essential component in all

phases of the software development life cycle (Younan 2003).

Therefore, organizations have taken numerous security measures involving high

investments, but unfortunately no amount of security can thwart all security holes (Gordon

et al. 2003). It is essential that security be incorporated in a system as a nonfunctional

requirement at the time of coding, not only later in the analysis and design phases. Security

is not fully integrated within the other phases of software development life cycle (spe-

cifically in coding) unlike other nonfunctional requirements, e.g., reliability and perfor-

mance (Anderson 2008). Security, itself, is a broader concept, and there is little consensus

on its attributes and information models. Security attributes/sub-attributes must be

achieved for assuring the security of a software product. Three major security attributes are

as follows: confidentiality, integrity and availability (CIA). These attributes are further

divided into security sub-attributes in SEI technical report in an elaborate way (Firesmith

2003).

In today’s world of global computing, new threats are emerging rapidly and without

warning. Beside these emerging threats, software products are still vulnerable to old known

security threats like buffer overflow (Sidiroglou et al. 2005)—a classic threat for software

products for the last 20 years. Another known threat is the SQL injection defect that results

from careless programming and thus is found in many modern Web-based applications for

almost a decade (Buehrer et al. 2005). Programmers have little guidance on how to avoid

these known security threats at the code level. For this reason, programmers are com-

mitting the same programming mistakes over and over again. Therefore, there is a need for

a security quality model that can be used by software developers and designers to manage

these known security threats by implementing security at the code level. Moreover, such a

model may also be used by quality engineers to attain a certain desired level of security in a

software product.

Most of the existing quality or security models are not generic and may not define

security goals in a comprehensive way and provide little assistance in effectively incor-

porating security quality factors into a software product. Most of these existing models are

specific for some domain, or they address only some attributes of security, i.e., integrity or

30 Software Qual J (2015) 23:29–54

123

confidentiality. These models do not always provide any adequate mechanism for building

security into software. Most of them are either theoretical models/information models

(Balfanz and Simon 2000; Nagaratnam et al. 2004) or based on some strict mathematical

properties (Biba 1977; Hofheinz and Unruh 2008) that are hard to comprehend and

implement for the programmers. Furthermore, some of these models are neither illustrated

comprehensively and clearly nor it is very clear how the internal characteristics of the

software product are connected to the high-level quality attributes.

In this paper, we propose a generic security quality model (SQM) that can be used for

building security into software products. The proposed SQM is an extension of Dromey’s

quality model (Dromey 1995), which aims to serve as a guide on how to build quality into

a software product. Using the Dromey’s model as a baseline, we propose a framework to

link tangible product properties to high-level security attributes identified in (Firesmith

2003). To develop these linkages, we advocate the identification of low-level structures,

referred to in this paper as structural forms, and their associated security-carrying prop-

erties that influence the overall high-level security attributes of the software. The model

proposes a structured way of creating this linkage between the low-level structural forms,

and their quality-carrying properties and the high-level security attributes. Our contribution

is simplifying and extending the Dromey’s model for security. As a proof of concept, we

have applied the model to known security threats and countermeasures.

We share the motivation and objectives of Dromey to develop the SQM. The model is

proposed with the following objectives: (a) to assess, to prescribe or to specify security

quality requirements in a software product; (b) to comprehend how the specified level of

security may be implemented in a software product; (c) to enhance the security of the

software; (d) to use the model for training people on how to develop a secure software;

(e) to provide a framework that is generic enough to incorporate diverse existing and future

security-related quality needs; (f) to have a model that can be used by various interest

groups associated with the software; and (g) to help advance the knowledge of software

security quality. We realize that the construction of a completely instantiated model is a

nontrivial task. It may require a continuous group effort of the industry and/or the research

community to achieve a mature model. But once constructed, the designers may use it to

specify and to set the desired level of security; the programmers can use it as a guideline

for implementing the desired level of security for a particular product, while the quality

managers may use it to audit the implementation. To this end, we propose architecture of

an automated tool that can support the described process.

The remaining part of this paper is organized as follows: Sect. 2 provides the literature

review, which discusses the existing concepts used in this research. Section 3 describes the

proposed generic security quality model and illustrates how the model can be instantiated

using well-known security defects. The proposed automation of the model as future is

discussed in Sect. 4. In Sect. 5, we provide a brief discussion on the merits and limitations

of the proposed model.

2 Literature review

Software security is an important facet of software quality. A software product is secure if

it protects against unauthorized disclosure and modification of the information and data it

possesses, and also protects against denial of service attacks (Landwehr et al. 2001). The

thought behind the software security is to engineer software in such a way so that it works

correctly under malicious attacks (McGraw 2006). For this purpose, several security

Software Qual J (2015) 23:29–54 31

123

models and quality models have been proposed in the literature that addresses different

quality and security issues, as discussed in the proceeding sections. Broadly speaking, the

generic security and other quality models listed here do not address our objective of

explicitly identifying the internal product characteristics or properties that influence the

high-level attributes like security (Dromey 1996).

2.1 Security as a quality attribute

The three quality attributes of security are generally acknowledged to be confidentiality,

integrity and availability (Firesmith 2003). Confidentiality is the degree to which sensitive

information is secured from unauthorized users; integrity is the degree to which infor-

mation is protected from unauthorized corruption; and availability is the degree to which

systems are protected from different types of denial of service attacks (Lodderstedt et al.

2002). Another important attribute associated with security is access control, which is the

degree to which the access of the system is limited to only authorized users. Identification,

authentication and authorization are considered to be the sub-attributes of access control.

Identification is the degree to which a system identifies the external users before allowing

the access; authentication is the degree to which the system verifies the claimed identities

as authorized users; and authorization is the degree to which access rights are properly

enforced for the authorized users. In addition, various other security sub-attributes have

been proposed as in (Firesmith 2003).

Decomposition of security has been proposed by (Wang and Wulf 1997) in which

security is decomposed in confidentiality and integrity attributes. These attributes are

further decomposed in factors, criteria and metrics. Additionally, security decomposition

has been provided in (Brito et al. 2002). Here, the security is decomposed into integrity and

confidentiality only. Decomposition of security attribute has also been presented in a SEI

technical report (Barbacci et al. 1995). In this report, security is divided in CIA and then

further in sub-attributes in the form of internal and external factors. A detailed information

model on software security has been defined by Firesmith (2003), in which security has

been divided into classes and sub-classes. The author has proposed a detailed set of

consistent information models of safety, security and survivability engineering. Security

has been defined as one of the quality factors. The author decomposed security into many

different quality sub-factors in a comprehensive way. These sub-factors are further

decomposed into more comprehensive set of security sub-factors. In SQM, we have used

Firesmith’s information model (2003) for security attributes and sub-attributes. This

decomposition of security attribute into sub-factors is shown in Fig. 1.

2.2 Security models

The classical security models may be divided into three categories. The confidential

security models are used to model confidentiality of the system to prevent unauthorized

information disclosure. Bell and Lapadula (1976) is an access control model that is used

for expressing information flow control requirements with the focus on confidentiality. The

integrity security models are used for the systems where integrity of information is the

prime concern. The access control formulation in Biba (1977) integrity model was

developed as mathematical dual of Bell and LaPadula (1976). Confidentiality imposes

constraints on who can access an object, while integrity puts a constraint on who has the

right to modify the object. On the other hand, hybrid security models address the need of

the systems to integrate both integrity and confidentiality policies. The Chinese Wall

32 Software Qual J (2015) 23:29–54

123

model (Brewer and Nash 1989) refers to both integrity and confidentiality. It is useful for

modeling conflict of interest in business environments. Another group of models that are

used to model complex access control requirements is referred to as role-based access

control (Ferraiolo et al. 2001). These models are used to manage access control by

assigning rights to roles rather than to individual users separately. A number of different

variations have been proposed over the years (Table 1).

A complete description of other models is beyond the scope of this paper. However, it is

noteworthy that the existing security models are often mathematical based and are highly

specialized, thereby, making them difficult to use. These models are not always generic

enough to incorporate different aspects of security. They also provide little guidance on

how to integrate the model with the rest of the system requirements (Mouratidis and

Giorgini 2007). Specifically, the specialized models are not generic enough to specify

security properties of the internal system components that together contribute to all kinds

of different high-level security attributes.

2.3 Software quality models

It is generally the case that classical models of software development do not explicitly

include security as a high-level attribute. Instead, security is often described as a sub-

attribute of functionality. On the other hand, some models completely omit security as a

Fig. 1 Decomposition of software security in security attributes and sub-attributes [reproduced from(Firesmith 2003)]

Software Qual J (2015) 23:29–54 33

123

quality attribute. In McCall’s quality model (1977), eleven quality factors are described

under three aspects of product quality, but they addressed only one aspect of security, i.e.,

integrity. Likewise, security as an independent attribute is also not addressed in ISO 9126

(1991), Boehm (1978), FURPS (Grady and Caswell 1987) and Kitchenham (1987) models.

Some work has been done for evaluating the quality of commercial off-the-shelf (COTS)

components like Rawashdeh and Matalkah (2006) proposed a quality model for COTS

components, which is based on ISO 9126 and Dromey’s quality model. Another quality

model for COTS has been proposed by Franch and Carvallo (2003). It is a theoretical

model that is also based on ISO 9126. Security is considered in the model proposed by

(Tawfik et al. 2007), but the focus of the model is cost estimation. Systemic total quality

model (Ortega et al. 2000) combines the ideas of several quality models by putting security

as a sub-attribute under functionality.

On the other hand, some studies have attempted to critically analyze various quality

models to define new hybrid models or to identify characteristics of a robust quality model.

In one of the earlier works on the topic, Kitchenham presents a critical overview of the

existing quality models to conclude that the elusive goal of quality needs a holistic

approach that transcends the product view of quality and it must be defined in view of

organizational level requirements, and all the aspects of the quality must be defined in a

measurable way. Kitchenham includes McCall (1977), ISO 9126 and Dromey for the

comparison of the models. Dromey’s model is particularly presented in a favorable manner

for establishing a criterion for including any specific software property along with a means

of establishing a completion criterion for the model. A more recent study is more critical of

McCall, Boehm (1978), Dromey and FURPS (Grady and Caswell 1987) quality models for

not completely defining the connection of lower levels of the model with the upper levels

of the quality models (Al-Qutaish 2010). A systematic study of quality models including

the models that are mentioned here recommends need for more research in proposing new

or improving existing models to support prediction of quality using models, methods,

techniques and approaches (Tomar and Thakare 2011).

A Systematic Quality Model for Evaluating a Software Product is proposed by Oretega

et al. to asses a product’s efficiency and effectiveness (2003). The existing quality models

such as McCall, Boehm, FURPS, ISO 9126, Dromey and ISO 15504 were critically

evaluated to develop the proposed model. The model takes into account the quality

characteristics of the Dromey model and ISO 9126, McCall’s relationship between quality

characteristics and the metrics, and other quality metrics existing in the literature. The

Table 1 A summary of existing software security models

Domain Model Concern Description

Securitypolicymodels

Bell-LaPadulaModel

Confidentiality An access control model that is used to expressinginformation flow control requirements

Biba Integrity A model that enforces constraints on who has the right tomodify an object

ChineseWallmodel

Hybrid A model to support both confidentiality and integrity bysupporting modeling of conflict of interest in a businessenvironment

Role-basedaccesscontrol

RBAC Access control A generic access control model that is used specifiesaccess rights in terms of roles

34 Software Qual J (2015) 23:29–54

123

model attempts to incorporate both the process and the product dimensions of quality for

product evaluation. The model falls short of our desired objective of making explicit the

tangible properties of the low-level structures that ultimately influence the overall product

quality. Table 2 illustrates how different quality models do not always cover all aspects of

security and either consider the security partially or omit it all together.

2.4 Dromey’s quality model

Dromey states that it is impracticable to incorporate higher-level quality attributes directly

into a software product. For example, the quality attributes such as reliability or usability

cannot be built directly. Hence, there is a need for a comprehensive, consistent and im-

plementable set of product characteristics that can be called quality-carrying properties

(QCPs) against each higher-level quality attribute. These product characteristics are tan-

gible product properties that the relevant structural form (e.g., loop and variable) should

have in order to build quality into the software product. The existence of the product

properties in software will result in the implementation of the corresponding higher-level

quality attribute at code level. Therefore, there is a need that the software programmer

must link the product properties (QCPs) with the relevant structural forms and then in turn

with the relevant higher-level quality attribute.

In order to realize the need for building quality into the software product, Dromey

proposed a well-defined quality model (1995) in which the concept of integrating

quality into software product at code level is followed. It is a product quality model

which identifies that different products require different aspects of quality. Hence, a

more dynamic approach is required for proposing a model so that it must be assured

that the quality has been attained into the software product. The focus of the model is

on the relationship between the quality attributes and the sub-attributes. They also

attempted to connect product carrying properties with the upper level of software

quality attributes and lower level of software structural forms. In the Dromey model,

the emphasis is on creating explicit links between higher-level quality attributes,

quality-carrying properties and the underlying structural forms. This explicit link brings

clarity that can guide different groups of the users such as programmers, designers and

quality managers.

Table 2 Security in existing software quality models

Quality model Security attribute

McCall Integrity only

Boehm No

FURPS Functionality ? security

ISO-9126 Functionality ? security

Kitchenham No

COTS Functionality ? security

Cost estimation model Yes

Total quality model Functionality ? security

Dromey No

Software Qual J (2015) 23:29–54 35

123

2.4.1 Model overview

The motivation behind Dromey’s work (Dromey 1995) is that the software product does

not possess higher-level quality attributes (e.g., functionality and security) directly.

Instead, it exhibits certain product characteristics in the low-level components, which are

referred to as quality-carrying properties (e.g., accurate, assigned and encapsulated). Now

the linkage between quality attributes and product characteristics (QCPs) is a sensitive and

essential job of a quality model. Dromey provides a direct link between quality attributes

and the corresponding product characteristics (QCPs) for building quality into the software

product. A well-defined approach provides a clear linkage between higher-level quality

attributes (e.g., functionality and reliability) and lower-level quality-carrying properties

(accurate and assigned), and this process must be adaptable.

2.4.2 Model application

Product quality is determined by choice of components (SRS, software design and code)

that encompass the product. Dromey used the following steps to ensure quality in software

product:

• To identify and to classify component/structural form of the product.

• To identify relevant tangible quality-carrying properties for the omponent/structural

form identified above.

• To link these quality-carrying properties with the corresponding higher-level quality

attribute.

Consequently, software product quality is ensured by implementing quality-carrying

properties for each relevant structural form. Violation occurs by not implementing relevant

quality-carrying properties and thus as a consequence not achieving the related higher-

level quality attribute. Dromey’s product quality model works for designers by using top-

down perspective and for programmers by using bottom-up perspective (see below).

Dromey provided a well-defined process for building QCPs into a software product. These

QCPs are in turn linked with the relevant higher-level quality attributes. In short, Dromey

proposed a product quality model that sets up a lucid link between tangible QCPs and

intangible higher-level quality attributes.

An important advantage of this approach is that it can assist in conducting a systematic

search for quality defects. The model guides where to look for defects and also indicates

the quality-carrying properties whose violation will create defects in software product. This

information provides constructive guidance for identifying defects for any particular lan-

guage environment. In addition, the model assures the quality of software and provides

systematic classification of quality defects. The salient features of the model are that it has

enough methodology to characterize software product quality for large and complex sys-

tems and it will be practically possible to specify and to verify quality requirements.

36 Software Qual J (2015) 23:29–54

123

2.4.3 Model limitations

Although Dromey’s software quality model provides a systematic way to build and assess

the quality of software, however, there are some major limitations associated with this

model that are as follows: the model is abstract and does not adequately describe lower-

level details. Dromey has taken quality attributes from ISO 9126 and has not decomposed

these quality attributes into sub-attributes. For example, usability is an important quality

factor that must be decomposed into its sub-attributes, i.e., learnability and efficiency.

These sub-attributes have different desirable product properties (quality-carrying proper-

ties) for implementing these attributes at code level. Therefore, it is desirable to decompose

quality attributes into their sub-attributes. This limitation is also reported in (Jamwal 2010).

Additionally, the relationship between different model components is not clear. For

example, it is not clear how the quality-carrying properties classification helps in the

construction of the model and what role they play in the model application. Similarly, the

exact nature of relationship between various model components has not been described.

None or little work has been done to refine and apply Dromey’s product quality model to

individual quality attributes for building quality at code level. More specifically, there is no

evidence in the literature to suggest using Dromey’s model for software security, whereas

the demand of software security is increasing in every sector. Moreover, security is

sometimes in conflict with usability; therefore, there is a need to prioritize security vs.

usability depending on how much security is required as compared to usability. There is

little guidance provided by the Dromey model on how to address the problem of priori-

tization and conflict resolution among the competing quality attributes.

2.5 Security as a quality attribute

Security is commonly defined in terms of CIA, i.e., confidentiality, integrity and avail-

ability (Avizienis et al. 2000) but software security is not that simple a concept. Rather, it is

a complex domain that cannot be comprehensively defined solely in terms of CIA (Fire-

smith 2003). Further classification is necessary. One security decomposition has been

given by (Wang and Wulf 1997), in which security is decomposed in terms of confiden-

tiality and integrity attributes. These attributes are further decomposed in factors and then

in criteria and then further in metrics.

Wang and Wulf (1997) did not present the relationship with all security attributes in a

comprehensive way. However, they only addressed confidentiality and integrity and did

not provide the decomposition of availability. Additionally, security decomposition has

been provided in (Brito et al. 2002); nonetheless, this decomposition is highly abstract.

Brito et al. (2002) decomposed security into integrity and confidentiality only. Another

decomposition of the security attribute has been presented in a SEI technical report

(Barbacci et al. 1995). In this report, security is divided into CIA and then further into sub-

attributes in the form of internal and external factors. The report did not provide any

relationship between CIA and the internal/external factors.

A detailed information model on software security has been defined by Firesmith

(2003), in which security has been divided into classes and sub-classes. In this technical

note (Firesmith 2003), the author proposed a detailed set of consistent information models

Software Qual J (2015) 23:29–54 37

123

of safety, security and survivability engineering. Security has been defined as one of the

quality factors. The author decomposed security into many different quality sub-factors in

a comprehensive way. These sub-factors are further decomposed into more comprehensive

set of security sub-factors. In our proposed SQM, we use Firesmith’s information model

for security attributes and sub-attributes. This decomposition of security attribute into sub-

factors is shown in Fig. 1.

3 Security quality model

As stated earlier, our proposed SQM (see Fig. 2) is an extension of Dromey’s product

quality model (1995). In our attempt to construct the Dromey model for security, we faced

a number of challenges. We have introduced the following components in the model in

order to facilitate the construction of the model: security defects, structural forms with

defects, structural forms with defects, attack scenarios and security attributes. On the other

hand, we have omitted the classification of QCPs according to the correctness (internal and

contextual) and descriptive properties from the model. We did not find the classification

particularly useful in the context of security.

3.1 Security quality model components

The components of the proposed SQM and their relationship are illustrated in the Fig. 3.

The top-level component in the model is software security. We find the ISO 9126 definition

of software security very useful, which describes software security as the capability of the

software product to protect information and data so that unauthorized persons or systems

cannot read or modify them and authorized persons or systems are not denied access to

them (ISO-9126 1991).The software security is decomposed into sub-attributes as dis-

cussed in previous sections. These sub-attributes may further be decomposed into various

sub-attributes as required. Therefore, software security has one or more security attributes,

which may have zero or more security sub-attributes. For the sake of uniformity, we only

use two levels of decomposition, but this can be extended to any level of granularity. The

security (sub)-attributes are linked with one or more security-carrying properties (SCPs).

SCPs are those security properties of structural forms that influence the overall security of

the product. These properties are referred to quality-carrying properties in the Dromey

Model.

The structural forms are the building blocks of the product. They are generally the

lower-level components that exhibit important quality-carrying properties, which

Fig. 2 Basic view of software security model (SQM)

38 Software Qual J (2015) 23:29–54

123

contribute to the overall quality of the product. It is the modeler’s choice to select a

meaningful level of abstraction for a component. These structural forms are in turn linked

to the relevant SCPs. In this way, the model can be constructed using the top-down

approach. The identified security attributes can be linked with SCPs, and in turn, these

SCPs are linked with the underlying structural forms as shown in Fig. 3. For greater

flexibility, the model can also be constructed using a bottom-up approach. Security defects

along with the underlying structural forms are identified first. Attack scenarios may also be

identified to identify the fixes for the defects. These fixes can have one or more underlying

structural forms. Therefore, we differentiate between structural forms with defects and

structural forms for fixes. Once the structural forms having fixes are identified, these are

linked with SCPs and then to the relevant security (sub)-attribute. The SQM components

are listed in Table 3.

3.2 Security defects and QCPs

Consideration of defects plays a central role in the construction of the Dromey model. A

model is considered incomplete if it cannot classify a specific defect. That is, the classi-

fication of all the known defects in the model serves as completion criteria, while con-

structing the model. Defects are those properties of the structural form that detracts from a

particular desired quality attribute. For instance, not assigned is that property of a structural

form variable that detracts from achieving the quality attribute reliability. In order to

achieve reliability, we must incorporate the fix of this defect. Therefore, the structural form

variable must have a quality-carrying property assigned and create its link to the quality

attribute that it impacts—reliability.

Fig. 3 Conceptual framework for software security model (SQM)

Software Qual J (2015) 23:29–54 39

123

However, when we tried to apply the same concept to security, we faced a problem. A

defect related to a particular structural form can only be fixed by assigning quality-carrying

properties of some other structural form(s). For instance, the structural form input field in a

Web application may have a property incorrect type handling that detracts from achieving

availability quality attribute of security. However, the fix may have a check for type

constraint property for the structural form input validation method. In fact, through our

experience, we have found that a particular defect may have one or more fixes related to

structural forms other than the structural form carrying the defect. To address this chal-

lenge, we have introduced a new component security defect in our model and a structural

form associated with the defect called structural form having defects. The security defects

have SQP that detracts it from achieving one or more security quality attributes. The

security defects are also associated with the structural forms for fixes. The security defects

are fixed by the structural forms for fixes and have their independent SQPs that impact

high-level security quality attributes, as illustrated by the example below.

Table 3 The SQM components

Component Description

Software security The capability of the software product to protect information and data so thatunauthorized persons or systems cannot read or modify them and authorizedpersons or systems are not denied access to them (ISO-9126 1991)

Security attributes A well-defined decomposed quality attribute of software security

Security sub-attributes A well-defined decomposed quality attribute of one of the software securityattributes

Security-carryingproperty

A property associated with a structural form that influence the overall security of asoftware product

Attack scenario An event or series of steps that describe how an attack may be launched using thedefects in underlying structural form(s)

Security defect A defect in structural form that detract the software product from achievingsoftware security

Structural forms withdefects

The low-level software components that manifest one or more security defects

Structural forms forfixes

The low-level software components that manifest one or more fixes that influencepositively in achieving software security

40 Software Qual J (2015) 23:29–54

123

3.3 Attack scenarios

Another challenge we faced is that the vulnerabilities in systems are often exploited by the

attackers through the exploitation of complex attack scenarios. It is vital to understand this

complex attack scenario in order to determine how the exploitation of one or more security

defects has led to the compromise of one of the security quality attributes. For instance, it

may not be intuitively clear what quality attribute is impacted by having a not-strongly

typed input field. To understand the impact, we must understand and analyze the attack

scenario and how it impacts the system. Let us have a look at the following scenarios. One

of the common ways to compromise a Web application is through SQL injection attack

(Buehrer et al. 2005). The attack can be launched in a number of ways. One of the common

forms is to pass an incorrect parameter through user input field, say an un-escaped single

quote character.

In this case, an attacker can use this vulnerability as a tautology (‘1’ = ‘1’) and pass it

to the backend SQL query. When appended to any query, it will always be evaluated to be

true. If the tautology is passed with the query that matches username and password pro-

vided through the user input fields, then the query will always be successful. As a result, an

unauthorized user will be able to compromise the access control quality sub-attribute as it

will compromise not only identification but also the authentication and authorization by

giving the intruder access to restricted data. However, it is pertinent to note that the same

defect of not validating user input in the Web applications can be exploited in a number of

different ways, which may affect different security quality attributes. For instance, it can be

used for the deletion of entire tables through unchecked user fields. In this case, one of the

quality factors that will be impacted will be integrity. Similarly, the incorrect inputs can

also be used to crash the application, thereby, compromising the availability protection

quality attribute of security. To help identify the relationship between the structural form

defects and the quality attribute that is detracted because of the defect, we have introduced

a component attack scenarios that creates an explicit link between the defects and the

security attribute that it impacts. This linkage in the aforementioned examples may be

created as follows:

3.4 Security quality attribute classification

We do not prescribe any particular classification of security attributes and sub-attributes,

but we find the Firesmith classification and definition very useful for our model con-

struction. During the construction of the model, we found that sometimes a SQP impacts a

higher level of attribute and sometimes the impact is minimal as it influences a lower-level

quality attribute. If the username and password fields are susceptible to SQL injection

attack and as a result the attacker is granted access rights to the restricted information, then

Software Qual J (2015) 23:29–54 41

123

we say that all the sub-attributes of the quality attribute access control are detracted. So

instead of linking with all the three sub-attributes, it is sufficient to link the related SQPs to

the higher-level attribute access control. But if only username is accessed through the

attack, then we can link it to the lower-level sub-attribute identification. We believe that

this flexibility enhances the capability of the model to be more descriptive and brings

clarity while constructing the model. Therefore, we propose one or more levels of clas-

sification of quality attributes. However, to keep the model simple to describe, we have

restricted our discussion to two levels of decomposition in this paper.

3.5 Classification of quality-carrying properties

Dromey proposes classification of the quality-carrying properties according the impact of

QCPs on the product. According to Dromey, the impact of some of the QCPs is so

significant that the product will not work as intended if these properties are violated. Such

properties are referred to as correctness properties. Those correctness properties that are

associated with internal working of a structural form are referred to as internal properties,

whereas those properties that describe how a structural form interacts with other structural

forms or influences the behavior of other structural forms are classified as contextual

properties. Lastly, descriptive properties are those properties that add value to the product

by making it easy to understand and use for its intended purpose. Dromey associates

correctness properties with a product’s functionality and reliability while descriptive

properties are associated with maintainability and reuse. In the context of security, we

found it hard to classify the identified properties and found the classification of little help

during the construction of the model. Perhaps, there is a need to identify and classify

correctness and descriptive properties in the context of security. But with respect to the

proposed model, we have omitted this classification. We identify the exploration of use-

fulness of the classification as possible future work.

3.6 The SQM construction approaches

As discussed, SQM can be constructed by using either a bottom-up approach or a top-down

approach. There is a vast amount of literature that is available on known security defects.

For example, an extensive list of security threats and defects is presented in (Howard et al.

2006). Using this information, the SQM can be constructed using a bottom-up approach.

The first step is to identify a known security defect and find the underlying structural

form(s) associated with it. Next, we identify all possible fixes for the defects and identify

all the underlying structural forms associated with the fix of a particular security defect.

The security-carrying properties, which are prescriptive statements that negate the presence

of defects in the structural form, are identified in the next step. That is, the absence of the

properties would lead to the identified defects. In SQM, the defects play another important

role. They are used to identify those attack scenarios that exploit these security defects.

42 Software Qual J (2015) 23:29–54

123

These attack scenarios are then studied to identify the security (sub)-attributes that are

compromised because of the presence of the identified defect. A link is created between the

structural form having defect, the defect, the attack scenario and the affected security

(sub)-attributes. Another separate link is created between the defect and the fixes associ-

ated with it. The identified sub-attributes are then separately linked with each of the SCPs

that have been identified for structural form for fixes. These steps are described below:

SQM construction—the bottom-up approach

Step 1: Identify a security defect

Step 2: Identify structural forms associated with the defect identified in Step 1

Step 3: Identify all possible fixes for the defect identified in Step 1

Step 4: Identify structural forms for the fixes identified in Step 3

Step 5: Identify security-carrying properties for the structural forms for fixes identified in Step 4

Step 6: Generate attack scenario(s) that are possible due to presence of defect identified in Step 1

Step 7: Identify security (sub)-attributes that are affected by analyzing the attack scenarios generated inStep 6

Step 8: Create a link between the defect identified in Step 1, the attack scenario(s) identified in Step 6 andthe security (sub)-attributes identified in Step 7

Step 9: Create a link between structural forms for the fixes identified in Step 4, the security carryingproperties identified in Step 5 and the security (sub)-attributes identified in Step 7

Step10:

Repeat Steps 1–9 for all the know software security defects

In the same spirit as advocated by Dromey, the SQM can also be constructed with a top-

down approach. In the top-down approach, we start with a high-level security attribute and

decompose it into security sub-attributes. Then, we identify all the possible countermea-

sures and control that are known by the research or development community. From these

controls, we identify the security-carrying properties and the underlying structural forms

that are used to implement these controls. We then create a link between security attributes,

security sub-attribute, security-carrying property and the structural form that on which the

controls are implemented. For instance, if we identify access control as the security

attribute and identify authorization as its sub-attribute, then the known security controls

and countermeasures may include: passwords field must not display its contents, use two-

factor-authentication, and username password should not be the same, etc. In this case, the

underlying structural forms may be verify_User (username, password) method, which may

have a SQP Username and Password Must Not Be Same (see Table 6). The steps for

constructing the SQM using the top-down approach are listed below:

SQM construction—the top-down approach

Step 1: Identify a security attribute

Step 2: Identify all the security sub-attributes related to the security attribute identified in Step 1

Step 3: For all the security sub-attributes identified in Step 2, identify the known securitycontrols and countermeasures

Step 4: For each of the control and countermeasures identified in Step 3, identify theassociated structural forms

Software Qual J (2015) 23:29–54 43

123

Table b continued

SQM construction—the top-down approach

Step 5: Create a link between the structural form identified in Step 4, the SCPs in Step 3,the security sub-attribute in Step 2 and the security attribute identified in Step 1

Step 6: Repeat the Steps 1–5 for all the known security attributes

3.7 The SQM views

The constructed model can be viewed in using the same structure as the original Dromey

model. The model, viewed from left to right comprises of a single structural form (for

fixes) linked to one or more security-carrying property, which in turn is linked with

security attributes and sub-attributes. The transient data needed to generate the SQM view

can stored in the form of tables as illustrated in Tables 4 and 5. This transient data include

data generated from Steps 1–10 and Steps 1–6 of the model construction used during

bottom-up and top-down approaches, respectively. While these data are useful for the

creation of the model, they are cumbersome and perhaps uninteresting in the final con-

structed view of the model.

As a proof of concept, we illustrate how the model can be constructed using the

approaches outlined above. We use a well-known security flaw that is prevalent in many

Web applications to construct the model using bottom-up approach. Later, we give an

example of construction of the model using top-down approach using trivial and well-

known security controls for security attribute access control. The SQL injection attack used

as a proof concept for the model construction is thoroughly discussed in the literature

(Buehrer et al. 2005). A brief description of the defects that lead to SQL inject attack and

some of its manifestations are briefly discussed here. A SQL injection attack is typically

used against data-driven Web applications. A part of a structured query language (SQL) is

passed through a user input field in the application. If appropriate checks are not used, this

illegitimate query returns data to that was not intended by the Web application. If the

attack is successful, then a user can incorrectly be verified as an authorized user, dump

confidential data to the attacker or provide database structural information that can be used

by the attacker to launch further attacks. As a simple example, consider the case of

incorrectly filtered escape characters that can be used to launch a SQL attack. If the user

input is not control to stop escape characters, then this input can be used to manipulate

SQL statements. The following SQL query matches the username passed through the input

field and stored in the variable userName. If the value of the variable userName matches

any name in the table users, then that tuple is returned. If there is no match, the query

returns null.

However, if the following malicious value is passed through to the userName variable

via the input field, then it would change the overall SQL statement.

As a result of this value passed through the user input field, the reconstructed SQL looks

like as illustrated below.

44 Software Qual J (2015) 23:29–54

123

Now, this query will always return a tuple from the database because the result of the

query will always be true as it is appended by a statement (OR ‘1’ = ‘1’), which obviously

will always be true. If this code is part of the authentication process, then the authentication

of the user will be bypassed by the system and the attacker will be authenticated as an

authorized user. This vulnerability in the data-driven Web applications can be exploited in

number of ways. Here, we use SQL injection as an example to construct the model.

Similarly, other malicious input can be passed to a SQL query to get data dumps of various

natures. The details of each type of SQL injection attack is beyond the scope of this paper.

3.8 Bottom-up approach

We begin construction of the model by using the example illustrated above. The first step

in constructing the model using the bottom-up approach is identification of a security

defect. We identify the defect as passing of single quote character in the user input field

(Step 1). The structural form associated with this defect is the user input field (Step 2). The

study of literature tells us that one of the ways to fix this defect is through the use of an

inputValidationMethod. This method is used to filter out undesirable input that may be

Table 4 Bottom-up approach (Steps 1–5)

No. Defect Structuralform withdefects

Structuralforms forfixes

Security-carryingproperties

Quality attribute

1. Incorrect typehandling of userinput

Input field Input field Strongly typed Availability protection

Inputvalidationmethod

Typed constraintsenforced

Availability protection

2. SQL keywordspassed throughuser input

Input field Inputvalidationmethod

Reject SQLkeywords

Availability protection,SW integrity,confidentiality

3. Single quotationmarks passedthrough user input

Input field Inputvalidationmethod

Replace singlequotes withdouble quotationmarks

Availability protection,SW integrity,confidentiality

4. SQL commentcharacters passedthrough user input

Input filed Inputvalidationmethod

Reject SQLcommentcharacters

Access control,availability projection,integrity,confidentiality

Table 5 Bottom-up approach (Steps 6–7)

No. Defect Structural form Attack scenario Quality attribute

1. Incorrect type handling Input field Tautology parameter Passed Access control

2. Incorrectly filtered keyword Input field Drop table command passed SW integrity

DELETE command Passed SW integrity

SELECT command passed Confidentiality

Software Qual J (2015) 23:29–54 45

123

passed through the user input field, including passing of single quotation marks as in our

example (Step 3). Therefore, we identify the structural form used to fix the defect as

inputValidationMethod (Step 4). One of the properties associated with this structural form

is that it should reject single quotes (Step 5). Additionally, the structural form user input

field (Step 4) should also have the property as inputValidationMethod (Step 5). This way

we have two different structural forms associated with a single defect. Each one of them

has a different property associated with it by merely looking at these properties, and it may

not be easy to identify which security attribute may be linked with them.

Therefore, we need to understand how this vulnerability is exploited by an attacker

(Step 6). One of the attack scenarios may be that the attacker inputs the tautology

(‘1’ = ‘1’) in the password field. By doing so, the SQL query is mutilated in a manner that

the user can be incorrectly authenticated. If there had been a check on user input field that

would reject passing of single quotation mark as an invalid user input, then the query

would not have executed. Therefore, we identify one of the attack scenarios as bypass

authentication (Step 7). Another attack scenario associated with this attack is bypass

identification (Step 7). Now, it is easier to identify the two security sub-attributes identi-

fication and authentication that are affected by the defect in question. These sub-attributes

are in turn associated with the security attribute access control (Step 7). As a result of

completing the aforementioned Steps 1–7, we are able to create the following links. This

relationship can also be captured in a table format as presented in Table 4. Using these

data, we can generate the SQM view similar to the Dromey model as illustrated in Fig. 4.

Let us look another example. Using the same approach, an attacker can inject a more

malicious code to delete the entire table from the database by appending the SQL query

with the DROP TABLE command. The applications that are prone to SQL inject attack can

easily reveal the underlying database structure. Once the attacker has the knowledge of the

database tables and its fields, he/she can then use this information to change the database.

Instead of entering the tautology described in the previous example, the attacker can enter

the following SQL command in the user input field:

This command when appended with the SQL query that checks for a match between the

user-supplied name and the username in the users table would delete the entire users table.

The query appends [a’] with the original query, which forces the SQL to consider the

46 Software Qual J (2015) 23:29–54

123

original query to be complete and then append another SQL statement, which is separated

with a semicolon. This new statement drops the table from the database. The attack was

possible because there were no validation checks on the user input field. The problem can

be fixed by filtering out the single quotation marks from the user input and perhaps by

strongly typing the user input field, which would only allow the desired type of input.

Again, for simplicity, we do not discuss other fixes such as disallowing multiple SQL

statements.

To incorporate this defect into the model, we follow the following steps. We identify the

defect as passing of single quote character in the user input field. The structural form in

question is again user input field. To fix the problem, the user input is validated through the

inputValidationMethod, which should have the property reject single quotes as in the

previous example. Similarly, the user input field would have the same property as input-

ValidationMethod. Additionally, we also identify another property strongly typed. The

strong typing of the input field would help reject undesirable characters such as semicolon.

However, when we generate the attack scenario, we realize that the two different security

attributes are compromised as a result of this attack. When the table is dropped (i.e.,

deleted from the database), both the data integrity and availability protection are com-

promised. The resultant SQM view is illustrated in Fig. 5.

A slightly more advanced attack can be launched using the input injection method. A

complex query can be created by passing a SQL statement that uses UNION command,

which is used to combine two or more SELECT statements. In this way, two or more SQL

statements can be executed, and they may not have anything in common. One query may

return product details form products table, and the other may return user details from users

table. Let us consider the following example. A universal resource locator (URL) is often

used to extract data from databases as illustrated below. The URL is used to extract product

details for the product whose ID is 123 (productid = 123). This user input if appended by

the UNION keyword followed by the SQL SELECT statement as illustrated below would

return the usernames and passwords from the users table. Here, the user input

Fig. 4 SQM view 1

Software Qual J (2015) 23:29–54 47

123

productid = 123 is appended with the UNION statement. The resulting SQL query would

be transformed as follows:

The most common way to validate the URL user input field. The input field must be

filtered for SQL keywords such as UNION, SELECT and xp_. Therefore, to address the

problem, we identify another property of inputValidationMethod: reject SQL keywords.

The attack when launched can potentially reveal confidential data. Therefore, we link the

SCP with confidentiality sub-attribute. Confidentiality is in turn linked with privacy. The

resulting SQM view is depicted in Fig. 6. We have applied the approach to identify a

number of SQL injection attacks. A snapshot of the structural forms inputValidation-

Method, and input variable is provided in Figs. 7 and 8.

3.9 Top–down approach

In order to prove that our SQM is rigorous and repeatable, we have also verified the

proposed model by using top-down approach. Basically, this approach is more suitable for

software designers who typically view security from a top-down perspective (high-level

perspective). By applying this approach, we have identified set of possible SCPs against

each security attribute/sub-attribute. Initially, we congregated a number of existing solu-

tions for implementing each of the security attributes and sub-attributes. Subsequently, we

identified the relevant structural forms for fixes by carefully examining the existing

solutions gathered earlier. The most critical phase was the identification of SCPs against

these structural forms for fixes. We examined each structural form (for fixes) and identified

the relevant SCPs against each security attributes and sub-attributes. These SCPs are then

in turn linked with relevant security defects and then with the structural forms having

Fig. 5 SQM view 2

Fig. 6 SQM view 3

48 Software Qual J (2015) 23:29–54

123

defects. By using this approach, the designers can embed the security attributes and sub-

attributes into the software product by implementing the relevant SCPs in the design of

software.

Let us consider the security attribute, access control (Step 1). One of the sub-attributes

of the access control is authentication (Step 2). A number of controls exist that support the

quality attribute authentication (Step 3). These include controls such as passwords field

should not display its contents; use of CAPTCHA codes to ensure human interaction;

forcing users to change passwords periodically; and use of question-answers for second

level of authentication. We use these control to identify associated structural forms (Step

4). One of the structural forms associated with authentication is the password field. The

SCP associated with the password field is that it should not display its contents. As a last

step, we link password field with the SCP ‘Do Not Display Contents,’ which is linked with

the security sub-attribute authentication. The sub-attribute authentication is then linked

with its parent attribute, access control (see Fig. 9). We repeat the process until all the

known controls are mapped unto the underlying structural forms and their associated SCP

(Table 6).

Fig. 7 Snapshot of the structural form input validation method

Fig. 8 Snapshot of the structural form input variable

Software Qual J (2015) 23:29–54 49

123

4 Automation of SQM

We envisage an automated tool to support the development of software according to the

desired security levels of an application. The tool, integrated into the development envi-

ronment, would have a layered architecture. An overview of the proposed architecture is

presented here. The identified structural forms and their associated SCPs are constantly

updated through research and are stored in a (ideally third party) centrally maintained

database. The compatible and decentralized integrated development environments (IDEs)

are configured to receive the updated SCPs and their details on regular basis. The IDEs can

also be configured according to the need of a particular application. The IDE will guide the

programmer about the available SCPs when using any of the associated structural forms. An

audit report can then be generated based on the SCPs selected or ignored by the programmers

to assess the level of security implemented in an application. The update of the SCPs and

associated details in an IDE is performed in the same spirit as update of signatures in anti-

virus software. Such a tool would be useful for (a) quality managers, (i) to set the desired

level of security in a development project and (ii) to generate audit reports to check how

much the desired security level is achieved; for (b) programmers, (i) to tune their IDEs to

retrieve the security QCPs from the local database (LDB), which is called QCPs retrieval,

and (ii) to check in those QCPs they have implemented in a structural form. The process will

be applied to each structural form used in a project. This process is called QCPs configu-

ration. Our current work also includes developing a compatible usability quality model.

5 Conclusion

In this paper, we have presented a software security quality model whose purpose is to build

security into software products. The model is a useful tool for programmers because it

Table 6 Top-down approach (Steps 1–5)

Securityattribute

Sub-attribute Security controls Structuralforms

SCP

Accesscontrol

Authorization,authentication,identification

Hide typed characters in thepassword input field

Input field Do not displaycontents

Use verify_User Method forauthorization, authentication,identification

Input field Must haveverify_UserMethod

User name password must not bethe same

Verify_UserMethod

Username andpassword must notbe the same

Use two-factor authentication Verify_UserMethod

Use PIN and useridentificationnumber

Fig. 9 Authentication linked with its parent attribute access control

50 Software Qual J (2015) 23:29–54

123

enables them to verify that adequate security has been achieved by ensuring that the

required properties are built into the product. The model also allows quality managers/

engineers to audit a software product. The model is an extension of the Dromey quality

model. We preferred Dromey’s model over others because it addresses the core issue of how

to build quality into a product by creating explicit links between underlying structural forms

and the properties of these structural forms that exhibit quality. These properties are then

linked to high-level quality attributes. This linkage differentiates Dromey’s model from

other models as it brings a degree of clarity to how the abstract quality attributes manifest

themselves in a product. However, while adopting the model for security, we faced a

number of significant challenges. The identification of structural forms and their properties

that help achieve security turned out to be a nontrivial task. Similarly, the identification of

defects and their fixes was difficult, as defects in one structural form were fixed by adding

some characteristics in another structural form. The link between the security-carrying

properties and the security attribute was also difficult to identify as the nature of attack

would determine which security attribute is affected by a particular defect. To this end, we

added several new model components: security defects, structural forms with defects, attack

scenarios and security attributes. We also provide a detailed guideline on how to construct a

model. As a proof of concept, we have used known security defects and security controls to

construct the model using both the bottom-up and top-down approaches.

We acknowledge that constructing a complete model is a nontrivial task that extends beyond

the scope of a single paper. Nonetheless, we propose an automation of SQM where a central

repository of structural forms, their security-carrying properties and the associated security

attributes are stored as signature files. This repository can be built by research or the industrial

community. The signature files can be downloaded onto local servers in the development

environment, and the local IDE’s can be configured for desired security attributes. When a

programmer uses a structural form, the IDE can prompt him/her for the associated properties

that may be then selected. This way a record of the properties can be kept, and these can be used

by the quality engineers for audit purposes. Our future work includes investigating a detailed

architecture of such an automated environment. We are also investigating the practical issues in

constructing models for other quality attributes such as usability. Our future work includes

development of a complete architecture for automation of SQM.

Acknowledgments We are greatly indebted to (late) R. G. Dromey for his insight into developing theproposed model during personal conversations. We also acknowledge the contribution of our colleagues atSecure and Dependable Systems Research Group at Riphah International University. In particular, we wouldlike to acknowledge the contribution of Asif Jilani, Farzana Yousaf and Umra Naeem who helped theauthors during the development of the model.

References

Al-Qutaish, R. E. (2010). Quality models in software engineering literature: An analytical and comparativestudy. Journal of American Science, 6(3), 166–175.

Anderson, R. (2008). Security engineering: A guide to building dependable distributed systems (2nd ed.).London: Wiley.

Avizienis, A., Laprie, J.-C., & Randell, B. (2000). Fundamental concepts of dependability. In Proceedings of3rd information survivability workshop, pp. 7–12.

Balfanz, D., & Simon, D. R. (2000). WindowBox: A simple security model for the connected desktop. Paperpresented at the proceedings of the 4th conference on USENIX windows systems symposium, Vol. 4, Seattle.

Barbacci, M., Klein, M. H., Longstaff, T. A., & Weinstock, C. B. (1995). Quality attributes. Technical reportCMU/SEI-95-TR-021, ESC-TR-95-021.

Software Qual J (2015) 23:29–54 51

123

Bell, D., & Lapadula, L. (1976). Secure computer system: Unified exposition and MULTICS interpretation.http://csrc.nist.gov/publications/history/bell76.pdf.

Biba (1977). Integrity Considerations for secure computer systems. MITRE Co., technical report ESD-TR76-372.

Boehm, B. W. (1978). Characteristics of software quality. Amsterdam: North-Holland Pub Co.Brewer, D. F. C., & Nash, M. J. (1989). The Chinese Wall security policy. In Security and privacy,

Proceedings of IEEE symposium on, 1–3 May 1989, pp. 206–214. doi:10.1109/secpri.1989.36295.Brito, I., Moreira, A., & Araujo, J. (2002). A requirements model for quality attributes. In Proceedings of

early aspects: Aspect-oriented requirements engineering and architecture design, Amsterdam.Buehrer, G., Weide, B. W., & Sivilotti, P. A. G. (2005). Using parse tree validation to prevent SQL injection

attacks. Paper presented at the proceedings of the 5th international workshop on software engineeringand middleware, Lisbon.

Dromey, R. G. (1995). A model for software product quality. Software Engineering, IEEE Transactions on,21(2), 146–162. doi:10.1109/32.345830.

Dromey, R. G. (1996). Cornering the Chimera [software quality]. Software, IEEE, 13(1), 33–43. doi:10.1109/52.476284.

Ferraiolo, D. F., Sandhu, R., Gavrila, S., Kuhn, D. R., & Chandramouli, R. (2001). Proposed NIST standardfor role-based access control. ACM Transactions on Information and System Security, 4(3), 224–274.doi:10.1145/501978.501980.

Firesmith, D. G. (2003). Common concepts underlying safety, security, and survivability engineering.Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University.

Franch, X., & Carvallo, J. P. (2003). Using quality models in software package selection. Software, IEEE,20(1), 34–41. doi:10.1109/ms.2003.1159027.

Gordon, L. A., Loeb, M. P., & Sohail, T. (2003). A framework for using insurance for cyber-risk man-agement. Communications of the ACM, 46(3), 81–85. doi:10.1145/636772.636774.

Grady, R. B., & Caswell, D. L. (1987). Software metrics: Establishing a company-wide program. New York:Prentice-Hall Inc.

Hofheinz, D., & Unruh, D. (2008). Towards key-dependent message security in the standard model. Paperpresented at the proceedings of the theory and applications of cryptographic techniques 27th annualinternational conference on Advances in cryptology, Istanbul.

Howard, M., LeBlanc, D., & Viega, J. (2006). 19 Deadly sins of software security. New York City:McGraw-Hill Inc.

ISO-9126, I. I. S. (1991). Software product evaluation–quality characteristics and guidelines for their use.Jamwal, D. (2010). Analysis of software quality models for organizations. International Journal of Latest

Trends in Computing, 1(2).Joshi, J. D., Ghafoor, A., Aref, W., & Spafford, E. (2002). Security and privacy challenges of a digital

government. In W. McIver Jr & A. Elmagarmid (Eds.), Advances in digital government, advances indatabase systems (Vol. 26, pp. 121–136). Berlin: Springer.

Kitchenham, B. (1987). Towards a constructive quality model. Part 1: Software quality modelling, mea-surement and prediction. Software Engineering Journal, 2(4), 105–126. doi:10.1049/sej:19870014.

Kraemer, S., & Carayon, P. (2007). Human errors and violations in computer and information security: Theviewpoint of network administrators and security specialists. Applied Ergonomics, 38(2), 143–154.doi:http://dx.doi.org/10.1016/j.apergo.2006.03.010.

Kshetri, N. (2006). The simple economics of cybercrimes. Security & Privacy, IEEE, 4(1), 33–39. doi:10.1109/msp.2006.27.

Landwehr, C. E., Heitmeyer, C. L., & McLean, J. D. (2001). A security model for military message systems:retrospective. In Computer security applications conference, 2001. ACSAC 2001. Proceedings 17thannual, 10–14 Dec. 2001, pp. 174–190. doi:10.1109/acsac.2001.991535.

Lodderstedt, T., Basin, D. A., & Doser, J. (2002). SecureUML: A UML-based modeling language for model-driven security. Paper presented at the proceedings of the 5th international conference on the unifiedmodeling language.

McCall, J. A., Richards, P. G., & Walters, G. F. (1977). Factors in software quality. AD-A049-014, 015, 055(Vol. 1–3). Springfield, VA: NTIS.

McGraw, G. (2006). Software security. In Building security in. Boston: IEEE security and Privacy.Mouratidis, H., & Giorgini, P. (2007). Integrating security and software engineering: Advances and future

visions. Hershey, PA: Idea Group Pub.Mouratidis, H., Giorgini, P., & Manson, G. (2005). When security meets software engineering: A case of

modelling secure information systems. Information Systems, 30(8), 609–629. doi:http://dx.doi.org/10.1016/j.is.2004.06.002.

52 Software Qual J (2015) 23:29–54

123

Nagaratnam, N., Janson, P., Dayka, J., Nadalin, A., Siebenlist, F., Welch, V., et al. (2004). The securityarchitecture for open grid services. Paper presented at the global grid forum recommendation draft.

Ortega, M., Perez, M., & Rojas, T. (2000). A model for software product quality with a systemic focus. InProceedings of 4th world multi conference on systemic, cybernetics and informatics SCI 2000 and Inproceedings of 6th international conference on information systems, analysis and synthesis ISAS 2000,Orlando, FL, pp. 395–401.

Ortega, M., Perez, M., & Rojas, T. (2003). Construction of a systemic quality model for evaluating asoftware product. Software Quality Control, 11(3), 219–242. doi:10.1023/a:1025166710988.

Rawashdeh, A., & Matalkah, B. (2006). A new software quality model for evaluating COTS components.Journal of Computer Science, 2(4), 373–381.

Sidiroglou, S., Giovanidis, G., & Keromytis, A. D. (2005). A dynamic mechanism for recovering from bufferoverflow attacks. Paper presented at the Proceedings of the 8th international conference on InformationSecurity, Singapore.

Tawfik, S. M., Abd-Elghany, M. M., & Green, S. (2007). A software cost estimation model based on qualitycharacteristics. Paper presented at the proceedings of workshop on measuring requirements for projectand product success (MeReP ‘07), Palma de Mallorca.

Tomar, A. B., & Thakare, V. M. (2011). A systematic study of software quality models. InternationalJournal of Software Engineering & Applications, 2(4), 1–61.

Wang, C., & Wulf, W. A. (1997). A framework for security measurement. In Proceedings of the nationalinformation systems security conference (NISSC), Baltimore, MD, pp. 522–533.

Younan, Y. (2003). An overview of common programming security vulnerabilities and possible solutions.Belgium: Vrije Universiteit Brussel.

Author Biographies

Saad Zafar obtained his PhD and MS in Software Engineering fromGriffith University, Brisbane Australia. He has started his professionalcareer working as Software Engineering and Information Technologyconsultant in the USA and Pakistan, respectively. He started histeaching career in 1996. His areas of interest include software engi-neering with a focus on requirements engineering and informationsecurity. He has also developed interest in other related fields ofsoftware engineering including software quality. Currently, he isworking as Dean, Faculty of Computing, Riphah International Uni-versity, Pakistan since 2007. He is also Certified Information SystemsAuditor and Certified Information Security Manager by InformationSystems Audit and Control Association (ISACA). Dr. Saad Zafarprovides Information Technology and Information Systems Auditingtraining and consultancy to the industry on regular basis.

Misbah Mehboob completed the MS degree in software engineeringfrom International Islamic University, Islamabad, Pakistan, in 2012.Her research interests include software engineering, software securityand network security. In particular, she is currently working onapplication security.

Software Qual J (2015) 23:29–54 53

123

Asma Naveed is currently serving as Asst. Professor in FoundationUniversity, Islamabad and a student of MS program in Riphah Inter-national University, Islamabad. New venues in the field of SoftwareEngineering have always been attracting her, sparking her research, todeepen her understanding and knowledge of this sea of innovation. Indoing so, she has gleaned a deeper insight into area of RequirementEngineering. Her professional career covers about twelve years in thepublic and private sectors, having nurtured the youth pertaining to alllevels of computer education. Asma Naveed is a passionate researcherof Software Engineering. Her areas of interest are Software quality,methods for software verification and validation with special focus onefficiency and effectiveness of method.

Bushra Malik obtained her MS in Software Engineering from RiphahInternational University (RIU), Pakistan in 2011. She is currentlyworking as a Lecturer and serving RIU since 2011. Her area of interestis Software Engineering with a strong focus on Software EngineeringEducation.

54 Software Qual J (2015) 23:29–54

123