The EGI Software Vulnerability Group and EMI

1. The EGI Software Vulnerability Group and EMI Dr Linda Cornwall, STFC, Rutherford Appleton Laboratory EGI CF 2012 SVG and EMI

2. Contents • The Purpose of the EGI Software Vulnerability Group • What is a vulnerability? • Activities for reducing vulnerabilities • Summary of the issue handling process • Vulnerability Assessment - EMI • Prevention of new vulnerabilities EGI CF 2012 SVG and EMI

3. Purpose Purpose of the EGI Software Vulnerability Group (SVG) “To eliminate existing vulnerabilities from the deployed infrastructure, primarily from the grid middleware, prevent the introduction of new ones and prevent security incidents”. EGI CF 2012 SVG and EMI

4. What is a vulnerability? • A weakness allowing a principal (e.g. a user) to gain access to or influence a system beyond the intended rights • Unauthorized user can gain access • Authorized user can • gain unintended privileges – e.g. root or admin • damage a system • gain unintended access to data or information • delete or change another user’s data • impersonate another user EGI CF 2012 SVG and EMI

5. What is not a vulnerability • Actions which can only be carried out by site administrators • Site administrators mostly trusted • Except with bulk encrypted data + keys • Issues which provide information that may be useful to an attacker • Not usually treated as vulnerabilities • General concerns • e.g. “these instructions are not clear” EGI CF 2012 SVG and EMI

6. 3 main activities for reducing vulnerabilities • Handling vulnerabilities found/reported • Main activity of SVG • Assessing software for vulnerabilities • Mainly done by others, including EMI • Preventing new vulnerabilities being introduced • Developer education, awareness • Considering new software to be used in the infrastructure EGI CF 2012 SVG and EMI

7. Main focus • The main focus is to deal with software vulnerabilities in the EGI Unified Middleware Distribution (UMD) • Middleware generally does not have any other activity handling vulnerabilities • Also handles other software (jointly with CSIRT) to provide consistent risk assessments • Most vulnerabilities found and fixed outside grid activity EGI CF 2012 SVG and EMI

8. Types of software EGI CF 2012 SVG and EMI

9. EGI UMD • Software is distributed by EGI as the Unified Middleware Distribution(UMD) • UMD consists of IGE (Initiative for Globus in Europe), EMI (glite, Unicore, ARC, dCache). • Service Level Agreement (SLA) with these software providers, including • Agree to response times, provide contact details, etc. • Participate in process EGI CF 2012 SVG and EMI

10. Issue handling process • This is carried out by the SVG Risk Assessment Team (RAT) • The RAT has access to information on vulnerabilities reported • Anyone may report an issue • By e-mail to report-vulnerability@egi.eu • Issue is investigated by a collaboration between the RAT, reporter and developers. EGI CF 2012 SVG and EMI

11. Issue handling (2) • If the Issue is valid, the RAT carries out a risk assessment • Issue placed in one of 4 risk categories Critical, High, Moderate or Low • Risk assessment carried out by the RAT because • mitigating or aggravating factors may exist in the Grid environment • Usually by consensus - the RAT usually agrees on the category • Say vote, but mostly agree on category EGI CF 2012 SVG and EMI

12. Issue handling (3) • Target Date for resolution set according to the Risk • Critical - 3 days, High - 6 weeks, Moderate – 4 months, Low - 1 year • Aim to reach this point within 4 working days • Within 1 day for critical issues • This allows the prioritization of the timely resolution of issues according to their severity EGI CF 2012 SVG and EMI

13. Issue handling (4) • It is then up to the developers and release team to fix the problem by the Target Date or earlier • SVG will provide help and advice if appropriate • Track version product where vulnerability is fixed, release of e.g. EMI which contains fix, release UMD containing fix. • Advisory released when fix present in UMD, or on the target date EGI CF 2012 SVG and EMI

14. Fixing issues • Development teams (e.g. In EMI) fix problem and test solution • Integrated into release • Tested and certified • Later released as part of EGI UMD • Small coding error that results in vulnerability can result in a lot of work. EGI CF 2012 SVG and EMI

15. Vulnerability Assessment • Examination and testing of software in order to find vulnerabilities • For EMI this is done in the Computer Architecture and Operating Systems department at UniversitatAutònoma de Barcelona • Some assessment work also carried out by Poznan Supercomputing Centre EGI CF 2012 SVG and EMI

16. FPVA • Members of the University of Wisconsin and theUniversitatAutònoma de Barcelona have developed the First Principles Vulnerability Assessment • This involves the detailed manual assessment of a piece of software EGI CF 2012 SVG and EMI

17. FPVA methodology • Understanding the architecture, resources, trust and privilege analysis, detailed evaluation of components • Very effort intensive, typically a few PM effort per piece of software • Plan written for small number of priority components to be analysed during EMI EGI CF 2012 SVG and EMI

18. FPVA gLite assessed • VOMS Admin 2.0.18 • Vulnerabilities found fixed (1 year ago) • Argus 1.2 • No vulnerabilities found • gLexec 0.8 • Some ‘Low’ risk vulnerabilities found • Fixed in EMI 2 • VOMS Core 2.0.2 • 1 ‘Low risk DoS EGI CF 2012 SVG and EMI

19. FPVA in work/plans gLite: • WMS: Workload Management System • currently in work • CREAM: Computing Resource Execution And Management • Planned after WMS EGI CF 2012 SVG and EMI

20. FPVA plans -UNICORE • Target System Interface (TSI) • provides an interface between UNICORE and the individual resource management/batch system and operating system of the Grid resources. • Gateway • an authenticating web proxy service for web service requests (SOAP messages) and normal HTTP traffic of the UNICORE Grid middleware EGI CF 2012 SVG and EMI

21. Vulnerability prevention • Developer education • Tutorials on secure coding given at the EGI TF 2011 • Tests in certification • Assessing new software to be deployed on EGI infrastructure • Requirements for changes – ensure these do not introduce vulnerabilities EGI CF 2012 SVG and EMI

22. E.g. file permission • World writeable executable that runs as ‘root’ is a root exploit • Several during EGEE-II and EGEE-III • Now part of the EMI certification process to check for world writable files • None recently • World readable can of course also expose data or information unintentionally EGI CF 2012 SVG and EMI

23. Other vulnerability prevention • No funding/effort for checking new software for vulnerabilities • Checklist checks which must be done before new software used in EGI suggested • No progress yet • Checking new requirements/ change requests • E.g. ‘tool’ which gives useful info may introduce a vulnerability EGI CF 2012 SVG and EMI

24. The future • Current SVG issue handling well established and should continue • Vulnerability assessment continuing • Assessment of new software, changes • No significant effort at present • Virtualization, Clouds, other changes, • Need to address changes needed • Sustainability of activity • Availability of funding and effort EGI CF 2012 SVG and EMI

25. More information • Vulnerability Issue handling Process https://documents.egi.eu/public/ShowDocument?docid=717 • EGI SVG Wiki https://wiki.egi.eu/wiki/SVG:SVG • RAT Members https://wiki.egi.eu/wiki/SVG:RAT_Members • Secure coding tutorials at EGI TF https://www.egi.eu/indico/contributionDisplay.py?contribId=75&confId=452 • FPVA http://research.cs.wisc.edu/mist/includes/vuln.html • University of Wisconsin/UAB team http://research.cs.wisc.edu/mist/includes/people.html EGI CF 2012 SVG and EMI

26. Questions? • ?? EGI CF 2012 SVG and EMI