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 "EGI CSIRT Information Disclosure Policy (draft)"

From EGIWiki
Jump to navigation Jump to search
(Created page with '{{Egi-csirt-header}} The principle of the disclosure policy is to maximize the security of the EGI infrastructure, and not to release information that compromises the security…')
 
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{Egi-csirt-header}}
{{Egi-csirt-header}}


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.
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 *https://wiki.egi.eu/wiki/EGI_CSIRT:TLP*
Note that CSIRT has a 'traffic light' system for information distribution [[EGI_CSIRT:TLP]]


The EGI Software vulnerability issue handling process is available from
The EGI Software vulnerability issue handling process is available from
https://documents.egi.eu/public/ShowDocument?docid=47 and has been approved by the EGI PMB and OMB.  
* [https://documents.egi.eu/document/47 Operational Security Procedures ]
 
and has been approved by the EGI PMB and OMB.  


== CSIRT Members ==
== CSIRT Members ==
Line 19: Line 17:
For other information CSIRT strongly requests that members of the CSIRT team adhere to this policy, unless there is a good reason not to.   
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 member finds a vulnerability ==
== 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.
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.
Line 38: Line 36:


* Information or technical details that may help an attacker exploit the vulnerability or write an exploit.
* Information or technical details that may help an attacker exploit the vulnerability or write an exploit.
== Limited disclosure ==
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.

Latest revision as of 17:14, 29 November 2012


| Mission | Members | Contacts
| Incident handling | Alerts | Monitoring | Security challenges | Procedures | Dissemination



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.

CSIRT Members

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.

Non-disclosure

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.

This includes:

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

Limited disclosure

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.