Use third-party software

Security guidance for the use of non-commercial software

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?

Definitions:

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.

 

Open-source distributions and package managers

Open-source operating systems such as Linux typically come as part of a distribution including a wide variety of packaged open-source applications, tools and libraries. Distributions may be commercial (eg. Red Hat Enterprise Linux), through a volunteer community (eg. Debian), or incorporate elements of both.  There are also projects which package OSS for proprietary systems such as Windows and macOS.

Major distributions generally have strong, long-standing reputations.  Greater due diligence may be needed before considering one of the more niche systems, even if it is derived from one of the major ones.

If the required application is available through a major distribution, consider whether it’s feasible to use that rather than a standalone installation, bearing in mind the following:

Advantages:

  • Commitment to provide security support for a defined period of time
  • This may vary from a few months to ten years or more
  • Easy to monitor for updates
  • Simplified management of complex dependencies
  • Version stability – a given application version may be supported for many years

Disadvantages:

  • May be slow to incorporate new features
  • More specialist applications, tools or libraries may not be included
  • Proprietary freeware is generally not included, though there may be OSS equivalents
  • Smaller distributions may not have sufficient resources to issue timely updates

Other considerations:

  • Ensure the skills and resources are available to maintain the system
  • Track end-of-support dates, and plan upgrades well in advance
  • Understand what the distribution actually supports, for example:
    • Development branches often have limited or no support
    • Not all packages may receive the same level of support – for example those in Ubuntu main versus universe or multiverse
  • For critical applications, check how rapidly the distribution releases updates
  • While there is some oversight of a package prior to inclusion in a given distribution, it is no guarantee of secure software development