Open-source software security
Definition
Open Source Software Security is the measure of assurance or guarantee in the freedom from danger, risk, etc in an open source software system.
The Debate
There is an ongoing debate on whether open source software increases software security or is detrimental to its security. There are a variety of different benefits and drawbacks for both sides of the argument. There are also a variety of metrics and models to measure the effectiveness of the security.
Benefits of Open Source Security
- More eyes on the source code mean more eyes that can discover a possible vulnerability.
- Closed source software forces the user to accept the level of security that the software vendor is willing to deliver and to accept the rate that patches and updates are released[1].
- It is assumed that any complier that you would use creates code you can trust, but it has been demonstrated by Ken Thompson that a complier can be subverted to create faulty executables that are unwittingly produced by a well-intentioned developer[2]. With access to the open source code for the compiler, the developer has at least the ability to discover if there is any mal-intention.
- Kerckhoffs’ principle is based on the idea that an enemy can steal a secure military system and not be able to compromise the information. His ideas were the basis for many modern security practices, and followed that security through obscurity is a bad practice[3].
- The cost of the software.
Drawbacks of Open Source Security
- If you have access to a given piece of source code then so does a potential attacker[2]. Any vulnerability that hasn’t been discovered yet, a potential attacker could take advantage of.
- Just because a project is open source doesn’t mean that it will be reviewed. Imagine the instance of an open source software project that was written by a couple key people and has millions of lines of code along with many years of effort invested into it. Although the potential for discovering a bug or some kind of back door by many eyes is there, if there is not a large community supporting this project, it may lack the proper review to discover it. A good example of a similar scenario is by Marcus Ranum, an expert on security system design and implementation, and his first public firewall toolkit. At one point in time, there were over 2,000 sites using his toolkit, but only 10 people gave him any feedback or patches[4].
- Having a large amount of eyes reviewing code can lull user into a false sense of security[5]. Just because a considerable number of reviewers are looking at the code behind a project does not guarantee that every potential security flaw will be fixed.
- In open source software, there is the potential for the inability to control the construction process[6]. In closed source software, there are controls in place for hiring practices. Potential employees are interviewed, and there is a selection process on who is going to be part of the work force. There is some sort of manager in charge of the project driving the construction process. In open source software, there are not always these controls in place, and any mal-intent could be inserted into a project easier with no consequences.
Metrics and Models
There are a variety of models and metrics to measure the security of a system. These are a few methods that can be used to measure the security between open and closed source software systems.
Number of days between vulnerabilities
It is argued that a system is most vulnerable after a potential vulnerability is discovered, but before a patch is created. By measuring the number of days between the vulnerability and when the vulnerability is fixed, a basis can be determined on the security of the system. There are a few caveats to such an approach such as not every vulnerability is equally bad, fixing a lot of bugs quickly might not be better than only finding a few and taking a little bit longer to fix them, taking into account the operating system, or the effectiveness of the fix[2].
Poisson process
The Poisson process can be used to measure the rates at which different people find security flaws between open and closed source software. The process can be broken down by the number of volunteers Nv and paid reviewers Np. The rates at which volunteers find a flaw is measured by λv and the rate that paid reviewers find a flaw is measured by λp. The expected time that a volunteer group is expected to find a flaw is 1/(Nv λv) and the expected time that a paid group is expected to find a flaw is 1/(Np λp)[2].
Morningstar model
By comparing a large variety of open source and closed source projects a star system could be used to analyze the security of the project similar to how Morningstar rates mutual funds. With a large enough data set, statistics could be used to measure the overall effectiveness of one group over the other. An example of such as system is as follows[7]:
- 1 Star: Many security vulnerabilities.
- 2 Stars: Reliability issues.
- 3 Stars: Follows best security practices.
- 4 Stars: Documented secure development process.
- 5 Stars: Passed independent security review.
Baselines for Open Source Security
Coverity Scan
Coverity in collaboration with Stanford University has established a new baseline for open source quality and security. The development is being completed through a contract with the Department of Homeland Security. They are utilizing innovations in automated defect detection to identify critical types of bugs found in software[8]. The level of quality and security is measured in rungs. Rungs do not have a definitive meaning, and can change as Coverity releases new tools. Rungs are based on the progress of fixing issues found by the Coverity Analysis results and the degree of collaboration with Coverity[9]. They start with Rung 0 and currently go up to Rung 2.
- Rung 0 The project has been analyzed by Coverity’s Scan infrastructure, but no representatives from the open source software have come foreward for the results[9].
- Rung 1 At rung 1, there is collaboration between Coverity and the development team. The software is analyzed with a subset of the scanning features to prevent the development team from being overwhelmed[9].
- Rung 2 There are 11 projects that have been analyzed and upgraded to the status of Rung 2 by reaching zero defects in the first year of the scan. These projects include: AMANDA, ntp, OpenPAM, OpenVPN, Overdose, Perl, PHP, Postfix, Python, Samba, and tcl[9].
References
- ^ Cowan, C. (2003, January). IEEE Security & Privacy. IEEE Security & Privacy , 38-45. Retrieved May 5, 2008, from IEEE Computer Society Digital Library.
- ^ a b c d Witten, B., Landwehr, C., & Caloyannides, M. (2001, September/October). Does Open Source Improve System Security? IEEE Software , 57-61. Retrieved May 5, 2008, from Computer Database.
- ^ Hoepman, J.-H., & Jacobs, B. (2007). Increased Security Through Open Source. Communications of the ACM , 50 (1), 79-83. Retrieved May 5, 2008, from ACM Digital Library.
- ^ Lawton, G. (2002, March). Open Source Security: Opportunity or Oxymoron? Computer , 18-21. Retrieved May 5, 2008, from IEEE Computer Society Digital Library.
- ^ Hansen, M., Köhntopp, K., & Pfitzmann, A. (2002). The Open Source approach - opportunities and limitations with respect to security and privacy. Computers & Security , 21 (5), 461-471. Retrieved May 5, 2008, from Computer Database.
- ^ Schneider, F. B. (2000, May). Open Source in Security: Visiting the Bizarre. 2000 IEEE Symposium on Security and Privacy (S&P 2000) , 126. Retrieved May 5, 2008, from IEEE Computer Society Digital Library.
- ^ Peterson, G. (2008, May 06). Stalking the right software security metric. Retrieved May 18, 2008, from Raindrop: http://1raindrop.typepad.com/1_raindrop/security_metrics/index.html
- ^ Coverity. (n.d.). Accelerating Open Source Quality. Retrieved May 18, 2008, from Scan.Coverity.com: http://scan.coverity.com/index.html
- ^ a b c d Coverity. (n.d.). Scan Ladder FAQ. Retrieved May 18, 2008, from Scan.Coverity.com: http://scan.coverity.com/ladder.html