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?"

Comments

In general;

[GoofyBoy]

Everyone is different so I would take a manager and ask for feedback on a draft.

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/ 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.

Re:From experience

[techno-vampire]

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".

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.

General plan here

[swordgeek]

Here's how to write it as if you were an auditor. When it gets to the auditors, they'll eat it up.

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.

I happen to write these reports every so often...

[Cybersonic]

Ill make this short, informative, and somewhat dumbed down, just like the type of report they are looking actually for.

Go here and read: sans.org/rr

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.

• Network-based Firewalls
• Network-based Anti-Virus
• Network-based IPS/IDS
• Network-based Anti-SPAM
• Host-based Firewalls
• Host-based Anti-Virus
• Host-based IPS/IDS
• Host-based Anti-SPAM
• Patch Management
• Vulnerability and Application Assesment
• VPN (IPSEC and/or SSL-based)
• Authentication (LDAP, Radius, 2-Factor, etc...)
• Anti-SPAM
• Event Management
• Logging Servers
• Content Filtering
• Wireless Security

I hope you have at least some idea of a plan for each of these areas...