How to respond to a Security Incident
By Michael Desrosiers
Web Site: http://m3ipinc.com
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
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.
Increase ad revenue 50-250% with Ezoic
More Articles by Michael Desrosiers
© 2012-07-07 Michael Desrosiers