1. What if you suspect a security incident or software vulnerability? What if you suspect a security incident at your site? DON’T PANIC Immediately inform: Your local site security team Your NGI Security Officer And the EGI CSIRT Team via e-mail to abuse@egi.eu Please give the following information in your initial report: Your name Your e-mail address Details of the incident If you do nothing else, and are really stuck, at least inform abuse@egi.eu – they will help you. This MUST be done within 4 hours of discovering an incident. The incident will then be handled by the EGI Incident Response Task Force (IRTF) of the EGI Computer Security Incident Response Team (CSIRT) Security incidents are normally found by site administrators, but may be discovered by others. It is important that they are handled efficiently in a timely manner to minimize damage and prevent them spreading across the Grid. Software vulnerabilities also need to be handled in a timely manner to help prevent incidents. What if you find a software vulnerability? DO NOT discuss on a mailing list - especially one with an open subscription policy or public archive DO NOT post information on a web page DO NOT publicise in any way, especially to the media IMMEDIATELY report it to report-vulnerability@egi.eu Talking about vulnerabilities openly exposes information that may be useful to an attacker Vulnerabilities reported are handled by the EGI Software Vulnerability Group (SVG) Security incident handling procedure When a security incident potentially affecting grid users, services or operations is suspected, the Incident handling procedure available from https://documents.egi.eu/secure/ShowDocument?docid=710 MUST be followed. Software Vulnerability issue handling procedure Software vulnerabilities are handled according to the EGI Software Vulnerability Issue handling procedure https://documents.egi.eu/secure/ShowDocument?docid=717 Most of the Issue handling is carried out by the SVG “Risk Assessment Team” or “RAT” Investigation The RAT, along with the reporter and software developers, establish whether the issue is real and what the potential effects of an exploit would be Risk Assessment A risk assessment is carried out by the RAT for all valid issues, where the issue is placed in 1 of 4 risk categories – Critical, High, Moderate, Low Target date for resolution set This is a fixed value for each risk category Critical – 3 days High – 6 weeks Moderate – 4 months Low – 1 year This allows the prioritization of fixing of issues, according to how serious they are. It is then up to the developers and software distributers to ensure the vulnerability is eliminated from the software available to the EGI infrastructure in time for the Target Date Advisory issued When the vulnerability is eliminated or on the target date – whichever is the sooner For more information on CSIRT activities please see the EGI CSIRT wiki https://wiki.egi.eu/wiki/EGI_CSIRT:Main_Page EGI SVG and EGI CSIRT teams for the EGI Community forum Manchester 8-12 th April 2013 For more information, including advisories already issued publicly and other SVG activities see the EGI SVG wiki https://wiki.egi.eu/wiki/SVG Site responsibilities after discovering an incident When a security incident potentially affecting grid users, services or operations is suspected, the following procedure MUST be followed: 1.Immediately inform your local security team, your NGI Security Officer and the EGI CSIRT via abuse@egi.eu This step MUST be completed within 4 hours after the suspected incident has been discovered. 2.Do NOT reboot or power off the host. In case no support is shortly available, whenever feasible and, if admitted by your local security procedure and if you are sufficiently familiar with the host/service to take responsibility for this action, try to contain the incident. For instance by unplugging all connections (network, storage, etc.) to the host. Please note down carefully what actions you take with a timestamp; that would be very important for later analysis as well as if the incident ends up in a legal case. This step SHOULD be completed as soon as possible, and MUST be completed within one working day after the suspected incident has been discovered. 3.Confirm the incident, with assistance from your local security team and the EGI CSIRT. 4.If applicable, announce downtime for the affected hosts in accordance with the EGI operational procedures with “Security operations in progress” as the reason. If applicable, this step MUST be completed within one working day after the suspected incident has been discovered. 5.Perform appropriate analysis and take necessary corrective actions. Logging information such as IP addresses, timestamps and identities involved etc., concerning the source of any suspicious successful connection, must meet the minimal requirements specified in Appendix A of the procedure. The objective is to understand the source and the cause of the incident, the affected credentials and services, and the possible implications for the infrastructure. Throughout step 5, requests from the EGI CSIRT MUST be followed-up within 4 hours. 6.Coordinate with your local security team and the EGI CSIRT to send an incident closure report within 1 month following the incident to all the sites via site-security-contacts@mailman.egi.eu, including lessons learnt and resolution. This report should be labelled AMBER or higher, according to the Traffic Light Protocolsite-security-contacts@mailman.egi.eu 7.Restore the service and, if needed, update the service documentation and procedures to prevent recurrence as necessary. Vulnerability reporters responsibilities 1.Those who find a vulnerability must not publicise information on a Vulnerability without the agreement of the SVG. It is important that vulnerabilities are kept private while they are being investigated and fixed. This includes not entering on a widely readable bug tracking system, discussing on a mailing list which is publicly archived or does not have strict membership criteria, or placing information on a web page. If information on a vulnerability has been distributed, then the reporter should make the SVG aware of this and if possible try and ensure the information is removed. 2.Report the Vulnerability. Anyone who finds a vulnerability should report it to the EGI SVG via report-vulnerability@egi.eureport-vulnerability@egi.eu 3.The reporter is invited to help with the investigation. While this is not mandatory, reporter’s help is much appreciated. 4.Reporter receives information. This includes the outcome and conclusion of the investigation, including the risk category and Target Date for resolution, and a copy of the advisory. For more information please contact Linda.Cornwall@stfc.ac.uk, egi-csirt-team@mailman.egi.eu, svg-rat@mailman.egi.euLinda.Cornwall@stfc.ac.ukegi-csirt-team@mailman.egi.eusvg-rat@mailman.egi.eu