Posted by Rob Slade on November 11, 2016.
Recently I found that Autism Canada had created a guide for journalists covering stories about autism and those who have it. My immediate reaction was that this was a great idea for those of us in infosec to steal. Not only are most of us rather far out on the Aspberger’s scale, but we suffer the same kinds of misunderstanding from society in general, and reporters in particular.
I figure that we should build our own guide for journalists writing about infosec. Pretty much every day you read articles and yell (mostly silently, but not always) “I wish they would stop saying [X]!” We could help not only journalists and the general public, but also ourselves. (I’m sure you’ve sat through presentations and articles from your colleagues that make frequent use of common errors.)
So, to start off with some general principles:
Don’t try to oversimplify stories about infosec.
Information security has multiple aspects, since our computer and communications systems are, themselves, extremely complex. However, as Einstein said, everything should be as simple as possible–but no simpler. And, as a famous journalist said, for every complex problem, there is an answer that is simple, neat–and wrong.
And, of course, there is the fact that the media is used to writing for an audience that is used to six-second sound bites and 140 character tweets.
When I’m reading an article in the general press about a technical issue, I can often tell that a journalist has been given a phrase or an illustration about a problem, and has not been informed about the limitations of that illustration, in regard to the reality of the technology. This really isn’t the journalist’s fault, except in terms of failing to pursue the issue. But you do have to ensure that you understand the problem, before you start writing about it.
If you do take the time to understand the problem, you often find that the basic issue actually is quite simple. It’s just that it’s not illustrated by the example you were either told or were going to use in the first place.
Which brings me nicely to an important second principle:
Don’t explain things you don’t understand.
I have spent years traveling around the world, helping people to prepare for a certain certification examination. There are many guides, one of which has risen to pre-eminence in popularity. I always tell my students that this guide is helpful, fairly complete, easy to read, and that I absolutely refuse to answer any question that begins “[The guide’s author] says …”
The author of this guide put a great deal of time and effort into writing, polishing, and updating the content of the book. (She also put a lot of time into collecting other people’s material, but that’s a separate issue.) The author had, indeed created a helpful resource–but a rather imperfect one. She did insist on “explaining” technical issues that she did not, in fact, understand, and, therefore, some of the explanations made no sense, and others were flatly wrong.
If you don’t understand it, you’re not going to be able to explain it properly. This would seem to be a very basic tenet, but, over the years, I have found that all kinds of people are willing to “explain” things they don’t understand. (When I wrote my first book I got this advice from another author and was quite offended. After all, I’d put six year’s worth of research into the work. Then I got farther into reviewing technical books, and realized exactly where he was coming from …)
OK, what kind of things in press reports of infosec make you shudder?Submitted in: Perspectives, Rob Slade, Security |