 |
| Open Source and Free Software Wars: Source dwheeler.com |
Just finished speaking at the Security Day hosted by the Sardegna(Italy) Research Park where I was invited to present on the topic of Open source projects for Web Application Security and moderate a round table on security of FOSS (Free Open Source Software) vs. COTS (Commercial Off The Shelf) with participating managers from Microsoft, IBM ISS and consultants from Engineering and Ablativ consulting.
The following themes were stimulated during the round table:
1) Did FOSS adoption in EU (since 2004 directive) [1] resulted in a more secure environment because of the diversity of the systems/platforms being used by organizations/companies?
Answer: a diversity of mechanism helps security on the other hand managing different platforms and systems is very difficult. A uniformity of platforms actually helps a more secure configuration and management effort (i.e. patching). The main objective is not to establish an eterpgenoues environment rather to establish a secure environment/infrastructure as a whole such as have a patch management process in place for all type of systems and applications being used.
2) Some COTS advocate that their systems are more secured because are closed (e.g. source code is not made available). Security experts advocate the contrary because security by obscurity does not buy security (e.g. Kirckoff's second law principle)and therefore is not a good reason for keeping systems close [2].
Answer: We need a security assessment process to validate the security of any software that is acquired/integrated with either from OSS community or COTS vendors. Access to the source code should be a requirement so can be assessed for vulnerabilities before adoption/release. Keeping the software closed (security by obscurity) is not a good reason for security.
3) According to a study [3] from a source code analysis tool vendor (e.g. Fortify) FOSS is not as secure as COTS because most FOSS produced lack secure software reviews. Is this a call for vendors and companies to source code analyze FOSS before adoption/integration?
Answer: We need a process to security validate with source code analysis that libraries and systems we use/integrate independently being from FOSS or COTS. Some customers of IBM asked for a OWASP secure code certification as a way to provide evidence that the software has been security reviewed. A certification could also provide legal guarantees to FOSS and COTS users. Ideally this certification could be required by compliance with a new normative/regulation on software assurance.
4) Time to patch is critical for the security of both FOSS and COTS [4]. For example, there have been cases where Mozilla was recommended over IE by CERT (2004) based upon the fact that took Microsoft 9 months to patch it. The same happened to FOSS [5]: for example, it took more then one year to Debian to discover and patch OpenSSL. The point here is: who takes liability of un-patched vulnerabilities and how software adopters/integrators could enforce FOSS and COTS to develop patches in very short time.
Answer: Ideally you need to establish a process and work with the software vendors/communties to develop patches before the zero day vulnerabilities are disclosed. This is what Microsoft is doing with MSVR program for example. The time to release a patch is important factor but some data (e.g. IBM) shows that actually system admins still leave most systems unpatched even if patches have been available for a while. Therefore timely patch management seems still to be a bigger problem to address then timely release of patches for zero day vulnerabilities.
5) OSS is free but it is not free from maintenance cost [6]: fixing vulnerabilities via a catch and patch approach is very expensive for both software developers and adopters. Usually the cost to develop patches is a responsibility of who develop software and both FOSS and COTS would rather continue to transfer this cost to the end user instead of bearing is themselves. The fact is that would be much cheaper for FOSS and COTS software developers fixing their software bugs during the development cycle instead of during production.
Answer: Indeed we need a process to require vendors and communities developing software to fix software vulnerabilities before going into production. The cost associated with developing patches can be a good reason for promoting
secure software development in the SDLC among FOSS and COTS. In the case of COTS, Microsoft proved that an increased security (e.g. reduced number of bulletins) has an impact on costs: assuming an average cost of bulletin is 100,000 $ by comparing Windows 2003 server with Windows 2000 the reduced number of bulletins is a strong argument of adopting a SDL (Security Development LifeCycle.)
The conference was very well organized and the location was just wonderful place to visit, hope to come back on vacation during the summer.
References:
[3] Fortify: Rising Enterprise Adoption of Open Source Software is Putting Businesses At Greater Risk
Posts
1 comment:
From enterprise practices, it's not cost-saving to use OSS compared against COTS, unless your HR cost could be controlled very well.
=Richard=
http://sbin.cn/blog
Post a Comment