Grid Security Update David Kelsey (RAL) HEPiX, LBNL 28 Oct 2009

Overview Grid Security Update Progress during the last year (since last HEPiX talk) Operational security (OSCT) Vulnerability handling (GSVG) Security policies (JSPG) Identity management and trust (IGTF) Thanks to colleagues for material (Romain Wartel - OSCT, Linda Cornwall - GSVG, David Groep - IGTF) Nothing on technical issues – see talk by M. Litmaath on WLCG Security (Thursday) 28 Oct 09HEPiX, Kelsey2

OPERATIONAL SECURITY… 28 Oct 09HEPiX, Kelsey3

OSCT Tasks Security Incident Response Concentrate on this today OSCT also works on Security Service Challenges Security Training Security Monitoring But no more on those today 28 Oct 09HEPiX, Kelsey4

EGEE Security Incidents 28 Oct 09HEPiX, Kelsey5

Incidents Common attack: Stolen SSH account(s) or Web application (known) vulnerability Escalate as root CVE , CVE , etc. Deploy rootkit or further malware Several incidents avoidable if sites were up-to-date with security patches Grid management supported recent suspension of unpatched sites 28 Oct 09HEPiX, Kelsey6

Incidents(2) Updated incident response procedure Redesigned to include feedback and metrics from security service challenges Specific details and contact points added Templates for initial reporting and final report Coordination process within the OSCT described onse_Procedure.pdf 28 Oct 09HEPiX, Kelsey7

Peers Collaboration with the NRENs Significant progress since last year Many more contacts established between the ROCs and their NRENs BoF at TERENA Network Conference 09 Collaboration plan agreed, implementation in progress As far as we can go, the rest is in the hands of each ROC/NREN 28 Oct 09HEPiX, Kelsey8

Peers (2) Collaboration with peer grids Creation of GRID-SEC "A coordinated response to cross-grid security incidents“ Framework to share incident-related information Rather extensive coverage of the academic community Already been handling 2 cross-grid security incidents Incidents affecting sites belonging to different grids 28 Oct 09HEPiX, Kelsey9

VULNERABILITIES … 28 Oct 09HEPiX, Kelsey10

Enabling Grids for E-sciencE EGEE-III INFSO-RI GSVG Issue handling summary Grid Security Vulnerability Group Aim is to find and fix vulnerabilities in the middleware –And avoid security incidents Anyone may report an issue –By ing to –By entering in the GSVG savannah  Note that bugs are private so cannot be read except by members of this savannah project The Risk Assessment Team (RAT) investigates the issue, if valid carries out a Risk Assessment Advisories issued – see

Enabling Grids for E-sciencE EGEE-III INFSO-RI Some numbers (Sept 2009) 174 Issues submitted since started in 2005 –(28 submitted in last 12 months) –For those fully risk assessed (since current strategy started mid 2006) 1EC, 19 High, 21 Moderate, 39 Low 111 closed –64 closed as fixed, 16 invalid, 5 duplicates, 10 OSCT informed, 5 software no longer in use, 11 more general concerns adequately addressed 63 open –17 awaiting TD, 15 disclosed, most of the rest either very low risk or more general concerns rather than specific vulnerabilities –Situation with open issues not awaiting TD described in document at Vulnerability and Risk management 12

SECURITY POLICIES … 28 Oct 09HEPiX, Kelsey13

21 Sep 2009Kelsey, Security Policy Security Policy Site & VO Policies Certification Authorities Traceability and Logging Security Incident Response Accounting Data Privacy Pilot Jobs and VO Portals Grid & VO AUPs JSPG Security Policies

21 Sep 2009Kelsey, Security Policy Recent JSPG work Five recently approved and adopted policies Virtual Organisation Registration Security Policy Virtual Organisation Membership Management Policy Grid Policy on the Handling of User-Level Job Accounting Data VO Portal Policy Security Incident Response Policy

Ongoing revisions Site Registration Security Policy –Remove EGEE-specific procedures –Use same simple style as the VO Registration Security Policy Grid AUP –Some Grids use it but have modified our text –Some infrastructures do not have VOs –Revise to include these modifications 21 Sep 2009Kelsey, Security Policy

New policy framework for EGI A framework to enable interoperation of collaborating Grids –managing cross-Grid operational security risks Identify policy components help trust building between Grids Not imposing a single policy for all Other components are either too EGEE-specific or are operational rather than related to security – separate them Each Grid will have security policies consisting of the framework components and their own Grid-specific components 21 Sep 2009Kelsey, Security Policy

Policy Components 21 Sep 2009 Infrastructure Includes Incident Response Vulnerability Handling Patching Data protection Registration etc Users Includes AUP Traceability VO Management Data protection Incident response Data protection Registration etc Providers Includes Traceability Incident Response Access control Registration etc

Security Policy Framework 21 Sep 2009 InfrastructureUsersProviders Incident Response Traceability Data Protection Policy Components (numbered) at matrix intersections etc etc etc

IDENTITY MANAGEMENT AND TRUST… 28 Oct 09HEPiX, Kelsey20

Enabling Grids for E-sciencE EGEE-III INFSO-RI IGTF Developments International Grid Trust Federation –EUGridPMA, TAGPMA, APGridPMA Federation Certification Authorities Robot certificates and naming Private key protection 21 HEPiX, Kelsey

Enabling Grids for E-sciencE EGEE-III INFSO-RI Federated Authentication IGTF created a global X.509 PKI trust fabric This currently serves a few x 10,000 users The identity vetting processes and CA operations are expensive –Can we improve this? Now show what is happening in Europe Similar activities have also started in the USA –NCSA CIlogon project  Using US InCommon federation

Towards more Federated Authorities in Europe and the TERENA eScience (Personal) CA David Groep

Federated Authorities in Europe and the TERENA TCS CAs - 24 David Groep – Grids, Eduroam, Federations  Different terms, same issues  How to provide access only the ‘proper’ people?  Most of whom you’ve never met and will never meet  Across organisations and countries  Traceable and consistent over many years  Core issue is trust

Federated Authorities in Europe and the TERENA TCS CAs - 25 David Groep – Refresher: Federations grid structure was not too much different!  A common Authentication and Authorization Infrastructure  Allow access to common resources with a single credential

Federated Authorities in Europe and the TERENA TCS CAs - 26 David Groep – With thanks to Licia Florio, TERENA A highly successful confederation!

Federated Authorities in Europe and the TERENA TCS CAs - 27 David Groep – Beyond the network  Research community requirements go beyond network access  Increasing dynamics in the education system  Students can access courses in other faculties  Students take some course units abroad (Bologna)  On-line courses are more common  Users want to access the same services no matter where they are  Grid: example of access to distributed resources  More institutions dealing with the same users means:  Multiple registration of users  Overhead to manage guest users  Increased possibility of error in managing the users’ records With thanks to Licia Florio, TERENA

Federated Authorities in Europe and the TERENA TCS CAs - 28 David Groep – Grid & Federations - a logical combination  Many of the e-Infrastructure users have a federated account anyway  Could give users grid certificates within 5 minutes without any further hassle, if the trust level matches  Allows users to ’try’ the grid  Allows for scaling the number of grid users significantly  Comparable issues and trust levels  Federation assurance levels are going up, as more diverse services participate in the federation  User account management of IdPs is improving rapidly … far more rapidly than grid credential management …

Federated Authorities in Europe and the TERENA TCS CAs - 29 David Groep – Federated CAs: there already!  SWITCH  Accredited 2007 under SLCS  Shib-only federation, dedicated software development  Leverages nice, tightly-controlled SWITCHaai federation  DFN SLCS  Accredited 2008 as SLCS  TERENA eScience Personal CA (formerly NetherNordic SLCS/MICS)  Under accreditation today  Multi-technology federation, SAML2 based  Heterogeneous federations, with web access being the only common element

Federated Authorities in Europe and the TERENA TCS CAs - 30 David Groep – New: TERENA ‘eScience’ TCSes  Initial partners: FEIDE, SURFfederatie, HAKA, WAYF, Swamid, CESNET TERENA  Trans-national, cross-federation service  But not (yet) confederated  How many SLCS/MICS CAs does Europe need ?  Consolidate operational PKI skills in one place  Better sustainability, in line with the European trend

Federated Authorities in Europe and the TERENA TCS CAs - 31 David Groep –

Federated Authorities in Europe and the TERENA TCS CAs - 32 David Groep –

Federated Authorities in Europe and the TERENA TCS CAs - 33 David Groep – In ‘personal CA’, not necessarily aware of grid applications

Federated Authorities in Europe and the TERENA TCS CAs - 34 David Groep – Federated CAs (SLCS and MICS) in 2010

Enabling Grids for E-sciencE EGEE-III INFSO-RI Robots & naming “Non-human automated clients that perform automated tasks without human intervention on behalf of named human individuals” –E.g. monitoring clients, some types of Grid portals The draft IGTF Guideline for Robots can be found at One common name component of the subject distinguished name (in the certificate) –must start with the string “Robot”, immediately followed by the COLON character or a SLASH –And followed by a string describing the function of the robot The natural person responsible for the automated client must also be identified by an appropriate representation of their name in the CN

Enabling Grids for E-sciencE EGEE-III INFSO-RI Robot naming (2) The CERN CA has proposed for robot certs –to drop the requirement for a person’s name  Frequent change of staff and/or duties  Privacy issues –substitute with a responsive address of the group responsible for the robot certificate  And add an Endorser’s personID *Lots* of discussion on this at recent IGTF meetings –So far the IGTF is not willing to drop the requirement for an actual responsible person to be named

Enabling Grids for E-sciencE EGEE-III INFSO-RI Robot – hardware tokens USB secure hardware tokens – private key can never be extracted (unencrypted) Initial risk analysis –hardware tokens to protect Robot keys –does not fundamentally improve security cf software tokens –If the hardware tokens remain activated for long time periods and if the relying parties accept 'proxy' certificates for delegation Different groups in the IGTF will now proceed with a more in-depth analysis of the security issues It is likely, but not certain, that future versions of the Guideline on Robots may relax the requirement to use hardware tokens

Enabling Grids for E-sciencE EGEE-III INFSO-RI Private key protection A new "Guideline on Private Key Protection“ – –Draft at this stage Generation and storage of user private keys on –shared file systems –remote user interface systems (codifying current practice) Generation and storage of private keys *for end users* –on well secured and managed portals –without the user ever having to hold the private key Enabling national Credential Stores/MyProxy Services –run for many users and on behalf of many portals –subject to some specific security restrictions

SUMMARY … 28 Oct 09HEPiX, Kelsey39

Summary Good progress during last year –In all security areas Handling of security incidents and vulnerabilities continues to improve Policies are moving forward into EGI era Identity management is changing to tackle ease of use and scaling issues 28 Oct 09HEPiX, Kelsey40

Questions? 28 Oct 09HEPiX, Kelsey41