OVERVIEW

The Lake Havasu City Information Technology Division is responsible for responding to reports of incidents, compromises, and breaches of City computers, data, and network resources. The purpose of the Incident Response Plan is to establish procedures in accordance with applicable legal and regulatory requirements to address instances of unauthorized access to or disclosure of City information. The Incident Response Plan defines the policy, roles and responsibilities for the involved personnel when reacting to an information security threat.

The primary emphasis of activities described within this plan is the return to a secure state as quickly as possible, while minimizing the adverse impact to the City. Depending on the circumstances, the Information Technology Security Administrator (ITSA) may decide to modify or bypass one or more of the procedures outlined in this plan in response to a particular security incident, with the understanding that the ITSA will take all reasonable steps to investigate and resolve any security issues. The capture and preservation of incident relevant data (e.g., network flows, data on drives, access logs, etc.) is performed primarily for the purpose of problem determination and resolution, as well as classification of the incident.

The City shall provide timely and appropriate notice to affected individuals and departments when there has been a security incident, a compromise, or a breach involving city data, computers, or networks. The ITSA, IT Manager, Administrative Services Director, and the City Manager shall be responsible for reviewing breaches to determine whether notification is required, and directing responsible departments in complying with the notification obligation. All known or suspected security incidents must be reported to the ITSA. Suspected incidents should be reported to the administrator or through the Lake Havasu City Helpdesk system.

DEFINITIONS

Information Technology Security Administrator (ITSA) –  A position within the IT Division that is appointed by the IT Manager.

Security Incident - A vulnerability which may compromise the security of city resources has been discovered and is underway. Generally, this means a weakness in intrusion prevention has been found, an attempted exploit has taken place, or reconnaissance by a hacker has been thwarted. Examples include systematic unsuccessful attempts to gain entry, a PC or workstation infected with a virus, worm, Trojan, botnet, or other malware that has been discovered and removed.

Security Compromise – An escalation of a security incident where the attacker has gained control of a city account, system, or device, and is leveraging that position to control and utilize compromised resources for the purpose of unauthorized acquisitions. At this point, it has been determined that data has not been compromised or stolen.

Security Breach – A confirmed, unauthorized acquisition, modification or destruction of city or private data has taken place. At this point, a breach has been forensically determined and evidence supports that data was compromised.

Private data - Data about individuals that is classified by law as private or confidential and is maintained by the city in electronic format or medium. “Private data” means data classified as not public and available to the subject of the data, and "confidential data" means data classified as not public but not available to the subject of the data.

Unauthorized acquisition - For the purposes of this plan, this means that a person has obtained city data without statutory authority or the consent of the individual who is the subject of the data, and with the intent to use the data for non-city purposes

Systematic unsuccessful attempts - continual probes, scans, or login attempts where the perpetrators obvious intent is to discover a vulnerability and inappropriately access and compromise that device.

Lake Havasu City Resources or Systems includes all city-owned computers, peripherals, networks, and related equipment and software, and the voice and data communications infrastructure.

GENERAL INCIDENT RESPONSE PROCEDURES

1. Intrusion attempts, security breaches, or other technical security incidents perpetrated against city-owned computing or networked resources must be reported to the ITSA. Functional department managers and/or supervisory personnel must:
   1. Report any security incidents in order to obtain assistance, advice, or to file the incident.
   2. Report any systematic unsuccessful attempts (e.g., login attempts, probes, or scans).
   3. Where feasible given the circumstances, reports should be sent as soon as the situation is detected; minimally the report should be sent as soon as possible thereafter.
2. Upon receiving a report of a security incident, the ITSA will:
   1. Ensure that appropriate information is collected and logged per applicable procedures.
   2. Immediately assess actual or potential disclosure or inappropriate access to institutional or personal information.
   3. Report the situation to the IT Manager and the Administrative Services Director and City Manager.
   4. Consult with and/or assign the incident to other personnel for further investigation as necessary.
   5. Provide preliminary advice or comment to the department as required.
   6. Initiate steps to warn other Lake Havasu City systems personnel if it appears that the situation has the potential to affect other City systems as well.
   7. Perform or assist in any subsequent investigation and/or perform computer forensics as required.
   8. If circumstances dictate, report and/or consult with City Attorney, City Police Department, Internal Auditors, City Manager, and/or other appropriate agencies.
   9. Ensure that appropriate records are filed.
   10. Confirm actual or probable disclosure or inappropriate access to institutional or personal information.
   11. Invoke formal incident response procedures commensurate with the situation.
3. In order to protect City data and systems, as well as to protect threatened systems external to the City, the ITSA may block, or place restrictions on technology services provided using any City-owned systems and networks. Specifically:
   1. Limitations may be implemented through the use of policies, standards, and/or technical methods, and could include (but may not be limited to) usage eligibility rules, password requirements, or restricting or blocking certain protocols or use of certain applications known to cause security problems.
   2. Restrictions may be permanently deployed based on a continuing threat or risk after appropriate consultation with affected constituents, or they may be temporarily deployed, without prior coordination, in response to an immediate and serious threat.
   3. Restrictions deployed temporarily will be removed when the risk is mitigated to an acceptable level, or where the effect on city functions caused by the restriction approaches or exceeds risk associated with the threat, as negotiated between the affected departments and the ITSA.
4. In order to protect City data and systems, as well as to protect threatened systems external to the City, the ITSA may unilaterally choose to isolate a specific City system from other City or external networks, given:
   1. Information in-hand reasonably points to the system as having been compromised.
   2. There is ongoing activity associated with the system that is causing or will cause damage to other City systems and/or data, or the assets of other internal or external agencies, or where there is a medium-to-high risk of such damage occurring.
   3. All reasonable attempts have been made to contact the responsible systems personnel or department management, or such contact has been made where the technician or department managers are unable to (or choose not to) resolve the problem in a reasonable time.
   4. Isolation is removed when the risk is mitigated to an acceptable level, or where loss of access or function caused by the isolation approaches or exceeds risk associated with the threat, as negotiated between the responsible department manager and the ITSA.
   5. Advance consultation with the appropriate security contractor, or City Attorney, where practical and where circumstances warrant.
5. The reaction to a reported security vulnerability directly corresponds to the potential for damage to the local system (or adjacent systems) or inappropriate disclosure or modification of data. The risk levels are characterized as:
   1. Very High Risk, response is immediate:
      1. Damage to the system or data is occurring, or
      2. Attempts to exploit the vulnerability on that system are occurring, or
      3. The vulnerability is currently being actively exploited against other similar technologies within the City; probable damage to systems and data is being experienced in those other incidents.
   2. High Risk, response is within 1 hour:
      1. The vulnerability is known to exist on the system;
      2. The exposure is currently being actively exploited against other similar technologies external to the City;
      3. Damage to systems and data are being experienced in those other incidents.
   3. Medium Risk, response should be within 4 hours:
      1. The system is susceptible to the vulnerability given that the system is configured incorrectly;
      2. The exposure is currently being actively exploited against other similar technologies external to the City;
      3. There is some potential for damage to systems and data.
   4. Low Risk, response should be within 8 hours:
      1. The system is susceptible to the vulnerability given that the system is configured incorrectly;
      2. The exposure is currently being actively exploited against other similar technologies external to the City;
      3. Damage to systems and data is possible but is not considered likely.
6. In the event of a significant series of incidents, a compromise, or a breach, the entire episode and response are reviewed to determine which parts of the incident response plan worked correctly. The “lessons learned” will be part of an After Action Review process to determine areas that need to be changed (policies, system configurations, etc.).