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 to Please give the following information in your initial report: Your name Your address Details of the incident If you do nothing else, and are really stuck, at least inform – 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 Talking about vulnerabilities openly exposes information that may be useful to an attacker Vulnerabilities reported are handled by the EGI Software Vulnerability Group (SVG) Incident handling When a security incident potentially affecting grid users, services or operations is suspected, the Incident handling procedure available from MUST be followed. Software Vulnerability issue handling procedure Software vulnerabilities are handled according to the EGI Software Vulnerability Issue handling procedure 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 EGI SVG and EGI CSIRT teams for the EGI Community forum Manchester 8-12 th April 2013 The EGI Software vulnerability Group (SVG) The purpose of the European Grid Infrastructure (EGI) Software Vulnerability Group (SVG) is “To eliminate existing vulnerabilities from the deployed infrastructure, primarily from the Grid Middleware, prevent the introduction of new ones and prevent security incidents” This is carried out in 3 main ways: Handling potential vulnerability problems reported Checking software for vulnerabilities (Vulnerability Assessment) Educating developers to write secure code The largest activity is vulnerability handling, which is the handling of vulnerabilities found by anyone (often site administrators, CSIRT members, developers and security experts from various projects) and reported to SVG. For more information, including advisories already issued publicly and other SVG activities see the EGI SVG wiki 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 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 including lessons learnt and resolution. This report should be labelled AMBER or higher, according to the Traffic Light 7.Restore the service and, if needed, update the service documentation and procedures to prevent recurrence as necessary.