College of Engineering
North Carolina State University
Raleigh, NC 27695
sdoster@arches.uga.edu

1. Introduction

Security has become an increasingly important topic as technology has become an integral part of our lives. Computers and other devices have become indispensable components of almost every home and office. As these technologies have provided the convenience of digital accessibility to all of our private personal and professional information, the consumer's chief concern has become the protection of that information. To establish trust and maintain clientele, vendors have been forced to consider the necessity of integrating security into their products.

There are several different methodologies that can be used to develop software, but the focus of our research project has been on Extreme Programming (XP) and its ability to produce secure software. Of recent, organizations long known for producing high-quality safety- and mission-critical applications, such as Motorola [1], IBM [2], and NASA [3], are adopting XP and/or XP-like methodologies. However, security experts are concerned that XP will have a negative impact on software security [4].

The research this summer has focused on a subset of the Trusted XP project. We have created a survey for customers as an aid for the requirements gathering phase of any software development process (including XP). In this paper, we will discuss the different areas which have had an influence on the creation of the survey, and then look at the details of the survey itself, followed by how we hope to use this information in the future.

2. Background Security Information

Many of the security problems that exist in software products today are problems that were introduced by the developers, as is outlined numerous times in [4]. Therefore, this is the area where most of the work needs to be done in order to remedy the problem. However, customers also need to be aware of where potential problems lie, so that they can know what to insist upon in the software they intend to purchase or have developed. There are several categories of possible security holes that developers can introduce into a product. We will take a moment to discuss three of these flaws. This is by no means an exhaustive list, but it does attempt to cover briefly some of the major security concerns.

2.1 Buffer Overflows

One of the most common security problems within software arises from buffer overflows. The CERT Coordination Center [5] issues daily advisories of discovered security flaws, a large percentage of which is composed of buffer overflows. McGraw and Viega give a detailed presentation of how buffer overflows cause problems in their book Building Secure Software [4]. A buffer overflow can occur when there are no appropriate bounds checking mechanisms in place when a string is entered into the program. In this case, a user can submit a string which is too long for the buffer which is supposed to hold it, consequently overflowing that buffer. The additional characters in the submitted string will spill out into memory, covering over other, potentially important data. In the best case, such an overflow will cover over non-allocated memory, and there will be no noticeable problems to the user or the software. However, attackers can potentially exploit such a flaw by submitting specially crafted strings into the software. For example, a string could overflow a buffer and write over the return address of a function, causing the program to jump to a point in the code specified by the user which would execute the requests of the malicious user, rather than following the intentions of the developer.

Though buffer overflows can be innocuous, the most pernicious examples can be exploited to grant access to a system. In either case, the problem can easily be avoided if developers simply check that any input they receive from users is within the specified bounds of the array and truncate the string otherwise. This problem is also non-existent in languages such as Java, which provide internal bounds checking for the programmer. The problem of buffer overflows demonstrates the importance of alert developers, whose bugs can create exploitable security flaws.

2.2 Race Conditions

Another common security problem found in software (and reported frequently by CERT) is race conditions. Race conditions occur in multithreaded environments when poor coding introduces a window of vulnerability in which certain input will force the code to respond in a manner not intended by the programmer. For example, this happens when one thread is able to modify a variable before another thread is finished using it, making the second thread continue processing with an incorrect value in the modified variable. The main security problems related with race conditions are has to do with file-based time-of-check, time-of-use flaws. As a standard example of this, a program running with root privileges (access to the entire system) is asked to perform a write to a file specified by the user. The program will first perform a check to see if the user has permission to write to the file, and then it proceeds to open and then write to the requested file if this permission is granted. The exploitable race condition occurs between the check for permission and the actual opening of the file. If during that window of vulnerability, the user is able to switch the file he requested with a file he wouldn't normally have access to, such as the password file, the program will then write over the password file instead of the originally requested file. Thus, he will have exploited the race condition to get unauthorized access to the password file - a clear security violation.

This is only one example of the danger of race conditions, but there are many others. The relative ease with which this attack can be executed should encourage developers to locate and eliminate these problems in their code. Exploiting a race condition requires only patience on the part of an attacker.

2.3 Internet and Wireless Security

The Internet has introduced a whole new range of security problems as it provides a means for users to launch attacks on systems housed thousands of miles away. Similarly, the introduction of wireless technologies is further facilitating the problem by allowing attackers to use easily discarded, untraceable devices to launch attacks. In his book Security & Privacy for E-Business, Ed Ghosh outlines some of the major problems facing software that runs in this type of environment [6]. Some of the security holes he points out include the fact that users could potentially modify forms on web pages and send invalid information, as well as the fact that hidden fields are not really hidden, and users could still potentially modify these fields.

3. Standardization of Security

We have shown that there are many different types of security problems related to software development, which has prompted a study into a means of formalizing how a specific piece of software responds to these kinds of problems. Recently, a form of standardization called the Common Criteria (CC) [7] has come into prominence with its claim to provide a quantifiable definition of the security level of any software product. The CC provides Evaluation Assurance Levels (EAL) which would be assigned to every piece of software which submitted itself to an evaluation against the CC. There are seven different EALs which provide an increasing level of security assurance. Products with these seals of approval will be guaranteed to have a quantifiable level of security. Each seal guarantees more functional security than the previous, as there are increasing requirements which must be met in order for a product to receive a higher seal. This attempt at establishing an objective security standard should aid in the alleviation of some of the security problems, as well as give customers a tangible seal of a product's trustworthiness. Though there is always the concern that the EALs will lull customers into a false sense of security, such standardization is still a positive step in the attempt to provide secure software.

4. Security Policies and Standards

The CC is concerned with an objective standard of security; however, there are also company specific security standards which have to do with company security policies. As our research has to do with these particular standards, we will take a moment to define them. Security standards would be detailed extensions of the company's security policy, and they would easily translate into security requirements that could be incorporated into the first stage of the software development process. To clarify, a company's security policy is a very general statement of what its security related intentions. An example of a statement in a security policy would be "We will require access control for our remote users." On the other hand, a standard is a more detailed extension of the policy. For example, a security standard that built on the following statement from a policy would be "We will require the use of passwords of a minimum length of 10 alphanumeric characters to authenticate our remote users." The more complex distinctions between policies and standards are discussed in [9]. Our research focuses on creating these company specific security standards.

5. Software Development Approaches to Security

There are two different techniques that developers have employed in order to provide security in their products.

The first model, often used, adds security considerations on at the end of the production of the application. Those who follow this methodology do not consider security as an initial requirement and instead try to add a few security related modules just before releasing the product or, possibly, after product release based on actual security breaches. They then offer a "patch" to the problem, which may or may not contain its own security flaws. Though this technique is by no means effective, it is the most widely used model because of its ease on the software developers.

The second model takes the approach that security must be integrated into every step of the software development life-cycle in order for it to be addressed properly. Proponents of this theory maintain that software can only be secure if it is considered throughout the development process. This means that security should be a consideration in requirements gathering, coding, testing, and every other phase of development. Though this approach is more time consuming for the developers, it actually provides an effective means of including security in software. Unless all of the individuals involved in the process of creating the software are thinking about making the product secure, the final product is unlikely to be secure. Our following research with the survey is concerned with implementing this approach to software development.

6. Survey

Following the previous discussion of security and software development procedures, our current research has been concerned with the need to integrate security into every phase of the software development life cycle. This methodology presents the most effective means of preventing security flaws in the software. To be as effective as possible, this issue needs to be addressed by both customers and developers, and our current focus is helping customers create effective security standards that can be translated into software requirements. These requirements would then ensure that both parties will understand the exact place of security within the software development process.

We have created a survey, which can be found in the Appendix, which will do two things. First, it will assess how customers prioritize security. Second, it will gather information from customers about their current security-related actions with the intention of using this information to provide a classification for establishing standards that reflect the company's security policy.

The types of questions fall into several distinct categories. We will examine how each of these categories presents a security problem and show how the types of questions we asked will work to address each of them.

6.1 Users

The first category of questions has to do with the people who will actually use the system. In any system, the human element is always the weakest link because people can easily be manipulated into divulging private information. Our questions have to do with how users will be granted access, which information users will have access to, and how the users can be held accountable for their actions.

The first (and often easiest) attack for a malicious party gain entrance to a system is to steal a password from a trusted user. There are several different ways that this could occur. One way would be to use social engineering to manipulate a trusted third party, who has access to the passwords, into divulging the password. There is also a possibility that a user would write down their password, as a personal reminder, and then leaving that paper somewhere that at attacker could gain access to it. Yet another option would be that a user could choose a poor password, such as a word from the dictionary, which would be easy for a malicious user to guess. These are specifically problems that customers of software products will need to address in their specifications, and thus we attempt to address these potentialities in our survey.

Another area of consideration for companies in the case of users has to do with the type of access each user is granted to protected information. First, users could, either intentionally or unintentionally, modify or delete information that they should never have been able to access. Granting only the absolutely necessary access should eliminate accidental and deter intentional modifications as users cannot abuse information to which they do not have access. Second, we previously discussed that passwords can be stolen, granting an invalid user access to the system. If we limit the permissions of the users as much as possible, this will at least curb the amount of information an attacker would have access to (excluding the case where the compromised account is one which has all permissions). This follows the principle of least privilege, as described in [4].

A final aspect which would, if not defend the company from attack, at least give them a means of recovery, would be to trace the actions of a user once they have logged onto a system. Once it can be determined that security has been breached, companies will need to be able to determine what information the attacker accessed. This will enable the company to recognize compromised data and respond accordingly (such as by using backups), facilitating recovery from an attack. Tracing actions could also enable a company to recognize a compromised account more quickly than otherwise, as certain questionable behavior could trigger an alert to the company's IT department.

6.2 Information Protection

This is one of the most important areas of discussion because the entire security problem revolves around preventing protected information from improper use. As such, this subject took up a substantial portion of the survey, in which our questions focused on determining the necessary external security related to the information, as well as how it would need to be protected. Our questions were general, but they were meant to encourage customers to relate each question to every specific subset of data that will need to be protected.

There are several external considerations that need to be taken into advisement about information protection. One of the first would be whether or not certain information has legal restrictions regarding its protection. If information needs to be protected by law, special considerations will need to be made to ensure that all legal stipulations will be met. Additionally, company policies about information should also influence decisions about security. The existence of both (or either) of these components represents a base level of security that must necessarily be met in the requirements of the system.

After deciding what needs to be protected and for what period of time, the company needs to decide how strong the protection needs to be. This relates to things such as encryption, and companies need to decide what level of encryption will be suitable to meet the needs of their situation. However, they also need to be concerned with the protection of information before encryption and after decryption as well. One of the common mistakes in security management is treating encryption as a panacea. It is far more important to have the same level of security for data throughout its residence in a program rather than having supposedly unbreakable encryption in one section and virtually no protection somewhere else. Attackers will always go after the weakest link in a system, making it highly unlikely that anyone would even attempt to break encrypted information if that same data can be taken in plain text at some other point.

6.3 Threats

One of the most important components of a security analysis is determining potential threats and company vulnerability to those threats. Threats can come from many directions, and we specifically addressed threats created by the environment in which the system will be used. Once again, this is not a comprehensive list of possible security threats, but it is intended to encourage customers to think about what threats they might encounter in their own situations.

Most threats arise from the environment in which an application is run. Companies particularly need to outline their vulnerabilities if their program will be accessible via wireless devices or the Internet, each of which has their own related problems. It is important that security requirements take into account all of these considerations. Another element that could potentially be threatening would be the choice of language. There are many types of threats inherent in certain languages, such as C and C++. [8] explains numerous bugs that C programs are liable to, especially referring to files and pointers. [4] details a number of insecure C library functions, which are easily exploited in a security attack. An uninformed developer could misuse certain library functions and inadvertently introduce security holes into a system. The customers should have an understanding of the security flaws within the language they want to use, so that they can ensure that developers will use that language properly.

Another threat which addressed in the survey falls into the category of the principle of least privilege. The threat involved would be that of allowing unnecessary access to the system which could potentially be exploited. For example, if none of the trusted users within a company need to make use of FTP, the company should not have that program running. Having that unnecessary functionality available introduces a potential threat that could readily be exploited by malicious users.

6.4 General Questions

None of the categories we have mentioned have intended to be comprehensive, and as such, there is a final grouping of general questions which attempt to address issues not covered in the other sections. There is a rough segmentation of these questions into three different sections: system robustness, security requirements gathering, and miscellaneous questions.

The first group of questions relates to system robustness and has to do with things such as scalability and load tolerance. Scalability refers to the ability of a computer application to continue to function well as it (or its context) is changed in size or volume in order to meet a user need. Load tolerance has to do with the ability of a system to distribute the processing throughout its components so that one part is not so overburdened that it crashes and opens the possibility of compromise in the system. Though these questions have more to do with survivability, which is loosely defined as the ability of a system to recover gracefully from a crash without compromising its security, they do touch on the security aspects of development and still need to be addressed.

The next group of questions has to do with information gathering about the current security requirements practices of the company. These questions mainly address what the company currently specifies in their requirements. Particularly, we ask about whether they specify what users may not do and whether they specify their own particular vulnerabilities. Building on this, we also try to determine how, if at all, they prioritize their vulnerabilities to threats. It is imperative that customers know from the beginning what their weaknesses will be so that they can decide which of these need to be addressed by the developers.

The final group of questions really is a catch-all of a number of different things that needed to be asked but did not readily fit into one of the aforementioned categories. Some of these questions are about the importance of having an unbiased third party review of the software before it is shipped. Another question asks about the inclusion of "shrink-wrapped" software, as including someone else's software into the project means that the project can only be as secure as the weakest point of the included software. Finally, there are a number of questions about the willingness of management to contribute financially to the security aspects of the project.

7. Future Work

The work related to the survey has just begun, and there is much more that will need to be accomplished in the near future.

7.1 Pilot and Edit survey

The first step will be to pilot the survey in order to get feedback from security experts about how effective our questions will be. We will send the survey to a number of carefully selected individuals and companies, and then we will modify the survey to include their suggestions. At this point, the survey will have received approval from a number of reputable sources, and we will be able to send it out to companies for their responses.

7.2 Administer the survey

The survey has been developed as a PHP web application. The results of the survey are automatically saved in a backend MySQL database for each of analysis.

7.3 Compiling responses

The next step in the process will be to compile the responses that we receive from sending out the survey. This phase will include general database maintenance as well as statistical analysis of the information gathered.

7.4 Creating security standards

Our ultimate purpose in creating this survey has been to help customers create effective security standards as described in Section 4. As such, our intention is to establish a taxonomy for creating these standards that are reflective of the company's security policy, which will simplify the requirements gathering process for companies.

7.5 Trusted XP

This research has been performed within the broader scope of a research project called Trusted Extreme Programming (XP). XP is a software engineering methodology that has several different components described in detail in [10]. The XP practices do not include the creation of high-level or low-level design that developers will refer to when coding. Instead, XP's informal requirements gathering practice is very functionally-oriented. Users specify the things they want and do not generally focus on non-functional requirements like security. Thus, many, such as the authors of [4], have questioned whether XP will be able to provide comprehensive security specifically because of this lack of design. Our project, therefore, has attempted to discover if it is possible for XP to provide security and, if so, what steps would be necessary in order to reach that point.

7.6 Necessity of training

Most of the security related problems arise from a lack of training for both customers and developers. In order for security management to be effective, all parties involved need to understand the problems and be thinking about them throughout the process.

8. Conclusions

This research was performed as a subset of the Trusted XP project. We hypothesize that our future work will lead to the discovery that the security standards we will produce will be compatible with the informal requirements gathering phase of XP. However, our findings should be beneficial to the entire field of software engineering as they speak to a topic that spans development methodologies.

Finally, there is no such thing as a completely secure system, but there certainly can be a system with no security. As we approach a more technologically dependent society, it is imperative that every effort be directed towards integrating security concerns into every phase of the software development life-cycle.

References

1. Bowers, J., et al. Tailoring XP for Large System Mission-Critical Software Development. in Extreme Programming/Agile Universe. 2002. Chicago, IL: Springer.
2. Krebs, W. Turning the Knobs: A Coaching Pattern for XP Through Agile Metrics. in Extreme Programming/Agile Universe. 2002. Chicago, IL: Springer.
3. Wood, W.A. and W.L. Kleb. Extreme Programming in a Research Environment. in Extreme Programming/Agile Universe. 2002. Chicago, IL: Springer.
4. Viega, J. and G. McGraw, Building Secure Software: How to Avoid Security Problems the Right Way. First ed. 2002, Boston: Addison-Wesley. 493.
5. Ferguson, P., et al., Results of Applying the Personal Software Process, in IEEE Computer. 1997. p. 24-31.
6. Ghosh, A.K., Security & Privacy for E-Business. 1st ed. 2001, New York: Wiley Computer Publishing. 240.
7. Fowler, M., Analysis Patterns: Reusable Object Models. Object Technology Series, ed. G.J. Booch, Ivar; Rumbaugh, James. 1997, Menlo Park, CA: Addison Wesley Longman, Inc.
8. Thielen, D., No Bugs! Delivering Error-Free Code in C and C++. First ed. 1992, Reading, Ma: Addison-Wesley. 206.
9. Peltier, T.R., Information Security Policies, Procedures, and Standards: Guidelines for Effective Information Security Management. 2002, Boca Raton: Auerbach Publications. 297.
10. Beck, K., Extreme Programming Explained. Fifth ed. 2000, Boston: Addison-Wesley. 189.

Appendix

Survey Questions

Users
1. How many users will be accessing the application?
2. How many different types of users will need to be in place ?
3. Have you determined what information each user group can/cannot access?
4. Will you need to support auditing (tracing users' security related actions)?
5. How do you determine the level of trust for users?
6. Will you require password authentication for users?
7. Will you enforce difficult to guess passwords (i.e. requiring both letters and numbers)?

Information
8. Are there related laws about the protection of this information?
9. Are there company policies about the protection of this information?
10. Should this information be stored securely? (ex. With encryption)
11. What level of encryption should be used?
12. Will you ensure data safety before encryption and after decryption as well?
13. How long will this information need to be protected?
14. Of what priority is the security of this information?
15. If the information is stored distributedly, will any of the users have a vested interest in accessing information from other users?
16. Do you allow anonymous entries into your database?

Threats
17. Will this application be accessible over a local network?
18. Will this application be accessible over the Internet?
19. Will this application be accessible by wireless devices?
20. Will the application potentially be liable to Denial of Service (DoS) attacks?
21. What language(s) will the application be written in?
22. Will the system be distributed?
23. Will security-critical information (i.e. passwords) be transferred between distributed components?
24. Do you keep the default security settings on your current system?
25. Do you modify the security settings to block unnecessary functionality (i.e. preventing access through FTP if the company doesn't need to use it)?

General
26. Have you considered fault tolerance in your specifications?
27. Have you considered scalability (The ability of a computer application to continue to function well as it (or its context) is changed in size or volume in order to meet a user need)?
28. Have you considered the load tolerance of each part of the system?
29. Have you planned for intrusion tolerance and response (tracking intruders once they have access)?
30. Does your requirements gathering specify what users may NOT do?
31. Does your requirements gathering specify your particular vulnerabilities?
32. Does your requirements gathering specify the consequences of the breach of vulnerabilities?
33. Does your requirements gathering prioritize these potential vulnerabilities?
34. Will you require a third-party security review of the system before going live?
35. Are you going to request that other "shrink-wrapped" software be used in the production of this application?
36. Have you ever been hacked?
37. Would you be willing to increase your budget to add security?
38. Is there a security engineer on your team?
39. Are there any other security-related concerns you feel need to be addressed?