A Framework for Identifying Software Vulnerabilities within SDLC Phases

Report as inappropriate Your report has been received

Shared by: ijcsiseditor

Stats

views:: 262
posted:: 7/5/2011
language:: English
pages:: 5

Public Domain

Document Sample

(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, 2011

A Framework for Identifying Software Vulnerabilities
within SDLC Phases
Zeinab Moghbel Nasser Modiri
Department of Computer Engineering Department of Computer Engineering
Science and Research Branch, Islamic Azad University Zanjan Branch, Islamic Azad University
Tehran, Iran Zanjan, Iran

Abstract—Considering the fast development of software and its Different definitions of security are expressed [1-3], but the
complexity, the requirement of securing has faced new aspects. overall concept of security can be described as follows:
The more the software becomes complex and its access rate rises, prevention of unauthorized access and illegal data
a creative technique is being created to attack, access, or manipulation. So the purpose of security is data protection to
manipulate its data. Therefore, creating a new approach in order
to detect software vulnerability is essential. Various studies have
avoid disclosure and change it. Several layers of security have
proved that in case of considering security in late phases of been suggested than ever [4, 5]. And many researches and
software development and testing to mitigate software studies have done on these layers. One of most important
vulnerabilities, will be time consuming and complex, and it is layers is software layer. Studies have shown that many
probably that it couldn’t supply the security completely. So, security breaches have occurred because of code flaws or not
taking into account the security issue from the early phases of to cover some issues in designing software [6]. In other words,
software development is essential. most security violations have occurred due to vulnerability in
In this paper, we propose a framework in order to identify software. Software vulnerability is a weakness or flaw that can
software vulnerability. In this framework, we use common be exploited [1]. Vulnerabilities may be intentionally or
criteria standard (ISO/IEC 15408) and CVE (Common unintentionally. Since many vulnerabilities are unwanted and
Vulnerabilities and Exposures) to identify software vulnerability, unintentional, we must find a way to detect these
which is done in every phase of the software development life vulnerabilities and avoid happening them.
cycle. Therefore, the process of secure software development will
be improved, and software with less vulnerability will be At the beginning of software engineering industry, software
produced. security was being considered in late phases of software
development, and usually was being checked in test phase. But
Keywords- Software vulnerability; Common Criteria (CC);
Common Vulnerabilities and Exposures (CVE); Common with the increasing complexity of software and existence of
Vulnerability Scoring System (CVSS); secure software strong aims and motivations in order to violate security,
securing has faced problems. Hence, engineers have decided
to integrate security in the early phases of software
I. INTRODUCTION development. Thus, various processes were created to
integrate security areas into SDLC and to produce secure
Nowadays the software has been developed in different software such as SDL [7], CLASP [8] and Touchpoints [2]. In
fields, so that various issues have been taken into account. these processes, security areas such as threat modeling, risk
Worldwide improvement of software either in terms of size management or secure coding have been combined together in
and complexity or in terms of wide applications causes that the the process [9]. In another paper SVDAF [10] framework is
software faces important demands. However, while the introduced. SVDAF detects and removes vulnerabilities in
software security that has been considered, but the incidence each phase in order to produce secure software. Vulnerability
of new security violations and modern technologies detection and analysis has been done by checklists in each
development in software engineering has led to various phase of SDLC, after the vulnerabilities are removed, secure
security aspects to be considered. software is produced. Unfortunately, this framework still has
not been implemented and tested.

203 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, 2011
In our framework, we use standard methods to identify and violate security functional requirements or not. These
detect software vulnerabilities in each phase of SDLC, so the vulnerabilities have been detected during evaluation of the
accuracy of our methods would be guaranteed. One of these development and anticipated operation of the TOE (Target of
standards is Common Criteria. Common Criteria standard Evaluation) or by other methods (e.g. by flaw hypotheses,
(ISO/IEC 15408) [11] assures the security by means of quantitative or statistical analysis of the security behavior of
executing security performance evaluation processes. Also we the underlying security mechanism).
use Common Vulnerabilities and Exposures (CVE) [12] to
This class only includes of AVA_VAN (Vulnerability
contribute in Common Criteria. CVE have been used to
Analysis) family. The AVA_VAN requirements mentioned as
identify known vulnerabilities in software. After identifying
in [17] include:
software vulnerabilities, we must determine that output of
each SDLC phase is vulnerable or not. For this purpose, we Search for public domain resources to identify
use Common Vulnerability Scoring System (CVSS). CVSS potential vulnerabilities in the TOE.
[13] assigns a number or score to any vulnerability, which
indicates its risk. Analysis of evidence evaluation to identify potential
vulnerabilities in the TOE.
The paper is organized as follows: in section 2 we explain
Performance of penetration test to identify that the
Common criteria standard briefly. In section 3 we describe
CVE. In section 4 we introduce our proposed framework to TOE can avoid penetrations, which are expected by
identify software vulnerabilities in SDLC. Finally, in section 5 an attacker or not.
we present conclusions and suggestions for future work. Flaw Hypotheses

II. COMMON CRITERIA STANDARD (CC) In our proposed framework, we will introduce equivalent
cases for AVA_VAN requirements.
Common Criteria standard (ISO/IEC 15408) is one of the
known standards for security evaluation of IT products. This
standard offers a series of classes and predefined packages for
organizations that will help them to develop their products at III. COMMON VULNERABILITIES AND EXPOSURES (CVE)
certain levels of security and prepare them for CC audit. CVE system provides a reference method for information
Classes are the most general grouping of security security vulnerabilities which are generally known. This
requirements. This means that all members of a class system determines a conventional and standard naming for
concentrate on a particular security process. Every class vulnerabilities. In fact, CVE is the database of known
refined into one or more families, which each family vulnerabilities and standard description of these
concentrates on the part of the security process. Every family vulnerabilities, such that known software vulnerabilities can
consists of one or more components and each component has a be identified by it. This system is a tool for identifying and
set of individual elements. The result of CC evaluation has classifying vulnerabilities based on either at design,
been shown as certain levels, which are called Evaluation architecture or coding phase has appeared.
Assurance Level (EAL). EALs begin from EAL-0 that means
low-assurance and end at EAL-7 namely highest level of In fact, CVE uses Common Weakness Enumeration (CWE).
assurance. CWE [18] is a classification mechanism, which distinguish
common weaknesses by showing types of vulnerability. This
Common Criteria standard consist of three parts: means that CWE has classified software weakness in three
Part 1: Introduction and general model [14], categories: architecture, design, or implementation and
execution. Hereby, detecting and identifying known
Part 2: Security functional components [15], and vulnerabilities in various phases of SDLC become easier, and
Part 3: Security assurance components [16]. this procedure helps CC evaluator to identify software
vulnerabilities faster and better.

Part 1 and part 2 include of background information,
reference objectives and guide the process of setting IV. THE PROPOSED FRAMEWORK
requirements for security operations. Part 3 performs security Our framework is depicted in Fig.1, its aims to identify
evaluations of IT products and assures security. In this paper, software vulnerabilities in every phase of SDLC. In each
we will concentrate on part 3. cycle, the input of this framework is one of SDLC phases,
which then enter in vulnerability life cycle and determine
Six classes for part 3 are defined, that we use Class AVA
(Vulnerability Assessment) in order to identify software whether the product of this phase is vulnerable or not. In
vulnerabilities. This class is an assessment that determines vulnerability life cycle, the first step is to search and detect
whether potential vulnerabilities could allow the attacker to vulnerabilities. In fact, it performs this step by Common
Criteria standard and cooperates with vulnerability database

204 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, 2011
CVE to be ready for the next step. Then CVSS gives a score In our framework, the requirements of AVA_VAN family
for identified vulnerabilities, whereas this score assigns the are as follows:
risk of the vulnerability. Now with the obtained value, we
We use CVE database to search for public domain
check if the product of this phase is vulnerable or not. If this
resources to identify potential vulnerabilities in the
product is not vulnerable, it is considered secured, otherwise it
TOE.
enters in vulnerability mitigation step, and then again has been
checked, whether applied mechanism has led to mitigating We use individual phases of SDLC to analyze of the
vulnerabilities or not. evidence evaluation in older to identify potential
vulnerabilities in the TOE.
Various phases of SDLC will be evaluated in these
components as follows:
• The requirements phase: in this phase, we first extract the
requirements of the software. Also in this phase we need
to extract security requirements, so we can identify
security violations and vulnerabilities by AVA_VAN
class. Then we can use misuse/use case [20] or UMLSec
diagrams [21].
• The design phase: in this phase, we integrate the security
requirements in software design. For this purpose, we can
also use UMLSec diagrams. Thereby, we can detect
software weaknesses, and then identify vulnerabilities by
CC evaluators.
Figure 1. The Framework for Identifying Software Vulnerabilities within
SDLC Phases • The implementation phase: in this phase, the code has
been written in a programming language. There are
various programming languages in software engineering
We briefly will explain the different sections of our industry that everyone has its specific characteristics.
framework as follows:
Each of these languages has weaknesses that may be
abused. Here the code of the program has been reviewed
A. SDLC Component and evaluated by CC evaluator, whether it is vulnerable or
not. For this purpose, CC evaluator use methods such as
The first step in our framework is SDLC. The SDLC
penetration test.
shows different phases of the software development life cycle
that consist of requirements, design, implementation, test and • The test and maintenance phase: in this phase, software
maintenance. In each cycle, a product of a software life cycle program has been executed and tested. In some cases
phase or a resultant product in SDLC, will enter the there are vulnerabilities, which have been appeared during
vulnerability life cycle. If in the vulnerability life cycle it is program execution by users. These vulnerabilities may
detected as vulnerable product, then will perform vulnerability have existed in earlier phases, but have not seen, or this
mitigating procedures, and will re-enter the vulnerability life phase has been observed. Again in this phase, CC
cycle as a product of SDLC. After all, if we will be ensured
that our product is secured, this product will enter the next evaluators use AVA_VAN class to evaluate
phase of software development life cycle, and eventually the vulnerabilities.
final product will result. 2) CVSS Component
One of the vulnerability classifications is based on SDLC
This system would assign a score to any vulnerability. This
phase in which a vulnerability type could be introduced [19].
score represents a real risk of vulnerability for data and
This states that the specific vulnerabilities of each phase are
information, and the priority can be done by it. Common
known. But we must note that all of vulnerabilities in SDLC
vulnerability Scoring system (CVSS) consists of three metrics
phases are not known, and various vulnerabilities will be
[13]: Base Metrics, Temporal Metrics, and Environmental
identified by a method, which will be explained later.
Metrics. The numerical value has been assigned to any
vulnerability by these metrics that called severity. Severity
value indicates the risk level or the threat of vulnerability.
B. Vulnerability Life Cycle
We have categorized the obtained severity as follows:
1) Common Criteria & CVE Components

205 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, 2011
1. Vulnerability is labeled “Low” severity if a CVSS base For improving our framework, we suggest the followings:
score was of 0.0-4.4.
Automated identifying vulnerabilities: we must have
2. Vulnerability is labeled “Medium” severity if a base techniques to identify vulnerabilities automatically.
CVSS score was of 4.5-7.4. This cause that people with less security expertise can
use these techniques.
3. Vulnerability is labeled “High” severity if a CVSS base
Identified unknown vulnerabilities: according to our
score was of 7.5-10.0. studies, our framework has good results for known
vulnerabilities, but how we can assess this framework
for unknown vulnerabilities and reach the desired
The above classifications are based on our experience in results.
different projects.
REFERENCES
[1] A. K. Talukder, M. Chaitanya, “Architecting Secure Software
3) Secured Phase Component Systems”, CRC Press, 2009.
In general, product vulnerabilities' severities are one of the [2] G. McGraw, “Software Security: Building Security In”, Addison
criteria that indicate the safety of the product in SDLC phase. Wesley, 2006.
Since our proposed framework is based on identifying [3] L. Bass, P. Clements, R. Kazman, “Software Architecture in
software vulnerabilities, so safety criteria of the product will Practice”, Second Edition, Addison Wesley, 2003.
be based on the product vulnerabilities’ severities. If all [4] S. V. Kartalopoulos, “Security of information and communication
vulnerabilities’ severities are “low”, then the product of the networks”, IEEE Press Series on Information & Communication
phase is known as a safety product, and enters this step of the Network Security, 2009.
framework namely Secured Phase. [5] S. Purser, “A practical guide to managing information security”,
Artech House Technology Management Library, 2004.
[6] R. J. Ellison, J. B. Goodenough, C. B. Weinstock, C. Woody,
C. Vulnerability Mitigation Component “Evaluating and Mitigating Software Supply Chain Security Risk”,
Software Engineering Institute, 2010.
If severities of all identified vulnerabilities are not “low”,
then we will enter this step. This step contains of the [7] M. Howard, S. Lipner, “The Security Development Lifecycle:
SDL: A Process for Developing Demonstrably More Secure
mechanisms to mitigate vulnerabilities in various phases of the Software”, Microsoft Press, 2006.
software development life cycle. For this purpose, there are
[8] Open Web Application Security Project - OWASP, "CLASP:
Specific mechanisms for every phase that has not been Comprehensive Lightweight Application Security Process",
addressed in this framework. http://www.owasp.org/index.php/Category:OWASP_CLASP_Proj
ect, 2006.
[9] B. D. Win, R. Scandariato, K. Buyens, J. Grégoire, W. Joosen, “On
V. CONCLUSION AND FUTURE WORK the secure software development process: CLASP, SDL and
Touchpoints Compared”, Information and Software Technology
By considering the software has been developing rapidly, it 51, 2009.
has faced new security requirements. On the other hand,
[10] A. Agrawal, R. A. Khan, “A Framework to Detect and Analyze
software placing on the network and increasing the level of Software Vulnerabilities –Development Phase Perspective-“,
user access, has led to increase accessibility and International Journal of Recent Trends in Engineering, 2009.
manipulability of various information. Furthermore, expertise [11] ISO 15408: Common Criteria for Information Technology Security
and motivation of attackers to access and manipulate data, is Evaluation (CC), http://www.commoncriteriaportal.org.
another reason to emphasize the software securing. Therefore,
[12] Common Vulnerabilities and Exposures (CVE),
in this paper we considered software securing. http://cve.mitre.org.
In this paper, we proposed a framework that identified [13] P. Mell, K. Scarfone, S. Romanosky, “A Complete Guide to the
vulnerabilities in individual phases of the software Common Vulnerability Scoring System”, Version2.0, 2007.
development life cycle. For this purpose, we used the [14] ISO 15408:2009 Common Criteria for Information Technology
contribution of Common Criteria standard and CVE database. Security Evaluation, Version 3.1, Revision 3, “Part1: Introduction
Moreover, we applied CVSS ranking system to evaluate the and general model”, CCMB-2009-07-001, July 2009.
security of the product in SDLC, which assigns a score to any [15] ISO 15408:2009 Common Criteria for Information Technology
vulnerability that illustrates its risk. If severities of all Security Evaluation, Version 3.1, Revision 3, “Part2: Security
identified vulnerabilities are “low”, then the product of the functional components”, CCMB-2009-07-002, July 2009.
phase is considered secured. Otherwise, the product will enter [16] ISO 15408:2009 Common Criteria for Information Technology
in the vulnerability mitigation component to use specific Security Evaluation, Version 3.1, Revision 3, “Part3: Security
mechanisms of each phase for mitigating existing assurance components”, CCMB-2009-07-003, July 2009.
vulnerabilities.

206 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, 2011
[17] E. Pierre, J. Arnold, AVA_VAN.2 – Performing Vulnerability International Conference on Information Technology: Coding and
Analysis Under CCv3, SAIC, 2008. Computing (ITCC'05) - Volume 02, 2005.
[18] Common Weakness Enumeration (CWE), http://cwe.mitre.org. [21] G. Popp, J. Jürjens, G. Wimmel, R. Breu, “Security-Critical
System Development with Extended Use Cases”, 10th Asia-Pacific
[19] P. Meunier, Classes of Vulnerabilities and Attacks, Wiley Software Engineering Conference (APSEC), 2003.
Handbook of Science and Technology for Homeland Security,
2008.
[20] J. Pauli, D. Xu, “Misuse Case-Based Design and Analysis of
Secure Software Architecture”, ITCC '05 Proceedings of the

207 http://sites.google.com/site/ijcsis/
ISSN 1947-5500