A Study on Secure SDLC Specialized in Common Criteria

Transcription

1 , pp A Study on Secure SDLC Specialized in Common Criteria Min-Gyu Lee 1, Hyo-jung Sohn 2, Baek-MinSeong 3 and Jong-Bae Kim 4* 1,2,3,4* Graduate School of Software, Soongsil University, Seoul , Korea 1 marse101@naver.com, 2 hyojung.sohn@gmail.com, 3 feeling127@naver.com, 4* kjb123@ssu.ac.kr Abstract. Common Criteria (CC) is a globally standardized for information technology security evaluation criteria for IT products manufactured around the world. IT products used in governmental organizations and public institutions must acquire a certain level of or higher than the Evaluation Assurance Level (EAL) of CC. Meanwhile, the general Software Development Life Cycle (SDLC) does not suggest guidelines to eliminate weakness in the development ; therefore, a possible critical situation may occur. Furthermore, CC currently performs security certification for Target of Evaluation (TOE) only, and it does not suggest a guideline related to Secure Software Development Life Cycle (SSDLC) that considers weakness in the development. If the relevant TOE is developed by SSDLC specializing in CC, all of the evaluators and developers can engage in CC certification with an objective perspective. This thesis suggests that SSDLC can develop TOE suitable for CC by identifying vulnerabilities and weaknesses, making a reference to MS-SDL, OWASP Comprehensive Lightweight Application Security Process (CLASP), and McGraw s Touchpoints based on the weaknesses provided at the CWE. Keywords: Common Criteria, CC, SSDLC, Secure SDLC, CWE, weakness, vulnerability, MS-SDL, CLASP, Touchpoints 1 Introduction Common Criteria (CC) is a globally standardized criteria (ISO/IEC 15408) for information technology security evaluation criteria of IT products that are manufactured around the world. IT products that will be introduced by governmental organizations and public institutions must acquire a certain level of or higher than the Evaluation Assurance Level (EAL) of CC in order to be delivered. Currently, when a number of software-related small-sized and medium-sized companies develop software for CC certification, they usually hire after the results have been completed without hiring the CC expert from its initial development due to issues regarding the cost. At the Software Engineering Institute of Carnegie Mellon University, 70% of the weaknesses, which occurred during a design error, have been reported. When it was unable to eliminate these weaknesses during the software design phase, the costs occurred in as much as 30 times during the maintenance phase [1]. In addition, CC currently performs security certification for Target of Evaluation (TOE) only; ISSN: ASTL Copyright 2015 SERSC

2 however, it does not suggest a guideline related to Secure Software Development Life Cycle (SSDLC), which can analyze the weakness during the development. This paper suggests that the SSDLC is able to develop TOE suitable for CC, based on the weakness provided by the Common Weakness Enumeration (CWE), by determining the vulnerabilities and the weaknesses in references of the MS-SDL, OWASP Comprehensive, Lightweight Application Security Process (CLASP), and Touchpoints. The results of this study can be utilized as guidelines for the developers with the purpose of CC certification in the of developing software, of which the weaknesses are eliminated. 2 Related Work We have witnessed that if there are vulnerabilities that have not been eliminated during the phases of SDLC design, implementation, and, the cost would demonstrate an exponential growth. One weakness is accompanied by multiple vulnerabilities; therefore, it is important to eliminate the weaknesses. In this paper, I mapped the removable items from the CWE weakness list (Ver.2.8) per item during the design, implementation, and test phases, by using the study data of Bart [2], who has done a comparative study for MS-SDL, CLASP, and Touchpoints. The total number of items during the design, implementation, and test phases is 81. For CWE s weaknesses list [3], the Weaknesses Introduced During Design (CWE- 701) of the Development Concept (CWE-699) will be used as a weakness list. The weaknesses presented are shown in Table 1. Table1. Weaknesses Introduced During Design (CWE-701) CWEs in this view Total CWEs Total 383 out of 1003 Views 0 out of 32 Categories 3 out of 244 Weaknesses 377 out of 719 Compound Elements 3 out of 8 The weaknesses that can occur in the design phase are 380 in total, except for View and Categories. For the weakness list in the implementation phase, the Weaknesses Introduced During Implementation (CWE-702) of Development Concept (CWE-699) will be used. Similarly, the weaknesses that possibly occur in the implementation phase are 600 in total, except for View and Categories. During the test phase, it is used by removing the duplicates from the two CWE lists of the design phase and the implementation phase. Since all existing vulnerabilities must be removed, it was analyzed based on the total weaknesses of 687. In CC Part 2, Security Functional Requirements (SFR) provides a total of 11 Security Functional Classes. This is a set of functional components which is a standard for determining the security features and security mechanisms of TOE [4]. For the weaknesses of the security functional requirements that can be removed in the 20 Copyright 2015 SERSC

3 design and implementation phase, it has utilized the method [5] of using the Security Features (CWE-254). The listed weaknesses are 110 in the design phase, and 75 in the implementation phase. Security Assurance Requirements (SAR) is a set of assurance components that is a standard for determining the assurance level of TOE [6]. The ultimate goal of the CC certification is to acquire Evaluation Assurance Level (EAL). Therefore, the developers shall establish a goal of acquiring an EAL. In CC, when the developer tries to acquire TOE above EAL4, they must submit the source code to the rating institution. The source code analysis is important for the verification of the weaknesses, and it has been conducted from the evaluation of above EAL4. However, even this source code analysis is explicitly stated in the CC standard that it is not a requirement of the evaluators. As a result, utilizing the items [7] will remove the weaknesses of the CC. As mentioned above, the source code analysis can only be made by submitting the source code when it acquires more than an EAL4 grade. For EAL1~3 grades, the source code analysis is not possible. Based on the items, mapping is conducted by finding the weaknesses that can be removed from the CWE weaknesses list. 3 SSDLC Research Method for Specialized Common Criteria 3.1 Research Process This research paper maps to find the weaknesses to be removed by comparing the items of SSDLCs that can eliminate the vulnerabilities as described above with the predefined CWE list. The weaknesses are then mapped to be removed, based on the CWE list with CC Security Functional Requirements (SFR) and Security Assurance Requirements (SAR). In addition, it proposes an SSDLC that is suitable to each EAL grade by determining the correlation of the weaknesses that were found in the two previous phases. 3.2 SSDLC Item Comparison and CWE List Mapping Since it was not able to add the mapping data for all of the weaknesses, it has given the Top 25 Most Dangerous Software Errors [8] according to the CWE/SANS. The reference shows the top 25 most dangerous weaknesses. The results that mapped the weaknesses ranked 1st, 3rd, and 5th in the SSDLC comparison. When looking at the SQL-Injection that ranked 1st place on the above data out of the most dangerous weaknesses, the vulnerabilities to be derived are seven, but there was no way of finding the weaknesses during the design phase. Based on the methods that were successful in finding the weaknesses during the implementation phase, there were security analysis tools, automated source level, and manual code. Moreover, the methods used in finding the weaknesses regarding the SQL-Injection Copyright 2015 SERSC 21

4 during the test phase were fuzz, risk-based, unit, and penetration methods. According to the above result, all the weaknesses that can be removed from SSDLC have been confirmed, and it could be a cornerstone for the weaknesses and comparative materials that can be found in CC in the future. 3.3 CC and CWE List Mapping In Section 3.2, the mapping of the CC and CWE list involved the 1st, 3rd, 5th ranks of the CWE/SANS. For the CC comparison, it utilized the SFR that has become a standard for defining the TOE s security functions and security mechanisms as described in Section 2.3, as well as the SAR that has become a standard for defining the TOE assurance level. On the other hand, the source code analysis and the vulnerability analysis are not mandatory in the assurance requirements, but they can be used according to the requirement of the evaluator. Therefore, it has separately analyzed two cases, wherein one case used the source code analysis and the vulnerability analysis, while the other case did not utilize any of the aforementioned methods. 3.4 Comparison Analysis In this section, it has compared the weaknesses that the CC and SSDLC can remove in EAL4~7 grades by using the data mapped in Section 3.2 and Section 3.3. The comparison results from EAL1~3 and EAL4~7 in the analysis data on Section 3.3 are the same, and it has summarized the table of EAL4~7 only to prevent duplication. Organizing results are shown in Table 2. 4 Conclusion In this paper, after having mapped the weaknesses that can be found in SSDLC and those in the CC based on CWE list, the comparative analysis for the correlation of weaknesses were found in SSDLC and those in CC. Based on the mapped data, it proposed a SSDLC that specializes in CC by selecting the steps that must be undertaken in SSDLC through EAL grades. The results of this study may be used as an SSDLC guideline that matches the target EAL of the developers in order to acquire a CC certification. Table2. Comparison of the Mapped Data CWE SSDLC CWE ID Design Implementation Test 22 Copyright 2015 SERSC

5 CC (EAL 4~7) SAR SFR CWE-89: SQL Injection CWE-120: Classic Buffer Overflow CWE-306: Missing Authenticati on CWE-306: Missing Authenticati on 1. Threat modeling 1. Threat modeling 1. Fuzz 2. Unit 4. Risk-based 1. Fuzz 2. Unit 4. Risk-based 1. Fuzz 2. Unit 1. Fuzz 2. Unit References 1. Gregory Tassey, Ph.D.: The Economic Impacts of Inadequate Infrastructure for Software Testing.: National Institute of Standards and Technology (2002) 2. Bart De Win, Riccardo Scandariato, Koen Buyens, Johan Gre goire, WouterJoosen.: On the secure software development CLASP, SDL and Touchpoints compared: Information and Software Technology 51 (2009) Common Weakness Enumeration, 4. Common Criteria v3.1: Part 2:Security functional components (2012) 5. JinseokPark,Seungjoo Kim.: How the CC Harmonizes with Secure Software Development Lifecycle : Journal of The Korea Institute of Information Security & Cryptology VOL.24, NO.1, Feb BundesamtfürSicherheit in der Informationstechnik.:Guidelines for Developer Documentation according to Common Criteria Version 3.1 (2007) 7. Mehmet Kara.: Review on Common Criteria as a Secure Software Development Model: International Journal of Computer Science & Information Technology (IJCSIT) Vol 4, No 2, April MITRE.: CWE/SANS Top 25 Most Dangerous Software Errors (2011) Copyright 2015 SERSC 23