Due to the nature of the application, DarkHorse is not optimized for mobile devices. Please view it on a desktop or tablet for the best experience.
Definitions
We at DarkHorse like to think that everything we’ve done on the platform makes perfect and intuitive sense. However, even when things make perfect sense to us, for people not familiar with the insides of our minds, it’s probably worth explaining why we do some of the things we do. That’s what this page is for: explaining specific nuances of the DarkHorse model, that may or may not be intuitive otherwise.
Vulnerability / Risk Ratings.
DarkHorse rates all findings with a Risk score. This score is intended to represent the relative risk that the vulnerability poses to the organization.
DarkHorse believes that risk is informed by two key pieces of information: (1) the technical severity of an issue (e.g. how much damage could this cause, if exploited in the wild); and (2) the likelihood of exploitation. As opposed to rating purely on technical severity, our risk score provides a more complete picture that allows one to be able to more effectively prioritize that which poses the highest risk to the organization.
How the risk score is calculated is shown in the table below.
Explanation of Risk: (1) critical and extremely critical reports will never have a lower risk than technical severity (though a critical could be raised to an extremely critical if it is highly likely to be exploited), as the impact of them being exploited, however low it may be, poses significant risk to the organization. (2) All other findings may be rated higher or lower than their technical severity, depending on the likelihood of exploitation. This is designed to reflect the fact that when prioritizing what vulnerabilities to work on, a moderate finding with low likelihood of exploitation may carry a lower risk to the organization than another moderate finding that's highly likely to be exploited. Of course, this makes intuitive sense, which is why we've build our risk scoring matrix to reflect this reality.
Relative to the rest of the industry, the current dominant views on rating vulnerabilities are either:
DarkHorse believes that risk is informed by two key pieces of information: (1) the technical severity of an issue (e.g. how much damage could this cause, if exploited in the wild); and (2) the likelihood of exploitation. As opposed to rating purely on technical severity, our risk score provides a more complete picture that allows one to be able to more effectively prioritize that which poses the highest risk to the organization.
How the risk score is calculated is shown in the table below.
Explanation of Risk: (1) critical and extremely critical reports will never have a lower risk than technical severity (though a critical could be raised to an extremely critical if it is highly likely to be exploited), as the impact of them being exploited, however low it may be, poses significant risk to the organization. (2) All other findings may be rated higher or lower than their technical severity, depending on the likelihood of exploitation. This is designed to reflect the fact that when prioritizing what vulnerabilities to work on, a moderate finding with low likelihood of exploitation may carry a lower risk to the organization than another moderate finding that's highly likely to be exploited. Of course, this makes intuitive sense, which is why we've build our risk scoring matrix to reflect this reality.
Relative to the rest of the industry, the current dominant views on rating vulnerabilities are either:
- P1-P5 (Bugcrowd); or
- CVSS (HackerOne, Intigriti).
Why we don't offer managed triage.
Our perspective on managed triage is that it inherently contains a large amount of duplicative (and thereby inefficient) efforts. Of course, your mileage may vary, but this is our general take on the matter:
If you get 100 reports over the course of a year, it’s pretty well established in the industry that ~25-30% of those are expected to be valid, unique, in-scope reports.
You will have to replicate and interact with all of those reports.
It’s also unlikely that your input won’t be needed on other reports – for instance, anyone who has run a program can attest to needing to weigh in during the triage process as to whether a given report is an actual security vulnerability, or if such and such a thing is out of scope, and so on. We’ll call that another 5-10% of all reports.
So, out of 100 total reports, you’re having to engage on anywhere from 30-45% of what gets submitted. Said, differently, if you were previously operating from a place of “triage costs us $x per report”, it’s probable that the true cost was being underestimated by as much as nearly 50%.
And that’s not yet taking into account that valid reports are the most time consuming category of report. Which is to say that the remaining 55-70% of reports are made up duplicates, not applicable findings, and items that are out of scope – which are non-coincidentally, the easiest finding to triage.
When we put a lower weight those types of reports, relative to valid, unique findings, it becomes clear that while triage may touch 100% of reports, you are also having to touch at least 50% of the work.
At DarkHorse, we’re all about efficiency, and duplicating efforts for ~50% of the work is not something we’d consider to be efficient. Which is why we don’t offer managed triage by default – because we’re here to offer the simplest, most efficient option to the market. Is it economically efficient to fly on a private jet? In most cases, no. But is it convenient? Sure. Sometimes convenience outweighs the economics, especially if economics aren’t a significant concern.
We make no argument that paying for managed triage isn’t beneficial, and for many organizations it may still be cost-efficient. We’re just presenting the facts; what you do with them is up to you.
The same principle applies to providing support – where most support issues require client interaction of some sort, it makes no sense to have a middleman for the sake of being a middleman, and so we simply don’t do that.
If you get 100 reports over the course of a year, it’s pretty well established in the industry that ~25-30% of those are expected to be valid, unique, in-scope reports.
You will have to replicate and interact with all of those reports.
It’s also unlikely that your input won’t be needed on other reports – for instance, anyone who has run a program can attest to needing to weigh in during the triage process as to whether a given report is an actual security vulnerability, or if such and such a thing is out of scope, and so on. We’ll call that another 5-10% of all reports.
So, out of 100 total reports, you’re having to engage on anywhere from 30-45% of what gets submitted. Said, differently, if you were previously operating from a place of “triage costs us $x per report”, it’s probable that the true cost was being underestimated by as much as nearly 50%.
And that’s not yet taking into account that valid reports are the most time consuming category of report. Which is to say that the remaining 55-70% of reports are made up duplicates, not applicable findings, and items that are out of scope – which are non-coincidentally, the easiest finding to triage.
When we put a lower weight those types of reports, relative to valid, unique findings, it becomes clear that while triage may touch 100% of reports, you are also having to touch at least 50% of the work.
At DarkHorse, we’re all about efficiency, and duplicating efforts for ~50% of the work is not something we’d consider to be efficient. Which is why we don’t offer managed triage by default – because we’re here to offer the simplest, most efficient option to the market. Is it economically efficient to fly on a private jet? In most cases, no. But is it convenient? Sure. Sometimes convenience outweighs the economics, especially if economics aren’t a significant concern.
We make no argument that paying for managed triage isn’t beneficial, and for many organizations it may still be cost-efficient. We’re just presenting the facts; what you do with them is up to you.
The same principle applies to providing support – where most support issues require client interaction of some sort, it makes no sense to have a middleman for the sake of being a middleman, and so we simply don’t do that.