grid security in egee/lcg isgc 2005, taipei, taiwan 29 april 2005

Grid Security in EGEE/LCGISGC 2005, Taipei, Taiwan

29 April 2005

David KelseyCCLRC/RAL, UK

[email protected]

29-Apr-05 David Kelsey, Grid Security, ISGC 2005

2

Introduction

• The Grid aim– Easy and open sharing of resources

• However– Highly distributed resources and communities– Independent administrative domains

• The Internet today– An ever-increasingly hostile environment– Growing need for firewalls and other controls

• Therefore need to convince– Computer Centres to allow Grid services– Developers & Users to take security seriously

• Grid functionality versus Security– A major challenge!


3

Outline• These slides are available at

http://hepwww.rl.ac.uk/kelsey/kelsey29apr05.ppt• Security requirements

– Security groups & requirements in EGEE• The Grid Security model• Authentication• Authorization & VO Management• Security Policy & Procedures• Operational Security

– Security Service Challenges• Future plans• Final words


4

Security Requirements

• Users require– Open/easy access to cpu and data– Single Registration (once per VO)– Single Sign-On (login once per session)– Not to be bothered by security!

• But they do need Availability and Data Integrity• Computer Centres/Security Officers require

– Full local control of access to their resources– Knowledge of User details– Ability to audit (Who? What? When?)– Secure middleware, applications and services– Not to be bothered by security incidents

David Kelsey, Grid Security, ISGC 2005 5

Enabling Grids for E-sciencE

INFSO-RI-508833

JRA3 JRA1

NA4

MiddlewareSecurity Group

Joint Security Policy Group

NA4NA4NA4Solutions/Recommendations

Req. Req.Req.

Req.

Req.

Req.

SA1

“Joint Security Policy Group” defines policy and proceduresand inputs requirements to MWSG(For LCG/GDB and EGEE/SA1)

(Cross Membership of US OSG Sec Team)

CA Coordination

Security

Middleware

Applications

Operations

OSG

LCG

OSCT

Security requirements - Understanding how input from applications, sites and operations are handled.


6

The Security Model


7

The Security Model• Authentication – proof of identity

– GSI: Globus Grid Security Infrastructure (interoperate)

– Single sign-on via X.509 certificates (PKI)– Delegation (via short-lived proxy certs) to services

• Global Authorization – right to access resources– Virtual Organisation (VO) – e.g. a Biomed experiment

• Maintains list of registered users• Allocates users to groups and/or roles• Controls global policy and allocations

• Local Authorization – site access control– Via local (e.g. Unix) mechanisms or– Callouts to local AuthZ enforcement (Grid

developments)– Grid ACL’s - global identity or VO AuthZ attributes

• Policy– Grids (e.g. EGEE, OSG) define security policy– Many stakeholders also contribute to “policy”



INFSO-RI-508833

Security Baseline assumptions

• Be Modular and Agnostic– Allow for new functionality to be included as an afterthought– Don’t settle on particular technologies needlessly

• Be Standard– Interoperate (GGF, WS-I, OSG, …)– Don’t roll our own, to the extent possible

• Be Distributed and Scalable– “Central services are evil”– Always retain local control

Slide from Olle Mulmo – EGEE-3 Athens 19 April 2005



INFSO-RI-508833

Baseline assumptions

• VOs self-govern the resources made available to them– Yet try to minimize VO management!– Use AuthN to tie policy to individuals/resources

• An open-ended system– No central point of control– Can’t tell where the Grid ends

• Best-effort solutions– rather than “appropriate” solutions

Slide from Olle Mulmo – EGEE-3 Athens 19 April 2005


10

Security Policy

Key Material

Group of unique names Organizational role

Server

UserAttributesVO

Policy

ResourceAttributesSite

Policy

Policy

Authorization PolicyArchitecture

Local SiteKerberosIdentity

PolicyEnforcement

Point

VOOther

Stakeholders

Site/Resource

OwnerAuthorization

Service/PDP

Policy andattributes.

Allow orDeny

Resource

Standardize

Delegation

User

Process actingon user’s behalf

PKI/KerberosIdentity

TranslationService

PKIIdentity

Delegation Policy

Graphics fromGlobus Alliance& GGF OGSA-WG

Policy comes from many stakeholders


11

Authentication


12

Authentication

• Keep Authentication and Authorization separate– Authentication best done at Institute level– Authorization best done at VO level

• Provide the User with one (Grid) electronic identity– For use in many Grid projects or VOs– For user convenience

• Have successfully built a global PKI (X.509)– Mutual Authentication of people and services

• What is the most appropriate scale?– One CA per country/region (ideally for all eScience)

• EU Grid PMA has coordinated the (global) CA’s– “minimum requirements” for accredited CA’s

• Now three worldwide PMA’s for Authentication– Asia/Pacific, The Americas and EU– International Grid Federation coordinates these

• Federation agreement aimed for GGF in June 2005


13

EU Grid PMA CAs

Other Accredited CAs: DoEGrids (USA) GridCanada ASCCG (Taiwan) ArmeSFO (Armenia) Russia Israel Pakistan

“Catch-all” CAs operated byCNRS (for EGEE)US DoE (for LCG)SEE-GRID (for SE Europe)

• Austria• Belgium• CERN• Cyprus• Czech

Republic• Estonia• France• Germany• Greece• Hungary

• Ireland• Italy• Nordic

countries• Poland• Portugal• Slovakia• Slovenia• Spain• Switzerland• The

Netherlands• UK

Under consideration•Baltic Grid

•Bulgaria

•China – IHEP

TERENA TACAR repository(for root certificates)

http://www.eugridpma.org/


14

Authorization and VO Management


15

Authorization & VO Management

• In EGEE gLite Release 1• Global AuthZ (VOMS)

– Virtual Organization Membership Service• VO members, their groups and roles• Provides digitally signed AuthZ “attributes”

– Included in the grid proxy certificate

• Local AuthZ– Local Centre Authorization Service (LCAS)

• A framework to handle local policy (e.g. banned users)

– Local Credential Mapping (LCMAPS)• Provides local credentials (Kerberos/AFS, ldap nss…)

• Local policy decisions (CE and SE)– Can decide and enforce policy on VOMS attributes

• n.b. LCAS/LCMAPS is just one local AuthZ service


16

AuthZ – VOMS & LCAS

VO-VOMS

useruser serviceservice

authentication & authorization info

user cert(long life)

VO-VOMS

VO-VOMS

VO-VOMS

CA CA CAlow frequency

high frequency

host cert(long life)

authz cert(short life)

service cert(short life)

authz cert(short life)

proxy cert(short life)

voms-proxy-init

crl update

registration

registration

LCAS


17

Security Policy


18

EGEE/LCG Security Policy

• During 2003/04, the LCG project agreed a first version of its Security Policy– Written by the Joint Security Policy Group– Approved by the Grid Deployment Board

• A single common policy for the whole project– But does not override local policies

• An important step forward for a production Grid• The policy

– Defines Attitude of the project towards security and availability

– Gives Authority for defined actions– Puts Responsibilities on individuals and bodies

• Now being used by EGEE and (some) national Grids


19

EGEE/LCG Security Policy (2)

Security & Availability Policy

UserAUP

Certification Authorities

AuditRequirements

Incident Response

User Registration & VO Management

http://cern.ch/proj-lcg-security/documents.html

Application Development& Network Admin Guide

picture from Ian Neilson

VOAUP

Under Revision

http://cern.ch/proj-lcg-security/documents.html

http://proj-lcg-security.web.cern.ch/proj-lcg-security/docs/LCG_Security_Guide.asp


20

Operational Security and Security Service Challenges

EGEE3 Athens 21 April 2005 - 21

Operational Security

• After LCG Workshop and EGEE2

Practicalinformation for

sys admins

Systemmonitoring

tools

Incidentresponse

SecurityService

Challenge

EGEE Operational Security Coordination TeamSlide from Ian Neilson – EGEE-3 Athens 19 April 2005

EGEE Athens 21 Apr 2005 - 22

Operational Security Coordination

• Security Service Challenges• Objectives (https://edms.cern.ch/document/478367)

a) Evaluate the effectiveness of current procedures by simulating a small and well defined set of security incidents.

b) Use the experiences of a) in an iterative fashion (during the challenges) to update procedures.

c) Formalise the understanding gained in a) & b) in updated incident response procedures.

d) Provide feedback to middleware development and testing activities to inform the process of building security test components.

Slide from Pal Anderssen – EGEE-3 Athens 21 April 2005

EGEE Athens 21 Apr 2005 - 23

Future Plans


24

Future plans

Authentication• Many concerns about user-managed

credentials– Too complex and too insecure

• Several solutions to be considered– Smart Cards– Credential Repositories (e.g. MyProxy)

• Long-term credentials never held by user

– Site Integrated Proxy Services (SIPS)• e.g. Kerberos CA

• Better certificate revocation technologies– E.g. OCSP


25

Future plans (2)Other foreseen EGEE security developments include• Logging and Auditing• Authorization

– Local policy decisions and enforcement– Standards based (OGSA-AuthZ)

• Delegation• Data Key management

– privacy & confidentiality• Isolation and Sandboxing• Dynamic Connectivity (Site Proxy)

See EGEE Global Security Architecturehttps://edms.cern.ch/document/487004/EGEE Site Access Control Architecturehttps://edms.cern.ch/document/523948/


26

Future plans (3)

Security Policy and Procedures• Joint Security Policy Group

– With OSG– Revise all security policy documents

• Aim to make more general (wherever possible)– e.g. by working on joint documents– Today, too LCG-specific

• Currently working on User AUP and VO AUP– See Bob Cowles’ talk

Security Vulnerability Detection and Reduction• Look for and record known problems

– Middleware and Deployment– And encourage speedy fixes

• Work started in UK GridPP• Now collaborating with EGEE JRA3


27

Future plans (4)

Operational Security• In Europe, EGEE OSCT will continue the work

recently started• Incident Response

– see Bob Cowles’ talk on OSG work– EGEE using same approach

• Perform Security Service Challenges• Security Monitoring• Forensic Analysis• Best practice guides


28

References

• LCG/EGEE Joint Security Policy Grouphttp://proj-lcg-security.web.cern.ch/

• EGEE JRA3 (Security)http://egee-jra3.web.cern.ch/

• Open Science Grid Securityhttp://www.opensciencegrid.org/techgroups/security/

• EU DataGrid Securityhttp://hep-project-grid-scg.web.cern.ch/

• LCG Guide to Application, Middleware and Network Security

https://edms.cern.ch/document/452128• EU Grid PMA (CA coordination)

http://www.eugridpma.org/• TERENA Tacar (CA repository)

http://www.terena.nl/tech/task-forces/tf-aace/tacar/

http://proj-lcg-security.web.cern.ch/

http://proj-lcg-security.web.cern.ch/

http://egee-jra3.web.cern.ch/







29

Final Words

• Much has been achieved over recent years– Authentication– Authorization– Policy and Procedures– Operational Security

• “Keep Security Simple” – or deployers & users will turn it off

• But Grid middleware is less mature than Operating Systems– and see the many security patches for OS’s

• Security incidents will happen– Well defined/agreed response procedures are essential– Grid services/middleware will need frequent security

patches• Perhaps this will be the first sign of maturity?

grid security in egee/lcg isgc 2005, taipei, taiwan 29 april 2005

Documents

security modeldavid

security incidentsdavid

security policy group

grid servicesdevelopers

introductionthe grid

policydavid kelsey

david kelsey cclrcral

local controlslide