[BreachExchange] Addressing incident response with some common sense

Audrey McNeil audrey at riskbasedsecurity.com
Wed Jul 18 19:10:30 EDT 2018


https://it.toolbox.com/blogs/kevinbeaver/addressing-
incident-response-with-some-common-sense-071118

Incident response – it’s something that many people hope they never have to
deal with. Maybe that explains why so many organizations don’t have a
formal incident response plan. And, when incidents do occur, they clearly
get caught off-guard and react in all the wrong ways. The thing is,
incident response is nothing magical or mysterious. Nor is it super
technical. It's all just common-sense steps that you walk yourself and your
team through in order to address security events in a mature and
professional manner. It’s all about to getting to the root cause,
cleaning-up, learning and moving on.

If you don't take a measured approach to security incidents, opposing
counsel most certainly will. Be it your customers, business partners, or
whomever, when people are impacted by a security breach, they’ll go out of
their way to get back at your business – spending much less time and money
hiring lawyers than it would’ve cost your business to address security
incidents in the first place. You must not follow the crowd and stop
treating security and the inevitable incident or breach as insurmountable
challenges. An approach that deals with the basics – and nothing more – is
the only approach that you should be spending time on. Otherwise, you'll
likely get sidetracked with technical minutia, politics, and other things
that only serve to distract you.

For incident response to work and for your business to survive an attack,
you just need to focus on a few things:

· Who’s on the team? It should be more than just IT and security staff.
Legal, HR, customer service, and PR should be involved. A member of the
executive management needs to be on board as well.

· How do you define “incident”? It’s more than “we got hacked”. It should
involve everything from a lost laptop to malware outbreaks to denial of
service attacks. You need to know when to invoke the plan.

· Who else will you likely need to call on when an incident occurs?
Internet service providers, cloud vendors, forensics investigators and
security consultants come to mind.

· How will you respond and what will tools will you need to determine
whether a breach occurred? This is where you outline your
approach/methodology for analyzing the situation. Tools such as existing
SIEM, log analyzers as well as network analyzers and vulnerability scanners
will likely need to be in the mix.

· How will you notify those impacted? This should follow the letter of the
law according to state (i.e. state breach laws), federal (i.e. HIPAA), and
international (i.e. GDPR) breach notification requirements.

· How will you test your plan? Running through tabletop scenarios mimicking
the various types of incidents can make for great practice that allows you
to fine-tune your plan.

These are all common-sense basics that many people have yet to think about.
Don’t let that be you.

Keep in mind the time factor as it relates to incident response. Hackers or
others with ill intentions often have nothing but time. So you need to be
able to respond quickly and effectively. That comes with a solid incident
response plan and all the right people knowing what to expect when the
going gets rough. If you do this, you can minimize the impact of the time
factor and swing it back in your favor. Don’t take the route that others
have taken and try to wing it with incident response. The PR and legal
issues tend to stack up quickly so being able to figure out what happened
while keeping a level head is the only insurance you have to minimize an
incident’s impact on your business.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20180718/bcdae335/attachment.html>


More information about the BreachExchange mailing list