Most of us have to generate recurring reports for the state of security, system uptime or general performance at our respective work places. Recently I've had to review a fair number of monthly reports from different sources and I'm always on the lookout for great ways to steal ideas from others and claim it as my own, er, learn and adapt from. I thought I'd share some observations on what I liked and what worked for me. One quick note; these were all from the private sector, so I haven't reviewed any government or public sector reports but the theory is hopefully the same. Rather than suggest some sort of universal template to fit every situation, I've observed applying the concepts of these four words to reporting. Using these concepts correctly just made being able to effectively understand and absorb the information so much easier:
Clarity Know you audience and write the report for them so apply the correct level of terminology, detail and as general groups think: your peer group, your boss, management or the general public. Consistency How can someone review previous or future reports without the same points of reference? Using the same template, with the same headings for the same recurring report makes it a breeze to see trends and the reader gets use to what to expect to see. Concise As technical people we love the details, but those recurring reports many not want every bit of detail, so summarise. You can refer to data, but sixteen pages of eight point, densely compresses text of server alerts messages is hard to read, let alone understand. Colourful This isn’t a reference to fruity language, although a smattering of four letter words will get the reader’s attention but for all the wrong reasons. I’m, of course, meaning those eye catching images stuffed in to reports to make assimilating complex data simple and quick. Have to be a bit careful with this, but good use of colour in tables or charts can draw in the reader. Well executed charts and tables can make absorbing complex data much easier and get across points very quickly. Use clashing colours or, just as bad, tones that blend in together making impossible to work out what’s happening are annoying and distract from the reader’s ability to understand the report or drain the will to continue through it.
Wrapping up, take pity on those you’re writing a report for and try to avoid making it one of those government forms Ph.D’s struggle to comprehend. A book that I really enjoyed reading was from Jon Moon [1], an English author, who is determined to rid the world of confusing, poorly written paper work of all ilks.
[1] http://www.jmoon.co.uk/book.cfm Chris Mohan --- Internet Storm Center Handler on Duty |
Chris 105 Posts ISC Handler Oct 25th 2011 |
Thread locked Subscribe |
Oct 25th 2011 9 years ago |
Along this line, I'd love a post/discussion on what metrics are useful to publish as a report on a weekly or monthly basis. Malware infections? Time to remediate infected machines? There has been disagreement amongst peers on the most useful routine reports to provide and I'd be interested in what SANS folk have to say on the matter.
|
Anonymous |
Quote |
Oct 25th 2011 9 years ago |
having to write many a report these are great insights and you've highlighted the problem with using acronyms, which is them not being defined before it is supplied/identified, but I wouldn't agree with trying to avoid their use.
an acronym can make the writing and flow of a report more succinct, especially if you have to highlight a particular system/solution/issue numerous times in the same statement. no one likes to continually read the same words over and over again. the use of an acronym can help to break up the redundant rhythm of a particular paragraph or statement making for a better reading experience. |
SonofSpiff 2 Posts |
Quote |
Oct 25th 2011 9 years ago |
Which metrics you include in a report may also be influenced by whatever you deem as a particular risk to the organization. For instance, I've got net-snmp reporting the number of log messages matching certain regex patterns and then graph those with cacti so I can show the number of login failures on an ssh server (I show incorrect passwords and incorrect usernames as separate graph items). It's a way to remind management of the need for things like 3rd factor logins.
I also graph the number of packets rejected by firewalls at various locations just to track trends (and I check them frequently just to look for anomalies - a big spike in rejected outbound traffic may mean a compromised or mis-configured system, for instance). |
Brent 123 Posts |
Quote |
Oct 25th 2011 9 years ago |
One important metric we track is number of machines with current definitions. It almost always gets overlooked, management thinks that if they have AV on all the systems, everything is good.
Another metric is how many machines currently on the network have recently checked into the AV console. If the machines are on the network but not currently reporting in, again, they can't receive updates, can't report that they're (possibly) infected, and can't be remediated remotely. |
Brent 1 Posts |
Quote |
Oct 26th 2011 9 years ago |
Sign Up for Free or Log In to start participating in the conversation!