Overview

This consultation has completed. 

Participants are invited to:

Following the consultation all comments will be taken back to the SIRFTI working group for review and if appropriate the paper will then be forwarded to the REFEDS Steering Committee for sign-off and publication on the REFEDS website as per the REFEDS participants agreement.  At this stage the SIRTFI Working Group may also begin the process of taking the paper forward as an Internet Draft and towards an RFC.

The PDF for the consultation is available as an attachment to this page.  Background on the SIRTFI Working Group is available.  All comments should be made on: consultations@lists.refeds.org. 

Change Log

Change Log for the Consultation on the SIRTFI Consultation. The consultation opens on Tuesday 3rd November 2015 and closes on Tuesday 8th December 2015 at 5pm CET.  Please fill in your comments and change requests below. Line numbers are available in the document for ease of reference.

Number
Current Text / Reference
Proposed Text / Query
Proposer
Action
1line:  (Leave Blank)

Other Comments / Observations

 

  • No labels

11 Comments

  1. Thomas Lenggenhager

    All the wording is vague enough to not raise too many eyebrows.

    For small institutions the requirement of 'A security incident response capability exists' is probably  the most difficult one. They may just have a security contact.

    I wondered whether '[PR1] The participant has an Acceptable Use Policy (AUP)' expects a specific AUP for identity federation or whether a general AUP for all the local users is sufficient. The latter is realistic, the former would not be realistic.

    1. Hannah Short

      Hi Thomas, 

      Following discussions with the sirtfi authors, we have decided not to change the wording for this point. Any AUP which covers federated access is enough. For example, this could be a federation specific AUP within an organisation, or a policies federation-wide policy.

      We will not be changing the wording but we will create an FAQ page within REFEDS and include this question.  

       

  2. Eefje van der Harst

    Excellent work so far! A few remarks/ questions on behalf of SURFnet:

    • Line 90, OS1: does this also apply to 'appropriate security measures should be implemented that fit the risk profile associated with the data that is processed' or is it worthwhile to make this a separate item in the list? Same goes for upgrades to new standards and protocols in a timely manner? Or is the latter covered sufficiently in OS2?
    • Line 96, OS4: should we define in this document that only real users that are identified appropriately, can have access rights? (so no test/admin accounts) Or is this too specific?
    • Line 100, OS6: does 'a security incident response capability' also cover policy & processes?
    • In general: should we define that participants and fed operators should have the appropriate clauses in their contractual agreements with (sub)-contractors to ensure adequate security incident response?

    1. Hannah Short

      Hi Eefje, 

      Thanks for this! We had some long discussions, to answer your points. We do not plan to change the text regarding these comments, please get back to us if the reasoning below is insufficient. 

      • This seems to be going down the data protection and privacy route. We think this point falls better into a different policy (data protection) as it extends the scope of sirtfi beyond the basics of security response. We do not want to be too prescriptive in terms of software upgrades so OS2 should be sufficient to cover the required security related enhancements. Anything not security focussed would not be relevant within the context of sirtfi.
      • We felt that having identified, individual users falls under Level of Assurance (LoA) rather than security response. This is something that is being worked on within AARC. We have discussed including Sirtfi as part of LoA but not the other way around since LoA is broader.
      • In some cases, at smaller or younger organisations, a "security team" may not be sufficiently mature to have a documented process, e.g. it might be a single person working on security. We do not want to exclude these entities by default. This should be included in the FAQ section we are planning to add to the REFEDS wiki. 
      • This point seems too specific for sirtfi; we do not want to prescribe or assume that participants have contractual agreements. The paragraph at line 82 gives a general stance towards this and related concerns.

  3. Ian Young

    I'm curious as to whether OS1, which talks about applying patches, is also supposed to imply that only supported software (for which patches are actually supplied) is to be used, or whether that would be somehow implied by OS2 instead. Getting a pass on OS1 by running software so old that patches are no longer being supplied would otherwise seem to be an undesirable consequence.

    1. Hannah Short

      Hi Ian, 

      Following discussions with the sirtfi authors, we have agreed not to change the wording here. Thank you for your comment anyway, it generated a lot of discussion. Neither OS1 nor OS2 are supposed to imply that only "supported" software is used. Many research organisations have custom software for which patches are not available; we do not want to prescribe that software must be supported. Patches should be implemented where possible and there should be a vulnerability management process. The software and vulnerability patching process should be commensurate with the risk profile of the organisation; there may be instances (e.g. remote hardware) where implementing patches is not achievable. OS1 and OS2 have slightly different scopes, OS1 could be viewed as the proactive and OS2 as reactive, and we felt that having both brought value.

      I hope this answered your question - get in touch if not!  

  4. Alex Stuart

    The audience section includes SP and IdP operators and Federation Operators, but operators of standalone Attribute Authorities are not explicitly included.

    1. Hannah Short

      Hi Alex, 

      Thanks for your comment. We have agreed to change the "Audience" wording to include Attribute Authorities and to leave it generic enough for any future entities to be within scope. The change will appear in Sirtfi v 1.0.
       

  5. Hannah Short

    Thank you for your comments - the working group will discuss them all on Monday and come back to you with changes/answers for each of them.

  6. Hannah Short

    We had further comments offline from Mihály Héder. 

    •  The perception of ITIL terminology is not undividedly positive. It is better not to evoke ITIL, thus alienate those who are hostile towards it just for the sake of reusing two definitions of it.

      The sirtfi authors felt that it is good practice to reuse an external glossary, rather than redefine the terms, regardless of some user dissatisfaction. We will not change this text though will consider changing it in version 2.0 if feedback is recurring.
       
    •  Respect and use the Traffic Light Protocol information disclosure policy.
      This is very abstract and discouraging at the same time. It does not say much, still very specific. TLP is far from a well-known scheme. There are surely many organizations that does not disclose information unnecessarily but they just not use TLP as such.

      Taking wider opinion into consideration, TLP seems to be very well used globally. We see value in specifying a specific protocol and will not change the text at this stage.  

     


  7. FRÉDÉRIC MALENGREAU

    I am new to SIRTFI and am trying to see if we are SIRTFI compliant.

    My first question is : do the OS assertions concerne the whole infrastructure or only the identity-related servers?

    Sorry if the question is too simple...