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.
4 comments:
While I agree with your (and Harlans') comments about graphics and presentations, your post begs the question; what apps did you use to make your graphics and your timeline? More importantly, what apps do you find useful -- or not so useful?
A seemingly fundamental problem in the 'look at this' image is that of hiding the important information: the timeline at the bottom is lost in the background murk, and the callout colours do not help in making the correct read-order clear: start at the *bottom* (contrary to normal reading order) and then proceed in a kind of right-to-left, then top-and-down order.
The video doesn't help much: it only enforces a reading order to make the presentation clearer. The real solution probably lies in encouraging that reading order without imposing the 'viewing time line' of the video, but instead by layout and choice of colours.
Better is (I think) to make the timeline the central feature, and place it above the text (or perhaps at the left edge), and then pull out the separate points below or to the right of it that.
Remove the colour from the text -- if it is thought to be useful, place it on the time line.
The basic problem is one I would place in grahical and typograhical design -- and probably best solved by someone who solves *that* kind of problems daily. (Which I don't, though I dabble in typographical design.)
Anders,
Thanks for the comments. Can you provide examples of what you are describing?
This continues to be a problem for us. How to properly render timelines visually. I would also be interested in the tools you have used to create this.
Post a Comment