Available online at www.sciencedirect.com
ScienceDirect Procedia Computer Science 60 (2015) 1092 – 1100
19th International Conference on Knowledge Based and Intelligent Information and Engineering Systems
A Case-based Management System for Secure Software Development Using Software Security Knowledge Masahito Saitoa, Atsuo Hazeyamab*, Nobukazu Yoshiokac, Takanori Kobashid, Hironori Washizakie, Haruhiko Kaiyaf, Takao Ohkubog a Graduate School of Education, Tokyo Gakugei University, 4-1-1 Nukuikita-machi, Koganei-shi, Tokyo 184-8501 JAPAN Department of Information Science, Tokyo Gakugei University 4-1-1 Nukuikita-machi, Koganei-shi, Tokyo 184-8501 JAPAN c 3National Institute of Informatics 2-1-2 Hitotsubashi, Chiyoda-ku, Tokyo 101-0003 JAPAN d Graduate School of Fundamental Science and Engineering, Waseda University 3-4-1 Okubo, Shinjuku-ku, Tokyo 169-8555 JAPAN e Department of Computer Science and Engineering, Waseda University 3-4-1 Okubo, Shinjuku-ku, Tokyo 169-8555 JAPAN f Faculty of Science, Kanagawa University 2946 Tsuchiya, Hiratsuka-shi, Kanagawa 259-1205 JAPAN g Institute of Information SECurity (IISEC) 2-14-1 Tsuruya-cho, Kanagawa-ku, Yokohama-shi, Kanagawa 221-0835 JAPAN b
Abstract In recent years, importance on software security technologies has been recognized and various types of technologies have been developed. On the other hand, in spite of recognition of necessity of providing cases that deal with full life cycle for secure software development, only few are reported. This paper describes a case-based management system (CBMS) that consists of an artifact management system and a knowledge-based management system (KBMS) to manage cases for secure software development. The former manages the artifacts created in secure software life cycle. The latter manages software security knowledge. The case-based management system also manages association between artifacts and software security knowledge and supports both visualization among software security knowledge and between artifacts and software security knowledge. We conducted an experiment to evaluate the system. We describe the effectiveness and future work of the system. © by Elsevier B.V.by This is an open © 2015 2015Published The Authors. Published Elsevier B.V.access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of KES International. Peer-review under responsibility of KES International Keywords: Secure software development support; Case-based management system for secure software development
*
Corresponding author. Tel.: +81-42-329-7465. E-mail: hazeyama at u-gakugei.ac.jp.
1877-0509 © 2015 Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of KES International doi:10.1016/j.procs.2015.08.155
Masahito Saito et al. / Procedia Computer Science 60 (2015) 1092 – 1100
1093
1. Introduction The number of services available on the Internet is increasing. This trend will continue because of the spread of mobile terminals and/or information electronics in the near future. Along with this trend, computer security becomes increasingly important. In recent years, as increasing number of services has been implemented using software, and with increasing software complexity, the importance not only of network security technologies such as encryption or access control technology, but also of software security technologies has been recognized [7]. Software security deals with security during the whole software development process [7], that is, it is not simply embedded in the network security technologies in a software system but is built into the software system through various types of security activities. Various types of technologies for secure software development have been developed, such as processes, principles, patterns, and guidelines. However, since software engineers are not experts on security in general, they do not know what kind of knowledge exists and how it should be used. Therefore, necessity to cases that address the whole life cycle of secure software development is advocated [1]. However, there are only few such cases. Apvrille and Pourzandi showed example artifacts for secure software development of which task is an instant messaging service, that is, artifacts for security requirement analysis, architecture design, and so on. They also showed some topics. However, the topics remain fragmentary and they are not associated with artifacts. The SHIELDS project aims to construct a repository-based secure software engineering environment [4]. The goal of the project is to store and share security models that represent the expertise of experts. For that purpose, the project provided a modeling tool. However, association of artifacts with software security knowledge does not seem to mention. By storing both software security knowledge and artifacts created by secure software development and associating them as case, we can support software engineers who are not always experts in software security. To manage such cases, a case-based management system (CBMS) is required. This paper proposes a CBMS for secure software development that manages software security knowledge and artifacts created by secure software development and associates them as case. In addition, as we conducted a small experiment to show effectiveness of the system, we show some results. 2. Requirements for CBMS We discuss requirements for CBMS. We identified the following six requirements. Requirements from (1) to (4) are those from our previous study [5]. (1) The system should be able to manage artifacts (those that do not consider security fully) that are inputs for secure software development and outputs from that development. Meaning to manage artifacts that are inputs for secure software development corresponds to the misuse case by Sindre and Opdahl. Their method proposes to extract normal use cases at first, then extract misuse cases. (2) The system should allow users to register, revise, and/or delete knowledge for secure software development, for example, methods, patterns, standards, and so on. (3) The system should allow users to register, revise, and/or delete the rationale for artifacts. The system should enable to associate relationship of the rationale with the artifacts and relationship of the rationale with the knowledge used to prepare the artifacts. (4) The system should allow users to give annotations to artifacts. Annotations are also associated with the knowledge. (5) Visualization support of the whole structure of software security knowledge: This is a requirement that emerged from the result of our previous experiment. All of software security knowledge are instances of classes in Fig. 2. The whole structure forms a large-scaled and complicated network structure. When a user accesses knowledge, (s)he selects the type of knowledge (s)he wants to access, then knowledge is shown in a tabular form in the experiment. Therefore, a participant said that it was easy to retrieve knowledge (s)he wanted. On the other hand, another participant said that it was difficult to retrieve necessary knowledge if (s)he did not have knowledge fully. To solve these problems, it is necessary to identify the type of each knowledge in a direct manner. In addition, the system is required to show the holistic view of the knowledge base. At this time, what should be done, that is, process should be placed at the starting
1094
Masahito Saito et al. / Procedia Computer Science 60 (2015) 1092 – 1100
point, and then related knowledge is placed. Furthermore to show degree of usage, knowledge that was frequently used should be identifiable. (6) Visualization support between artifacts and software security knowledge This requirement also comes from the result from our previous experiment. As described before, we suppose to associate an artifact with the knowledge that was used to prepare the artifact. The degree of abstract differs artifact by artifact. In the experiment, discussions regarding how detailed requirement specification should be written were exchanged. In order to trace that different abstract level of knowledge is reflected to development, all artifacts should be managed and traceability should be maintained. 3. A case-based management system for secure software development This section describes a case-based management system for secure software development. It is consisted of a knowledge-based management system (KBMS) and an artifacts management system. Fig. 1 shows an overall architecture of the system. The figure shows the system manages both artifacts (requirement (1)) and software security knowledge (requirement (2)). It also shows that the system associates knowledge with artifacts (requirement (3)) and review comments (requirement (4)). C ase-based management system for secure software development A rtifacts created by software development
S et of functions for case-based management system
M ethod X 㸯㸬 ͐ Q
P attern x R elationship between knowledge
R elationship between knowledge base and artifacts rationale1
G uideline y
revise A rtifact 1
K nowledge base
R eview comment1
A rtifact 1.1
A rtifacts created by secure software development
Fig. 1. Configuration of our case-based management system 3.1. Knowledge-based management system The KBMS provides the following functions: registration of software security knowledge, modification of it, deletion of it, association among pieces of knowledge and browsing of knowledge. This is a solution to requirement (2). Fig. 2 shows knowledge types and their relationships. The model is an extension to that by Barnum and McGraw [2]. Barnum and McGraw proposed a knowledge model for secure software development. Their model is consisted of seven classes and their relationships. We think their model lacks some important concepts for secure software development, that is, process (and its components) and security pattern. Therefore we proposed a model that is extension to that by Barnum and McGraw. z Visualization of holistic view of KB Our KB is organized by instances of classes as shown in Fig. 3 (Fig. 3 shows a part of the whole knowledge base). It forms a very complicated network structure where nodes represent knowledge and links represent relationships between pieces of knowledge. It is therefore necessary to support visualization that represents the structure in a direct manner. In particular, a “process” describing what activities need to be done is displayed as a starting point (tree structure of the left hand side in Fig. 3 shows the CLASP process [13]), then the related pieces of knowledge are
Masahito Saito et al. / Procedia Computer Science 60 (2015) 1092 – 1100
1095
associated. As Fig. 2 shows, there are ten types of knowledge regarding software security. Instances of each type are identifiable by color. This is a solution to requirement (5). When a user selects a node (s)he would like to access, the details of the knowledge and a list of artifacts that use the knowledge are shown. Visualization is implemented by using D3 [10].
Fig. 2. Schema of software security knowledge base
Fig. 1
Fig. 3. Visualized software security knowledge base (excerpt) 3.2. Artifacts management system In general, dependence relationships exist between artifacts created in software development. This applies to secure software development. Countermeasures extracted in secure requirement analysis have to be designed, then implemented as code. To support this, we represent relationships between artifacts explicitly (requirement (6)). We also visualize relationships between artifacts and pieces of knowledge used in preparing them (Fig. 4). In Fig. 4, squares represent artifacts, circles represent knowledge, and a link between an artifact and knowledge shows what kind of knowledge is used to prepare an artifact. This figure shows some prepared artifacts (“misuse case,” and “secure
1096
Masahito Saito et al. / Procedia Computer Science 60 (2015) 1092 – 1100
code”) of secure software development by some participants and relationships between artifacts and knowledge used to prepare them. We can see some pieces of knowledge such as “session management” and “password brute force” are used by some participants from the central part in Fig. 4 (surrounded by red line).
R equirement analysis
S ession mgmt M is -use case
M easure to C S R F L ogging
M is-use case M is -use case
M is -use case M is -use case S ecure code
P re questionnaire P ost questionnaire
A pplication
P ost questionnaire M is -use case
M is -use case
Fig. 4. Visualization of relationships between artifacts and software security knowledge used 4. Experiment We conducted an experiment to show usefulness of our case-based management system. 4.1. Overview of the experiment We describe an overview of the experiment. (1) Objectives Objectives of the experiment are the following three points: 1) Usefulness evaluation of using cases 2) Usefulness evaluation of visualizing relationships among software security knowledge and those between software security knowledge and artifacts 3) Usefulness evaluation of associating software security artifacts with software security knowledge for a task as rationale (2) Procedure Each participant creates software security artifacts by referring to a case and knowledge base as input. Each participant is asked to create a case of his secure software development that is consisted of artifacts and association of the artifacts with software security knowledge that referred to prepare the artifacts. By development referring to the stored case and software security knowledge, we clarify (1) and (2) of the objectives of this experiment. By the participants registering their case, we clarify (3) of the objectives of this experiment. We describe the knowledge base provided for this experiment in (5) of this sub-section and the case provided for this experiment in (6) of this subsection. (3) Participants We asked two students of our laboratory for tackling the task. One is the third year undergraduate student (we call him A). Another is the fourth year undergraduate student (we call him B). Both students have experiences on software development in the form of Project-Based Learning (PBL). (4) Task
1097
Masahito Saito et al. / Procedia Computer Science 60 (2015) 1092 – 1100
The task is a web application development that informs lab members of events or duty in a lab using JSP and Servlet technologies. In this experiment, we asked the participants for developing the following two functions only, registration of events and browsing of them. (5) Knowledge base used in the experiment For constructing our KB, we use existing materials that are public and available on the Web. We registered the following contents z Process: we adopt the Comprehensive, Lightweight Application Security Process (CLASP) [13] because it addresses a full lifecycle. We also adopt the security requirement analysis method by Okubo and Tanaka [11] (an extension to the method by Sindre and Opdahl). We position this method as part of the CLASP process. z Principle: principle of CLASP [14]. z Security pattern: we adopt the patterns by Yoder and Barcalow [16]. z Guideline: we adopt web application design guideline by Microsoft [8] and Mozilla secure coding guideline [3]. z Rule: we adopt the Open Web Application Security Project (OWASP) Cheat Sheet [15]. z Attack pattern: we adopt Common Attack Pattern Enumeration and Classification (CAPEC) [9]. We associate each attack with “Spoofing,” “Tampering,” “Repudiation,” “Information disclosure,” “Denial of service,” and “Escalation of privilege” (STRIDE), which is a category of threats [8], because it is often used in threat analysis. When a relationship exists between pieces of knowledge, we register the relationship. For example, CAPEC is a dictionary for attack. The schema has the item “solution and mitigation.” When the descriptions in the item are found in other knowledge such as guidelines or rules, we set the relationships between the attack pattern and guideline or rule. (6) A case provided for the experiment We used the common task for software security proposed by Okubo et al. as a case [12]. It aims at standard data for experimenting on and evaluating methodologies developed for secure software development. The task called EMSSec is an academic affairs management system for a university whose major functions are management of explanatory meeting participants, management of enrolled students, and management of certificates for graduated students. The following artifacts are created for the task as a project (hereafter, the common task project): use case diagram, class diagram, tree diagram of threats and their countermeasures, and source code written in CakePHP. They are created by experts in software engineering and software security. We provided misuse case diagrams we created by referring to the tree diagram of threats and their countermeasures and source codes in PHP, and association of them with KB as a case [6]. Fig. 5 shows a misuse case diagram regarding authentication of the task and associated knowledge to prepare it (excerpt). prevents
User Elevation of privilege enables Information disclosure
Third party
Spoofing
CSRF
Brute force attack
Account lock
enables
Measure to XSS
XSS
Logging
enables
Enhancement of password
enables
periodical change
prevents
Session fixation
detects
enables
Measure to session fixation
prevents
enables
Session hijacking enables
Measure to CSRF
Safe session management
Session conjecture
Separation of AP
threaten MITM prevents Encryption of channel
User ID and password
threaten
authentication User
D etail of the artifact
N ame T ype D ate O rigin R emark
prevents
[misuse case diagram for authentication]
M isuse case diagram 2 D ec. 12, 2014 S ource of the P J
Theft of DB
enables
DB
Measure to injection
Info. disclosure enables
prevents
enables
DB encryption
DB access prevents
Injection attack
Password hashing Third party
K nowledge used N ame of knowledge A O S R E (A spect-O riented S ecurity R equirement E ngineering) us ing A ss eM is
C ontents I extracted threats and cons idered meas ures us ing this method. S eparation of A P L imitation of acces s L ogging L ogging
Fig. 5. Example case (extended misuse case diagram and knowledge associated with it)
1098
Masahito Saito et al. / Procedia Computer Science 60 (2015) 1092 – 1100
4.2. Result We show some results of the experiment. Fig. 6 represents a misuse case diagram created by participant A and associated software security knowledge. We can see that (s)he selected necessary knowledge by referring to the case from the description, for example, “I referred to MITM in the case example” in the “contents for knowledge used.” We can also see some comments that (s)he learned from the case because (s)he did not have necessary knowledge. We think these comments suggest usefulness of the case.
D etail of the artifact Name T ype D ate O rigin R emark
M isuse case diagram 2 D ec. 18, 2014 S ource of the P J
K nowledge used
C ontents I referred to M IT M in the case example. I referred to the case example and received advice from my senior. I referred to the case example. I referred to the case example. I had that known, but the case example is useful for reaffirmation. I had no knowledge for that, therefore, I learned it from the case example. I had no knowledge for that, therefore, I learned it from the case example. I had no knowledge for that, therefore, I learned it from the case example. I had no knowledge for that, therefore, I learned it from the case example.
S Q L injection
Fig. 6. Case created by a participant (extended misuse case diagram and knowledge associated with it) Fig. 7 shows a list of knowledge associated with the source code of an authentication function. It includes password brute-force, dictionary attack and password conjecture that are the countermeasures to the spoofing attack.
S ecure source code 9 J an. 7, 2015 S ource of the P J
Name Type D ate O rigin R emark
K nowledge used C ontents
S Q L injection
A s M ITM is an attack on network, its measure is to encrypt channel. J ava addresses measures to session fixation and session mgmt by default. Therefore, session fixation and session conjecture will be solved. I take measures to X S S attacks by X S S .java. I take measures to injection attacks for all DAO…. I take measures to C S R F by C heckE ventS ervlet and E ventR egisterS ervlet. I take measure by counting the number of login failure for the same ID and get the last login time in LoginManager. I take measure by counting the number of login failure for the same ID and get the last login time in LoginManager. I take measure by counting the number of login failure for the same ID and get the last login time in LoginManager. J ava addresses measures to session fixation and session mgmt by default. Therefore, session fixation and session conjecture will be solved. A pache and Tomcat will take measures to this attack.
Fig. 7. Case created by a participant (a source code file and knowledge associated with it)
Masahito Saito et al. / Procedia Computer Science 60 (2015) 1092 – 1100
1099
We conducted an interview to the participants to investigate whether our system achieved the objectives. Table 1. Comments from the interview Assessment Comments from the participants items z A case provided is useful for discovery of countermeasures although implementation language differs. Opinion for use of stored 9 As the number of cases is few and the case does not always include all of the countermeasures, for example, countermeasures to theft of DB, I had to look into points in question. cases 9
Opinion for visualization Opinion for creating a case
z 9 z 9 9 9
9
Some countermeasures, concretely speaking, session management depend on implementation language. In PHP, setting for session management is needed, while Java manages session by default. Visualization of KB is useful for retrieving knowledge. It is difficult to search for knowledge that is less used. I learned security from requirement analysis to design by practice. It is inconvenient to create artifacts over browsing knowledge because development environment is not seamlessly integrated. Pre-conditions are unclear for both the common task and the task assigned. Therefore it was difficult a countermeasure should be addressed by operation, by environment or by development of functions. It took costs to modify source codes by referring to those created by others. In this experiment, I do not know whether my code is surely secure because testing is not conducted.
5. Discussion We found some opinions that suggest effectiveness of usage of cases and visualization support. Although programming language is different between the stored case (PHP) and the task (Java), the stored case helped both participants understand the way of countermeasures. z The function that represents both the relationships among software security knowledge and those between knowledge and artifacts in a network structure is useful for retrieval of knowledge. On the other hand, we have some drawbacks: 9 In the item “opinion for visualization,” a participant pointed out that it was difficult to find knowledge of which frequency of usage is less by merely visualization. 9 It takes costs for association of artifacts with knowledge because the environment to create artifacts is not seamlessly integrated into our KBMS. 9 In addition, in the current implementation, an artifact is managed by file as the unit. Therefore as association of knowledge is conducted for file, both participants pointed out it was difficult where each knowledge designates in the artifact. If elements that compose of an artifact are associated with each piece of knowledge in a software engineering environment, we think the relationships between software security knowledge and a part in an artifact make clear. 9 In the evaluation item, a participant pointed out that it is unclear how a case addressed security in the artifact because the requirements were unclear in the task. We found pre-conditions should be clarified in the task. From this experiment, we confirmed effectiveness of both usage of cases and a visualization function to represent both the relationship between software security knowledge and the relationship between artifacts and software security knowledge. In addition, we found that creating a case that associates artifacts with the software security knowledge is useful for learning. On the other hand, some issues were pointed out: even though cases implemented by different languages are useful for discovery of countermeasures, countermeasures in the implementation phase are different, therefore cases by different languages in the implementation phase are required. It is also necessary to provide a software engineering environment that can support artifacts creation and associate artifacts with the software security knowledge. z
6. Conclusions This paper has described a case-based management system for secure software development that integrates software security knowledge base and an artifact management and associates artifacts with software security knowledge. We
1100
Masahito Saito et al. / Procedia Computer Science 60 (2015) 1092 – 1100
also conducted an experiment to show effectiveness of the case-based management system. We confirmed effectiveness for retrieval of the knowledge by visualization of knowledge base. On the other hand, we found necessity to be able to associate knowledge within a development environment. In addition, even though cases implemented by different languages are useful for discovery of countermeasures, countermeasures in the implementation phase are different, therefore cases by different languages in the implementation phase are required. Acknowledgment This study was conducted as the 2014 joint project by National Institute of Informatics. The knowledge base was developed by partially supported by the Grant-in Aid for No. (C) 22500910 and 26330394 from the Ministry of Education, Science, Sports and Culture of Japan. The common task is a research result of the 2013 Strategic Software Research. The authors would like to thank anonymous reviewers for their comments to improve the manuscript. References 1. Apvrille A, Pourzandi M. Secure Software Development by Example. Security & Privacy 2005; 3:4 10-17. 2. Barnum S, McGraw G. Knowledge for Software Security. Security & Privacy 2005; 3:2 74-78. 3. Coates M, Lyon C, Goodwin M. WebAppSec/Secure Coding Guidelines, https://wiki.mozilla.org/WebAppSec/Secure_Coding _Guidelines (Accessed 1 Apr. 2015). 4. Hakon P, Ardi M S, Jensen J, Rios E, Sanchez T, Shahmehri N, Tondel I A. An Architectural Foundation for Security Model Sharing and Reuse, Proc. ARES 2009. 823-828. 5. Hazeyama A., Shimizu H. Development of a Software Security Learning Environment. Proc. SNPD 2012; 518-523. 6. Hazeyama A, Saito M, Yoshioka N, Kumagai A, Kobashi T, Washizaki H, Kaiya H, Okubo T. Case Base for Secure Software Development Using Software Security Knowledge Base Proc. STPSA2015, in conjunction with COMPSAC2015 2015 (To appear). 7. McGraw G. Software Security. Security & Privacy 2004; 2:2 80-83. 8. Microsoft. Design Guidelines for Secure Web Applications. https://msdn.microsoft.com/en-us/library/ff648647.aspx (Accessed 1 Apr. 2015). 9. The MITRE Corporation, CAPEC, http://capec.mitre.org (Accessed 4 Jan. 2013). 10. Murray S. Interactive Data Visualization for the Web, an Introduction to Designing with D3. O'Reilly Media; 2013. 11. Okubo T, Tanaka H. A Proposal of an Efficient Security Requirements Analysis Method. J IPSJ 2009; 50:10 2484-2499 (In Japanese). 12. Okubo T et al. Study on Common Task in Software Development That Takes Security and Privacy into Account. Forum on Strategic Software Research; 2013. http://www.iisf.or.jp/SSR/prpsl_pdf_2013/p13_11_okubo.pdf (In Japanese). 13. OWASP. CLASP Best Practice. https://www.owasp.org/index.php/Category:CLASP_ Best_Practice (Accessed 1 Apr. 2015). 14. OWASP. CLASP Security Principles, http://www.owasp.org/index.php/CLASP_Security_ Principles (Accessed 1 Apr. 2015). 15. OWASP. Cheat Sheet, https://www.owasp.org/index.php/Cheat_Sheets (Accessed 1 Apr. 2015). 16. Yoder J, Barcalow J. Architectural Patterns for Enabling Application Security, Proc. PLoP’97, 1997.
