Date post: | 20-Jan-2018 |
Category: |
Documents |
Upload: | reynold-hutchinson |
View: | 215 times |
Download: | 0 times |
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…
28 Oct 09 HEPiX, Kelsey 3
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 09 HEPiX, Kelsey 4
EGEE Security Incidents
28 Oct 09 HEPiX, Kelsey 5
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
28 Oct 09 HEPiX, Kelsey 6
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
28 Oct 09 HEPiX, Kelsey 7
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 09 HEPiX, Kelsey 8
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
28 Oct 09 HEPiX, Kelsey 9
VULNERABILITIES …
28 Oct 09 HEPiX, Kelsey 10
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/
Enabling Grids for E-sciencE
EGEE-III INFSO-RI-222667
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 …
28 Oct 09 HEPiX, Kelsey 13
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
21 Sep 2009 Kelsey, Security Policy
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
21 Sep 2009 Kelsey, 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 2009 Kelsey, Security Policy
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…
28 Oct 09 HEPiX, Kelsey 20
Enabling Grids for E-sciencE
EGEE-III INFSO-RI-222667
IGTF Developments
International Grid Trust Federation– EUGridPMA, TAGPMA, APGridPMA
• Federation Certification Authorities• Robot certificates and naming• Private key protection
21HEPiX, Kelsey
Enabling Grids for E-sciencE
EGEE-III INFSO-RI-222667
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
Federated Authorities in Europe and the TERENA TCS CAs - 25David Groep – [email protected]
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!
Federated Authorities in Europe and the TERENA TCS CAs - 27David Groep – [email protected]
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 - 28David Groep – [email protected]
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 - 29David Groep – [email protected]
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 - 30David Groep – [email protected]
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
Federated Authorities in Europe and the TERENA TCS CAs - 31David Groep – [email protected]
Federated Authorities in Europe and the TERENA TCS CAs - 32David Groep – [email protected]
Federated Authorities in Europe and the TERENA TCS CAs - 33David Groep – [email protected]
In ‘personal CA’, not necessarily aware of grid applications
Federated Authorities in Europe and the TERENA TCS CAs - 34David Groep – [email protected]
Federated CAs (SLCS and MICS) in 2010
Enabling Grids for E-sciencE
EGEE-III INFSO-RI-222667
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
Enabling Grids for E-sciencE
EGEE-III INFSO-RI-222667
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
Enabling Grids for E-sciencE
EGEE-III INFSO-RI-222667
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-222667
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 …
28 Oct 09 HEPiX, Kelsey 39
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 09 HEPiX, Kelsey 40
Questions?
28 Oct 09 HEPiX, Kelsey 41