Incident Response

Taking CSIRT modeling to the next level

Presentation made using reveal.js. Type ? for navigation help, or just skip through using space key.

About the event

FIRST TC

Oslo, November 20th 2015.

About me

Frode Hommedal

Subject Matter Lead · Telenor CERT
7 years at Norwegian national CERT

I think a lot about models and methods.

About this presentation

On modeling CSIRTs

213 slides long (sry) · Made using Reveal.js

Why this topic?

Because I believe we are being
outperformed by our adversaries

What am I presenting?

Not The Answer™ but rather
the status of my own research
and learning experience

(Which is far from done...)

What do I hope to achieve?

I hope to spark some interest
in CSIRT modeling, I hope for
feedback, comments and new ideas
and I hope you find it useful.

Questions or comments?

@FrodeHommedal on Twitter
Or via LinkedIn

(I'd love to hear from you if you have comments)

Coming up:
A quick intro to the presentation.

This presentation has
grown beyond 200 slides.

So a presentation of the
presentation is in order.

Introduction

First there's the introduction,
where I present the backdrop
of my work, as I perceive it.

(If you click the link, hit back in your browser to get back here.)

Two critical loops

Next we inspect two critical loops
I believe every mature CSIRT
should be an important driver for.

(Sort of to set the CSIRT stage before discussing models.)

5 fun facts

Then there's a short break
for comic relief as we look at
5 fun facts about your defense.

(And yes, they're funny because mostly they're true...)

Adversaries

We then have a very quick
look on our adversaries.

(But only briefly. This presentation is about us, not them.)

Countering

An equally brief section on the
analytical bedrock of IR analysis for
countering our adversaries follows.

(We're not as special as we think...)

The CSIRT Analysis Pyramid

Finally it's time for one of the
major models of the presentation,
the CSIRT Analysis Pyramid.

Tactical

During the presentation I use
the word tactical a lot. So we
divert shortly for a definition.

Tactical Analysis

Next up is a deep dive into a
key concept of all the models,
namely tactical analysis.

The OODA loop

Before we delve into the CSIRT OODA
loop, we take a look at the original.

The CSIRT OODA loop

And finally it's time for
the CSIRT OODA loop.

(Let's get inside that adversary OODA loop.)

And that's it. I hope
you will enjoy the ride.

(Coming up next is the introduction.)

Throughout human history we have always had conflicting interests, competition, conflicts, unrest and war. We have also always had crime. So we have more or less always had soldiers, spies, rebels and criminals; armies, intelligence organizations, rebel movements and criminal syndicates. None of these things are new.

Yet we seem to have been caught completely off guard when we — after having invented computers; decided to connect every single of them to the same network; and then digitizing every piece of information and every service and stuck it all onto said interconnected computers — discovered that all those people adopted new technology really well and very quickly.

The result? We have opened the gates and brought back raiding and pillaging at a level not seen for a long, long time, at least in large parts of the world.

We have enabled spies and criminals to operate at large scale with little risk of being caught and brought to justice or face any kind of consequences.

Their cost / benefit ratio is ridiculous.

We have a leaky boat design, but instead of fixing the leaks, we are just making faster and bigger boats with more bells and whistles to carry more people more often.

And more often than not security people are only brought in to bail water out of the boat when things get too bad, instead of being asked to help fixing the design.

(I've sort of addressed this issue before, talking directly to developers: The Internet is on fire: Don't just stand there — grab a bucket)

And boy, is there a lot of water to bail. We hear about new critical vulnerabilities and severe security breaches almost every week. Big companies, everywhere.

We are experiencing breach fatigue.

We have actually had to conclude that we are unable to design, deploy and operate IT infrastructure securely.

Your prevention never holds up.

And worse, we don't seem to learn. We
keep putting way too much faith in prevention.

How sustainable does this sound to you?

We need a shift in thinking
from Secure IT to Defendable IT.

(Or Rugged IT or Sustainable IT or whatever. But better!)

This presentation is dedicated to
CSIRT models and methods I hope
will help pushing towards defendable IT.

But first, a quick look at how
a typical CSIRT engagement
at a mature CSIRT looks.

And there you are, happily spinning
in your SOC hamster wheel...

(Doesn't sound familiar at all, does it...?)

So 7 improvement vectors ...

... vs 1 improvement vector.

Your overall security performance probably
improves more with 8 than just 1, right?

Countering

Stopping your adversaries in their tracks.

Quick HOWTO

Hypothesize · Collect · Detect · Identify · Act

Sounds familiar...?

(It should)

It's quite similar to the intelligence process:

Requirement ⇨ Plan · Collect · Analyze · Assess ⇨ Exploit

Next: Let's apply it to incident response!

Goal: Getting from incidents via
threat intel to risk management.

Objective: Driving the improvement loop
so you consistently achieve improvements
along as many of the 8 vectors as possible.

But first, a few words on
the hierarchy of knowledge.

Tactical analysis is the bridge between
(incident driven) technical analysis and the
risk management process in your company.

Tactical analysis is a crucial driver behind
many of the 8 mentioned improvement vectors.

Teaser

The CSIRT Analysis Pyramid builds on the
following capability model for the CSIRT:

(I will expand on that another time)

(Break)

The CSIRT OODA loop

From intrusion to response

This will all be simplified,
but please bear with me.

Attacker rallying cry (1)

What do we want?
Access to information!
When do we want it?
Preferably straight away!

Attacker rallying cry (2)

What do we want?
Control of the capability!
When do we want it?
Preferably straight away!

Attackers want two things. Accass to information and control over capabilities.

Access example: Strategy documents.

Control example: Computer to send spam.

From the attacker's side there are
three main foothold perspectives:

• User Credential Access
• Operating Environment Access
• Operating System Access

ENV example: Running malware "as user".

SYS example: Rootkit.

From the defender's side there are
five main footprint perspectives:

• User Level Footprints
• Application Level Footprints
• Operating Environment Level Footprints
• Operating System Access Level Footprints
• Network Level Footprints

APP example: Browser cache.

ENV example: Autoruns.

SYS example: Authentication logs.

Most of the time incident response starts with the discovery of suspicious or known bad behaviour and activities on one or more of your IT systems.

As you discover more (possibly) related evidence within the available forensic footprint, it is important that it is properly recorded, registered and organized.

Now starts the challenge of identifying which of the discovered evidence is relevant to understanding what the attacker is doing within your systems.

The technical analysis, evidence triage and information management part of your incident response engagement is closely related to the observe stage in the OODA loop.

Next comes the orientation phase, where you analyze your findings, look for correlations and connections and figure out what is going on.

This stage is driven by tactical analysis.

You are literally
connecting the dots.

Once you have figured out how your evidence connects, you need to interpret it's significance and the story it tells.

Forensic evidence is the show part of show and tell, but you also need to be able to tell the story. What is really happening?

You must establish and test hypotheses. Rigorously. Or the evidence will only tell you what you want it to...

CHINESE APT ALL TEH THINGS !!1!

Once you have a good understanding of what's going on, it's time to plan a response.

Key point. Plan, then act.

And when you do act, act decisively.

(E.g. reinstall all affected computers simultaneously.)

But don't just react. Think ahead.

Plan for your adversary's response.

Getting inside your adversary's OODA loop means performing these steps faster and better than the tactical actions of your adversary during your engagement.

To drive the analysis and response process
during an incident you need to staff up at
least three distinct and separate roles.

1. Incident lead

Coordinator, process driver and responsible for the outcomes.

2. Tactical analyst

The big picture person, setting the analytical course.

3. Information manager

Managing the inevitable information overload.

These three distinctly different roles should comprise the core team of an incident response engagement.

They obviously need support from technical analysts, management, operations and so forth. You need more than three people involved in an incident engagement.

But an incident engagement not run by a core team will most likely struggle with focus, process and progress.

Achieving that is the core team's function. Keeping the right focus, adhere to established processes and make sure you make good progress and get results.

Do this right, and you may
outperform your adversaries.

Do this right, and you can
clench your fist in triumph.