Six Ways to Increase the Business Relevance of Risk-Based Reporting
When it comes to vulnerability and risk reporting, there’s a significant disconnect between what business stakeholders want and what the vast majority of security assessment and tool vendors provide. All too often, tools generate dense reports full of technical minutiae while third-party vendors provide pages awash with red, green and amber colors. Unfortunately, business stakeholders have little insight into the relevance of these findings in the context of their day-to-day operations and what correctives exactly to prioritize. This needs to change.
As technologist and security professionals, here are six actions we can and should take to close the relevance gap:
Understand Who You Are Working For
Any Information Protection, IT security and Risk organization – internal or external – needs to understand the business they are trying to support. If you only have a vague understanding of the business and their industry then you are not partnered properly. Without this fundamental, foundational knowledge, risk reporting is always going to be generic and of limited value to an organization’s senior business stakeholders.
Educate Vendors and/or Security Leaders About What it is You Need
Too often product vendors fashion software tools based on what they think we need rather than asking us in the security community what we really want for businesses we serve. However, instead of pointing fingers, we also have to look ourselves in the mirror as many security professionals lack the skills to communicate our specific requirements. So have a frank conversation with your vendors. Likewise, internal business and security stakeholders also need to closely collaborate so needs are communicated.
Start With The End Game
Most of us are guilty of zeroing in on a platform’s feature set, inspection capabilities and how well it can identify vulnerabilities. Executive-level reporting capabilities are typically an afterthought. How about we switch that around and begin with the end requirements? Even better, how about we involve business stakeholders at the outset – when we are vetting capabilities and services? By getting the business side of the house engaged upfront and perhaps even participating in pilot programs, risk reports are likely to be much better at reflecting their needs.
Provide Business Context
Rather than provide pages of technicalities, reports should provide risk in a broader context relative to the specific business and the assets’ deployment model. What makes executives nervous at night? In short, disruptions to business operations. Not being able to process transactions? Not being able to schedule production on a factory floor? As security practitioners, we should want to know so we can customize the tools we use to assess threats and vulnerabilities in these terms. Rather than focusing solely on Common Vulnerabilities and Exposures (CVE®), how about reports show by business criticality where budget should be deployed to get the most protection? Because we seldom have the budget to fix everything, reports need to be contextualized for better, more informed decision making.
Only Select Highly Customizable Tools
Only select tools that you can fashion to your environment and needs. Too often tools have their own vernacular and that is forced on stakeholders. Improvements could be made by reporting risk in a way business executives can understand and minimizing the “security speak” that so many of today’s tools produce.
Don’t Report The Irrelevant
Security and risk assessment reports are typically not only sizable, but also extremely detailed. When dealing with business stakeholders, only the most relevant themes should be reported on. Please, no more pages of technicalities and meaningless raw scores that lack any context. How about these reports highlight a few areas of concern where there is a high risk of exploitation and explain why this matters to the business?
All of these steps are relatively easy to implement and once they have been worked through, your risk based reporting will not only be more relevant, but far more impactful. It may even result in additional funding because business stakeholders can finally understand the very real ramifications of security vulnerabilities in the context of the day-to-day running of the business.
Explore more blog posts
Part 1: Ready for Red Teaming? Intelligence-Driven Planning for Effective Scenarios
Take time for dedicated planning and evaluation ahead of red team testing to prepare your organisation for effective red team exercises.
The Strategic Value of Platformization for Proactive Security
Read about NetSPI’s latest Platform milestone, enabling continuous threat exposure management (CTEM) with consolidated proactive security solutions.
Backdooring Azure Automation Account Packages and Runtime Environments
Azure Automation Accounts can allow an attacker to persist in the associated packages that support runbooks. Learn how attackers can maintain access to an Automation Account.