Intro
This is part two of a two-part blog post series that aims to simplify what DORA compliance entails from a TVM perspective and offer actionable steps to get ready for DORA and fortify your vulnerability management program over the coming weeks.
If you haven’t read part one yet, you can do so here: https://www.cytidel.com/post/dora-compliance-and-your-threat-vulnerability-management-programme-part-one
Tips to Get Your TVM Program DORA Ready for January 2025
Start with the Vulnerability Management Policy
If you’re still classifying your vulnerabilities by CVSS and reporting on a 5x5 matrix, you may want to re-evaluate how you’re measuring risk. Just note, you’re not alone as this is a massive problem in the industry.
CVSS is a great data point when used correctly, but most companies don’t know what it is. CVSS is a measure of impact. Nothing to do with likelihood. Doesn’t take the context of your organisation into account. Doesn’t know whether there’s an active exploit available. There’s no context, therefore you’re making poor decisions when this is your key data point.
Check your scanner coverage
Verify if your vulnerability scanner is identifying vulnerabilities across all assets within the organisation. This may require multiple scanners, and potentially from different vendors, but it’s critical to ensure you have visibility of risks across the organisation. You can’t protect what you can’t see.
Review your vulnerability assessment and prioritisation process
After updating your policy, this should be easier. It’s important to clearly define how you rank and prioritise vulnerabilities for remediation. When a vulnerability meets the threshold set, what is the process to initiate a remediation effort?
Many organisations will utilise their existing ticketing system to raise a request for remediation, but make sure you include sufficient information for the engineer on the receiving end to actually take action. All too often, these tickets are either rejected, closed without success, or ignored because there’s either not enough detail in the ticket, or there’s simply too many “critical tickets”. Be considerate of the IT engineers deploying these fixes, as they’ve been struggling for far too long with every security risk being sent their way requiring urgent attention, which is often unrealistic.
If you don’t know where to start with prioritisation, here are a few options:
Start with EPSS and CISA KEV
Exploit Prediction Scores (EPSS) provides an estimate on how likely a vulnerability is to be exploited in the next 30 days. This is an open source data feed that is updated every day
CISA Known Exploited Vulnerabilities (KEV) provide a list of known actively exploited vulnerabilities. If any of these are on your network, get rid of them. Fix them. Turn it off. Whatever you decide, they’re higher risk than a lot of the others that are appearing in your vulnerability scans.
Pros:
These feeds are free and provide a good starting point
Cons:
These are lagging indicators, often only updated after exploitation has been detected on mass. By then, it may be too late.
You will also need to integrate these feeds into your tools and reports if they are not already provided by your existing scanning vendors.
Purchase a vulnerability intelligence feed
Vulnerability intelligence feeds provide a strong source of enriched information relating to vulnerabilities, available exploits, and emerging risks. Mapping this feed against your vulnerability scanner’s results can enhance your understanding of the overall risk profile, and enable better decision making
Pros:
Relatively inexpensive if considering the likes of Cytidel's Vulnerability Intelligence Feed.
Faster delivery of vulnerability information, significantly enhance your ability to identify vulnerabilities most likely to be exploited.
Improve risk reporting by using specified metrics and scenarios your business cares about rather than CVSS scores.
Cons: You will likely need to manage this correlation in-house. This can be time consuming, and an expert in vulnerability management may be required to fully interpret the data / generate your risk reports
Consider automate the heavy lifting by talking to Cytidel (shameless plug but it’s our blog so it’s allowed)
Cytidel work with customers to elevate their Threat and Vulnerability Management Programmes. This includes everything from providing access to our advanced vulnerability intelligence, to integrating with your existing vulnerability scanners, right through to generating simple reports senior leaders and boards will understand.
Pros:
Automated vulnerability management assessments meaning no more pulling board reports together from multiple spreadsheets and trying to work out what all this data means.
Clear understanding of your organisation’s risk profile so that you report on your organisation’s posture rather than the number of generic vulnerabilities present.
Easily identify the risks most likely to be exploited, enabling better decision making and resource prioritisation
Stop drowning in vulnerabilities and get the insights you need out of your existing stack. We make it easy for you to focus on what matters without needing to replace your existing technology or scanners.
Cons:
There’s an onboarding phase so it’s not a “switch it on and all my problems go away”
You may need to update policies and processes if they are not modernised already
Your first report might scare you when you see which systems are exploitable. But it’s better to know now and fix it rather than find out the hard way.
Penetration Testing
Rather than the basic penetration testing many organisations have become accustom to running, DORA now requires Financial Services organisations to operate a Threat-Led Penetration Test (TLPT). How this differs from a standard penetration test, is in how you plan for it. The traditional approach is to hire someone for x days and see how far they can get. Simple, and often not effective due to the amount of reconnaissance time required.
TLPT involves understanding the organisation, and the threats facing that organisation. When developing the test plan, you will select specific use cases to exploit known threats with a real possibility of targeting your business.
This might include looking at your vulnerability scans, identifying the vulnerabilities with known exploits, and using those as the starting point for the penetration test. You may also look at specific threat actors, the vulnerabilities they chain together, and identify common attack patterns you may see in a real-world attack against your business.
These types of penetration tests are far more effective, more likely to successfully produce meaningful results, and ultimately provide you with clear risks requiring immediate attention to mitigate the impact of such an attack in a real-world scenario.
An important fact to note here if that the regulation allows for you to run these tests using an internal team, however you must use an external Threat Intelligence Provider.
Define your risk acceptance process
Sometimes, you simply can’t remediate a risk. It happens. This might be for various reasons such as the system is being worked on, a stable patch not being available, dependencies on other work being completed first, inability to schedule downtime, or the engineer that knows how to restart the system is on holidays (yes, I’ve heard this one before!).
Whatever it might be, make sure you have a process to feed these risks into your overall Governance, Risk, and Compliance (GRC) programme. Recording, understanding, and reporting on these risks is crucial to maintain oversight over ICT risks, and reporting these up to senior leadership is no longer optional. Remember, these new regulations mean business leaders and directors are now legally responsible for their ICT risk management programme.
With that in mind, the way GRC teams report ICT risks must be clear and concise. Most board packs we see include a 5x5 matrix when talking about vulnerabilities and simply shows how many vulnerabilities exist within the business, or worse, risks posed by vulnerabilities aren’t reported up the chain at all.
Both of these are bad for different reasons:
The matrix shows a number of risks which is effectively meaningless. There’s no context and 95 times in 100, this number will have gone up since the last meeting. Business leaders become desensitised to these numbers and struggle to correlate value to their risk management investments when the metrics we use to demonstrate these risks continuously appears to get worse. What does this lead to? No more funding for the programme because there’s no clear value.
In some cases, board packs and security reports don’t list key risk metrics – often due to the security team not having the right visibility needed to report them. We’ve already discussed how exploitation of vulnerabilities is the top initial access vector for data breaches, so why leave such an important security metric off our reports? If business leaders will now be legally responsible for their ICT risk, they’ll certainly want to understand the risks they are living with, and which ones will have funding allocated to reduce the risk.
How to report vulnerability risks
I’ll leave you with this point, but it’s an important one. When defining your risk management programme, agree the metrics you want to report, and how you want to report them.
Understand what makes the most sense for your business, but also what will be understood by the people ultimately responsible for these risks.
This might be represented with number of exploitable vulnerabilities, likelihood of a breach from a known risk (I say known risk because there’s always zero days and emerging risks that can’t be predicted but can be minimised with good security practices), or simply number of applications breaching our agreed risk tolerance.
If you’ve found this helpful and would like to continue the conversation further, feel free to get in touch via our contact form and a member of the team will be in touch.
Disclaimer: this blog is intended to provide tips for enhancing your vulnerability management programme and does not constitute legal advice.
Comments