Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @

Talk:SPG:Drafts:Operations Policy

From EGIWiki
Revision as of 18:34, 7 July 2011 by Dkelsey (talk | contribs)
Jump to navigation Jump to search

Comment on the draft text of site operations policy

Discussion at SPG meeting of 16 June 2011 - copied from the minutes

DG - There was quite a lot of discussion on internal draft wiki page and I tracked discussion on mailing list. Last comment by PS and all those changes were incorporated.

TF said that she included this text from point 1 in OLA and for her that is redundant. DG - We should keep it taking in account that there is procedure in place. DF – question about Resource Centre OLA TF - requirement to be certified Resource Centre, the idea is to have different OLAs and other who focus on resource providers and the OLA focusing on OS - It is important whoever provide the service to comply with this policy. It should apply to everybody, not only for resource providers. It should be explicitly said that the document apply to all parties. DK - Maybe some VO can say my VO box is not part of the infrastructure. Maybe it is worth to have sentence – all services real or virtualized. DG – It can mean that policy applies also to networks and physical buildings. We don’t want to go that far. Leave the text the way it is. DG - last sentence; add that they can be revised from time to time (agreed)

Discussion about Point 4 revised according to DJ suggestion “You should follow IT security best practices that include pro-actively applying software patches, updates or configuration changes related to security. When notified by the Infrastructure or any Resource Centers involved of software patches, updates or configuration changes required for security, you shall apply these to your services within the specified time period” (agreed)

POINT 7, 8 and 11. DK - Should these statements be somewhere else?

POINT 7 TF - This could be put under responsibilities of the OLA. We have just approved the final draft so I am reluctant to revise it again.

DK SPG can suggest that these statements (point 7 and 8) be added in the next release of the OLA.

POINT 8 This is general statement provided to everyone not only to RC. TF - Statement under Resource Centre responsibility is in the OLA.

POINT 11 DK - Just delete it, it should be in top level security policy. OS - We need clear statement and connection with Top level security policy. DG - Leave it as it is, to leave it vague and with a broader meaning and it is good to have it (agreed). TF - OMB have different escalation processes described in different documents so we should clarify what it refers to. We should have Suspension policy, it is in our plans. We need to reference to different procedures. DK - Maybe to keep it general and not to put link. TF - We have operational procedures gathered into single wiki page. That can be solution; it is just a matter of identifying referenced documents. DG - There are number of references that should be put added to the policy draft (action 03/03).

TF - What are the obligation of the suspended sites? It is general problem for existing procedures and policies. DG - How many other policies suffer from the same issue? TF - We said in the OLA that is not binding during suspension. DG - At this point I would not bother. TF - Then site which is not part of the infrastructure can decide not to comply with policies MM - Do we have a procedure for RPs to leave the infrastructure for whatever reason? If site is suspended he is still part of infrastructure and policies should apply. TF - We have procedure for RP to be decommissioned. When you leave there is no reason for doubt. DK – When RCs are leaving, they need to leave traceability and logging information. TF - For suspension which is temporary it is not clear for me. Maybe to make clear that suspended sites will stay part of infrastructure. DK - We don’t mentioned suspension here. DG - point 4, 5 and 6 of the draft remain in effect even after you have left infrastructure, maybe to add sentence at the end. DK - I think it is better to address this in some other document, there are advantages to keep it vague. TF - Stick to the plan in having a suspension policy, it should be clarified than. Maybe we can have interim solution. TF suggestion: Policies are also applicable to service providers that are temporarily suspended. DK - Adding a sentence to introduction.

Replies to feedback received before 16 June 2011 from Davidg

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