Talk:SPG:Drafts:Operations Policy

From EGIWiki
Revision as of 18:28, 7 July 2011 by Dkelsey (talk | contribs) (Move all comments and background info to the discussion page - reinstated from 16th June.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Comment on the draft text of site operations policy

Replies from Davidg

Dear all,

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, *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

  • [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

  • [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
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!

Cheers, DavidG.

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 Policy development Process and EGI-SPG Term of Reference.

1- Keep.

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.

3- Keep.

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).

6- Keep.

7- Keep.

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.

9- Keep.

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

Items that are not related to security

Comments from --Ocalladw 14:03, 13 April 2011 (UTC):

1. Keep!

2. Keep!

3. May have security implications, but not specific

4. Keep!

5. Logging / data protection: borderline Security Policy!

6. IPR: not security specific

7. Not security specific

8. Keep!

9. General compliance with operational procedures

10. Keep!

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)
    1. 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?
    2. no change
    3. 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"
    4. no change
    5. Mentions "Sites": substitute with "other Resource Centres, Service Operators", etc.
    6. Mentions "Site": rephrase to refer to "on your resources"
    7. Mentions "Sites": could probably be removed, as the agreement is with "the Grid" not with "other Sites"
    8. Replace "to your site" with "to your resources or services"
    9. no change
    10. In this, "your access" appears to refer to a site's access to the Grid
    11. 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  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.
  10. 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.
  11. Disputes resulting from your participation in the Grid will be resolved according to the Grid escalation procedures.