This page contains answers to frequently asked questions that you may encounter as your organisation considers becoming Sirtfi compliant. Content will be updated as Sirtfi adoption continues. Technical FAQs on the Sirtfi framework are available on the Wiki.
Q: What are the benefits of joining the Sirtfi trust network?
A: By expressing compliance with Sirtfi, your organisation can increase the level of trust it holds within the community. By improving this trust, other organisations will be more likely to grant access or permit authentication. The key benefit of becoming Sirtfi compliant is the ability to collaborate effectively with other Sirtfi compliant organisations, in the event of a federated security incident. See the Sirtfi Brochure for further information.
Q: Why are both Service Providers and Identity Providers encouraged to join?
A: Typically, assurance frameworks contain normative statements concerning identification, credential management, and authentication. This assurance framework is not addressing identity assurance, but rather security assurance. Sirtfi brings a guarantee that an entity supports a baseline of operational security and will be able and willing to collaborate in incident response. Any participant within the framework is able to initiate incident response, or respond to a call for incident response. For incident response to be successful in a federated environment, all entities must participate.
Q: How do I join the Sirtfi trust community?
A: Details can be found in the Guide for Federation Participants on the Sirtfi Technical Wiki
Q: Sirtfi seems pretty vague on precisely what I need to do, and how I should do it. Why is that?
A: Sirtfi version 1.0 has set an intentionally low bar; it primarily serves to develop the trust relationships needed for incident response rather than to strengthen existing cybersecurity risk postures. It is expected that most organisations are able to comply with Sirtfi quickly and easily. The precise measures and changes required at an organisation are left to the determination of the organisation itself.
Q: Must all of my systems satisfy the Sirtfi requirements in order for my organisation to assert Sirtfi compliance?
A: No. As discussed in the framework: “How comprehensively or thoroughly each asserted capability should be implemented across an organisation’s information system assets is not specified. The investment in mitigating a risk should be commensurate with the degree of its potential impact and the likelihood of its occurrence, and this determination can only be made within each organization”. This is applicable to all Sirtfi assertions. Some believe that critical components that directly interact with identity federation, such as IdPs, SPs, AAs, OPs, RPs and any secondary credential management systems should be explicitly in scope. This may be a reasonable proposition to consider when the Sirtfi Trust Framework is next revised.
Q: Can one organisation assert Sirtfi compliance for another organisation’s entity?
A: Yes, providing certain conditions are met. An organisation may assert Sirtfi on behalf of a separate entity, such as the hub of a hub-and-spoke federation on behalf of its members, providing that existing policies between the parties are equal to or more restrictive than Sirtfi. Similarly, a security contact for an entity may be provided at an separate organisation, provided that they will abide by Sirtfi requirements on behalf of the entity.
Q: Who can I ask for help?
A: Your Federation Operator will be able to guide you or, if required, redirect you to appropriate individuals within REFEDS.
Q: What happens if an organisation fails to comply with the Sirtfi trust framework in the event of a federated incident?
A: If an organisation can no longer comply, they must stop asserting their compliance with the Sirtfi trust framework.
Q: Are there any requirements for data protection?
A: No data protection requirements are stipulated within the Sirtfi framework. An organisation should analyse their own risk profile in terms of personal data and take corresponding precautions.
Q: Are there any requirements for the assurance of users’ identities? For example, is there a security requirement for all accounts be linked to identifiable individuals?
A: No. Sirtfi is a trust framework for security incident response. Other trust frameworks may address authentication, attributes, or other aspects of achieving overall trust in federated transactions. This particular requirement contributes to the definition of the Level of Assurance (LoA) of an IdP. Requirements for LoA have not been included in the Sirtfi trust framework although there is a certain overlap. There is ongoing work in the AARC project to provide guidelines on a baseline level of assurance https://aarc-project.eu/workpackages/policy-harmonisation/
Q: I am a federation operator, where can I find further information to support Sirtfi adoption within my federation?
A: Details can be found in the Guide for Federation Operators on the Sirtfi Technical Wiki
Q: Who should I choose as my Sirtfi security contact?
A: See https://wiki.refeds.org/display/SIRTFI/Choosing+a+Sirtfi+Contact
Q: How is Sirtfi-compliance assessed?
A: Entities are encouraged to complete a self-assessment of their organisation against the requirements of the Sirtfi framework, without the need for external review. A successful self-assessment is sufficient for an organisation to be able to assert the Sirtfi assurance entity attribute in their entity’s metadata. Self-assessment is a minimum requirement. Entities are welcome to exceed that requirement.
Q: Can I assert Sirtfi if I am running a proxy?
A: Some IdPs and SPs act as proxies to others. For example, a group of Service Providers may be accessed through a single Service Provider Proxy which is registered in an identity federation. Vice versa, an IdP Proxy may issue authentication tokens that may have originated from multiple other Identity Providers.
You are still encouraged to perform a self-assessment of your proxy – consider each statement in the context of what your proxy is enabling. For example, [TR1] requires logs to be kept to enable traceability, a Service Provider Proxy should ensure that downstream services are recording such logs. [OS5] requires that users can be contacted, if an Identity Provider Proxy collects and verifies such information then it is able to satisfy the requirement. If your proxy passes such a self-assessment of the Sirtfi Framework, you are able to assert Sirtfi.