Update on Security Policy David Kelsey (RAL) 7 Mar 2010 Security Workshop @ ISGC 2010, Taipei david.kelsey at stfc.ac.uk
Overview • Why do we need security policies? • Joint Security Policy Group (JSPG) – Some history – Interoperability • Overview of JSPG policies – Current status and recent work • The transition to EGI Kelsey, Security Policy 7 Mar 2010 2
Why do we need security policies? • Management of IT security – Management of risk, balanced with availability of services • Perform a risk analysis – Need a Security Plan • to mitigate and manage the risks • Security Plan includes various “Controls” – Technical – Operational – Management • Security Policy is part of Management Controls (written documents) Kelsey, Security Policy 7 Mar 2010 3
Trust is important • Trust is a relationship of reliance. A trusted party is presumed to seek to fulfill policies, ethical codes, law and their previous promises. (wikipedia) • Trust is a prediction of reliance on an action, based on what a party knows about the other party. Trust is a statement about what is otherwise unknown -- for example, because it is far away, cannot be verified, or is in the future. Kelsey, Security Policy 7 Mar 2010 4
Joint Security Policy Group • This started as a WLCG activity in 2003 • In 2004, EGEE phase 1 started – JSPG remit expanded to cover both projects – Strong participation by OSG, NDGF, … • Revised mandate (2008) – http://www.jspg.org/ – prepares and maintains security policies for its primary stakeholders (EGEE and WLCG) – also able to provide policy advice on any security matter • Policies approved and adopted by Grid management • Now taking forward into EGI era (more later) Kelsey, Security Policy 7 Mar 2010 5
Policy Interoperability • Wherever possible, JSPG aims to – prepare simple and general policies – applicable to the primary stakeholders, but – also of use to other Grid infrastructures (NGI's etc) • The adoption of common policies by multiple Grids eases the problems of interoperability (and scaling) • Users, VOs and Sites all accept the same policies during their (single) registration (with Grid or VO) • Other participants then know that their actions are already bound by the policies – No need for additional negotiation, registration or Kelsey, Security Policy 7 Mar 2010 6 agreement
Overview of JSPG Policies Kelsey, Security Policy 7 Mar 2010 7
Grid Security Policy • The main policy document • https://edms.cern.ch/document/ 428008/ • “…policy regulating those activities of Grid participants related to the security of Grid services and Grid resources.” Kelsey, Security Policy 7 Mar 2010 8
Grid Security Policy (2) • Objectives – gives authority for actions • may be carried out by certain individuals and bodies – places responsibilities on all participants • Scope – This policy applies to all participants – Every site participating in the Grid autonomously owns and follows their own local security policies – This policy augments local policies by setting out additional Grid-specific requirements. Kelsey, Security Policy 7 Mar 2010 9
Grid Security Policy (3) • Additional Policy documents – Appendix 1 defines additional policy documents – These must exist for a proper implementation of this policy • Roles and Responsibilities: Participants – Grid Management – Grid Security O ffj cer & Grid Security Operations – Virtual Organisation Management – Users – Site Management – Resource Administrators Kelsey, Security Policy 7 Mar 2010 10
Grid Security Policy (4) • Limits to Compliance – Grid policies designed to be applied uniformly across all sites and VOs – exceptions may be made when required – must be justified in a document submitted to the Grid Security O ffj cer for authorisation – In exceptional circumstances it may be necessary for emergency action – the exception should be minimised, documented, time- limited and authorised at the highest level of the management commensurate with taking the emergency action promptly, and the details notified to the Grid Security O ffj cer at the earliest opportunity Kelsey, Security Policy 7 Mar 2010 11
Grid Security Policy (5) • Sanctions – Sites or resource administrators who fail to comply may lose the right to have that service instance recognised by the Grid – Users who fail to comply may lose their right of access to and/or collaboration with the Grid • may be reported to their home institute • Or to appropriate law enforcement agencies – VOs which fail to comply may lose their right of access to and/or collaboration with the Grid • Including all their users Kelsey, Security Policy 7 Mar 2010 12
JSPG Security Policies Security Incident Certification Traceability and Response Authorities Logging Security Site & VO Grid & VO Policy Policies AUPs Pilot Jobs and Accounting Data VO Portals Privacy Kelsey, Security Policy 7 Mar 2010 13
Recent JSPG work • JSPG membership expanded to include more NGIs (-> EGI era) – revise all policy documents to make simpler and more general Policies approved and adopted during the last year… • Virtual Organisation Registration Security Policy https://edms.cern.ch/document/573348/8 • Virtual Organisation Membership Management Policy https://edms.cern.ch/document/428034/3 • Grid Policy on the Handling of User-Level Job Accounting Data https://edms.cern.ch/document/855382/5 • VO Portal Policy https://edms.cern.ch/document/972973/6 • Security Incident Response Policy https://edms.cern.ch/document/428035/7 Kelsey, Security Policy 7 Mar 2010 14
Revision to Grid AUP • http://www.jspg.org/wiki/ Grid_Acceptable_Use_Policy – Version 4.1 • Old policy document (V3.1 28 Oct 2005) – one of the early successes of JSPG – a simple common policy for use on several di fg erent interoperating Grids – AUP has to be accepted by all users during their (re)registration with their VO – Important for interoperation between Grids Kelsey, Security Policy 7 Mar 2010 15
Grid AUP (2) • Many Grids and other computing infrastructures, e.g. DEISA, have since used this AUP • but needed to make small modifications • main aim of this revision – take these modifications into account – produce a new version to meet the needs of Grids using the policy Kelsey, Security Policy 7 Mar 2010 16
Revision to Site Registration • http://www.jspg.org/wiki/ Site_Registration_Security_Policy – Version 3.1 • Old policy document (V2.0 16 Mar 2006) – contains many detailed registration procedures • These are too EGEE-specific • JSPG decided to remove these – change the focus of the document to be purely related to security policy issues – similar to the recently approved "Virtual Organisation Registration Security Policy“ • new document is now much shorter and simpler Kelsey, Security Policy 7 Mar 2010 17
From EGEE to EGI Kelsey, Security Policy 7 Mar 2010 18
Problems with current Policies • The complete revision during EGEE-III has been successful, however… • Still many di fg erent documents – Overlaps and inconsistencies • Includes operational issues as well as security-related issues • Participants find it di ffj cult to know which policy applies to them • Many policies are rather EGEE-specific Kelsey, Security Policy 7 Mar 2010 19
Policy framework for EGI - defining policy standards • A framework to enable interoperation of collaborating Grids – aimed at managing cross-Grid operational security risks • Identify policy components needed for trust between Grids • Not necessarily imposing a single policy for all – But Grids can use template policies if they wish • Presents the current set of JSPG policies – Taking high-level view to identify those components which are necessary • Other components are either too EGEE-specific or are operational rather than related to security – separate them Kelsey, Security Policy 7 Mar 2010 20
Framework (2) • Specifies the issues that need to be addressed in a Grid's security policy • At this stage does not define minimum standards or requirements – Standards should come later Kelsey, Security Policy 7 Mar 2010 21
Policy Framework: Participants Infrastructur Users Providers e Includes Includes • Grid users • Grid Sites Includes • VOs • Resource • Grid • Application Providers Operations Communities • Service • Security O ffj cer Providers, e.g. • Sec Operations VO running services 7 Mar 2010
Policy Components Infrastructur Users Providers e Includes Includes • AUP • Traceability Includes • Traceability • Incident • Incident • VO Response Response Management • Access control • Vulnerability • Data protection • Registration Handling • Incident • etc • Patching response • Data protection • Registration • Registration • etc • etc 7 Mar 2010
Security Policy Framework Infrastructur Users Providers e Incident Response 1 2 3 Traceability 4 5 6 Data Protection 7 8 9 etc etc etc 7 Mar 2010
Recommend
More recommend
