Software Security Checklist

People often develop or select software because it does something useful, which they wish to do. The motivation is to get things working, do something useful, and security is often not considered. Anyone who develops, selects or deploys software which is used on the EGI infrastructure, or think that certain software may have an impact on the EGI infrastructure, needs to consider security. We will maintain this simple checklist to help.

While this checklist does not guarantee security, and is not a security assessment of the software, thinking about these issues will help flag up whether serious problems with the software are likely.

Who is the Technology Provider?

If the Software Provider is an organisation or company, with a record for providing reliable, secure software, then this is a good indicator that the software can be considered for use. The large Linux distributors usually redistribute software which others have provided, and the distributions themselves typically have vulnerability handling procedures and strategies which can be relied on. If the software provider is a group of people we know well, with a track record of producing reliable secure software and the programmers have the necessary skills and are co-operating with the project to provide software suitable for use, then this is also a good indicator that the software can be considered for use. If the software comes from a reliable software provider, then the sections below will need less consideration. If the software comes from unknown, small companies or ‘hobby’ programmers, then the sections below need to be considered very carefully.

Has anyone with security expertise done an assessment of it?

If an assessment has been carried out by people with security expertise consider their findings.

Does the code look professional

If the software has not been produced by a reliable company or organisation then take a look at it. Does it look good, clear, and professional? Is the code well documented, does it explain clearly what it is doing? Does it compile cleanly, without warnings? Is it the code flow easy to understand? For the more experienced, are there any security issues such as ignoring errors and return codes? None of these are any guarantee that the software is secure, but indicate that some time has been spent on putting it together in an organised way.

For more information, SVG has some additional references for Secure Coding

Is user input sanitised?

Some of the commonest types of software vulnerability come from the failure to sanitise user input. These include buffer overflow vulnerabilities and SQL injection vulnerabilities. It is not sufficient to trust a client supplied by a software provider. New malicious clients may be developed. This is particularly important if the programming language used and the software itself contain constructs which may be exploited if user input is not sanitised.

Is the software under security support

If the infrastructure depends on some software it is important that it is under security support. Consider the type of security support – if it’s a reliable company, then it is likely to be adequate. If the programmers are from a collaborating project and are funded to continue to develop and maintain this software then it is also likely to be fine. If the software is provided by a small company, which you know little about then look carefully at how well it is likely to be supported. If the software support is no longer funded but there is some party committed to providing updates for at least a year or so, (this should be captured in the form of a MoU), then one can rely on this. If it is not supported, or relies on someone maintaining it as a hobby then think again about whether security support is adequate. How long will the software be under security support? It may be that a large company or organisation commits to supporting the software for a number of years into the future. If so, then this is good. Otherwise, think about how long support is likely to be available. Have you considered what would be the impact if the software were no longer to be supported in the future?

When was the last stable release?

If the last stable release was several years ago, it is probably an indication that support may actually be limited and cannot be relied upon.

How are software vulnerabilities reported?

It is essential that a new vulnerability can be reported to the software provider, without generating a publicly readable ticket or other publicly available information.

What are the configuration issues related to security?

Ensure that the software can be configured securely in the circumstances in which you wish to use it. Ideally, the default configuration should be secure. If not, e.g. if there is a default password, ensure that you understand how to configure it securely and if you are suggesting to others that they use this software, include instructions on what needs to be done to configure it securely.

Does usage of the software comply with the EGI policy on the processing of personal data?

It is important that all activities comply with The EGI Policy on the processing of personal data This policy aims to ensure that data collected as a result of the use of the Infrastructure is processed fairly and lawfully by Infrastructure participants. Some of this data, for example that relating to user registration, monitoring and accounting contains “personal data” as defined by the European Union (EU). The collection and processing of personal data is subject to restrictions aimed at protecting the privacy of individuals. It must be possible to configure the software such that it complies with this policy.

Does the software provider have a mailing list you can subscribe to?

Many software providers have one or more mailing lists which you can subscribe to in order to receive updates on the software, including information on security advisories. Having such a list is an indicator of good practise. If there is such a list, ensure you have subscribed to this list.