SVG:Software Security Checklist

Main page

Software Security Checklist

Issue Handling

Advisories

Notes On Risk

Advisory Template

More

---

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 is developing software, or selecting or deploying software on the EGI infrastructure, or which may have an impact on the EGI infrastructure needs to consider security. We will maintain this simple checklist to help. This should apply to anyone selecting or writing software for use on the infrastructure, whether resource providers, VOs, or those selecting or writing software for the enabling of the sharing of computing resources in EGI, or software included in Virtual Machines.

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 Technology Provider (TP) is a large organisation or company, with a good record for providing good, reliable, secure software then this is good. The large linux distributions usually redistribute software which others have provided, but the distributions themselves typically have good vulnerability handling procedures and strategies which can be relied on If the technology provider is a group of people we know well, with a good track record of producing reliable secure software and the programmers have good skills and are co-operating with the project to provide software suitable for use then this is good indicator that the software is should be considered for use. In the case of unknown, small companies, ‘hobby’ programmers, and other software which you may come across and think ‘this is useful’ think carefully and be extra vigilant in the sections below.

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 good?

If the software has not been produced by a large reliable company or organisation then take a look at it. See if it looks good, clear, and maintainable? Would you feel happy to maintain it if it was part of your job?

Is user input sanitized?

Some of the commonest types of software vulnerability come from the failure to sanitize 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 contains constructs which may be exploited if user input is not sanitized.

Can you ensure that using this software complies with EGI Data protection policy?

The EGI data protection policy is currently being developed. It is essential to comply with data protection legislation. As a bare minimum it must not be possible to link an action to an individual user, and make this information widely available.

Is the software under security support?

If the infrastructure depends on some software it is important that it is under security support, so that any vulnerability found can get fixed. If a security problem is found and it can't be fixed there's a fair chance that people will be told to stop using it on the EGI infrastructure.

Consider the type of security support – if it’s a large reliable company then it’s likely to be fine.

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’s likely to be supported.

If the software support is no longer funded but the institute providing it is willing to support it and their programmers maintain it during work time then it is likely it will be O.K.

If it’s not supported, or relies on someone maintaining it as a hobby then think again about whether security support or for that matter other support is adequate.

How long will the software be under security support?

It may be that a large company or organization 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.

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 handled?

It is essential that a new vulnerability can be reported to the technology provider, without generating a publicly readable ticket or other publicly available information. That this can be done and how should be checked.

For a large company or organization the creation of a ticket which is not public, or a security e-mail address may be provided. For a smaller organisation, or collaborating project, directly e-mailing the developers may be the means of reporting vulnerabilities.

What are the configuration issues related to security?

Check the configuration issues related to security, and ensure that the software can be configured securely in the circumstances in which you wish to use it and that it complies with the EGI data protection policy.