Docstoc

A Framework for Identifying Software Vulnerabilities within SDLC Phases

Document Sample
A Framework for Identifying Software Vulnerabilities within SDLC Phases Powered By Docstoc
					                                                               (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