1. K-State home
  2. »Information Technology Services
  3. »IT Security
  4. »IT security policies and procedures
  5. »IT security procedures
  6. »IT security incident management

Information Technology Services

IT security incident management

Table of Contents

  1. Purpose
  2. Scope
  3. Definitions
  4. Security Incident Classification System
    1. Incident Categories
    2. Incident Severity
    3. Incident Response Summary Table
  5. Security Incident Reporting and Detection
    1. Security Incident Reporting
    2. Incident Detection
  6. Incident Handling and Response
    1. Analysis
    2. Containment
    3. Eradication and Recovery
    4. Follow-up
  7. Collection and Preservation of Evidence
  8. Incidents Involving Confidential Personal Identity Information
    1. State of Kansas Law
    2. Executive Incident Management Team
    3. Credit Card Information
    4. Procedure for handling a breach of confidential personal identity data
    5. Deciding whether or not to notify victims
  9. Incident Tracking and Reports
    1. Incident Tracking System
    2. Annual Report
    3. Post-Incident Report
  10. Related K-State and State of Kansas Policies and Procedures
  11. References
  12. Appendix 1. Kansas State University IT Security Post-Incident Report
  13. Appendix 2. Sample Notification Letter to Victims of Possible Identity Theft
  1. Purpose
    The purpose of these procedures is to insure effective and consistent management of security incidents involving K-State information and/or information technology resources. These procedures implement K-State's IT Security Incident Reporting and Response Policy.
  2. Scope
    These procedures apply to all University personnel, units, and affiliates with responsibility to respond to security incidents involving University IT resources or data.
  3. Definitions
    These procedures apply to all University personnel, units, and affiliates with responsibility to respond to security incidents involving University IT resources or data.
    Confidential Data
    Highly sensitive data intended for limited, specific use by a workgroup, department, or group of individuals with a legitimate need-to-know. See K-State's Data Classification and Security Policy, section .052.C for an expanded definition and examples.
    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)
    An individual's name (first name and last name, or first initial and last name) in combination with one or more of the following: a) Social security number, b) driver’s license number or state identification card number, c) passport number, or c) financial account number, or credit or debit card number, alone or in combination with any required security code, access code or password that would permit access to a consumer's financial account.
  4. Security Incident Classification System
    Security incidents will be classified according to incident categories and severity of incident in order to determine the appropriate response. A security incident classification scheme will be maintained by the Chief Information Security Officer to describe security events and support incident tracking over time.
    1. Incident Categories
      The following categories will be used to describe IT security incidents at Kansas State University. Several categories may apply to a single incident. The examples listed in each category are not meant to be exhaustive.
      1. Confidential personal identity data exposure
        • Social Security Numbers with or without names
        • Credit Card information
        • Identity theft
        • Other
      2. Criminal activity/investigation
        • Subpoena, search warrant, or other court order
        • Litigation hold request (aka e-Discovery)
        • Online theft, fraud
        • Threatening communication
        • Child pornography
        • Physical theft, break-in
      3. Denial of Service
        • Single or distributed (DoS or DDoS)
        • Inbound or outbound
      4. Digital Millennium Copyright Act (DMCA) violation
        • Official DMCA notification from copyright owner or legal representative
        • Illegal distribution of copyrighted or licensed material (movies, music, software, games)
        • Illegal possession of copyrighted or licensed material
      5. Malicious code activity
        • Worm, virus, Trojan
        • Botnet
        • Keylogger
        • Rootkit
      6. Policy violation
        • K-State policy violation
        • Violation of student code of conduct
        • Personnel action/investigation
      7. Reconnaissance activity
        • Port scanning
        • Other vulnerability scanning
        • Unauthorized monitoring
      8. Rogue server or service
        • Rogue file/FTP server for music, movies, pirated software, etc.
        • Phishing scam web server
        • Botnet controller
      9. Spam source
        • Spam relay
        • Spam host
        • K-State computer on a block list
      10. Spear Phishing
        • Scam e-mail specifically targeting a K-State e-mail addresses that tries to trick people into divulging private information
      11. Unauthorized access
        • Abuse of access privileges
        • Unauthorized access to data
        • Unauthorized login attempts
        • Brute force password cracking attempts
        • Stolen password(s)
      12. Un-patched vulnerability
        • Vulnerable operating system
        • Vulnerable application
        • Vulnerable web site/service
        • Weak or no password on an account
      13. Web/BBS defacement
        • Defacement of web site
        • Inappropriate post to wiki, blog, etc.
        • Redirected web site
      14. No Incident
        • When investigation of suspicious activity finds no evidence of a security incident
    2. Incident Severity
      The severity of incident is a subjective 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.

      The following factors are considered in determining the severity of an incident:
      • Scope of impact – how many people, departments, or systems does it affect?
      • Criticality of the system or service – how important is it to the continuing operation of the institution? What would be the impact on the business, either functional or financial, if this system or service were unavailable or corrupted?
      • Sensitivity of the information stored on or accessed through the system or service – does it contain confidential data, such as personal identity information or credit card information?
      • Probability of propagation – how likely is it that the malware or negative impact will spread or propagate to other systems, especially to other systems off campus?
      Four levels of incident severity will be used to guide incident response: high, medium, low, and NA (“Not Applicable”), as seen below:
      1. High
        The severity of a security incident will be considered “high” if any of the following conditions exist:
        • Threatens to have a significant adverse impact on a large number of systems and/or people (for example, the entire institution is affected)
        • Poses a potential large financial risk or legal liability to the University
        • Threatens confidential data (for example, the compromise of a server that contains or names with social security numbers or credit card information)
        • Adversely impacts an enterprise system or service critical to the operation of a major portion of the university (for example, e-mail, student information system, financial information system, human resources information system, learning management system, Internet service, or a major portion of the campus network)
        • Poses a significant and immediate threat to human safety, such as a death-threat to an individual or group.
        • Has a high probability of propagating to many other systems on campus and/or off campus and causing significant damage or disruption
        High severity incidents require an immediate response and focused, dedicated attention by the CISO and other appropriate University officials and IT security staff until remediated. These incidents also have extensive notification and reporting requirements, as outlined in the Incident Response Summary Table below. A Post-Incident Report is required.
      2. Medium
        The severity of a security incident will be considered “medium” if any of the following conditions exist:
        • Adversely impacts a moderate number of systems and/or people, such as an individual department, unit, or building
        • Adversely impacts a non-critical enterprise system or service
        • Adversely impacts a departmental system or service, such as a departmental file server
        • Disrupts a building or departmental network
        • Has a moderate probability of propagating to other systems on campus and/or off campus and causing moderate damage or disruption
        Medium severity incidents require a quick response by appropriate personnel (usually from the affected unit) who have primary responsibility for handling the incident. Notification requirements are outlined in the Incident Response Summary Table below. A Post-Incident Report is not required unless requested by the Chief Information Officer or other appropriate administrator.
      3. Low
        Low severity incidents have the following characteristics:
        • Adversely impacts a very small number of systems or individuals
        • Disrupts a very small number of network devices or segments
        • Has little or no risk of propagation or causes only minimal disruption or damage in their attempt to propagate
        Since a single compromised system can “wake up” and negatively affect other systems at any time, appropriate personal (usually the technical support staff responsible for the system) must respond as quickly as possible, no later than the next business day. Notification requirements are outlined in the Incident Response Summary Table below. A Post-Incident Report is not required unless requested by the CIO.
      4. NA
        This is used for events reported as a suspected IT security incident but upon investigation, no evidence of a security incident is found. This usually corresponds to the incident category, "No Incident."
    3. 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.

  5. Security Incident Reporting and Detection
    1. Security Incident Reporting
      1. All members of the University community are responsible for promptly reporting suspected or known security incidents, including an observed or suspected security weakness in K-State systems or services, in accordance with K-State's IT Security Reporting and Response Policy.
      2. All suspected high severity incidents, 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:

        Chad Currier
        Information Security and Compliance
        Email: ccurrier@k-state.edu

        If the CISO is not available, contact K-State's Chief Information Officer (CIO):

        Gary Pratt
        Director Information Technology Services
        Kansas State University
        2323 Anderson Avenue, Suite 116
        Manhattan, KS 66506
        Phone: 785-532-6520
        Email: gpratt@k-state.edu

      3. All other suspected incidents must also be reported to any of the following:
        1. Send email to abuse@k-state.edu (preferred)
        2. Contact the CISO listed above
        3. Contact any member of the Office of Information Security and Compliance. Any incident that is not high severity may be reported first to departmental IT support personnel, the unit's Security Incident Response Team (SIRT) representative, or the unit head before reporting it to the people listed above.
      4. Warning: If reporting a suspected security weakness or system vulnerability, do not attempt to confirm it by testing the weakness since that could be interpreted as a potential misuse of the system or cause damage to it.
      5. When receiving a report of a suspected or confirmed security incident, the CISO or designee will gather as much of the following information as possible:
        1. Name, affiliation, e-mail address, and phone number of person reporting the incident
        2. Description of the suspected security incident
        3. Information to help identify the source of the suspicious activity, like an IP address or an e-mail message with full headers.
        4. Date(s) and time(s) of the suspicious activity, noting the time zone.
        5. Evidence of suspicious activity (for example, full headers of an e-mail message suspected to be spam originating at K-State, appropriate log records, etc.)
      6. In addition to documenting the initial report, the CISO or designee will:
        1. Create an entry in the University security incident tracking system (see “Incident Tracking and Reporting” below)
        2. Initiate appropriate incident handling procedures
        3. As appropriate, communicate with and provide feedback about the results to those reporting the incident once the incident has been handled and closed
    2. Incident Detection
      1. In addition to reports from the University community of suspected or confirmed security incidents, anomalous events may be detected that indicate potential security incidents. Having mechanisms to detect anomalous events early and reliably helps minimize their impact. Detection can be very challenging since there are potentially so many different types of incidents and vectors for attack on a huge number and variety of systems and networks. Thus no one person, unit, or technology can possible monitor it all. Detection is therefore a collaborative effort among University and departmental IT and security personnel.
      2. Channels for detecting possible security incidents include:
        1. E-mail sent to abuse@k-state.edu or security@k-state.edu
        2. E-mail sent directly to the CISO
        3. Phone call to the CISO
        4. Automated botnet detection system
        5. REN-ISAC notification of suspected malicious activity
        6. Network performance monitoring (e.g., noticing a congested network segment)
        7. Notification from a copyright owner or representative sent to K-State’s designated copyright agent
        8. Court orders (for example, a subpoena or search warrant). All IT-related court orders should be directed to the Office of General Counsel.
        9. A customer contacts the IT Help Desk
        10. Monitoring security mailing lists and web sites for threat alerts (for example, the SANS Internet Storm Center — isc.sans.org)
        11. Monitoring external sources of information about new vulnerabilities and exploits and about incidents occurring at other organizations
        12. Employing passive detection techniques such as network flow analysis (top talkers, traffic volume thresholds, communication with known malicious sites, etc.); log file analysis (operating system, system services, databases, applications, network devices, etc.); intrusion detection/prevention systems, and monitoring alerts from security systems (firewalls, anti-virus protection, intrusion detection/prevention systems, wireless network management systems that detect rogue wireless access points, etc.)
        13. Employing active detection techniques such as port scans looking for unusual services, vulnerability scans, manual monitoring of radio frequencies to detect unauthorized wireless access points, and file integrity verification that detects changes to important files
  6. Incident Handling and Response
    Security incident response will be typically handled through several stages: analysis, containment, eradication and recovery, and follow-up.
    1. Analysis
      Once a potential security incident is reported or anomalous activity detected, analysis must be performed to determine if it is indeed symptomatic of a security incident and to understand the nature of the incident for proper remediation.
      1. Goals
        1. Understand the nature and scope of the incident.
        2. Collect enough information about the incident so the response team can prioritize the next steps in handling the incident, which is normally containment.
        3. Determine if confidential data is involved in the incident.
      2. Components of security incident analysis
        1. Collaboration with other professionals as needed (for example, a security analyst, network analyst, system administrator, and application manager working as a team to analyze the system exhibiting the anomalous behavior; relevant SIRT representative; consulting external sources like REN-ISAC, US-CERT, SANS, etc.).
        2. Understanding normal system and network behavior so anomalous activity can be identified
        3. Analysis and correlation of as many indicators as possible, such as monitoring network traffic to/from the host suspected of being compromised, network packet captures for more in-depth analysis, log file analysis, interviews with users and/or system administrators, etc.
        4. Initial determination of the incident’s scope (How many systems affected? Is it actively propagating? If so, how?)
        5. Research of the specific malware or type of attack
        6. Collection of additional data which may require permission from the Chief Information Officer (CIO) per K-State's Information Technology Usage Policy.
      3. Procedures for Analysis
        1. Detect security event (see section V.B. above)
        2. Analyze event data to determine if it is indicative of a security incident and get an initial impression of the nature and scope of the incident
        3. Notify the CISO who may assist with the initial analysis of the event data. Other appropriate personnel may be notified at this point as well, like relevant IT support staff, the SIRT representative, or a supervisor or department head.
        4. The CISO will record it in the Incident Tracking System (see section VI.E below)
        5. If there’s a need to access personal data, like an individual’s e-mail or files, in order to gather more information about the incident, first get approval from the CIO per K-State's Information Technology Usage Policy.
        6. Determine if any confidential data was or might have been affected.
        7. If the incident is of high or medium severity:
          1. Image the hard drive, memory, and any other relevant media before performing analysis that might alter evidence. For hard drives, bit-by-bit copies are required in case deleted files need to be recovered. This is especially important for cases that involve confidential data, possible criminal investigation, or sensitive personnel actions.
          2. Preserve the original media in a secure location and perform analysis on a copy of the data.
          3. Take notes on all actions taken.
        8. Perform additional forensics sufficient to characterize the incident (for example, analyze netflow data).
    2. Containment
      1. Goals
        Once a security incident in confirmed, the next step is typically containment.
        1. Stop potential loss of confidential data
        2. Protect other computers and information on the campus network and Internet (for example, keep the malware from spreading to other computers on or off campus)
        3. Prevent further damage to the compromised system and/or information
        4. Identify the location and owner of the computer(s) so they can be engaged in containment, eradication, and recovery
      2. Delaying containment
        In some cases, containment may need to be delayed in order to monitor the attacker’s activity, usually to collect more evidence. However, the risk of the compromised system being used to attack other systems or breach confidential data could lead to legal liabilities. Consult with the CISO Office of the University Attorney before deciding to delay containment.
      3. Procedures for containment
        1. Identify the location and/or owner of the system(s) involved in the incident by checking any of the following:
          1. Network ARP tables to map the IP address to a MAC address
          2. DHCP logs for MAC address and hostname
          3. "nbtscan" command to query host NetBIOS information
          4. Impulse SafeConnect (or the current network access control system) for registered student computers in the residence halls
          5. "netsum" info on unix.ksu.edu
          6. "Nomad" network device management software
          7. QRadar log file management system
        2. Determine if the computer needs to have its network access blocked. If so, this can be accomplished in several ways by the CTS network team:
          1. At the switch port, router interface, campus border
          2. Block the MAC address on all campus wireless networks (be sure to block it on all wireless networks, not just the residence halls, for example. Also block the wired network interface for the same computer if known).
          3. Disable dial-up modem access
          4. Disable VPN access
          5. If the offending device is an unauthorized wireless access point, its connection to K-State's data network must be blocked or removed. This can be done either via the network switch port to which it is connected, or by physically locating the device and unplugging it.
        3. The list of blocked computers is posted at  https://www.k-state.edu/its/networks/secure/blockedhosts.html, a site that is eID-password-protected and only accessible from on-campus IP addresses. This site lists the IP address, MAC address, building location, NetBIOS name if known, reason for the block, and the date of the block.
        4. The procedure for blocking/unblocking compromised computers is published on the Removing Compromised Computers from the Network page.
        5. An alternative to blocking all network access, if available, is to put the computer in a network quarantine that redirects its network traffic to a web server with instructions for the owner on how to proceed. This can be done in Impulse SafeConnect, for example.
        6. There may be cases when a specific protocol or UDP/TCP port needs to be blocked at the campus border or some other network interface in order to prevent propagation of the malware or to protect the campus from further attacks. Consult the CTS network team (network@k-state.edu) if considering this since they will have to implement it in campus firewalls or router Access Control Lists.
        7. Notify the system administrator and/or user responsible for the system. This is often done via the sirt-contacts LISTSERV mailing list when the CTS network team posts the block notification.
        8. Isolate the affected computer(s) either by unplugging the network cable (preferred) or shutting down the computer. Unplugging the network cable and leaving it running is best since shutdown can alter or destroy evidence, like with memory-resident malware. For wireless computers, the wireless interface can be disabled while leaving the computer running.
        9. Perform containment on the affected system(s) to keep it(them) from doing further damage to the computer or the data on it. This step depends on the nature of the compromise/malware, the need for preserving evidence (i.e., if you have to preserve evidence, don’t do anything to the computer until images of RAM and the hard drive are captured), the urgency of restoring the service hosted on the affected systems, and the time and resources available.
    3. Eradication and Recovery
      1. Goals
        1. Preserve evidence if it has not already done
        2. Perform additional analysis as needed to complete the investigation
        3. Remove the components of the incident impacting the affected systems, such as deleting the malicious code or disabling a compromised user account.
        4. Mitigate the attack vector so a similar incident does not occur (for example, patch the vulnerability used to compromise the system, apply standard system hardening procedures, adjust firewall rulesets, etc.)
        5. Restore systems to normal operation
      2. Procedures for Eradication and Recovery
        1. Determine the full scope of the incident – how many systems did it affect and therefore need to be repaired?
        2. Determine if any additional analysis is needed:
          1. Determine if any of the affected systems still need to have memory, hard drive(s), or other media imaged to preserve evidence; make an image copy of the media, preserve the original and perform analysis on the copy.
          2. Perform additional analysis, which may include:
            • Searching for malware by running an anti-virus scan and/or rootkit detection software, or looking for specific files known to be associated with current threats
            • Recover deleted files and file fragments
            • Perform a vulnerability scan
            • Check for unusual running processes and suspicious registry entries, especially ones that run on start-up
            • Determine open network ports and processes listening to those ports
            • Take a network packet capture and analyze the network traffic
            • Analyze network flow data
            • Analyze log files for unusual activity
            • Search for confidential data that may have been missed in the initial analysis
        3. If eradication and recovery keeps the system or service out of operation beyond the length of time that can be tolerated by the institution, invoke business recovery and continuity procedures to restore the service until normal operations can be resumed.
        4. Determine if a reformat/reinstall is required. Compromises that allow remote control of the system, gain root/Administrator privileges, and/or install a backdoor require a complete, clean re-install of the system for eradication.
          1. The CISO in conjunction with SIRT will determine when a specific type of compromise requires reformat/reinstall
          2. Reformatting the hard drive and re-installing from a backup tape prior to the compromise is acceptable, as is restoring from a clean image for those systems that use disk imaging technology like Symantec Ghost.
          3. Note that reinstalling must occur without exposing the vulnerable system to the campus network and the Internet
        5. If infected with malware and a reformat/reinstall is not required, remove the malware from the system. Running an anti-virus scan after updating virus definition/pattern file may suffice. Specific instructions for removing certain types of malware may also be found by searching the Internet.
        6. If the incident involves an unauthorized wireless access point, locate te device and contact the person responsible for it to ensure that it ceases operation.
        7. Mitigate the attack vector to prevent further instances. This may include:
          1. Patching vulnerabilities in the operating system and all applications software
          2. Changing passwords
          3. Placing the system behind a firewall
          4. Adjusting firewall rules
          5. Updating or installing new security software (for example, anti-virus software or a host-based personal firewall)
          6. Applying standard system security hardening techniques
          7. Passing a security assessment
          8. User training
        8. Restore network access if the system was blocked during the containment phase. The request to remove the network block must come from the appropriate SIRT representative in as described the Removing Compromised Computers from the Network page.
        9. Return the system to normal operations
    4. Follow-up
      1. Goals
        1. Determine lessons learned and make recommendations to prevent subsequent similar incidents
        2. Issue final reports
        3. Archive evidence and documentation
        4. Close out the incident
      2. Procedures
      3. The Incident Manager should confirm that all action items, investigations, analyses, and communications are completed
      4. Hold a Post-Incident Review session, if required, to determine ways to improve K-State’s management of security incidents and help prevent future incidents, not to assign blame.
        1. It should be scheduled to occur within 2-3 weeks of the incident’s remediation
        2. Include the incident response team and relevant stakeholders
        3. Appoint one person to record notes – successes, failures, recommendations, and action items
        4. Cover the following areas in the review session:
          • Are there any open issues? In other words, is remediation of the incident complete?
          • What could have prevented the incident?
          • How effectively was the incident handled (response time, communication, following procedures, containing spread/damage, etc.)?
          • Recommend changes to policy, procedure, and security controls to prevent and more effectively handle future incidents.
          • Identify any needed follow-up tasks and assign those tasks to individuals
      5. Evidence management — does any evidence need to be preserved longer? If so, for how long and by whom? Release or properly destroy any evidence that is no longer needed.
      6. Complete a Post-Incident Report if required (see “Post-Incident Report” in section IX.C below) and submit it to the Chief Information Officer. Security incidents with a severity category of "high" must complete a post-incident report. The CIO may request a post-incident report for any security incident.
      7. The CIO will review any recommendations and consider assigning resources to implement them.
      8. Archive reports and other relevant documents and communications ("work product") according to K-State's retention of records policy and procedures. This includes log files, timelines, recovered files, notes, network flow data, e-mails, etc.
      9. Close out incident tickets in the incident tracking system
  7. Collection and Preservation of Evidence
    When a security incident involves legal action against a person or organization, or a personnel action against a K-State employee, evidence must be collected, preserved, and presented to conform to the rules for evidence specified in the relevant jurisdiction(s). The following procedures help ensure the strong evidence trail needed for admissibility (making sure it can be used in court) and weight of evidence (high quality and completeness).
    1. When collecting evidence, follow all appropriate K-State policies and procedures, such as getting permission from the Chief Information Officer to access data in situations outlined in the Confidentiality and Privacy section of K-State's Information Technology Usage Policy.
    2. Document all actions taken in the collection and preservation of the evidence.
    3. For data stored on electronic media, such as a hard disk drive, USB flash drive, CD, DVD, or RAM, make a mirror image or copy (depending on applicable requirements) of the media. For example, if forensics will require recovering deleted files or file fragments from a hard drive, a bit-by-bit mirror image of the drive is required since a file-by-file copy will not capture that data.
      1. Have another person witness the imaging/copying process. If the incident involves a high profile or sensitive criminal case, have a law enforcement officer assist with the collection of the evidence, witness the imaging/copying process, and store the originals.
      2. Log all actions taken during the imaging/copying process, including date, time, and location the image/copy was made, who performed the actions and who witnessed it, and the tools and programs used.
      3. Label the original media and store it along with the log of the imaging/copying process in a secure location.
    4. Perform all forensics work on the image or copy, not the original. Additional images or copies of the original can be made if needed (for example, if forensics analysis on the copy destroyed some evidence and you need to continue analysis on a fresh copy).
    5. For paper-based documents, keep the original in a secure location and log the following:
      1. who found the document
      2. where it was found
      3. date and time it was found
      4. who witnessed the discovery
  8. Incidents Involving Confidential Personal Identity Information
    Incidents suspected of or known to involve confidential personal identity information, such as names with social security numbers or credit card numbers, have special legal, policy, and notification requirements in addition to the normal incident handling procedures outlined in this document.
    1. State of Kansas Law
      The primary law framing response requirements for incidents involving personal identity information is Kansas Statute 50-7a, the Unfair Trade and Consumer Protection — Protection of Consumer Information, that became effective in January 2007. It defines personal information as:

      "...a consumer's first name or first initial and last name linked to any one or more of the following data elements that relate to the consumer, when the data elements are neither encrypted nor redacted: (1) Social security number; (2) driver's license number or state identification card number; or (3) financial account number, or credit or debit card number, alone or in combination with any required security code, access code or password that would permit access to a consumer's financial account. The term 'personal information' does not include publicly available information that is lawfully made available to the general public from federal, state or local government records."

      The law requires a “reasonable and prompt investigation to determine the likelihood that personal information has been or will be misused. If the investigation determines that the misuse of information has occurred or is reasonable likely to occur, the … agency shall give notice as soon as possible to the affected Kansas resident.” Thus prompt action in cases known or suspected to involve personal information is critically important.
    2. Executive Incident Management Team
      1. Incident response in these cases will be overseen by an Executive Incident Management Team (EIMT) as mandated by K-State’s Security Incident Reporting and Response Policy. An EIMT may also oversee the response to other high-severity incidents, but the primary purpose is to deal with incidents involving personal identity information.
      2. The purpose of the EIMT is to provide executive guidance to the response process to insure: a) an appropriate, timely, and legal response, b) to make decisions related to the incident, and c) to notify appropriate parties.
      3. The team consists of:
        • Senior administrator for the affected unit
        • Chief Information Officer (CIO)
        • Chief Information Security Officer
        • Representative from the Office of General Counsel
        • Representative from the Vice President for Communications and Marketing
        • Others as needed (for example, the K-State Police for criminal incidents, or the data steward of the affected data)
      4. The CIO will convene the EIMT at the appropriate time per the procedure that follows.
    3. Credit Card Information
      If the PII threatened in the incident includes credit card information, all normal procedures for handling a suspected breach of confidential data must be followed, in addition to:
      1. Include a representative from the Division of Financial Services on the Executive Incident Management Team (EIMT)
      2. Promptly notify the affected payment brands (VISA, MasterCard, Discover, etc.), as required by the Payment Card Industry Data Security Standards, security control 12.9.1
      3. The EIMT should consider notifying the acquiring bank that processes financial transactions for K-State
    4. Procedure for handling a breach of confidential personal identity data
      1. If the CISO determines that confidential data has been or may have been breached, the CISO will immediately notify the CIO.
      2. The CISO will oversee additional forensics analysis to gather as much information as possible about what happened, being sure to properly protect evidence.
      3. If after analysis the CIO and CISO have definitive evidence that the confidential data was not breached, then no further special action is required and normal incident response procedures may continue. However, the security of this system and the need to store confidential data on it should be carefully assessed.
      4. If there is a possibility that confidential data involving personal identity information was breached, the CIO will convene the EIMT as quickly as possible to review the evidence and determine if a breach of confidential personal identity data occurred or is “reasonably likely” to have occurred (wording of the state notification law).
      5. If the EIMT determines that personal identities are not at risk, no further special action is required and normal incident management procedures may continue.
      6. If the EIMT determines that personal identities are at risk, the EIMT oversees the response, addressing the following issues:
        1. Determine if the affected individuals need to be notified and the appropriate method for notification (Senate Bill 196 has stipulations)
        2. Determine who will draft and sign the notification (see Appendix 2 for sample notification letter)
        3. Assign someone to collect victim mailing addresses and to distribute notifications
        4. Determine the point of contact for inquiries from the victims, media, and other interested parties and the type of assistance to offer. In determining the type of assistance appropriate to the situation, consider assistance such as:
          • Providing personal assistance in getting free credit protection,
          • Establishing a toll-free phone number for victims to call for assistance, and/or
          • Establishing an informational website.
        5. Determine the need for a news release and timing in relation to the communication with victims. The news release will be drafted by a representative from the Vice President for Communications and Marketing or designee and reviewed by the EIMT.
        6. Determine if all national consumer credit agencies need to be notified (required by Kansas law if notifying more than 1,000 consumers) and if so, who will notify them and what information will be provided
        7. Discuss how the incident could have been prevented and steps to take to prevent similar incidents in the future
      7. If potential victims do need to be notified, the CIO or designee(s) should notify the following people as quickly as possible:
        1. Office of the President
        2. Provost and Senior Vice President
        3. President of the Faculty Senate
        4. President of the Student Senate
        5. Director of Government Relations
        6. CEO and Director of IT for the Board of Regents, as required by BoR policy and procedure:
          • President and CEO: Dr. Andy Tompkins, 785-296-3421, atompkins@ksbor.org
          • Director of IT: Steve Funk, 785-296-3421, sfunk@ksbor.org
        7. The Board of Regents Director of IT will notify the Executive Branch Chief Information Technology Officer and the state IT Security Officer
      8. The CISO will convene a Post-Incident Review Session with key stakeholders from the EIMT and others as needed (see section VI.D.2.b above)
      9. The CISO will draft a confidential Post-Incident Report (see “Post Incident Report” in section IX.C below) to be reviewed by appropriate members of EIMT for accuracy and submitted to the CIO and senior administrator(s) in the affected unit(s).
    5. Deciding Whether or Not to Notify Victims
      If confidential data resides on a compromised computer, it is not always obvious whether the data were accessed and therefore whether potential victims need to be notified, especially in light of Kansas law that requires notification if “misuse of the information has occurred or is reasonably likely to have occurred.” EDUCAUSE provides the following questions to consider when deciding whether confidential data was breached (from the University of California Office of the President):
      1. Is the information is in the physical possession and control of an unauthorized person, such as a lost or stolen computer or other device containing unencrypted notice-triggering information?
      2. Is there evidence that information has been downloaded, copied, or otherwise accessed, for example: an ftp log that contains the name of a file containing notice triggering information?
      3. Was a privileged (e.g. root or administrator) or non privileged account, one with access to privileged information, compromised?
      4. Was on system or multiple systems compromised?
      5. Is the identity of the attacker known or unknown? If known was the attacker a disgruntled insider or an unaffiliated third party? Were multiple attackers involved?
      6. Are there indications that the information was used by an unauthorized person, such as fraudulent accounts opened or instances of identity theft reported?
      7. Did the unauthorized person have access to the information for an extended period of time?
      8. What was the time between compromise start and compromise discovery?
      9. Did the compromise indicate a directed attack, such as a pattern showing the machine itself was targeted versus an automated attack?
      10. Did the attack appear to seek and collect the information?
      11. Did the attack appear to include tampering with records (e.g., changing grades)
      12. Did the attacker attempt to cover up their activity?
      13. Did the attacker release information about the nature or scope of the attack?
      14. Was the information encrypted and would the encryption method effectively prevent the information from being accessed.
      15. What is the potential damage to individuals if notification is not given?
      16. What is the potential damage to institutional credibility in the case of notification?
      17. What is the potential damage to institutional credibility i n the case of failure to notify?
  9. Incident Tracking and Reports
    1. Incident Tracking System
      1. The CISO will maintain an incident tracking system and record the following information about all reported security incidents:
        1. Incident ID number assigned by the CISO in the form YYYY-XXX where “YYYY” is the year in which the incident occurred and “XXX” is a unique number that roughly corresponds to the sequential order of occurrence of the incident that year. For example, 2007-103 would be the 103rd incident that occurred in 2007.
        2. Incident category(ies), severity, and description
        3. Identity of the affected system(s) – IP address, domain name, MAC address
        4. Whether the system contains confidential data
        5. Location of the affected system(s) – building and department
        6. Contact information – usually the departmental security contact, appropriate system administrator, or SIRT representative
        7. Dates and times – first notice, when contact notified, blocking/unblocking
        8. Recovery action taken
      2. All IT security incidents or suspected incidents (i.e., reports of suspicious activity that upon investigation are determined not to be a security incident) will be recorded in the incident tracking system.
      3. The incident tracking system should be used to identify trends or outbreaks that may require changes to security controls and/or policies to reduce the risk of future occurrences.
      4. The incident tracking data is considered confidential and should therefore be encrypted when stored or transmitted and disclosed only to authorized individuals. The confidentiality of reports derived from the incident tracking data will be determined on a case-by-case basis by the CISO and/or the CIO.
    2. Annual Report
      In January each year, the CISO will summarize the incidents for the previous calendar year and provide a report to the CIO and SIRT. The security incident data may also be used for other reports as needed. This report will be marked as confidential.
    3. Post-Incident Report
      1. Individual security incidents may require completion of a Post-Incident Report. Incidents with a severity category of "high" must submit one, and the CIO may request one for any security incident. Normally, the incident manager will complete the post-incident report.
      2. The CIO will review any recommendations in the report and determine additional follow up actions.
      3. Post-incident reports must be submitted to the CIO, be marked as confidential, and use the form specified in Appendix 1.
  10. References

Last date modified: February 21, 2018; revised for PCI DSS, Dec. 29, 2011; revised contact details, June 3, 2013