Security and maturity dashboards (2/4)
This post follows a previous post on the topic of SSI dashboards.
In the previous post, we saw that dashboards are primarily used for management or communication purposes, but also that there isn't a single type of dashboard, but rather a multitude depending on their objectives. Finally, we presented the concept of a high-level, risk-oriented dashboard, adapted for reporting for information security governance.
This type of dashboard is actually quite rare; the main obstacle being the required level of information security maturity. Indeed, a dashboard is an aggregate of indicators, themselves based on metrics constructed from collected data. For it to be useful, it is therefore essential to have relevant indicators, and thus to have clearly identified one's security needs as well as how to address them in technical and organizational terms. All of these elements require a minimum level of security maturity, which is far from being achieved by all information security management approaches.
On the other hand, certain information essential for constructing relevant indicators is not always available due to a lack of structure in the information system and IT processes. This is the case, for example, with asset inventories (hardware, software, etc.) or risk and vulnerability classification criteria. Without this information, it becomes difficult to assess the proper implementation of measures across the system or to quantify a risk or exposure to a threat.
Furthermore, for a dashboard to be useful, it must be fed with data at a frequency that allows it to show changes and trends over a given period. If the various metrics are too complex to obtain, data collection is likely to be delayed or simplified, compromising the dashboard's consistency and therefore its long-term usefulness. Establishing reliable data collection methods, following a well-defined procedure and frequency, at an appropriate cost, also requires a certain level of expertise.
Faced with these problems, the easy solution might be to use the available information to create a dashboard. This includes statistics provided directly by security solutions, which are very tempting… but unfortunately, they are not always very relevant, or are even biased. Indeed, what does the number of blocked viruses represent? What should be inferred from a change in this number? An increase in the number of viruses or in the effectiveness of the solution? If time must be invested in developing a dashboard, it's best to ensure that the indicators provide useful information.
Despite the difficulties mentioned earlier, it would be wrong to believe that the use of security dashboards is reserved solely for organizations with a very high level of security maturity. On the contrary, this tool can contribute to strengthening it, particularly by facilitating the implementation of a quality approach. Developing the dashboard will first require clearly defining the fundamental objectives to be achieved. Some of the data collected to populate it can be reused within an internal control process that is sometimes lacking. Providing relevant indicators, understood and accepted by its users (technical teams, management, etc.), allows for the establishment of a constructive dialogue based on factual elements. It unites teams around concrete objectives and actions that will eventually no longer be the sole concern of the CISO. Finally, the evolution of the indicators throughout the dashboard's lifespan will reflect the progressive achievement of objectives and the improvement in the level of security. More demanding indicators will set new areas for progress, thus contributing to the implementation of the virtuous circle of any quality approach.
In the end, we realize that while the issue of SSI maturity is strongly linked to security dashboards, it does not constitute a hindrance to their use, but on the contrary, an appropriate use of indicators can greatly help to build and support a security approach, the raising of the security level will bring about the raising of the security level.
In our next posts, we will focus on the heart of the matter, namely the choice of relevant security indicators and the pitfalls to avoid when setting up a dashboard.
The next post will deal with the development of dashboards.
