InCommon Federation Security Incident Handling Framework

Prepared by: Nicholas Roy, Director of Technology and Strategy, InCommon

Version: 1.0

 Date: January 11, 2017

Change Log

Mission Statement of InCommon CSIRT

InCommon’s Computer Security Incident Response Team (CSIRT) is a group of identified individuals working at Internet2 and in the community, assigned specific roles, and chartered to respond to security incidents related to InCommon’s trust, identity and security-related services so that they may be relied upon by InCommon participants for mission-critical and security-sensitive operations on an ongoing basis.  To that end, the InCommon CSIRT will:

• Receive information about security-related threats to InCommon infrastructure

• Receive information about security-related threats to InCommon participants’ federating systems

• Assess the risk of such threats

• Develop response and remediation plans where appropriate to address these threats

• Execute, with the possible addition of needed external resources, incident response according to a documented incident handling framework

• Report out to stakeholder communities on the nature of incidents responded to, status of response, and to communicate as needed with affected parties

Definition of “Security Incident”

A computer security Incident is: A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices. [4]

An event is an observable change to the normal behavior of a system, environment, process, workflow or person (components). There are three basic types of events:

1. Normal—a normal event does not affect critical components or require non-standard/pre-approved changes (such as normal periodic software patch application) prior (or on an emergency basis, after the fact) to the implementation of a resolution. Normal events do not require the participation of senior personnel or management notification of the event.

2. Escalation – an escalated event affects critical production systems or requires  implementation of a resolution that must follow a change control process, or require an emergency change control process after the fact. Escalated events require the participation of senior personnel and stakeholder notification of the event.

3. Emergency – an emergency is an event which may

1. impact the health or safety of human beings

2. breach primary controls of critical systems, as documented by InCommon staff

3. materially affect component performance or because of impact to component systems prevent activities which protect or may affect the health or safety of individuals

4. be deemed an emergency as a matter of policy or by declaration by the available incident coordinator

InCommon’s CSIRT handles Escalation and Emergency-level computer security incidents, including relevant security vulnerabilities/disclosures that are made known to it.  Normal-level security-related events are handled by InCommon Operations.

Initial Contact/Notification and Triage

Any party may make InCommon’s CSIRT aware of a relevant security incident or disclosure via one of the following mechanisms (available 24x7x365)

1. Send an email with a HIGH PRIORITY to: security@incommon.org

2. Call this number: +1 734 352 7045

InCommon’s CSIRT will accept, evaluate and reply (when necessary and deemed appropriate) to valid submissions according to the following time table:

Generalized Procedure for When Action Is Required

Upon receipt of information about a possible security threat to InCommon, the CSIRT will:

1. Identify an incident handling lead

2. Assign the lead to perform a brief initial assessment of the situation, including initial classification of the incident or disclosure as: “Normal,” “Escalation,” or “Emergency” in nature.

3. The lead will determine and execute next steps based on assessment of initial event classification, including the formation of an incident handling team as necessitated by nature, criticality and scope.  Lead may call in resources for the incident handling team, and those resources are obligated to help with further analysis, remediation and other necessary incident handling steps.  Normal procedures to follow are documented in the Incident Handling Actions Matrix below

4. All relevant details of the incident including classification, handling, communication, resolution and disposal will be documented in a shared file repository within Internet2

5. An incident is closed when the Executive Sponsor determines that the event has been handled appropriately and is no longer an active threat.  In some cases, one or more reports may be issued to relevant stakeholders.

Roles

Roles 1-4 make up the standing CSIRT, with all roles under 5 filled on an as-needed basis.

1. CSIRT Executive Sponsor, typically the Internet2 Vice President for Trust and Identity Services

2. Incident Lead, typically an InCommon technical director or manager

3. Incident Communications Representative, typically an Internet2 marketing and communication director

4. REN-ISAC liaison

5. Incident Handling Team (specific make-up of each team subject to availability and appropriateness at the discretion of the Incident Lead and CSIRT Executive Sponsor)

1. Lead (a role which may be assigned to any of the team members, but should remain lead throughout the handling of an incident)

2. Executive Sponsor

3. Steering Liaison

4. Ops Advisory Liaison

5. InCommon Operations Representative

6. Internet2 Communications Representative

7. Internet2 Chief Information Security Officer Representative

8. Other relevant internal Internet2 areas

9. REN-ISAC Representative and Liaison

10. Law enforcement Representative and Liaison

11. Legal Representative

Assessment of an Incident

This section is a set of guidelines to allow the named incident handling lead to assess the classification of an incident, for use as input in determining next steps, in the next section.

Scope

To be in scope for action by InCommon’s CSIRT, mitigation of the incident must essentially depend on one or more changes to InCommon’s operations which involve InCommon’s change management processes, as determined by the CSIRT.

An incident or disclosure which has compromised, or may lead to the compromise of, systems or services that affect one or more of:

1. InCommon Operations or its upstream or third-party providers (for example, cloud hosting providers, multifactor authentication providers, etc.) on which its operations depend.

2. The systems or services of an InCommon Participant relevant to federation participation, such as Identity Provider or Service Provider software or related cryptographic materials.

3. Any other operational aspect of InCommon’s trust services.

are deemed to be in-scope for InCommon’s incident handling processes and should be assessed for nature and criticality before any further actions are taken.  If an incident is not in-scope, it will be documented and handed off to the appropriate party (internal to or external to InCommon) for further assessment and handling.

Nature

Answer the question: Is the event an “Incident”?  i.e.:

1. Discovery of the neglect of a system or systems by a human actor responsible for maintaining that/those systems that prevents misuse or exploitation of the system(s) to harm InCommon or its participants’ networks or systems as those networks or systems function in a core or supporting role within the portfolio of Incommon trust services.

2. Use of a system or network in any way that compromises InCommon or its participants’ networks or systems as those networks or systems function in a core or supporting role within the portfolio of InCommon trust services.

3. Any other use or misuse of computing resources, intentional or otherwise, which would cause harm to networks or systems that have a core or supporting role within the portfolio of InCommon trust services (for more information on InCommon services, see: https://www.incommon.org/).

4. Disclosure of a security vulnerability known to affect systems or services used in the operation of InCommon’s infrastructure.
   

If an event is determined to be an “Incident” in nature, it should be further analyzed for elements of criticality in order to determine necessary actions.  If the event is not an “Incident,” it should be handed off to InCommon Operations for further analysis and handling.

Criticality

Incidents fall into three criticality categories:

Normal - an event that does not affect critical production systems or the trustworthy flow of identity/trust-related data across InCommon services.

Escalation - an event that affects production systems and requires change control steps be followed as part of a response.

Emergency - a change to a production system impacting one or more of the following:

1. Health and safety

2. Critical controls on systems which are relied upon for the trustworthy exchange of identity/trust data between InCommon participants and which utilize InCommon services for facilitation of this data exchange

3. Ability of InCommon or one or more of its participants to provide services or conduct business via InCommon services

4. Anything deemed an emergency by virtue of related InCommon policies or the CSIRT Executive Sponsor

Events that are “Escalation” or “Emergency” in nature should be acted upon by the Incident Lead in coordination with the incident handling team according to the Incident Handling Actions Matrix in the next section.  Events that are “Normal” will be handed off to the relevant party for further handling.

Communications

Communication of an incident is a critical step in the response plan, to be formulated in accordance with the matrix below.  It is important that a communication plan be designed in a way that does not disclose information about an incident to an inappropriate audience.  In many cases it is also important to let InCommon participants and other stakeholders know about an incident in a timely manner based on their need to know and need to share indicators of compromise.  At a minimum, for an Escalation or Emergency-level Incident, an after-action review– with a root cause and remediation steps identified –should be conducted by the Incident Lead, and a report should be prepared which may be shared with appropriate audiences.

A designated communication representative should be named as part of each Escalation or Emergency-level incident.  This person will provide needed input to a decisionmaking process about what information to share with which audiences, and in particular, what information may be shared outside of Internet2 and the CSIRT, when, via what channels, and in what format.  The Executive Sponsor will have ultimate authority for decisionmaking about the release of information, in consultation with the Incident Lead.

Traffic Light Protocol for Exchange of Information

For the purposes of communications with the CSIRT and with external parties during the handling of an active incident (and for further information sharing with other parties after the incident), the Traffic Light Protocol [3] must be used as a way to identify, label, and ensure compliance with scoping of the information shared.  The Incident Lead, Executive Sponsor and Communications Representative are primarily responsible for assigning TLP categories to information to be shared, although there are times when other members of the CSIRT and external parties will need to make an assessment about TLP categories and label information they are sharing.  When there is uncertainty on the part of a party responsible for classification on the proper classification of a communication item, the party should verify with the CSIRT or incident handling team.  Generally, the originator of new information will need to appropriately initially label that information.

Reference: TLP levels matrix, from US-CERT [3]

Incident Handling Actions Matrix

This matrix is intended as a generalized guide for the broad steps required in the classification and handling of security-related events.  The matrix below is partially derived from information available from EDUCAUSE [2]

Appendix A: Foundational Documents

[1] West Brown, Stikvoort, Kossakowski, Killcrece, Ruefle, Zajicek.  Handbook for Computer Security Incident Response Teams (CSIRTs) April, 2003.  Carnegie-Mellon University Software Engineering Institute, CMU/SEI-2003-HB-002

[2] EDUCAUSE, Sensitive Data Exposure Checklist v1.1

[3] US-CERT, Traffic Light Protocol

[4] NIST SP800-61, Computer Security Incident Handling Guide

Appendix B: Acknowledgements

Thanks to the following individuals and groups for their contributions to this document:

Kim Milford, REN-ISAC

Thomas Barton, The University of Chicago

Jane Drews, The University of Iowa

InCommon Technical Advisory Committee

InCommon Steering Committee

REN-ISAC

Big Ten Academic Alliance CISOs

EDUCAUSE

Internet2 and InCommon Staff

Internet2 TIER Security and Audit Working Group

Published Security Incident Reports

2016-11-17-01 (InCommon IdPs release duplicate persistent nameID to ORCID SP)