Slashdot Mirror

← Back to Stories (view on slashdot.org)

Security Analysis Reports for Managers?

Posted by ryuzaki0 on from the where's-that-universal-translator-when-you-need-it dept.

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

3 of 33 comments (clear)

  1. here is what I do.... by cavtroop · · Score: 3, Interesting

    I sort the report by severity, and calculate statistics from that. the first few pages are the 10,000' view - i.e.: we have 7 systems with level 5 vulnerabilities, 38 systems with level 4, etc. etc.... Then, on the following pages, I break down the report into the nuts and bolts - that lets the managers that want just the overview to stop reading after the first few pages, and provides detail for the managers that want it. is that what you are looking for? pretty basic, actually...

    1. Re:here is what I do.... by SatanicPuppy · · Score: 2, Interesting

      Absolutely. Put in an executive summary, and you can pretty much fill the rest of the report with hardcore tech jargon. Generally I put in a summary page, then a mid-level summary that is light on the jargon, and then I just append a slimmed-down version of the raw data to the end.

      It generally meets with approval.

      --
      ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
  2. Re:To answer your question by Anonymous Coward · · Score: 1, Interesting

    The Problem is that
    * 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 important if even non-trained people like them can understand it; your advantage is that you had the time to read some minor low-level details about your work; apart of this, they could be doing it themselves. But then something goes wrong. Then you tell your managers you told the risks. They cover by telling you didn't go into enough technicalities, so they wouldn't grant the OK under sounded ground (and rightly so: you really can't simplify your bussiness; you just can cover some facts that sooner or later will return to reclaim you their proper place). Anyway, it's your fault, not theirs (it's not an imagination. Don't you remember the "powerpoint-slides-and-the-shuttle-goes-boom" case?)
    * Go into the deep technicalities and in four minutes your managers will tell that's not what they were looking for, it's too boring and anunderstandable so you are at fault *and* nothing goes approved ...but since its your fault, not theirs, anything awry that may happen is still your head, not theirs.

    There was the case about the pharaoh asking Euclide for a shortway into learning maths. There's no shortways, not even for kings, Euclide answered.

    Well, I'd bet that should be your answer too.