Sunday, February 8, 2009
Support Talk Forensics
There's a new podcast/online radio show by Larry Daniel called Talk Forensics. I'm really looking forward to this since Larry is bringing real forensics experts in to discuss forensics. It's every Sunday at 4 pm Eastern, starting today when Larry talks with a cadaver and trailing dog expert. Apparently Larry needs at least 500 downloads to extend his show. Larry's blog, if you didn't know is over at exforensis.
Thursday, February 5, 2009
Graphical representation of concepts
Recent discussions led me to do a little homework and reading in the past few days. These discussions were more or less along the lines of how to make an impact when presenting data of interest to decision makers. As you all should know by now I am a very visually oriented person. If a graphic can help make sense of a difficult to explain subject, then use the graphics.
To date, the best presentation I've seen that included graphics was given by James Aquilina at TechnoSecurity 2008. His use of animated characters to present concepts was just brilliant. I wish I had been able to ask him a few questions after the presentation.
Anyways, I had to present to a group of decision makers some time ago about the Master Boot Record Rootkit and how it worked. I fought for hours trying to figure out what would make sense. How could I describe a MBR rootkit in simple terms? I determined there was simply no easy way to describe it's complexity and have them understand. So, why try? If I would only confuse them by talking about it, why not have a graphic or two that would get my point across and make sense to them?
I simply developed the following:
We of the technical breed need to realize something and need to realize it fast. If you're going to work in this field, you need to make people understand difficult subjects. If you can maintain technical accuracy and make a lay person understand you, then you've succeeded. In this case, using the graphics removed the need to describe the ins and outs of sectors and MBR code and JMP instructions and turned it in to a discussion of "this malware is bad" after a simple explanation, and allowed the decision makers to focus on the meaningful stuff.
Now let's discuss issues of time. How do you use time in a presentation to the lay person?
In many cases we may do this with a report that reads something like this:
11/2/08 9:25 AM
FTP service on server was modified.
An FTP account with a weak password was created and the account was granted access from external hosts.
11/8/08 9:22 PM
System was remotely compromised by brute force FTP attack.
11/8/08-1/12/09
FTP access was used for distribution of warez.
1/20/09
Sensitive data was downloaded from the server.
2/4/09
System Administrators discover the incident and respond by pulling the network cable, scanning the computer with antivirus, and deleting the files created by the attackers.
2/5/09
IRT responds and collects incident data.
Sure this is simplified greatly, but it's a common method of using time. Let me point something out if you didn't catch it. There was a three month gap in the incident, from the time of compromise to the time of containment. There was a two month period of time when the system was being used for warez distribution. The brain must process that time lapse in a textual presentation. Math must be done to calculate the temporal proximity. *hint* people reading your report don't want to do math or think too hard.
Now look at this:
What are you drawn to? The green? The red? That there is an apparently large gap between the two green items? Now we're getting somewhere.
Harlan's concepts for using time are a great starting place for this. As he says, and I agree, we identify a point or span of time where actions took place and present them using various elements. I'm not *yet* using this graphical representation at a micro level where we present MAC times and small correlated events to tell the story. I'm using this at a high level to tell the story of the events leading up to, and during the incident. This is an abstracted view of an incident that can be used to explain incident events to the decision maker or lay person. Think about a presentation you might have to give to a body responsible for deciding the fate of an organization. This group might include C level execs and their underlings. How would you present an incident to them? Is a report format appropriate? Would your report even get read in enough detail? My philosophy is write your technical report as normal, but create an executive report with a graphic or two and a timeline that highlights important points in time.
The goal should be to explain the incident, but keep it simple enough to keep their attention or call their attention to specific items of interest. One can get as fancy as you like, as long as you don't lose the audience. The following is a different way of looking at the same timeline. *think timed presentation*. I do apologize for the poor quality, the video did not render properly from the original to youtube. I'm working on a different render and hope to have it updated soon.
There is definitely more work to be done with using time and timelines.
To date, the best presentation I've seen that included graphics was given by James Aquilina at TechnoSecurity 2008. His use of animated characters to present concepts was just brilliant. I wish I had been able to ask him a few questions after the presentation.
Anyways, I had to present to a group of decision makers some time ago about the Master Boot Record Rootkit and how it worked. I fought for hours trying to figure out what would make sense. How could I describe a MBR rootkit in simple terms? I determined there was simply no easy way to describe it's complexity and have them understand. So, why try? If I would only confuse them by talking about it, why not have a graphic or two that would get my point across and make sense to them?
I simply developed the following:
We of the technical breed need to realize something and need to realize it fast. If you're going to work in this field, you need to make people understand difficult subjects. If you can maintain technical accuracy and make a lay person understand you, then you've succeeded. In this case, using the graphics removed the need to describe the ins and outs of sectors and MBR code and JMP instructions and turned it in to a discussion of "this malware is bad" after a simple explanation, and allowed the decision makers to focus on the meaningful stuff.
Now let's discuss issues of time. How do you use time in a presentation to the lay person?
In many cases we may do this with a report that reads something like this:
11/2/08 9:25 AM
FTP service on server was modified.
An FTP account with a weak password was created and the account was granted access from external hosts.
11/8/08 9:22 PM
System was remotely compromised by brute force FTP attack.
11/8/08-1/12/09
FTP access was used for distribution of warez.
1/20/09
Sensitive data was downloaded from the server.
2/4/09
System Administrators discover the incident and respond by pulling the network cable, scanning the computer with antivirus, and deleting the files created by the attackers.
2/5/09
IRT responds and collects incident data.
Sure this is simplified greatly, but it's a common method of using time. Let me point something out if you didn't catch it. There was a three month gap in the incident, from the time of compromise to the time of containment. There was a two month period of time when the system was being used for warez distribution. The brain must process that time lapse in a textual presentation. Math must be done to calculate the temporal proximity. *hint* people reading your report don't want to do math or think too hard.
Now look at this:
What are you drawn to? The green? The red? That there is an apparently large gap between the two green items? Now we're getting somewhere.
Harlan's concepts for using time are a great starting place for this. As he says, and I agree, we identify a point or span of time where actions took place and present them using various elements. I'm not *yet* using this graphical representation at a micro level where we present MAC times and small correlated events to tell the story. I'm using this at a high level to tell the story of the events leading up to, and during the incident. This is an abstracted view of an incident that can be used to explain incident events to the decision maker or lay person. Think about a presentation you might have to give to a body responsible for deciding the fate of an organization. This group might include C level execs and their underlings. How would you present an incident to them? Is a report format appropriate? Would your report even get read in enough detail? My philosophy is write your technical report as normal, but create an executive report with a graphic or two and a timeline that highlights important points in time.
The goal should be to explain the incident, but keep it simple enough to keep their attention or call their attention to specific items of interest. One can get as fancy as you like, as long as you don't lose the audience. The following is a different way of looking at the same timeline. *think timed presentation*. I do apologize for the poor quality, the video did not render properly from the original to youtube. I'm working on a different render and hope to have it updated soon.
There is definitely more work to be done with using time and timelines.
Subscribe to:
Posts (Atom)
