...

Incident response is of course nothing new to SURFnet and SURFconext is in this regard largely "yet another service". SURFcert deals with a large volume of incidents daily which include incidents very comparable to those in that could affect 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, procedures, 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. When specific knowledge of SURFconext is needed, SURFcert will liase with the SURFconext team.

SURFconext is a bit special as a federation in that as a hub-and-spoke federation, it has centralised knowledge of who logged into where what 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.

Of course all incident handling and disclosure of information to other parties (if any) will be handled in accordance to SURFnet policy.

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.

...