A Case Study of Adopting Security Guidelines in Undergraduate Software Engineering Education

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.


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.

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.

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.

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 ( D V ) 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.

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 3column 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.If wrongly declared, data confidentiality, integrity, and availability may be violated.Q.2.Use a try-with-resources statement to safely handle closeable resources.
The try-with-resources statement ensures that each resource is closed at the end of the statement.
When resources are not closed properly, data confidentiality, integrity, and availability may be violated.Q.3.Avoid using try-catch-finally block.
Ordinary try-catch-finally block can raise some issues: such as failing to close a resource because an exception is thrown as a result of closing another resource, or masking an important exception when a resource is closed.
When resources are not closed properly, data confidentiality, integrity, and availability may be violated.Q.4.Use the same type for the second and third operands in conditional expressions.
Use different types in a conditional expression may cause unintended type conversions.
When types are not the same, data integrity may be violated.Q.5.Avoid using static field variables.
Static variables are class variables, not instance variables.Science any other class in the same scope can access the static variables, it is very difficult to secure them.
Since static variables can be modified by other classes in the same scope, data integrity may be violated.

Q.6. If possible make public static fields final
Otherwise, attacker may change the value.If value changed, data integrity may be violated.

Q.7. If possible, use immutable objects.
Contents of the mutable object can be changed.
If contents changed, data integrity may be violated.
Contents of the mutable objects can be changed.Clone the objects before processing them internally.
If contents changed, data integrity may be violated.
After compilation, any class in the package can access the inner class.Meanwhile, private filed of the inner class will be converted into non-private to permit access by the inner class.
If other classes in the package can access the inner class, data confidentiality and integrity may be violated.If private filed of the inner class changed, data integrity may be violated.
Q.10.Avoid using the clone() method to copy untrusted method parameters Inappropriate use of the clone() method can allow an attacker to exploit vulnerabilities by providing arguments that appear normal but subsequently return unexpected values.Such objects may consequently bypass validation and security checks [22].
Data confidentiality and integrity may be violated.
Otherwise, malicious developers can instantiate a class without running its constructors [2].
This may violate data confidentiality and integrity.

Q.12. Avoid embedding sensitive information
Malicious developers can obtain such a sensitive information This may violate data confidentiality.

Q. 13. Prevent constructors from calling methods that can be overridden
Constructors that call override methods give attackers a reference to the object being constructed before the object has even been fully initialized This may violate data integrity

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.

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.This public static method purpose is to connect to the database within the application.vMethodpulls necessary information: Symbol, Name, Percent_Change, Price, Price2, Price3, Days_High, and the Days_Low.
This is the strategy method that runs the trading strategy of the application.The stock is updated from the sandp500 and if the stock is in portfolio (the stock that we own) and if the stock is in the watchlist (the stocks we are watching, not owned) each strategy is performed.

Q.1, Q.2 public static void main(String[] args)
The main method within this application because this application is deployed by JavaFX.The main serves only as fallback in case the application cannot be launches through deployment artifacts.

Q.1 public void updateAccount()
This method simply updates the account.The method updates watch list tab, portfolio tab, and also update past tab method Q.1

Observations and Suggestions
In this research, we observe that there are several common security vulnerabilities appearing in the capstone project.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: 123 6% 2036 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

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

Q.2
More than one resource operations in the try-catch-finally block Since several exceptions may be thrown, some exceptions will be masked.

Q.5 Static variables
Since other classes in the same scope may be able to access and modify a static variable, this variable should better be claimed as final static. Q.9 Inner class Since there are some security issues related to inner class.It is better to move inner classes to outer classes.
Q.12 Sensitive information Use Java security APIs to handle sensitive information.
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.

Table 1 .
Critical questions, explanations, and potential software vulnerabilities.Private: visible to the class only • Public: visible to the world • Protected: visible to the package and all subclasses.

Table 2 .
Vulnerability assessment for variables in the M3_Main class.

Table 3 .
Vulnerability assessment for methods in the M3_Main class.This startTask class extends the TimerTask of the program and it called every certain amount of minutes to basically check if the market is open or not and then runs on another thread.A run method determines if the market is open or close based on the times of 9:30 am -4:00 pm M-F.

Table 4 .
Vulnerability assessment for variables in the wallet class.

Table 5 .
Vulnerability assessment for methods in the wallet class.

Table 12
and has the vulnerability density close to 0%.That is 0% D V ≈.

Table 6 .
Vulnerability assessment for variables in the stock class.

Table 7 .
Vulnerability assessment for methods in the stock class.

Table 10 .
Vulnerability assessment for variables in the Trade_Decision class.

Table 11 .
Vulnerability assessment for methods in the Trade_Decision class.This method is run through for stocks within the watch list.Here we use three different prices that are refreshed constantly which are then ran through number of if statements to determine if the stock should be bought, or left alone.This method is run through when stocks are in the portfolio.Again they have used three different prices that are ran through a number of if statements; each refreshed 3 different times to determine if the stock should be sold or held within the portfolio.

Table 12 .
Suggestions for eliminating common software security vulnerabilities.The product should make all classes package-private, since they are in the same package (M3Application) and not served as an API or interface for external classes.This implementation is not appropriate.Methods in the product should obtain at least default access modifier privilege.Most of them should be in private access modifier privilege, since they are used internally.Q.1Variables are public Variables should limit the accessibility.In this product, most variable should be in private access modifier privilege.Q.2 Resource is not proper closedThis product should use try-with-resources statement to ensure each resource is closed at the end of the statement.