This procedure should be shared with any service operator within your Research Collaboration.
| Panel | ||||
|---|---|---|---|---|
| ||||
Incident Response ProcedureThis 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. |
Step | Action | Deadline |
1. (Suspected) Discovery | Inform the local security team (if applicable) | WITHIN 4 HOURS |
Inform the Research Collaboration Security Officer | WITHIN 4 HOURS | |
In collaboration with the Research Collaboration Security Officer, ensure that suspected affected external federated partners are informed | WITHIN 1 DAY | |
2. Containment | Isolate affected hosts (if feasible) | WITHIN 1 DAY |
Snapshot and/or suspend affected VMs | WITHIN 4 HOURS | |
Disable affected appliances | WITHIN 4 HOURS | |
Disable (suspected) detrimental user access | WITHIN 4 HOURS | |
3. Confirmation | Investigate to confirm whether the incident is real | WITHIN 1 DAY |
4. Downtime Announcement | Announce applicable downtime. The reason e.g. “security operations in progress” should be stated. | WITHIN 1 DAY |
5. Analysis | Collect evidence regarding the incident - as appropriate | |
Perform analysis of the incident - as appropriate | ||
Follow-up on requests from security teams | WITHIN 4 HOURS of receipt | |
6. Debriefing | Prepare a post-mortem incident report in collaboration with the Research Collaboration Security Officer | WITHIN 1 MONTH |
7. Normal Service Restoration | Restore normal service operation after incident handling is complete |
Post-mortem incident reports and the associated evidence and analysis must be retained for a period of at least 180 days after normal service operation.
Based on working hours: 1 day is 1 working day, 1 hour is 1 working hour
Cooperate