Federated Incident Response

[Tom Barton <>]

Thanks Wayland. A new and substantially revised version of the Sirtfi doc, v1.8, was produced in the meanwhile. It is attached. Feedback about this latest version from you, and everyone, is most welcome.

Many of the concerns raised by Illinois and Wisconsin (below) were addressed by very substantially reducing the specificity and depth of requirements that were expressed in v1.6. Effectively, v1.6 arose from a context in which a collaborative group of research cyberinfrastructure organizations wanted to agree on a shared security response model among them. In getting to v1.8 we tried to focus mainly on the willingness to help respond to an incident, positing only what was necessary about each organization's capabilities and policies.

Some concerns were raised that might not be addressed by that blanket response:

Would this contradict an institution's policies regarding sharing of security information? No. Sirtfi v1.8 respects an organization's established policies.

Do we need to agree on what constitutes an incident? No. Sirtfi v1.8 is about helping to manage an incident that someone else has determined they are experiencing.

Might GRC functions also need to form in the federated context with representatives from each institution in addition to IR functions?  Sirtfi v1.8 is intended to define a trust framework that can scale to the global R&E sector, so there can be little, if anything, that is centralized about its implementation. What GRC functions did you imagine?

What if we're "relaying" authentications from users that don't belong to our organization, eg, a google social ID gateway operated within our organization - what is our obligation for managing those? If you allow use of this gateway for services internal to your organization, then you probably already have a need to manage those authentications for internal incident response purposes. Sirtfi v1.8 would allow another Sirtfi compliant organization to ask you to do so for them too. But more below on this.

Do we need to enforce an AUP or have any obligations connected with users of gateway'd social IDs? I'm curious what the use case here really is. If you are indeed relaying or proxying a google user, say, to a third party and representing it as an authentication event produced by your organization, then you might have a problem. Sirtfi v1.8 still requires ability to suspend user access rights and notification of AUP. Both of these things are generally necessary for an organization's own internal purposes, to manage a situation in which such an account is being used contrary to its AUP. That's different than providing social ID access to services operated by the organization, where you don't control the authentication and don't need to notify of the AUP.

Traceability questions. Under Sirtfi v1.8 log records need not be shared. Nothing about what form help takes is specified in detail. What you do to meet internal incident response needs is probably about what you'd expect to do when helping to manage a federated incident.

Thanks,
Tom

-- 
Tom Barton
Senior Director for Architecture, Integration, and Security
Chief Information Security Officer
IT Services
University of Chicago
+1 773 834 1700

On 3/30/2015 12:38 PM, Wayland Morgan wrote:

Hi all,

Digging up an old thread here. It appears that I never actually sent any
feedback from a UIUC perspective.

+ Shared infrastructures and active monitoring to detect and reduce the
impact of security incidents

-Whom shares what and in what context? Real time or other? Does this
include the real time sharing of logs? I could see a potentially tricky
nuance to our institutional information sharing policies if for example
we were to federate our logging infrastructures with another institution
and for example they were to be compelled by some LEA entity to divulge
shared information. What assurances do we have that we can uphold these
standards of process for info sharing in a federated context?

+ Monitoring and Incident Response

-How do we define what exactly an incident is in the federated context?
This answer can at times vary depending on an organizations environment
specific requirements. Could federating IR functions across institutions
result in resourcing concerns if for example shops are expected to
support security requirements for more organizations than just there
own? How should this be addressed? Who is responsible for monitoring and
implementing alerting mechanisms?

Generically speaking, many organizations define and incident roughly
along the lines of "A security incident is the act of violating an
explicit or implied information security policy." What happens if
someone elses definition differs from another? It seems that a common
definition would be needed but I can see where this could potentially
distract from organizationally unique requirements.

+ Governance, Risk, and Compliance

It would seem that GRC functions would also need to form in the
federated context with representatives from each institution in addition
to IR functions.

Regards,
Wayland

*****************************
Wayland Morgan
IT Security Analyst
Office of Privacy and Information Assurance
University of Illinois
PGP Fingerprint:
0ED3 9CEA 4CF9 3565 C5A9
03DB D971 D711 842A A77E

On 10/24/2014 11:25 AM, Keith Hazelton wrote:

Some collective feedback from UW-Madison on the SirTfi draft:

We responded to this positioning ourselves primarily in the role of IdP.
Some of the terminology was not easy to translate to our world, for
example DITI was a challengingly abstract term and the glossary did not
include a definition of claims processor which came up in a couple
sections of the draft.

We looked over each of the six operational areas:

- Operational Security

The draft suggested a four-level self-rating for how well an
organization meets each specific requirement within the six operational
areas. In our IdP and its supporting environment, we have different
segments of users that fall under different procedures. Each segment
might get a different rating for requirements OS1 to OS4. More loosely
affiliated users might rate a 0 on OS1, the general NetID population
might be at 1; but only identified sub-populations might reach level 2,
depending on the ID proofing and single (or multiple) credentials
issued. Basically it would not be possible for us to give a meaningful
single rating to the operational security requirements.  It seems it
will be necessary to specify for a given user and given session a level
of assurance that would imply one of the four levels.

On requirement OS2, around patching, it seems that 'verified, recorded
and communicated to the appropriate contacts' sets a high bar.

- Incident Response

Our roadmap includes support for authentication via external providers
(Google, Twitter, etc.) through a campus-level gateway. If such
externally authenticated users access federated services, there are any
number of challenges around security incident responses. Again, it seems
that minimally SPs will need authentication context information that
will allow them to determine whether they want to accept a given
provider's assertion or not. 

One approach under consideration at UW-Madison is to carry stub identity
records for federated (including external AuthN providers') users. If we
become aware of a compromised credential of this kind, we can't 'turn it
off' at the source, but we can break the link to the internal user
record, giving us a means to head off access by those users to SPs.

- Traceability

TR1: Who is in a position to release what? We can't get logs from Google
& FB; language is fairly general in this draft, seems like it will
eventually at least need to spell out minimum retention period; Locale
at which user registration took place could also be an important item of
information.

TR3: Re identifying users: The bare logs won't suffice: AD GUIDs won't
do the log recipient any good; To go beyond that imposes a significant
work load on the IdP side.

- Participant Responsibilities

PRU1: we have AUP for NetID holders; but with social credentials, how do
we catch & deliver AUP;

PRC3: Legal staff come down firmly against implications that we're
liable for behavior of individual users. SPs, of course, retain rights
to discontinue access to an individual or group to protect integrity of
service for others.

- Legal/Management Issues

The statement leading into the individual requirements sets a high bar
with the language '...policies and procedures appropriately communicated
to all participants, that address legal issues including but not limited
to...'

LI2: The focus on making participants aware of their obligations is a
sound one (compare with our comments on PRC3 above).

- Protection and processing of Personal Data/Personally Identifiable
Information

Lots of jurisdictional sticky wickets in this area. 

In general we recognize the significant challenge of establishing a
trust framework that can function in an international context. But we
found ourselves wondering whether there were ways to leverage
well-defined existing frameworks, PCI, FISMA and others.  Granted that
this would likely mean different reference points for the US, EU, etc.
The reference to the Traffic Light Protocol in the Incident Response
section of this draft is one example of this kind of approach.

       -- Tom Jordan(IAM), Jeff Savoy (security), Keith Hazelton
(architecture)

Attachment: Sirtfi-V1.8.pdf
Description: Adobe PDF document