Are you assuming no one ever finds zero-day vulnerabilities in "trusted" code? What happens when a piece of code that you trust is compromised in a way you didn't expect?
They're talking about malware, not exploits. It's a habit of the non-technical side of the industry and means 'this hash hasn't been seen before'. Given the phrasing -- "Apps" are "cyber fingerprinted", hashes are "crashed" -- I'd guess the post was written by a marketer or SE.
We are talking about file-based malware that needs to execute.
It doesn't mean this hash hasn't been seen before, it means that application X which is trusted, is on the trust list (and yes, fingerprinted by 6 hashes) is allowed to run. Application Y which is not on the trust list is blocked from running.
That malware can't get on the trust list (unless by a malicious admin) and therefore can't run.
A zero day exploit that allows the injection of malware onto an endpoint for example, doesn't really matter as the malware can't run. How application Y got there, is irrelevant. It could have come from any attack vector.
Exploits don't have to pivot to PE files, and even the exploits that go that route don't have to do it in a way that triggers standard loader hooks (e.g. PsSetLoadImageNotifyRoutine).
To that point, all user submitted content has a new and unseen hash, and could become executable in the face of a zero day in otherwise trusted code that is processing it. This is equally true of web applications and Excel attachments to emails.
People who think the top level poster’s approach to security is sufficient are gravely mistaken.
Not at all, zero days are of course found in trusted code. But they are used to inject malware (file based). That malware is not on the trust list and therefore is blocked from executing.
For example - what turned out to be a zero day exploit was blocked from executing as it was an unknown app. It was an uninstall script that tried to run ever hour and appeared to be part of an AV solution.
9 months later, it was identified as a zero day exploit by 'traditional' AV companies.
Similarly it has blocked SHA1 attacks where for example a previously trusted app has been compromised but even if the SHA1 matches, the other 5 hashes don't and therefore it is not allowed to execute. If any one hash doesn't match - it is blocked.
Comments
Are you assuming no one ever finds zero-day vulnerabilities in "trusted" code? What happens when a piece of code that you trust is compromised in a way you didn't expect?
They're talking about malware, not exploits. It's a habit of the non-technical side of the industry and means 'this hash hasn't been seen before'. Given the phrasing -- "Apps" are "cyber fingerprinted", hashes are "crashed" -- I'd guess the post was written by a marketer or SE.
We are talking about file-based malware that needs to execute.
It doesn't mean this hash hasn't been seen before, it means that application X which is trusted, is on the trust list (and yes, fingerprinted by 6 hashes) is allowed to run. Application Y which is not on the trust list is blocked from running.
That malware can't get on the trust list (unless by a malicious admin) and therefore can't run.
A zero day exploit that allows the injection of malware onto an endpoint for example, doesn't really matter as the malware can't run. How application Y got there, is irrelevant. It could have come from any attack vector.
Exploits don't have to pivot to PE files, and even the exploits that go that route don't have to do it in a way that triggers standard loader hooks (e.g. PsSetLoadImageNotifyRoutine).
To that point, all user submitted content has a new and unseen hash, and could become executable in the face of a zero day in otherwise trusted code that is processing it. This is equally true of web applications and Excel attachments to emails.
People who think the top level poster’s approach to security is sufficient are gravely mistaken.
No claims that it is sufficient - what is does do it prevent any non-trusted file based executable etc from running.
Doesn't do fileless, memory-based or rootkit but does prevent any untrusted and therefore unknown executable from running.
Does that have value - of course, a true default deny approach.
Not at all, zero days are of course found in trusted code. But they are used to inject malware (file based). That malware is not on the trust list and therefore is blocked from executing.
For example - what turned out to be a zero day exploit was blocked from executing as it was an unknown app. It was an uninstall script that tried to run ever hour and appeared to be part of an AV solution.
9 months later, it was identified as a zero day exploit by 'traditional' AV companies.
Similarly it has blocked SHA1 attacks where for example a previously trusted app has been compromised but even if the SHA1 matches, the other 5 hashes don't and therefore it is not allowed to execute. If any one hash doesn't match - it is blocked.