Kevin Mitnick, anyone?

I’ve long been a fan of the Kevin Mitnick story. His hacking, capture by the FBI, and subsequent legal drama all make for a complex story.

This week, I had the opportunity to present the story to one of my classes. I think the lesson went really well. A little background on how Kevin Mitnick fits in my daily routine: The students in this class are studying for their A+ Computer Technician certification exam and our topic is computer security. Here’s how I presented Mr. Mitnick to the class:

  1. Sketch the Mitnick story in broad strokes to the class. Describe his breakin to Tsutomu Shimomura‘s computer (based on previously reading Takedown and various Free Kevin websites), his history with social engineering (based on the introduction to The Art of Deception), and the time he spent in jail — both before and after trial.
  2. Read a social engineering story from The Art of Deception with students reading the roles. It reads like a play, where the students have the opportunity to ham it up.
  3. Discuss and reflect. The students spontaneously offered comments (“no way, no one would ever do that!”) and I asked questions (“What weakness is the attacker preying off of here?”).
  4. Assign students to research the Free Kevin movement and the FBI’s position. For resources, Wikipedia’s Kevin Mitnick article is flagged as biased — so that’s a great discussion point. Tsutomu Shimomura’s website for Takedown has good pro-government information. Set up a class discussion on both sides of the story.

Colorful stories like Kevin Mitnick’s involvement in social engineering help show teens that the weakest spot in security is the human element. Once I can get the kids to put themselves in the shoes of a Joe in accounting or a Sue in marketing, they’re able to see how a social engineer, posing as a computer technician, can gather seemingly innocuous bits of information.

3 thoughts on “Kevin Mitnick, anyone?

  1. His story is an interesting and educational one. One of the things that gets lost in his story and similar ones is that they really do cause expensive problems for the companies whose computers they break into. I was an operating system developer in a group whose main development system was broken into many years ago. Because the break in happened while the master disk was writable (a very short window) we had to hand check every line of code. You would be crazy to trust someone who lied to break into your system when they say they didn’t touch anything after all. About 70 people worked for a month to do that checking. That is a lot of lost productivity and cost a lot of money. It made the break in a lot more than a harmless prank.

  2. Wow, 70 people for a month of work, just because you weren’t sure no one wrote to the code. These days, code checkout systems like CVS would render that unnecessary (but — gasp — what if you think your repository is unreliable!?!)

    I will definitely incorporate your story into the Mitnick teaching I do.

    Thanks for sharing, both here and in your blog. I enjoy reading your computer science resources.

Comments are closed.