Slashdot Mirror
Security Analysis Reports for Managers?
chaffed asks: "I've been tasked with translating a security analysis report for our powers that be and ultimately for our auditors. The manager's are not technically savvy, but they aren't PHBs, either. To what depth should one descend into Information Security and Technology topics? More generally, how would a technical person relate to a non-technical person? Should all technical terms be defined or just cryptic ones? What assumptions are reasonable to make about the reader (Non-Technical Managers)? What physical format should an analysis take, bulleted points or in depth discussion?"
Make it as graphic as possible. I mean it literally. If there's a way to do it in a chart, do it. Managers also tend to read summaries first, and more often than not, only. So make sure the summary gets the point across.
They don't care about technical issues. They care about cost, threat level and benefit. Make sure you cover that bases. Don't try to construct too many "if" sentences, since they'll be brushed away with "won't happen, don't care" too easily, even if that "if" does actually mean "when".
Explaining terms is fruitless, imo. They will skip over the parts they don't understand rather than look up terms in a glossary. The same is true for a lengthy prolog trying to explain terms. And don't try to create hyperlinked (or otherwise electronic) documents to make looking up things easier. They'll just print it and your time is wasted.
As said before, they don't care about technical details. They don't care where a potential attacker comes into the system. They care about the questions:
How do we prevent it?
How much time (in manhours/mandays) does it take?
How much does it cost?
Make sure you cover those 3 questions. Preferably in the summary.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Apart from poor formatting and errors in spelling etc, I have to agree with this.
Having done many such reports (as an independant "audit" process), I just have to add one thing that goes against the general flow of the postings so far. Don't dumb-down the report - people who have management roles are generally literate and have active brain cells. They need to make their own call on how important things are, they are looking for your narrow technical viewpoint and will add that to the other narrow viewpoints from the rest of the organisation.
So you need to make the important issues clear and upfront and with some kind of cost of not-doing. I've never written a report with $ costs, just in expected down-time to fix etc. I've always found this quite effective in getting the point across - there is the list of critical must-do's and then the should-do's with rough time-and-materials costings.
I think most of my "should-do's" were done and the must-do's scared the pants off some of the managers - on the basis that the costs for the lower priority items were so high.