...
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? - Documented on the eduGAIN website.
- These will be monitored and shown as warning in validators (including history).
- Warnings will be followed up by edugain-support.
- We will advertise and promote the BCP.
|
| JRA3 T1 | Review validator requirements | - Work with eduGAIN-OT - should be mostly in place.
|
| JRA3 T1 | Ensure validator warnings are being follow-up with by edugain-support | - Establish support process for eduGAIN validator warnings.
|
| 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. | - Identity a team! Proposal of 3 IR people on rotation to support edugain-support
- Unique global identifier for the incident to support communication.
- Support for incident response classification with edugain-support area of OTRS.
- Define how far into the analysis and forsenics the eduGAIN team will be required to go. Is this purely support / coordination or is this managing forsenic analysis on behalf of participants.
- Secure communication channel (secure IRC channel? e-mail?). Challenge will be to not restrict communication through use of non-friendly tools.
- Enabling use of signed / encrypted email. Can be difficult if people are not using personal certificates as a day-to-day process.
- Would suggest an additional role of ensuring the correct e-mail addresses (Sirtfi contacts) are being used in the communication.
|
|
| 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. | - Robustly covered support desk with back-up and holiday cover to meet this target. Even then identifying on this timescale is a challenge.
- Define hours that the team operates.
- Can only cover orgs with security contacts, or use other contacts?
|
|
| AARC report | Coordinate the security incident resolution process and communication with affected participants until the security incident is resolved. | - Identify if / when Federation Operators have signed up to play a role.
- Clarity on coordination vs management of incident.
|
|
| AARC report | Ensure suspension of service (if applicable) is announced in accordance with federation and interfederation practices. | - Just ensure it is announced or that it happens?
- Requires action by Federation Operator (eduGAIN OT cannot suspend individual services).
- Requires metadata refresh.
|
|
| 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. | - As per typical request ticket.
|
|
| AARC report | Assist and advise participants in taking corrective action, or restoring access to service (if applicable) and legitimate user access. | - Define expectations here. What can eduGAIN actually achieve? Will depend on central skillset and focus.
- Balance of expectations between FOs and SPs / IdPs.
|
|
| 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. | - We need to define a communication process here. There will be a need to share 1) at a public level and 2) at affected parties level. I don't see why a Sirtfi contacts only level would be appropriate, needs clarifying.
- Secure data store for documentation related to incidents.
- Define a role for the comms team - training through CLAW workshop?
|
|
| AARC report | Update documentation and procedures as necessary. | - Ensure responsible owners are actioned in eduGAIN OT, Service Management, support desk etc.
|
|
| General | Freshness of contact data | - Put in place a response testing process for Sirtfi email addresses.
|
|
| General | GDPR compliance of supporting information sharing and appropriately expiring tickets. GDPR compliance of contact data. | - AAI specific 15
- Federation 9
- Individual 109
- Security specific 142
- IT Support 31
- Unclear 25 |
|
| General | Bridging the circles of trust / mismatch between the expectations of contact types. | - As per Hannah's stats, there are very different people potentially receiving messages, who will have very different expectations as to what to do / have different access and experience to tools / terminology etc. What can be done here?
|
|
| General | Disclosure policy | - Align with GÉANT or something more specific?
|
|
| General | Who is responsible for checking and enforcing Sirti errors. | - At metadata level: checking by eduGAIN OT. Are we emailing out when errors are identified?
- In terms of responsiveness: Mario's testing tools.
|
|
