Last year’s number of publicly reported data breaches in the U.S.
had already surpassed
2020’s count
by the end of September.
With at least 1,000 breaches annually,
are there still folks
who think there’s no chance they’re getting hacked?

We said in a previous post
that the optimism bias and overconfidence are tendencies
that influence the mentality
that an organization will not be subject to cyberattacks.
We recommended everyone adopt a healthy level of skepticism.
To sum up the idea,
there’s a saying you have probably heard time and again:
“It’s not a matter of if you get attacked, but when.”
And when it happens,
you better be prepared.

Preparation often comes in the form of an incident response plan.
It lays out
how the organization expects to manage threatening events.
As private businesses and some governmental entities
in the U.S.
are required by law
to notify about security breaches,
having a plan is a shared need.
We will review some of the incident response plan essentials on this blog post.

Some essentials for your incident response plan

It has been suggested
that one of the most crucial steps of incident response
is handling the situation in the first hour following its discovery.
Regardless of what you think would be
your immediate response to a security incident,
experts would agree
that panic and anxiety are usual responses in the environment,
which then becomes hectic.
It appears that it doesn’t even matter
how prepared everyone is on your team;
most people can’t help these reactions.
Granted
that you probably won’t be able to approach the incident with a cool head,
the most helpful asset will be your incident response plan.

The first thing is to define
a Computer Security Incident Response Team (CSIRT).
As has been described
in publications by NIST,
these teams usually consist of security analysts.
You will want to have the most capable people on it,
who will then have to speculate on the causes of the incident.
It has been recommended
that,
to respond efficiently during the first hour since discovery,
they “assume the most likely cause and act accordingly.”

The CSIRT’s work can be facilitated
if your organization has generated thorough threat models.
These are the product of examining the entire attack surface
and the possible attack vectors
to establish the necessary security measures.
Mind you,
these models should be up to date with trends
such as cloud security and remote working.
(By the way,
the latter had a substantial effect on last year’s cost of data breaches,
adding approximately $1M,
as well as the time of their discovery,
adding 58 days.)

Someone like a chief information security officer (CISO)
would rely on those entrusted to carry out the response
to validate the state of the environment and,
very importantly,
to assess the impact.
The latter can be defined using a framework
such as the NIST Guide
for Conducting Risk Assessments.
In this guide,
an assessment scale suggests,
for example,
how a high impact equals the organization’s incapability
to fulfill its mission.
In such a situation,
assets may be severely damaged
and even individuals could be harmed.
As you might have guessed,
this guide includes much more than attacks performed by malicious individuals,
such as events involving technical malfunction,
environmental disasters
or legal compliance problems.

On another important note,
part of containing a cybersecurity incident is
to have an incident response communication plan
to send appropriate notifications to management
and critical third parties.
It may contemplate media statement templates
according to the severity of the impact,
expected or already experienced.
Templates save time and allow consistency.
Your organization should have established channels and disclosure policies
that permit the confidentiality
that is required while handling communication of the incident.
For example,
the CSIRT may choose to prepare canned email messages
to alert stakeholders (e.g., clients, users)
and press release templates
to inform the broader community.
A strong communication plan can help
reduce anxiety in the public and sustain public trust,
ultimately limiting the reputational costs.

Another piece of advice
that you may hear quite often is
that an incident response plan should be tested.
Broadly speaking,
rehearsals may point to gaps
in policy and technical implementations.
Maybe the CSIRT can also find out
that reporting chains were unclear,
or there may be a clash between members
due to uncertainty about who’s got the last word.
These can be corrected to enhance the plan.

Finally,
your organization should train employees
to detect strange events
and identify tactics of social engineering
in emails and websites.
Indeed,
these are among the suggestions
sent out recently by the U.S. government
in the light of a heightened possibility to suffer cyberattacks
conducted by Russian threat actors.

A preventive approach to cybersecurity as a requirement

Up until this point,
it should be crystal clear
that an incident response plan is necessary for every organization.
Now,
we would like to raise the point
of moving beyond a responsive mindset
by adopting a preventive approach to cybersecurity.
What we mean by this is simple:
Stop waiting for a cyberattack to happen
to finally identify and address the vulnerabilities
in your system!

A constant,
thorough understanding of your system’s security status
is more than a “nice” thing to have.
It is actually something that should be in place,
which involves implementing security testing
from the early stages of the software development lifecycle
and through its entirety.

At Fluid Attacks,
we help you with the task of adopting this preventive approach.
Our red team actively finds
and exploits your system’s vulnerabilities,
getting to them before malicious attackers do.
Contact us!

*** This is a Security Bloggers Network syndicated blog from Fluid Attacks RSS Feed authored by Jason Chavarría. Read the original post at: https://fluidattacks.com/blog/incident-response-plan/