EGI CSIRT Information Disclosure Policy (draft)
The principle of the disclosure policy is to maximize the security of the EGI infrastructure, and not to release information that compromises the security of other systems.
Note that CSIRT has a 'traffic light' system for information distribution EGI_CSIRT:TLP
The EGI Software vulnerability issue handling process is available from
and has been approved by the EGI PMB and OMB.
For information learnt as a result of membership of the CSIRT team, CSIRT members MUST adhere to this policy.
For information on vulnerabilities in software found in the EGI UMD and the IGE, or any other software covered by a Service Level Agreement between software providers and EGI, CSIRT members MUST adhere to this policy.
For other information CSIRT strongly requests that members of the CSIRT team adhere to this policy, unless there is a good reason not to.
If a CSIRT member finds a vulnerability
If a member of the CSIRT team find a vulnerability, it should be reported to the appropriate software provider via an established mechanism for that software.
For vulnerabilities in the EGI UMD and the IGE or other software subject to an SLA between EGI and the software provider, vulnerabilities must be reported by e-mail to report-vulnerability (at) egi.eu.
Other vulnerabilities may be reported by this mechanism.
The CSIRT team will not publically disclose information on vulnerabilities that is not already public, when no available software updates are available to resolve the vulnerability.
- The existence of vulnerabilities, with the exception below in the absence of response from software providers.
- Any exploit that a CSIRT member has written or become aware of. This includes exploits which are not already public even if the existence of a vulnerability is public.
- Information or technical details that may help an attacker exploit the vulnerability or write an exploit.
If CSIRT needs to warn sites of the existence of a vulnerability that is not public, or provide information to sites which is not public, then the information must be sent by e-mail using the 'Traffic light protocol', usually amber or green. This includes technical details of any recommended mitigating action which may expose information useful to an attacker. Such information will of course not be posted on a publicly readable web page by CSIRT.
Disclosure in absence of adequate response from software provider
If a CSIRT member reports a vulnerability, the software provider should have some time to resolve the problem. For vulnerabilities in middleware distributed by the EGI UMD and the IGE, or any other software covered by a Service Level Agreement between software providers and EGI, vulnerabilities MUST be reported by CSIRT members by this mechanism and they MUST not disclose information. This process includes a responsible disclosure policy, which discloses vulnerabilities on a target date according to risk.
In the case where there is a vulnerability in other software such as an operating system, then the preferred method of handling is jointly with the Software Vulnerability Group to follow the vulnerability issue handling process. If there is no feedback from the software provider, then the existence of the vulnerability may be disclosed but any exploit written and/or information that allows an attacker to write an exploit should be excluded. Similar principles to the EGI Software Vulnerability issue handling process should apply.
After updates are available
Usually, when updates are available, the existence of the vulnerability will be made public by the provider of the software. Such public information may then be re-distributed by CSIRT. However, further technical details which are not public and may help an attacker will not be made public by the CSIRT team, until at least 6 months after the vulnerability has been resolved to ensure all users of the software (not just in EGI) have had ample time to update their systems.