Page History

...

Federated identity introduces new challenges for security incident response. Federation participants should consider the impact of federated identity in their incident response practices and treat federated identity partners impacted by a security incident in a similar manner as they would local parties.

Incident Response Policy

Goal of this Policy

...

Reporting a Security Incident

The following procedure assumes Federation participants have published one or more security Contacts in Metadata for the purposes of security incident response.

1. A participant discovering a security incident should strive to notify any affected parties in the federation to the extent allowed by that participant's policies, relevant laws and resource constraints.
2. Participants should maintain a current point of contact for security incident reporting (see "Security Contacts in Metadata" below).
3. Participants, when discovering a security incident, should strive to report the incident to other affected participants at the provided point of contact for security incident response. For example:
   1. If an Identity Provider discovers a security incident that affects one or more Service Providers, it should strive to contact those Service Providers and share relevant information.
   2. If a Service Provider discovers a security incident that affects one or more Identity Providers, it should strive to contact those Identity Providers and share relevant information.
   3. If a security incident involves a user, the incident should be reported to that user's Identity Provider at the provided point of contact for security incident response.
4. Participants should encrypt incident communications to prevent unauthorized disclosure.
5. Service Providers have ultimate authority for access control for their services. A Service Provider may choose to locally de-authorize a user or Identity Provider for any reason, including containment of a security incident.
6. Identity Providers have ultimate authority for access control to their services. An Identity Provider may choose to deny release of user identifiers and attributes to a Service Provider for any reason, including containment of a security incident.
7. A user could be the originator of a security incident report if, for example, they find activity attributed to them at a given Service Provider for which they do not believe they are responsible. The user might report this to either the Service Provider or to their Identity Provider, but in either case, the participant receiving the security incident report should apprise the second participant of the report.

...

1. Participants are expected to keep internal logs with accurate date/time stamps that allow for security incident response. For example, an Identity Provider should be able to identify the specific individual associated with an anonymised identity presented to a Service Provider.
2. Participants are expected to retain such logs for whatever period of time organizational policy dictates or allows.

Policy Adoption

To adopt this policy:

• Publish federated incident response contact information for your federated services and identity providers.
• Implement a log retention policy for federated services and identity providers.
• Document and advertise your procedure for responding to a federated security incident.

Security Contacts in Metadata

Federation participants should publish Contacts in Metadata for security incident response. For example:

...

<md:ContactPerson contactType="other"
     xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
     xmlns:ext="urn:mace:incommon:contactType"
     ext:extendedType="security">
  <md:EmailAddress>mailto:security@example.edu</md:EmailAddress>
  <md:TelephoneNumber>999-999-9999</md:TelephoneNumber>
</md:ContactPerson>

Acknowledgements

This material was originally developed by the CIC Identity Management Taskforce (see: CIC Federated Security Incident Response Policy).