Incident Response Procedure
This procedure is effective from <insert date>.
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!
|
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. |
Investigate | 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! |
Identify a coordinator | 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. |
Cooperate | 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! |