So, what does HML actually stand for? It stands for "High Medium Low". High Medium Low in a sense of looking at "How can you prioritize issues, how can you prioritize vulnerabilities and threats in your environment?" Many organizations actually use propriety mechanisms to do that prioritization. You might have come up with your own vehicle of prioritizing. Other organizations actually use industry standards like CVSS, for example. CVSS stands for "The Common Vulnerability Scoring System". And, although these ways of prioritizing are actually good baselines, what they don't allow you to do is actually look at your context to your organization and mapping those threats specifically to your environment. So you may want to look at a few other ways of prioritizing and having a little more context around your vulnerabilities and issues in your organization that would help you make more sense and take better action.
So let's take a look at some of those considerations. For example, you may want to look at your assets, and looking at the criticality of those assets - criticality as in, "Is this asset more important than this other asset?" For example, you might have financial data like your ERP systems with your customer information residing on this asset which is probably more critical and more important than your fantasy football leagues of your colleagues at work or your cafeteria booking systems. So take that into consideration, the criticality of your assets.
Another aspect might be the age of vulnerabilities. We're constantly bombarded in the news with the latest APTs and the latest zero days. And, although these can cause a lot of harm to your organization, the reality is that the majority of APTs and zero days actually don't impact a lot of organizations. So, you might actually want to take the reverse approach of looking at the age. So, the older a vulnerability is, the more likely it is for an attacker to potentially write an exploit that can do harm to your organization. So take a look at that as well, as a consideration.
Thirdly, there are mail records. Mail records are prevalent. They're all over the place. They can do harm to your organization. But the reality is that there's only a very, very small number vulnerabilities that actually trigger these mail records. So if you're able to identify this very small number of vulnerabilities, the likelihood of you preventing malware attacks from happening just expands exponentially. So you can reduce a lot of risk by looking at these very few vulnerabilities.
Lastly, do you have potentially compensating controls in place in your organization? For example, you might have your firewalls configured in a way that would prevent vulnerability from actually being exploited. So take a look at your compensating controls to determine the likelihood of a vulnerability actually being exploited. So, you don't always have to patch, you don't always have to immediately remediate. A mitigation strategy might be a good approach for your organization to eliminate some of the risk and to help you prioritize what you need to fix and focus on first. So what we would call all of these elements together is "Real Risk", risk that in relevant to your organization that is actually contextual to your environment. And if you can use "Real Risk" to help prioritize, you can move from HML to security heaven.
So that was it for today's session. Thank you very much for joining, and we look forward to welcoming you again for one of our Whiteboard Wednesdays. Thank you.
