The University of Tennessee Chattanooga Incident Response Plan

The University of Tennessee Chattanooga Incident Response Plan Prepared by: Michael Dinkins, CISSP Senior Information Security Officer UT Chattanooga Information Technology Security & Projects Office

Table of Contents Document Control... ii Approvals... ii 1. Executive Summary...3 2. Goal...3 3. Scope...4 4. Roles and Responsibilities...4 4.1. Contact Information... 4 4.2. Responsibilities... 4 5. Event Detection and Analysis Process...5 5.1. Common Attack Vectors... 5 5.2. Incident Analysis and Verification... 5 5.3. Incident Prioritization... 6 5.4. Incident Notification... 7 6. Containment, Eradication & Recovery...8 6.1. Containment... 8 6.2. Eradication... 8 6.3. Recovery... 8 6.4. Documentation... 8 7. Post-Recovery...9 8. Incident Response Using Standard Operating Procedures...9 9. Incidents involving MODERATE systems...9 10. Reporting...9 11. Follow-up...10 Appendix A- UTC Information Technology Security Glossary of Terms...11 Appendix B - IT Security Glossary Definition of Responsibilities...12 Appendix C Data Exposure Incident SOP...14 Appendix D Compromised Device Incident SOP...16 Appendix E Compromised Account Procedure...20 i

Document Control,Version l!{o. Author : :1.,t. 1.0 1L/712074 Michael Dinkins Summary of Changes AppTovals t Vice-Chancellor & CIO ufio*ft:,{*-, Michael Dinkins Senior lnformation Security Officer,,1 / 'l I *. lit, t* Date.$lel&e Title, Date of Approv Thomas Hoover. Associate Vice Chancellor and Chief lnformation Officer Michael Dinkins Senior lnformation Security Officer \ra&it n N6.- 1.0 1.0

University of Tennessee Chattanooga Incident Response Plan (IRP) 1. Executive Summary The University of Tennessee s Security Incident Policy requires campuses and institutes to develop and maintain a security Incident Response Plan (IRP), including procedures for technical staff and users that detail detecting, communicating, responding to, and reporting security incidents. A security incident refers to an adverse event in an information system, and/or network, or the threat of the occurrence of such an event. Incidents can include but are not limited to unauthorized access, malicious code, network probes and denial of service attacks. (See Appendix A for a glossary of terms.) This document implements the University of Tennessee s security Incident Response Policy and specifies response objectives and prioritization for University of Tennessee Chattanooga (UTC). UT Chattanooga s campus community is required to utilize this process in cases concerning suspected violations or imminent threat of violation of any of the following: Information Technology Policy IT0110 (AUP), computer security policies, or standard security practices Fiscal Policy FI0805 Information Technology Resources Unauthorized release or exposure of university systems All applicable laws of the state of Tennessee and the federal government This Incident Response Plan contains references to the processes necessary for dealing with security incidents and/or resource abuses from any source connected to or transmitting information using UTC information technology resources. 2. Goal UTC is committed to minimizing the effects of a security incident and restoring information technology services. This Incident Response Plan is meant to provide the UTC community with a systematic approach for handling the discovery of and response to an abuse or security incident. Regardless of the criticality of the incident, it is essential that all steps outlined in this program are followed and the process is developed to achieve the following goals: Minimize disruptions to business functions and network operations confirm whether an incident or abuse has occurred Promote the accumulation of accurate information Establish controls for proper retrieval and handling of evidence Allow for legal (to include criminal and/or civil) actions against perpetrators Provide accurate reports and useful recommendations To be a successful IR program the Plan should be kept current. It must reflect the organizational UTC Incident Response Plan 3

and/or infrastructure changes and newly discovered vulnerabilities as they occur. This document must be reviewed annually by the UTC Chief Information Officer or designee. 3. Scope This process applies to all users (including but not limited to staff, faculty, students, contractors, consultants, and visitors) while using UTC information systems resources. All users are required to be advised of this plan and comply with this process. 4. Roles and Responsibilities 4.1. Contact Information The following is the point of contact for information regarding the Incident Response Plan: Name: Title: Email: 4.2. Responsibilities Michael Dinkins Senior Information Security Officer Michael-Dinkins@utc.edu All users of UTC information resources, system administrators, information systems support personnel, and security support personnel must understand their role in relationship to this process and comply with its requirements. The UTC Chief Information Officer (CIO) or his designee is responsible for maintaining and overseeing the incident response process and assigning members to the Security Incident Response Team (SIRT) appropriate to the security event. The CIO or designee(s) has the authority to monitor suspicious activity and to disconnect equipment that are in violation of university, campus, state or federal regulations. The Security Incident Response Team (SIRT) is accountable to the CIO for the investigation, declaration, analysis, and disposition of an incident. The membership of the SIRT is dependent on the type of incident and the means necessary to mitigate its effect on the confidentiality, integrity or availability of information resources. SIRT Members should be responsible for the following areas: Determining the tools and technology utilized in intrusion detection, Performing appropriate pre-incident activities (e.g. monitoring network activity, vulnerabilities, logs, etc.) Defining and classifying incidents, Determining if incident should be investigated and the scope of such an investigation (i.e. law enforcement agencies, forensic work) Securing the network Conducting follow-up reviews. See Appendix B for more detail covering the responsibilities of specific personnel. UTC Incident Response Plan 4

5. Event Detection and Analysis Process 5.1. Common Attack Vectors Events can be detected through automated or manual means. Automated detection capabilities include UTC s network-based and host-based Intrusion Detection/Prevention Systems (IDPSs) and antivirus software. Incidents may also be detected through manual means, such as problems reported by users or observations of abnormal resource utilization, suspicious account activity and log analysis. Additionally, UTC may receive reports from sources external to the university that have detected issues and reported the activity to the university. Although incidents occur in many ways, this plan focuses on the procedures to handle incidents that use the following common attack vectors: 1. External/Removable Media an attack executed from removable media (e.g., flash drive, CD) or a peripheral device. 2. Attrition An attack that uses brute force methods to compromise, degrade, or destroy systems, networks or services. 3. Web An attack executed from a website or web-based application. 4. Email An attack executed via an email message or attachment. 5. Improper Usage Any incident resulting from the violation of UT Policy IT0110 The Acceptable Use Policy by an authorized user, excluding the above categories. 6. Loss or Theft of Equipment The loss or theft of a computing device or media used by the university, such as a laptop or smartphone. 7. Other An attack that does not fit into any of the other categories. 5.2. Incident Analysis and Verification IT staff and the Security Incident Response Team cannot rely and react solely on the initial reports of a security incident. Computer users rarely provide accurate problem descriptions, and log files typically include numerous false positives. Indicators such as a server crash or modification of file can happen for operational reasons not related to any security incident. Conversely, a small file change could be the only indicator of a security breach. The following practices should make incident analysis and validation more viable: Profile networks and systems. Profiling is measuring the characteristics of expected activity so that changes to it can be more easily identified. Understand normal behavior. Incident response team members should study networks, systems, and applications to understand what their normal behavior is so that abnormal behavior can be recognized more easily. Establish and maintain a log retention policy in accordance with NIST SP 800-92, Guide to Computer Security Log Management. Perform event correlation. Security analyst(s) should review all appropriate log files. Evidence of an incident may be captured in several logs that each contain different types of data. UTC Incident Response Plan 5

Ensure all host clocks are synchronized. Event correlation will be more complicated if the devices reporting events have inconsistent clock settings. Maintain and Use a Knowledge Base of Information. Include information that analysts need for referencing quickly during incident analysis. Run Packet Sniffers to Collect Additional Data. Ensure a packet sniffer is available and configured appropriately to capture relevant traffic on UTC s network. Filter the Data. With limited security resources there is simply not enough time to review and analyze all the indicators. At minimum the most suspicious activity should be investigated. Filter out insignificant categories of indicators. However, there is greater risk when showing only the categories of the highest significance because new malicious activity may not fall into one of the chosen indicator categories. Observing one of the following events is generally inconclusive. However, a combination of any the following activities can represent a security event and should be investigated: Unsuccessful logon attempts; Unexplained system crashes; Unexplained poor system performance; Port scanning (use of exploit and vulnerability scanners, remote requests for information about systems and/or users, or social engineering attempts); Unusual usage times (statistically, more security incidents occur during non-working hours than any other time); An indicated last time of usage of an account that does not correspond to the actual last time of usage for that account. 5.3. Incident Prioritization Incidents are prioritized based on the following relevant factors: Category None Low Moderate High 1. Functional Impact the current or future impact of an incident on UTC s ability to conduct business. UTC follows University of TN Policy IT0115 Information and Computer System Classification, which categorizes security breach impact to UTC as Low, Moderate or High. Applying Policy IT0115: Definition No effect to UTC s ability to provide all services to all users Limited effect; UTC can still provide all critical services to all users but has lost efficiency Serious effect; UTC has lost the ability to provide a critical service to a subset of system users Catastrophic effect; UTC is no longer able to provide critical services to any users 2. Informational Impact an incident may affect the overall impact (Low, Moderate or High) on the confidentiality, integrity and/or availability of the information, and the SIRT must consider how information exfiltration could impact UTC: UTC Incident Response Plan 6

Category None Privacy Breach Proprietary Breach Integrity Loss Definition No information was exfiltrated, changed, deleted, or otherwise compromised Sensitive personally identifiable information (PII) of taxpayers, employees, beneficiaries, etc. was accessed or exfiltrated Unclassified proprietary information, such as protected critical infrastructure information (PCII), was accessed or exfiltrated Sensitive or proprietary information was changed or deleted 3. Recoverability Impact the size of the incident, the effort and the resources required to return to full operation should also be considered: Category Regular Supplemented Extended Not Recoverable Definition Time to recovery is predictable with existing resources Time to recovery is predictable with additional resources Time to recovery is unpredictable; additional resources and outside help are needed Recovery from the incident is not possible (e.g., sensitive data exfiltrated and posted publicly); launch investigation 5.4. Incident Notification When an incident is analyzed and prioritized, the incident response team needs to notify the appropriate individuals. The exact reporting requirements will vary depending on the incident and determination by the IT Security Incident Response Team. The following personnel must be notified of all security incidents: CIO. Depending on the nature of the security breach the Senior Information Officer, at his/her discretion, must notify the CIO either verbally or in writing. The Senior Information Security Officer. At the discretion of the Senior Information Security Officer the following personnel will be notified based on the severity and potential impact of the security incident: IT Security Advisory Team Security Incident Response Team(s). External incident response teams (if appropriate). System Owner and/or functional Security Liaison. At the discretion of the Chief Information Officer the following will be notified based on the severity and potential impact of the security incident: Human resources (e.g. harassing emails). Public Affairs (as directed by CIO) Public Safety/Campus Police Legal Department Law enforcement UTC Incident Response Plan 7

6. Containment, Eradication & Recovery 6.1. Containment Most incidents require containment before an incident overwhelms resources or increases damage. The purpose of containing the incident is simply to limit extent of the attack. Containment provides time for developing the appropriate remediation and making the best decision for the situation. The containment strategy varies based on the type of incident. (e.g., shut down a system, disconnect it from a network, or disable certain functions). For example, the strategy for containing an email-borne malware infection is quite different from that of a networkbased DDoS attack. Criteria for determining the appropriate strategy include: Potential damage to and theft of resources Need for evidence preservation Service availability (e.g., network connectivity, services provided to external parties) Time and resources needed to implement the strategy Effectiveness of the strategy (e.g., partial containment, full containment) Duration of the solution (e.g., emergency workaround to be removed in four hours, temporary workaround to be removed in two weeks, permanent solution). In certain cases the attack may be put into a sandbox so that additional information can be collected. Use caution using sandboxes; some attacks may cause additional damage when they are contained. 6.2. Eradication After containing the incident every effort must be made to eliminate the threat and prevent it from causing further damage. During eradication, it is important to identify all affected hosts so that they can be remediated. Disable breached user accounts, identify and mitigate all vulnerabilities that were exploited, delete all malware, etc. Clean and reformat all the infected media and ensure the most current anti-virus software is installed and operating. When making backups, ensure they are clean. For some incidents, eradication is either not necessary or may be performed during recovery. 6.3. Recovery The SIRT should verify that system administrators have restored to normal operation and confirm that the systems are functioning normally, and the vulnerability no longer exists. Once a resource is successfully attacked, it is often attacked again, or other resources within the organization are attacked in a similar manner. The incident may call for increased system logging or network monitoring. 6.4. Documentation The primary reason for gathering evidence during an incident is to resolve the incident, but it may also be needed for a legal process. When forensics are performed, clearly document the incident and remediation accordingly, and with the understanding that any evidence can be admissible in court. Incident documentation should be accounted for at UTC Incident Response Plan 8

all times and a log should be kept when transferred from UTC employee to a law enforcement official. 7. Post-Recovery The IT Information Security Advisory Team should hold a lessons learned meeting with all involved parties after a major incident, and optionally periodically after lesser incidents as resources permit. This meeting provides a chance to review what occurred, what was done to intervene, and how well intervention worked. 8. Incident Response Using Standard Operating Procedures The Incident Response process must be initiated as soon as possible or critical information could be lost/destroyed before the SIRT has a chance to review it. All users should report suspect events to the UTC Call Center (a.k.a. HelpDesk) and to their respective System Administrator (SA). The SA or Call Center teams will then gather the necessary information to appropriately record the security event. Furthermore, UTC information technology support personnel have the responsibility to inform affected individuals/organizations in a timely fashion. The contact number for reporting a security event is: IT Call Center (HelpDesk): (423)425-4000 9. Incidents involving MODERATE and HIGH categorized systems A suspected compromise of any system must be reported immediately to the IT Call Center. The suspected system should not be rebooted, disconnected, or otherwise altered unless directed by a member of the Security Incident Response Team (SIRT). Any compromised system that stores, processes, or transmits information considered sensitive must be reported immediately to the Senior Information Security Officer (SISO) or SIRT. Systems classified as MODERATE (or possibly HIGH) may contain restricted information that includes, but is not limited to, personally identifiable information (PII), Family Educational Rights and Privacy Act (FERPA), and Health Insurance Portability and Accountability Act (HIPAA). No UTC system should store information covered by Payment Card Industry Data Security Standards (PCI-DSS), i.e. credit card information. However, the IT staff must respond as if that were the case. Any system classified as MODERATE or HIGH may be business critical from a service availability perspective vs. an information classification perspective-- and require the same response. Please note the following: Appendix C Data Exposure Incident SOP Appendix D Compromised Device Incident SOP Appendix E Compromised Account SOP Standard Operating Procedures (SOP), which outline the specific steps to be taken during the incident response stage of a suspected incident or abuse, are listed as appendices to the Incident Response Plan. UTC IT personnel should be familiar with each SOP and adhere to the standards defined within that procedure. 10. Reporting The UTC service tracking system (Footprints) shall be used for recording security incident information UTC Incident Response Plan 9

and must include the appropriate data fields that allows for work and cost analysis. Deriving a financial cost associated with an incident will help those who may be prosecuting any suspected perpetrators, and will aid in the justification of funding for future security initiatives. Depending on the type of incident or abuse, a Footprints service ticket shall be created and the SISO notified. At the discretion of the SISO a more detailed security incident report may be requested. The system user or owner should contact the IT Call Center for guidance. Answers to the following questions should be included in this report: Did the incident disrupt ongoing operations? Was any data irrecoverably lost, and, if so, what was the value of the data? Was any hardware damaged? Was there unauthorized access to information classified as MODERATE? What is the estimated cost of the loss? A copy of any security incident report shall be forwarded to the UTC SISO for review, storage, and reporting. Incident reports must be disseminated to the parties involved and the support personnel. 11. Follow-up Performing follow-up activity helps the UTC campus improve their incident handling processes as well as aid in the continuing support of any efforts to prosecute those who have broken the law or abused any UTC information technology resources. If it cannot be determined whether a follow-up is needed, information owners should contact the Senior Information Security Officer for guidance. Follow-up actions include the following: Define the "lessons learned" Analyze what has transpired and what was done to intervene. Was there sufficient preparation to prevent the incident? Did detection occur promptly? If not, why? Could additional tools have helped the detection and recovery process? Was the incident sufficiently contained? Was communication adequate, or could it have been better? What practical difficulties were encountered? Every effort should be made to complete follow-up documentation within 90 days of closing an incident to ensure continuing improvement to the Incident Response Plan. UTC Incident Response Plan 10

Appendix A- UTC Information Technology Security Glossary of Terms Acceptable Use Policy (AUP) The University of Tennessee IT Policy IT0110 Acceptable Use of Information Technology Resources implements the general principles regarding the appropriate use of information systems equipment, software, and networks. This policy applies to all users (including but not limited to, staff, faculty, students, contractors, consultants, and visitors) while using UTC information systems resources. Computer System This includes all computing devices including, but not limited to, laptop and desktop computers, personal digital assistants, and all mobile email devices. Security Incident Response Team (SIRT) The SIRT supports the operations of the UT Chattanooga campus through mitigation of all incidents adversely impacting the confidentiality, integrity, availability, and accountability of information technology resources. Event An occurrence that has not been verified as a security incident. Family Educational Rights and Privacy Act (FERPA, 1974) FERPA protects the rights of students by controlling the creation, maintenance, and access to educational records. It guarantees students' access to their academic records while prohibiting unauthorized access by others. Health Insurance Portability and Accountability Act (HIPAA) Creates a standard for healthcare providers and institutions to protect the confidentiality and integrity of personal health information. Incident Response The documented process used by information technology professionals in response to information technology resource compromises, vulnerabilities, and attacks. This process is developed to achieve the following goals: Accurately identify systems involved Confirm whether an incident or abuse has occurred Promote the collection of accurate information Establish controls for proper retrieval and handling of evidence Minimize disruptions to business functions and network operations Allow for legal (to include criminal and/or civil) actions against perpetrators Provide accurate reports and useful recommendations Information Technology Resources Includes any computers, computer systems, network devices, telephony systems, or software applications supported by UTC. Payment Card Industry-Data Security Standards (PCI-DSS) - Provides for developing a payment card security process including prevention, detection, and appropriate reaction to security incidents. Security Incident A violation or imminent threat of violation of information security policies, acceptable use policies, or standard security practices. Incidents can include computer intrusions, denial-of-service attacks, insider theft of information, copyright violations, and any activity that requires support personnel, system administrators, or computer crime investigators to respond. Standard Operating Procedure (SOP) The Standard Operating Procedure (SOP) implements the general principles established by the Incident Response Plan (IRP) regarding the specific steps which UTC personnel must follow when responding to an abuse or incident. System Administrators (SA) The UTC campus employees that are responsible for Information Systems (including the security controls for the system) within a department or group. Users Refers to all students, faculty, staff and others while accessing, using, or handling the University of Tennessee, Chattanooga s information technology resources. Others include, but are not limited to, subcontractors, visitors, visiting scholars, potential students, research associates, grant and contract support personnel, media representatives, guest speakers, and non-university entities granted access. UTC Incident Response Plan 11

Appendix B - IT Security Glossary Definition of Responsibilities Call Center The UTC IT Call Center is the first level of interaction for users experiencing security events. It is the IT Call Center s responsibility to coordinate incoming information on a per user basis, advise individual users on handling individual security events or incidents, and forward information relating to an event or incident to the SISO or SIRT. The IT Call Center shall instruct the user not to reboot, disconnect, or otherwise alter the system when a confirmed incident has been discovered. Field Support Field Support is an operations unit under Strategic Systems that provides direct interactive support for users experiencing security incidents that do not have a System Administrator in place or require additional expertise. Field Support personnel shall instruct the user of the appropriate action(s) when a confirmed event has been discovered, unless directed by a member of the SIRT. Incident Analyst The IA is responsible for performing the analysis of a particular incident. This shall include determining the cause of the incident, the impact to the campus, and the recommended response. The IA is a SIRT member. Incident Investigator The incident investigator is responsible for the gathering of all necessary information pertaining to a security incident and for the tracking and reporting of specific incidents. The investigator is the communication liaison between the affected groups and the UTC Security Office. The Incident Investigator is typically someone from IT Call Center, Field Support, and/or Network Services. Information Security Office (ISO) The UTC Information Security and Projects Office is the entity that is responsible, under the Chief Information Officer (CIO), for the IT security oversight and administration of the Information Security Program. The UTC ISO, under the direction of the Senior Information Security Officer (SISO), coordinates information security efforts within UTC campus. In addition, the ISO is accountable for actively monitoring key intrusion detection and intrusion prevention systems, assisting in vulnerability assessments, and overseeing forensic investigations. Information Systems Support Personnel In this document, Systems Support Personnel applies to all system administrators, Call Center personnel, Field Support, the ISO, and any individual at UTC that support information technology resources. Information Security Analyst (ISA) UTC s Senior Information Security Analyst (SISA) serves as the technical resource responsible for proposing countermeasures and for hardening various systems and platforms supported within the university. This role is assigned by the SISO. Network Services (NS) The Network Services team will work in conjunction with the IT Call Center, Field Support, and the ISO in order to identify, analyze, and respond to suspected and verified security incidents. Such responses may include disabling or re-enabling network ports, port scanning, and altering router access control lists or firewall policies. Senior Information Security Officer (SISO) The SISO is the Director of the Information Security and Projects Office. The SISO mobilizes the Security Incident Response Team (SIRT) to review the incident and respond according to the specific SOP. The SISO will coordinate the response with system administrators, the IT Call Center, Field Support, Network Services, security personnel, and other agencies as necessary (including but not limited to Campus Police, Student Affairs, Public Relations, Office of the General Counsel, and the Federal Bureau of Investigation). The ISO is also responsible for notifying the Chief Information Officer (CIO) regarding security incidents to obtain additional direction as necessary. SIRT Incident Handler(s) The SIRT Incident Handlers are responsible for leading a particular incident response operation or effort. This task can be assigned to any member of the SIRT team depending on the nature of the task. SIRT Team Leader The SIRT Team Leader will be the SISO or designee responsible for the overall administrative and personnel management of the SIRT team. UTC Incident Response Plan 12

System Administrator (SA) The SA is the first level of interaction for users that are experiencing a security event or incident. It is the system administrator s responsibility to coordinate incoming information, advise users on handling security events, forward information to the UTC ISO, and disseminate information to users and other system administrators as appropriate. The system administrator is responsible for monitoring the systems within their department to identify unusual behavior or symptoms, which may indicate a security incident. Users Users are responsible for monitoring unusual system behavior, which may indicate a security event. Users must be able to recognize the indications of a security event as outlined in the incident verification section of this document. Users are responsible for reporting events to their local system administrator, the UTC ISO, the IT Call Center, Field Support, or Network Services immediately. The user must not reboot, disconnect, or otherwise alter the system when an event has been discovered, unless directed otherwise by a SA, a member of the SIRT or the ISO. Otherwise, collection of valid evidence can be negatively impacted by losing critical information stored in system memory. UTC Incident Response Plan 13

Appendix C Data Exposure Incident SOP Responsibilities Whenever Information Technology (IT) is notified of a data disclosure or a potential data exposure, specific steps should be taken to ensure compliance with federal and state regulations. The department responsible for the exposure should inform their department head and respective Vice Chancellor of the incident, and work with the UTC Information Security Office and all appropriate officials to determine appropriate action(s). The department responsible for the exposure assumes primary responsibility for dealing with issues of the exposure according to the UTC procedure listed here. They should work with system owners to verify the classification of the data and take responsibility for developing a communications plan that includes any publicity, notification to individuals and others, and necessary remediation. The group or department responsible for the data exposure is responsible for contacting individuals affected by the exposure and must consult with the UTC Office of University Relations, IT Security and Projects Office and the UTC Office of the General Counsel to develop a communication plan. PII-Personally Identifiable Information Personally identifiable information (PII), including information classified as MODERATE, is covered by The University of Tennessee Data Breach Notification Policy, IT0121. Personal information means an individual s first name or first initial and last name, in combination with any one (1) or more of the following data elements, when either the name or the data elements are not encrypted: 1) Social security number; 2) Driver license number; or 3) Account number, credit or debit card number, in combination with any required security code, access code, or password that would permit access to an individual s financial account. Personal information does not include publicly available information that is lawfully made available to the general public from federal, state, or local government records. UTC Incident Response Plan 14

Data Exposure Remediation Procedure USERS Responsible Department IT/ISO/SIRT Identify Possible Data Exfiltration Identify Possible Data Exfiltration Notify Department Head Does Exposure contain PII? Notify Department Head NO YES Document Incident Notify Call Center (create FP ticket) Remediate, Follow-up, Rolebased Training Notify appropriate data steward HR Data: HR Director (423)425-4221 end Student data: Registrar (423)425-4416 Financial data: AVC BusFinance (423)425-4781 Form SIRT & begin investigation Notify Office of the General Council Issue Incident Report Dev Comm Plan Notify Affected Users Remediate, Follow-up, Rolebased Training END UTC Incident Response Plan 15

Appendix D Compromised Device Incident SOP Responsibilities Whenever Information Technology (IT) is notified of a device or potential device compromise, specific steps should be taken to ensure compliance with federal and state regulations. This applies to university-owned devices or personal devices accessing university resources. The department responsible for the exposure should inform their department head and respective Vice Chancellor of the incident, and work with the UTC Information Security Office and all appropriate officials to determine appropriate action(s). The actions taken are dependent on factors including the security classification (LOW, MODERATE, or HIGH) of the device and the university affiliation of the primary user (e.g. Faculty, Staff, or Student). The user or department responsible for the compromised device should inform their department head of the incident and work with the incident handlers to determine appropriate action(s). The user/employee, group or department who owns the device assumes responsibility for dealing with issues pertaining to the compromised device. They should work with the ISO, SIRT or other incident handler(s) to verify the classification of the data and develop a communications plan. The user, group or department is responsible for contacting individuals affected by any exposure of sensitive or restricted data (see Appendix C), and the responsible party must consult with the UTC Office of University Relations, IT Security and Projects Office and the UTC Office of the General Counsel to develop an appropriate communication plan. IT Procedures for Responding to the report of a compromised device The following outlines the standard operating procedures that should be followed in response to the report of a compromised device (either personal or university-owned) that could adversely impact the network and/or AUP policy violations. LEVEL 0 Description If the device is personally owned, it is up to the owner to see that the issue is addressed. If the device is university-owned, it is up to the department to see that the issue is addressed. Machines at this level are considered at risk. Users will be notified of the potential threat that could lead to a compromise or infection in the future. Action Taken by IT Upon detection, a Footprints ticket will be generated to log the incident and the owner as designated in Network Registration will be sent an email informing them of the potential threat. UTC Incident Response Plan 16

Action Required by the User No action required. Examples: LEVEL 1 Description Potential problems found proactively Notification by an outside source (REN-ISAC, MS-ISAC) Machines at this level are considered vulnerable to known exploits and a threat to the network or to other devices. The user must take some action or he will be cut off from the network. If the device is university-owned the department is responsible for seeing that the machine is prepared for network access. Action taken by IT Upon detection, a Footprints ticket will be created to log the incident and the user will be sent an email with the appropriate instructions on how to correct the problem. If the user does not correct the problem within 24 hours, the machine s network registration will be disabled. For devices belonging to faculty/staff: The Footprints ticket will be assigned to the IT Security Analyst and set to a status of Infected_ Possible. After 24 hours of monitoring and at the discretion of the SISA, if this machine shows up again the ticket status will be changed to Infected_ 2BDisabled and assigned to Network Services where the machine s Network Registration entry will be disabled. For devices belonging to students: The Footprints ticket will be assigned to the IT Security Analyst and set to a status of Infected_ Possible. After 24 hours of monitoring and at the discretion of the SISA, if this machine shows up again the ticket status will be changed to Infected_ 2BDisabled and assigned to Network Services where the machine s Network Registration entry will be disabled. The ticket will then be assigned to Call Center for instructing student on how to clean machine for network access. Action Required by the User User must take the action requested within 24 hours. Examples: LEVEL 2 Patch has not been applied to prevent known exploits (i.e. vulnerabilities like MS04-011 or the HEARTBLEED bug) Virus/Worms Notification by an outside source (REN-ISAC, MS-ISAC) UTC Incident Response Plan 17

Description Machines at this level have been found to be compromised. Action Taken by IT Footprints ticket will be generated to log the incident and the user will be sent an email letting him/her know of the problem and the appropriate action that needs to be taken. The user s Network Registration entry will be disabled. In addition, the network access will also be blocked (i.e. the network port will be disabled and/or the MAC address will be blocked on wireless). For devices belonging to employees (personal or university-owned): The Footprints ticket will be assigned to Network Services for disabling the Network Registration entry, network port and/or wireless access. The FP ticket will then be assigned to Field Support and Security Analyst for machine analysis, forensics if necessary, and restoration. For devices belonging to students: The Footprints ticket will be assigned to Network Services for disabling the Network Registration entry, network port and/or wireless access. The ticket will then be assigned to the Call Center. The student may contact the Call Center for assistance and instruction. When the student cleans/rebuilds the infected computer, network access can be restored. Action Taken by the User The user must address the compromise and/or problem before IT will enable the user s Network Registration entry and/or network port. The user must rebuild his/her computer. If this is a university-owned device, the department is responsible for seeing that the machine is rebuilt. Examples: Compromised computers Rogue DHCP servers Denial of service attacks Unauthorized scanning Trojans Notification by an outside source (REN-ISAC, MS-ISAC) UTC Incident Response Plan 18

LEVEL DESCRIPTION IT ACTION OWNER ACTION COMMUNICATION 0 Device is at-risk Create FP Ticket; notify owner NONE Owner notified of potential threat EXAMPLE Potential problem(s) found proactively Notification by an outside source (e.g. MS/REN-ISAC) 1 Machine considered vulnerable to known exploits and a threat to the network or to other devices. EMPLOYEE MACHINE: A FP ticket will be assigned to the IT Security Analyst and set to a status of Infected_ Possible. After 24 hours of monitoring and at the discretion of the SISA, if this machine shows up again the ticket status will be changed to Infected_2BDisabled and assigned to Network Services where the machine s Network Registration entry will be disabled. User must take the necessary action within 24 hours or machine network registration will be disabled. User sent an email with the appropriate instructions on how to correct the problem. Patch has not been applied to prevent known exploits (i.e. vulnerabilities like MS04-011 or the HEARTBLEED bug) Virus/Worms Notification by an outside source (REN-ISAC, MS- ISAC) STUDENT MACHINE: The Footprints ticket will be assigned to the IT Security Analyst and set to a status of Infected_ Possible. After 24 hours of monitoring and at the discretion of the SISA, if this machine shows up again the ticket status will be changed to Infected_ 2BDisabled and assigned to Network Services where the machine s Network Registration entry will be disabled. The ticket will then be assigned to Call Center for instructing student on how to clean machine for network access. 2 Compromised machine. EMPLOYEE MACHINE: A FP ticket will be assigned to Network Services for disabling the Network Registration entry, network port and/or wireless access. The FP ticket will then be assigned to Field Support and Security Analyst for machine analysis, forensics if necessary, and restoration. STUDENT MACHINE: A FP ticket will be assigned to Network Services for disabling the Network Registration entry, network port and/or wireless access. The ticket will then be assigned to the Call Center. The student may contact the computer to the Call Center for assistance and instruction. When the student cleans/rebuilds the infected computer, network access can be restored. The user must address the compromise before IT will enable the user s Network Registration entry and/or network port. The user must rebuild his/her computer. If this is a universityowned device, the department is responsible for seeing that the machine is rebuilt. User sent an email with the appropriate instructions on how to correct the problem. Compromised computers Rogue DHCP servers Denial of service attacks Unauthorized scanning Trojans Notification by an outside source (REN-ISAC, MS- ISAC) UTC Incident Response Plan 19

Appendix E Compromised Account Procedure USERS CALL CENTER IT SERVICES IT/ISO/SIRT Identify Possible Account Compromise Create FootPrints Ticket (Compromise_Possible) Form SIRT & begin investigation NO Notify Call Center (423)425-4000 Employee Account? END Document Incident YES Does User have access to PCI,HIPAA, PII, FERPA? Yes or Unsure Notify SISO. ISSUE REPORT NO Was UTC system compromised? Yes or Unsure Image/Clean/ Rebuild System Remediate, Follow-up, Rolebased Training NO END END END UTC Incident Response Plan 20