Better security through storytelling
If you are like me, storytelling is not a native skill. But others have been using this in the security field for a while. Recall the Trojan horse story from 2000 BC. So why focus on story telling now?
Two significant trends demand it: (1) working more effectively with developers and (2) working more effectively with boards of directors and C-level executives. Both of these groups are becoming more important to the success of an enterprise security program. I have encountered storytelling more often in my own work in the last few months and I’ll share my experiences and thoughts in both areas, which I am calling “tactical storytelling” and “strategic storytelling”.
It’s obvious now that developers are critical to all business operations. It wasn’t so obvious in 2011 when Marc Zuckerberg wrote: “software is eating the world”. As your business processes are automated and new ones are developed at the speed of need, security will need to interact with the development teams to manage risks. Developers are already collaborating more closely with operations, under the DevOps umbrella, and security needs to join this party.
Product development has moved to Agile methodology in both large and small organizations; Agile developers implement code on the basis of “user stories”. These stories are more conversational in concept. They can complement the traditional security compliance requirements. For example, instead of PCI 6.4.3 “Production data are not used for testing or development” we might have a user story like: “As a developer, I want to ensure that production data is not used in testing, so that customer confidentiality is not compromised”. User stories can give security practitioners a better way to interact with development teams, using their language.
A recent book by Stephen Dye, "Secure Agile Development," does a nice job of explaining user stories in more detail. He provides more detailed user stories around the SANS Top 25 software vulnerabilities. Each “story” is cast into a one-page template that could be used by a development team to address that security vulnerability. You can use the template to help develop new stories for your Agile teams. These stories are simply a better way to foster communication between security teams and development teams. By using this approach, you will have fewer security issues, when the application goes live.
Stories are great for communicating with executives as well. Yes, security awareness has moved up to the C-Suite and board, but most executives are not trained in this field or in technology in general. So how do you communicate with them, especially if you have a tech background? You can learn from the masters of security storytelling.
For example, you can watch William H. Murray here. Or you can watch Jack Daniel here. You can learn from these people. For me, each time I give a presentation I consult with Dan Roam’s book "Show and Tell". This is a very easy to read book on giving presentations. Each of his four presentation types is built on a storyline. The story is the glue that links together “The Report”, “The Explanation”, “The Pitch”, and “The Drama”. I have looked at a lot of books on this subject, but this is the best for easy to absorb and practical guidance on using a story to make your point.
You can go further than this. If you are trying to sell a major security program, or sell yourself into a C-level role, you will need to position these goals as part of a story that your audience can see themselves in. To get this Jedi Master level of storytelling, you can use the techniques explained by Peter Guber in his book "Tell to Win". Guber is a master of storytelling and movie making. He tells the reader how to do it, but you will have to develop your own style and approach.
Whatever challenges you are facing, think about using stories to communicate and help overcome those obstacles. Create a story inventory ahead of time, and bring them out for each situation. Use the guidance from the references above. “Do or do not, there is no try”.
This article is published as part of the IDG Contributor Network. Want to Join?