WHAT IS OUR PRIMARY USE CASE?

We use Trend Micro Apex One™ for endpoint security. We are using the SaaS version of Trend Micro Apex One.

I like the way Trend products integrate with each other. The Trend Micro Apex One servers are all tied into Central, which is now integrated into my Trend Vision One™ console. The on-premises stuff is also integrated with Azure. 

HOW HAS IT HELPED MY ORGANIZATION?

I am confident in Apex One's capability to defend endpoints against threats like malware, ransomware, and malicious scripts.

Apex One has predictive machine learning and behavior monitoring, which are essential for endpoint security. Our file scan also scans the memory for malware. Behavior monitoring is particularly effective at detecting ransomware attacks because it can check for unusual encryption methods.

I like the way Trend products integrate with each other. The Apex One servers are all tied into Central, which is now integrated into my Vision One console. The on-premises stuff is also integrated with Azure.

We use a single dashboard through Apex Central to view detections, threat hunting, and investigations. The visibility through the single console is important. When we open the dashboard, it tells us what it has found. For example, I am currently looking at the SaaS version. If I go to ApexOne, I can see all of the agents that are currently connected. It takes a few moments for all of the agents to load. We are currently in a downtime during the summer months. We are a school board, so there are fewer staff members on-site, and not all of the schools are open. We have 12,000 employees and 80,000 students. However, not all of the students are online right now as they would be during the school year. Next Friday, we will have more staff members in the office. When school starts after the Labor Day long weekend in Canada in September, everyone will be back online. Currently, the dashboard only shows 9,140 agents. Last week, it showed 6,400 agents. I have the system set up to remove inactive agents so that the system does not have to constantly scan a bunch of systems that are not even there. I have seen up to 17,000 endpoints on our system.

Vision One is now monitoring my Cloud One workload security and My Cloud Central. This means that Vision One is collecting data from both systems and giving me a comprehensive overview of my security posture. When I open Vision One, I will be able to see visibility into my entire organization. I have configured Vision One to send data to our Syslog server and receive data from our Qualys server. The Qualys server scans my servers for vulnerabilities and reports back to Vision One. I have also set up a service gateway and a workload security data center gateway. The workload security data center gateway feeds data from my VMware ESX servers into Vision One. This allows Vision One to see the real-time status of our VMs, including which ones are powered on, which ones are running the Deep Security Agent, and which ones are still running on my on-prem Deep Security server. Vision One provides me with a risk overview, an exposure overview, and an attack overview. This information includes details about credential access, lateral movement, collection impact, and suspicious mail forwarding rules.

We have our Azure system for Office 365 and on-premises Azure Active Directory also connected to Vision One. This means that Vision One can see all logins to our Azure system and our on-premises AD. I have agents running on our on-premises directory controllers, so this data is also being fed into Vision One. Vision One can also see our Azure domain controllers and our DMZ. I receive alert emails when something serious happens. I haven't received any of these emails since we started using Vision One. However, I receive emails about endpoints that have had files quarantined. The file on the endpoint was too large to move to the main server quarantine, so Vision One just gave me a small error message. Currently, the endpoint protection dashboard shows that out of 19,678 endpoints, agents have been deployed on 13,675. This includes Macs. The dashboard shows one Linux endpoint, which is my service gateway. There are 882 Mac OS endpoints, which is lower than the usual number of 1,100 because not all of them are turned on. There are 12,792 Windows endpoints. The dashboard also shows that 6,003 endpoints have no security protection. These endpoints likely include network equipment, certain Linux servers that are not running Trend Micro software, and proprietary operating systems that are used by our network team and other IT groups. There are also endpoints that are listed in our Active Directory, but they are either turned off or do not have any active systems. Updates are applied on an hourly basis. If an exploit gets through and an endpoint has not been updated, it will receive the update on the next cycle. The most common reason for an endpoint not receiving an update is a network issue or the endpoint being powered off. Once an endpoint goes online, it is configured to automatically retrieve security updates from the server, or directly from Trend Servers over the internet if the server is unavailable. The first thing the endpoint does when it goes online is update its security patches, signatures, and scan engines. When a detection is made, the endpoint first deletes the file and quarantines it. It then blocks the action of whatever the file was trying to do. The endpoint's virtual patching, behavior monitoring, and predictive machine learning then stop any unusual activity. This may even include an activity that is supposed to happen. We have had members of our ICT department complain that they were unable to install software because the antivirus protection was blocking it. In some cases, we have groups within our organization that are responsible for maintaining their own servers. When they are doing upgrades, they may schedule us to temporarily disable the antivirus protection so that they can complete the upgrade. Even if malware does not get detected by the web reputation system and is downloaded by a user, it may still be detected by the signature-based malware detection system. If it is not detected by either of these systems, it may still be blocked if it tries to contact its master. These master addresses are often common addresses on the internet that are used by bots to communicate with a server that is maintained by the threat actor. If a bot is blocked from contacting its master, it will be unable to function. If we see a large number of bots being blocked, we will investigate the system to see what is causing the issue. In many cases, it turns out to be a legitimate activity that is being blocked by the system. For example, we may have custom scripts running on certain servers that look suspicious to the system. We can manually whitelist these scripts so that they are not blocked. Overall, the system is designed to be overprotective. This is because it is better to block something that is legitimate than to let malware through. We can always fix a false positive, but it is much more difficult to fix a security breach.

I started using Apex One in August 2020. I learned how to move agents, install software, and get the agent onto the server. I also learned from the documentation, knowledge base, forums, and other users. I found Apex One to be more difficult to learn than PaperCut because the terminology and concepts are different. PaperCut is just about printing and monitoring, while Apex One is about cybersecurity. There are also many caveats to consider with Apex One. I found the scan settings to be particularly challenging. Trend Micro has helpful best practices documents, which I used to learn what the normal settings are for servers and workstations. For example, servers don't need to be scanned for office document exploits because they typically don't have Office installed. I also learned that it's important to balance security with performance. We don't want to scan servers so heavily that it slows them down, but we also don't want to skip important security checks. In January 2021, we changed our policy on security settings. We now tell users that if there are any problems, we will fix them. We would rather have a small problem that we can fix quickly than have to restore a server from backup, which can take days.

ApexOne provides virtual patching, also known as vulnerability protection, to protect against vulnerabilities before they are exploited. Deep Security and Workload Security call this feature intrusion prevention, but it is essentially the same thing.

WHAT IS MOST VALUABLE?

Workload security now has a feature called Activity Monitor for each endpoint. This is a free version of their Endpoint Basecamp product that is automatically installed with every Apex One agent. Even if we are not licensed for Endpoint Basecamp, it will still be installed. On the servers, I had to remove the Endpoint Basecamp and then deactivate and reactivate the workload security agent to get the Activity Monitor working properly. However, I am glad that we get free monitoring for our servers, even though we do not get it for our workstations.

The agent program version column in the agent screen, we could never sort by. It's so handy to be able to sort by that now. We can go to one end of the scale to see the lowest agent version, and then go to the other end to see how many are updated to the latest agent.

WHAT NEEDS IMPROVEMENT?

Microsoft's new Azure Code Signing is causing a lot of issues for us with Apex One. We currently have two systems in operation, on-prem and SaaS, and many of the agents won't upgrade beyond version B11564 because these newer versions require Azure Code Signing compliance on the endpoint. If we are not up to date with our Windows updates, we don't have this compliance. Irrespective of the Windows version we are running, we have to apply patches to the machines, if the OS is not damaged, to make them compliant. After that, we can upgrade to the latest version of the respective agent. This process also applies to both Deep Security and Workload Security.

I have two production servers: one for Windows and another for Mac. These servers are available in both on-premise and SaaS versions. Additionally, I have a test server that is located on-premises. The significant distinction with the SaaS version is the absence of a test server where I can install a new version. This means I can't allow the agents on it to upgrade and then perform testing. In contrast, with the production SaaS version of Apex One, I have numerous agents transitioning and coming online. It's essential that these agents upgrade to a newer version. Among these agents, there are five or six different versions, not counting the really old ones that have yet to upgrade due to ACS noncompliance. I can't leave the testing phase for an extended period because I still have outdated agents that need to be updated. These agents can't be left hanging while I wait to test the newest version that has just been released. New versions seem to come out every couple of months in the SaaS environment. In the past, when I solely used the on-premises version, I would review security bulletins for the SaaS version to identify any issues. I'm apprehensive about potential future situations involving this, primarily because the majority of our agents now operate on the cloud version. If a problem is discovered, rolling back on those agents would be challenging. It would require careful operation to revert them to a different version.

The on-premises version of Apex One has an update function that allows us to manually update a bunch of servers. For example, if I just turned on a policy, I can force the agents to quickly download the policy and start following the update procedure or update settings. However, this function is not available in the SaaS version. This is because the system cannot communicate with the agent through the firewall. The SaaS version has an automatic update function and an update source entry in the update agents sub-menu, but it does not have a way to force agents to update. This is a problem because we cannot automatically update the agents. We have to manually log in to the machines and give them an update command. Currently, we have no choice but to wait until the agents find the updates themselves.

I am confident in Trend Micro Apex One’s capability to defend endpoints against threats like malware, ransomware, and malicious scripts. 

FOR HOW LONG HAVE I USED THE SOLUTION?

I have been using Trend Micro Apex One for three years.

HOW ARE CUSTOMER SERVICE AND SUPPORT?

I have the enterprise version, so I can usually talk to someone in the Philippines even during after-hours. I only do this when it's something that can't wait until the next day. If it can wait, I'll let it go until then. But if something is broken and needs to be fixed right away, I'll get in touch with the Philippines team. They have some good people there, and the support is really good. I think Trend's support is probably the best of any of the vendors I work with.

I have a few open tickets, and one of them involves the developers. They keep coming back to me with questions that they have passed on to the service representative I'm working with. The developers want to know why I'm seeing something that they think I shouldn't be seeing. I'm generating a report that is supposed to show me all the endpoints on our workload security server that do not have agent self-protection enabled. This is part of the Vision One report. One of the endpoints that the report identifies is our service gateway. It is running Ubuntu Linux and has a Deep Security agent installed, but agent self-protection is not enabled by default. There is a way to enable it, but it's not typically done for Linux systems. Agent self-protection prevents unauthorized configuration of the Trend Deep Security agent service settings. This means that we can't change or stop the service without first disabling agent self-protection.

HOW WOULD YOU RATE CUSTOMER SERVICE AND SUPPORT?

Positive

WHAT OTHER ADVICE DO I HAVE?

I would rate Trend Micro Apex One ten out of ten.

My concern arises when an endpoint lacks Apex One, as we are not actively monitoring for this. While we possess a scanner, this is why I intend to maintain the on-premises system's functionality. I plan to transition away from the deep security system and migrate the application team to the cloud version, although this transition process is currently pending. I need to retain the on-premises Apex One primarily for assessment scanning purposes. This involves scanning all items listed in our active directory, along with the subnets for our VPN, to identify unprotected endpoints. During a recent scan, I identified nine such endpoints and proceeded to install the agent on them. Occasionally, there are instances where the agent won't install, but no error message indicates a connection issue or existing installation. Some of them show as not having the agent installed, even though they do, which can happen when the endpoint is booting up during the assessment scan and the agent hasn't yet been loaded. Resolving this is relatively swift, although there are instances where devices not compliant with ACS will trigger a message stating that the agent cannot be loaded. These devices are then flagged, and I work on making them ACS-compliant to ensure proper agent protection.

The noteworthy aspect of Apex One is that we didn't begin using it extensively until the third quarter of 2021 when vulnerability scanning was initiated. Although we had an Apex Central server, we were not using any policies on it. To enable Vulnerability Protection, we needed to implement endpoint policies in Apex Central. Vulnerability protection involves virtual patching, where regular scans check our operating system's vulnerability to known exploits. It also includes monitoring applications for vulnerabilities and guarding against those vulnerabilities until they can be patched. This process is largely automatic, as the rules to counter cyber threats are introduced until the system is patched, at which point they are removed automatically. In contrast, on the Deep Security side, I need to execute this process manually. A weekly automated scan takes place, followed by an emailed report. This report aids in identifying missing policies or necessitated rule adjustments based on scan findings. We have to constantly monitor the systems to make sure it is okay. I have email alerts coming in from Trend Micro Apex One, and Central Systems. I have folders for workload security, deep security, and Trend Micro in my inbox. I check these folders even when I'm not online to make sure there are no major alerts. In a way, this gives me peace of mind. As long as the agents are running properly and there is enough memory and disk space, everything is fine. However, I still have to manually check the Apex One System Event Log to see if any Apex One endpoints are running out of memory or disk space. We also use SCCM. I set up a scheduled script to create a report of all endpoints with less than 1 gigabyte of disk space. I put this report in a folder that is accessible to all of our school techs and team leaders. This way, they can check the report periodically to see if any endpoints need to be reimaged or have some garbage removed from the disk.