1 / 12

LCG Security Coordination

LCG Security Coordination. Ian Neilson LCG Security Officer Grid Deployment Group CERN. Security Coordination Objectives. LCG Grid Deployment Board (GDB) meeting in July 2004 - Discover/own/chase/fix security incidents Liaise with national/institute CERTs

jayme
Download Presentation

LCG Security Coordination

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. LCG Security Coordination Ian Neilson LCG Security Officer Grid Deployment Group CERN EGEE ARM-2 – 5 Oct 2004 - 1

  2. Security Coordination Objectives • LCG Grid Deployment Board (GDB) meeting in July 2004 - • Discover/own/chase/fix security incidents • Liaise with national/institute CERTs • Install/run appropriate monitoring/intrusion detection • Ensure known problems are patched or worked around • Analyse audit logs • Perform security LCG Service Challenges • Ownership of … • Security incidents • From notification to resolution • Liaise with national/institute CERTs • Middleware security problems • Liaise with development & deployment groups • Co-ordination of security monitoring • Post-mortem analysis • Access to team of experts EGEE ARM-2 – 5 Oct 2004 - 2

  3. Security Activities in EGEE Security Activities in EGEE From Dave Kelsey’s CHEP’04 Plenary Talk CA Coordination NA4 NA4 NA4 NA4 Solutions/Recommendations Req. JRA3 JRA1 Req. Req. Req. Middleware Security Group LCG/EGEE Joint Security Group Req. “Joint Security Group” defines policy and procedures For LCG/GDB and EGEE/SA1 (Cross Membership of OSG) Req. SA1 EGEE ARM-2 – 5 Oct 2004 - 3

  4. OSG - Security Incident Handling and Response Guide (draft) • To guide the development and maintenance of a common capability for handling and response to cyber security incidents on Grids. • The capability will be established through • (1) common policies and processes, • (2) common organizational structures, • (3) cross-organizational relationships, • (4) common communications methods, and • (5) a modicum of centrally-provided services and processes. EGEE ARM-2 – 5 Oct 2004 - 4

  5. GOC Guides Policy – the Joint Security Group Incident Response Certification Authorities Audit Requirements Usage Rules Security & Availability Policy (1) Common policies and processes Application Development & Network Admin Guide User Registration http://cern.ch/proj-lcg-security/documents.html EGEE ARM-2 – 5 Oct 2004 - 5

  6. Security Coordination - Groups • Parties from OSG IR • Security Operations Centre(s) (=?GOCs/CICs) • Organize, coordinate, track, report • Security contacts • Defined for every grid participant: users and resources • Incident Response & Technical Experts • Managed list of available expertise • Ad hoc Incident Response teams • Formed on demand • Security Operations Advisory group • Advise development and practice of SOC (=JSG+?) • X-SOC coordination • SOCs participation/communication across grid boundaries (2) common organizational structures EGEE ARM-2 – 5 Oct 2004 - 6

  7. CSIRT Media/Press “PR” CIC/GOC “External” GRID OSCT RC ROC Security Coordination - Channels EGEE operational channels still being established. Responsibilities and processes being defined. (3) cross-organizational relationships, EGEE ARM-2 – 5 Oct 2004 - 7

  8. Security Coordination – Comms. • Incident Reporting List • INCIDENT-SEC-L@xxx.yyy • Security Contacts Discussion List • INCIDENT-DISCUSS@xxx.yyy • External contact • Reporting • Other grids • MUST be Encrypted • How is this achieved and managed? • Tracking system • MUST be secure • Press and Public Relations (4) common communications methods ?INCIDENT-SEC-L@lcg.org → postmaster@living_church_of_god.org EGEE ARM-2 – 5 Oct 2004 - 8

  9. Operational Security - Services • List Management • Alert/Discuss – ref: previous slide • Multiple ad-hoc IR Teams • Experts • Ticket Tracking System • Where do problems enter? – local contact • Can this be part of support lists? • Must be secure • Public Relations • Securely accessible evidence repository • Guidelines, practice statements • Policy interface to JSG • OSCT must (help) define process behind all these services (5) a modicum of centrally-provided services and processes EGEE ARM-2 – 5 Oct 2004 - 9

  10. Security Coordination - Issues • “Security Operations Centre”: what is it for EGEE/LCG? • Don’t think we can have “Central” control • So formulate activity as “coordination team” • Security contacts lists need management • Dead boxes, moderated boxes, etc etc • Do we have appropriate contact: site security or local admin? • Need to coordinate through Regional Operations Centres (ROC) • Need to utilise services from Core Infrastructure Centres (CIC) • Wherever possible - don’t duplicate channels • What is the relationships with LCG GOCs and EGEE CICs? • Are they the same? • Are we communicating with local site security team or grid ‘admin’ responsibles EGEE ARM-2 – 5 Oct 2004 - 10

  11. Operational Security – where to start? • “Start small and keep it simple.” • Define basic structures • Where/how lists hosted • Where/how problems tracked • Who/where/how ‘experts’ organised • JSG review and update policy documents • ROCs to take over management of contacts lists • Must integrate with site registration process • Establish what level of support is behind site security entries • Relationships with local/national C • Validate/test entries • Exercise channels and raise awareness by Security Challenges – next slide. EGEE ARM-2 – 5 Oct 2004 - 11

  12. 2004 Security Service Challenges • Objectives • Evaluate the effectiveness of current procedures by simulating a small and well defined set of security incidents. • Use the experiences of a) in an iterative fashion (during the challenges) to update procedures. • Formalise the understanding gained in a) & b) in updated incident response procedures. • Provide feedback to middleware development and testing activities to inform the process of building security test components. • Exercise response procedures in controlled manner • Non-intrusive • Compute resource usage trace to owner • Run a job to send an email • Storage resource trace to owner • Run a job to store a file • Disruptive • Disrupt a service and map the effects on the service and grid EGEE ARM-2 – 5 Oct 2004 - 12

More Related