Cliquez ici pour la version française
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
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.
They are two versions of this specification:
The only differences between the two versions are related to minor reformulations, and a new assertion regarding incident response (IR3). They are cumulatives, meaning compliance with version 2 implies compliance with version 1.
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 |
The following chapter describes the steps to follow by an organization in order to express a SIRTFI compliance.
The first step for an organization consists in completing a self assessment following the SIRTFI Framework (see previous chapter). As this constitutes a formal commitment with other organizations, this assessment is supposed to be carried (or at least validated) by relevant authority, the CISO typically.
In the case where the assessment is positive, then the organization can declare this compliance for each of the federated resources (IdP or SP) it owns. This operation is performed through the Federation registry.
This operation is performed through the Federation registry, from the editing page of the involved entity (IDP or SP). Under the “compliance” tab, you only have to tick the dedicated box in order to attest this ressource is compliant.
After ticking the box, then you have to define a security contact for this entity (the fields security contact name and emails , grayed so far, become writable)
The security contact will be the initial point of contact during a federated incident involving this resource.
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.
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 :
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)
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 :
<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/sirtfi2</saml:AttributeValue>
<saml:AttributeValue>https://refeds.org/sirtfi</saml:AttributeValue>
</saml:Attribute>
</mdattr:EntityAttributes>
</md:Extensions>
...
</md:EntityDescriptor>
<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>