Federated Incident Response

["Wessel, Keith" <>]

That’s an excellent plan, Tom. Given the challenges of both steps, it seems much more doable in two pieces than all at once.

 

Keith

 

 

From: [mailto:] On Behalf Of Tom Barton
Sent: Monday, May 11, 2015 5:23 PM
To:
Subject: Re: Sirtfi Incident Response: Credential compromise

 

Hi Brett et al.,

I'm very sorry to have this reply so long after your question.

Short answer: Willingness to notify does belong in the sirtfi doc, ultimately.

Longer answer: The hardest part about trying to build an infrastructure for federated security incident response is that the risks are felt by one party but mitigation and response is tasked to another. That makes it hard for the latter party to see why they should invest in a problem felt by the former party, at first.

The good news is that those latter parties are always glad to be of help managing an incident when they are asked.

So this leads naturally to a two-phase project. In the first phase we pursue a valuable use case that all parties agree is worthwhile and work out all of the details of how one can contact the other, how an SP can contact an IdP to help with what appears to be a compromised account, between any pair of the tens of thousands of SPs and IdPs globally.

In the second phase the focus is on that apparent imbalance between cost and benefit that impedes an IdP org from notifying an SP org proactively when they have had a related credential compromise. Minimize the circumstances in which that is actually a valuable thing to do and make it as painless as possible, but finally set the bar and help the community to determine that it should clear it.

I think this is best approached as two phases rather than one, because two smaller steps are more likely to succeed than one big step.

I've been working with a couple of colleagues over the last couple of weeks on a work plan to achieve operational federated security incident response. It mirrors these two phases for essentially the reasons stated. Several of the right parties and organizations are now engaged with this problem and have it prioritized and resourced, including REFEDS, the Geant AARC project, and InCommon. So I'm hopeful that we will actually make some progress on this problem.

Tom

On 4/6/2015 9:21 AM, Brett Bieber wrote:

Scott Koranda posted the following comment in the Incident Response section of the Google-doc:

"This section describes an organization's interactions with other organizations participating in the framework. So why does an agreement that one organization aware of an incident will notify the other not belong in this document and in this section?

 

Scott's comment raised some similar questions in my head that could occur when a subject believes their credential has been compromised, and the follow-on situation—when the IdP operator believes one of their user's credentials has been compromised.

 

There's nothing in the document that describes any relationship to the subjects/actors, besides some logging/traceability and the ability to contact users. There's also no obligations or requirement placed on the member to notify other Sirtfi members of an incident, only that they're "...able and willing to collaborate...with [other Sirtfi participants]"

 

I feel that Sirtfi members should be able and willing to respond to an incident report from their own users (which are not themselves Sirtfi members), and to notify known affected Sirtfi participants.

 

Were those aspects intentionally omitted from the IR section? and

Is it acceptable/understood that the established incident response process at the participant [IR4], will includes these aspects, and can be left out of the IR section?

 

Thanks,

 

-Brett