Who should I choose as my Sirtfi contact?
The purpose of this page is to assist you in selecting a Sirtfi contact for your entity. Your federation operators may provide valuable recommendations – be sure to liaise with them for guidance.
- The Sirtfi contact should be an individual or group who has agreed to perform the incident response obligations of the Sirtfi Framework on behalf of the entity
- Existing incident response structures, including CERTs, may be leveraged where available
Correspondence sent to the Sirtfi contact must not be publicly archived
A flow chart has been provided to describe the thought process for choosing a Sirtfi contact.
Example Sirtfi contact choices
By liaising with your federation operators, you should be able to gauge which potential Sirtfi contact is best placed to be the initial point of contact during federated incident response. Consider the expertise, availability and mandate of candidates when making your decision. The table below provides some example choices of Sirtfi contact.
Entity in federation with centralised incident response support
External security team – Federation
Entity in e-infrastructure with centralised support
External security team – e-Infrastructure
Entity within organisation with federation aware security team
Organisation’s security team
Mature entity with security conscious entity support
Entity’s support team or individual
Small scale entity
Individual with appropriate knowledge
What are the expectations on the Sirtfi contact?
The Sirtfi contact will:
- Use and respect the Traffic Light Protocol (TLP) during all incident response correspondence
- Promptly acknowledge receipt of a security incident report
- As soon as circumstances allow, investigate incident reports regarding resources, services, or identities for which they are responsible
Which information is required?
The following fields are mandatory for a Sirtfi contact:
Can additional information be included?
Additional fields, such as telephone numbers or secondary email addresses, may be added if desired. Only fields from the OASIS Standard for contactType may be added.
Why do you favor an external team even if a local team exists and would qualify? I assume that especially the security teams of bigger universities would prefer to be the primary contact.
In the table with the examples just below the chart a local team is listed as an option for a university, but it does not match with the flow chart.
The idea is that, if there is an external team (such as an NREN CERT) already performing security response, it makes sense for them to act as a Sirtfi contact "proxy". Of course, if a university prefers to be contacted directly then that is equally valid.
With the flow chart we wanted to highlight that leveraging existing models is encouraged but, you're right, it should only be chosen if it makes sense for the organisation/university. I will try and reflect that in the chart.
Thank you, Hannah, for the quick fix!