A matter of when, not if. At some point you will face an cyber-security incident, or a security event that looks suspiciously like it. To contain, mitigate, and resolve the incident requires collaboration from everyone: resource providers, collaborations, users, and identity sources. The federated model of the AAI, in the AARC BPA as well as in eduGAIN more generally, means that many incidents touch all of these parties, and only by working together we can squash the incident. To do that effectively requires you have an incident response procedure that addresses your own security as well as the federation as a whole.

First response

• Don't panic! You are not the first one to be involved in a security incident, and by the time you observe the incident it has likely been ongoing for quite some time. On average: 3 months. So before you act: think!
  • look up your incident response procedure and have it handy so you do not forget any steps.
  • is this incident (potentially) going to be reported to law enforcement agencies (LEAs)? Then preserving immutable evidence is key: only work on copies and snapshots, and involve LEAs as early as possible. Otherwise, whatever evidence you collect may not hold up in court.
  • if you have an organisational security team (CSIRT, CERT, whatever), involve them! Not sure if you have one? Look up in Trusted Introducer or ask your Federation Operator.
• Think about physical safety: could the incident involve (remote) access to Operational Technology? SCADA systems controlling research equipment, lasers, beamlines, or BSL air scubbing facilities, for instance? Maybe at other sites? Make sure Occupational Health and Safety is alerted.
• What may appear as a malicious user could actually be a compromised identity, where the user is a victim as well. Do not jump to conclusions, but do share identifiers and names with identity providers and peer infrastructures, so the legitimate user can be warned and protected. But of course, there can be insider attacks and miscreants as well. Your investigations will find them...
• Share information with peers in a trusted way. Use the Traffic Light Protocol to ensure the audience knows what is expected without having to ask you every time. Could this incident potentially involve federated users? Involve your Federation Operator and (for services and infrastructures) the Collaboration platform and operator. They need to know to help you resolve the incident!
• If you find yourself overloaded with work, find an incident coordinator in your infrastructure or at your federation. Having a single focus point is tremendously helpful for keeping track of things.
• For research collaborations: you have a pivotal role in the AARC Blueprint as a hub for role and group management, and as the only entity that can link identifiers between services and identity providers! Cooperate, and be ready to suspend in case of doubt. The resource providers rely on your alertness and cooperation!

Response procedures

Every collaboration, infrastructure, and organisation is - to some extent - unique: who should be contacted, is an organisational security team available, what is the responsible chain of management. But the structure of incident response is mostly the same, regardless of the organisation. You should review the Security Incident Response Trust framework for Federated Identity (SIRTFI v2) and check whether you meet each of the basic steps. If you are in doubt about a requirement, that is a good place to start fixing it. Most common observation: lack of communication within your own organisation. This you can fix!

We provide a couple of examples from tried and tested infrastructures as well:

• UK IRIS
• eduGAIN Security Handbook (and other eduGAIN security resources)

Documenting your security contact information

"A clear statement of the policies and procedures of a CSIRT helps the constituent understand how best to report incidents and what support to expect afterwards.  Will the CSIRT assist in resolving the incident?   Will it provide help in avoiding incidents in the future?"  "Constituent communities need to know exactly how their CSIRT will be working with other CSIRTs and organizations outside their constituency, and what information will be shared."

If you (an infrastructure, a collaboration, an identity source) have a means to publish information, do so:

1. publish a 'security.txt' file in its well-known location: https://example.com/.well-known/security.txt
2. write the brief description of the security team in RFC2350 format.

Well-known collaboration platform operators and security contacts

• B2ACCESS - security@eudat.eu
• CERN IAM services - computer.security@cern.ch
• CILogon - security@ncsa.illinois.edu
• eduGAIN - abuse@edugain.org
• EGI Checkin - abuse@egi.eu
• GEANT CoreAAI (MyAccessID, MyAcademicID, ...) - security@eduteams.org
• SURF SRAM - securityincident@surf.nl

Resources

• AARC I051 Guideline to Federated Security Incident Response for Research Collaboration
• SIRTFI version 2: federated security incident response and communications
• security contacts for federated identity providers and relying parties: infrastructures and services (REFEDS MET)
• UK IRIS
• eduGAIN Security Handbook
• eduGAIN security team
• Federation Operators list (eduGAIN)
• EGI CSIRT
• RFC 2350 Expectations for Computer Security Incident Response