MetaDefender Core Windows

I have used MetaDefender  for one and a half years, deploying it in different environments and managing a team of professional services that deploy MetaDefender  products in customer environments. I talk with customers and am aware of use cases where new or additional needs arose after MetaDefender deployment. For example, customers needed to transfer files between source and destination using MetaDefender. I know that MetaDefender File Transfer Protocol, or MFT , is now supported, but in the past, it was not. There are products that have been developed from customer needs, such as products that can transfer files from source to destination with integration to MetaDefender.

The detection rate of the MetaScan multi-scanning feature is very high. When discussing Linux with five engines or ten engines, it can detect most of the viruses that are tested. I have seen very few instances where customers reported a virus that was not blocked after a PT scan. When we verify these cases, we confirm they occurred. Of course, every engine has its own detection rate, and you cannot achieve 100 percent detection. When using MetaDefender especially on Windows, the detection rate is very high, and it increases as you use more engines. Most customers I see using eight or twelve engines on Windows have good results with both configurations. When customers use a large number of engines, such as twenty engines with integration to external scanners, the results look almost perfect because in cyber security, there is no 100 percent, but it is close to that.

The effectiveness of Deep CDR in reconstructing files safely and without signatures is very effective. When people configure Deep CDR correctly, it performs as it should. Sometimes some files are negatively affected by CDR. If I must be specific about what could be helpful, it would be to create a policy or workflow in OPSWAT terminology that handles cases when CDR cannot be performed or harms the file. I am not certain if the system can check whether CDR has harmed a file, but I know of use cases where CDR was disabled because it made files unable to open or unable to open properly. I believe this is very effective and is the most effective engine of OPSWAT because customers ask for OPSWAT for two main reasons: the CDR capabilities and the multi-scanning engines.

Some feedback indicated that it takes too much time to configure certain policies because there are many options. Some people appreciate this because you can configure anything, but I believe MetaDefender should have a wizard or general policies that can be used for 80 percent of customers.

I use the expanded file type and archive coverage feature sometimes, especially for customers who try to scan large archives with the deep scan capabilities of OPSWAT and Deep CDR. This provides full protection because it scans every single file, but sometimes it takes too long. When discussing CAB files or archives for patching or server updates and BIOS updates and operating system updates, the scanning process takes too long, and it was difficult for customers who sometimes decided not to scan because the scanning time was excessive.

I use the reporting and audit visibility features. Some capabilities are lacking in reporting because we do not have full statistics that are easy for users to understand. If something requires checking and then referring to documentation to understand it, that is too much for most users. When looking at one of the statistics, you can see how many files have been scanned and then you see a number out of 500 or a different number if you change it. It is not a number of files or scan processes; it is a number of files inside a file. When you scan a PowerPoint presentation file, for example, it counts as forty different files because of all the sub-files. I understand from customers that when they look at the visualization data or statistics, they do not understand what is happening there.

Most customers I see do not use the file-based vulnerability assessment feature. It has some good results about vulnerabilities, but I am not certain if it is that helpful because many organizations, when they deploy a file and see that there are vulnerabilities, still deploy it because it is part of the code. It can produce results, but those results do not cause any action. Many products have something more advanced than vulnerabilities and static scoring. They have tools that can inform you about a vulnerability, whether the vulnerability is exploitable, if it is weaponized, and if someone can use this vulnerability in your environment. The file-based vulnerability feature works, but for most people, they do not take any action based on the results or block files because of file-based vulnerabilities.

I have been working in cyber security for almost eight years.

The stability of the system is very high. I have not experienced crashes or downloads when the server is rebooted, and the server runs well after rebooting. I have not seen errors frequently. I recall one problem with MetaDefender email where there was an unusual issue with some connections remaining open, but I found this kind of problem only once. Most of the time, it is very stable, and you can rely on MetaDefender Core and also email. The stability problems with OPSWAT occurred when they attempted to migrate one product, such as the email product, to a SaaS service; it was not stable in that environment.

MetaDefender is very scalable. From what I understand, when you use one database for all instances, you can deploy ten different servers or ten different instances with a separate database for each one. You cannot check the status of scans in each one; you have to check each specific instance. When discussing a shared database, it is scalable, but the performance is harmed. I do not know the specific impact, but it is just a feeling I have.

I have contacted the technical support of OPSWAT. The quality of answers from support has been very good most of the time. It can be useful when contacting support to mention what needs to be collected and what needs to be sent before opening the ticket. For example, if discussing an issue, support will probably ask for specific logs. This can save time because many vendors, when they check something and ask for logs, need those logs from the beginning. If you open a ticket and the answer is to proceed, and the answer after one day is that specific logs are needed, it is better to know that from the beginning.

The deployment of MetaDefender on Windows and Linux machines is very easy and quick. When discussing deployment of containers or deployment in Kubernetes  environments, it sometimes takes too long. The deployment of the sandbox product takes too long. The deployment of MetaDefender email security, core, and MetaDefender kiosk has very easy and quick deployment.

One person can deploy MetaDefender. It is one of the products that can be managed by one person and managed easily, including the deployment.

The pricing of MetaDefender is about hundreds of dollars. If I remember correctly, when someone attempted to buy from us one instance of OPSWAT, it was about nine thousand dollars for multi-scanning with eight engines and also the CDR module. The pricing is good, but when you add additional engines, this is what causes most people not to use additional features. Every additional engine, not about scanning engines but other engines such as file-based vulnerabilities and so forth, requires another license. If customers could buy in one price the basic package, which includes CDR and multi-scanning, in one price, many people would prefer to do it. However, when it is necessary to pay for every single engine or single feature, I believe most customers do not want to use it for that reason.

I have used alternatives to MetaDefender, but not as an administrator, only as a user. I used some kiosk products similar to MetaDefender kiosk. There is an alternative called Sasa Software, I believe it is Sasa Scanner or Gateway Scanner. I used it, but the user interface is not as good as OPSWAT. The experience with this product is not as good as the experience with OPSWAT, and the time it took to scan some large files was very long. OPSWAT is the best alternative. I also see on customers' side another product called RESEC, and this product also was not a good experience. The user experience is not good enough in this field, and when users try to configure policies, it lacks features when compared to OPSWAT.

The sandbox helps in cases of suspicious files. However, the sandbox alert indicates suspicious activity for many different files. When we test some files that we download from vendors' official sites for server BIOS upgrades or firmware upgrades on servers, such as files from Dell or HPE, these files are also considered suspicious for many use cases. The sandbox is good only for specific areas. If discussing email, it can be good. However, if discussing large files, the sandbox can indicate suspicious activity in almost every executable file. This causes customers not to believe in the results. They say it is suspicious, but it is fine to them. Even if something is actually suspicious, it does not receive attention because of the many files that should be legitimate but are considered suspicious.

Perhaps the effectiveness of the sandbox and level of suspicious files can have two different levels. If asked how it can be better, a different score or different tag for suspicious files from known vendors and suspicious files from unknown vendors could help. Multiple levels of suspicious files, scores, or tags could be something that can be configured. For example, when using the sandbox to scan files that you download from the internet to different environments, such as air gap environments, and in this environment you manage IBM servers, if you scan the file and select that you are using it for IBM servers before scanning, it could be considered less suspicious. The system could also load a certificate of the file that you download and then determine whether it has a trusted certificate or a certificate that is probably good enough or probably not suspicious most of the time.

I am not certain if MetaDefender can do anything else. Perhaps if they want to improve vulnerability management, instead of managing static CVEs, they could have a different method involving CVEs but something else as well. For example, CVEs that can be harmful because they are exploitable could be differentiated. However, this is something that cannot be managed at the MetaDefender level because it is just about files on a perimeter and does not understand the deployment of the environment because it is not running in the real environment. I am not certain if there is a way to do this better.

There are some upgrades when MetaDefender has new features, so you have to upgrade. This is not about the upgrade of the engines that happen all the time if you have an internet connection or do it manually. The maintenance can take significant effort that causes most people not to upgrade and update it all the time. Considering offline users, offline environments, and environments with no internet, easier updates could be helpful. The upgrade of MetaDefender version, whether email or MetaDefender Core, is very quick. I would rate this review eight out of ten.