This FAQ provides information about SIRTFI (Security Incident Response Trust Framework for Federated Identity): what it is, why it is important, and how you can participate.
SIRTFI Proof of Concept Participation
InCommon is conducting a proof of concept for SIRTFI. At this point, we are offering participation to campuses with researchers that use services provided by CERN. If you have been contacted by InCommon offering participation in the proof of concept, and you wish to participate, please do the following:
The InCommon Executive from your organization should send an email to Kevin Morooney, Internet2 Vice President for Trust and Identity (firstname.lastname@example.org, and Ann West (email@example.com), Associate Vice President for Trust and Identity, agreeing to the points listed below:
- <Organization> affirms that <Organization> supports the SIRTFI Framework requirements and will continue to support the framework as it evolves. InCommon has not verified that our deployments adhere to the specification.
- <Organization> takes full responsibility for the use of this tag in our production and pilot deployments.
- <Organization> acknowledges that InCommon is not supporting the SIRTFI tag from a policy and process point of view and will not be providing change management communications other than required metadata changes. InCommon will fully support SIRTFI according to the specifications once the complete document set is finalized, InCommon has the resources and time to do so, and the community finds enough value.
Point number 3 reflects that the SIRTFI specification is still under development by REFEDS, and that this is still a proof of concept for InCommon.
InCommon staff will then update your organization's security contact type to the new REFEDS type, and place the SIRTFI entity attribute in the metadata of your Identity Provider. Your InCommon Site Administrator must then approve the publication of new Identity Provider metadata containing this change.
What is SIRTFI?
SIRTFI (Security Incident Response Trust Framework for Federated Identity) provides a framework for effective incident response collaboration among federation and interfederation participants. One compromised account can create a security problem for a multitude of services across the interfederation community. When an organization complies with the SIRTFI framework, it agrees to participate in a federated incident response process.
Why is InCommon Conducting this Proof of Concept?
This is the first step toward supporting a global incident response system for research and education trust federations. With ever-increasing and evolving cybersecurity threats, and our increasing interconnectedness through eduGAIN, federation participants need a way to quickly collaborate in the face of a security incident. One compromised account at an institution can provide access to a multitude of services around the world. SIRTFI provides a framework for an effective response in the event of an incident that may involve federated identities.
SIRTFI stipulates high-level practices and procedures, and identifies organizations that are capable of participating in a federated incident handling process. Federation participants that comply with SIRTFI are marked in the federation’s metadata, raising the bar for operational security across federations.
What does it mean to be compliant with SIRTFI?
REFEDS, an organization of federation operators and participants from around the world, has published the SIRTFI framework, which specifies a set of assertions that comprises SIRTFI compliance. The assertions are divided into four areas: operational security, incident response, traceability, and participant responsibilities. Details are available on the REFEDS website (PDF). An organization agrees to abide by these assertions, which is demonstrated by the relevant Identity Provider or Service Provider metadata carrying the SIRTFI assurance entity attribute, and updating its security contact with the new REFEDS security contact type. (Please note that, at the current time, this is different than the InCommon security contact that you may already have in your metadata, but is directly based on the InCommon contact type. InCommon plans to migrate to the REFEDS security contact type as a separate process from this SIRTFI pilot).
Technically, what do I do to assert SIRTFI compliance?
REFEDS has published a "Guide for Federation Participants," which contains a simple recipe for asserting SIRTFI compliance. The two technical steps (outlined in the REFEDS guide) are adding a REFEDS Security Contact and adding the SIRTFI compliance assertion to your metadata. These are both currently handled by the process documented in the "How do I participate" topic, above.
What's the next step after the proof of concept?
InCommon operations and the proof of concept participants will evaluate the proof of concept after gaining some experience (we don't have a specific timeline). However, we anticipate that, after the proof of concept, we will encourage all InCommon participants to adopt the SIRTFI framework.
Why do this now?
InCommon is expanding the proof of concept because some international organizations have begun to require SIRTFI compliance for access to at least some of their services. This is intended to help a small set of identity providers continue uninterrupted access for their researchers, faculty, and others.