Humans have been telling stories to each other much longer than we've had computers.  I still think it's a powerful tool.  Over the holiday I've been telling various updated versions of the "Stone Soup" story to various groups in the security community.  There are many versions of the Stone Soup story.  They all fall into the "clever man" category of the Aarne-Thompson-Uther index.  Think of it as a CVE for folktales.  Specifically, Stone Soup is a type 1548 folktale.  Such stories normally involve a stranger who comes to a house or village and promises to demonstrate that they can make soup from a stone.  The first time that I heard this story, I was in kindergarten and in that telling, travelers came to a poor village who didn't have enough food to spare, so they promised to show them how to make soup from a stone.  First they needed to borrow a pot and some water and some firewood and they began to boil the stone.  Periodically tasting it and noting that it would taste better with an onion, or carrots, or chicken or what have you.  Eventually the makings of a real soup were found by the villagers and a proper soup is made.  At kindergarten, it was a lesson on sharing and coming together.  In this telling of the story everyone wins.

There are, howerver, multiple versions of the tale and it's not always so equitable.  Sometimes the clever man visits upon people who have plenty of food, but are unwilling to share, so they are fooled into providing a meal.  It relies upon the teller of the story to contextualize the tale, they'll choose who is the "good guy," and who is the "bad guy," and determine the lesson that they want to express in the story.

I've told versions of this story where I've chosen the villagers to be good, and the traveller is a charlatain who sells them a magic stone to solve their security troubles.  The lesson being that some security tools are like stone soup where the tool itself doesn't solve the problem, it's just an artifice that won't function until you give it visibility of your network, or you provide it with a proper inventory, or you code it with the right business rules.  It's lesson is that the tools won't do the hard work for you and if you had done the hard work already, you wouldn't need the tool. 

In other versions, the taveller doesn't have to be a charlatain, they can be entertaining and motiviating like in a 1720 version of the story where the villagers weren't being fooled, they bought into the game and everyone has a good time.  A stone-soup-like product could be sold with that kind of openness.  An organization may need help with "hard work" and such a product comes with the support to actually help with that work.  It's when budget and manpower from ongoing internal projects are diverted to a product like this is when there ceases to be a happy-ending.

In another re-telling, I've painted everyone in a mix of good and bad light.  In this version there are three main characters: a miracle-worker, the decision-maker who is convinced by the charlatain to purchase a magic stone to secure the castle, and they existing security staff.  As the security staff puts in all of the effort to make the magic stone functional, they're also partly to blame because they couldn't pull it all together without a magic stone to put it all under.  They weren't able to get the support of the decision-maker without the miracle-worker.  The lesson in that one was that we should be wining and dining our own management, before someone else does.

Telling such tales can be as helpful as humor and anecdotes.  There's more oral tradition to computer security than we would probably like to admit.  Stories are easier to consume than lectures, and may have better recall rates.

Kevin Liston