3 ms·

Azure claim a bunch of standards, inc the various ISO, SOC, etc as well as claiming HIPAA et al. Now, I haven't checked this service is in scope, but I would pr

Azure claim a bunch of standards, inc the various ISO, SOC, etc as well as claiming HIPAA et al. Now, I haven't checked this service is in scope, but I would presume it is. Given such an obvious piece of external evidence that the IMS has failed (not keeping the software up to date, internal audit not detecting the software is out of date,etc, all the way through to an external incident occurring due to this failure) you have to wonder whether there should be some greater repercussion/ outcome than just "we fixed the vuln". I would very much want to hear what they're doing to fix eg. the internal audit. Root cause on this is a management failure.

viraptor 5y ago
> not keeping the software up to date At that scale "up to date" is not the same as for a standard tech company. It's possible that they run old but custom patched versions in the same way RedHat shipped old kernels with hundreds of patches on top. It certainly is a management failure, but people jumping to conclusion here about old versions may be missing the mark.
- raesene9 5y ago
  In the article you can see that they actually exploit the old issues, which seems to strongly indicate that this is not a case of back porting.
  - y4mi 5y ago
    Unless the backported fix didn't actually remove the vulnerability. Or the vulnerable systems reported as being fixed without actually being so because of another bug. There are a lot of imaginary situations that could've happended. There should be an in-depth analysis from this, but I don't think it's safe to really draw conclusions about their processes from what we know from this exploit alone.
    - raesene9 5y ago
      Given that the Azure notification provided zero details on the patching, I think we can apply Occam's razor here quite effectively. One the one hand we have an old version with a known vulnerability that was successfully exploited. On the other hand we have a backporting process for 5 years that applied fixes to this and a large number of other issues but missed the exploitable vulnerability. Sure we can come up with imaginary scenarios where the second option is possible, but when reasoning about a scenario from limited information I generally go with the simplest possible explanation.
      - y4mi 5y ago
        If you start of using Occam's razor and skip the analysis entirely as you're seemingly fine with you'll just end up with a confirmation bias by only looking at signals which collaborate with what you want to be the truth.
        raesene9 5y ago
        Sure and if we were skipping the analysis here, I'd agree with you. However we have several signals from the researcher side, and no signals (that I've seen) from the vendor side and all of the signals point to a lack of patching. In this case are there any signals you've seen that point to silent backporting that missed the exploited vulnerabilities?
  - viraptor 5y ago
    That's why I didn't say they do backport anything. I don't know how they run that service internally. But knowing how some large customer-facing services are run, I wanted to caution against calling out the "out of date" software that happened in many comments. Sometimes you can't "just update things" and rely on other ways to mitigate.

viraptor 5y ago

> not keeping the software up to date At that scale "up to date" is not the same as for a standard tech company. It's possible that they run old but custom patched versions in the same way RedHat shipped old kernels with hundreds of patches on top. It certainly is a management failure, but people jumping to conclusion here about old versions may be missing the mark.

raesene9 5y ago
In the article you can see that they actually exploit the old issues, which seems to strongly indicate that this is not a case of back porting.
- y4mi 5y ago
  Unless the backported fix didn't actually remove the vulnerability. Or the vulnerable systems reported as being fixed without actually being so because of another bug. There are a lot of imaginary situations that could've happended. There should be an in-depth analysis from this, but I don't think it's safe to really draw conclusions about their processes from what we know from this exploit alone.
  - raesene9 5y ago
    Given that the Azure notification provided zero details on the patching, I think we can apply Occam's razor here quite effectively. One the one hand we have an old version with a known vulnerability that was successfully exploited. On the other hand we have a backporting process for 5 years that applied fixes to this and a large number of other issues but missed the exploitable vulnerability. Sure we can come up with imaginary scenarios where the second option is possible, but when reasoning about a scenario from limited information I generally go with the simplest possible explanation.
    - y4mi 5y ago
      If you start of using Occam's razor and skip the analysis entirely as you're seemingly fine with you'll just end up with a confirmation bias by only looking at signals which collaborate with what you want to be the truth.
      - raesene9 5y ago
        Sure and if we were skipping the analysis here, I'd agree with you. However we have several signals from the researcher side, and no signals (that I've seen) from the vendor side and all of the signals point to a lack of patching. In this case are there any signals you've seen that point to silent backporting that missed the exploited vulnerabilities?
- viraptor 5y ago
  That's why I didn't say they do backport anything. I don't know how they run that service internally. But knowing how some large customer-facing services are run, I wanted to caution against calling out the "out of date" software that happened in many comments. Sometimes you can't "just update things" and rely on other ways to mitigate.