Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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: [email protected]; [email protected]
S. Zafare-mail: [email protected]
M. MehboobInternational Islamic University, Islamabad, Pakistane-mail: [email protected]
A. NaveedFoundation University College of Liberal Arts and Science, Islamabad, Pakistane-mail: [email protected]
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