[netman21]

This is all great. Signing and verifying software is important. But it is woefully inadequate in a post Solarwinds-Notpetya-FLAME world. We need something that allows an organization to verify that code has not been maliciously tampered with. I can only think of a combination of sandboxing to detect detonation and C&C comms, and reverse engineering to compare the updates with previous versions. The last is problematic because most licensing bars reverse engineering but oh well..

[varunsharma07]

I agree. There are projects such as https://github.com/ossf/package-analysis and https://github.com/step-security/harden-runner that do behavior analysis. Disclosure: I’m maintainer of the second one.

[MattPalmer1086]

NotPetya delivered itself via an official update, but then did nothing for a month. It was triggered using a response to a standard update check message. Seconds later it was compromising everything in sight.

My point being that sandboxing, etc. would not have helped you at all.

[varunsharma07]

If there was a way to know the behavior of NotPetya and realize that it has code to do things that M.E.Doc (the tax preparation program that was backdoored) was not supposed to do, that could have been used as a way to reject its installation. We are far away from being able to do such analysis at scale, but my point is that it is ultimately the behavior of software that makes it malicious or not.

[MattPalmer1086]

I don't think that is possible for any software that isn't completely trivial. It's related to the halting problem.

If you are relying on detecting behaviour, then you have to run it.

NotPetya did nothing abnormal until it was triggered by the response to a normal network call. The first opportunity to block it would be when it was triggered.

So you could not have blocked the install by this method.

You can detect likely malicious behavior and contain those systems, which would have helped.