Open Source Security
It is often claimed that open source software is intrinsically more secure than closed source or proprietary software. Others argue that it is not, and it is expected this debate will continue for some time to come. The availability of source code provides both attackers and defenders opportunities to study code in detail and identify software vulnerabilities.
On the other hand, closed source software forces users to accept only the level of security diligence that the vendor chooses to provide. This paper discusses ways in which we can take advantage of the nature of open source software with regard to IT security. We also outline a number of best practices in open source software security that are recommended by the open source community, along with important points on using open source products safely within the organisation.
SOFTWARE SECURITY FOR OPEN SOURCE SYSTEMS
As discussed earlier, one characteristic of open source software is the public availability of source code, including potential criminals and attackers. Attackers are able to study source code and exploit vulnerabilities that may be due to programming flaws much more quickly. In addition, open source applications are usually developed jointly by volunteer contributions from groups and communities over the Internet. Attackers might also be able to contribute parts of the code to the software this way. Code level security usually depends on reviews conducted by those entrusted with maintaining the project or other contributors. However, it should be noted that closed source software could also suffer from similar problems if source code is leaked out to the public, such as the introduction of backdoors by disgruntled staff.
Efforts have been made by the open source community to improve software security and quality so as to mitigate vulnerabilities in applications and systems, including open source software. In general, open source software security is best achieved by following these best practices:
1.
Maintain an inventory of all software being used, including open source software. The software inventory should also document the version, the hash value (such as MD5 or SHA-1) for verification of the integrity of the source code, as well as the website where the software was originally downloaded.
2.
Check the availability of security updates and bug fixes for open source software regularly so that patch management processes can be followed regularly to minimise any loopholes in the selected open source software.
3.
Change all default security settings in open source software as soon as it is installed. Configure the product in the most secure way possible by disabling unwanted services.
4.
Test and scan the source code with code analysers or auditing tools, such as BOON (Buffer Overrun detection) , FlawFinder , RATS (Rough Auditing Tool for Security) , and so on. Developers may also want to run compiler-integrated tools, such as ProPolice (or Stack-Smashing Protector, or SSP) from IBM , which automatically insert protection codes into source code that protect compiled programs.
5.
Ensure that the open source application fully complies with existing network architecture if the application requires the opening of any firewall ports. This avoids any violation of the organisation’s firewall and security policy when a new application is introduced.
HOW TO USE OPEN SOURCE PRODUCTS SAFELY IN THE ORGANISATION
To use open source products safely, organisations must consider the following:
1.
Set up a well-documented security policy and ensure the policy is strictly adhered to. This policy should be revised, as business needs change.
2.
Download open source products only from trusted sites, such as the official website of the software developer(s), to avoid potential risks from pre-inserted malicious code.
3.
Download source code rather than a compiled package. In this way, source code can be verified against the MD5 / SHA-1 checksums provided, analysed for security vulnerabilities and compiled for the organisation’s specific needs.
4.
Study the product’s documentation carefully for any explanation of the secure configuration parameters.
5.
Check whether there is a reporting procedure should a vulnerability be discovered in the product, and ensure all security issues around the product are well maintained and addressed.
6.
Check regularly on common security vulnerability databases, such as CVE (Common Vulnerabilities and Exposures) , for published information on any security vulnerabilities pertaining to the open source product(s) being used.
7.
Adopt a “Defence-in-Depth” strategy so that various threats at various levels right from the open source product to the network can be fully addressed.
8.
Provide appropriate training to in-house staff for the support and maintenance of open source products. Put together proper documentation for all the practices and configurations required in order to avoid problems that might arise due to job rotations or employment termination.
