You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

This list of Frequently Asked Questions is provided to complement the information contained in the Sirtfi Trust Framework Document.

General Questions

General questions are listed on the public facing site: https://refeds.org/sirtfi/sirtfi-faqs 

 

Questions on Sirtfi Assertions

Operational Security [OS]

  • [OS1] Security patches in operating system and application software are applied in a timely manner.

Q: Does this imply that only supported software, for which patches are actively supplied, should be used?

A: Many federated services within research and education rely on custom applications and development due to their age and complexity. Stipulating that only supported software be used may pose unnecessary obstacles for organisations joining the Sirtfi trust framework. OS2 implies that any software deployed by an organisation, custom or otherwise, must be actively maintained in the event that a vulnerability is identified.  

  • [OS2] A process is used to manage vulnerabilities in software operated by the organisation.
  • [OS3] Mechanisms are deployed to detect possible intrusions and protect information systems from significant and immediate threats
  • [OS4] A user’s access rights can be suspended, modified or terminated in a timely manner.

Q: What is a “timely manner”?

A: The definition of appropriate timescales will vary per organisation based on maturity of the services and resource availability. response time should be commensurate with the scale of the incident. 

  • [OS5] Users and Service Owners (as defined by ITIL [ITIL]) within the organisation can be contacted.

Q: What is ITIL?

A: ITIL is a standardised glossary of definitions used within the IT community. It is referenced here to limit redefinition of accepted terms. https://www.axelos.com/Corporate/media/Files/Glossaries/ITIL_2011_Glossary_GB-v1-0.pdf

  • [OS6] A security incident response capability exists within the organisation with sufficient authority to mitigate, contain the spread of, and remediate the effects of a security incident.

Q: Does this security incident response capability need to be documented?

A: Ideally this capability should be documented in the form of policies and procedures. For large organisations there is the expectation that a formalised capability exists. For smaller organisations it is possible that this capability is less formal and may simply be the availability of an individual to handle such incidents. The level of documentation available should be commensurate with the scale of the organisation and services.


Q: Should organisations have equivalent agreements with their subcontractors to ensure an incident response capability exists?

A: Best practice indicates that contracts with subcontractors should cover incident response. These contracts are out of scope in a federated context for the purposes of this framework. The Sirtfi trust framework could be used as a starting point for such contractual agreements.

Incident Response [IR]

  • [IR1] Provide security incident response contact information as may be requested by an R&E federation to which your organization belongs.
  • [IR2] Respond to requests for assistance with a security incident from other organisations participating in the Sirtfi trust framework in a timely manner.
  • [IR3] Be able and willing to collaborate in the management of a security incident with affected organisations that participate in the Sirtfi trust framework.
  • [IR4] Follow security incident response procedures established for the organisation.
  • [IR5] Respect user privacy as determined by the organisations policies or legal counsel.
  • [IR6] Respect and use the Traffic Light Protocol [TLP] information disclosure policy.

Q: Will I need to use the TLP for all communication once I have agreed to Sirtfi?

A: No, the TLP should be used for communication regarding federated incidents but there is no stipulation for other communication. Information is widely available, e.g. https://en.wikipedia.org/wiki/Traffic_Light_Protocol

Traceability [TR]                                                                       

  • [TR1] Relevant system generated information, including accurate timestamps and identifiers of system components and actors, are retained and available for use in security incident response procedures.
  • [TR2] Information attested to in [TR1] is retained in conformance with the organisation’s security incident response policy or practices.

Participant Responsibilities [PR]

  • [PR1] The participant has an Acceptable Use Policy (AUP).

Q: Does this AUP need to be specific for identity federation?

A: No, as long as all activity conducted at entities within the federation is covered by an AUP.

  • [PR2] There is a process to ensure that all users are aware of and accept the requirement to abide by the AUP, for example during a registration or renewal process. 

 

  • No labels