Information Security Standards (ISS) are developed to support and enforce both District Administrative Regulations and the California Community College Information Security Standard.

Summary

As an integral part of an organization’s incident response program, an incident response plan documents the roles, responsibilities, and communication strategies to address issues like service outages, cyber incidents, and data loss.

1. Purpose and Scope
2. Security Incident Response
3. Incident Response Process
4. Glossary

1.0 Purpose and Scope

The purpose of the Security Incident Response Standard is to provide requirements and procedural steps that will enable a quick and effective recovery from unplanned LONG BEACH COMMUNITY COLLEGE DISTRICT (LBCCD) security incidents.

This is one of a series of Information Security Standards maintained by the District Information Technology (IT) department designed to protect LBCCD information systems.

This Standard contains:

• Requirements for responding to information security incidents or breaches
• Roles and responsibilities
• Basic procedures needed to respond in a systematic manner

District IT Departmental Procedures exist which contain:

• Security Incident Reporting Procedure
• Contact information
• Preservation of Evidence
• Breaches of Confidential or Personal Information
• Additional Resources

The primary audience for this Standard is the Computer Incident Response Team (CIRT), system and network administrators, and those in District and campus or business areas who have been designated to participate in the incident response team.

This Standard is approved by the LBCCD Executive Cabinet, and by their approval, members of the Incident Response Team have full authority to act according to the IR plan to swiftly protect our systems and data.

The principal objective of Incident Response is to identify an incident, evaluate its severity and impact, and quickly and effectively as possible formulate and execute a response to an unforeseen incident, disaster, or emergency that may place sensitive information at risk or interrupt information systems and business operations. Additional objectives include the following:

1. The need to ensure that all employees fully understand their duties in implementing such a plan
2. The need to ensure that operational policies are adhered to within all planned activities
3. The need to ensure that proposed contingency arrangements are cost-effective
4. The need to consider implications on other Departments
5. Disaster recovery capabilities as applicable to Classified Staff, Faculty, Student population, and other affected groups.

When an incident occurs the Emergency Response Team (ERT) may be activated. The ERT will then decide the extent to which the DRP must be invoked.

1. Respond immediately to a potential disaster and call emergency services;
2. Assess the extent of the disaster and its impact on the business, data center, etc.;
3. Decide which elements of the DR Plan should be activated;
4. Establish and manage a disaster recovery team to maintain vital services and return to normal operation;
5. Ensure employees are notified and allocate responsibilities and activities as required.

Should the incident escalate to a declared disaster, the team will be contacted and assembled by the ERT. The team’s responsibilities include:

1. Establish facilities for an emergency level of service within 2.0 business hours;
2. Restore key services within 4.0 business hours of the incident;
3. Recover to business as usual within 8.0 to 24.0 hours after the incident;
4. Coordinate activities with disaster recovery team, first responders, etc.
5. Report to the emergency response team

Depending on the particulars of the incident, steps noted here may be supplemented by additional LBCCD procedures, such as those that exist in other documentation, business continuity plans, operational procedures, technical standards, or other processes and procedures fitting the circumstances of the incident.

1.1 Applicability to all Employees and Volunteers

In accordance with Administration Regulation 3720: Computer and Network Use, this Standard applies to all District students, faculty, staff, and all others granted use of District information resources (users).

1.2 References and Related Documents

Please refer to the following Administrative Regulations and Standards for additional information and references including definitions:

• AR 3720: Computer and Network Acceptable Use
• District IT Information Security Policies, Regulations, and Standards

2.0 Security Incident Response

Incident response is an expedited reaction to an issue or occurrence either electronic or physical. Those responding must react quickly, minimize damage, minimize service interruptions, and restore resources, all the while attempting to guarantee data integrity, and preserve evidence.

2.1 Incident Response Standard

Unplanned security events must be reported to the appropriate operational manager and the District-wide IT Service Desk as quickly as possible. A consistent approach to security incident response can minimize the extent and severity of security exposures.

Security incidents that are categorized as medium or high must be documented. Where appropriate, security incidents will be reviewed with local campus IT management. The Security Incident Reporting Procedure is used for this purpose.

The process for handling security incidents has the following phases:

Immediate actions

• Investigation
• Resolution
• Recovery and Reporting

The recommended actions for each phase are described in Section 3.

Any directives issued by a member of the CIRT during a response may supersede this document.

2.2. Maintenance

This Security Incident Response Standard will be reviewed and updated on a bi-annual basis, at a minimum, or as relevant personnel, locations, threats, or regulatory/contractual requirements change.

The Incident Response plan and procedures should be tested at least annually.

2.3 Roles and Responsibilities

This section defines roles and teams involved in the Incident Response process. The procedures and processes these teams may follow are in Section 3 of this document.

2.3.1 Incident Response Coordinator

All security incidents must be reported to District IT through the District-wide IT Help Desk. Where appropriate, District Management will determine who will be the overall Incident Response Coordinator (IRC). The IRC will maintain this Security Incident Response Standard and Incident Reports and records, and also coordinate tests and any required training.

2.3.2 Computer Incident Response Team (CIRT)

The Computer Incident Response Team (CIRT) will be responsible for handling the overall LBCCD response effort. CIRT members represent the IT, Legal, HR, and campus organizations. CIRT members who are LBCCD managers may assign others to work on specific tasks of the incident response process.

Not all members of the CIRT will be involved in any given incident. All CIRT members must be willing to accept the responsibility that is required of them and to be able to respond to an emergency at any hour.

2.3.3 Business Response Teams

Business Response Teams may be involved in the incident response process when an incident occurs in an LBCCD business area. Both primary and secondary contacts have been designated for each business area.

2.3.4 Users

Despite the existence of system and audit logs, computer and network users may be the first to discover a security event or possible breach. As noted in AR 3720: Computer and Network Use, end-users need to be vigilant for signs of unusual system or application behavior that may indicate a security incident in progress.

All LBCCD users are responsible for reporting incidents they detect, which may include virus or malware infections, a system compromise, or other suspected security incidents. Incidents must be reported to the District IT Service Desk.

2.3.5 Managers

In accordance with AR 3720: Computer and Network Use, LBCCD managers and users must ensure that employees are aware of their monitoring and reporting responsibilities. They are also responsible for reporting all suspected information security incidents to the District IT Service Desk as soon as possible.

2.4 Contact Information

Refer to District IT departmental procedures for designated personnel and contact information for the IRC, CIRT, and Business Response Teams.

3.0 Incident Response Process

The following section describes the procedures that are common to all types of security incidents and the recommended steps for each phase of a security incident. Please refer to Section 3.3.2 for specific security incident types.

3.1 Documentation and Preservation of Evidence

Evidence of a computer security incident may be required for civil or criminal prosecution or to document the event for insurance reasons. To preserve evidence, all relevant information collected during the incident must be protected. To maintain the usefulness of possible evidence, LBCCD staff must be able to identify each note or piece of evidence and be prepared to explain

The chain of custody for all evidence must be preserved. Documentation will be required that indicates the date, time, storage location, and sequence of individuals who handled the evidence. There must not be any lapses in time or date. The hand-off of evidence to authorities must also be documented.

3.2 Control of Information

The control of information during a security incident or investigation of a suspected security incident or breach is critical. If people are given incorrect information, or unauthorized persons are given access to information, there can be undesirable side effects, for example, if the news media is involved. See the communication plan above or turn this section into the communication plan with media and outside agencies.

No LBCCD staff member, except the Chief Information Officer (CIO) or their designate(s), has the authority to discuss any security incident with any person outside of the District. If there is evidence of criminal activity, The CIO or designate will notify law enforcement and request their assistance in the matter.

The IRC is the main point of contact for all communications (internal or external) to reduce the spread of misinformation, rumors, and compromise of the response. All CIRT members should refer requests for information to the IRC, who will work with the Vice-Chancellor and the Public Information Officer (PIO) regarding any communications.

If a hacking incident were to occur, a secure communications mechanism may need to be implemented since the attacker may be monitoring network traffic. All parties must agree on what technology to use to exchange messages. Even the act of two people communicating could indicate to an intruder that they have been detected. Greater care needs to be exercised when an internal person is suspected or could be an accomplice to the compromise.

Incident-specific information is not to be provided to any callers claiming to be involved. This includes but is not limited to systems or accounts involved, programs, or system names. All requests for information should be documented and forwarded to the Incident Response Coordinator (IRC). Members of the CIRT, working with the IRC, will handle any questions regarding the release of any information pertaining to a security incident. Communication may be from the IRC, a member of the CIRT, or through voicemail or IT bulletins.

If a breach involving personally identifiable or cardholder/credit card information has potentially occurred: The relevant Business Response teams must work with the IT and Legal to determine the specific procedures that should be followed and the nature of notification processes.

The CIO or their designate(s) will be the only persons who may authorize contacting external law enforcement agencies should this be necessary.

3.3 Security Incident Categories

Security incidents at LBCCD fall into one of the following four categories:

Incident Category	Description	Examples
Internal	Any user (authorized or unauthorized) misusing resources, violating the Acceptable Use Administrative Regulation, or attempting to gain unauthorized access	Unauthorized use of another’s account Authorized user misusing privileges Intentionally modifying production data Inappropriate use of College and District computing resources.
External	Unauthorized persons attempting to gain access to systems or cause a disruption of service	Denial of service attacks Mail spamming Malicious code Hacking / cracking attempts
Technical Vulnerabilities	A weakness in information system hardware, operating systems, applications, or security controls	Compromised passwords Data that should be protected appears to be available Data integrity issues
Loss or theft	Loss or theft of LBCCD-owned hardware, software; loss or theft of Restricted information.	Lost laptop Lost smartphone Lost device or documents containing confidential LBCCD data Airport authority confiscation of LBCCD hardware or software Theft of LBCCD hardware or other materials Breach of student data

3.4 Security Incident Severity Levels

An incident could be any one of the items noted in the “Description” column and be classified as having a severity level, with corresponding actions to be taken to begin an investigation of the incident.

Incident Severity Level	Description	Action Required
SEVERE/ URGENT	Successful hacking or denial of service attack Confirmed breach of personally identifiable (PI) information Significant operations impact Significant risk of negative financial or public relations impact PII, as defined by the Data Classification Standard.	Activate CIRT team and notify the IRC. Notify all necessary management team members If a breach of PII or regulated information is suspected contact cyber-insurance/ breach attorney
HIGH	Hacking or denial of service attack attempted with limited impact on operations Widespread instances of a new computer virus not handled by anti-virus software Possible breach of student information or PI Some risk of negative financial or public relations impact	Notify Incident Response Coordinator, who will notify CIRT team members as necessary. If a breach of Confidential information is suspected Notify external organization
MEDIUM	Hacking or denial of service attacks attempted with no impact on operations Widespread computer viruses easily handled by anti-virus software Lost laptop/smartphone, but no data compromised	Notify Incident Response Coordinator, who will notify CIRT team members if necessary.
LOW	Password compromises – single user Unauthorized access attempts Account sharing Account lockouts	Notify Incident Response Coordinator.

3.5 Security Incident Phases

The process for handling all LBCCD security incidents has four general phases:

1. Immediate actions
2. Containment
3. Investigation
4. Resolution
5. Recovery and Reporting

3.5.1 Immediate Actions

The first actions to be taken are to make an initial identification of the category of incident occurring (Internal, External, Technical Vulnerabilities, Loss or Theft) as described in the table above and notify the District IT Service Desk.

AR 3720: Computer and Network Use, directs users to notify District IT immediately upon identifying a security incident of any type. As a rule, users should also notify their immediate manager to inform them of the incident. District IT will then notify the appropriate response teams to begin the investigation and resolution phases.

Response to an incident must be decisive and be executed quickly. Reacting quickly will minimize the impact of resource unavailability and the potential damage caused by system compromise or a data breach.

3.5.2 Investigation

Once reported to the District-wide IT Service Desk, a determination will be made as to the Severity Level (Severe / Urgent, High, Medium, or Low) of the incident based on initial reports.

The CIO or their designate (designate may include college management) has the authority to declare a Severity level incident and activate the CIRT.

Upon declaration of a security incident, the following actions may also occur depending on the severity and nature of the incident:

• Notification of executive management team members/ campus Security
• Notification of District IT Management and/or campus IT Management.
• Notification of any outside service providers
• Notification of Business Response Teams impacted by the security event
• Initiation of a public relations response plan or development of emergency communications
• Notification of business partners and others who may be impacted by the security event
• Implementation of incident response actions for the containment and resolution of the situation needed to return to normal operations

3.5.3 Resolution

LBCCD’s immediate objective after an incident has been reported and a preliminary investigation has occurred is to limit its scope and magnitude as quickly as possible.

3.5.4 Recovery and Reporting

After containing the damage and performing initial resolution steps, the next priority is to begin recovery steps and make necessary changes to remove the cause of the incident. Reports and evidence must also be organized and retained.

Per the State of California Department of Justice, Data Security Breach Reporting requirement:

California law requires a business or state agency to notify any California resident whose unencrypted personal information, as defined, was acquired, or reasonably believed to have been acquired, by an unauthorized person. (California Civil Code s. 1798.29(a) [agency] and California Civ. Code s. 1798.82(a) [person or business].)

Any person or business that is required to issue a security breach notification to more than 500 California residents as a result of a single breach of the security system shall electronically submit a single sample copy of that security breach notification, excluding any personally identifiable information, to the Attorney General. (California Civil Code s. 1798.29(e) [agency] and California Civ. Code s. 1798.82(f) [person or business].)

3.5.5 Post-Incident Activity

A process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments will be managed by District IT.

3.6 Incident Response Contact Matrix

The following table describes common incidents and the primary reporting contact for each. The primary contact will be responsible for assigning an IRC.

Category	User Group	Primary Conact
Internal, External, Loss, or Theft	Students	Vice President of Student Services
Technical Vulnerability	Students	Vice President Student Services, CIO
Internal, External, Loss, or Theft	Faculty	Vice President of Instruction
Technical Vulnerability	Faculty	Vice President of Instruction, CIO
Internal, External, Loss, or Theft	Staff	Vice President of Human Resources
Technical Vulnerability	Staff	Vice President of Human Resources, CIO

4.0 Glossary / Definitions

Business Response Teams	Business Response Teams can be activated to enhance LBCCD’s response to incidents that affect specific business areas. These teams have established designated contacts for handling incidents or security breaches and enhanced collaboration between diverse groups.
Computer Incident Response Team (CIRT)	The CIRT will act as the core incident coordination team for severe security incidents or breaches and is represented by individuals from District IT, campus IT, and business areas.
Incident Response Coordinator (IRC)	The IRC serves as the primary point of contact for response activities and maintains records of all incidents. This individual has overall responsibility and ownership of the Incident Response process.
Security Breach	Unauthorized release or exposure of information that is confidential, sensitive, or personally identifiable. The definition of a breach and the actions that must be taken can vary based on regulatory or contractual requirements.
Security Incident	A security incident is any adverse event that compromises the confidentiality, availability, or integrity of information. A security incident that is classified as medium or critical may be noticed or recorded on any system and or network controlled by LBCCD or by a service provider acting on behalf of LBCCD.
Security Violation	An act that bypasses or contravenes LBCCD security Administrative Regulations, practices, or procedures. A security violation may result in a security incident or breach.