IT Security Incident Response Plan

1.	Introduction	4
1.1	Purpose	4
1.2	Scope	4
2	Roles & Responsibilities	4
2.1	IT Technology Infrastructure Group	4
2.2	IT Incident Response Advisory Team	4
2.3	IT Network Specialist - Security	5
2.4	IT Security Team	5
2.5	IT Incident First Responders Team	5
2.6	Users	5
3	Types of Information Technology Security Incidents	6
3.1	Internal and External Threat	7
3.2	Malicious Code Attacks	7
3.2.1	Virus Incidents	7
3.2.2	Macro Viruses	7
3.2.3	Worms	7
3.2.4	Trojan Horses	8
3.2.5	Cracking Utilities	8
3.2.6	Ransomware	7
3.3	Cracker/Hacker Attacks	9
3.4	Technical Vulnerabilities	10
3.5	Legal Incidents	10
3.6	Physical Attacks	10
3.7	"Social Engineering" Attacks	11
3.8	Unintentional release of confidential or protected information	11
4	Procedures for Responding to incidents	12
	Confidentiality	12
4.1	Preparation	12
4.1.1	Baseline Protection	12
4.1.2	Planning and Guidance	12
4.1.3	Training	13
4.2	Identification	13
4.2.1	Analyzing the Symptoms	13
4.2.2	Identify the Nature of the Incident	14
4.2.3	Identify the Evidence	14
4.2.4	Protect the Evidence	14
4.2.5	Report the Events	14
4.3	Containment	15
4.3.1	Maintain a Low Profile	15
4.3.2	Avoid Potentially Compromised Code	15
4.3.3	Back up the System	15
4.3.4	Change Passwords	15
4.4	Eradication	16
4.4.1	Determine the Cause and System	16
4.4.2	Improve Defenses	16
4.4.3	Perform Vulnerability Analysis	16
4.5	Recovery	16
4.5.1	Determine the Course of Action	16
4.5.2	Monitor and Validate System	16
4.6	Follow up	16
4.6.1	Review and Document the Quality of the Response to the Incident	16
4.6.2	Document Incident Costs	17
4.6.3	Filing a Report	17
4.6.3	Revising Policies and Procedures	17
4.7	Notification	17
5	Conclusion	18
6	Policy Documentation	18
	Availability	18
	Changes	18
	Appendix A: Glossary	19
	References	22

1. Introduction

1.1 Purpose
The purpose of this Information Technologies (IT) security incident response plan (IRP) is to provide general guidance to the college to:

enable quick and efficient recovery from IT security incidents;
respond in a systematic manner to incidents and carry out all necessary steps to correctly handle an incident;
prevent or minimize disruption of critical computing services;
minimize loss or theft of sensitive or mission critical information.

It is also a guide to sharing information— internally within IT, externally with College leadership, and with information security and law enforcement organizations, as well as a guide for pursuing appropriate legal action.

1.2 Scope
The guidance contained in this document is applicable to all IT employees and contractors (collectively known as IT users), and others who process, store, transmit, or have access to or responsibility for IT information and infrastructure computing resources at the College. This guidance is applicable to all College information and infrastructure computing resources at all levels of sensitivity.

2 Roles and Responsibilities

Each IT staff member has responsibilities related to the security of all College’s computing systems and networks. The persons and work groups listed below have specific responsibilities with regard to the reporting and handling of information security incidents. It is important for each entity to know in advance its role. See Figure 1 for a diagram illustrating the hierarchy and associated responsibilities.

2.1 IT Technology Infrastructure Group
IT Technology Infrastructure is the work group within IT that is primarily responsible for managing information security standards, procedures, and controls intended to minimize the risk of loss, damage, or misuse of IT-supported electronic data.

IT Technology Infrastructure:

Serves as the focal point for reviewing information system security issues that have campus and College-wide impact.
Prepares guidelines for establishing and maintaining the security incident response plan
Investigates all information security problems/incidents
Supports the IT Security Team (see section 2.4) and/or other system administrators to analyze and resolve security incidents
Evaluates and documents investigation findings after resolving an incident
Recommends security strategies (e.g. use of intrusion detection tools, penetration testing, etc.) to appropriate executive management
Promotes security awareness to the College computing community

2.2 IT Incident Response Advisory Team
The Incident Response Advisory Team is comprised of:

Chancellor,
Vice Chancellor, Information Technologies,/Chief Information Officer,
Vice Chancellor, Vice Chancellor Human Resources,
Vice Chancellor, Administrative Services,
Director Public Safety/Risk Manager, and
Vice Chancellor, Marketing & Communications.

This team can augment itself as needed. This group provides oversight and guidance to the Security Team in matters of information control, makes strategic decisions, and keeps the Cabinet and Board of Trustees informed (as needed).

2.3 Director, Enterprise Systems and Security
In regards to incident response, the Director of Enterprise Systems and Security is responsible for:

Coordinating the overall response and recovery activities for security incidents
Providing guidance and assistance in determining the appropriate action taken
Providing regular updates to IT senior management (CIO, Executive Director) of any IT Security incident and investigation findings

2.4 IT Security Team
The IT Security Team is a small group of IT experts from various work groups who are responsible for planning and implementing IT Security measures to avoid IT Security incidents, and who are the core first responders in the unlikely event that the College experiences an IT Security incident. The IT Security Team is led by the Director of Enterprise Systems and Security when responding to an IT Security incident.

2.5 IT Incident First Responders Team
This team is composed of both IT and non IT staffers. From the Information Technologies department: IT System Administrators and other key IT personnel who are familiar with all College systems and networks and may often be the first to discover a security incident. These staff members are responsible for reporting incidents to Director of Enterprise Systems and Security immediately, as well as likely members of the team helping to determine and implement a solution, when applicable. The First Responders may augment their team as appropriate with any OCC employee.

This group of first responders should perform the following, as appropriate, if there is a suspicion that something is amiss:

Investigate briefly
If suspicion is confirmed or indeterminate, confer with supervisor, networking manager/administrator, and notify Director of Enterprise Systems and Security immediately
Start an event log by noting date and time of all actions
Identify risk to system or information
Implement response plan of incident discovery as directed by the IT Security Team
Monitor, study and update situation

2.6 Users
Despite advances in automated intrusion detection systems, computer users may be the first to discover an intrusion. Both end- and system-users should be:

Vigilant for unusual system behavior, which may indicate a security incident in progress
Report suspected or known incidents (e.g., a virus infection, a system compromise, or a denial of service incident, which may detected by resident software on the system user's workstation) to the IT Support Center.
Preserve evidence
Cooperate with investigative personnel during investigation if needed

Group	Composition	Role
IT Incident Response Advisory Team	Vice Chancellor, Information Technologies/Chief Information Officer Vice Chancellor, Human Resources Vice Chancellor, Administrative Services Vice Chancellor Marketing & Communications Chief of Public Safety Manager of Environmental Health Safety and Risk Management	Provides guidance to the Security Team Makes Strategic Decisions Controls all communication Keeps the Cabinet and Board of Trustees informed- as needed
IT Security Team	Director of Enterprise Systems and Security Cyber Security Analyst Director, Technology Applications Director, Client Technology Services Executive Director Technology Infrastructure	Implements the Incident Response Plan Provides Tactical response to incident Draws in any resources (First Responders team, or any others as needed) to manage incident Reports all progress to the Advisory Team
IT Incident First Responders Team	IT Security Team plus the any/all of the following- as needed: Network Specialists System Administrators Programmer Analysts Project Analysts Managers of Desktop Support Campus Public Safety Lieutenants Campus Facility Managers	Initial investigation; escalate to Security Team when appropriate. Start Event Log, identify risk, follow direction of the Security Team
College Stakeholders	Executive Council Board of Trustees	Help manage relationships with students and county constituents

Figure 1. IT Security Incident Response organization and responsibilities

3 Types of Information Technology Security Incidents

Although computer security incidents may take many forms, there are certain types of attacks that occur more frequently than others. Knowing what these types of attacks are and how IT

3.1 Internal and External Threat

Internal Threat: An internal threat is any instance of a user misusing resources, running malicious code or attempting to gain unauthorized access to an application. Examples include unauthorized use of another user's account, unauthorized use of system privileges, and execution of malicious code that destroys data. More significant internal threats may include an otherwise authorized system administrator who performs unauthorized actions on a system or systems.

External Threat: An external threat is any instance of an unauthorized person attempting to gain access to systems or cause a disruption of service. Examples include “getting into a system” to steal information, disruption/denial of service attacks, mail spamming, and execution of malicious code that destroys data or corrupts a system.

3.2 Malicious Code Attacks
Malicious code is typically written to mask its presence thus it is often difficult to detect. Self replicating malicious code, such as viruses and worms, can replicate so rapidly that containment can become an especially difficult problem. Dealing with malicious code attacks requires special considerations.

3.2.1 Virus Incidents
A virus is self-replicating code that operates and spreads by modifying executable files. Viruses are often user-initiated and would pose virtually no threat if every user always followed sound procedures. E-mail ‘executables’ tend to carry infectious virus coding.

IT Response: IT provides all users with notices and alerts concerning viruses and the procedures that limit the spread of viruses. IT has anti-virus tools in place, including a virus scanner on each Windows desktop PC, Windows server, and Exchange mail server. IT also does real time scanning of traffic for viruses at the
Firewall.

IT will immediately evaluate the threat and remove any computer(s) suspected to be infected by a virus from the network.

3.2.2 Macro Viruses
Macro viruses are a specific type of virus that utilizes an application's own macro programming language to distribute themselves (e.g., in MS Word or MS Excel).

IT Response: Because macro viruses infect document files rather than programs, IT has extended its virus protection to include the examination of all files using the latest commercial anti-virus application(s).

3.2.3 Worms
A Worm is self-replicating code that is self-contained, (i.e., capable of operating without modifying any software). Worms are best noticed by looking at system processes. If an unfamiliar process (usually with an unknown name) is running and is consuming a large proportion of a system's processing capacity, the system may have been attacked using a worm. Worms also sometimes write unusual messages to users' displays to indicate their presence. Messages from unknown users that ask the user to copy an electronic mail message to a file may also propagate worms. Worms generally propagate themselves over networks and can spread very quickly.

IT Response: If any IT staff member observes the symptoms of a worm, he or she must inform IT Support Center immediately.

Prompt killing of any rogue processes created by the worm code will minimize the potential for damage. If the worm is a network-based worm (i.e., uses a network to spread itself), the workstation, server, and client machine will be disconnected from the network.

3.2.4 Trojan Horses
Trojan horse programs are hostile programs masquerading as valid programs or utilities. Most malicious code is really a Trojan horse program in one way or another. Trojan horse programs are often designed to trick users into copying and executing them.

IT Response: If any IT staff member observes the symptoms of a Trojan horse, he or she must inform IT Support Center immediately.

Prompt removal of any malicious code (typically done using anti-virus software) will minimize damage to systems.

3.2.5 Cracking Utilities
Cracking utilities are programs used to assist attackers for a variety of purposes, such as elevating privileges, obtaining passwords, disguising the attackers’ presence and so forth. They may be planted on our systems, or be used from outside the system, to either gather information or launch attacks against the target system.

IT Response: If a system is found to have cracking utilities on it, the response will vary depending on the circumstances. IT Support Center must be informed immediately. Refer to section 3.3 a detailed response description.

3.2.6 Ransomware
Ransomware is a form of malware that, when executed, will encrypt all files on a device. Once files are encrypted, a malicious actor will ask the victim to pay a ransom using some form of cryptocurrency to an untraceable account. If the ransom is paid the actor will provide the victim a code to unlock the files and return the device to a usable state. If the ransom is not paid, actors have been known to leak sensitive data stolen from the victim’s computer in an effort to extort payment. Some ransomware has been engineered to be wormable which means if activated it can spread through the network encrypting any connected device.

IT Response: All anti-virus and ant-malware applications used by IT include ransomware detection and protection. If ransomware attempts to run on a protected device, the attack is prevented and an alert is sent out via the anti-virus management software. At that point the device will be contained and evaluated before returning to the network.

3.3 Cracker/Hacker Attacks¹Crackers and hackers are users who attempt to obtain unauthorized access to remote systems. Until recently, crackers and hackers used virtually the same surreptitious methods to intrude. The average hacker still sits at a PC or terminal entering commands, waiting to see what happens, and then entering more commands. Now, most cracking attacks are automated and take only a few seconds, which makes identifying and responding to them more difficult. Crackers now generally use "cracking utilities," (described above) which usually differ from conventional malicious code attacks in that most cracking utilities do not disrupt systems or destroy code. Cracking utilities are typically "a means to an end," such as obtaining administrative-level access, modifying audit logs, etc. Rootkits are used in some cases to hide other cracker/hacker activities which makes discovery all the more difficult.

Indications that a cracker or hacker may have compromised a system include the following
symptoms:

Changes to directories and files
A displayed last time of login that was not the actual time of last login
Finding that someone else is logged into an individual's account from another terminal
Inability to login to an account (often because someone has changed the password).

IT Response: If these or other suspicious symptoms are noticed, IT Support Center should be notified immediately.

If an attacker is caught in the act of obtaining unauthorized access, IT follows procedures dependent on the nature of the attack.

If the attacker has obtained administrative-level access, is deleting or changing user files, or has access to a machine that contains sensitive data, the attack poses a serious threat. In this case, IT locks the attacker out of this system by aborting the processes the attacker has created.
If the cracker does not obtain administrative-level access and does not appear to be damaging or disrupting a system, IT may elect to allow the attacker to continue so as to collect the evidence necessary to determine any tools or vulnerabilities that need to be removed before serious damage occurs. To continue in this manner requires the approval of the IT Senior Management Team (CIO, Executive Director).
The CIS faculty teaches a network security class in which Cracking tools are used. The IT Security Team is aware of, and allows the use of these tools in the context of the classroom environment. Students are not permitted to use Cracking tools on non-classroom environment servers.

A critical stage in cracker/hacker attacks is eradication. Because crackers so frequently use cracking utilities, it is important to ensure that no cracking scripts remain on the system once the cracker's attack has ceased. Ultimately, this often requires a complete re-imaging of any affected system(s).

Another critical component of responding to cracker/hacker attacks is handling evidence that is gathered. System log printouts, copies of malicious code discovered in systems, backup tapes, referring to chains of custody and entries recorded in logbooks may conceivably be used as evidence against perpetrators. (See section 4.2.4).

IT Response: If a system user finds evidence of such cracking artifacts, IT will make copies of the artifacts and forward them to the Cyber Security Analyst for further examination. The Cyber Security Analyst and System Administrators will work to restore any file permissions and configuration settings that the attacker may have changed to their normal value. Resolving cracker/hacker attacks is risky, unless one possesses the technical skills, programs, and appropriate equipment.

3.4 Technical Vulnerabilities
As opposed to an internal or external threat, a technical vulnerability is a “hole” or weakness in an information system or components (e.g., system security procedures, hardware design, and internal controls) that could be exploited to violate system security. Any technical vulnerabilities in applications and operating systems that are discovered during Development Testing, User Acceptance Testing, or Security Scanning and Evaluation will be resolved but there is always a threat of as-yet-unknown gaps in system security.

IT Response: If a user discovers a technical vulnerability that could be used to subvert system or network security, he or she should immediately document that vulnerability. This document should record the following information:

Describe the vulnerability
Describe the circumstances under which the vulnerability was discovered
Describe the specific impact of the weakness or design deficiency
Indicate whether or not the applicable vendor has been notified.

After documenting the vulnerability, the information should be brought immediately to the attention of IT Management and/or Cyber Security Analyst. Do not send vulnerability reports over the network, or share vulnerability information with anyone outside of official channels. Hand carry paper or electronic documents to IT Management and/or Cyber Security Analyst who will coordinate the efforts to resolve the vulnerability with the system administrator and associated parties.

3.5 Legal Incidents
Legal incidents are not always attacks directly against the organization or a vulnerability that can be exploited. These incidents may include situations where local, state or federal law enforcement agents are involved. This could include, but may not be limited to, local, state or federal agents entering the college premises with a warrant authorizing the seizure and confiscation of computer hardware that has been involved in a security incident.

IT Response: Any time external law enforcement agents are involved, the Director of Public Safety and a member of the IT Senior Management Team (CIO, Executive Director) should immediately be notified. In coordination with the Office of Legal Affairs, the proper legal response will be determined.

If a valid warrant has been authorized, and law enforcement must ast quickly, the college will not impede the law enforcement agent from carrying out the specifics of the warrant. The responding college employee must notify Public Safety and the Office of Legal Affairs as soon as possible.

3.6 Physical Attacks
A physical attack is where physical security is compromised and the attacker attains access to
either system (PC, Server) or removable data media (diskette, thumb drive, backup tape, CD, DVD, Zip). The result of the access may be damage, destruction, theft of the system(s) or data, or altering systems to allow future access.

IT Response: Contact Public Safety to secure the location and contain the physical access breach. Cyber Security Analyst and/or IT Management must be informed immediately to evaluate the situation and the probability of compromise to a system or data.

3.7 “Social Engineering” Attacks
A “Social Engineering” attacker uses deception and fraud to gain access to college systems or information. An example would be “phishing”/”pharming” e-mails or web-pages which trick a user into providing sensitive information, such as usernames, passwords and credit card details, by masquerading as a trustworthy entity in an electronic communication. The possible approaches could be by almost any path, including e-mail, web-pages, telephone, paper mail, and face-to-face meetings.

IT Response: If a system user receives a suspicious email or other suspicious symptoms are noticed, IT Support Center should be notified immediately.

If a system user realizes after the fact that they have been tricked, IT Support Center should be notified immediately

If an attacker is caught in the act of obtaining unauthorized access, IT follows procedures dependent on the nature of the attack.

If the attacker has obtained administrative-level access, is deleting or changing user files, or has access to a machine that contains sensitive data, the attack poses a serious threat. In this case, IT locks the attacker out of this system by aborting the processes the attacker has created.
If the attacker does not obtain administrative-level access and does not appear to be damaging or disrupting a system, the IT Security team may elect to allow the attacker to continue so as to collect the evidence necessary to determine any tools or vulnerabilities that need to be removed before serious damage occurs. To continue in this manner requires the approval of the IT Senior Management Team (CIO, Executive Director).

3.8 Unintentional release of confidential or protected information
Through some combination of human error, process failure, and/or technological condition, confidential or sensitive information may be unintentionally released from the college. In the event this occurs, the information release must be contained immediately and swift corrective
action taken to prevent any further release.

IT Response: If a user discovers a confidential/sensitive information release, he or she should immediately document the symptoms of the release. This document should record the following information:

Describe the information released
Describe the circumstances under which the information release was discovered
Describe the scope of the information released, if possible.

After documenting the circumstances, the situation should be brought immediately to the attention of IT Management and/or Cyber Security Analyst. Do not send reports over the network if they contain any description(s) of a vulnerability which may be exploited, or share vulnerability information with anyone outside of official channels. Hand carry paper or electronic documents to IT Management and/or Cyber Security Analyst who will coordinate the efforts to resolve the vulnerability with the system administrator and associated parties.

4 Procedures for Responding to Incidents

IT defines six stages of response when servicing a computer security incident: Preparation, Identification, Containment, Eradication, Recovery, and Follow-up. Knowing about each stage facilitates responding more methodically and efficiently, and helps key staff understand the process of responding so that they can deal with unexpected aspects of incidents they face.

Confidentiality
In the event of an IT security incident, uncontrolled release of details about the nature of the event and/or the information compromised in the incident can cause 3 negative outcomes:

The perpetrator(s) may gain additional information about their victim (OCC), or be “tipped off” about the investigation, which may reduce our chances of apprehending the perpetrator.
Confidential data, whether student records, personal information, or internally sensitive material, can be leaked inadvertently;
Erroneous media exposure about OCC or its employees may result.

Therefore, anyone involved with the discovery of, or the response to an incident, should handle event details with the greatest level of confidentiality. Information should only be shared on a ‘need to know’ basis and only with those who are involved with the response to the incident.

The following section defines the six stages of response.

4.1 Preparation
IT considers being prepared to respond to an incident before it occurs to be one of the most critical facets of incident handling. This advanced preparation avoids disorganized and confused responses to incidents. It also limits the potential for damage by ensuring that response plans are familiar to all staff, thus making coordination easier.

4.1.1 Baseline Protection
IT has installed baseline protection on all College’s systems and networks. All computing components have a first-line level of defense to keep incidents from spreading quickly from system to system. The local area network (LAN) servers have access controls set so that no one except the LAN administrator(s) can write to system executables.

As is always the best practice, all system administrators must maintain compliance with Computer Emergency Readiness Team (CERT) notices, bulletins, and incident and vulnerability notes to ensure that all appropriate defensives are in place before an incident occurs.

IT has obtained tools in advance to avoid the potentially damaging delays that can occur when starting to procure such tools after an incident has happened. Examples include virus detection and eradication tools.

4.1.2 Planning and Guidance
IT has established an IT Security Team (section 2.3). Assigned security personnel will be
available during a critical incident involving one or more essential systems. Each relevant work group within IT will contribute one or more team member(s), as needed, to participate in the analysis and resolution of security incidents.

IT has planned for emergency communications needs. Should an incident adversely affect regular communication channels, IT has prepared lists of personnel to be contacted during incidents, including home phone numbers and cell phones.

IT has created this written incident response plan and distributed it to all levels of IT staff. This written guidance is structured to help IT staff respond to unexpected events that may be symptoms of computer security incidents.

4.1.3 Training
Appropriate training will be provided to all IT Security personnel and other appropriate staff members on a regular basis. Training helps update their knowledge and skills in handling security incidents.

4.2 Identification
The approach to the Identification Stage involves:

Validating the incident
If an incident has occurred, identify its nature
Identifying and protecting the evidence
Logging and reporting the event or incident.

When a staff member notices a suspicious anomaly in data, a system, or the network, he or she begins this identification process.

4.2.1 Analyzing the Symptoms
Determining whether or not an anomaly is symptomatic of an incident is difficult since most often apparent symptoms of a security incident are something else, (e.g., errors in system configuration, application bugs, hardware failures, user error, etc.).

Typical symptoms of computer security incidents could include, but not be limited to, the following:

A system alarm or similar indication from an intrusion detection tool
Suspicious entries in system or network log files
Accounting discrepancies
Repeated unsuccessful logon attempts
Unexplained, new user accounts
Unexplained new files or unfamiliar file names
Unexplained modifications to file lengths and/or dates, especially in system executable files
Unexplained attempts to write to system files or changes in system files
Unexplained modification or deletion of data
Denial/disruption of service or inability of one or more users to login to an account
System crashes
Poor system performance
Alerts from a program or sniffer device that monitors network traffic
Remote requests for information about systems or users (e.g., social engineering)
Unusual time of usage (many computer security incidents occur during non-working hours)
An indicated last time of usage of a user account that does not correspond to the actual last time of usage for that user
Unusual usage patterns (e.g., programs are being compiled in the account of a user who does not know how to program, an escalation in disk usage by a single account )

4.2.2 Identify the Nature of the Incident
Although no single symptom conclusively shows that a computer security incident has occurred or is taking place, observing one or more of these symptoms prompts the observer to investigate events more closely. IT Staff members who encounter one or more of these symptoms should report it to the Director of Enterprise Systems and Security. The Cyber Security Analyst will document, examine, and validate security incidents on a case by case basis, looking for FERPA, PCI or PII violations.

IMPORTANT NOTE: If the Cyber Security Analyst believes any sensitive student or employee data may have been lost or stolen, it should be immediately reported to IT Senior Management (CIO, Executive Director).

4.2.3 Identify the Evidence
In order to protect the evidence, number, date and sign notes and printouts, store complete logs in a safe, or copy the entire log to an alternate location and secure appropriately.

4.2.4 Protect the Evidence
Documentation should be provided that indicates the sequence of individuals who have handled the evidence and the sequence of locations where the evidence has been stored. (The evidence should be stored, at all times, in a locked environment). Dates and times must be specified as well. There must not be any lapses in time or date. The hand-off of evidence must be documented as well.

The Cyber Security Analyst, or designee, should capture, using forensic level mirroring software, an exact copy of any system(s) in which suspicious events have been observed as soon as a computer security-related incident has been declared. If the Cyber Security Analyst believes this event may lead to criminal charges, a Public Safety Officer shall be
called upon and the mirrored data will be handed off immediately.

Since perpetrators of computer crimes are becoming increasingly proficient in quickly destroying evidence of their illegal activity, be aware that, unless evidence is immediately captured by making a full backup, this evidence may be destroyed before it can be examined. This backup will provide a basis for comparison later to determine if any additional unauthorized activity has occurred.

4.2.5 Report the Events
If a computer-based incident is detected, it must be reported immediately to IT Support Center who will then contact the Director of Enterprise Systems and Security or the Cyber Security Analyst.

In addition, Cyber Security Analyst has the responsibility to report incident information to senior management in a timely fashion. If the attacker successfully accessed any part of OCC’s systems, the Cyber Security Analyst will also report the incident to the Director of Public Safety. The system and network audit logs provide sufficient information to facilitate deciding whether or not unauthorized activity has occurred. In the event of a serious breach of security or evidence of criminal activity, the Cyber Security Analyst will notify the IT Senior Management Team.

CAUTION: Except otherwise required by law, no IT staff member, except Senior IT management (CIO, Executive Director) and the Cyber Security Analyst has authority to discuss any security incident with any person outside of IT.

4.3 Containment
The immediate objective for the Containment Stage is to limit the scope and magnitude of an incident as quickly as possible, rather than to allow the incident to continue in order to gain evidence for identifying and/or prosecuting the perpetrator.

The first critical decision to be made during the containment stage is what to do with critical information and/or computing services. A decision will be made regarding whether the sensitive data is to be left on the system or copied to media and taken off-line. Similarly, a decision may be made to move critical computing services to another system on another network where there is considerably less chance of interruption.

A decision on the operational status of the compromised system itself will be made. Whether this system should be 1) shut down entirely, 2) disconnected from the network, or 3) be allowed to continue to run in its normal operational status (so that any activity on the system can be monitored) will depend on the risk to assets threatened by the incident.

In the case of a simple virus incident, IT will move quickly to eradicate any viruses. If the system is highly sensitive or information and/or critical programs may be at risk, IT will generally shut down the system or temporarily isolate it from the network.

If there is a reasonable chance that letting a system continue to run as normal without risking serious damage, disruption, or compromise of data can identify a perpetrator, IT may continue operations under close monitoring.

4.3.1 Maintain a Low Profile
If a network-based attack is detected, IT must be careful not to tip off the intruder. Avoid looking for the attacker with obvious methods; if hackers detect an attempt to locate them, they may delete files and/or systems.

4.3.2 Avoid Potentially Compromised Code
It is not advisable to log in as root or administrator and then start typing commands to a system suspected of being compromised. For example, avoid using ftp to download tools from another site. If possible, record the fingerprint of critical binaries for the organization's core operation systems. This ‘fingerprint’ will be compared to a baseline (known good) ‘fingerprint’.

4.3.3 Back up the System
Back up the affected system to new, unused media if at all possible. Make a backup as soon as there are indications that a security incident has occurred. Making a full back up immediately captures evidence that may be destroyed before having a chance to look at it. Make two backups whenever possible: One to keep sealed as evidence and one to use a source for additional backups.

4.3.4 Change Passwords
It is recommended that we need to change the system administrator and/or affected staff passwords immediately on all affected systems. Passwords should be changed on comprised systems and on all systems that regularly interact with the compromised systems and notify all affected staff of the password change. If a sniffer device is detected or suspected, passwords may have been compromised on all systems on the LAN. In this case, more accounts may be required to change their password.

4.4 Eradication
The next priority, after containing the damage from a computer security incident, is to remediate the cause of the incident.

In the case of a virus incident, IT will remove the virus from all systems and media by using one or more proven commercial virus eradication applications.

IT recognizes that many intrusions leave benign or malignant artifacts that can be hard to locate. Therefore, IT will concentrate on the eradication of 1) malignant artifacts (e.g., Trojan horses) and 2) benign artifacts when they present a serious risk. This will likely be achieved by erasing the hard drive and re-imaging the system.

4.4.1 Determine the Cause and Symptoms
Use information gathered during the containment phase and collect additional information. If a single attack method cannot be determined, list and rank the possibilities.

4.4.2 Improve Defenses
Implement appropriate protection techniques such as firewalls and/or router filters, moving the system to a new name/IP address, or in extreme cases, porting the machine's functions to a more secure operating system.

4.4.3 Perform Vulnerability Analysis
Use Qualys or a comparable product as a vulnerability analysis tool to scan for vulnerable systems that are connected to affected systems.

4.5 Recovery
IT defines recovery as restoring a system to its normal mission status.

4.5.1 Determine the Course of Action
In the case of relatively simple incidents (such as attempted but unsuccessful intrusions into systems), recovery requires only assurance that the incident did not adversely affect the College’s computer or data resources.

In the case of complex incidents, such as malicious code planted by insiders, recovery may require a complete restoration operation from backup tapes, a re-image of the machine or partial/full implementation of the IT BCP plan in the event of a brute cyber terrorist attack.

4.5.2 Monitor and Validate System
First, determine the integrity of the backup itself by attempting to read its data. Once the system has been restored from backup, verify that the operation was successful and that system is back to its normal operating condition.

Second, run the system through its normal tasks monitoring it closely by a combination of network loggers and system log files. Monitor the system closely for potential “back doors” that may have escaped detection.

4.6 Follow-up
IT realizes that devoting further resources to an incident after the Recovery Stage is not always cost effective. However, IT also realizes that following up on an incident after Recovery helps to improve incident handling procedures.

4.6.1 Review and Document the Quality of the Response to the Incident
Within 3 weeks after an incident IT, the Director of Enterprise Systems and Security will lead review how well they responded to the incident (using IT’s established Corrective Action Root Cause Analysis). This review will include at least one member of Senior IT management (CIO, Executive Director).

Was there sufficient preparation for the incident?
Did detection occur promptly or, if not, why not?
Could additional tools have helped the detection and eradication process?
Was the incident sufficiently contained?
Was communication adequate, or could it have been better?
What practical difficulties were encountered?

Annually, Senior IT management (CIO, Executive Director) will review these Corrective Action analyses to determine if there are systemic improvements to be made.

4.6.2 Document Incident Costs
IT will review the staff time required to address incidents (including time necessary to restore systems). This leads to the following cost analyses:

How much is the associated monetary cost?
How much 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, and, if so, what was the cost?

Deriving a financial cost associated with an incident can help to justify future budget requests for security efforts.

4.6.3 Filing a Report
Depending on the type of incident, the Director of Enterprise Systems and Security will file a report of the incident to further IT staff awareness. Without endangering the IT security mechanisms, the report will be appropriately distributed.

4.6.4 Revising Policies and Procedures
IT realizes that developing effective computer security policies and procedures often requires revising those efforts in light of experience. Therefore, lessons learned from each incident are used to review the IT computer security measures.

4.7 Notification
If the incident involves the potential loss of student or employee personally identifying information or financial information, notification to those affected is required by our fiduciary responsibility to our users, and also may be required as directed by Michigan Public Act 566 of 2006. The reporting will be done after approval by IT Incident Response Advisory Team with concurrence from the Chief Counsel.

Notification must be done “without undue delay”. Such notification may be delayed for two issues (but must proceed after the issues are resolved)

It may be delayed while OCC takes measures necessary to determine the scope of the security breach and restore the reasonable integrity of the database (including determination of what information was compromised, and who was affected).
If a law enforcement agency determines and advises OCC that providing a notice will impede a criminal or civil investigation or jeopardize homeland or national security.

Notification may be done by various means in accordance with Public Act 566. OCC may also concurrently send a message via e-mail to those affected people with e-mail addresses registered in Colleague – but as e-mail addresses are currently not believed complete (especially if some of the affected people are students have not been in school recently.), email would not be used as the sole notification process.

5 Conclusion

This IT security incident response plan provides reasonable methods for limiting the possibility of an adverse effect on all the College’s computing assets and networks due to the occurrence of an information system security incident, and for facilitating the rapid and successful recovery from an incident, should one occur.

It stresses two fundamental principles related to incident response.

The first principle is the importance of following well-defined and systematic procedures for responding to computer security-related incidents. The six stages of the incident response procedures (preparation, detection, containment, eradication, recovery, and follow-up) provide a sound basis for securing all the College’s computer resources. They also serve as a foundation for developing custom procedures tailored to specific operational environments. The only effective way to respond to incidents is to use a structured methodology.

The second principle is that unless conducted systematically, incident response efforts are of little value. Coordination of effort is a critical facet of incident response. IT staff members can significantly reduce the staff hours needed to respond to incidents if properly coordinated.

6 Policy Documentation

Availability
This IT Security Incident Response Plan is for use by the IT security incident managers and responders.

Changes
The IT Security Incident Response Plan is a "living" document that will be altered as required to deal with changes in technology, applications, procedures, legal and social imperatives, perceived dangers, etc. It is reviewed by Chief Information Officer & staff on annual basis and any major changes are approved by the IT Incident Response Advisory Team committee.

Appendix A: Glossary

Glossary of Terms
Anomaly	An unusual or atypical event (in a system or network).
Attack Scanner	A tool used to remotely connect to systems and determine security vulnerabilities that have not been fixed.
Cracker	A person who obtains or attempts to obtain unauthorized access to computer resources for specific, premeditated crimes. (See also Hacker)
Checksum	Value computed, via some parity or hashing algorithm, on information requiring protection against error or manipulation.
Code	A system of communication in which arbitrary groups of letters, numbers, or symbols represent units of plain text of varying length.
Cracking Utilities	Programs planted in systems by attackers for a variety of purposes such as elevating privileges, obtaining passwords, and disguising the attacker's presence.
Cryptographic	A checksum that is generated using a checksum cryptographic means. It is used to detect accidental or deliberate modification of data.
Denial of Service	(DOS) occurs when an intruder uses malicious code to disrupt computer services, including erasing a critical program, “mail spamming” i.e., flooding a user account with electronic mail, or altering system functionality by installing a Trojan horse program.
Encryption	Using encryption renders information unintelligible in a manner that allows the information to be decrypted into its original form - the process of transforming plaintext into cipher text.
Espionage	Espionage is stealing information to subvert the interests of IT, Oakland Community College, the Federal government, or gaining access to a competitor's data to subvert contract procurement regulations.
Event	Any observable occurrence in a computer system or network, e.g., the system boot sequence, port scan, a system crash, or packet flooding within a network. Events sometimes provide an indication that an incident is occurring, although not necessarily.
Firewall	Used to control access to or from a protected network. Enforces a network access policy by forcing connections to pass through this system, where they can be examined and evaluated. The system can be a router, a personal computer, a host, or a collection of hosts, set up specifically to shield a site or subnet from protocols and services that can be abused from hosts outside the subnets.
Hacker	A person who obtains or attempts to obtain unauthorized access to a computer for reasons of thrill or challenge. (See also Cracker)
Hoax	A hoax occurs when false stories, fictitious incidents or vulnerabilities are spread (e.g., virus warnings that do not exist).
Incident²	An incident is defined as any adverse event whereby some aspect of computer security could be threatened: loss of data confidentiality, disruption of data or system integrity, or disruption or denial of availability. Examples include penetration of a computer system, exploitation of technical vulnerabilities, or introduction of computer viruses or other forms of malicious software.
Integrity	(1) A sub-goal of computer security which pertains to ensuring that data continues to be a proper representation of information, and that information processing resources continue to perform correct processing operations. (2) A sub-goal of computer security which pertains to ensuring that information retains its original level of accuracy. Data integrity is that attribute of data relating to the preservation of: (a) its meaning and completeness, (b) the consistency of its representation(s), and (c) correspondence to what it represents.
Intrusion	Unauthorized access to a system or network
Malicious code attacks	Include attacks by programs such as viruses, Trojan horses, worms, and scripts used by crackers/hackers to gain privileges, capture passwords, and/or modify audit logs to exclude unauthorized activity.
Malware	Software designed to infiltrate or damage a computer system without the owner’s informed consent. Also known as Malicious code.
Misuse	Misuse occurs when someone uses a computing system for other than official or authorized purposes.
Pharming	A more sophisticated “Phishing” technique which involves preserving an URL but secretly changing the associated IP address to redirect a website's traffic to another (bogus) website.
Phishing	A “social engineering” technique to fraudulently acquire sensitive information, such as usernames, passwords and credit card details, by masquerading as a trustworthy entity in an electronic communication.
Rootkit	A rootkit is a cloaking software tool used by crackers to conceal files, utilities or other software from the Operating System (OS) and/or the system administrator. Crackers can use rootkit technology to hide malware which allows them access and/or control of the computer.
Social Engineering	A collection of techniques used to manipulate people into performing actions or divulging confidential information that they would not normally want to do. (See Phishing, Pharming).
Sniffer	A device or program that captures packets transmitted over a network
Social engineering	"Conning" unsuspecting people into sharing information about computing systems (e.g., passwords) that should not be shared for the sake of security.
Threat	Capabilities, intentions, and attack methods of adversaries to exploit any circumstance or event with the potential to cause harm to information or an information system.
Tiger Team	Government and industry - sponsored teams of computer experts who attempt to break down the defenses of computer systems in an effort to uncover, and eventually patch, security holes.
Trojan horse	Computer program containing an apparent or actual useful function that contains additional (hidden) functions that allows unauthorized collection, falsification or destruction of data.
Unauthroized access	Unauthorized access encompasses a range of incidents from improperly logging into a user's account (e.g., when a hacker logs in to a legitimate user's account) to obtaining unauthorized access to files and directories possibly by obtaining "super-user" privileges. Unauthorized access also includes access to network data gained by planting an unauthorized "sniffer" program (or some such device) to capture all packets traversing the network at a particular point.
Virus	Self replicating, malicious program segment that attaches itself to an application program or other executable system component and leaves no external signs of its presence.
Vulnerability	A weakness in an information system, cryptographic system, or components (e.g., system security procedures, hardware design, internal controls) that could be exploited to violate system security policy.
Worm	An independent program that replicates from machine to machine across network connections often clogging networks and computer systems as it spreads.

References

Administrative Information Technology Services (AITS), University of Illinois, Urbana Champaign Incident Response Plan.

Schultz E. & Shum way R., Incident Response: A strategic Guide to Handling System and Network Security Breaches, New Riders, 2002

Federal Agency Security Practices (FASP), FASP: Incident Response Capability, December 27, 2002.

Internet Security Systems, Computer Security Incident Response Planning (PDF), 2001

Federal Communications Commission, FCC Computer Security Incident Response Guide (PDF) December 2001.

Center for Information Technology (CIT), Security Policies, Guidelines and Regulations, 02/06/2003

Michigan Compiled Laws, Chapter 445. Trade and Commerce §445.72. Notice of security breach; requirements.

¹The principal distinction between these two types of intruders is that 1) "crackers" intrude with the intent of attacking specific systems, or inserting, deleting, or modifying specific data; 2) "hackers" intrude for the thrill. Hackers may cause damage, but it is as an afterthought, not premeditated.

²Includes both deliberate attacks and accidental violations, but, for the purposes of these guidelines, the term "incident" does not encompass such events as natural disasters or failures of basic services to the general community (e.g., power outages, loss of telephone service, etc.) unless caused by deliberate act.

Change Log

07-08-2021 Adopted

OCC Logo