Skip to content
Jump to bottom

Version 1.4 generifying further #3

Merged
merged 1 commit into from Sep 9, 2019
+42 −55
Merged

Version 1.4 generifying further #3

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
97 changes: 42 additions & 55 deletions main.adoc
View file
Open in desktop
@@ -1,23 +1,23 @@
:opening-bracket: [
:closing-bracket: ]
== InCommon Federation Security Incident Handling Framework
== Internet2 Trust and Identity Services Incident Handling Framework

*Prepared by:* Nicholas Roy, Director of Technology and Strategy, InCommon +
*Version:* 1.3 +
*Date:* July 15, 2019
*Prepared by:* Nicholas Roy, Director of Technology and Strategy, InCommon/Internet2 Trust and Identity Services +
*Version:* 1.4 +
*Date:* September 5, 2019



*Document Title: InCommon Security Incident Handling Framework* +
*Document Title: Internet2 Trust and Identity Services Security Incident Handling Framework* +
*Repository ID: OBTAIN NEW* +
*DOI: OBTAIN NEW* +
*Persistent URL: OBTAIN NEW* +
*Authors: Nicholas Roy* +
*Authors: Nicholas Roy* +
*Publication Date: UPDATE* +
*Sponsor: InCommon Steering Committee* +
*Superseded documents: None* +
*Proposed future review date: August 1, 2021* +
*Subject tags: security, incident, trust, incommon, services*
*Sponsor: Vice President, Internet2 Trust and Identity Services* +
*Superseded documents: None* +
*Proposed future review date: September 5, 2021* +
*Subject tags: security, incident, trust, identity, incommon, services*

*© 2019 Internet2* +
*This work is licensed under a https://creativecommons.org/licenses/by/4.0/[Creative Commons Attribution 4.0 International License.]*
Expand All @@ -35,6 +35,7 @@
|Publication|Revisions from Internet2 General Counsel|January 30, 2017|1.1|Nicholas Roy
|Publication|Revisions to fix typos and add document repository information|February 27, 2018|1.2|Nicholas Roy
|Draft|Support other InCommon services|July 15, 2019|1.3|Nicholas Roy|
|Draft|Changed from InCommon to Internet2 Trust and Identity Services|September 5, 2019|1.4|Nicholas Roy|
|===

<<<
Expand All @@ -44,10 +45,9 @@
=== Table of Contents


InCommon Security Incident Handling Framework +
Internet2 Trust and Identity Services Security Incident Handling Framework +
Table of Contents +
Governing Language +
Mission Statement of InCommon CSIRT +
Mission Statement of Internet2 Trust and Identity Services CSIRT +
Definition of “Security Incident” +
Initial Contact/Notification and Triage +
Generalized Procedure for When Action Is Required +
Expand All @@ -59,25 +59,15 @@ Criticality +
Communications +
Traffic Light Protocol for Exchange of Information +
Incident Handling Actions Matrix +
Appendix A: Foundational Documents +
Appendix A: References +
Appendix B: Acknowledgements +

=== Governing Language
WARNING: We likely need different governing language to make this apply beyond the federation, since this references the FEDERATION OPP.
=== Mission Statement of Internet2 Trust and Identity Services CSIRT

The InCommon Federation Operating Policies and Practices [1] document states, as of July, 2016:
Internet2’s Trust and Identity Services 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 Internet2's Trust and Identity (TI) Services so that they may be relied upon by users for mission-critical and security-sensitive operations on an ongoing basis. To that end, the CSIRT will:

10.3.1 - Suspension for reasons of security +
_A Participant may request the suspension of any Federation services in the case of Administrator credential compromise, participant key compromise, or other security compromise within the Participant's systems. This request may be made via e-mail or telephone from the Executive or Administrator and will be verified by InCommon using trusted communication channels. Suspension may include processes such as revoking credentials, or removing or modifying Metadata._

_If InCommon suspects any compromise or negligence on the part of a Participant, it will make reasonable efforts to contact Participant to resolve the issue. In the case of a significant security incident that poses an unacceptable risk to InCommon or other federation participants, InCommon may take immediate remediation actions commensurate with the impact of the incident._

=== 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 relevant aspects of InCommon participants’ systems
* Receive information about security-related threats to TI service infrastructure
* Receive information about security-related threats to relevant aspects of TI service users'/deployers' 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
Expand All @@ -89,7 +79,7 @@ A computer security Incident is: A violation or imminent threat of violation of

=== 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)
Any party may make the CSIRT aware of a relevant security incident or disclosure via one of the following mechanisms (available 24x7x365)

. *_Call this number: +1 734 352 7045 (PREFERRED)_*
. *_Send an email to: security@incommon.org_*
Expand All @@ -98,13 +88,13 @@ Any party may make InCommon’s CSIRT aware of a relevant security incident or d

*_Inquiries from any law enforcement agency regarding a security incident, including formal legal process such as subpoenas and warrants, must be directed to the General Counsel of Internet2._*

*DO NOT* communicate any sensitive information via these channels. InCommon staff will set up a secure communications channel with you, if need be, after your initial request is received
*DO NOT* communicate any sensitive information via these channels. Internet2 staff will set up a secure communications channel with you, if need be, after your initial request is received

InCommon’s CSIRT will accept, evaluate and reply (when necessary and deemed appropriate) to valid submissions as soon as possible, but in no event later than 24 hours after receipt of the notice.
The CSIRT will accept, evaluate and reply (when necessary and deemed appropriate) to valid submissions as soon as possible, but in no event later than 24 hours after receipt of the notice.

=== Generalized Procedure for When Action Is Required

Upon receipt of information about a possible security threat to InCommon, the CSIRT will:
Upon receipt of information about a possible security threat to an Internet2 Trust and Identity Services service offering, the CSIRT will:

. Identify an incident handling lead
. 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.
Expand All @@ -117,20 +107,20 @@ Upon receipt of information about a possible security threat to InCommon, the CS
Roles 1-4 make up the standing CSIRT, with all roles under 5 filled on an as-needed basis.

. CSIRT Executive Sponsor, typically the Internet2 Vice President for Trust and Identity Services
. Incident Lead, typically an InCommon technical director or manager
. Incident Lead, typically an Internet2 Security Lead
. Incident Communications Representative, typically an Internet2 marketing and communication director
. REN-ISAC liaison
. 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)
.. Lead (a role which may be assigned to any of the team members, but should remain lead throughout the handling of an incident)
.. Executive Sponsor
.. Steering Liaison
.. Ops Advisory Liaison
.. InCommon Operations Representative
.. Service Advisory Committee Liaison
.. Service Operations Representative
.. Internet2 Communications Representative
.. Internet2 Chief Information Security Officer Representative
.. Other relevant internal Internet2 areas
.. REN-ISAC Representative and Liaison
.. Law enforcement Representative and Liaison
.. Law Enforcement Representative and Liaison
.. Legal Representative

=== Assessment of an Incident
Expand All @@ -139,46 +129,45 @@ This section is a set of guidelines to allow the named incident handling lead to

==== 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.
To be in scope for action by the CSIRT, mitigation of the incident must essentially depend on one or more changes to TI service operations which involve TI 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:

. InCommon Operations or its upstream or third-party providers (for example, cloud hosting providers, multifactor authentication providers, etc.) on which its operations depend.
. The systems or services of an InCommon Participant relevant to their InCommon participation, such as Identity Provider or Service Provider software or related cryptographic materials.
. Any other operational aspect of InCommon’s trust services.
. TI Operations or its upstream or third-party providers (for example, cloud hosting providers, multifactor authentication providers, etc.) on which its operations depend.
. The systems or services of a Trust and Identity Services participant/connector relevant to their use of such services, such as Identity Provider or Service Provider software or related cryptographic materials, RADIUS infrastructure, etc.
. Any other operational aspect of TI 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.
are deemed to be in-scope for TI'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 Internet2) for further assessment and handling.

==== Nature

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

. 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.
. 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.
. 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/[https://www.incommon.org/]).
. 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.
. 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 TI or its participants’/connectors' networks or systems as those networks or systems function in a core or supporting role within the portfolio of TI services.
. Use of a system or network in any way that compromises TI or its participants'/connectors' networks or systems as those networks or systems function in a core or supporting role within the portfolio of TI services.
. 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 TI services (for more information on TI services, see: https://www.incommon.org/[https://www.incommon.org/]).
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 a relevant service operations group 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.
*Normal* - an event that does not affect critical production systems or the trustworthy flow of identity/trust-related data across TI 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:

. Health and safety
. 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
. Ability of InCommon or one or more of its participants to provide services or conduct business via InCommon services
. Anything deemed an emergency by virtue of related InCommon policies or the CSIRT Executive Sponsor
. Critical controls on systems which are relied upon for the trustworthy exchange of identity/trust data between TI services' participants/connectors and which utilize TI services for facilitation of this data exchange
. Ability of TI or one or more of its participants to provide services or conduct business via TI services
. Anything deemed an emergency by virtue of related governing 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 will be prepared at the request of Counsel. The review will include root cause analysis and remediation steps, and should be conducted by the Incident Lead, and a report should be prepared which may be shared with appropriate audiences.
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 TI services' particpant/connector 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 will be prepared at the request of Counsel. The review will include root cause analysis and remediation steps, and 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.

Expand Down Expand Up @@ -208,7 +197,7 @@ _Reference: TLP levels matrix, from US-CERT [4]_

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]

All information known by InCommon relating to the security incident, including, as applicable, log files and other digital evidence, will be retained by InCommon for 7 years.
All information known by Internet2 relating to the security incident, including, as applicable, log files and other digital evidence, will be retained for 7 years.

|===
||Normal |Escalation |Emergency
Expand All @@ -234,9 +223,7 @@ All information known by InCommon relating to the security incident, including,
|CSIRT team conducts an after-action review as part of security continuous improvement process. These decisions are documented by the Lead or designee.||X|X
|===

=== Appendix A: Foundational Documents

{opening-bracket}1{closing-bracket} https://www.incommon.org/docs/policies/InCommonFOPP.pdf[InCommon Federation Operating Policies and Practices]
=== Appendix A: References

{opening-bracket}2{closing-bracket} West Brown, Stikvoort, Kossakowski, Killcrece, Ruefle, Zajicek. Handbook for Computer Security Incident Response Teams (CSIRTs) April, 2003. Carnegie-Mellon University Software Engineering Institute, http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=6305[CMU/SEI-2003-HB-002]

Expand Down