...
- 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!
...
Well-known collaboration platform operators and security contacts
- B2ACCESS - security@eudat.eu
- CERN IAM services - computer.security@cern.ch
- CILogon - security@ncsa.illinois.edu
- 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