April 2010 Archives
Filed in: PowerPoint Ranger
I have been looking back through some of my previous blogs these past few weeks and I just happened to notice that I seemed to be on a minor rant about how security personnel present security information (in this
blog and this
blog). I told myself that I would pick another topic this week to avoid seeming like a broken record. Then, this story popped up in the New York
Times called "
We Have Met the Enemy and He Is PowerPoint." It is about how some of the leaders in the US military hate the use of PowerPoint as the default way to convey information up and down the chain of command. This quote sums the article well:
"The amount of time expended on PowerPoint, the Microsoft presentation program of computer-generated charts, graphs and bullet points, has made it a running joke in the Pentagon and in Iraq and Afghanistan." According the article, most junior officers fill their time building slide decks for one meeting or another, with many affectionately referring to them as PowerPoint Rangers. (Full disclosure: When I was in the service, I was a qualified PowerPoint Ranger myself. Since I retired, I have upgraded my skills to PowerPoint Ninja.)
I love the New York Times quotes from the generals (especially the McMaster quote):
"It's dangerous because it can create the illusion of understanding and the illusion of control. Some problems in the world are not bullet-izable."-- Brig. Gen. H. R. McMaster 
"When we understand that slide, we'll have won the war."-- General Stanley A. McChrystal referring to this
slide that tries to convey the complexity of the Afghanistan war (I want to meet the Captain that put that slide together - he must have had a lot of time on his hands).
"PowerPoint makes us stupid."-- Gen. James N. Mattis of the Marine Corps. It seems that these military leaders are of like mind with Doctor Edward Tufte.
From my
blog at the end of March:
"You will be interested to know that Dr. Tufte hates PowerPoint; at least the default way that most people use it: Title, 3-5 bullets of text, spinning doughnuts that have nothing at all to do with the presentation. In his seminar, Dr. Tufte does not use it. His famous example-- how NASA's engineers might have failed to prevent the Challenger Space Shuttle catastrophe in 1986 because a badly designed slide deck did not convince NASA leadership to scrub the launch-- is bone chilling."
Alas, PowerPoint is not to blame here. Presentation software, like PowerPoint and other software packages are merely presentation tools. Where the military, NASA, the commercial sector and, of course, the security community fail is how we all use the tool.
For what is PowerPoint good? It is good for conveying ideas to a large group of people - it is actually quite good at that.
For what is it not good? Summarizing very complex ideas - at least in its default use (reams of slides filled with indented bullet lists). Presenters can use the tool for good summaries, but the creator needs to back up the work with a longer narrative. This is similar to what we do at iDefense with our written products that cover the same topic at different lengths: Long Papers, Minis, Executive Summaries and One-Page Bullet Lists.
Where we all have failed is using the tool as the only vehicle to construct an original thought. PowerPoint has no method that I know of to convey subtlety or complexity; indeed, its creators did not intend for it to do so. I have come to believe that most PowerPoint decks should point back to a larger body of work or should accompany a resident expert. In most cases, the deck should not stand alone. How many times have you requested a copy of the slides used for a briefing that you thought was outstanding, but by the time you got around to reading them again, you found that you could not remember why you thought they were so good?
The bottom line is that many people are tempted to use PowerPoint as their only vehicle for organizing their thoughts. As General Mattis says, that "makes us stupid." Here is my recommendation for all the security geeks out there. If you are trying to convey your idea, before you resort to slide decks, write it out. Talk to your friends about it. Draw it on the white board or a handy bar napkin or your passed-out buddy's bald head. When done, write it out again and look for holes in your thinking. When you are done with all of that, you might be ready to pull out the PowerPoint program and work on your Ranger tab.
Actually, the
slide that General McChrystal denounced in the New York Times article is the perfect slide that the presenter should have used. With one slide, General McChrystal instantly understood how complex the Afghanistan problem is. If that were the author's intent, then hoorah - the meeting would have been over! Doctor Tufte would be proud.
(No Comments)
Filed in: Books
This is not a comprehensive list of books that all security professionals should read. It is really my own eclectic collection that I have found valuable in understanding the cyber security landscape throughout my career. If you are new to the field, start with the titles in the "Novels and Books for Historical Context." As the subtitle implies, you should have read these by now.
Novels and Books for Historical Context
(You should have read these by now.)
"Neuromancer"
by William Gibson
"The
Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage"
by Cliff Stoll
"Snow
Crash" by Neal Stephenson
"Fatal
System Error: The Hunt for the New Crime Lords" by Joseph Menn
Current State-of-the-Art Books
"Cyber
Fraud: Tactics, Techniques and Procedures" by iDefense (shameless
plug)
Books You Should Hand Your New Boss as He Comes in the Door
"Secrets
and Lies: Digital Security in a Networked World" by Bruce Schneier
Good Hacker Novels that Don't Exaggerate the Genre
"The
Blue Nowhere: A Novel" by Jeffery Deaver
Interesting Cyber Security Novels that I Just Liked
"Cryptonomicon"
by Neal Stephenson
"Killobyte"
by Piers Anthony
"The
Zenith Angle" by Bruce Sterling
Gaming and Future Intelligence Collection
"Daemon"
by Daniel Suarez
"Halting
State" by Charles Stross
Information Design
"The
Visual Display of Quantitative Information, 2nd edition" by Edward
Tufte
"Visual
Explanations: Images and Quantities, Evidence and Narrative" by
Edward Tufte
"Envisioning
Information" by Edward Tufte
"Beautiful
Evidence" by Edward Tufte
"The
Wall Street Journal Guide to Information Graphics" by Donna Wong
(No Comments)
Filed in: Wall Street Journal
I just finished reading
"The
Wall Street Journal Guide to Information Graphics" by Donna Wong. A
couple of weeks ago, I went on a fan-boy
rant
regarding the research and writings of Dr. Edward Tufte; who in my
opinion, is the smartest person on the planet when it comes to conveying
complex ideas in a chart. His books and lectures over the years have
really helped me convey complex security ideas to my bosses and
customers. However, the downside to Doctor Tufte's methods is that he
does not make it easy for you. He expects you to wade through the entire
set of books (count 'em, four in all) and decide for yourself. He gives
no executive summaries, no bullet points and definitely no accompanying
PowerPoint slide decks. Enter Ms. Wong.
According to the back cover, Ms. Wong has been doing information
graphics for more than 20 years and she was a student of Doctor Tufte
back in the day. Compared to Tufte though, Wong is concise; her thin
book of 149 pages is a how-to book for creating effective charts; mostly
for newspaper-type publications as the title implies.
This is not a book you read cover to cover. It is more of a cook book.
Want to know how to do a line chart? Turn to page 49 and admire the
layout. On the left page, Wong describes all the incorrect ways to do
it. "Never shade below a line unless the chart has a zero baseline." On
the right, she shows all the ways to do a line chart correctly. "Choose
the y-axis scale so that the height of the fever line occupies roughly
two-thirds of the chart area." On both pages, she outlines the dos and
don'ts in a terse and easy-to-read form. Unlike Tufte, she is not giving
you the history of line charts from the beginning of time to the
present. She just gives her opinions based on 20 years of industry
experience. If you are in a hurry, this is a book to keep on your shelf
regardless if you are just beginning your security career or if you are a
grizzled veteran.
My only knock on the book is that as the reader gets to latter parts,
the examples tend to be more and more specific to journalism; mostly
financial journalism; however, this is a minor knock. You can learn a
lot by spending three or four hours perusing this book. You can
definitely make your own charts better if you review the appropriate
section of Ms. Wong's book before you go final with your own chart
designs. I think it is so valuable that I am going to add it to my own
recommended book list for security professionals. For those of you
following along at home, here is the latest list:
Novels and Books for Historical Context
(You should have read these by now.)
"Neuromancer"
by William Gibson
"The
Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage"
by Cliff Stoll
"Snow
Crash" by Neal Stephenson
"Fatal
System Error: The Hunt for the New Crime Lords" by Joseph Menn
Current State-of-the-Art Books
"Cyber
Fraud: Tactics, Techniques and Procedures" by iDefense (shameless
plug)
Books You Should Hand Your New Boss as He Comes in the Door
"Secrets
and Lies: Digital Security in a Networked World" by Bruce Schneier
Good Hacker Novels that Don't Exaggerate the Genre
"The
Blue Nowhere: A Novel" by Jeffery Deaver
Interesting Cyber Security Novels that I Just Liked
"Cryptonomicon"
by Neal Stephenson
"Killobyte"
by Piers Anthony
"The
Zenith Angle" by Bruce Sterling
Gaming and Future Intelligence Collection
"Daemon"
by Daniel Suarez
"Halting
State" by Charles Stross
Information Design
"The
Visual Display of Quantitative Information, 2nd edition" by Edward
Tufte
"Visual
Explanations: Images and Quantities, Evidence and Narrative" by
Edward Tufte
"Envisioning
Information" by Edward Tufte
"Beautiful
Evidence" by Edward Tufte
"The
Wall Street Journal Guide to Information Graphics" by Donna Wong
(No Comments)
Filed in: Software Liability
One of my colleagues at iDefense, Sean Larsson, and I were discussing
software liability last week. This popped up around the water cooler
because Toyota executives admitted that software glitches caused some of
the
brake
failures that have been in the news lately.
From my take on the US zeitgeist, most people are shrugging this off as
just another big company not executing the proper due diligence on its
products, but this situation is different. This is a software problem
and one of my pet peeve topics.
As a computer scientist, I am embarrassed that my field has not
developed into a profession more akin to our civil, mechanical and
electrical engineering counterparts. Those engineers have to attend at
least a four-year college program sanctioned by the Accreditation Board
for Engineering and Technology (
ABET),
pass the
Fundamentals
of Engineering Exam and then, after several years working for a
licensed engineer, pass the
Principles and Practice of
Engineering Exam before they can call themselves "professional
engineers." Many software development companies, by contrast, will allow
anybody who can get a program to compile to work for them. Professional
engineers build bridges, spacecraft, dams and power grids without risk
of life or limb to the general populace. When somebody does
screw up
though, there are
consequences
for that engineer and most likely everybody that works for him or her.
Computer scientists, by contrast, have no equivalent professional
program. If they are lucky, they get to attend an ABET school for
computer science, but that is about it. Until recently, if they screwed
up, these computer scientists just went back to their computers and
published a patch for software that should have worked in the first
place. There are no consequences for building bad software, no outside
organization that can uphold community standards as some do for
professional engineers, doctors and lawyers.
Don't get me wrong. Software developers have created some beautiful
pieces of code over the years. There are, perhaps, an infinite number of
examples you could point to that would make you say to yourself, "Wow,
that is amazing." Off the top of my head, here are three relatively
recent examples: the
Google search
engine, the
WolframAlpha
knowledge engine and the World of Warcraft massively multiplayer
online role-playing game (
MMORPG). For you
gamers out there, you know I had to slip in a game for my list.
Here is the rub. Even though we have built some amazing automation over
the years, we still cannot eradicate the most basic of security coding
errors: the "buffer overflow." This problem and others like it have been
around for 50 years because they are "too hard" to fix. Wait, that is
not correct. We absolutely know how to code without introducing buffer
overflow errors. Every college student in CS-101 is taught how. The
problem is that, as a profession, we do not have the will to enforce it.
Tell that to the NASA engineers who put people on the moon and brought
them back safely.
Thus, you can see my embarrassment. On one hand, we put people on the
moon. On the other, we still have buffer overflows. Perhaps the computer
scientists of the world, me included, could raise our sites a bit.
As Sean says, there is hope. It is ironic to me that we might have
Microsoft to blame for any success in this area. Its
Trustworthy
Computing Security Development Lifecycle, although not perfect, is
the model for the industry. Indeed, Adobe adopted similar practices
about two years ago and is working to get it right. Gary McGraw's book, "
Software
Security: Building Security In" is a treatise on best practices
that software houses and internal software development programs can use
to improve their secure coding practices. (By the way, Gary works in the
building adjacent to ours in Virginia. I met him at the
FS-ISAC
conference last year). All of this is a long way from passing the
Principles and Practice of Engineering Exam for computer scientists, but
it is progress.
As
Bruce
Schneier said in 2002, "[C]omputer security is at a crossroads. It's
failing, regularly, and with increasingly serious results." The Toyota
example is just the latest and probably the most obvious to the general
populace. Eight years after Schneier's blog and 50 years after computer
programming began in earnest, we still have not figured out how to
legitimize our profession.
(No Comments)
