Federated Incident Response

[Wayland Morgan <>]

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)