2009 International Conference on Computational Science and Engineering

Activity and Artifact Views of a Secure Software Development Process

Muhammad Umair Ahmed Khan and Mohammad Zulkernine

School of Computing, Queen’s University, Kingston, Ontario, Canada, K7L3N6
{umair, mzulker}@cs.queensu.ca

Abstract their sequence of execution (referred to here as activity

view). However, an activity view may not capture
The number of security errors and vulnerabilities many important aspects of the process, e.g., activities
can be reduced if a secure software development may not be directly dependent on other activities for
process (SSDP) is followed. Such a SSDP must cater their execution. In fact, activities depend on artifacts
for security aspects during each phase of development. that are produced or modified by other activities.
In this paper, we present a new process that provides Moreover, some artifacts depend on other artifacts. To
ways of addressing security concerns and represent these dependencies, we introduce the concept
incorporating security decisions throughout the of an artifact view. An artifact view of a SSDP
software development process. Our process has two elaborates on the artifact-artifact and activity-artifact
views: activity and artifact. The activity view presents relationships.
development activities performed during requirements Our SSDP has both the activity and artifact views
engineering, design, implementation, and assurance and covers the requirements engineering, design,
phases. The artifact view, on the other hand, identifies implementation, and assurance phases. Each of the
the relationships among the various SSDP artifacts phases in our SSDP has a set of development activities
that are produced during development. that ought to be performed in the specified sequence
(activity view). The artifact-artifact and artifact-
1. Introduction activity relationships of the artifacts resulting from
these activities are presented in the artifact view. Our
Within current software security practice, during the proposed SSDP provides guidance in finding errors
final stages of development (assurance or testing), that may lead to security vulnerabilities and helps to
various techniques (e.g., penetration testing) are used identify security requirements to remove these errors.
to reveal any security vulnerabilities that the software The rest of this paper is organized as follows.
might have. The identified security vulnerabilities are Section 2 defines some of the terms related to software
removed by revisiting and correcting requirements, security. Section 3 provides the related work. Section 4
design, and code. If the software is already released or elaborates the activity view, while Section 5 presents
deployed, a patch is developed [1]. Moreover, security the artifact view of our proposed SSDP. Section 6
requirements are usually kept separate and are not concludes this paper by summarizing the work.
interweaved with the functional requirements and
design. This leads to inconsistencies and ambiguities. 2. Preliminaries
Given that, it is essential that the software is developed
in a secure fashion from the beginning. Hence, it is Many terms used in software security are also
required to have a repeatable secure software employed in other fields of software engineering with
development process (SSDP) which addresses security varying meanings. Here, we explain some of these
aspects during each phase of software development. terms used in this paper.
Most of the SSDPs proposed in the literature do not Software security error: The term error has been
include adequate secure software development very rarely used in software security literature. Most of
activities. Therefore, in this paper, we propose a new the authors use the term vulnerability and do not
SSDP that includes necessary secure software distinguish between vulnerability and error. Sometimes
development activities that are essential to achieve the term flaw is also used instead of error [2]. A
more secure software. Existing SSDPs focus on the software security error is a tangible manifestation of a
development activities that need to be performed and mistake in any of the software development life cycle
(SDLC) artifacts (requirement specifications, design,

978-0-7695-3823-5/09 $26.00 © 2009 IEEE 399

DOI 10.1109/CSE.2009.383
or source code) of a piece of software that leads to a modeling during the requirements engineering phase.
vulnerability [2-4]. A software security error can be Risk analysis is performed on informally identified
one of the following if it is related to security threats: risks/threats. MS SDL also does not suggest the use of
(1) a requirement specification error (an incorrect or security specification languages to represent security
missing requirement in the requirement specifications requirements and secure design decisions. Moreover,
due to a mistake made in the requirement engineering for the requirements engineering and design phases,
phase of the SDLC), (2) a design error (an incorrect MS SDL does not endeavor to identify security errors
logical decision, the decision itself or the and specify security requirements to remove these
representation of a decision, in the design due to a errors. MS SDL is similar to our process in many
mistake made in the design phase of the SDLC), or (3) aspects such as performing risk analysis multiple
a source code error (an incorrect representation of the times, modeling threats during design, specifying
design decisions in the source code due to a mistake security mechanisms during the requirements
made in the implementation phase of the SDLC). engineering phase, following secure design guidelines
Software error: A software error is a superset of and secure coding standards, and performing multiple
software security error. The only difference is that assurance activities.
while a software security error leads to a vulnerability, Comprehensive, Lightweight Application Security
a software error results in undesired functional Process (CLASP) [10] is different from our process as
behavior which may not be related to security. it does not perform any activity to identify software
Software security vulnerability: A software security errors during requirements engineering and
security vulnerability is the result of a software design phases. Consequently, it does not specify
security error [3]. security requirements to remove such errors. CLASP
Software security requirement: A software also does not suggest using security specification
security requirement [4], sometimes also referred to as languages to represent security requirements and
a countermeasure or safeguard [5-7], can be defined as secure design decisions. CLASP proposes annotating
a requirement needed to avoid a specific software only the class diagram with security information. It is
security error during development. A software security similar to our SSDP in the following ways. It
requirement can be specified for any SSDP artifact [4]. advocates performing risk analysis and threat modeling
Consequently, a security requirement can be a during both requirements engineering and design
requirement specified during the requirements phase or phases. CLASP also specifies security mechanisms
a design decision made during the design phase. For early in the requirements engineering phase. It suggests
the implementation phase, the security requirements that secure design guidelines and secure coding
would be the secure coding standards and guidelines. standards be followed. In the assurance phase, CLASP
proposes to perform inspections, static code analysis,
3. Related work and security testing. CLASP is the only existing
process that has multiple views. The activity-
The seven touch points identified in McGraw’s assessment and activity-implementation views, when
software development lifecycle process [8] are combined, are similar to the activity view suggested in
different from our process in that they do not include this paper (and other SSDPs). While the rest of the
threat modeling in any phase. Moreover, security CLASP views are important, none of them is
requirements (and mechanisms) are not incorporated comparable to the artifact view presented here as part
from the beginning and are specified based on the of our SSDP.
results of the assurance phase. McGraw also does not The major distinction between Appropriate and
specify the use of security specification languages, Effective Guidance for Information Security (AEGIS)
secure design patterns, or secure coding standards. [11] and our process is that AEGIS only focuses on the
McGraw’s touch points are similar to our process with requirements and design phases and does not specify
respect to the assurance phase (both advocate any secure development activity for the other phases.
performing static analysis and penetration testing). Our Moreover, it does not propose the use of security
process has specification-based security testing as specification languages and secure design guidelines.
compared to risk-based security testing in McGraw’s Similar to our process, AEGIS suggests identifying
touch points. Moreover, we both propose performing security vulnerabilities (not errors) and threats. How
risk analysis multiple times. threats should be identified is not mentioned. Risk
Trustworthy Computing Security Development analysis is carried out multiple times and security
Life Cycle or Microsoft Software Development Life requirements to remove the identified vulnerabilities
Cycle (MS SDL) [9] does not perform formal threat are also specified.

400
Phase
R1.Specification of functional requirements R2.Conducting inspections to identify software errors
Requirements If required
Engineering R9.Security assessment of the requirements specifications R3.Conducting threat modeling
R4.Risk analysis on threats
If the security index If the security index is less than the threshold
R5.Specification of high-level security requirements
is greater than or R6.Selection and specification of security mechanims
equal to the threshold R10.Specification of low-level security requirements R7.Propritization of security requirements
R11.Prioritization and inclusion of low-level security requirements R8.Conducting inspections from a security perspective

D1.Specification of the functional design D2.Conducting inspections to identify software errors

Design If required
D8.Security assessment of the design D3.Enhancing the threat model
D4.Risk analysis on threats
If the security index If the security index is less than the threshold D5.Design decisions to mitigate threats
is greater than or D6.Propritization of design decisions
equal to the threshold D7.Conducting inspections from a security perspective
D9.Specification of low-level security requirements
D10.Prioritization and inclusion of low-level security requirements

Implementation I1.Selecting a secure programming language

I2.Following secure coding standards and guidelines
I3.Unit testing

Assurance A1.Code inspections and static analysis

A2.Generating test cases
A3.Integration, acceptance, and penetration testing

Figure 1. Activity view of the SSDP

Secure Software Development Model (SSDM) [12] 4.1. Requirements engineering phase
focuses mainly on the requirements engineering phase.
It does not propose any design or implementation It has been estimated that an error introduced in the
phase activity. The only activity for assurance is requirements engineering phase, if not removed
penetration testing. SSDM is similar to our process immediately, can cost up to 200 times more to correct
only with respect to modeling during the requirements in later stages of development [15]. It can be assumed
engineering phase. that correcting a software security error will be equally
Secure Software Development Process Model expensive. Hence, this phase must receive special
(S2D-ProM) [13] is a strategy-based SSDP. For attention and have the following activities to derive
advancing from one development phase to the next, complete functional and security requirements.
S2D-ProM proposes multiple alternate strategies. R1. The behavior and deployment environment of
These strategies are very high-level, e.g., use of the software should be specified using use cases along
personal experience. with detailed functional requirements (diagrams/text).
None of the existing SSDPs presents an artifact R2. The requirements specifications ought to be
view. A comparative study of many existing SSDPs is inspected (multiple times, if required) for identifying
presented in [14]. and removing software errors.
R3. Abuse cases should be specified. Information
4. Activity view of the SSDP about software assets, attackers, attackers’ interests,
attackers’ resources, attack surfaces, and threats to
The SSDP addresses requirements engineering, existing software of the same domain must be
design, implementation, and assurance phases. This collected. A threat model can be developed in light of
process can be used as a sequential (waterfall) or an the aforementioned information.
iterative (spiral) process for development. Moreover, it R4. Risk analysis should be performed on the
contains both functional and secure software identified threats to calculate the collective potential
development activities (e.g., specification of use cases damage that each of them can cause to different assets
vs. specification of abuse cases). The activity view [4]. This information can be used to prioritize threats.
presents the development activities for each of the R5. High-level security requirements such as
phases and the sequences in which they should be preservation of confidentiality, integrity, and
performed (Fig. 1). In the following subsections, we availability should be specified to mitigate identified
elaborate on these activities. threats. Specification languages that can represent

401
security requirements (e.g., UMLsec [1]) may be used D4. Risk analysis should be performed on the
to specify these security requirements. identified threats to calculate the potential damage that
R6. It may be possible that more than one security each of the threats can cause.
mechanisms is able to fulfill a security requirement. D5. Security requirements (secure design
Moreover, different security mechanisms can offer decisions) must be identified for threats that violate
varying levels of assurances. The implementation and any of the high-level security requirements. There
social cost (e.g., usability) of a security mechanism could be multiple design decisions to mitigate any
might also be different. An appropriate security threat (similar to Step R5). Moreover, further security
mechanism should be selected by considering the mechanisms could also be incorporated.
above mentioned issues. Detailed functional D6. Secure design decisions to remove threats can
requirements (e.g., strength of the password) must also be prioritized based on a cost/benefit analysis.
be specified. The selection procedure should involve D7. Software security errors and previously
all stakeholders. specified secure design decisions should be identified
R7. High-level security requirements can be through inspections. Security errors or vulnerabilities
prioritized by performing a cost benefit analysis. reported in the existing similar software can be used as
Security mechanism with higher priority should be a checklist.
implemented first if there are budgetary constraints. D8. A threshold of acceptable security needs to be
R8. Software security errors and already specified defined using, e.g., security index [4]. Security index
low-level security requirements may be identified of the design must be within the threshold.
through inspections. Security errors or vulnerabilities D9. If the calculated security index is less than the
reported in existing similar software can be used as a threshold, then secure design decisions to remove the
checklist for inspections. errors should be specified.
R9. A threshold of acceptable security can be D10. The newly specified secure design decisions
defined by using, e.g., security index [4] which can be prioritized based on cost benefit analysis. High
provides a measure of the current security state of an priority design decisions should be included.
SDLC artifact. Security index of the requirements
specification should be within the threshold. If a weak 4.3. Implementation phase
security mechanism is selected to mitigate a threat,
then its weakness may be treated as a vulnerability Design is translated into code during
while calculating the security index. implementation. Following are the activities that need
R10. If the calculated security index is less than the to be performed during implementation to achieve
threshold, then security requirements to remove the secure code.
identified errors should be specified. I1. Higher-level programming languages offer
R11. The newly specified security requirements can fewer prospects of insecure code being written.
be prioritized based on cost benefit analysis. High However, sometimes it is necessary to use a low-level
priority security requirements should be included. language to gain direct access to the hardware level. A
language must be selected that is as high-level as
4.2. Design phase possible while keeping in view the programming
requirements of the software under development.
Design is the representation of decisions taken to I2. Secure coding standards and guidelines
fulfill requirements. Design specifies two aspects of should be followed to avoid source code errors.
the software: static structure and dynamic behavior. I3. Unit testing needs to be performed with
The design phase in the SSDP has the following steps. security concerns in mind. Security errors reported in
D1. Detailed functional design (including design similar software should be used as a reference.
of security mechanisms) should be specified in a
secure manner by following secure design patterns and 4.4. Assurance phase
secure design guidelines. A secure design language
such as UMLsec may be used. During the assurance phase, the software is checked
D2. The design must be inspected (multiple times, to find if it meets the requirements. Following activities
if required) for identifying/nd removing software should be performed during this phase.
errors. A1. Code must be inspected (based on the
D3. The threat model developed during the checklists of the previously reported errors) to identify
requirements engineering phase should be enhanced. software and security errors. Moreover, static analysis
tools should be used to find errors. The discovered err-

402
Requirements Engineering Table 1. Artifact view of SSDP: activity-artifact
Information about assets and attackers relationship
Activities Input Artifacts Output Artifact
R1 None Functional requirements.
Threat model R2 Functional requirements. Functional requirements.
Functional requirements
R3 Information about assets and attackers. Threat model.
R4 Threat model. Threat model.
High-level security requirements
R5 Threat model. High-level security
requirements.
Security mechanisms to be included R6 High-level security requirements. Security mechanisms to
be included. Functional
requirements with
Functional requirements with specifications of security
specifications of security mechanisms Security errors mechanisms.
R7 High-level security requirements. High-level security
requirements.
Final requirements Low-level security R8 Functional requirements with Security errors.
requirements specification of security mechanisms.
Design Checklist of existing security errors.
R9 Functional requirements with Security index.
Functional design Enhanced threat model
specification of security mechanisms.
R10 Security errors. Low-level security
Functional design with secure design Secure design decisions requirements.
decisions R11 Functional requirements with Final requirements.
Security errors specification of security mechanisms.
Low-level security requirements.
Final design Low-level security D1 Final requirements. Functional design.
requirements D2 Functional design. Functional design.
Implementation D3 Functional design. Enhanced threat model.
Threat model.
Code D4 Enhanced threat model. Enhanced threat model.
Assurance D5 Enhanced threat model. Secure design decisions.
Test cases and checklists for D6 Secure design decisions. Secure design decisions.
Final code inspections and static code D7 Functional design with secure design Security errors.
analysis decisions.
Figure 2. Artifact view of SSDP: artifact-artifact D8 Functional design with secure design Security index.
decisions.
relationship D9 Security errors. Low-level security
requirements.
ors must be removed through rework. D10 Functional design with secure design Final design
A2. Test cases should be developed based on decisions. Low-level security
requirements.
functional and security requirements. I1 None None
A3. Integration and acceptance testing needs to be I2 None Code
performed based on the security requirements. I3 Code Code
Penetration testing should be performed based on the A1 Code. Checklists for inspections and Code
static code analysis.
known vulnerabilities and the potential attacks that the A2 Final requirements. Final design. Low- Test cases.
software may encounter. Any security errors found level security requirements.
must be removed. A3 Code. Test cases. Final code.

5. Artifact view of the SSDP re used to develop the Threat model. High-level
security requirements and Security mechanisms to
The information in the current artifacts are used to fulfill them are specified. The specifications of security
develop further artifacts. Moreover, each development mechanisms are incorporated in the functional
activity in the SSDP either results in a new artifact or requirements. The resulting artifact, Functional
enhances an already existing one. This artifact requirements with specifications of security
evolution can be represented using artifact-artifact and mechanisms, is inspected and Security errors are
activity-artifact relationships, respectively. This identified. Security errors are used to specify Low-level
evolution needs to be explicitly defined to guide security requirements. Functional requirements with
software developers. For the artifact-artifact specifications of security mechanisms are enhanced
relationship, we use “ Æ ” to represent that the target with Low-level security requirements to develop Final
artifact is produced by taking the source artifact(s) as requirements. Functional design is developed based on
input(s). Figure 2 presents these relationships. Final requirements. Threat model is enhanced based
Initially, Information about assets and attackers and on functional design. Secure design decisions, that can
Functional requirements are produced which in turn a- mitigate the threats in the Enhanced threat model, are
incorporated in the Functional design. Security errors

403
are identified by inspecting the Functional design with Acknowledgement
secure design decisions. Low-level security This research is partially funded by the Natural
requirements to remove these errors are developed. Sciences and Engineering Research Council of Canada
These low-level security requirements (including (NSERC).
already existing ones) are integrated in Functional
design to develop Final design. Final design is used to References
develop the code of the software, while Final
requirements, Final design, and Low-level security [1] J. Juerjens, Secure Systems Development with UML,
requirements identified during the requirements Springer, 2005.
engineering and design phases are used to generate [2] C.E. Landwehr, A.R. Bull, J.P. McDermott, and W.S.
security test cases and checklists for inspections and Choi, “Taxonomy of Computer Program Security Flaws,”
ACM Computing Surveys, 1994, vol. 16, no. 3, pp. 211-254.
static code analysis. The tested code, after rework,
[3] I.V. Krsul, “Software Vulnerability Analysis,”
results in Final code. Doctoral dissertation, Department of Computer Sciences,
We show the activity-artifact relationships with the Purdue University, Indiana, USA, 1998.
help of Table 1. The first column lists the activities in [4] M.U.A. Khan and M. Zulkernine, “Quantifying
the SSDP. The second and third columns identify the Security in Secure Software Development Phases,” In Proc.
corresponding input and output artifacts, respectively. of the 2nd IEEE International Workshop on Secure Software
Engineering (IWSSE’08), Turku, Finland, 2008, IEEE CS
Press, pp. 955-960, 2008.
6. Summary and conclusions [5] A. Jaquith, Security Metrics, Addison Wesley, 2007.
[6] D. Verdon and G. McGraw, “Risk Analysis in
A secure software development process is required Software Design,” IEEE Security and Privacy, IEEE CS
Press, 2004, vol. 2, no. 4, pp. 79-84.
to incorporate security throughout software
[7] R. Kissel, “Glossary of Key Information Security
development. We have proposed such a process in this Terms,” National Institute of Standards and Technology,
paper. Our SSDP has two views: (1) activity view NISTIR-7298, 2006.
which presents the development activities and their [8] G. McGraw, Software Security: Building Security In,
sequence of execution and (2) artifact view that Addison Wesley, 2006.
illustrates the artifact-artifact and activity-artifact [9] S. Lipner, “The Trustworthy Computing Security
relationships. Both views are important to provide the Development Lifecycle,” In Proc. of the 20th Annual
Computer Security Applications Conference (ACSAC ‘04),
developers with clear guidance. CA, USA, 2004, IEEE CS Press, pp. 2-13.
The SSDP places emphasis on requirements and [10] OWASP CLASP Project, http://www.owasp.org/index.
design phases. We propose that a threat model is built php/Category:OWASP_CLASP_Project. Visited May 2009.
during the requirements phase and enhanced during the [11] I. Flechais, C. Mascolo, and M.A. Sasse, “Integrating
design phase. Similarly, risk and cost benefit analysis Security and Usability into the Requirements and Design
should also be performed in both phases. We have Process,” International Journal of Electronic Security and
Digital Forensics, Inderscience Publishers, Geneva,
identified inspection as an important error discovering Switzerland, 2007, vol. 1, no. 1, pp. 12-26.
activity which must be part of requirements, design, [12] A.S. Sodiya, S.A. Onashoga, and O.B. Ajayi, “Towards
and assurance phases. During the implementation Building Secure Software Systems,” Issues in Informing
phase, the selection of an appropriate (secure) Science and Information Technology, Informing Science
programming language is important. Following secure Institute, California, USA, 2006, vol. 3, pp. 635-646.
coding standards and guidelines is also necessary to [13] M. Essafi, L. Labed, and H.B. Ghezala, “S2D-ProM: A
Strategy Oriented Process Model for Secure Software
avoid any previously reported security errors. During Development,” In Proc. of the 2nd International Conference
the assurance phase, we suggest that inspections and on Software Engineering Advances (ICSEA’07), Cap Esterel,
static code analysis should be performed before testing. French Riviera, France, 2007, p. 24.
As the security requirements (and secure design [14] M.U.A. Khan and M. Zulkernine, “On Selecting
decisions) have been finalized after cost/benefit Appropriate Development Processes and Requirement
Engineering Methods for Secure Software,” In Proc. of the
analysis during the requirements engineering and 4th IEEE International Workshop on Security, Trust, and
design phases, we propose that all the identified Privacy for Software Applications (STPSA 2009), Seattle,
security errors that violate these requirements must be WA, USA, IEEE CS Press, 2009, to appear.
removed. Integration and acceptance testing should be [15] B.W. Boehm and P.N. Papaccio, "Understanding and
Controlling Software Costs," IEEE Transactions on Software
performed while keeping security in mind. Finally, Engineering, 1988, vol. 14, no. 10, pp. 1462-1477.
penetration testing ought to be carried out based on
potential attacks that the software may encounter when
deployed.

404