Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "SVG:Software Security Checklist"

From EGIWiki
Jump to navigation Jump to search
Line 2: Line 2:


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.  
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.
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, and it will additionally be placed on the wiki.  


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.  
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.  
Line 8: Line 8:
== Who is the Technology Provider? ==
== 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.  
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 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
The large Linux distributors usually redistribute software which others have provided, but the distributions themselves typically have 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.
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.
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.
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? ==
== Has anyone with security expertise done an assessment of it? ==
Line 17: Line 18:
If an assessment has been carried out by people with security expertise consider their findings.  
If an assessment has been carried out by people with security expertise consider their findings.  


== Does the code look good? ==
== Does the code look professional? ==


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 maintainableWould you feel happy to maintain it if it was part of your job?
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 professionalIs 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 organized way.
 
For more information, see  [https://www.mir-swamp.org/ Information from SWAMP project]  SVG has some additional references for  [[SVG:Secure_Coding | Secure Coding ]]


== Is user input sanitized? ==
== 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.  
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 contain 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? ==  
== 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.
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.
 
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 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 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 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.  
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.  
How long will the software be under security support?  
 
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.  
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.  
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? ==
== 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.  
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? ==


== How are software vulnerabilities handled? ==
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. 


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.
== What are the configuration issues related to security? ==


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.
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.  


== What are the configuration issues related to security? ==
== Does usage of the software comply with the EGI policy on the processing of personal data? ==


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.
It is important that all activities comply with  [https://documents.egi.eu/document/2732 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.

Revision as of 13:04, 25 August 2017

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 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, and it will additionally be placed on the wiki.

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, but 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 organized way.

For more information, see Information from SWAMP project SVG has some additional references for Secure Coding

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 contain constructs which may be exploited if user input is not sanitized.

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 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. 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.