[BreachExchange] The Business Guide to Developing a Cyber Security Incident Response Plan

[Audrey McNeil]

http://www.aim.ph/blog/the-business-guide-to-developing-
a-cyber-security-incident-response-plan/

Remember the 1995 movie, The Net? In the scene post her stolen identity,
the protagonist, a computer programmer, says the most unthinkable thing,
“Our whole world is sitting there on a computer. It’s in the computer,
everything …  is stored in there. It’s like this little electronic shadow
on each and every one of us, just, just begging for someone to screw with.”

Outside the fictional realm, we’re actually seeing how technology, amid all
the IT services available, becomes a precursor of privacy concerns, data
breach, and other online security threats. And without a cyber-security
incident response plan (CSIRP) properly set up, organizations risk losing
tons of critical data.

 Implementing Your CSIRP

A CSIRP is a written plan that companies can use when dealing with
potential cyber threats. Since the CSIRP describes a number of possible
scenarios, the responding team’s actions become deliberate and uniform,
rather than random and inconsistent. Here are important pointers to
remember when building your cyber incident response plan.

 Response team

Incident responders are your hardworking and skilled team members who work
before, during, and after a cyber incident scenario—from developing the
CSIRP to launching investigations and doing cleanup to assessing the CSIRP
effectiveness as part of follow-up operations.

Who can save the day for you? A senior management rep, a systems, database
or network administrator, network engineer or programmer, security officer,
legal rep, and public affairs officer may be tapped as part of the response
team.

Third-party vendors, consultants, or specialists may also be brought in,
depending on service level agreements or on the company’s human resources.

 Reporting

As soon as your team has confirmed that there’s been an unusual activity in
your system, senior management needs to be notified right away. Then, just
as quickly, technical members of the team assemble at the scene to perform
their designated functions, as the rest of the team receive updates and
give directives to address issues under their scope.

At this point, documentation needs to be done. Below is a list of the
information to be included in the report:

Point-of-contact information: name, telephone, email address
Incident category: CAT 1-CAT 6
Incident date and time
Source IP, port, and protocol (if known or available)
Destination IP, port, and protocol (if known or available)
Location and component of the system/s involved in the incident
Method used to identify the incident: audit log analysis, intrusion
detection system, system administrator, end-user feedback)
Description of the incident

 Initial response

The nature of your response will have to be based on the incident category,
type, or level that you’re dealing with, but the bottom line is still to
contain the issue. Naturally, the initial response for security breach
caused by an insider threat would be different from social engineering.

For malware attack, for example, you can call in a forensics team to do
reverse-engineering tactics, provided that your team has previously created
a sandbox to hold the malware for observation and containment.

 Investigation

Here’s where all the dirty work comes in, trying to figure out what
actually happened to your system or network. Your forensics team can now
collect malware and logs onsite or remotely and try to discover hash, as
well as registry values as well as its effect on the entire systems and
infrastructure.

These, plus all other relevant data gathered from multiple sources (read:
bit-stream copies of drives; external storage; network, system, and
application logs), will be used to identify and deploy appropriate
remediation methods.

Recovery and follow-up

By this time, hopefully, after receiving some beating, your network is
ready to get a makeover and return to its normal state. Your disaster
recovery and follow-up plan can be divided into two phases: incident
recovery and post-incident recovery.

In incident recovery, you’ll be restoring your system and data, and then
validating if the system is completely operational.

Post-incident recovery basically involves retrospection, asking yourself
how to avoid the same misses in the future, making a record of all the
lessons learned, and enhancing the CSIRP with the improvements needed.
After all, nothing is perfect, right?

Public relations

Trust your spin doctors to take the necessary steps and address public
concerns through press releases or statements. The goal is to restore
confidence and loyalty among end-users all throughout the crisis.

 Law enforcement

In cases when criminal investigations are carried out, the designated team
member, usually the Chief Compliance Officer, the Chief Security Officer or
the Chief Information Officer, needs to consult law enforcement contacts to
discuss the whys and wherefores of incident reporting and collection of
evidence to help in the investigation and prosecution of cyber attackers.

The value of the CSIRP should never be underrated, serving as a cushion of
some sort against the ugly impact of a cyber security crisis. If your
organization still does not have a legit CSIRP, you better act now sooner
than later. Or at the very least, be sure to have some contingency in place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20161024/225db3c7/attachment.html>