Business Risk Management: How MSSPs can Create a Risk Dashboard for Clients

Many Managed Security Services Providers (MSSPs) provide risk dashboards to their clients. Not only do these dashboards provide an overview of enterprise IT risk, they should (in theory) enable conversations around what actions need to be taken with respect to risk exposure, as well as requests for services from the MSSP or increased budgets.

Regular communications will help you gain buy-in from other executives — agreement on the client’s risk appetite, and what risks they can accept, must mitigate, can transfer, or should systematically avoid. Done correctly, this dashboard makes the decisions about IT risk management accessible to all executive team members — no matter their level of technical expertise — and facilitates the communication between service provider and client in a way that fosters longer term relationships.

But how do you create a risk dashboard that empowers you to communicate an accurate picture of IT security health in a way that resonates with the business leaders in your client’s organization without breaking the bank with analyst labor?

Unfortunately, building a risk dashboard from the raw data can be difficult: you need to pull together data from a wide range of security logs, analyze it and build a risk model that gives a clear and comprehensive overview of risk in your client’s organization. In order to have the credibility required for effective and objective communication, the model has to transform complex technical data into understandable and contextual metrics, while retaining links and transparency to the underlying data sources.

Consistent Metrics — Not Hype

When you create a risk dashboard, avoid sensational latest threats or the hottest trends in favor of consistent and well-understood metrics.  While the latest hot topic will get some attention in the short run, it is a poor measure of risk to the organization or your service performance.  The client will quickly tire of the never-ending onslaught of possible breaches that have no context to their business operations.

You could adapt the dashboards you use as time progresses, in order to reflect the ever-changing cyber security landscape.  However, you should balance this with consistency in metrics and reporting. CEOs and other business leaders want dashboards that allow them to measure security performance over time, so your dashboard should display a consistent handful of metrics that tell that evolving story of your client’s IT security health and what it means to their business operations.

Avoid Making Your Dashboard Too Technical

Remember that a risk dashboard is a tool that facilitates communication between your highly technical staff and nontechnical executives within your client’s organization. Therefore, you need to ensure that your dashboard can be understood by a nontechnical audience. Even though the data that goes into creating your dashboard is likely going to be highly technical, you need to avoid inserting too many technical details into the final product.

For example, you might have one or two vulnerability metrics that you create from the number, severity and age of vulnerabilities.  Another might measure defensive activity, calculated from the volume and severity of events reported by security systems (firewall, anti-virus, etc.), and if you have a SIEM, you can show metrics that tracks alerts from correlated events.

Regardless of the metrics you decide on, you should always overlay business importance of the affected systems.  That will allow you and your client to prioritize resources and make operational decisions.

Additionally you may consider reporting on threat intelligence that is specific to the context of your client’s environment.  But, please, translate the tech-speak of that threat intelligence into business terms that make sense.

Final Thought

Many MSSPs are still experimenting with different ways of communicating data in a dashboard format, since the concept is still somewhat in its infancy. To stay ahead of the curve, focus on creating dashboards that present metrics in a business-focused context, so that people who are not security experts can use them to learn more about risk in your organization.  On the back-end, however, make sure your analysts have the tools they need to explain the metrics, should the need arise.

By taking the time to design a clear and relevant dashboard now, you can continue using the same dashboard for many years to come, improving the consistency of your reporting.