Security Analysis Reports for Managers? 33
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?"
Resources (Score:3, Funny)
To answer your question (Score:1, Funny)
Re:To answer your question (Score:1, Interesting)
* Managers
* Like
* Your ass at stake
The only reasonable approach would be:
"I'm the security officer. You can be confident about me, so I'll give you no technical explanations *at all*; just what has to be done, or you can distrust me; then you should fire me and hire a new one of your confiedence".
Really, it is the only good approach.
Now: you dont believe it and:
* Go into a phb-ized version of your technical analisis. One one hand, they will disrespect you. Your job can't be so importan
Other method- PRSC (Score:3, Insightful)
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.
here is what I do.... (Score:3, Interesting)
Re:here is what I do.... (Score:3, Interesting)
It generally meets with approval.
From experience (Score:5, Insightful)
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.
Re:From experience (Score:3, Informative)
In that case, if you mean "when that happens..." write it that way. Don't say "if" because they'll think it will never happen. "When" tells them it will happen, sooner or later. Say what you mean, not almost what you mean.
Re:From experience (Score:2)
"They don't care about technical issues. They care about cost, threat level and benefit.
Exactly.
However, I want to change around what you should present. Present the following:
1) How much does it cost us if we do nothing
2) What do we need to do to eliminate or reduce the cost of 1.
3) How much will step 2 cost. List both costs for eliminating step 1, as well as costs for reducing the majority of 1.
And to stress: SUMMARIZE, SUMMARIZE, SUMMARIZE. Prepare to back
Re: (Score:1)
To put it another way (Score:2)
Deliver a risk analysis rather than a security analysis. It's what most people really want and it's what HIPAA clients explicitly need according to statute.
Also from experience (Score:2)
> How much time (in manhours/mandays) does it take?
> How much does it cost?
I think that some other things are more important to a manager:
What is the risk to the business? (regulatory violation, monetary loss, etc.)
How much will a breach cost? (fines, downtime, system replacement, recovery, lost business, loss of competitive advantage)
What is the risk of occurance? (how likely is a breach to occur?)
In all honesty (you may disagree), I think these questions come way before tho
In general; (Score:5, Informative)
But in general;
>To what depth should one descend into Information Security and Technology topics?
Enough to make it clear as to why the topic is important and what impact it makes on the company. And not too long to make people bored.
> More generally, how would a technical person relate to a non-technical person?
With clear accurate words and descriptive and varied sentences. Interesting examples are good too. One of the best documents about a technical/complex topic I've read is at http://www.torontoinquiry.ca/ [torontoinquiry.ca] It was a long and boring inquiry about computer leasing, goverment procedures and its long and detailed. But reads like a trashy novel and very accessable and understandable. I enjoyed reading it and afterwards I felt I knew what had happened.
>Should all technical terms be defined or just cryptic ones?
Every single one of them in the glossery.
>What assumptions are reasonable to make about the reader (Non-Technical Managers)?
That they have at least a high-school level reading level and they need to know the information contained in your document.
>What physical format should an analysis take, bulleted points or in depth discussion?"
Yes. Use what ever you think you should need to use to clearly covey information. Formatting and layout are just tools.
I think Dilbert explained it best (Score:3, Insightful)
It's Security (Score:2, Insightful)
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
World's vaguest Ask Slashdot. Evar. (Score:2)
General plan here (Score:5, Informative)
First of all, the executive summary. "We are mostly secure/insecure, with (n) critical action items. Of these, (x) can be implemented with little effort or cost, (y) will require substantial effort and/or cost, and (z) will require a fundamental change in the way we do business." Actually, this breakdown might be a bit detailed for an ES. Yes, really.
Then provide the background: "The internet is a scary place. (n)% of security breaches come from inside. Personal laptops can sniff unencrypted traffic. Passwords are easy to hack. Security breaches can undermine us in some specific way, or cost $xxxMM. etc.."
Now the specifics: "Preliminary analysis of our network has uncovered some critical/significant/minor security flaws. These are blah, blah, and blah, in increasing/decreasing order of severity/cost-to-fix. A detailed analysis of these flaws is as follows:
(flaw1)
(flaw2)
(flaw3)
(...)
The analyses should be broken down in a fair amount of detail, with technical terms defined in a glossary at the end of the report. Each one should contain the cost-to-fix and the cost-of-breach if possible, as well as the likelihood of a breach. Having a DMZ mail server taken down by hackers might be a huge pain in the ass, but ask (i)will it actually cost the company that much money in lost productivity, (ii)how likely is it to happen, and (iii)how much will it cost to improve? Alternatively, a disgruntled admin can potentially destroy your data centre--downtime at (d) dollars/hour, plus the cost of lost data since the last tapes. A third alternative is loss of proprietary data to a competitor, which might be bad, or might be enough to shut the company down permanently. Be VERY CAREFUL here, though: If you're writing a security analysis, then don't stray into trying to build an entire DR plan. Seriously. Don't.
Summary: Exactly that--summarise the detailed analysis, ordered by the the cost/benefit ratio. Make sure that the difficulty of implementation or added risks are considered as well. Remember that at this point, you're just summarising the data, not yet doing the...
Recommendations: "Based on the above data, we recommend implementing blah and foo immediately. These provide some/significant improvements in security, can be achieved with a minimum of effort or cost outlay, and carry little/no risk of introducing new problems. In the 1-3month timeframe, 3-6 months, 6-12..." That sort of thing.
Then of course, the glossary.
Don't ever forget: Security weaknesses are the cost of doing business. For example: Moving from telnet to ssh provides a significant benefit, and allows you to keep working. Shutting off all interactive logins doesn't provide much further benefit, and most likely substantially interferes with the company's ability to do work. Limiting ssh access to a few client boxes may provide a security benefit (hard to quantify), but may also increase the administrative overhead enough to make it not worthwhile. All managers and techs much understand that security isn't an absolute goal--it's a degree of risk acceptance. Eliminate all unnecessary risks (security or otherwise) be aware of all the necessary ones, and mitigate the risks as much as possible.
Taking that example (Score:2)
This is where technical depth comes in. The next cheap big improvement to suggest to someone running ssh is to disable password authentication (especially given all the brute-force login attempts we've seen). Then everyone
Re:Taking that example (Score:2)
This is definitely a win from a security point of view, but the cost analysis is a tough one. How much does it cost for the keyfobs, the software to manage them, and the time involved in tying authe
Risk versus CounterMesure cost (Score:1)
Re:Risk versus CounterMesure cost (Score:3, Insightful)
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 viewpoi
Probability, avoidance, resolution (Score:3, Insightful)
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 [angryflower.com] is unprofessional.
Re:Probability, avoidance, resolution (Score:2)
That's basically the formula laid out in Fight Club [imdb.com].
If it costs
Think beyond a 'security gap' (Score:2)
I see too many non
Ever noticed how much security is like dentistry? (Score:2)
And none of it's any fun to the patient.
OR (Score:1)
But maybe that's just me.
Re:OR (Score:1)
AC Suggestion (Score:1, Insightful)
And on points you do not feel completely certain, let them know that you don't know. This often
Nice timing... (Score:1)
You can be technical... but don't fo
I happen to write these reports every so often... (Score:3, Informative)
Go here and read: sans.org/rr [sans.org]
They want a few powerpoint slides worth of information in a doc/pdf really... Lots of pictures and graphs. Highlight the risks and list the tasks needed to mitigate them.
Try to cover your own analysis of the products you have in place to protect your company.
I hope you have at least some idea of a plan for each of these areas...
you should... (Score:1)