Talk:Security Incident Response Policy
From JSPGwiki
| Table of contents |
14 Apr 2009 Comments
I think it's essential to include as the first item: "You shall promptly report security incidents to your local organization's incident response team." Local incident response takes precedence over Grid incident response. --Jim Basney
-->Done. --Romain 13:46, 15 Apr 2009 (BST)
I think we should say "incident response teams" rather than CERTs (i.e., not use an acronym without defining it). --Jim Basney
--> Done. --Romain 13:46, 15 Apr 2009 (BST)
Promptly reporting security incidents is already required by the Grid Acceptable Use Policy. Do we also need it here? Perhaps we should add a reference to the Grid AUP here to acknowledge the redundancy. --Jim Basney
--> Why not, but I am not quite sure how to adapt the phrasing. The Grid AUP is aimed at users, while this document also includes site administrators, etc. Any proposition for appropriate phrasing would be great! --Romain 14:02, 16 Apr 2009 (BST)
Both #1 and #2 require using "incident response channels defined by the Grid." This appears redundant. I propose changing #2 to: "You shall follow the incident response procedure defined by the Grid." The procedure will include the "channels". Note that OSG does not prescribe an incident response procedure for VOs and sites, so it's not clear how this would apply to OSG. --Jim Basney
--> Done. With regards to OSG, the current procedure (https://twiki.grid.iu.edu/bin/view/Security/IncidentDiscoveryReporting) may indeed need to be expanded as this policy is reduced. There is also the OSG incident response guide (http://osg-docdb.opensciencegrid.org/0000/000019/002/OSG_incident_handling_v1.0.pdf) that has both policy and procedure-relevant items. --Romain 14:02, 16 Apr 2009 (BST)
Item #3 appears overly verbose. I think the list of "third party organizations, other grid participants..." basically includes anyone. I suggest: "You shall promptly respond to and investigate incident reports regarding resources, services, or identities for which you are responsible." Not sure if we want to more precisely define "promptly" such as "within one business day". If we remove "grid incident coordinator appointed by the Grid for each incident" from #3, we should add it in #6 so the "incident coordinator" term is defined. --Jim Basney
--> Done. May be defining "within one business day" as a requirement is rather something to be left for the procedure? --Romain 14:02, 16 Apr 2009 (BST)
What is the difference between "local sanity checks" and "appropriate investigations and forensics" in #3 and #4? Does a "local sanity check" determine if an incident has occurred, whereas "investigations and forensics" provide details about a confirmed incident? --Jim Basney
--> I suspect this we could workaround this issue by simply removing "local sanity check" as you proposed. think "appropriate investigations and forensics" is sufficient. --Romain 14:02, 16 Apr 2009 (BST)
In #4, if the goal is to prevent re-occurrence, who should the investigation/forensics information be shared with? Should we require a "close-out report" (as required by the old policy)? --Jim Basney
--> There is indeed an implicit assumption that this will be dealt with by the procedure. The new policy does not define the incident response channels as the old policy did, so it is difficult to identify who would receive the "close-out report". --Romain 14:02, 16 Apr 2009 (BST)
Maintaining "grid security contact" information (#5) is covered by the VO and Site registration policies. Is this redundant? Should we refer to those policies here? --Jim Basney
--> Done. (Some reference number for JSPG policies would make referencing much easier.) --Romain 14:02, 16 Apr 2009 (BST)
Can we combine #6 and #7 which both address information disclosure? --Jim Basney
--> Done. --Romain 14:02, 16 Apr 2009 (BST)
The policy doesn't address how incident response is coordinated across sites and grids. Perhaps we could add more details about what the "grid incident coordinator" does? The participant is obliged to report to "incident response channels defined by the Grid" -- does that mean all Grid participants or Grid security contacts or only the Grid Security Officer or Grid Security Operations? Is the Grid Security Officer obliged to share incident information with other members of the Grid and/or with other grids? --Jim Basney
For example, in my opinion a very practical policy statement to facilitate cross-grid coordination would be: "The Grid shall assign a unique tracking number to each incident, which should be considered public information and hence should not disclose sensitive information such as the names of hosts or domains involved or indicate the number, nature, or scope of events reported." (Inspired by http://www.cert.org/archive/pdf/csirt-handbook.pdf). --Jim Basney
--> I have added an new bullet where we could try to include this point. --Romain 14:02, 16 Apr 2009 (BST)
May 14 2009 JSPG Meeting Notes
Aim of this policy is to establish trust between grids for incident response coordination.
Question about the target audience for this policy. Is "grid participant" correct?
- The Grid Acceptable Use Policy specifies what users should do. They won't read this policy separately.
- It is aimed at resource providers? service administrators?
Discussion of the definition of security incident. You must also report suspected security incidents.
We made edits according to the discussion between Jim and Romain above.
We dropped the part about minimizing the impact of incidents, and we should bring it back in a footnote.
Need to add a footnote to point the user to the Grid AUP.
We agree that this draft is now complete and ready for wider consultation.
In Jim's opinion, this policy is compatible with OSG policies and procedures.
In Romain's opinion, this policy is compatible with EGEE policies and procedures.
--Jim Basney 14 May 2009
Related grid incident response procedures
- EGEE (https://edms.cern.ch/document/867454)
- OSG (https://twiki.grid.iu.edu/bin/view/Security/IncidentResponseProcess)
- TeraGrid (http://www.teragridforum.org/mediawiki/index.php?title=TeraGrid_Security_Playbook)
Feedback received on version 3.1, 15 May 2009
Andrew Sansum (RAL): I'd expect a policy statement to address matters like: EGEE policy is that all incidents are investigated as fully as possible; wherever possible events are followed up with external organisations and action taken; that sites promptly report intrusions via the ...; that security incidents are treated as serious matters and their investigation resourced appropriatly; that failure to comply with [the implementation] may lead to a site being suspended from the Grid ... I guess the bullets sort of address some of this but they seem more like practice rather than policy to me.
Romain Wartel: I like the phrasing from Andrew. Propose to add: "The objective of this policy is to ensure that all incidents are investigated as fully as possible and that sites promptly report intrusions. In particular, security incidents are to be treated as serious matters and their investigation must be resourced appropriately." as an introduction to the list of bullets.
Fotis Georgatos (CSCS, Switzerland): On the wiki page, its reported title, date and version should always agree with the document itself: > https://edms.cern.ch/document/428035/4. Please fix, and ensure that the next version also complies with this req. (otherwise it takes some effort to ensure we are up-to-date with current).
David Kelsey (RAL, JSPG chair) reply to this: I assume you are complaining about the old (still current) policy. I agree that the actual document has "LCG/EGEE" in the title and doesn't mention "security", while EDMS says "Grid", but this has been like this for a long time and I don't want to change the old document now. I agree that in future it should all be consistent (as it is for the new version of this document). There are several ways to tell which policy is currently adopted.
- The Status is set to RELEASED in EDMS.
- Go to links "download current" on http://proj-lcg-security.web.cern.ch/proj-lcg-security/documents.html
- consult http://osct.web.cern.ch/osct/policies.html for EGEE currently adopted policies
--David kelsey 19:32, 18 Jun 2009 (BST)
Used by Committee on Institutional Cooperation (USA)
The JSPG Security Incident Response Policy (version 3.2) was used as input for the draft Federated Identity Management Incident Response Policy developed in the CIC (http://www.cic.net) Identity Management Working Group.
--Jim Basney 15:53, 14 Dec 2009 (GMT)
