How an organization responds regarding a security or privacy breach tells me a lot about their level of preparedness.
The first thing that an organization needs to understand is exactly what constitutes an incident, what incidents are reportable and what actions they 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 (HIPAA, SOX, GLBA)
Those that violate organizational policy and regulations.
Security incidents may reveal the need for increased computer security efforts, possibly including a security 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.
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.
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.
There you have it. The premise behind developing a sound and workable incident response mechanism, is to think it through before it is needed. This is one aspect of information security that cannot be reactive.
Got something to add? Send me email.
More Articles by Michael Desrosiers © 2012-07-07 Michael Desrosiers