2

We developed an application (see https://embeetle.com). To avoid false positives, all our executables and DLLs are code-signed with an Extended Verification Code Signing Certificate from Sectigo. Despite this, our users complain that Norton flags and deletes our executables and DLLs immediately when they try to launch the software:

enter image description here

As you can see, the threat is based on the fact that our software is "very new" and has "fewer than 5 users in the Norton Community". It is categorized as a WS.Reputation.1 threat (see https://knowledge.broadcom.com/external/article/191764/endpoint-protection-detects-known-good-a.html).

When using Symantec Endpoint Protection (SEP), the SEP client may log WS.Reputation.1 detections on legitimate executable files or installers from trusted vendors. Depending on policy settings, these files may be Quarantined or deleted. [...] The most common cause of this is a change to the file, such as a new version of an application.

Unfortunately, our executables and DLLs are very vulnerable to this. We push out updates very regularly (sometimes once a week). Such an update means: new executables and DLLs that take time to build up a reputation.

Solution 1: whitelisting executables

The solution most people present is to submit the executables and DLLs as False Positives to the antivirus companies. These companies typically have online submission forms. Unfortunately, this is not a sustainable solution:

  • Our software consists of many executables and DLLs interacting with each other - around 500 in total. Submitting them one-by-one in online forms would take many hours.

  • We push out new executables and DLLs at every update. This means we'd have to repeat the online submissions every time.

  • How long do these online submission forms take to be completely processed? If we push out a new update (eg. for an important bugfix), we don't want to wait for months.

Solution 2: whitelisting our Code Signing Certificate

If we can get our Code Signing Certificate to be trusted by the big antivirus vendors, our business is saved. I've read that big software corporations already practice this. The executables and DLLs they release are automatically trusted by the Antivirus companies.

Large corporations can achieve this - how can a small software business like ours achieve it too?

8
  • 2
    It's not an allowlist (whitelist), but you could submit the executable to Virus Total to at least demonstrate that it's benign (because few engines should FP on it) and hopefully let researchers examine and then clear it.
    – Adam Katz
    Sep 1, 2022 at 20:29
  • Hi @AdamKatz, how long does it take for the researchers to examine and clear it after submitting it to VirusTotal? Do they have a paid service for this?
    – K.Mulier
    Sep 1, 2022 at 20:32
  • 1
    I would upload the executable and all self-compiled ell files of your product to Virustotal before you release it. All the AV companies have access to the uploaded files so this should increase your reputation. Alternatively use an old PC and buy Norton AV for it including support plan. As a customer you should be easier to get in contact with Norton.
    – Robert
    Sep 1, 2022 at 21:34
  • Hi @Robert, I already am a customer at Norton. I can indeed upload all our executables and dlls to VirusTotal - but then will have to do it again and again each time we push out a new update (once a week at times). That's unfeasable. Also, how long does it take to be whitelisted? If it's more than a week - all of this is useless.
    – K.Mulier
    Sep 2, 2022 at 9:44
  • 1
    I'm not sure pushing to VT can help in any way but proving that this is Norton's issue. Honestly, I would consider this a client problem. I mean, if the only reason to delete a file is that Norton has never seen it, then it's time to switch to a better AV. If the VT outcome is that only Norton flags it, just tell your client to use better AV policies or a better AV altogether (Norton is a famously crappy AV). Sep 11, 2022 at 13:06

0

Browse other questions tagged .