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.2
-Date: February 27, 2017
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
-Repository ID: TI.100.1
-DOI: 10.26869/TI.100.1
-Persistent URL: http://doi.org/10.26869/TI.100.1
-Authors: Nicholas Roy
-Publication Date: January 30, 2017
-Sponsor: InCommon Steering Committee
-Superseded documents: None
-Proposed future review date: March 1, 2019
-Subject tags: federation, trust, incommon
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
+Publication Date: UPDATE
+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
© 2018 Internet2
+
© 2019 Internet2
This work is licensed under a Creative Commons Attribution 4.0 International License.
Change Log
-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 |
+
THIS PAGE INTENTIONALLY LEFT BLANK<
Table of Contents
-InCommon Federation 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
@@ -548,35 +571,22 @@
Table of Contents
Communications
Traffic Light Protocol for Exchange of Information
Incident Handling Actions Matrix
-Appendix A: Foundational Documents
+Appendix A: References
Appendix B: Acknowledgements
-Governing Language
-
-The InCommon Federation Operating Policies and Practices [1] document states, as of July, 2016:
-
-
-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
+Mission Statement of Internet2 Trust and Identity Services 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:
+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:
-
-
Receive information about security-related threats to InCommon infrastructure
+Receive information about security-related threats to TI service infrastructure
-
-
Receive information about security-related threats to InCommon participants’ federating systems
+Receive information about security-related threats to relevant aspects of TI service users'/deployers' systems
-
Assess the risk of such threats
@@ -600,9 +610,9 @@ Definition of “Security Incident”<
-Initial Contact/Notification and Triage
+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)
@@ -621,16 +631,16 @@ Initial Contact/Notification a
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 Federation 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:
@@ -663,7 +673,7 @@ Roles
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
@@ -685,10 +695,10 @@ Roles
Steering Liaison
-
-
Ops Advisory Liaison
+Service Advisory Committee Liaison
-
-
InCommon Operations Representative
+Service Operations Representative
-
Internet2 Communications Representative
@@ -703,7 +713,7 @@ Roles
REN-ISAC Representative and Liaison
-
-
Law enforcement Representative and Liaison
+Law Enforcement Representative and Liaison
-
Legal Representative
@@ -722,7 +732,7 @@ Assessment of an Incident
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:
@@ -730,18 +740,18 @@ Scope
-
-
InCommon Operations or its upstream or third-party providers (for example, cloud hosting providers, multifactor authentication providers, etc.) on which its operations depend.
+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 an InCommon Participant relevant to federation participation, such as Identity Provider or Service Provider software or related cryptographic materials.
+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 InCommon’s trust services.
+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.
@@ -752,17 +762,14 @@ Nature
-
-
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.
+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.
-
-
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/).
+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.
-
-
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.
+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/).
+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.
@@ -773,7 +780,7 @@ 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.
@@ -787,13 +794,13 @@ Criticality
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
+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 InCommon or one or more of its participants to provide services or conduct business via InCommon services
+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 InCommon policies or the CSIRT Executive Sponsor
+Anything deemed an emergency by virtue of related governing policies or the CSIRT Executive Sponsor
@@ -805,7 +812,7 @@ Criticality
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.
@@ -816,7 +823,7 @@ Traffic Light Proto
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.
-
+
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]
-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.
-
+
Incident Handling Actions Matrix
-Appendix A: Foundational Documents
-
+Appendix A: References
[2] 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
@@ -1040,7 +1044,7 @@ Appendix B: Acknowledgements
Table of Contents
InCommon Federation 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
@@ -548,35 +571,22 @@
Table of Contents
CommunicationsTraffic Light Protocol for Exchange of Information
Incident Handling Actions Matrix
-Appendix A: Foundational Documents
+Appendix A: References
Appendix B: Acknowledgements
Governing Language
-The InCommon Federation Operating Policies and Practices [1] document states, as of July, 2016:
-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
+Mission Statement of Internet2 Trust and Identity Services 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:
+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:
-
-
Receive information about security-related threats to InCommon infrastructure
+Receive information about security-related threats to TI service infrastructure
-
-
Receive information about security-related threats to InCommon participants’ federating systems
+Receive information about security-related threats to relevant aspects of TI service users'/deployers' systems
-
Assess the risk of such threats
@@ -600,9 +610,9 @@Definition of “Security Incident”<
Initial Contact/Notification and Triage
+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)
-
@@ -621,16 +631,16 @@
Initial Contact/Notification a
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 Federation 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:
-
@@ -663,7 +673,7 @@
-
-
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
@@ -685,10 +695,10 @@Roles
Steering Liaison
-
-
Ops Advisory Liaison
+Service Advisory Committee Liaison
-
-
InCommon Operations Representative
+Service Operations Representative
-
Internet2 Communications Representative
@@ -703,7 +713,7 @@Roles
REN-ISAC Representative and Liaison
-
-
Law enforcement Representative and Liaison
+Law Enforcement Representative and Liaison
-
Legal Representative
@@ -722,7 +732,7 @@Assessment of an Incident
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:
@@ -730,18 +740,18 @@Scope
-
-
InCommon Operations or its upstream or third-party providers (for example, cloud hosting providers, multifactor authentication providers, etc.) on which its operations depend.
+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 an InCommon Participant relevant to federation participation, such as Identity Provider or Service Provider software or related cryptographic materials.
+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 InCommon’s trust services.
+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.
@@ -752,17 +762,14 @@Nature
@@ -773,7 +780,7 @@-
-
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.
+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.
-
-
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/).
+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.
-
-
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.
+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/). +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.
@@ -805,7 +812,7 @@Escalation - an event that affects production systems and requires change control steps be followed as part of a response.
@@ -787,13 +794,13 @@Criticality
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
+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 InCommon or one or more of its participants to provide services or conduct business via InCommon services
+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 InCommon policies or the CSIRT Executive Sponsor
+Anything deemed an emergency by virtue of related governing policies or the CSIRT Executive Sponsor
Criticality
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.
@@ -816,7 +823,7 @@Traffic Light Proto
-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.
+
@@ -862,9 +869,9 @@ 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]
--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.
+
@@ -998,10 +1005,7 @@ Incident Handling Actions Matrix
-Appendix A: Foundational Documents
- +Appendix A: References
@@ -1040,7 +1044,7 @@[2] 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
Appendix B: Acknowledgements
-
-
Roles
CSIRT Executive Sponsor, typically the Internet2 Vice President for Trust and Identity Services