Cliquez ici pour la version française

SIRTFI : A trust framework for federations

1. Why SIRTFI ?

The growth and inter-connection of federations through eduGAIN has created a new vector of attack. One compromised account can provide access to a multitude of services across the inter-federation community.

This occurs in a context where the quality of operational security at organisations is variable and often unknown to other participants. There is typically no minimum level of security to join a federation. Consequently, there is no guarantee of effective collaboration between organisations in the event of a federated incident.

The SIRTFI framework (Security Incident Response Trust Framework for Federated Identity) adress this issue. It provides a mechanism to identify trusted, operationally secure eduGAIN participants and facilitate effective incident response collaboration.

SIRTFI is an initiative of the REFEDS SIRTFI working group (Research and Education FEDerations group) : https://refeds.org/sirtfi

2. The SIRTFI framework in a nutshell

The SIRTFI framework defines a set of security rules and best practises, structured around the four following fields : operational security, incident response, traceability and participant responsabilities

The table below details in a synthetic view each field covered by the framework :

Security Field Description
Operational Security [OS] - Regular patches
- Processes for vulnerability management
- Intrusion detection and information protection
- Possibility of timely user rights changes
- Established contacts for service owners and users
- Security Incident Response
Incident response [IR] - Security incident response contact information
- Timely reply to other SIRTFI members
- Collaborate in management of security incidents
- Respect security incident response procedures of own organisation
- Respect user privacy
- Respect Traffic Light Protocol (Traffic Light Protocol)
Traceability [TR] - Keep accurate logs of all relevant information available for handling security incidents
Participant Responsabilities [PR] - Acceptable use policy (AUP)
- User consent to AUP

3. Expressing SIRTFI compliance : step-by-step guide

The following chapter describes the steps to follow by an organization in order to express a SIRTFI compliance.

Step 1 - Organization self assessment

The first step for an organization consists in completing a self assessment following the SIRTFI Framework (see previous chapter).

Your organisation is SIRTFI compliant if you are able to agree with each and every statement included in the framework

In the case where the assessment is positive, then the organisation can declare this compliance for each of the federated resources (IdP or SP) it owns. This operation is performed through the Federation registry.

Step 2 - Declaring SIRTFI compliance (Federation registry)

This operation is performed through the Federation registry, from the editing page of the involved resource (IDP or SP). Under the “contatcs” tab, you only have to tick the dedicated box in order to attest this ressource is compliant.

Warning : by ticking the box “I certify that this SAML entity complies with the SIRTFI requirements”, you agree to comply with each and every statements of the SIRTFI framework.

After ticking the box, then you have to define a security contact for this resource (the fields security contact name and emails , grayed so far, become writable)

Step 3 - Choosing a Security contact (Federation registry)

The security contact will be the initial point of contact during a federated incident involving this resource.

The security contact of a resource should be an individual or group who has agreed to perform the incident response obligations of the Sirtfi Framework on behalf of the entity.

Step 4 – Submitting changes (Federation registry)

Submitting the form with the above changes on the Federation registry results in adding two SIRTFI extensions (SIRTFI entity attribute et Security Contact) in the metadata of your resource.

A example of these two SIRTFI metadata extensions is given in chapter 6.

4. Daily use of SIRTFI

For a compliant organization , the use of SIRTFI on a daily basis will mainly consist of the following tasks :

1. Collaborating to the security incident response process :

  • In the event of an incident involving a federated entity or user, contact the relevant security contact listed in metadata ;
  • If you are contacted for help in an external incident, you are obliged to respond and actively collaborate with other Sirtfi compliant entities.

2. The possibility if you are in charge of an SP, to restrict authentication to only those IdPs who are also trusted (i.e SIRTFI compliant) with the implementation on specific filtering at the SP side (see chapter 5 for more details)

5. Filtering at the SP side based on SIRTFI

At the Shibboleth SP side, you have the possibility to implement user filtering based on SIRTFI. The main idea here is to restrict access only to the users authenticated against a SIRTFI compliant IDP :

6. Appendix : SIRTFI metadata extensions

6.1 SIRTFI Entity Attribute

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ...>
  <md:Extensions>
    <mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
      <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
            Name="urn:oasis:names:tc:SAML:attribute:assurance-certification">
        <saml:AttributeValue>https://refeds.org/sirtfi</saml:AttributeValue>
      </saml:Attribute>
    </mdattr:EntityAttributes>
  </md:Extensions>
  ...
</md:EntityDescriptor>

6.2 SIRTFI Security Contact

<md:ContactPerson xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
      contactType="other"
      remd:contactType="http://refeds.org/metadata/contactType/security"
      xmlns:remd="http://refeds.org/metadata">
  <md:GivenName>Security Response Team</md:GivenName>
  <md:EmailAddress>mailto:security@xxxxxxxxxxxxxxx</md:EmailAddress>
</md:ContactPerson>