Technology Services

Information Security Management
Incident Handling

Incident Response Plan and Procedures

As part of a comprehensive security program for the State, the Information Security Management Office (ISMO) in the Information Technology Services Division is implementing an Incident Response Plan and Procedures. It is imperative that the State's IT community is aware of information security threats and concerns to minimize the damage from security incidents and malfunctions and to monitor and learn from them.

The term "incident" refers to an adverse event, or threat of an adverse event, in a computer system and/or network.

1. Types of incidents and when to report.

What type of incident must I report?

• Successful attempts to gain unauthorized access to systems or data;
• Unwanted disruption or denial of service;
• The unauthorized use/access of a system for the transmission, processing or storage of data;
• Changes to system hardware, firmware, and/or usage of software characteristics without the owner's knowledge, instruction or consent.
• Discovery of malicious code to include worms, viruses, Trojans, or web defacement, etc.
• Any breach of the computing environment that has the potential to spread outside of the agency's immediate control.

At the discretion of the agency CIO/IT Director, impacts to the computing environment that are contained within the agency's system and will not have an adverse impact on other agencies are not required to be reported. (i.e....pings/scans)

When should I report an incident?

Report any incident immediately that meets the above definition and criteria or is suspicious in nature. We encourage primary or secondary contacts for ITAB member agencies to report all suspicious activity, even if the incident is quite old at the time of reporting. Incident reports that are sent shortly after the incident occurred are the most likely to be of value. This does not imply that an incident report becomes useless after some period of time. Remember a report not only is the first step in recovery but it also helps raise awareness and contributes to the overall information security posture of the enterprise.

2. How to report and what should be included

• How to report an incident?
  Primary or secondary contacts for ITAB member agencies report and/or route incidents to the Technology Services help desk.
• What should I include in the incident report?
  When reporting an incident, it is important to ensure that you provide enough information for our Information Security Management Office (ISMO) staff to be able to understand and respond efficiently and effectively.
• Please supply the following:

• Contact information (who to contact for followup information)
• Location information (where is the problem taking place)
• Host/networks involved (how many systems/networks are affected)
• Attack description (what is/has happened)
• Impact (SEV1, SEV2, SEV3) (if applicable)

Severity levels:

o SEV1 = network/system totally down,
o SEV2 = network/system is 50% viable,
o SEV3 = spot outages

• For the development of preventative measures and reporting of the incident to the appropriate enforcement organizations a detailed report of the incident will be developed.

3. What will the Helpdesk do?

Technology Services help desk will take reported incidents from the "Contact Information for Virus/Security Incident Coordination" list. Only those reports verified by those listed as contacts will be considered as valid. Additionally, the help desk will log the incident report, assign a ticket number (as per the TS Customer Procedures Manual) and will immediately forward the report to ISMO staff for handling.

4. ISMO staff notifies appropriate agencies

The process begins with ISMO staff recording an "alert" message into a special voice mailbox, which is the security services incident reporting mailbox. ISMO staff will then instruct the Technology Services helpdesk to activate the incident notification procedure. ISMO staff will then send a message to the voice mailboxes of the ITAB member agency primary and secondary contacts.

Note: This system automatically calls each ITAB member agency primary and secondary contacts.

The message will be marked "return receipt" so the system can automatically notify ISMO staff which contacts have not played the message. The voice message will also be marked "urgent" so that it will be the first message in each mailbox.
The second step in the process will prompt the called party to contact their state voice mailbox or call the incident reporting mailbox. If the system calls a pager it leaves an alpha-numeric message to call voice mail for details. If the system calls a third party or an answering machine a message will be played instructing the ITAB member agency primary and secondary contacts to call voice mail. If the primary or secondary contact answers the call the system will prompt the contact to verify message receipt by pressing a special code on the dialpad. In case of a busy signal or no answer the system will repeat the notification process.
ISMO staff will continue to monitor the problem and update the voicemail message and distribute the updates to the ITAB member agency primary and secondary contact mailboxes as the status changes. This process will essentially create an event log with time and date stamped voice message status reports.

The notification process will conclude with an end of alert message.

5. ISMO staff performs an initial incident analysis
The initial incident analysis will include:

Collecting evidence

• impact statements from affected customers, including descriptions of the "threat" manifestations and other network or system behaviors.
• incident and activity logs, application and system logs,
• isolated examples of the virus(es) or worm(s),
• anecdotal information.

Develop timelines

• Establish incident timeline. Identify each significant event or behavior associated with the incident from the report and place on the timeline. Pick the earliest date known of the incident to establish emergence. This does not necessarily establish the Incident Reporting date as the genesis. An anecdotal report of a date preceding the incident does not preempt the Incident Report date, but adds to the body of knowledge.
• Establish common thread and modes of behaviors from examining the time line and other reports derived from empirical query of the Incident Reporting database.

Evaluate impact from customers.

• Percent of system/network outage (estimated) and assigned severity levels of 1,2,3.
• Evaluate and or determine threat entry point to systems affected and list vulnerabilities.
• Perform computer and network forensics, including information distilled from the evidence, the assessment of remedies, dissemination of those remedies, and preventive measures
• Transmit a notification to the affected customers immediately, if the vulnerabilities are clearly fatal to the continued operations of the affected customers or puts the entire State of Missouri Enterprise at risk.

NOTE: Customer should add any new vulnerabilities discovered during this time to the list.

6. Assess remedies and disseminate

Upon the initial notification of the incident to the ISMO staff, empirical data will be used to assist in identifying the threat, its severity and bring remedy. In cases involving viruses and worms, anti-virus vendor services will be employed to provide threat eradication.

ISMO staff will provide a list of effects of the threat eradication.

7. Develop preventative measures

ISMO staff will continue to develop preventive measures by further assessment of incident analysis data using a post-mortem protocol with a list of questions designed to populate an online survey instrument. Once the results are summarized, a preventive plan is created and posted on a web site/page for the customer. A preventive plan will include, listing of training and education, how to bring about elimination of the vulnerabilities, etc.