Page tree
Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 2 Next »

The Security Incident Response Trust Framework for Federated Identity (Sirtfi - spreek uit "cert'fy") is a REFEDS project which aims to publish incident response contact information for entities and have entities assert compliance with some basic incident response norms.

Technically, Sirtfi specifies two metadata elements:

  • A new ContactPerson type "security" which lists the point of contact for incidents;
  • A new EntityAttribute that asserts compliance with the Sirtfi framework norms.

It is possible that IdPs or SPs will only want to do business with entities that comply with Sirtfi, although concrete examples are at this point unknown.

This page describes the application of Sirtfi within the SURFconext federation.

General considerations

Incident response is of course nothing new to SURFnet and is largely "yet another service". SURFcert deals with a large volume of incidents daily which include incidents very comparable to those in SURFconext, e.g. "mail account x has been compromised and is sending phishing emails" or "eduroam account y sends suspicious traffic, please investigate". SURFcert has experience, contacts and systems in place to receive and handle incidents 24x7, register and follow up on them, and escalate when there are problems. We should seek to re-use as much of that as possible.

SURFconext is a bit special in that as a hub-and-spoke federation, it has centralised knowledge of who logged into where when (audit log). Normally IdP's will also log this. However, based on the incident, SURFconext's exclusive knowledge may be required to resolve an incident: if an opaque nameid is used, or if the reported incident refers to EngineBlock as the IdP.

Sirtfi for IdPs

From the view of SP's, all logins for IdP's in our federation run through SURFconext; also SURFconext may filter or augment the outgoing data. Therefore it makes sense to make SURFnet the primary point of contact for questions about logins originating from SURFconext on an SP. SURFcert is SURFnet's 24/7 incident response team. Therefore we should publish SURFcert as the security contact for all our IdP's in the (eduGAIN) metadata we produce.

SURFcert can register the incident and followup with surfconext-beheer and/or affected IdPs via their registered SEPs. We assume that an institution's SEP will be or should be made able to handle/appropriate redirect IdP related incidents. Until now we've hardly received any incidents. SURFcert will get documentation about basic workings of the federations and contact- and escalation points for surfconext-beheer. Actually received incidents will give us input on whether additional procedures or tools are needed for federation specific incidents.

As for the compliance assertion: SURFconext in combination with SURFcert complies with the points in the framework. Individual IdP's are already required to comply with those or equal rules through the SURFnet Aansluitovereenkomst and/or the SURFconext Addendum IX. Institutions that do not provide adequate indicent response are routinely escalated to account advisers to resolve this problem. In our constellation we can publish compliance with Sirtfi for each of our IdPs by definition and should do so in our publised (eduGAIN) metadata.

Given the above there's no need for IdPs in SURFconext to add Sirtfi information to their metadata themselves if they only interface with SURFconext. If an IdP does so regardless, we should probably check with them what the expectations are and how to handle this: is it only for other connections this IdP has, or do they want to override SURFconext's info for some reason?

 

Sirtfi for SPs

For "incoming" SPs that our IdPs use via eduGAIN we can look up the relevant Sirtfi information in eduGAIN metadata when we need it. There's a Dashboard story in the icebox to also make it available to SURFconextverantwoordelijken. It does not currently seem opportune to reject SPs without Sirtfi.

"Outgoing" SPs that SURFnet publishes (in eduGAIN) should be handled individually. A commercial SP like Edugroepen should probably list its own direct contact information and check compliance with the framework. SPs that are run by SURFnet itself may similarly decide on what the most appropriate contact point is. We can republish such information from the SPs metadata feed.

 

Implementation

  1. Discuss within SURFconext team
  2. Discuss with SURFcert (preliminary talks done)
  3. Discuss with key users (David Groep?)
  4. Make some basic documentation on SURFcert wikiwespje
  5. Publish contact info and assertions for IdPs; inform IdPs about Sirtfi
  6. Inform SPs and ask them to provide Sirtfi information in their metadata fields; republish if present
  • No labels