Future Forecast of Secure Software Development

Li Wen


 

Introduction:
If you were a frequent visitor of cert.org or bugtraq mailing list, you would not be surprised to come across software vulnerability reports several times a day. You can't help asking why there are so many bugs? Can't software be bug-free before they are released? This paper is an attempt to find out what factors have caused software bugs, what are the present ways of dealing with them, what are the challenges and what would be the future for secure software development.


The importance of secure software has never been so keenly felt when computer software based transactions have reached almost every aspects of our life. While we are receiving packages, we sign electronically. While we are buying groceries, groceries are weighted and calculated automatically. While we make a phone call, the telephone switch directs your call to the destination. Not to mention the ultimate triumph of computer age---Internet. A recent report from Nielsen//NetRatings indicated that of the 6 billion people on the planet, nearly 500 million now have Internet. With the development of technologies, getting on line has never been so easy. With the increasing CPU power and decreasing price, PCs have come a commodity in our life. In the near past, we used to dial up to the Internet, tolerating the slow connection and transmission. Today, high-speed Internet access technologies, such as cable modem, DSL, fast Ethernet allow our computers to be hooked on the Internet 24 hours a day, at a speed that is more than ten times as before. While we are enjoying the convenience, to our surprise malicious codes are also enjoying the same convenience. A vulnerability, once in the hands of malicious people, can be spread quicker than ever, and can be used against more computers than ever. The wide spread of "Love" bug is just one example of how a virus can leverage the insecurely designed Outlook address book to affect computers globally.


Background Information-What is software bugs and how are they created:

Definition of Software Bug:

According to opera.com, a software bug may be defined as a coding error that causes an unexpected defect, fault, flaw, or imperfection in a computer program. In other words, if a software does not perform as the developers intended, it is most likely a bug. The origin of the word "bug" has wrongly been associated with an incident where a moth was pulled out of a Mark II computer. Apparently, the term was used prior to modern computers to mean an industrial or electrical defect.

What Caused Bug:
The above definition of software bug gives us an impression that bugs are human error-some developer made a mistake, therefore as long as the developer is careful enough, bugs should be eliminated. However the persistence and abundance of bugs today proves that eliminating bugs is not an easy task to an extent that it is virtually impossible to be bug free. There are several factors that are influencing the software industry.

Complexity
Bruce Schneier (2000) claimed that "The future of digital systems is complexity, and complexity is the worst enemy of security". Today's software is very complicated, and it is very likely that tomorrow's software will be more complicated. Take Windows for an example. When Windows 3.1 was released in 1992, it had 3 million lines of code. When Windows 2000 was released in 1999, it had between 35 million and 60 million lines of code. When a program is designed with such complexity, there can be thousands of ways different modules will interact with each other. Sometimes one module alone may behave properly, but after integrated with other modules, bugs can occur. It is simply beyond a one individual's ability to comprehend every aspects of a large program and predict every result of interaction.

Extensible System
Today's software systems are designed with the idea of extensibility in mind, such as Java Virtual Machine in a Web browser, or the .Net virtual machine, or the J2ME micro VM built into phones and PDAs. By extensibility, it allows future codes to be integrated in the system, such as plug-ins in web browser. Extensibility is good, since it enhances and extends the functionality of a system, but at the same time it can easily introduces bugs as well. It is almost impossible for a developer to envision all the interactions between future codes and the current system, and there is simply no way to test for the future.

Economics
The current buggy state of software development can also be explained by microeconomics, as argued by Ross Anderson (2001). The current market needs more functionality and efficiency than security. Even programmers using C tend to err on "buffer flow", but "C for efficiency" is still an adequate reason for choosing C over Java. All vendors are trying to be the First in a market where the first gets all. That is how Microsoft has succeeded. Consumer's concern for security also depends on how much damage the attack is going to have on him/her not the entire network. That is why denial of service can always succeed. While a computer owner may have enough incentive to buy a firewall to protect his/her computer, there is much less incentive for the owner to spend even $ 1 on software to prevent his/her machines being used to attack other website using denial of service.

Current Way of Dealing with Bugs:

Penetrate and Patch
The dominance method of dealing with bugs is the so-called "Penetrate and Patch". Most software vendors didn't pay much attention to security before it is released. It is only after software is broken when they hurriedly come up with a "fix" to patch the hole. As indicated by John Viega and Gary McGraw (2001), there are several problems with penetrate and patch approach:
1. According to a study by Bill Arbaugh, Bill Fithen and John McHugh (2000), the life cycle of a bug doesn't end with a patch. Intrusion continues after a patch is released and may last several years before a bug dies out.
2. Part of the reason for administrators' reluctance to apply patches is that patches are rushed out as a result of market pressures on vendors and often introduce new problems of their own to a system
3. And system administrators tend to be overworked and often don't want to make changes to a system that "works"
4. Finally developers can only patch problems that they know about. Attackers may find problems that they never report to developers

Open Source vs. Proprietary
Another trend to develop safer software is to go the "Open Source Software" approach. In summary, OSS/FS programs are programs whose licenses permit users the freedom to run the program for any purpose, to modify the program, and to redistribute the original or modified program (without requiring payment to someone else or restricting who the program can be given to) (Wheeler).
The flagship example of open source movement should go to the development of Java programming language. After Sun opened the Java source code, security researchers around world have put much effort in discovering vulnerabilities, including very serious system bugs. It is a revolution in the software industry, and many people claimed Java as much securer than both C and C++. (Viega, 2001; McGraw, 1997).
However Open Source is not panacea for getting rid of bugs. There are several reasons (Viega, 2000; Obasanjo, 2002):
1. Many eye balls does not automatically guarantee that the code has been reviewed by competent parties
2. Most people only look at the parts of the code that they want to modify
3. The sheer complexity of a program makes comprehensive audit a mission impossible
4. Doing security reviews of source code is complex and boring. Even the experts can miss things.

Others
There are other measures software vendors use to tackle software bugs, including formal methods using mathematical algorithms, code audits, testing, design reviews and codified best practice. (Obasanjo, D. 2002) However most of them are still at the beginning stage. Take automated testing as an example. The current tools are "expensive, clumsy and missed a lot of problems" (Hapgood, 2001).

The Future of Secure Software Development:
It is relatively safe to predict that vendors and developers are going to pay more attention on software security during the development stage. Ideally there can be breakthroughs on smart source code analyzers (Holzmann, 2000). These analyzers can be embedded into standard program development environments, and they can work without the programmer being aware of it. These analyzer demons will be able to warn the programmer virtually instantaneously when subtle bugs get introduced into the code.

We are going to see more and more open source software. Despite of the fact that many "eye balls" don't always see the whole picture, there are sufficient examples that many dangerous holes of open source software are discovered by people around the world, some are security researchers, and some are security aware developers. Furthermore, by opening source code, software developers and researchers can learn from the source code and learn from each other, thus leading to better development practices.

The future software market is also more security-aware. Government agencies and software vendors are going to put more effort and investment in educating consumers of the importance of software security and software updates, and develop easier channels for communicating with end users when there is any security vulnerabilities or when a patch for a hole is available. After all, the wide spread intrusion after a patch is released is due to the fact that people either don't know or don't pay much attention to security. This is a win-win game. Only after consumers value more on efforts that are trying to make software more secure than on functionalities can there be more incentives for vendors to focus more on security.

In one word, producing secure software is a task that involves not only vendors and developer, but also users and government agencies. We are going to see more and more attention on software security in all sectors. After all, security-aware market goes hand-in-hand with secure software development.


References:
[Anderson, 2001] Ross Anderson (2001) Why Information Security is Hard--An Economic Perspective. http://www.acsac.org/2001/papers/110.pdf

[Arbaugh, 2000] Bill Arbaugh, Bill Fithen and John McHugh. Windows of Vulnerability: A Case Study Analysis. IEEE Computer. 30(10), 2000

[Hapgood, 2001] Fred Hapgood. Bug Battles-As Software gets more complex, automated testing becomes key. http://www.cio.com/archive/080101/et_revisit_content.html

[Holzmann, 2000] Gerard J. Holzmann (2000) The Future of Software: the reliability of interaction. http://cm.bell-labs.com/cm/cs/who/gerard/future00.html

[McGraw, 1997] Gary McGraw & Edward Felten. Java security--Hostile applets, holes, and antidotes : what every Netscape and Internet user needs to know. New York : Wiley, c1997

[Obasanjo, 2002] Dare Obasanjo. The Myth of Open Source Security Revisited http://softwaredev.earthweb.com/sdopen/article/0,,12077_983621,00.html

[Obasanjo, D. 2002] Dare Obasanjo. The Myth of Open Source Security Revisited v2.0. http://softwaredev.earthweb.com/sdopen/article/0,,12077_990711,00.html

[Schneier, 2000] Bruce Schneier (2000) Software Complexity and Security. http://www.counterpane.com/crypto-gram-0003.html#SoftwareComplexityandSecurity

[Viega, 2000] John Viega. The Myth of Open Source Security. http://softwaredev.earthweb.com/sdopen/article/0,,12077_626641,00.html

[Viega, 2001] John Viega and Gary McGraw (2001). Building Secure Software: How to Avoid Security Problems the Right Way. Addison-Wesley Professional Computing, 2001, New York

[Wheeler] David A. Wheeler. Open Source Software / Free Software (OSS/FS) References. http://www.dwheeler.com/oss_fs_refs.html


Home

INLS187