1. The Grid Security Vulnerability Group (GSVG) Enabling Grids for E-sciencE EGEE-III INFSO-RI-222667 http://www.gridpp.ac.uk/gsvg/ Eliminating and Preventing Grid Security Vulnerabilities to Reduce Security Risk The Grid Security Vulnerability Group (GSVG) What is a Grid Security Vulnerability? What if you find a vulnerability? Vulnerability issue handling Preventing new vulnerabilities being introduced What is being done to find vulnerabilities in the currently deployed grid? The Future – The EGI Software Vulnerabilities Group (SVG) Author list, credit, and further information GSVG RAT members: Linda Cornwall (RAL), Stephen Burke(RAL), Vincenzo Ciaschini(INFN), Gergely Debreczeni (CERN, KFKI-RMKI), Oscar Koeroo (Nikhef), Daniel Kouril (CESNET), Kalman Kovari (ELTE), Maarten Litmaath (CERN), Eygene Ryabinkin(RRC-KI), Mischa Salle(Nikhef), Ake Sandgren(HP2CN), Steve Traylen(CERN). Code reviews carried out by Gerard Frankowski and other members of the Security team at the Poznan Supercomputing and Networking Centre in Poland. Vulnerability Assessment information and Secure coding tutorials by Barton Miller and James Kupsch from the University of Wisconsin and Elisa Heymann of the Universitat Autònoma de Barcelona.are available at http://www.cs.wisc.edu/mist/ http://www.cs.wisc.edu/mist/ Article in ISGTW at http://www.isgtw.org/?pid=1002400http://www.isgtw.org/?pid=1002400 CERN, SwitzerlandCESNET, Prague, Czech Republic ELTE, Eotvos Lorand University HP2CN, Umea University, Sweden INFN, Istituto Nazionale di Fisica Nucleare, Italy KFKI-RMKI, The Research Centre for Particle and Nuclear Physics, Budapest, Hungary Nikhef, The Dutch National Institute for Subatomic Physics, Amsterdam, The Netherlands RAL, The Rutherford Appleton Laboratory, UK RRC-KI, The Russian Research Centre “Kurchatov Institute”, Moscow, Russia GSVG seeks to eliminate Grid Security Vulnerabilities from the software and prevent new ones being introduced. Our aim is to 'provide a high level of confidence in the security of the deployed infrastructure, thus reducing the risk of incidents.' This work tries to ensure that the Grid appears in the headlines for all the right reasons by avoiding headlines such as 'Grid vulnerability results in major LHC data loss' or 'Grid exploit behind major cyber attack.’ A vulnerability can be seen as a security system that can easily be bypassed, or analogous to a lock that can easily be picked, or a small hole that can let in a small creature which expands into a monster. A simple way of describing a vulnerability is as a bug or weakness in the design of a program or system that can be exploited with malicious intent. Examples include a user being able to get root or admin access where they should not, or being able to delete other users’ files, or anyone being able to gain access where they should not be able. Most people are familiar with the need to keep their computer systems up to date by installing Windows updates or Linux patches. Vulnerabilities may also occur in the software, known as grid middleware, which enables secure and reliable integration and access to the distributed computing resources owned by separate providers. DO NOT Discuss on a mailing list – especially one with an open subscription policy or a public archive. DO NOT Post information on a web page. DO NOT Publicise in any way, e.g. to the media. IMMEDIATELY report it to grid-vulnerability-report@cern.chgrid-vulnerability-report@cern.ch Talking about it in the open will disclose information that will be useful to an attacker. The GSVG ‘Risk Assessment Team’ or RAT, does the following when a new issue is reported: Investigates the issue Finds whether or not the issue is a real vulnerability by collaborating with the reporter and developers of the software as appropriate. If there is a valid issue - Carries out a Risk Assessment The RAT considers how serious a valid issue is, and puts the issue into one of four risk categories – Extremely Critical, High, Moderate, or Low. Sets Target Date for resolution according to Risk This is a fixed value for each Risk category Extremely Critical – 2 days High – 3 weeks Moderate – 3 months Low – 6 months This allows the prioritization of the fixing of issues, according to how serious they are. It is then up to the development team and the integration and testing team to ensure a patch is released in time for the Target Date. Issues an advisory This is done when a patch is released, or on the Target Date – whichever is the sooner, which is known as ‘responsible disclosure’. Release notes for patches should refer to the advisory. Since the activity began in 2005 192 issues have been handled by the GSVG. More on Risk Categories Tyre tracks of vehicles that have gone around a closed entrance gate. Sebastian Lopienski of CERN uses this slide in his presentations on security, with the label “This is not good security.” Site security officers most fear a vulnerability that gives an anonymous person access to the whole site, such a vulnerability would be placed be in the highest risk category, ‘Extremely Critical’ Risk. Issues which give an authorized user ‘Root’ or ‘Admin’ access, would usually be considered ‘High’ Risk. An issue which may allow a ‘Denial of Service’ attack in unlikely circumstances would usually be considered ‘Low’ Risk. The Risk Assessment Team votes to place each issue in the appropriate risk category. There may be mitigating or aggravating circumstances – vulnerabilities tend to have their own unique behaviour. Some members of the GSVG actively look for vulnerabilities in the currently deployed infrastructure. Members of the Poznan Supercomputing and Networking Centre examine code for poor programming techniques and report their findings. Members of the University of Wisconsin / Universitat Autònoma de Barcelona Middleware Security and Testing Group have developed their own techniques for assessing software for vulnerabilities and carried out assessments of several major middleware systems, found significant vulnerabilities in many of them, then helped the developers with remediation strategies. In all cases, any problems found are treated as Vulnerability issues. If your are a developer, please make an effort to become aware of how to avoid introducing new vulnerabilities – for example: Validate input – don’t trust user input, it could be malicious. Check file permissions – an executable with world write permission could be overwritten by a malicious person. Learn about secure programming. Tutorials have been given at various conferences, including some EGEE conferences, by members of the University of Wisconsin Security and Testing Group. Many texts are available for information on how to avoid writing vulnerable software. Up to now, most of the work has concentrated on finding and eliminating vulnerabilities in EGEE gLite software. In the coming months, this activity will be folded into the European Grid Infrastructure (EGI) Software Vulnerabilities Group, and will expand to include all of the technology used as part of EGI’s production infrastructure. Criteria for which software should be allowed onto the EGI infrastructure to ensure that insecure software is avoided will be defined. Software for EGI will be distributed by the EGI Unified Middleware Distribution (UMD). It is expected that the UMD will include other software providers as well as gLite, including ARC, UNICORE and Globus. A Service Level Agreement between EGI and EMI and other software projects which deliver to EGI will be defined, which will include accepting that the SVG will handle vulnerabilities in a similar way to that in EGEE, as well as providing contact details and agreeing to a response time. EGI Security SPGSVG SSG EGI CSIRT EGI Management NGI 2 Sites NGI 1 Sites NGI 3 Sites EGI Virtual Research Communities User Appl.1 Appl.2 Other Grids EUGridPMA UMD Middleware NGI: National Grid Initiative SVG: Software Vulnerabilities Group SPG: Security Policy Group SSG: Software Security Group CSIRT: Computer Security Incident Response team gLite ARC.... Unicore SVG draws membership SVG main interactions Other SVG interactions Examples of: