Skip to content ↓ | Skip to navigation ↓

A couple of weeks ago, I asked about what people are putting on their infosec dashboards to help communicate with the rest of the business, and I’ve gotten some interesting feedback.  I’m still gathering data, but thought I’d provide you with an in-process snapshot of what I’m learning.

I have a number of observations to share from my research, so far:

  • Where infosec reports in the org makes a difference.
    • When infosec reports into a technical executive, like a CIO, the reports tend to be more detailed and expose more of the details that security people care about, such as patching performance, application updates, MTTR statistics, open vs. closed tickets, and things like that.
    • When infosec reports into a non-technical executive (legal seems to be a more common place for infosec to report in larger organizations, for example – and Operations & Finance came up a few times, as well), the nature and level of detail changes.  I saw a few examples of reports that relate security activity to key business applications, but I also saw a lot of cost- and productivity-centric reporting in these situations.
  • Outside pressures / drivers affect what’s presented.
    • For better or for worse, when external drivers are present, the discipline and consistency around reporting increases.  I am seeing examples like infosec being involved in producing quarterly progress reports against SOX-404 objectives, reporting on reportable security incidents (PCI, FBI, EU Data Privacy Act, etc.), that often go to a formal audit committee.
    • When no outside pressure exists a number of infosec execs told me it was hard to get other parts of the business to pay attention, except where it involves budgeting or spending (cost of infosec); or when some security incident hit the exec radar, whether it happened to the company or one of its peers.
  • People will do the bare minimum if they can get away with it.
    • A lot of the responses I get sound a lot like “We just pass on our daily operational reports to my boss.”  In other words, people are doing good work on infosec stuff, but aren’t spending much time trying to figure out how to translate that into something the rest of the business cares about.  In some cases, I got the indication that many infosec execs (particularly those who rose through the ranks) aren’t confident that they know how to communicate to non-technical parts of the business.  Sometimes, this is just because it’s easier, other times it’s because they haven’t engaged with anyone else in the business to figure out what “good infosec reporting” means in their business.
    • On a related note, I just started reading a book called “How to Measure Anything:  Finding the Value of Intangibles in Business.”  I’m just getting started on the book, but it looks like it could be a useful resource in quantifying the value of infosec.
  • Sometimes reporting feels like a game of “bring me a rock.”
    • Another challenge I heard loud & clear was that it can be frustrating to figure out what to report up & out to the other parts of the business.  Many executives were hard-pressed to get much feedback from others in the business on how to improve their reporting, which parts were important, etc.  One person commented that he could probably issue the same report 3 months in a row with only the dates changed, and probably get away with it.  That is a clear sign that there isn’t a meaningful connection between infosec’s activities and the business, at least in that company.
  • Risk is getting more respect now than ever.
    • The one area that seems to be gaining traction is Risk.  A number of people I spoke with told me they are having meaningful dialog with their non-infosec peers around risk.  This seems to be an area in which all parts of the business can find common ground.  When you start to develop and articulate the linkages between “early indicator” activities and “late stage” results, the value of infosec rises dramatically.  For example, one executive is building the relationship between the availability of revenue-bearing systems and configuration hardening.  If he is successful (and I think he will be), he can provide a risk-adjusted view of how revenue generation may be impacted if their system hardening standards aren’t followed.

As I mentioned, this is a work in progress, so I’ll keep digging into this topic.  There are several ways you can become a part of this conversation, if you so desire:

If you have any good samples you can share (particularly effective ones), I’d love to see them.  If you want to email them to me, you can do so at “dmelancon at tripwire.com,” and if you want to encrypt the message here is a link to my public key.  Please include [Dashboard] in the subject line to help me organize them.

If you prefer, you can share your thoughts on this topic using the Comments function below, or you can join the discussion about dashboards on Quora (you’ll need to create a free account to add any comments).  Incidentally, there are some great thoughts on the Quora discussion from Fernando Montenegro and Robert Stucke on this topic.

@thatdwayne