We put a lot of effort into protecting the Internet-facing attack surface. That is not enough. A vulnerability in any software running at any layer on a system may enable an attacker could gain access, obtain higher privileges, or access sensitive data. How can you be confident that all software achieves an acceptable level of security? When vulnerabilities are identified, will updates be available promptly, and how will you be notified of them?
For this document, it is important to define the terms used for different software licensing models.
- Open-source software (OSS, sometimes known as free or libre software): software licensed such that end-users have the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose. Often the software comes at no cost but not always – it may be sold with a support contract, or come as part of a bigger product. Examples include Mozilla Firefox, OpenSSL, PuTTY.
- Proprietary software: software for which the end-user is not granted some or all of the rights available with OSS. Often the source code is not made public. This category can be further divided:
- Freeware: proprietary software distributed at no monetary cost to the end-user, but which is not OSS. Examples include Adobe Reader, Foxit Reader.
- Commercial software: proprietary software distributed at a monetary cost to the end-user. Examples include Microsoft SQL Server, Adobe Photoshop.
While the boundaries between freeware and commercial software are often blurred by charging only after a trial period, to remove adverts, or for advanced features, within this document we consider the act of payment to establish the boundary.
Security vulnerabilities are everywhere
It is an unfortunate truth of the modern software industry that virtually all complex software will contain bugs. Some of these will have security implications, regardless of where the software comes from, or the terms under which it is licensed.
Whether the proprietary software model is any more or less secure than the alternatives has long been the subject of vigorous and often unproductive debate. Ultimately, that question is missing the point: any software could introduce a vulnerability into your systems. There are two main challenges: firstly, to identify software less likely to introduce serious vulnerabilities, and secondly, to obtain sufficient assurance that when almost inevitably, a weakness is identified, a fix will be available to you in a timely manner. The differences come in how one goes about doing this.
Vulnerabilities need not be in a specific application – they can be anywhere in the software stack on the system. That includes CPU microcode, device firmware, hypervisors, the operating system, libraries, utilities and applications, and any associated plugins or modules. OSS applications in particular may depend on a large number of software libraries from other authors, for example the cryptographic library OpenSSL.
Assurance of security
When the University buys IT services from a commercial supplier, there is typically an agreement placing certain obligations on the supplier to ensure security of the services. If the University obtains OSS under such an agreement there will usually be some level of assurance regarding the maintenance and security of the software. Where software is available free of charge, there may be no such obligation to maintain the code.
If you are considering using software that does not come under such a contractual agreement, you should address the following:
Distribution packages. On open-source platforms such as Linux, the software may well be packaged and supported as part of a major distribution. Consider whether it’s feasible to use that rather than a standalone installation – while not always suitable, it can make maintenance far easier. Further considerations when using an OSS distribution are given in Appendix A.
Due diligence. Choose tools and applications that are well maintained, with active and reliable developer communities. When you intend to use software in critical systems and for confidential information, use our checklist to assess its suitability.
Vulnerability management. Unless fully supported through a distribution, ensure that you monitor public and community vulnerability feeds and ensure updates and security patches are applied promptly. OSS vulnerabilities are not always well reported and so you should include developer fees in your monitoring.
Dependency management. Managing dependencies outside of a distribution can be challenging. Minimise and track dependencies and avoid code fragments and multiple code versions.
Treat OSS as code. Above all, treat OSS as code you have written. You are responsible for ensuring that the code is secure and that good secure development practices are in place, such as vulnerability scans and code reviews before deployment. If you rely on the developer community to do part of the job, ensure you have done appropriate due diligence using our checklist.