A Day at TrendMicro – A Quick Look at Trend’s Deep Security Product [LockBOX]

Varrow was invited ‘and required’ to attend a training event in Arlington Texas as part of their partnership with Trend Micro. This event focused on the Deep Security product and its modules. All accommodations were provided by Trend Micro, and the Hyatt Place Hotel in Arlington was excellent. So… shout out to Hyatt! I will be staying at some of your other properties because of this trip. Many Thanks go out to Trend Micro on behalf of Varrow for including us as a targeted partner for this all-expense paid event; as only specific partners were chosen for this type of treatment.

After going through introductions we talked a bit about why Trend Micro purchased Mobile Armor recently and now the U.S. Government is their largest customer. We talked a bit about Drive Armor, Data Armor products and some of their other new security products. Trend Micro is set apart from everyone else from the standpoint of how they integrate with VMware. Securing your journey through the cloud is important to Trend Micro. Making sure that your private and public cloud is secured and not bogged down by the overhead of typical anti-virus products of the past. By using the API written by VMware you can leverage the vShield EndPoint product and now use agent-less AV within your cloud infrastructure. You can use the Deep Security product on SQL (2008, 2005), Oracle (10g, 11g), and Apache Derby databases. Deep Security is database intensive and needs to be designed with this in mind. Offloading the database to an enterprise database server would be essential to the success of a project in large environments as there is a lot of activity in the database. Pruning the database after a specified number of days would be a prudent thing to consider talking about with DBAs as the database growth can get out of hand. Specific settings within the DSM can help minimize the growth rate and also help purge records after specified timeframes.

In a VDI environment you really have to watch out for AV storms. An AV storm is what we would see if every time that there is an update or environment scan the CPU and memory resources are consumed for every desktop in every pool and your VDI environment can come to a screeching halt; extreme lag. In traditional agent based AV, if your parent image is not updated every time the AV engines and database is updated (which is normal) then every time a linked clone reboots it also has to do AV updates all over again. Using agentless AV you can avoid resource overhead by leveraging vShield and the Deep Security Virtual Appliances (DSVA) located on each host. When performing VDI assessments we have found that the number one application resource hog is the antivirus software in 99.9% of our clients. In the Deep Security product the DSVA holds the updated AV signatures and engines and performs the scans in an agentless deployment, thus enabling higher VM densities in VMware environments.

Currently in the Deep Security 7.5 product, the solution is comprised of 5 modules:

• Anti-Malware
• Deep Packet Inspection (DPI) – [comprised of]
  • IDS/IPS – Virtual Patching
  • Web Application Protection
  • Application Control
  • Stateful Firewall
• Log Inspection
• Integrity Monitoring
• Firewall

Out of the 5 modules, the Anti-Malware, DPI, and Firewall modules are agentless (leveraging the DSVA). The other two modules require a Deep Security Agent (DSA) to be installed onto the client. There are plans to move the other two modules to agentless as well when the API is updated in future revisions of vSphere. The product covers physical, virtual, and cloud environments. If the agent needs to be loaded the agent will control everything but the Anti-Malware portion which will still take advantage of the vShield EndPoint API and use the DSVA instead. This allows for updates of engines and signatures to still be completed by the DSVA as well as scans. The other 4 modules will be managed and controlled by the DSM but will reside on the client. Javascript will be needed for management of the DSM. The following table identifies which protection is provided by the Deep Security Virtual Appliance, the Deep Security Agent, or both:

** A note about the DSM: Make sure that you install the DSA on the DSM so that it can protect itself, afterwards assigning the ‘Deep Security Manager’ security profile to the server. So from a plan and design perspective, this DSM server should fall under the same cluster being protected by the DSVAs.

The core architecture is made up of the following:

• Deep Security Manager (DSM)
• Database – [Named or TCP Pipes]
• Deep Security Agent (DSA) – [using port 4120 & 4118 to/from DSM]
• DSM Management Console – [using port 4119; HTTPS back to DSM]
• Trend Micro Security Center – [using port 443 (SOAP over SSL) back to the DSM]
• Deep Security Virtual Appliance (DSVA)

For redundancy, the DSM can be split into a Primary and Secondary nodes sharing the same records on the same database. DSAs can switch between nodes if this connection with a specific DSM fails or times out. Using the dsa_config.exe executable you currently can configure the DSA on a case by case basis. This will probably disappear in future releases as it is not needed. All agents are configured and managed from the DSM console.

In VDI environments you need to tell DSM to ‘Allow Agent Initiated Activation’, in addition to this you should setup an event based task to look for these new VMs and to register them in the DSM. The event based task can be specified to assign a security profile based on Computer Name, vCenter Name, ESX Name, Folder Name or Platform. Using this event based task, you can assign the appropriate profile and activate the VM without a massive hands on approach to register each and every linked clone that appears. Who wants to do that anyway?

You also have a checkbox here in this System Settings window that states if the Computer name already exists to do the following:

1. Don’t allow activation
2. Activate a new computer with the same name.
3. Reactivate the existing machine

I ran across a report showing comparisons between the Trend Micro Deep Security product and both McAfee and Symantec. The article stated that “Tests showed that Trend Micro Deep Security, which provides an agentless virtual appliance-based approach to anti-virus protection optimized for virtualization, consistently consumed less CPU, RAM and disk I/O resources than the non VM-aware implementations where anti-virus agents and processing resided in each and every Windows 7 virtual machine.”

Also, from personal experience there is a very particular way to prepare your ESX hosts for use with Deep Security. If you do any of these steps out of sequence then you will end up blowing up the installation and will need to back everything out and start over on that host for it to work properly. Sometimes an automatic back out doesn’t even work and you have to uninstall Deep Security manually from the host. These steps have been documented as part of the Varrow best practices for our engineers to follow. BTW… don’t use SP1 and always use SP2 or better when installing Deep Security!! When using SP1 version, when you prepared the hosts, it would reboot them without warning. L I believe that this had to be a reason behind releasing SP2 so early after SP1 was initially released.

All-in-all this was a good class in which I was able to ask many questions that were based on issues and challenges that the Varrow Desktop Virtualization Team has run into with the product at our customer sites. The challenges ended up either being successfully resolved through actions identified in the user and installation guides, or were minor annoyances that we could present to TM for future release considerations. These solutions weren’t intuitive or easily found either (identified after some digging), but the Trend Micro engineers were very knowledgeable and helped us find the answers.

Advertisement