The debate if and how open source can affect the security of a product has been going on for a while. There are, theoretically speaking, three main points that can be made:

• Pro: The security of open source solutions is higher than that of closed solutions.
• Equivalent: The security of open and closed source projects is equal
• Contra: The security of open solutions is lower than that of closed solutions.

Generally, it can be said that all three assumptions can be correct. The statement is dependent on the standpoint and the properties of it, though. The statements can be summarized as follows:

• The security of open and closed solutions is equal: Theoretically, it is possible that a product – independent of its openness – can be developed with the same standards of security. The base quality of a solution is dependent on the quality of its execution and not its model. Just like there are insecure open source solutions, there are secure closed source solutions. The latter are harder to prove as evidenced in point #2.

• The security of open and closed source projects is the same: Transparency is a central aspect to develop trust and security. The openness of a product helps to achieve this goal. Therefore, it is possible for everyone with comparably little effort to determine the exact functionality and the security that comes with a solution. Due to this, errors can be discovered independently and more efficiently. Publishing these vulnerabilities helps to speed up the process of identifying and eliminating them. The quality of an open product can theoretically be increased much faster using this method when compared to the rise in quality of a closed project. The window for possible attacks is being minimized due to the number of people involved in quality analysis.

• The security of open source solutions is lower than that of closed source solutions: The openness of a solution can in turn encourage the motivation of a targeted hunt for vulnerabilities. Not informing the manufacturer or the public about these vulnerabilities can lead to a distinct advantage. By giving people insight into the functionality of a product, there needs to be less effort made to discover vulnerabilities. The immediate security of open systems is lower in the short- or mid-term-view of things, should undiscovered vulnerabilities remain.

Quota of Errors

Let’s assume that a system has a certain number of Total Vulnerabilities. This number can be greater or smaller than the Total Vulnerabilities Undiscovered. This number, in turn, can be greater than or equal to the number of Vulnerabilities Discovered. And this number can also be greater than or equal to the number of Vulnerabilities Public:

Total Vulnerabilities ≥ Vulnerabilities Undiscovered ≥ Vulnerabilities Discovered ≥ Vulnerabilities Public

The sequence of this comparison determines the danger emanating from a vulnerability. The more public a vulnerability is, the more likely it is to be mitigated. This is basically a good thing for both the manufacturer and the customer.

Some publications assume that the number of Vulnerabilities Discovered or Vulnerabilities Public is a direct indicator of the security of a system (and by that also a statement regarding Total Vulnerabilities). This is, as shown in the comparison, not necessarily the case. Only the data of the past could potentially _show a possible trend_.

A high number of publicized vulnerabilities in this case isn’t necessarily an indicator of the lacking quality of a product. They are also an indicator of the rise in security a product has, if the vulnerabilities are being fixed. Good examples of this are the Microsoft products IIS and Internet Explorer. Both solutions have been criticized over the years due to their high number of gaps in security and patches. The current statistical comparison (see also) with competing products shows that the level of security of these products is now above the average across the board. This proves that even the data of the past is not a certain indicator of security.

Model for High Security Environments

As evidenced above, open and closed source systems have distinct advantages. The question now arises which model should be preferred when it comes to high security environments.

A closed source solution can be recommended if a short-term advantage – and only a short-term advantage! – is to be met. If the solution can be tested by internal specialists, the solution can lead to head start (which can be assumed of the changes to DES by the NSA). The attackers will in the long run be able to catch up and transform the advantage of the closed source system into a disadvantage (as evidenced by the encryption called A5 used in GSM).

In the long run, open source systems should be preferred over closed source ones. By actively engaging in collaboration with a community – especially in combination with internal specialists -, vulnerabilities can be discovered and eliminated much quicker. The goal should be to, at some point and as quickly as possible, reach the state of a system that is as secure as possible and in which there are no highly critical and unknown weaknesses left.

About the Author

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

• http://blogs.securiteam.com/index.php/archives/1422
• http://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA.27s_involvement_in_the_design
• http://www.gfi.com/blog/top-15-vulnerable-applications/10/
• http://www.gfi.com/blog/top-vulnerable-applications-operating-systems-2010/
• http://www.heise.de/newsticker/meldung/26C3-GSM-Hacken-leicht-gemacht-892911.html
• http://www.suedmeyer.net/inhalte/pdf/a5_thesis.pdf
• https://vuldb.com/?id.statistiken
• https://www.computec.ch/news.php?item.257