4 ms·

Because Verizon's report, while a good read, isn't the end-all-be-all of threat intelligence. https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-c

Because Verizon's report, while a good read, isn't the end-all-be-all of threat intelligence. https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/ https://www.wired.com/story/notpetya-cyberattack-ukraine-rus... https://krebsonsecurity.com/2020/12/u-s-treasury-commerce-depts-hacked-through-solarwinds-compromise/ https://krebsonsecurity.com/2020/12/u-s-treasury-commerce-de... Software supply chain attacks are rare, but when they happen, they're usually high-impact ordeals.

MattPalmer1086 2y ago
Correct, software supply chain attacks may be rarer than a simple SQL injection attack, but they are much harder to detect and defend against, and can have very high impact. Where I work (highly regulated financial utility), we would absolutely love to have signed attestations for the provenance of python packages. I also have personal experience of NotPetya; I produced the forensic analysis of how it compromised the whole of Maersk. Took less than 30 minutes to take out their entire global IT infrastructure, with a cost of about $400 million.
- pastage 2y ago
  You need to know where these attestations were made, you need a TPM telling you that this was done on a patched untouched server, in an patched untouched VM, on a signed attested code base, with deploy scripts unchanged by anyone. We are not there as long as Jenkins and most build infrastructure is basically Remote exploit as a service it is also going to take a long time. While Petya like in Ukraine is harder the more attestations you add there is always a hole, especially when all of your infrastructure needs to run things from some proprietary vendor.
  - MattPalmer1086 2y ago
    Well, those would be nice too. But I'm happy to not let the perfect be the enemy of the good.
  - michaelt 2y ago
    The proposal is an attestation from Github, owned by Microsoft. They could instead use a cloud-based trusted execution environment on Azure, and get an attestation from some combination of Intel and Microsoft. Or they could use a TPM and get an attestation from Infineon that the Microsoft-signed shim loaded a kernel blessed by a Microsoft-approved Linux vendor such as Canonical. Seems to me that just trades one corporate attestation for another.
    - amiga386 2y ago
      And that attestation does not affirm that the device's /usr/bin/python3 was squeaky-clean and didn't Ken-Thompson the package build process. It just affirms which machine. The trust that the machine itself is not compromised is implicit; "oh, yes, we trust Microsoft not to mess up its GitHub Actions worker VMs" What would work better is if _everybody_ could run the same CI action to produce a release tarball, and it produced identical builds, and everyone doing this could publish their findings - we can federate a heterogenous network of verifiers, rather than trust a single source's attestation

MattPalmer1086 2y ago

Correct, software supply chain attacks may be rarer than a simple SQL injection attack, but they are much harder to detect and defend against, and can have very high impact. Where I work (highly regulated financial utility), we would absolutely love to have signed attestations for the provenance of python packages. I also have personal experience of NotPetya; I produced the forensic analysis of how it compromised the whole of Maersk. Took less than 30 minutes to take out their entire global IT infrastructure, with a cost of about $400 million.

pastage 2y ago
You need to know where these attestations were made, you need a TPM telling you that this was done on a patched untouched server, in an patched untouched VM, on a signed attested code base, with deploy scripts unchanged by anyone. We are not there as long as Jenkins and most build infrastructure is basically Remote exploit as a service it is also going to take a long time. While Petya like in Ukraine is harder the more attestations you add there is always a hole, especially when all of your infrastructure needs to run things from some proprietary vendor.
- MattPalmer1086 2y ago
  Well, those would be nice too. But I'm happy to not let the perfect be the enemy of the good.
- michaelt 2y ago
  The proposal is an attestation from Github, owned by Microsoft. They could instead use a cloud-based trusted execution environment on Azure, and get an attestation from some combination of Intel and Microsoft. Or they could use a TPM and get an attestation from Infineon that the Microsoft-signed shim loaded a kernel blessed by a Microsoft-approved Linux vendor such as Canonical. Seems to me that just trades one corporate attestation for another.
  - amiga386 2y ago
    And that attestation does not affirm that the device's /usr/bin/python3 was squeaky-clean and didn't Ken-Thompson the package build process. It just affirms which machine. The trust that the machine itself is not compromised is implicit; "oh, yes, we trust Microsoft not to mess up its GitHub Actions worker VMs" What would work better is if _everybody_ could run the same CI action to produce a release tarball, and it produced identical builds, and everyone doing this could publish their findings - we can federate a heterogenous network of verifiers, rather than trust a single source's attestation