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

Grid Security Update

David Kelsey (RAL)HEPiX, LBNL 28 Oct 2009

OverviewGrid 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 09 HEPiX, Kelsey 2

OPERATIONAL SECURITY…


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


EGEE Security Incidents


Incidents• Common attack:

• Stolen SSH account(s)• or Web application (known) vulnerability• Escalate as root

• CVE-2009-2692, CVE-2009-2698, 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


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

https://edms.cern.ch/file/867454/2/EGEE_Incident_Response_Procedure.pdfhttp://cern.ch/osct/incident-reporting.html


https://edms.cern.ch/file/867454/2/EGEE_Incident_Response_Procedure.pdf

https://edms.cern.ch/file/867454/2/EGEE_Incident_Response_Procedure.pdf

http://osct.web.cern.ch/osct/incident-reporting.html

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


Peers (2)

• Collaboration with peer grids• Creation of GRID-SEC• "A coordinated response to cross-grid security

incidents“• http://cern.ch/grid-sec/• 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


http://cern.ch/grid-sec/

VULNERABILITIES …


Enabling Grids for E-sciencE

EGEE-III INFSO-RI-222667

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 e-mailing to [email protected] or– By entering in the GSVG savannah

https://savannah.cern.ch/projects/grid-vul/ 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 – seehttp://www.gridpp.ac.uk/gsvg/advisories/



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 https://edms.cern.ch/document/1011173/1

Vulnerability and Risk management 12

SECURITY POLICIES …


21 Sep 2009 Kelsey, Security Policy

Security Policy

Site & VOPolicies

Certification Authorities

Traceability and Logging

SecurityIncident Response

Accounting DataPrivacy

Pilot Jobs and VO Portals

Grid & VOAUPs

JSPG Security Policies


Recent JSPG workFive recently approved and adopted policies• Virtual Organisation Registration Security Policyhttps://edms.cern.ch/document/573348/8• Virtual Organisation Membership Management Policyhttps://edms.cern.ch/document/428034/3• Grid Policy on the Handling of User-Level Job Accounting Datahttps://edms.cern.ch/document/855382/5• VO Portal Policyhttps://edms.cern.ch/document/972973/6• Security Incident Response Policyhttps://edms.cern.ch/document/428035/7

Ongoing revisions

• Site Registration Security Policyhttp://www.jspg.org/wiki/Site_Registration_Security_Policy

– Remove EGEE-specific procedures– Use same simple style as the VO Registration

Security Policy• Grid AUPhttp://www.jspg.org/wiki/Grid_Acceptable_Use_Policy

– Some Grids use it but have modified our text– Some infrastructures do not have VOs– Revise to include these modifications


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


Policy Components

21 Sep 2009

Infrastructure

Includes•Incident Response

•Vulnerability Handling•Patching

•Data protection

•Registration•etc

UsersIncludes

•AUP•Traceability

•VO Management

•Data protection•Incident response

•Data protection

•Registration•etc

ProvidersIncludes

•Traceability•Incident Response

•Access control•Registration

•etc

Security Policy Framework

21 Sep 2009

Infrastructure

Users Providers

Incident Response

Traceability

Data Protection

1 2 3

4 5 6

7 8 9

Policy Components (numbered) at matrix intersections

etc etc etc

IDENTITY MANAGEMENT AND TRUST…




IGTF Developments

International Grid Trust Federation– EUGridPMA, TAGPMA, APGridPMA

• Federation Certification Authorities• Robot certificates and naming• Private key protection

21HEPiX, Kelsey



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 - 24David Groep – [email protected]

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


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 - 26David Groep – [email protected] thanks to Licia Florio, TERENA

A highly successful confederation!


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


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 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


New: TERENA ‘eScience’ TCSes

Initial partners: FEIDE, SURFfederatie, HAKA, WAYF, Swamid, CESNETTERENA

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




In ‘personal CA’, not necessarily aware of grid applications


Federated CAs (SLCS and MICS) in 2010



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 athttps://grid.ie/eugridpma/wiki/GuidelineOnRobots• 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



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 e-mail 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



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



Private key protection

• A new "Guideline on Private Key Protection“– https://www.eugridpma.org/guidelines/pkp/– 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 …


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


Questions?


Documents

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