Comment on the draft text of site operations policy
Replies from Davidg
The new Generalized Operations Policy document has received very few comments over the past months, with the notable exception of Dorine and Peter
Of couse everyone is invited to comment (also on the comments) before it goes to wider consultation at the end of June. With this mail I'll try and - answer some of the issues raised and/or propose changes to the text - try raise awareness of the draft Policy and hope for more discussion ;-)
- General issues
Concerns raised by Dorine and Peter I think make clear that the scope of the document was ill-definedin the text. My aim of this policy was to address *both* sites that participate in EGI.eu, *as well as* any operator of a service (on a physical or virtual box, VOBox or VM image) that is hosted in a Resource Centre on behalf of "You", and acts within the EGI infrastructure. That's basically the intention behind the phrase "any Resource Centre involved", the involvement being that it is that Resource Centre that actually hosts your Service. That impact the wording of #1 and #2. Can we make that clearer in the preamble by, e.g. "By running a Service on the Infrastructure or by providing a service to the Infrastructure, either provided as an independent service or hosted in a Resource Centre, You agree to the conditions laid down in this document and other referenced documents" i.e. adding the explanatory line? In #1 and #2, the "Resource Centre involved" that obviously refers back to this line.
- [Dorine, #0]
I indeed like splitting the sentence, but the second part ("EGI security policies..." I would generalise to "Security policies may be ... from time to time. [full stop]" since also non-EGI policies can update (especially for hosted services)
- [Peter, #0 "Any resource centre involved"]
Did I address your concern above already, i.e. clarify what the involvement is?
- [Dorine, #2; Peter, #2]
Certainly sites in the UK need not comply with policies of other resource centres. It was intended to refer to hosted services. What about: "... of the Infrastructure and any Resources Centres involved in operating the Your service." ?
- [Dorine, #4]
I like your new sentence "You should follow IT security best practices especially, you shall pro-actively apply software patches and updates related to security.". as long as that gives the EGI CSIRT enough leverage to kick a site off the Infrastructure (or to kill a hosted Service by a Resource Centre) if this best practice is not followed ;-)
- [Peter, #4]
If we generalise the text as per Dorine's proposal, the issue disappears ;-) Otherwise, for hosted services the Resource Centres *do* have a role to play next to (and independent from) EGI, as as a hosting site you have your own responsibility. No third party can subsume such responsibility from a Resource Centre... In which case, given the clarification of "involved RC", I think it should stay.
- [Dorine, #5]
AFAIK, the Tracability and Logging policy describes what you must keep, and for how long. It does not limit what you can do with the logged or otherwise collected information. This line mirrors the statement in the AUP, and is needed for DPA compliance. So only once we have another policy in place that addresses the DPA issue, I think this line must stay there. In a subsequent iteration of this policy, we can maybe move it elsewhere ;-) But without this clause, data collection has no proper legal basis...
- [Peter, #6 "[you chall collect logging info] and provide them to the
Infrastructure"] However much an EGI CSIRT would like to get all logs from all sites, this is impossible. A site cannot be put under the obligation to hand over its logs, and it is contrary to privacy protection, site autonomy and legal requirements. The current "... and must assist the Infrastructure" is I think reaonsable, and the best that can be expected from sites. Logs are sensitive personal data and cannot (and should not) be given out to third parties, not even EGI ;-)
- [Peter, #7, on IPR creation by running jobs, is that security?]
Actually, generating IPR is not security, but at this point there is no other Policy document that addresses this issue. Let's keep it in here for now and - once we have an IPR Policy - move it there and scrapt it from v2 of this policy ;-)
- [Dorine, #8, on risk, loss, and damages]
It is indeed not really security (can we dump this somewhere else?) but any specific contract would override this generic clause anyway, and usually does. An contract between EGI (or a VO) and a RC would normally address these issues and supersede this disclaimer. What did you mean with "But if we keep this item, we should put "exacts" references to contract between EGI and resource providers. " ?
- [Dorine, #10]
Yes, but that's an operational procedure that I happily leave to others ;-)
Thanks again for all comments, especially Peter and Dorine, and let the discussion start!
Comments from --Dfouosso 14:03, 20 April 2011 (UTC):
0 - ( missing links to revision process).
( Proposal, change the paragraph to:) By running a Service on the Infrastructure or by providing a service to the Infrastructure, you agree to the conditions laid down in this document and other referenced policies. EGI security policies may be revised from time to time according to EGI.eu Policy development Process and EGI-SPG Term of Reference.
2 - ( NONSENSE: You shall comply with all security policies and procedures of [...] any Resources Centres involved. ) What makes that a site in UK "shall comply with " procedure of a resource center located Germany ?
( Proposal, change the paragraph to:) You shall comply with all security policies and procedures of the Infrastructure.
4- ( too specific)
( Proposal, change the first sentence to: ) You should follow IT security best practises especially, you shall pro-actively apply software patches and updates related to security.
5- ( this concerns the Tracability and Logging Policy. We could remove this section as there is a reference to this policy at the next item).
8 - The minimum security level provided and the definition of responsibilities in case of a damage should be define in the contract between the resource center and that infrastructure. Thus this seems not relevant a document that is intended to be used by everyone. But if we keep this item, we should put "exacts" references to contract between EGI and resource providers.
10- ( We should specify how this control is reglemented. )
11 - Keep.
Comments from --Peter Solagna 26 April 2011
General comment: I think that it would be useful to explain what the text means with "Any resource centre involved". Which kind of involvement are we talking about? Usage of the service?
2: I can't understand which procedures of " Resource Centres involved " this point is referring to.
4: I am confused with this text: "..or any Resource Centres involved of software patches and updates required for security.". Maybe it is a problem with my english, but I can't understand the meaning of this sentence. How a site can be involved in a software securiy activity? Is this text referring to members of SVG or CSIRT, and also members of some site's staff? If this was the meaning of the sentence, I would directly refer to the Infrastructure(EGI)and its bodies(SVG, CSIRT). Instead of "as soon as reasonably possible" I would write: "Accordingly with the security procedures that currently are in effect" (I suppose we don't wont to reference external procedures to keep the document as general as possible).)
6: I would change "..and must assist the Infrastructure " with "..and provide them to the Infrastructure"
7: Is this a security related topic?
Issues with the current site operations policy
Comments from --Ocalladw 14:03, 13 April 2011 (UTC):
3. May have security implications, but not specific
5. Logging / data protection: borderline Security Policy!
6. IPR: not security specific
7. Not security specific
9. General compliance with operational procedures
11. Dispute resolution is not security specific
Items that are too specific to sites
- General question: is the intention to remove all reference to Sites / Resource Centres and to focus on operation of services? If so, here are some comments/suggestions. --Ocalladw 13:53, 13 April 2011 (UTC)
- To adapt this directly, each service operator would need to register contact details somewhere. This could include, e.g. a VO running a web server on a cloud. Or would the responsibility remain at the hosting resource centre?
- no change
- Mentions "...mislead Users into submitting jobs or transferring data to your Site", so it's quite specific to sites (running grid middleware). This could be re-phrased as "...mislead Users into the suitability of a service for their needs"
- no change
- Mentions "Sites": substitute with "other Resource Centres, Service Operators", etc.
- Mentions "Site": rephrase to refer to "on your resources"
- Mentions "Sites": could probably be removed, as the agreement is with "the Grid" not with "other Sites"
- Replace "to your site" with "to your resources or services"
- no change
- In this, "your access" appears to refer to a site's access to the Grid
- no change
Items that are not policy but procedure
- "9. You shall comply with the Grid operational procedures including the requirement to support at least one VO designated by the Grid for the sole purpose of evaluating the availability of your Grid Services."
Perhaps this could be reduced to the first clause "9. You shall comply with the Grid operational procedures": the rest is a specific procedure related to a specific kind of infrastructure. If we want to preserve the spirit: "9. You shall comply with the Grid operational procedures, including procedures that have the purpose of evaluating the availability of your Grid Services." --Ocalladw 13:14, 13 April 2011 (UTC)
Issues to be considered for a generalized policy
- Align terminology with updated EGI glossary (e.g. "Site") --Ocalladw 13:09, 13 April 2011 (UTC)
- Replace the term the Grid with something suitably general. "Grid" suggests a link to current grid middleware and this policy should be usable by infrastructures that are not based on grid middleware. --Ocalladw 13:09, 13 April 2011 (UTC)
- Avoid use of the term "VO", which may not have meaning in other infrastructures. I suggest "User Groups" or "Groups". --Ocalladw 13:16, 13 April 2011 (UTC)
- Item 1. depends on a specific model for maintaining contacts. --Ocalladw 13:30, 13 April 2011 (UTC)
- should we consider the 'worker node part' of the pilot job framework as a service and subject to this policy? Certainly the central component is a workload management service is is subject to this--Davidg 08:17, 14 April 2011 (UTC)
- From the Pilot Job policy (#12): "The VO must make a description of the architecture, the security model and the source code of
their pilot job system available to Grid Security Operations and/or Sites on request." --Davidg 09:21, 14 April 2011 (UTC)
- Discussion may be needed on the virtualised service models to be addressed by this policy as well --Davidg 09:28, 14 April 2011 (UTC)
Original (Site Operations) Text
- You shall provide and maintain, in a central repository provided by the Grid, accurate contact information as specified in the Site Registration Policy, including but not limited to at least one Site Manager and one Site Security Contact who shall respond to enquiries in a timely fashion as defined in the Grid operational procedures.
- You shall comply with the Grid security policies, including any accounting and audit data requirements. You shall periodically assess your compliance with these policies, inform the Grid Security Officer of violations encountered in the assessment, and correct such violations forthwith.
- Before publishing information to the Grid resource information systems you shall make reasonable efforts to ensure that it is correct and up to date. You shall not publish information that could be detrimental to the operation of the Grid or mislead Users into submitting jobs or transferring data to your Site.
- When notified by the Grid of software patches and updates required for security and stability, you shall, as soon as reasonably possible in the circumstances, apply these to your systems. Other patches and updates should be applied following best practice.
- You shall use logged information, including information provided to you by Users, other Sites or by the Grid, for administrative, operational, accounting, monitoring and security purposes only. You shall apply due diligence in maintaining the confidentiality of logged information.
- Your participation in the Grid as a Site shall not create any intellectual property rights in software, information and data provided to your Site or in data generated by your Site in the processing of jobs.
- Provisioning of resources to the Grid is at your own risk. Any software provided by the Grid is provided on an as-is basis only, and subject to its own license conditions. There is no guarantee that any procedure applied by the Grid is correct or sufficient for any particular purpose. The Grid and other Sites are not liable for any loss or damage in connection with your participation in the Grid.
- You may control access by Users and VOs to your site for administrative, operational and security purposes and shall inform the Users or VOs if you limit or suspend their access. You shall comply with the Grid incident response procedures regarding the notification of security incidents and where appropriate, shall restore access as soon as reasonably possible.
- You shall comply with the Grid operational procedures including the requirement to support at least one VO designated by the Grid for the sole purpose of evaluating the availability of your Grid Services.
- The Grid may control your access to the Grid for administrative, operational and security purposes and remove your resource information from resource information systems if you fail to comply with these conditions.
- Disputes resulting from your participation in the Grid will be resolved according to the Grid escalation procedures.