Received 20 September 2014; revised 22 October 2014; accepted 18 November 2014

ABSTRACT

Security plays a large role in software development; simply without its existence the software would be vulnerable to many different types of attacks. Software security prevents leaks of data, alternation of data, and unauthorized access to data. Building a secure software involves a number of different processes but security awareness and implementation are the most important ones among them. To produce high quality software security engineers need to meet today’s cybersecurity demands, security awareness and implementation must be integrated in undergraduate computer science programming courses. In this paper, we demonstrate the importance of adopting security guidelines in undergraduate software engineering education. Thus, this paper focuses on integrating secure guidelines into existing applications to eliminate common security vulnerabilities. An assessment table, derived from several existing Java security guidelines, is developed to provide in depth critiques of the selected capstone project. Potential security vulnerabilities in the capstone project are identified and presented in a form showing the degree of threats against the three security characteristics: confidentiality, integrity, and availability addressed in the McCumber Cube model. Meanwhile, vulnerability density of the capstone project is calculated to demonstrate the performance of this research.

Keywords:

Software Security, Security Guidelines, McCumber Cube Model, Vulnerability Density

1. Introduction

Security is a term that you simply cannot get rid of. As computers become more and more prevalent in our daily lives it becomes even more important to safeguard these technologies. This is just as important as in the topic of software engineering. A vast majority of attacks make use of software vulnerabilities that are entirely preventable. It is stated by a pair of two leading experts, John Viega and Gary McGraw, “behind every computer security program and malicious attack lies a common enemy―bad software” [1] . Within the topic of software engineering, security is defined as the effort to create software in a secure computing platform. Software security prevents the following: leaks of confidential data, alternation of data without the knowledge of the system, and unauthorized access to the system [2] .

Software must be designed as well as implemented so that the secured users can perform actions that are needed and have been allowed. Building secure software involves many requirements and polices which thus produce a set of laws, rules, and practices that users have to abide by. These policies would address the following: data security, information security, and content security [2] . Data security refers to protective digital privacy measures that are applied to prevent unauthorized access to computer, databases and websites [3] . Some examples of data security technologies include software/hardware disk encryption, backups, data masking and data erasure [3] . Information security is designed to protect the confidentiality, integrity and availability of computer system data from those with malicious intentions [4] . Content security or sometimes referred to as digital rights management is the use of software or other computer technology to manage the conditions under which copyrighted material in digital form can be accessed [5] .

Almost all computers are connected to a local network or the Internet so every piece of the software deployed in a system is subject to potential adversaries. Several approaches in literatures have aimed atreducing potential software breaches [6] - [8] and the ones that integrate security aspects into Software Development Life Cycle (SDLC) are adopted most [6] [9] - [11] . However, they may not be good resources for educating computer science students because complicated knowledge and procedures are involved in every phase of the SDLC.

This paper focuses on using existing products and selected security guidelines to explain and verify how to implement a secure application. We have selected 13 critical questions from several Java security guidelines to reflect most common security errors in students’ codes. We then use these critical questions to assess every component in the selected capstone project. Each component will be scored using McCumber’s Cube model which evaluates information security in terms of data confidentiality, integrity, and availability [12] . Possible solutions for each vulnerability are also suggested.

The remainder of this paper is organized as follows: Section 2 reviews related work. Section 3 brings up our motivation. Section 4 defines software security metrics adopted by this paper. Section 5 explains the approach of adopting security guidelines to identify software vulnerabilities. Section 6 presents background of the selected capstone project. Section 7 assesses every component in the capstone project and discusses our observations and suggestions. Section 8 lists our observations and suggestions. Section 9 concludes this paper and points out future work.

2. Related Work

Several literatures have studied and addressed strategies with regards to how to implement security within the software development process. For example Computer Emergency Response Team (CERT) began new research in 2009 in software security measures that build on CERT’S core competence in software and information security. The overall purpose of this research was to address the following questions which include: “how do I establish and specify the required/desired level of security for a specific software application, set of application software-reliant system, system of systems, supply chains, and other multi-systems environments” [13] . Also, “how do I measure, at each phase of the development or acquisition life cycle that the required and/or desired level of security has been achieved?” [13] .

In addition, Jorge A. et al. have also researched this topic [14] . They both believe that most of the software developed in the world use classic methods which include: the classic Waterfall Model, Spiral Model, Capability Maturity Model Integration (CMMI), Team Software Process (TSP) and Personal Software Process (PSP) [6] [14] . All of these classic methods with regards to software development are mainly dedicated to the quality and consistency of the software development process and not security. They believe it is necessary to modify these classic evolutionary deployment models by adding computer science security. Their paper propose to add security through all the phases of the process. They have concluded that everything within the process of software development must be reviewed thoroughly [14] .

The McCumber Cube methodology offers a structured approach to assessing while also managing security risk in IT systems [12] [15] [16] . This model relies on the implementer to identify information assets and then think of risk management in a deconstructed view across 3 different characteristics which include as follows: confidentiality, integrity and availability of critical information [12] [16] . The strength in this model is in the multidimensional view required to implement robust Information Assurance (IA) programs. Well-executed systems will include this IA model during all phases of the SDLC.

3. Motivation

We have observed several cases showing the consequences of software vulnerabilities [17] [18] . For instance, a report from Capers Jones reveals that there are a number of vulnerabilities in most commercial software with10,000 function point size range and it will cost almost 50 cents out of every dollar to find and fix bugs [17] .

Another report, released by B2B International and Kaspersky Lab in 2013, reveals that the average financial loss of IT security breaches suffered by large companies from a single serious incident was $649,000. For small and medium size companies, the average financial loss was $50,000. Meanwhile, they also indicated that vulnerabilities in the software ranked highest among all internal threats faced by companies during 2011-2013 and about 10% of these threats caused leaks of important business data [18] .

These instances bring up our motivation of studying and engaging software security and quality knowledge into software engineering education. We make the assumption that with strong security knowledge gained during their undergraduate programming courses, our future software engineers will be able to eliminate most vulnerabilities within applications in the earlier stages of their SDLC process. As a result, many security breaches happened in today’s software could be eliminated and financial loss associated with them could be saved and re-invested.

4. Software Security Metrics

Several literatures have proposed the metrics of measuring software quality or security [19] [20] . In this paper, we assume that a potential vulnerability exists if a defect in the code leads to the violation of data confidentiality, integrity, and availability. Where, defect is defined as any issue that causes incomplete executions of the software. Thus, this assumption could be rewritten as:

A defect z {vulnerability} if z leads to the violation of data confidentiality, integrity, and availability.

We also define the vulnerability density () as the number of vulnerabilities in one line of code (LOC). Therefore, we have

where, V is the number of vulnerability and S is the size of the software in the unit of one LOC. Vulnerability density could be used to measure the programming in terms of how secure the code is. If other conditions are the same, a program with a higher vulnerability density is likely to be compromised more often.

5. Adopting Security Guidelines to Identify Software Vulnerabilities

To identify potential vulnerabilities in the application, this paper adopts security guidelines from several resources which emphasize on Java security design and implementation. As shown in Table 1, we create a 3- column table to address the criteria for identifying software vulnerabilities. A list of 13 critical questions derived from several existing Java security guidelines [2] [7] [8] [21] [22] is presented in the first column. These 13 questions are used to assess every component in the application to see whether there exist vulnerabilities in such a component. Explanations of every critical question are presented in the second column. Last, potential vulnerabilities of every component against the three security characteristics (i.e. confidentiality, integrity, and availability) addressed in the McCumber Cube model are listed in the third column. We examine most components including variables, methods, and classes in the application thoroughly to see whether any of them violates these security characteristics and to count the number of vulnerabilities as well as the vulnerability density of the application.

6. Capstone Project Background

Since focusing on software engineering education, we choose a computer science capstone project as the sample to examine common security vulnerabilities appearing in students’ projects. The application is selected from last year’s senior computer science capstone course. The goal of this project was to create an application for computerized stock trading. The student team developed their own algorithms to implement their trading strategy with how they buy or sell stocks. The algorithms are based on the trading strategies including high-frequency trading, day-trading, and investment. High-frequency trading strategy is where stocks are only held for a fraction of second or a few seconds. Day trading is a strategy where stocks may be purchased and sold several times in the same day. Finally investment strategy; where the holding period may be a few days, weeks, or even a holding period for a long-term capital gain.

The capstone project consists of 5 Java classes: M3_Main, Wallet, Stock, Transactions, and Trade_Decision. M3_Main class is the main class that interacts with other classes in the product. Wallet class handles all transactions that happen within the wallet whenever the application buys or sells stock based on their own algorithm. Stock class handles all information regarding the stocks depending on the application buying or selling based on

the algorithm. Transactions class is used for transactions made between the automated buying and selling of stocks while also allocating enough money within the wallet when the application buys a stock. Trade_Decision class is used for the trade decision between how stocks are bought and sold within the application. The project has totally about 2036 lines of code.

7. Vulnerability Assessment for the Capstone Project

Below these 3-columntables (Tables 2-11) provide in depth critiques of this capstone project which includes its classes, variables, and methods. In these tables, column 1 displays the details of variables or methods in each class; column 2 explains the meanings of variables or methods in the 1^st column; and column 3 indicates the critical questions that compromise variables or methods in the 1^st column.

8. Observations and Suggestions

In this research, we observe that there are several common security vulnerabilities appearing in the capstone pro- ject. We have analyzed them and addressed our suggestions below:

・ Accessibility of class, method, and variable should be addressed properly to protect data confidentiality, integrity, and availability.

・ Resources must be closed properly after released to protect data confidentiality, integrity and availability.

・ Resources must be monitored with special syntax and identifier to protect data confidentiality, integrity and availability.

・ Inner classes should be avoided to protect data confidentiality, integrity and availability.

・ Static variables should be avoided to protect data integrity.

・ Sensitive information should not be included in any part of codes and should be encrypted to protect data confidentiality.

At the end, 123 potential vulnerabilities (51 variables and 72 methods) are identified and classified in the capstone project with total of about 2036 lines of code. Therefore, the vulnerability density of this project can be estimated as:

This 6% vulnerability density is relatively high while comparing with most commercial applications [19] . However, we have to take into account that this represents students from last year’s computer science capstone course, who lack in software security awareness and quality knowledge. After the software security and quality knowledge have been introduced to a new group of students in this year’s senior computer science capstone course. Students in the new group are capable of identifying and rewriting these 51 variables and 72 methods. The revised project has eliminated most vulnerabilities listed on the Table 12 and has the vulnerability density close to 0%. That is.

9. Conclusions

After the study conducted on this capstone project we can now see and understand the underlying vulnerabilities that lie within this Java code. It is evident that the variables and methods within each of these classes are feasible to exploit within the application. It is also evident that the developers of the capstone project, while implementing, they were not aware of the threats they posed on themselves while developing. The very focus of this paper is to conduct a vulnerability assessment of this Java code to reveal its vulnerabilities. As you can see by using the guidelines above it is apparent that this application can pose many threats which include the following: integrity, confidentiality and even the availability of the entire application.

For example the use of public variables being created can pose threats of the following just listed. This was exemplified throughout the application time and time again. Another constant vulnerability that was found throughout the Java code included using static field variables. Since static variables can be modified by other

classes in the same scope, data integrity can be violated throughout the application. This vulnerability was exemplified in almost every class throughout the application, which can have serious impact to the core of the program. Constantly understanding and being aware of the threats that may occur throughout developing is very important in all applications and languages no matter what you’re programming in.

Having awareness throughout implementation of an application by using the guidelines and taking the time to cautiously implement will have great benefits, while also providing a more secure application. Again, the vulnerability assessment results confirm that the capstone project can be exploited to be able to carry out intellectual and also component penetrations. And this result also confirms the importance of our approach for adopting security guidelines into undergraduate software engineering education.

Acknowledgements

Dr. Yen-Hung Hu is an Associate Professor in the Department of Computer Science at Norfolk State University. Prior to joining the NSU, he was the Director of the Information Assurance Center at Hampton University and PI of the NSF CyberCorps: SFS HU GETS-IA program. Charles Scott is a graduate student in the Department of Computer Science at Hampton University and a scholarship recipient of the NSF CyberCrops: SFS: HU GETS-IA program.

References