The solution is used for XDR (extended detection and response), threat hunting, endpoint protection, and device filtering.
The solution works wonderfully to defend endpoints against malware, ransomware, and malicious scripts.
The solution’s machine learning capabilities are wonderful. We extensively tested the solution's machine-learning capabilities, and deploying it to several hundred machines was easy. The solution has capabilities to extend it to protect against AI attacks, deepfake videos, or deepfake emails. In the email protection module, the solution has a writing style analyzer. You can pinpoint the most important entities or people in the company, and the tool will learn how they write and communicate from their emails.
This allows the tool to protect against the business being compromised, and that's a very useful feature. It's a statistical analyzer based on machine learning that observes how you communicate. It needs time, but you can make it learn faster to see the emails. However, it's more useful if you work with current emails, not just the old ones.
You should give the tool two weeks for the current emails, and after two weeks, you can close the learning mode. The solution alerts if it thinks that a business email has been compromised. You have to give it two weeks before it can reliably say whether it's written by the actual user or if it's a fake.
Trend Vision One Endpoint Security provides a single console for cross-layer detection, threat hunting, and investigation. It will collect and show through alerts what is connected from other modules. When something happens on the node that originally came from an email the user clicked on, the tool can pinpoint where the email came from and who else in the company got it. You can block, delete, or put those emails in quarantine before other users click and open them.
You can see all the network activities they have done or tried to do. You can also see where they tried to communicate from the URL filtering and what they dropped. In the solution's new version, a privileged user has access to a predictive attack vector.
The single console's end-to-end visibility has reduced our response time because we have automated responses called playbooks. You can decide whether the probability is small, medium, or high and whether it comes from an email or file. You can also decide whether to block the user, kill the process, send an email, or create the workbench automatically to see what happened and what was the case.
You can manually generate workbenches for the hunting, but if you use the automation playbooks, it can respond faster automatically. The customer bought and managed the MDR (managed detection and response) service. Other professionals bought this managed service for all the products.
For the price of one SOC Analyst a year, a medium-sized bank got 24/7 service with extra help. It was pretty cheap compared to competitors or to the fine they would have to pay if something happened and they could not report back in a timely manner. They wanted to make sure they had double protection.
The solution's end-to-end visibility has reduced your response times. If something happens, the automation handles it pretty fast. Everything is filtered, and the workbenches are created automatically. There's also an auto-response. If something happens, we can block the user or disable the user's Active Directory. We can kill the process or isolate the machine.
It happens almost in real-time when the detection happens. Still, we have an option to just give alerts because the machine or user is too important to block or isolate automatically. You just want to see what happens in the console. If somebody's online, the response time takes ten minutes or so.
Users have to learn to use the solution because it's a bit complex. The solution is pretty straightforward in that the problem is not with the tool's usage but who works with it. Suppose a helpdesk person or an operator gets the alarms for the user laptops. It's not about where to click, how to use it, or which user is using that because it's super easy as it shows the username and where the user is logged in on other computers. You have all the information from the company if it's a clean alert.
Sometimes, they have to verify the technical background. Based on the alerts, the knowledge base, and the preview setting, Trend Micro users can chat with an AI to find out how serious the problem is. Suppose there is a software that behaves badly and gives a false positive because it's poorly written. You excluded it on other machines or decided not to quarantine it because you know it is problematic.
The software has a new version. It comes and is blocked again. It can learn that it has happened before in your environment, so that could be a false positive. You can chat with an AI there, and they can ask about the context. If you are in the workbench environment, you can ask about a user, and it will analyze. Previously, it was not so great. However, it's much better and more mature now because it has learned a lot from the company and what has happened inside it. They also could have just developed a new version.
It's very easy to administer Trend Vision One Endpoint Security.
The solution provides consolidated security across hybrid environments because users don't have to buy tools from three different vendors. Previously, there was an antivirus, an EDR, and a CM to analyze. They kept the CM because they already paid for it. The email protection was different. Right now, they see everything, including email protection, server protection, desktop or PC protection, and XDR.
All the protection for PCs, servers, and emails by both modules is happening from the same console. The threat hunting happens in the same console because they have all the logs. They have everything in one console, including email protection, threat hunting, and server protection. They will introduce mobile protection from Trend Micro, which is XDR for mobile.
All the threat hunting can happen. If something happens on one device, you can see the full context of the user in one console. This is the risk analysis for the C-level entities. It's the overall risk index, and it calculates the actual state. They have a module. The customer didn't buy it because they had already bought a tool for that. This module is more accurate and detailed because the default risk index shows you the overall risk or the ten most risky PCs and users.
Suppose you want the Attack Surface Risk Management (ASRM), which is a more detailed module. It calculates the risk differently if you are inside the company network, on the road with a laptop and free Wi-Fi, or at home and you don't have patches. It calculates that if you have a very important system that you have marked, and if the user connects to that and it's not patched correctly, it has a higher risk.
It could happen with another user who misses the same patches but doesn't have access to critical systems. It has a lower index because the impact will not be so high if the user is compromised. However, it will have a higher index if it's a privileged user. It's not like watching the software versions and the configuration options, but it also benchmarks the context of the user and learns from the AI as well.
The PC product includes 300 of the most widely used virtual patches for ongoing attacks. For example, if there is a new Microsoft bug with a remote desktop, it will provide virtual patches. However, if there is a missing patch not on your system, it's used and gives you an alarm if somebody tries to take advantage of it. Even if you don't need a patch, you can see when an unmanaged computer on the network is trying to hack it.
They have another virtual patching system for the servers in the server product, which is the cloud one and needs an extra license. It gives the host IPFs, and it analyzes traffic as well. If you have vulnerable systems, it will automatically use virtual patches, but it's an extra license for the servers.
If it sees that you have a vulnerable Java application and an old Java version, it will activate the virtual patches for the vulnerabilities against it. However, if you patch, it will turn off automatically by default, so it doesn't consume resources. So, it can be all automated.
It would be much easier if the solution added the allowed USB for pen drives and USB drives. You can import an Excel CSV file with 500 devices, but it will be allowed globally. That would be helpful if you want to allow it only in one policy. If you want to enable these pen drives only for one group or an organization's security group, you have to add them manually one by one. That could be easier.
It's a user experience, but you can add not just the serial but also the vendor. If you only have a Kingston pen drive, you can say that you want to allow all Kingston, or you can add the model number. If you know that you have a specific model of the Kingston pen drive, you can just allow Kingston and that model. The serial number is not important. You will not filter by serial number. However, if you want to filter by serial number and add only the given devices with the serial number, you have to add them one by one.
You have to do this if you don't want to allow them globally. It's enough if you know that you bought a Kingston pen drive and you just put in that you want to allow the Kingston and the model number. Then, all pen drives of the given model will be allowed for a given security group on a given number of computers. In that case, you can attach only pen drives and no external hard drives from Kingston. That could be fast.
If you want to add a given serial number, you add it one by one for a specific group. If you want to allow them globally, you say that everybody can use the pen drive on every computer. You can do it from a CSV. Let's say the CSV imports for security groups only and not company-wide. I think this is the more punctual way. If you want to allow it only for the security group or Active Directory group of users, you must manually edit it to limit the serial numbers.
The solution's user experience regarding device control could be more friendly or straightforward.
The solution's initial setup is straightforward. We planned in advance and created the policies. When we deployed the agents, it was easy because there was a generic deployment agent called base camps. When you deploy the base camps, it will look for the policy you want to use, download the needed components, and install the agent. For the EDR part, it will download the actual optimized driver and use only that one.
You can also create full offline installers, but you can use this automated one, which is small. You download the base camp agents, it reads the configuration, downloads everything that is needed, and activates the policy. If you have a system that cannot be reached by the internet, you can create a full installer. For example, you can download Red Hat Linux version 8.4 or version 8 and install it from a package. You can do this if you don't like the full automation.
We deployed the tool for a segment or group of users. We first deployed it on the PCs and then went to the servers. Once we had the installer, it was pretty fast. It was so pretty fast, but it took longer because of the management's decision not to replace everything at once. We have to consider the window when we can do the maintenance. We have to do it in a maintenance window and not anytime we want.
For the PCs and client computers, you could install 100 in an hour if you want. It took time to remove the previous vendor, ESET NOD32, and reboot the node. After we removed it, it was pretty fast. On one PC, it took about four to five minutes in general.
Along with Trend Vision One Endpoint Security, we evaluated Cynet and ESET NOD32. ESET NOD32 has limited time for roll logs, like seven to 15 days. The logs, by default, were there for 15 days. Only the hunted, examined, or the logs that were marked as not a false positive or the real attack were kept forever. Trend Micro, by default, gives customers 30 days to store or pull all the logs, and they could extend this to six months.
There were performance issues with ESET NOD32 because it has limited space to store the data, just like the URL and the reasoning. Trend Vision One Endpoint Security could store everything and has a much more mature interface. When NIS2 comes, you have to keep the logs for a longer day. You could store the logs externally instead of storing them in ESET NOD32 or Trend Vision One Endpoint Security.
In NIS2, you have a maximum of one month to represent the full threat hunting and the countermeasures you did. We need the logs for a longer period. You can do it in two days. However, if you don't find time to create the full report promptly within one month, it is better to have the full logs, not just for seven days, but 30 days by default, and be included in the price.