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.
"Well, something that you could never comprehend conflicts with something that you'd never understand."
Nerd: Derogatory term typically directed at anybody with a lower Slashdot ID than you.
It's security, thus you must make the most important points (i.e. those of greatest risk) the most prominent in any report and make them easy to understand. It'd recommend first bullet-pointing each security aspect in categories such as severe, medium and minor issues.
After this categorisation, it would be wise to describe each point in more detail in an after section using non-technical language, but making it obvious what the implications of ignoring these security issues could be. This should again, be priotised on the most major of these points.
If a manager is unable to understand a point or worse misunderstands, he may consider it trivial. And obviously, this could be disasterous over the long-term.
Security is a complex business, but the effect each potential problem has on an organisation can be summed up in simple terms.
Probability: What is the chance of a particular problem actually happening?
Avoidance: What would it take to avoid/reduce the chance of this problem occurring? How much will this cost? What will the effects be on productivity? What about morale?
Resolution: If the problem does happen, what will it take to fix it? How much will that cost? Downtime? Legal liability? Bad press?
Those are the three main variables a manager needs in order to decide whether to take action on a potential security problem. For example, if something costs a lot to mitigate, but is very unlikely to happen, then it probably won't be worth doing anything about unless the costs for fixing the problem are extreme.
You only need to go into the technical stuff in order to explain the above. You don't have to explain how the attack works beyond its immediate ramifications for avoidance etc. In-depth discussion will be skimmed, so break stuff into bulleted lists, charts and tables wherever it makes sense to do so, with a clearly marked summary for each section, so even the laziest PHBs will have an overview.
Oh, and not specifically work related, but if you are going to be writing stuff for other people to read in a professional capacity, then making obvious grammatical errors is unprofessional.
Bogtha Bogtha Bogtha
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.
Use bullet-point list, but elaborate on each. Keep it succint and focused on managerial point of view, however - you want to get points across, not show off your depth of knowledge. Analogies help, but make it clear that extending them is dangerous. Little bit of scare tactics (with stats, news clipping, etc.) can be helpful on points you feel strongly, but this is risky and should be used sparingly if at all.
And on points you do not feel completely certain, let them know that you don't know. This often times actually boost the level of confidence they'll place on you.
Actually, the above applies to most situations where you are making a presentation, not just tech-to-management.
The other method is a rather simple table:
Problem, Risk, Solution, Cost
This is what managers actually care about. A one sentence description of the problem, the risk of missing or stolen data as a percentage risk, a one sentence description of the solution, and the cost of that solution. That gives them what they need to know to work up your budget- and you implement what they want.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.