Approach to create a global federated
security incident response capability
Many R&E federations and their member organizations have developed a capability to handle security
incidents. However, there are no established tools and procedures to coordinate response to a
federated security incident, i.e., a security incident that involves two or more member organizations
among all member organizations across all R&E federations. When an SP organization experiences a
security incident that involves a credential issued by an IdP, they need to contact that IdP organization’s
security operations, and they should expect at least a basic level of assistance be offered to help them
remediate the incident. Similarly, there are no established tools and procedures by which an IdP
organization can notify an SP organization’s security operation when it has determined that an account
has been compromised, that account is being used to access the SP, and the SP organization is one that
has registered itself as being at risk of potentially substantial impact when unauthorized federated
access occurs.
In 2014 the Sirtfi group, comprised of volunteers from several European and North American scientific
cyberinfrastructure projects and R&E federations, began to address this problem. This work is now being
supported in part by the AARC project, ensuring that key people and deliverables are funded to continue
to work on the Sirtfi activity and establish a solution to this problem.
Following is a high level description of the strategy developed by the Sirtfi group, the status of some of
its elements, and a work plan designed to complete a solution. The proposed work is a joint effort of
AARC, REFEDS, several R&E federation operators, and several member organizations that volunteer to
help refine the solution being developed by Sirtfi. The existing Sirtfi mailing list, REFEDS, and individual
R&E federations are the venues in which this work will proceed.
The work plan proceeds in three phases:
1.
Develop the Sirtfi Trust Framework specification, which defines basic security incident
response capabilities to which member organizations can self-assert compliance.
A near final draft is complete. Volunteer organizations will be identified and asked to help finalize
the draft.
2.
Establish the means by which member organizations in all R&E federations can indicate their
compliance with the Sirtfi Trust Framework and how they can be contacted to initiate
coordinated response to a federated security incident.
Completion of this phase will effectively enable an SP that has detected an AUP violation involving a
credential issued by an IdP to initiate a coordinated response to that security incident.
REFEDS and R&E federation operators are key enablers of managing the federation metadata that
provides essential infrastructure for this function and communicating with their member
organizations to establish and maintain this information.
DRAFT 1
Tom Barton
p 1 of 3
3.
Establish the means for proactive notification of an account compromise when it can be
expected to produce a substantial impact to an at-risk SP organization.
A key enabler for this phase is deployment of tools that help automate the correlation of federated
access by an IdP’s accounts to SPs registered as being at-risk, and to convey standardized
notifications related to an account compromise and its remediation securely and privately from an
IdP to security organizations of affected SPs.
At the time of this writing there is a company called Confyrm that operates an infrastructure that is
potentially well suited to the Phase 3 objective and is interested to work with our vertical. This will
be explored.
Phase 1: Complete Sirtfi Trust Framework specifications
Who
Sirtfi working group
Volunteer IdP & SP
organizations
REFEDS
What
 Identify volunteer IdP and SP organizations to help bake Sirtfi draft
v1.8.
 Finalize Sirtfi draft v1.8 to produce public v1.0.
 Decide whether IdP notification of compromised account belongs in
v1.0 or will be slated for v2.0 in alignment with Phase 3 work.
 Propose entity metadata schema for security contacts.
 Propose entity attribute profile to signify adherence with Sirtfi public
v1.0.
 Work with Sirtfi working group to give feedback on Sirtfi draft v1.8.


Finalize entity metadata schema for security contacts.
Finalize entity attribute profile to signify adherence with Sirtfi public
v1.0.
Phase 2: Enable SP organizations to marshal incident response
capabilities at IdP organizations to help manage security incidents
Who
Sirtfi working group
Volunteer IdP & SP
organizations
REFEDS
DRAFT 1
What
 Produce educational and communication materials for REFEDS to
promulgate to member R&E federations
 Test use of security contact metadata for SP initiation of coordinated
response to a security incident.
 Promulgate educational and communication materials to help R&E
federations to
o Promote Sirtfi public v1.0 adoption
o Implement metadata extension for security contact information
o Implement metadata profile to signify Sirtfi public v1.0
adherence.
o Implement processes by which to maintain security contact
information and Sirtfi trust framework adherence.
Tom Barton
p 2 of 3
Who
R&E Federations
What
 Implement member security contact information maintenance
processes.
 Promote adherence with Sirtfi public v1.0 by member organizations.
 Implement entity tagging of entities belonging to members that
adhere with Sirtfi public v1.0.
Phase 3: Enable IdP organizations to proactively notify at-risk SP
organizations of events related to relevant account compromise
Who
Sirtfi working group
Volunteer IdP & SP
organizations
R&E federations
DRAFT 1
What
 Work with Confyrm to
o Set up proof of concept mechanism for SPs to register IdP
accounts whose unauthorized use has potential for
substantial impact.
o Define and set up means for IdP organizations to issue events
related to account compromises.
 Develop tools to help IdPs identify accounts that have been used
to access SPs that have registered themselves as being at-risk.
o Develop integration with Confyrm to source relevant events.
 Assess results of Confyrm proof of concept and determine
whether to continue towards a production implementation or
define an alternative method.
 Test tools and Confyrm proof of concept.

Continue communication and processes to encourage Sirtfi
adoption and maintenance of security contact information.
Tom Barton
p 3 of 3