Please click Incident Response Plan to download a PDF version of this document. 

Incident Response Plan

Policies & Procedures

Table of Contents

Organizational Details. 2

Code of Conduct 4

Information Classification and Disclosure. 5

Information Requests. 6

Human Error 8

HIPAA Violations. 8

Response Procedures for Payment Card Data Incidents. 9

Response Procedures for General Data Protection Regulation (GDPR) (EU) 10

Incident Severity. 10

Internal Contact List 13

Testing and Policy Review.. 14

Incident Handling. 14

Training. 16

How to Report an Incident 17

Definitions. 17

References. 18

 

Organizational Details

 

Mission Statement

The mission of the Loyola University Chicago Information Security Incident Response Team (LISIRT) is to promote a computing environment which ensures the confidentiality, availability, and integrity of the University’s data and systems. LISIRT will handle all information security incident analysis and response for systems managed by Information Technology Services (ITS), and will offer to assist with any information security incidents on systems within the Loyola network that are not managed by ITS. LISIRT will investigate reports of violations of Loyola ITS policies (http://luc.edu/its/policies.shtml). LISIRT will strive to consistently provide quality service in a timely fashion.

Constituency

The constituency of the LISIRT can include all persons accessing and using computing, networking, telephony and information resources through any facility of the University. These persons include students, faculty, staff, persons retained to perform University work, and any other person extended access and use privileges by the University given the availability of these resources and services, and in accordance with University contractual agreements and obligations.

Authority

When a security incident has been declared, the LISIRT team takes on the ownership and responsibility of the incident handling process. This can include directing key members of ITS staff on incident handling decisions and taking the necessary actions to remediate the issue without first discussing it with affected constituents. This includes the possibility of taking temporary action to mitigate a threat posed against the entire network by a segment of the network that is not managed by ITS. Any actions taken without previous discussion will be discussed with affected departments after the issue has been mitigated. The LISIRT will maintain open lines of communication with the affected constituents during the incident handling process.

Organizational Placement

LISIRT is housed within Loyola University Chicago’s ITS division. The team will be headed by the Chief Information Security Officer, or his or her appointee, referred to as the LISIRT lead in this document. The team will include members of the Information Security Office, as well as appropriate ITS leadership team members depending on the scope of the incident. The LISIRT may recruit key members within the University to aid in the handling of an incident. These members will run all communications, technical and logistical decisions through the LISIRT.

Services

LISIRT will provide the following services to its constituents:

• Incident handling
• Investigations of potential violations of Loyola policies, procedures, standards, and guidelines.

Incident Handling

The first step in the incident handling process begins when an event is detected by or reported to LISIRT. The LISIRT Lead will evaluate the event and determine if the Incident Response (IR) is appropriate. If the IR is enabled, all the authority granted within this plan will be granted to the LISIRT and a security incident will be declared. Logging of the incident begins, and the incident is triaged in accordance with the procedures defined within.

If the LISIRT lead is unavailable during the time of the event, the LISIRT’s backup, or any member of the LISIRT team, may declare a security incident and enable the IR after an evaluation of the event. The LISIRT team member that has escalated the incident will become the LISIRT Lead for the duration of the incident unless when the LISIRT lead becomes available, he or she may decide to transition the LISIRT lead role.

Incidents will be brought to the attention of the ITS Leadership Team, including the CIO, at the time when they are first classified as outlined in the Data Breach Response Policy. All incidents will be detailed in a monthly report that is sent to the ITS Leadership Team and the CIO.

Investigations of potential violations of Loyola University policies

LISIRT serves a supporting role for Human Resources, Office of the General Counsel, Student Affairs, and other departments. Requests from departments not specifically identified previously must be authorized by Human Resources or the Office of the General Counsel. LISIRT will perform technical investigations at the request of these bodies, while appropriately respecting the privacy rights of all individuals involved. This can include accessing electronic and voice mail, in accordance with the ITS policies (https://www.luc.edu/its/aboutus/itspoliciesguidelines/).  

Code of Conduct 

All LISIRT members are expected to adhere to the code of conduct detailed in this plan. Violations of the code of conduct may be grounds for dismissal from the LISIRT, and possible disciplinary action following standard University procedures for such actions, depending on the nature of the violation.

The code of conduct is designed to ensure that LISIRT members are professional, consistent, and service oriented, while exercising appropriate confidentiality, care and providing quality service.

Individuals covered

This policy covers all members of the LISIRT. Any members of ITS assisting with LISIRT business are also covered.

Policy

All members of the LISIRT are expected to be familiar with and follow all LISIRT policies. A copy of all LISIRT policies will be provided when an individual joins LISIRT. Revisions to LISIRT policies will be provided to all LISIRT members for comments, and updates to any policies will be provided to all current LISIRT members.

All LISIRT members are expected to perform LISIRT tasks to the best of their ability. All LISIRT members are expected to communicate LISIRT information only with individuals who have a need to know, and who should have access to the information based on its classification under the Data Classification Policy. When communicating LISIRT matters, all LISIRT members are expected to be constructive, to communicate with an appropriate level of technical detail based on the audience, and to project a professional image. LISIRT members should not hesitate to say that they “do not know the answer” if that is the case. LISIRT members will refer any inquiries from media representatives to University Marketing & Communications instead of providing an answer.

Information Classification and Disclosure   

All information received by LISIRT is initially shared only within LISIRT. Once the information is properly classified, it may be possible to share the information with a wider audience.

Individuals covered

This policy covers all members of the Loyola University LISIRT. Any members of ITS assisting with LISIRT business are also covered.

Policy

Information received by LISIRT can be classified as one of two types of data:

• Sensitive
• Non-sensitive

Sensitive information is information that will only be shared with LISIRT, the ITS Leadership Team and the CIO, Office of the General Counsel, Human Resources and any individuals designated by the ITS Leadership Team or the CIO. Any information which can easily be tied back to an individual is classified as Sensitive. In keeping with existing Loyola policies (https://www.luc.edu/its/aboutus/itspoliciesguidelines/), a user’s right to privacy must be respected as much as possible even when they are suspected of violating Loyola policies. Sensitive materials may be reclassified if identifying information has been sanitized. Any materials which contain Loyola Protected data or Loyola Sensitive data, as defined under the Loyola Protected Data and the Loyola Sensitive Data Identification Policy (https://www.luc.edu/its/aboutus/itspoliciesguidelines/protectedsensitivedatapolicy/) will be treated as Sensitive by LISIRT.

Non-sensitive information is information that can be shared with individuals within ITS as needed. Non-sensitive information is not easily tied back to an individual. Non sensitive information typically includes IP addresses, timestamp's, and similar technical information. Non-sensitive information can be shared with other Loyola groups as metrics concerning the incidents and trending information. Non-sensitive information may be shared with any individuals within ITS and any system administrators within the University community who need to know about the incident.

Data is classified by the LISIRT member who initially receives it. If an item is classified as Non-sensitive, any LISIRT member can change the classification to Sensitive. If an item is classified as Sensitive, only the LISIRT lead can change the classification to Non-sensitive. If a member of the LISIRT is unsure of the classification assigned to a particular piece of information, they should assume that the information has been classified as Sensitive.

Information Requests  

Various external groups may request information from LISIRT. The requestor and the type of information requested will determine if the information can be released, and what steps need to be followed to release the information.

Individuals covered

This policy covers all members of the Loyola University LISIRT. Any members of ITS assisting with LISIRT business are also covered.

Policy

Requests from Loyola University Medical Center (LUMC)

The Loyola University Medical Center (LUMC) shares a number of electronic resources with Loyola due to shared history. LUMC will contact Loyola’s LISIRT with technical information regarding possible incidents. LISIRT members are allowed to share any information that has been classified as Non-sensitive with LUMC. If LUMC is requesting information that has been classified as sensitive, the request must be approved by the LISIRT lead in consultation with the CIO and/or General Counsel. All communications with LUMC concerning incidents should carbon copy the LISIRT lead.

Requests from Internet Services Providers (ISPs), Incident Response Teams (IRTs), and the Research and Education Networking Information Sharing and Analysis Center (REN-ISAC)

ISPs, IRT’s, and REN-ISAC may contact Loyola’s LISIRT with technical information regarding possible incidents. Any messages of this nature should be forwarded to the LISIRT lead. The LISIRT lead will determine the appropriate response. The LISIRT lead may designate a member of the team to serve as the primary point of contact for communications concerning a particular incident, but all communications should carbon copy the LISIRT lead.

Requests from the media

All responses to requests for information made by members of the media must be approved by University Marketing and Communications.

If approached by a member of the media for a quote, LISIRT members should only reply with “no comment”, and direct the media representative to contact University Marketing and Communications.

If approached by a member of the media for trending information, LISIRT members should direct the media representative to contact the LISIRT lead. The LISIRT lead will work with University Marketing and Communications to determine if the requested trending information can be provided.

Requests from Law Enforcement

All responses to requests for information made by law enforcement must be approved by the Office of the General Counsel. The only exception to this is if a subpoena or a warrant is issued to ITS or the LISIRT. The warrant or subpoena must be honored; however immediate contact to the Office of the General Counsel must be made. The other exception is requests for trending data.

If approached by a member of law enforcement, LISIRT members should only direct the law enforcement agent to contact the LISIRT lead. The LISIRT lead will bring the request to the CIO and the Office of the General Counsel for approval, and then work with the law enforcement agent as appropriate.

If approached by a member of law enforcement for trending information, LISIRT members should direct the law enforcement agent to contact the LISIRT lead. The LISIRT lead will work with the Office of the General Counsel to determine if the requested trending information can be provided.

If a member of LISIRT discovers activities that are believed to violate local, state, or federal laws, they should bring the activities to the attention of the LISIRT lead. The LISIRT lead will work with the CIO and the Office of the General Counsel to determine if the information should be turned over to a law enforcement agency. If that is the case, the LISIRT lead will serve as the primary liaison between Loyola and the law enforcement agency.

Other Requests

Requests from non-ITS groups within Loyola for any additional information will need to be approved by the CIO, and may be subject to sanitizing before the information is released.

Information requests from outside of the University community will be evaluated individually. Requests for information from members of the media community will be forwarded to University Marketing and Communications. Requests for DMCA-related information will be forwarded to the DMCA agent as identified in the University Digital Millennium Copyright Act Policy (https://www.luc.edu/its/aboutus/itspoliciesguidelines/dmcapolicy/).

Decisions regarding other requests for information will be considered by the LISIRT lead.

Human Error  

 During a security incident, there is the possibility that a LISIRT member will make a mistake. The emphasis should be placed on correcting the mistake when it is detected, and working to improve the procedures to prevent similar mistakes after the incident has been resolved.

 Individuals covered

 This policy covers all members of the Loyola University LISIRT. Any members of ITS assisting with LISIRT business are also covered.

 Policy

 If any member of LISIRT believes that they identified a possible mistake in the investigation, all members of LISIRT who are working on the issue should be notified of the perceived mistake, why it is believed to be a mistake, and what effect this may have on the incident response.

 After the incident has been resolved, the LISIRT members involved in the incident will meet to determine what factors lead to the mistake. This is not an attempt to assign blame, but rather an attempt to refine the incident response process to prevent similar mistakes in the future.

 If a LISIRT member repeatedly makes the same or similar mistakes across a number of incidents, the LISIRT lead may ask the LISIRT member to resign their membership in the LISIRT.

 If the mistake constitutes a violation of a University policy (http://luc.edu/its/policies.shtml), the disciplinary procedure from that policy may apply. If that is the case, the LISIRT lead will be available to speak on the LISIRT member’s behalf, if needed.

HIPAA Violations

The primary focus of HIPAA is to improve the health insurance accessibility to people changing employers or leaving the workforce.  It also addresses issues relating to electronic transmission of health-related data in Title II, Subtitle F of the Act entitled “Administrative Simplification”.  The administrative simplification provisions include four key areas:

• National standards for electronic transmission
• Unique health identifiers for providers, employers, health plans and individuals
• Security Standards
• Privacy Standards

 

The HIPAA Security Standards require covered entities and business associates to implement policies and procedures to ensure:

• the confidentiality, integrity, and availability of all electronic protected health information
• protect against any reasonably anticipated threats or hazards to the security of such information
• protect against any reasonably anticipated uses or disclosures that are not permitted

 

Within this context, HIPAA requires covered entities and business associates to implement policies and procedures to address security incidents.  A security incident means the attempted or successful unauthorized access, use disclosure, modification, or destruction of information or interference with system operations in an information system.  Response and reporting implementation requirements include identifying and responding to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity or business associate; and document security incidents and their outcomes.

 

The HIPAA security standards were effective on April 21, 2003.   The compliance date for covered entities is April 21, 2005 and April 21, 2006 for small health plans.

 

Response Procedures for Payment Card Data Incidents

A Payment Card Data ‘incident’ is defined as a suspected or confirmed ‘data compromise’ or a ‘failure of critical security controls’. A ‘data compromise’ is any situation where there has been unauthorized access to a system or network where cardholder data is collected, processed, stored or transmitted. A ‘data compromise’ can also involve the suspected or confirmed loss or theft of any material or records that contain cardholder data. ‘Critical Security Controls include but are not limited to; firewalls, IDS/IPM, FIM, Anti-Virus, Physical Access Controls, Logical access controls and audit logging mechanisms.  Systems are monitored using OpsView Monitor which alerts Server Operations and Networking if an outage occurs.

All incidents in the Card Processing Environment must initially be reported to the University Information Security Office (UISO) via the Online Incident Reporting Form http://luc.edu/uiso/contactus/report.shtml or by email to datasecurity@luc.edu.

• The UISO will report the incident to the entire Loyola Information Security Incident Response Team (LISIRT).
• The LISIRT, along with other university staff, will investigate the incident and assist the compromised department in limiting the exposure of cardholder data.
• The LISIRT will resolve the problem to the satisfaction of all parties involved, including reporting the incident and findings to the appropriate parties (credit card associations, credit card processors, etc.) as necessary.

• The LISIRT Team will determine if policies and processes need to be updated to avoid a similar incident in the future.

---

 Response Procedures for General Data Protection Regulation (GDPR) (EU)

The General Data Protection Regulation (GDPR) (Regulation (EU) 2016/679) is a regulation by which the European Parliament, the Council of the European Union and the European Commission intend to strengthen and unify data protection for all individuals within the European Union (EU). It also addresses the export of personal data outside the EU. The GDPR applies to all companies processing the personal data of data subjects residing in the EU, regardless of the company’s location.  A GDPR Breach ‘incident’ is defined as Under the GDPR, as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed. There are specific legal procedures required by the GDPR.  Please consult the Incident Response Appendix immediately upon being informed of a potential incident.

• All incidents involving GDPR Protected Data must initially be reported to the University Information Security Office (UISO) via the Online Incident Reporting Form http://luc.edu/uiso/contactus/report.shtml or by email to datasecurity@luc.edu.

• The UISO will report the incident to the entire Loyola Information Security Incident Response Team (LISIRT).
• The LISIRT, along with other university staff, will investigate the incident and assist the compromised department in limiting the exposure of GDPR data.
• The LISIRT will resolve the problem to the satisfaction of all parties involved, including reporting the incident and findings to the appropriate parties (Individuals, collectors and processors, etc.) as necessary.
• The LISIRT Team will determine if policies and processes need to be updated to avoid a similar incident in the future.

---

Incident Severity

Incident response will be managed based on the level of severity of the incident. The level of severity is a measure of its impact on or threat to the operation or integrity of the institution and its information. It determines the priority for handling the incident, who manages the incident, and the timing and extent of the response. Four levels of incident severity will be used to guide incident response: high, medium, low, and NA (Not Applicable).

High
The severity of a security incident will be considered "high” if any of the following conditions exist:

Threatens to have a significant adverse impact on a large number of systems and/or people (for example, the entire institution is affected)

Poses a potential large financial risk or legal liability to the University

Threatens confidential data (for example, the compromise of a server that contains or names with social security numbers or credit card information)

Adversely impacts an enterprise system or service critical to the operation of a major portion of the university (for example, e-mail, student information system, financial information system, human resources information system, learning management system, Internet service, or a major portion of the campus network)

Poses a significant and immediate threat to human safety, such as a death-threat to an individual or group.

Has a high probability of propagating to many other systems on campus and/or off campus and causing significant damage or disruption

Medium
The severity of a security incident will be considered "medium" if any of the following conditions exist:

Adversely impacts a moderate number of systems and/or people, such as an individual department, unit, or building

Adversely impacts a non-critical enterprise system or service

Adversely impacts a departmental system or service, such as a departmental file server

Disrupts a building or departmental network

Has a moderate probability of propagating to other systems on campus and/or off campus and causing moderate damage or disruption

Low
Low severity incidents have the following characteristics:

Adversely impacts a very small number of systems or individuals

Disrupts a very small number of network devices or segments

Has little or no risk of propagation or causes only minimal disruption or damage in their attempt to propagate

NA (Not Applicable)
This is used for events reported as a suspected IT security incident but upon investigation of the suspicious activity, no evidence of a security incident is found.

Incident Response Summary Table
The following table summarizes the handling of IT security incidents based on incident severity, including response time, the responsible incident managers, and notification and reporting requirements. Detailed procedures for incident response and management are further defined in the Loyola University Chicago Incident Response Plan Appendix.

Incident Severity	Characteristics (one or more condition present determines the severity)	Response Time	Incident Manager	Who to Notify	Post-Incident Report Required*
High	Significant adverse impact on a large number of systems and/or people Potential large financial risk or legal liability to the University Threatens confidential data Adversely impacts a critical enterprise system or service Significant and immediate threat to human safety High probability of propagating to a large number of other systems on or off campus and causing significant disruption	Immediate	Chief Information Security Officer or an Executive Incident Management Team	Chief Information Security Officer Chief Information Officer Unit administrator (VP, Provost, Dean, etc.) Department Manager Technical support for affected device If breach of PII, see Loyola University Chicago Incident Response Plan Appendix for additional notification requirements	Yes
Medium	Adversely impacts a moderate number of systems and/or people Adversely impacts a non-critical enterprise system or service Adversely impacts a departmental scale system or service Disrupts a building or departmental network Moderate risk of propagating and causing further disruption	4 hours	Appointed by unit head	Chief Information Security Officer Department Manager Technical support for affected device	No, unless requested by the Chief Information Officer or other appropriate administrator
Low	Adversely impacts a very small number of non-critical individual systems, services, or people Disrupts a very small number of network devices or segments Little risk of propagation and further disruption	Next business day	Technical support for affected device	Chief Information Security Officer Department Manager	No
N/A	"Not Applicable" - used for suspicious activities which upon investigation are determined not to be an IT security incident.

Internal Contact List   

The ITS Service Desk will maintain a list of all contacts within ITS. Access to this list may be accomplished by calling the 24/7 support line (773.508.4487) or internally at 84487. This list will contain off-hours contact information for all ITS functional areas, and will be maintained by the ITS Service Desk process owner.

The LISIRT will utilize the after-hours support list in the event additional resources need to be contacted. In addition to this list of ITS contacts, the after-hours support list will also contain contacts for:

• Office of the General Counsel
• University Marketing and Communications
• Human Resources
• Campus Safety
• Facilities Management

The list of individuals will include their name, email address, Loyola telephone number, and emergency contact number.

Testing and Policy Review   

 The LISIRT will test the procedures in this plan and review the entire plan every 12 months if no incidents occur.

 To satisfy PCI requirements, if in any calendar year, no incidents have occurred, the LISIRT lead will conduct a table top exercise to test the Incident Response Plan. This test will be treated as an incident and the appropriate groups will be activated. The LISIRT lead will ensure that this plan is maintained in accordance with the Information Security Policy.

Incident Handling   

Summary

 This document provides an overview of the procedure for incident handling at Loyola.

Procedure

 Whenever an incident is detected, the following steps will be taken:

1. Identify affected resources:

The LISIRT will work to identify the scope of the incident. In this case, the scope involves evaluating the event, or events, identifying what resources might be affected, how many resources are affected, if any services are unavailable as a result of the incident, if any sensitive information might have been accessed and similar information that will be collected and analyzed. As the investigation progresses, the scope may be modified as appropriate. 

2. Begin documentation of the incident:

The LISIRT assigns each incident a unique incident number. Incident numbers are generated by combining the four digits of the current fiscal year with a four digit counter. So the first incident of 2008 would be 20080001, the next would be 20080002, etc. All steps taken by the LISIRT from this point forward will be documented. After the incident has been resolved, all of the available documentation will be collected for a final report (step #10). 

Documentation includes a brief description of any actions taken, along with the time that action was taken. This is especially important if the actions are being taken on a resource which may be compromised. 

3. Assess incident:

An assessment of the impact of the incident will be done. This impact will be brought to the attention of the ITS Leadership Team and the CIO. 

4. Assign responsible LISIRT members:

Based on the affected resources and the impact, ITS members with the appropriate knowledge will be assigned to the incident to aid the LISIRT team. 

5. Contain the incident:

If specific steps are available to contain the incident, the LISIRT will consider the consequences of those actions. If the benefits outweigh the costs, the containment steps will be performed. LISIRT has the authority to take necessary actions to mediate the issue without first discussing it with affected constituents. 

6. Collect evidence:

The LISIRT will collect evidence of how the incident occurred on the affected resources. Any digital evidence, such as log files and suspicious files, will be preserved by the LISIRT. Each piece of evidence will be assigned an evidence number consisting of the case number plus a four-digit counter. So the first piece of evidence in the first case of 2008 would be 200800010001, the second piece would be 200800010002, etc. All collected digital evidence will be documented. This information will be logged in the security metrics spreadsheet. 

7. Determine vulnerability:

The LISIRT will work to determine how the incident occurred. If a vulnerability is found on the resource, the LISIRT will determine if a patch or workaround is available. 

8. Determine malicious actions taken:

The LISIRT will work to determine what malicious actions may have been performed on the resource. Determining what actions might have been taken will influence the recommended recovery steps. Depending on the incident, forensic analysis may be required to determine what actions were taken on the resource. 

9. Provide recovery steps / Take recovery actions:

LISIRT is empowered to take the necessary steps to secure the resource and bring it back online. The resource will not be allowed back onto the network until it has been secured. Depending on the extent of the compromise, it may be necessary to restore the resource from tape backup, or to rebuild the resource from scratch. 

10. Create final report:

The LISIRT lead will create a report detailing the incident and all steps taken. All reports will be available within 3 business days after the completion of item #9. Reports will be provided to the ITS Leadership Team and the CIO. 

11. Archive evidence and report:

The LISIRT will archive all evidence obtained during the course of the investigation, along with a copy of the final report. Digital evidence will be stored on removable media. If the digital evidence does not have a built-in hash, an MD5 hash of the file will be created and stored as a text file with the evidence. All evidence will be stored in the LISIRT evidence locker. 

12. Process improvement:

The LISIRT will work to ensure that the same vulnerability is not present on other Loyola systems. The LISIRT will also work to identify any elements of the Incident Handling process that require improvement.

 

Training

Incident response plans require practice and training in order to be effective. Annually, Loyola University Chicago will run simulated breaches and responses for various scenarios that will allow the organization to fine tune its incident response plan, improving readiness for when real incidents occur.

How to Report an Incident

All suspected high severity events as defined in the Incident Severity section (above), including those involving possible breaches of personal identity information, must be reported directly to the University Chief Information Security Officer (CISO) as quickly as possible by phone (preferred), e-mail, or in person. If the ISO cannot be reached, contact the Chief Information Officer (CIO).

All other suspected incidents must also be reported to the CISO. These incidents may be first reported to departmental IT support personnel, the unit's Security Incident Response Team (SIRT) representative, or the unit head who can then contact the CISO. Reports should be made by sending email to datasecurity@luc.edu (preferred) or by notifying the CISO by phone, email, or in person.

For detailed information about reporting IT security incidents, see the Loyola University Chicago – Incident Response Plan Appendix. 

Definitions  

Electronic resources -All computing, networking, telephony and information resources procured through, operated or contracted by the University. Such resources include computing and networking systems including those that connect to the University telecommunications infrastructure, other computer hardware, software, data bases, support personnel and services, physical facilities, and communications systems and services.

Event – Any event that can be logged from any server, network device, or security device that contains suspicious activity. Examples of an event include the replacement of a system-level file, or the notification of a virus on a workstation. Events may or may not be malicious and must be evaluated to determine their impact.

(Security) Incident – An event, or combination of events, that alerts on real or risky activities that compromise the confidentiality, integrity and availability of information resources. Examples of incidents could include:

• attempts (failed or successful) to gain unauthorized access to a system or it’s data
• unwanted disruption or denial of service
• the unauthorized use of a system for the processing or storage of data
• changes to system hardware, firmware, or software characteristics without the owner’s knowledge, instruction or consent
• violations of the information security policy and University usage policies

Security Breach – Any successful unauthorized access to a Loyola University Chicago computer or system or network.

LISIRT – An Information Security Department team that receives, triages, resolves, assigns and tracks incidents of technology abuse or security breaches for all Loyola University Chicago campuses. This staff coordinates with various University offices as well as with external resources (Internet Service Providers, law enforcement, etc.).

LISIRT Lead – The University Information Security Officer (CISO) or their designee.

Server – A software program, or the computer on which the program runs, that provides service to client software running on the same computer or other computers on the network.

Workstation – Any personal computer or laptop.

Malware – Any type of malicious code, such as viruses, worms, trojans, bots, spyware.

References  

For details on specific Incident Response Procedures, please see the ITS Incident Response Plan Appendix.

Other Documents Referenced:

Data Breach Response Policy

LISIRT Contact List

Ransomware Decision Tree

HISTORY

September 30, 2008: v 1.0, Initial Policy

September 19, 2012: v 1.1, Added PCI Compliance information

June 24, 2015: v 1.1, Annual Review for PCI Compliance

July 23, 2015: v 1.2, Added Training Section

April 19, 2016: v 1.2, Annual Review for PCI Compliance

April 21, 2017: v 1.3, Added HIPAA Section

May 17, 2017: v 1.3, Annual Review for PCI Compliance

June 1, 2017: v 1.4, Added specialized section for PCI Incidents

June 14, 2017: v 1.5, Modified section for PCI Incidents

August 11, 2017: v 1.6 Added section for GDPR Incidents

September 17, 2018: v 1.7 Modifications to reflect organizational changes within ITS

August 27, 2019: v1.7 Annual Review for PCI Compliance

August 9, 2020: v1.7 Annual Review for PCI Compliance

August 14, 2023 v1.8 Modifications to reflect organizational changes within ITS, URL changes, and PCI compliance

Author: UISO

Version: 1.8 

LOYOLA UNIVERSITY CHICAGO
Information Technology Services
1032 W. Sheridan Ave. · Chicago, IL 60660 · 773.508-4487
datasecurity@luc.edu