Kansas State University

IT Security Incident Reporting and Response Policy

Chapter 3434

Issued April 15, 2009

Table of Contents

.010 Purpose

.020 Scope

.030 Effective Date

.040 Authority

.050 Policy

.060 Definitions

.070 Roles and Responsibilities

.080 Implementing Procedures

.090 Related Laws, Regulations, or Policies

.100 Questions/Waivers

.010 Purpose

This policy governs the actions required for reporting or responding to security incidents involving K-State information and/or information technology resources to ensure effective and consistent reporting and handling of such events.

.020 Scope

This policy applies to all members of the University community, including students, personnel, units, and affiliates using University information technology resources or data.

.030 Effective Date

This policy became effective on January 8, 2009

.040 Authority

For major incidents, which include a breach of personal identity information (PII), Kansas Regents IT Council (RITC) policy requires escalation to the top administration on campus and prompt notification of the Board of Regents office. Likewise, Kansas Senate bill 196 that went into effect in January 2007 requires a prompt investigation and notification of potential victims in response to a security incident involving a breach of PII.

.050 Policy

All members of the University community are responsible for reporting known or suspected information or information technology security incidents. All security incidents at K-State must be promptly reported to K-State’s Chief Information Security Officer (CISO) and other appropriate authority(ies) as outlined below in Section .080: Implementing Procedures.

Incident response will be handled appropriately based on the type and severity of the incident in accordance with the Incident Response Summary Table below in Section .080: B.2 and K-State's IT Security Incident Management Procedures. Handling of security incidents involving confidential data will be overseen by an Executive Incident Management Team.

All individuals involved in investigating a security incident should maintain confidentiality, unless the Chief Information Officer authorizes information disclosure in advance.

.060 Definitions

Security incident

Any real or suspected event that may adversely affect the security of K-State information or the systems that process, store, or transmit that information. Examples include:

• Unauthorized access to data, especially confidential data like a person’s name and social security number
• Computer infected with malware such as a worm, virus, Trojan Horse, or botnet
• Reconnaissance activities such as scanning the network for security vulnerabilities
• Denial of Service attack
• Web site defacement
• Violation of a K-State security policy
• Security weakness such as an un-patched vulnerability

Personal identity information (PII)

K.S.A. § 21-6107: Crimes involving violations of personal rights defines PII as including, but not limited to: an individual's name; date of birth; address; telephone number; driver's license number or card or nondriver's identification number or card; social security number or card; place of employment; employee identification numbers or other personal identification numbers or cards; mother's maiden name; birth, death or marriage certificates; electronic identification numbers; electronic signatures; and any financial number, or password that can be used to access a person's financial resources, including, but not limited to, checking or savings accounts, credit or debit card information, demand deposit or medical information. For K-State's purposes, PII also includes ones name in combination with a passport number.

.070 Roles and Responsibilities

1. The incident manager is responsible for managing the response to a security incident as defined in the incident response summary table in Section .080.B.2 below.
2. The Executive Incident Management Team oversees the handling of security incidents involving confidential data (e.g., personal identity information). This team has authority to make decisions related to the incident and to notify appropriate parties. The team consists of:
   • Senior administrator for the affected unit
   • Chief Information Officer
   • Chief Information Security Officer
   • Representative from the Office of General Counsel
   • Assistant Vice President for Media Relations
   • Others as needed (for example, K-State Police for criminal incidents)

.080 Implementing Procedures

1. Reporting Security incidents
   Any member of the K-State community who suspects the occurrence of a security incident must report incidents through the following channels:
   1. All suspected high severity events as defined in Section .080.B.1 below , including those involving possible breaches of personal identity information, must be reported directly to the Chief Information Security Officer (CISO) as quickly as possible by phone (preferred), email, or in person. If the CISO cannot be reached, contact the Chief Information Officer (CIO).
   2. All other suspected incidents must also be reported to the CISO. These incidents may be first reported to departmental IT support personnel, the unit's Security Incident Response Team (SIRT) representative, or the unit head who can then contact the CISO. Reports should be made by sending email to abuse@k-state.edu (preferred) or by notifying the CISO by phone, email, or in person.
   3. For detailed information about reporting IT security incidents, see the K-State IT Security Incident Management Procedures.
2. Responding to Security Incidents
   1. Incident Severity
      Incident response will be managed based on the level of severity of the incident. The level of severity is a measure of its impact on or threat to the operation or integrity of the institution and its information. It determines the priority for handling the incident, who manages the incident, and the timing and extent of the response. Four levels of incident severity will be used to guide incident response: high, medium, low, and NA (Not Applicable).
      1. High
         The severity of a security incident will be considered "high " if any of the following conditions exist:
         1. Threatens to have a significant adverse impact on a large number of systems and/or people (for example, the entire institution is affected)
         2. Poses a potential large financial risk or legal liability to the University
         3. Threatens confidential data (for example, the compromise of a server that contains or names with social security numbers or credit card information)
         4. Adversely impacts an enterprise system or service critical to the operation of a major portion of the university (for example, email, student information system, financial information system, human resources information system, learning management system, Internet service, or a major portion of the campus network)
         5. Poses a significant and immediate threat to human safety, such as a death-threat to an individual or group.
         6. Has a high probability of propagating to many other systems on campus and/or off campus and causing significant damage or disruption
      2. Medium
         The severity of a security incident will be considered "medium" if any of the following conditions exist:
         1. Adversely impacts a moderate number of systems and/or people, such as an individual department, unit, or building
         2. Adversely impacts a non-critical enterprise system or service
         3. Adversely impacts a departmental system or service, such as a departmental file server
         4. Disrupts a building or departmental network
         5. Has a moderate probability of propagating to other systems on campus and/or off campus and causing moderate damage or disruption
      3. Low
         Low severity incidents have the following characteristics:
         1. Adversely impacts a very small number of systems or individuals
         2. Disrupts a very small number of network devices or segments
         3. Has little or no risk of propagation or causes only minimal disruption or damage in their attempt to propagate
      4. NA (Not Applicable)
         This is used for events reported as a suspected IT security incident but upon investigation of the suspicious activity, no evidence of a security incident is found.
   2. Incident Response Summary Table
      The following table summarizes the handling of IT security incidents based on incident severity, including response time, the responsible incident managers, and notification and reporting requirements. Detailed procedures for incident response and management are further defined in the K-State IT Security Incident Management Procedures.

* See K-State IT Security Incident Management Procedures for details about the Post-Incident Report.

.090 Related Laws, Regulations, or Policies

1. K-State IT Security Incident Management Procedures
2. K-State IT security team
3. K-State Security Incident Response Team (SIRT)
4. Kansas Regents IT Council (RITC) Security Incident Policy and Procedure (PDF) – April 2005
5. Enterprise IT Security Reporting Protocols (PDF), State of Kansas IT Security Council, October 2007
6. State of Kansas, ITEC Information Technology Policy 7230, Revision1: General Information Technology Enterprise Security Policy
7. K.S.A. § 21-6107: Crimes involving violations of personal rights 

.100 Questions/Waivers

The Chief Information Officer (CIO) is responsible for this policy. The CIO or designee must approve any exception to this policy or related procedures. Questions should be directed to the Chief Information Security Officer.