Getting Incident Response Help from Richard Feynman

Published: 2018-04-14
Last Updated: 2018-04-15 04:18:36 UTC
by Kevin Liston (Version: 1)
0 comment(s)

Richard Feynman was kind of a big deal (https://en.wikipedia.org/wiki/Richard_Feynman) and known for being a "Great Explainer"1  One of the many things that he is know for, is his explanation technique.

The Feynman Technique (https://collegeinfogeek.com/feynman-technique/) is used a lot as a study technique but is also has application in your Incident Response and Investigation processes.  It breaks down something like this:

  1. Grab a sheet of paper, or open up a text editor, at the top put your concept or idea that you want to explain.
  2. Describe the topic in your own words as if you're trying to teach someone about it.  Use plain language as if you're writing for a non-expert.  Use examples to teach to.
  3. Read your work and identify the areas where your explanation is lacking or where out-right gaps exist.  Use them to refocus your study.
  4. Eliminate jargon and technical shortcuts.  Make sure that it all would make sense when read by someone who don't know what you know.

It doesn't take a lot of modification to apply this to writing incident narratives.  Keep your audience in mind, because narratives aren't read just by your fellow incident handlers but also by upper management, decision makers in IT, and general users.  This is why step four is so important.

The technique can also help focus and drive an investigation.  It can be used to help answer the crucial "are we finished with our investigation" question.

For example, a narrative in ticket might read like:

"User was exposed to a malicious web advertisement.  Initial exploit did not generate an alert, but the secondary payload was blocked by web filters.  System was re-imaged."

or

"User reported receiving a suspicious email.  Email contained a link to an exploit site that was not properly classified by our web filters.  URL was added to block-list and User given a pat on the head." 

These kinds of events happen several times a day in many environments.  Pretty simple, right?  But are they simple and complete enough?  Considering the second example, it's going to have a copy of the email and headers attached to the ticket and probably some sort of dynamic-analysis report of the malicious URL.  If I have to write that kind of narrative 50 times a day I might be happy with that narrative.  But I can do better.

Imagining that I present that narrative to the Quality Assurance manager in my head, I hear the following conversation:

QA-me: "Did they click the link?"

IR-me: "They claim that they did not, it's in the attached email."

QA-me: "Okay, add that to the narrative, but did they REALLY not click that link?  Did you check the logs? 'Trust but verify.'"

So, I update my narrative, and go back to check the web logs.  It takes a few minutes to determine that they didn't click the link, but sadly a few other's did.  Drat this just got a lot messier.

Think of what other questions the hypothetical QA manager would ask.  Iterate until the voices in your head are happy.

Sometimes you're not going to have an answer.  For example, consider a case where an employee has installed some unwanted software on one of your servers.  You might not get a good answer out of them for why they did it, but you stand a pretty good chance of know when in installed, and how it happened.  You might even know a bit about when it was used, but you might be missing monitoring or controls that wouldn't allow you to know where it connected to or what it was being used for.

"We don't know" is valid in a narrative as long as you can explain why you don't know.  Sometimes exploring why you don't know gives you an idea to actually find out.

Paraphrasing slightly: If you can't explain what happened, then you probably don't know what happened.  A good narrative with a high-level time-line and network diagram for your "interesting" incidents is an important product of your Incident Response process.  That is, if you fancy not working the same incident over and over.
 


1 LeVine, Harry (2009). The Great Explainer: The Story of Richard Feynman.

Keywords:
0 comment(s)

Comments

What's this all about ..?
password reveal .
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
https://thehomestore.com.pk/
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
https://defineprogramming.com/
https://defineprogramming.com/
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
Enter corthrthmment here...

Diary Archives