4 ms·

It's because the risk of a failure is high. If you end up not flagging something and it causes a vulnerability to become a data leak, you will end up getting b

It's because the risk of a failure is high. If you end up not flagging something and it causes a vulnerability to become a data leak, you will end up getting blamed as a classic "noone could have seen this coming"

aequitas 6y ago
The risk of a failure is _sometimes_ high and this will lead to something called alert fatigue: https://en.wikipedia.org/wiki/Alarm_fatigue https://en.wikipedia.org/wiki/Alarm_fatigue
- WrtCdEvrydy 6y ago
  The risk of failure to the scanner company is high. The risk of failure to you is low. That's the difference, they are shifting the burden of security to you... since if you don't patch the "exploit" which may not be an exploit, they can always point back to you in case there is a security breach because you didn't listen to the "magical scanner". It's a clear conflict of interest from twisted incentives. Additionally, if the thing never throws up any exploit warnings, you might wonder why you're paying so much for this fancy alerting thing.
  - aequitas 6y ago
    The value of a scanner with this kind of s/n ratio is very low. Because it would still cost me a lot time (thus money) to investigate every alert every time. What I would pay for is a scanner that is contextually aware and alerts when needed, give or take a few false positives. Not ones that have false positive as their default.
    - WrtCdEvrydy 6y ago
      Now you're getting it. Now think about the fact that most auditors want you running a scanner on your network (and it's required for certain legislation like GDPR)
    - px43 6y ago
      Sounds like what you're looking for is a scanner with more false negatives than false positives. One that won't alert you about a certain percentage of actual critical issues that it detects. You're not alone here, which is why things are so insecure. Enterprise security tools care mostly about catering to people like you who can't be bothered to investigate security issues. There are a totally different set of tools for those of us who actually want to find bugs, and the false positive rate (false:true ratio) on the best of those tools is more like 100:1. Often those tools have false positive rates of 1000:1 or even 10000:1, and people have built good machine learning models to sift through the findings automatically and sort them by likelihood of exploitability. It blows me away to hear people complain about the existence of false positives at ratios like 1:1. If only 50% of the findings in your tool are false positives, you are absolutely missing a ton of real bugs that will eventually be found by people who get paid to find real bugs.
yardstick 6y ago
When we review vulnerabilities in our dependencies we classify their likelihood of being exploited, and their potential impact on the business if they were exploited. Based on these we have a matrix that outputs an overall low/medium/high risk and that lets us prioritise reporting and fixing on medium/high issues. Works well for us. YMMV. (Making something up here) CVE: OpenSSL: RSA is broken Likelihood of exploitation: high Impact on our business: none. We migrated off RSA years ago. Overall risk: Low
- WrtCdEvrydy 6y ago
  Yeah, we've had this as well... for example, if you're running a certain version of node, you might have a CVE on the crypto module but if your API just accepts some data, processes some data and writes it to a local file without using crypto... are you really vulnerable?
  - Sebb767 6y ago
    It depends. Of course, if i.e. a malicious ciphertext can do an RCE, the app right now is not vulnerable. But at some point you might let the user backup his encrypted data and restore it. You colleague knows you already have the code, it's only decrypting the data, you checked it for security, what could go wrong? Of course, you shouldn't panic just because this issue exists, especially if you know it does not affect you right now. But leaving this unattended, especially without the huge exclaimer that you can not accept untrusted ciphertext, can easily come back to bite you. Maybe it was exactly what caused this (theoretical) issue in the first place.
- thaeli 6y ago
  An overall risk of "low" is incorrect here. The risk is "none" because it's not applicable to your environment. Or do you consider "low" a won't fix / not applicable categorization?
  - yardstick 6y ago
    Could use none. Low because if something changes elsewhere and we inadvertently start using RSA by accident, for example. But yeah if it’s not med/high it’s not necessary to fix. Maybe some mitigation where appropriate.
astrobe_ 6y ago
That's risk aversion, and that's why this domain is so unhealthy.

aequitas 6y ago

The risk of a failure is _sometimes_ high and this will lead to something called alert fatigue: https://en.wikipedia.org/wiki/Alarm_fatigue https://en.wikipedia.org/wiki/Alarm_fatigue

WrtCdEvrydy 6y ago
The risk of failure to the scanner company is high. The risk of failure to you is low. That's the difference, they are shifting the burden of security to you... since if you don't patch the "exploit" which may not be an exploit, they can always point back to you in case there is a security breach because you didn't listen to the "magical scanner". It's a clear conflict of interest from twisted incentives. Additionally, if the thing never throws up any exploit warnings, you might wonder why you're paying so much for this fancy alerting thing.
- aequitas 6y ago
  The value of a scanner with this kind of s/n ratio is very low. Because it would still cost me a lot time (thus money) to investigate every alert every time. What I would pay for is a scanner that is contextually aware and alerts when needed, give or take a few false positives. Not ones that have false positive as their default.
  - WrtCdEvrydy 6y ago
    Now you're getting it. Now think about the fact that most auditors want you running a scanner on your network (and it's required for certain legislation like GDPR)
  - px43 6y ago
    Sounds like what you're looking for is a scanner with more false negatives than false positives. One that won't alert you about a certain percentage of actual critical issues that it detects. You're not alone here, which is why things are so insecure. Enterprise security tools care mostly about catering to people like you who can't be bothered to investigate security issues. There are a totally different set of tools for those of us who actually want to find bugs, and the false positive rate (false:true ratio) on the best of those tools is more like 100:1. Often those tools have false positive rates of 1000:1 or even 10000:1, and people have built good machine learning models to sift through the findings automatically and sort them by likelihood of exploitability. It blows me away to hear people complain about the existence of false positives at ratios like 1:1. If only 50% of the findings in your tool are false positives, you are absolutely missing a ton of real bugs that will eventually be found by people who get paid to find real bugs.

yardstick 6y ago

When we review vulnerabilities in our dependencies we classify their likelihood of being exploited, and their potential impact on the business if they were exploited. Based on these we have a matrix that outputs an overall low/medium/high risk and that lets us prioritise reporting and fixing on medium/high issues. Works well for us. YMMV. (Making something up here) CVE: OpenSSL: RSA is broken Likelihood of exploitation: high Impact on our business: none. We migrated off RSA years ago. Overall risk: Low

WrtCdEvrydy 6y ago
Yeah, we've had this as well... for example, if you're running a certain version of node, you might have a CVE on the crypto module but if your API just accepts some data, processes some data and writes it to a local file without using crypto... are you really vulnerable?
- Sebb767 6y ago
  It depends. Of course, if i.e. a malicious ciphertext can do an RCE, the app right now is not vulnerable. But at some point you might let the user backup his encrypted data and restore it. You colleague knows you already have the code, it's only decrypting the data, you checked it for security, what could go wrong? Of course, you shouldn't panic just because this issue exists, especially if you know it does not affect you right now. But leaving this unattended, especially without the huge exclaimer that you can not accept untrusted ciphertext, can easily come back to bite you. Maybe it was exactly what caused this (theoretical) issue in the first place.
thaeli 6y ago
An overall risk of "low" is incorrect here. The risk is "none" because it's not applicable to your environment. Or do you consider "low" a won't fix / not applicable categorization?
- yardstick 6y ago
  Could use none. Low because if something changes elsewhere and we inadvertently start using RSA by accident, for example. But yeah if it’s not med/high it’s not necessary to fix. Maybe some mitigation where appropriate.

astrobe_ 6y ago

That's risk aversion, and that's why this domain is so unhealthy.