In order to support effective incident response among Sirtfi-compliant organisations, it has been proposed that both Federation Operators and eduGAIN OT provide a supporting role. Neither of these roles are defined or scoped within the current Sirtfi framework. AARC produced a paper than analysed these roles with a set of proposals for eduGAIN. These are analysed below along with other requirements to take on this role. It is assumed that the primary contact for this type of support will be edugain-support, with appropriate support from the GÉANT NOC / CERT teams.
High Level Needs
- Support Sirti at eduGAIN.
- Recruit support role. Request is with Shaun / HR.
- Coordinate roles: eduGAIN-support,GÉANT CERT, GÉANT NOC.
- Document workflow.
- Training.
Proposed Requirements
There are two levels that need to be supported:
- Support for Sirtfi within eduGAIN.
- Support for Incident Response coordination at eduGAIN.
This page outlines requirements for both of those.
Tasks: Sirtfi Support at eduGAIN
This is part of JRA3 Task 1. Campus and Federation (sub-task 1: eduGAIN Policy Review).
Source | Proposal | Requirements |
---|---|---|
JRA3 T1 | Establish Sirtfi as a BCP | What does it mean to have a BCP?
|
JRA3 T1 | Review validator requirements |
|
JRA3 T1 | Ensure validator warnings are being follow-up with by edugain-support |
|
JRA3 T1 | Gather security contacts for federations |
|
JRA3 T1 | Create a Incident Management Framework Template for Federations |
|
Requirements: Support for Incident Response coordination at eduGAIN
This is part of JRA3 Task 1. Campus and Federation (sub-task 4: eduGAIN Incident Response).
Source | Proposal | Requirements | Workplan Mapping |
---|---|---|---|
AARC report | Assist federation participants and Federation Security Incident Response Coordinator in performing appropriate investigation, system analysis and forensics, and strive to understand the cause of the security incident, as well as its full extent. Identifying the cause of security incidents is essential to prevent them from reoccurring. The time and effort needs to be commensurate with the scale of the problem and with the potential damage and risks faced by affected participants. |
| |
AARC report | In collaboration with Federation Security Incident Response Coordinators, ensure all affected participants in all federations are notified via their security contact with a “heads-up” within one local working day. |
| |
AARC report | Coordinate the security incident resolution process and communication with affected participants until the security incident is resolved. |
| |
AARC report | Ensure suspension of service (if applicable) is announced in accordance with federation and interfederation practices. |
| |
AARC report | Share additional information as often as necessary to keep all affected participants up-to-date with the status of the security incident and enable them to investigate and take action should new information appear. |
| |
AARC report | Assist and advise participants in taking corrective action, or restoring access to service (if applicable) and legitimate user access. |
| |
AARC report | Produce and share a report of the incident with all Sirtfi-compliant organisations in all affected federations within one month. This report should be labelled TLP AMBER [3] or higher. Coordinate communications around incident. |
| |
AARC report | Update documentation and procedures as necessary. |
| |
General | Freshness of contact data |
| |
General | GDPR compliance of supporting information sharing and appropriately expiring tickets. GDPR compliance of contact data. |
- AAI specific 15 | |
General | Bridging the circles of trust / mismatch between the expectations of contact types. |
| |
General | Disclosure policy |
| |
General | Who is responsible for checking and enforcing Sirti errors. |
|