Trustwave announced a Zero Malware Guarantee for their Managed Anti-Malware solution.
As any responsible consumer probably does, such claims typically trigger my “What’s the catch?” behavior. As the full terms are available easily, I figured I would try to understand what it really means. If any of my assumptions are wrong, please get in touch with me and let me know why, or why you think so.
Disclaimer: I am not a lawyer. I have not use the product. I am not affiliated with Trustwave.
Definition of malware
If someone promises complete protection against something, that something must be defined. From point 1.a in the terms:
Malware is defined as any client side exploit which is triggered during web browsing, including exploits of vulnerabilities in popular browsers and 3rd party browser plug-ins. This includes the most popular plugins such as Adobe Flash, Adobe Acrobat Reader and Oracle Java. For embedded content such as Java, PDF and Flash, the malware definition includes the page that has embedded the content. Client side exploits don’t include categories such as XSS, CSRF and other server side vulnerabilities.
My understanding is that regular malicious code contained in a normal executable file of any type are not covered by this. Only malware that can exploit vulnerabilities on the client software used to browse the web are included. To me, this means that a user downloading a malicious EXE, Jar or ZIP and subsequently running the code would not trigger a “Guarantee reimbursement” event.
Some minimum requirements
Points 4 and 5 look to enforce a minimum level of configuration that is expected for the guarantee to be applicable. The list of settings is quite clear, and is provided in the same document. A good example is this one:
HTTPS scanning must be enabled. If disabled, Managed Anti-Malware Service cannot inspect HTTPS traffic (i.e., traffic encrypted with SSL).
Obviously, any exceptions made by the customer resulting in a malware infection are not covered either.
How do you claim?
Let’s assume you get infected by a technique that is covered within their malware definition, and you detect it using different methods.
Not only do you need to provide the URLs, but you also need to provide the sample files, and most of all, the malware must still be available at the previously mentionned URLs.
The original infection URL(s) (up to 10 URLs for each claim), and the date they were browsed. If the URL is no longer malicious at the time of investigation, the claim will be determined to be invalid.
So if you wait until the source is cleaned before filing your claim, you will not get anything. Even if you do not wait, it has to still be there when they perform the investigation.
Performing analysis to obtain the original source URL is one thing, but you also must provide the embedding page, which could be challenging if it has been taken down, or if you are a SMB with low levels of information security skills or maturity. Don’t get infected twice…
In the case of embedded content (Java, PDF, Flash, Silverlight), the embedding page must also be provided.
How much free service will you get?
From Terms and Conditions 6:
You are limited to one (1) warranty claim per calendar quarter.
From Making a Warranty Claim 5:
If your claim is validated and approved, you will receive a new license key for your additional free month of service.
What I understand from this is that you are therefore limited to a rebate of 33%, no matter what the amount or frequency of malware detection are.
This is a splashy way to offer a a rebate of up to 33% to companies who will most probably not have the skills or resources to prove that what is defined as malware got through. And those who do might consider that the time needed to do that, combined with the odds that the source server will be cleaned “too fast”, are not worth spending.
If it helps prevent some clients from disabling security features that are enabled by default, that will be a net gain for security.