When
As needed.
Why
You need to understand what constitutes an incident, what incidents are reportable and what actions you need to take when an incident occurs. The purpose of an incident response plan is to respond, investigate and report any abnormal activities that deviate from approved or expected practices on your organization's information system resources. Your plan should include a description of a security violation, a security incident and an example of when a technical vulnerability causes or could cause one or the other.
There are two types of security violations: those that violate one or more laws of an authority (like the DoD or FTC) and those that violate any local organizational policy and regulations, as applicable.
Security incidents may reveal the need for increased computer security efforts, possibly including a security education, training and awareness program.
Technical vulnerabilities can be found in hardware, firmware or software and can be caused by design or implementation characteristics or flaws that leave an information system open to potential exploitation.
Should you shut down the system, alerting the potential hacker, or should you try to gain more information about the attacker for prosecution or study? Your decision will depend on what sort of activity has already been discovered and what the likelihood is of loss of life or market edge. Timely reporting is paramount and should be consistent with the incident's severity; efficient incident handling also minimizes the potential for negative public relations exposure.
When an attack is in progress, spontaneous decisions can thwart efforts to determine the source of the incident, collect evidence, prepare for recovering the system and protect system data. Be aware that if you report a potential crime, authorities may seize all of your equipment and remove it from your premises for an unknown amount of time.
Strategy
Your incident response plan will look similar to business continuity plans developed earlier:
- Preparation and planning: goals and objectives in handling an incident.
- Notification/point of contact in the case of an incident: local managers and personnel; law enforcement and investigative agencies; computer security incidents handling teams; affected and involved sites; internal communications; public relations; and customers, as applicable, if personal data was stolen.
- Identifying an incident and classifying its severity.
- Handling the incident: protection of evidence and activity logs; containment; eradication; recovery; and follow-up.
- Aftermath: What are the implications of past incidents?
- Administrative response to incidents.
An incident report should include the type, description and impact of the incident; date and time the incident occurred; name and classification of the information system; man-hours involved in recovery and cleanup; and a point of contact.
All reports are classified at the level of the system compromised, but at least "Confidential" on any system processing classified information.
More Information
Examples of good incident response forms can be found at cert.org and afcert.Kelly.af.mil (if you can access .mil URLs). RFC 2196: Site Security Handbook, Chapter 5, details the issues involved in the six-part plan listed above, and provides site policy guidance for handling incidents.
About the author
Shelley Bard, CISSP, CISM, is a senior security network engineer with
Verizon Federal Network Systems (FNS). An information security
professional for 17 years, Bard has briefed and written infosecurity
assessments and technical reports for the White House and Department
of Defense, special interest groups, industry and academia. Please
e-mail any comments to securityplanner@infosecuritymag.com.
Opinions expressed in this column are those of Shelley Bard and don't
necessarily reflect those of Verizon FNS.
