Deep Security 7 Best Practice Guide

Trend Micro Confidential
Nondisclosure Agreement is required for non-Trend Micro employees to view this document

Deep Security 7.0
Best Practice Guide

D DS S B Be es st t P Pr ra ac ct ti ic ce e T Te ea am m
J Ju un ne e 2 21 1, , 2 20 01 10 0

2

Trend Micro Incorporated reserves the right to make changes to this document and to the products
described herein without notice. Before installing and using the software, please review the readme file
and the latest version of the applicable user documentation.
The Trend Deep Security 7.0 Best Practices Guide provides best practice guidelines to customers
deploying and managing Deep Security. Detailed information about how to use specific features in the
software is available in the Online Help and in the Deep Security Installation Guide and Deep Security
Users Guide.
At Trend Micro, we are always seeking to improve our documentation. If you have questions, comments,
or suggestions about this or any Trend Micro documents, please contact your Technical Account
Manager.
3
Table of contents
1. Preface ................................................................................................................................................................. 5
2. Product Description .............................................................................................................................................. 6
2.1 Architecture . ..................................................................................................................................................... 6
2.2 Components ........................................................................................................................................................ 6
2.2.1 Deep Security Manager ............................................................................................................................... 6
2.2.2 Deep Security Agent .................................................................................................................................... 6
2.2.3 Database ...................................................................................................................................................... 7
2.2.4 Deep Security Virtual Appliance .................................................................................................................. 7
3 Hardware ............................................................................................................................................................. 8
3.1 Recommended Hardware ................................................................................................................................... 8
3.1.1 Deep Security Manager .................................................................................................................................... 8
3.1.2 Deep Security Agent .................................................................................................................................... 8
3.1.3 Deep Security Database .............................................................................................................................. 8
3.1.4 VMWare / DSVA .......................................................................................................................................... 9
4 Software ............................................................................................................................................................. 10
4.1 Recommendations ............................................................................................................................................ 10
4.1.1 Operating System ............................................................................................................................................. 10
4.1.2 Database .................................................................................................................................................... 11
4.2 Installing 32-bit or 64-bit Deep Security Manager........................................................................................... 11
5 Product Configuration ........................................................................................................................................ 12
5.1 GUI Configuration ............................................................................................................................................. 12
5.1.1 Dashboard ................................................................................................................................................. 12
5.1.2 Alerts ......................................................................................................................................................... 13
5.1.3 Security Profiles ......................................................................................................................................... 13
5.1.4 Firewall ...................................................................................................................................................... 16
5.1.5 Deep Packet Inspection ............................................................................................................................. 22
5.1.6 Integrity Monitoring .................................................................................................................................. 24
5.1.7 Log Inspection ........................................................................................................................................... 24
5.1.8 Components .............................................................................................................................................. 26
5.1.9 System ....................................................................................................................................................... 27
5.2 Recommendation Scans ................................................................................................................................... 29
5.2.2 Automatic Assignment of DPI rules for Single Host .................................................................................. 29
5.2.3 Automatic Assignment of DPI rules for Security Profiles .......................................................................... 29
5.3 Assigning Rules and Security Profiles ............................................................................................................... 30
5.4 Database ........................................................................................................................................................... 30
5.5 Deep Security Configuration Files .................................................................................................................... 31
5.5.1 DSM.Properties ................................................................................................................................................ 31
5.5.2 Logging.Properties............................................................................................................................................ 32
5.5.3 java.security ..................................................................................................................................................... 33
5.4 Recommendations for Deep Security Virtual Appliance (DSVA) ......................................................................... 33
6. Performance Tuning ........................................................................................................................................... 36
6.1 Duplicate Logs Handling ........................................................................................................................................ 37
6.2 Log Retention Strategy ........................................................................................................................................... 38
6.3 Database Indexing .................................................................................................................................................. 38
7. Backup and Disaster Recovery ............................................................................................................................ 39
4
7.1 Rule and Configuration Backup ............................................................................................................................... 39
7.2 Disaster Recovery .................................................................................................................................................... 43
7.3 Database Migration ................................................................................................................................................. 44
8. References ......................................................................................................................................................... 46
8.1 Communication Ports .............................................................................................................................................. 46
8.2 Command Line Parameters ..................................................................................................................................... 46
8.3 Security Updates ..................................................................................................................................................... 47

5
1. Preface
Welcome to Trend Micro Deep Security v7.0 Best Practices Guide. This document is designed to help
customers develop a set of best practices when deploying and managing Deep Security.
This document is also designed to be used in conjunction with the following guides, all of which provide
more details about Deep Security than are given here:
Trend Micro Deep Security v7.0 Implementation Guide
Trend Micro Deep Security v7.0 Installation Guide
Trend Micro Deep Security v7.0 Users Guide
Trend Micro Deep Security v7.0 Sizing Guide

6
2. Product Description
Deep Security 7 is a comprehensive, flexible and cost-effective security solution for physical and virtualized
environments, enabling customers to achieve and demonstrate compliance, maximize cost savings and
minimize business disruptions.

Deep Security allows you to create and manage comprehensive intrusion defense security policies, track
threats, and log actions taken in response to these threats. Beyond standard firewall protection, Deep
Security provides true stateful firewall configuration, and deep packet inspection, monitors file system
changes and inspects operating system logs, along with delivering advanced application vulnerability
protection.
2.1 Architecture
Deep Security is server and application protection software that allows systems to become self-defending. It
is comprised of a centralized management server, a small host-based software component called the Deep
Security Agent, a database and optionally a virtual appliance (for the virtual environment).

2.2 Components
2.2.1 Deep Security Manager
Deep Security Manager (DSM) is a powerful, centralized server that that allows users to create
and manage comprehensive security policies and track threats and preventive actions taken in
response to them. It provides role-based access control (RBAC) and a web-based administrator
console for flexible management access.

2.2.2 Deep Security Agent
Deep Security Agent is a small software component deployed on the physical server or virtual
machine being protected. It enforces the datacenters security policy through IDS/IPS, Web
application protection, application control, firewall, integrity monitoring, and log inspection.

7

2.2.3 Database
The Deep Security Manager uses a database to store client/agent information, configuration settings,
logs and other data. By default, an embedded Apache Derby database engine is installed. Trend
Micro recommends that you do not use the Derby database engine for production environments it is
designed only for small evaluation purposes. For production environments, it is recommended to use
a supported version of Oracle or Microsoft SQL.

2.2.4 Deep Security Virtual Appliance
Deep Security Virtual Appliance (DSVA) performs the some of the same security functionality as
the Deep Security Agent but runs on a VMware virtual machine. Its value is that it can protect
other virtual machines on the same physical ESX host and not require an agent on each host.
Each virtual machine can have its own individual security policy.

8
3 Hardware
3.1 Recommended Hardware
* Please note that these are not the minimum system requirements for this product.
3.1.1 Deep Security Manager
32 bit systems (support up to 5,000 Agents per DSM)
CPU: Intel Xeon with at least two logical 3.x GHz CPUs or equivalent
Memory: 4 GB
Disk Space: 1.5 GB

64 bit systems (support up to 10,000 Agents per DSM)
CPU: Intel Xeon with at least two logical 3.x GHz CPUs or equivalent
Memory: 8 GB
Disk Space: 1.5 GB
3.1.2 Deep Security Agent
CPU: 300MHz Intel Pentium or equivalent
Memory: 128 MB
Disk Space: 200 MB
3.1.3 Deep Security Database
The following hardware is recommended for the database server. We recommend that the database
server be installed on a separate machine.
CPU: Dual 2.4 GHz processor
RAM: At least 2 GB of RAM
Disk Drive: 20 GB

The following table shows the amount of database space that a DSM typically requires in the
indicated states.

Note: Database space should be pre-allocated to avoid autogrowth. Making 20GB available is sufficient for most
deployments.

9
3.1.4 VMWare / DSVA
Deep Security Virtual Appliance
Memory: 512MB
Disk Space: 20GB

ESX 4 Server (where DSVA will be deployed)
In addition to the ESX 4 standard system requirements, the following specifications must be met:

CPU: 64 bit, Intel-VT present and enabled in BIOS
Supported vSwitch: Standard vSwitch or 3rd party vSwitch Cisco Nexus 1000v
10
4 Software
4.1 Recommendations
* Please note that these are not the minimum system requirements for this product.
4.1.1 Operating System

Deep Security Manager
Microsoft Windows 2008 Server (64 bit)
Microsoft Windows 2003 Server SP2 (64 bit)

Note: The clock on a Deep Security Agent (DSA) machine must be synchronized with Deep Security
Manager (DSM) to within a period of 24 hours to avoid agent activation problems.

Deep Security Agent
Windows:
Microsoft Windows 7 (32- and 64-bit)
Microsoft Windows 2008 (32- and 64-bit)
Microsoft Windows 2008 R2 (64-bit)
Microsoft Windows Vista SP1 (32- and 64-bit)
Microsoft Windows 2003 SP2 (32- and 64-bit
Microsoft Windows XP SP3 (32- and 64-bit)
Microsoft Windows 2000 SP4 (32-bit)

Note: We do not support the Agent to be installed on Windows Server 2008 Core, Windows
Server 2008 HyperV, Microsoft Cluster Servers and Microsoft Virtual Server 2005 R2 SP1
systems.

Solaris:
Solaris 8 with SUN patch 113685 and 112438 (64-bit Sparc)
Solaris 9 and 10 (64-bit Sparc)
Solaris 10 (64-bit x86)

Linux:
Red Hat 4 (32- and 64-bit)
Red Hat 5 (32- and 64-bit)
SuSE 10 (32- and 64-bit)
SuSE 11 (32- and 64-bit)

AIX: AIX 5.3, 6.1

HP-UX: HP-UX 11i v3


11
Deep Security Virtual Machine
VMware vCenter 4 and ESX 4 or ESXi 4

Notes: Deep Security uses VMwares VMsafe API to intercept network traffic at the
hypervisor, please note that this API is not enabled in the free version of ESXi 4.
4.1.2 Database
While Deep Security comes bundled with an Apache Derby database, it is not recommended for
production use as it can only approximately sufficiently support 10 clients. The recommendation
is for customers to use Oracle 10g or Microsoft SQL 2008 / 2005 Sp2.
4.2 Installing 32-bit or 64-bit Deep Security
Manager
It is generally recommended that customers install the 64-bit version of the Deep Security Manager
for production environments. 64-bit systems are not subjected to the memory limits which 32-bit
systems are thus making 64-bit systems desired especially for larger deployments and for future
expansion.
Installing the 32-bit version of Deep Security Manager should only be considered if the system
hardware is limited to running 32-bit mode.

12
5 Product Configuration
There are many ways to architect a Deep Security solution there is not one correct way of configuring
Deep Security. Deep Security is a modular solution. This gives customers the flexibility to only use the
features that best suit their needs. A user can start with one or two modules, and then expand their
solution later as they grow or their needs mature.
This section does not cover specifics on how to configure each item specifically nor does it intend to
provide a mandatory framework for customers to follow. This section aims to present suggested
approaches and sample configurations that can be used as reference and/or templates to best suit your
environment.
5.1 GUI Configuration

Below are the main configuration settings to take note of after installing Deep Security Manager.
5.1.1 Dashboard
We recommend that at least the following widgets are included and placed on the area best seen
on the dashboard page:
a. Alert Status to keep you informed on any critical items that may need immediate attention
such as security updates and protection on computers getting offline.
b. Computer Status gives you a good overview of agents status.
c. My Account Status will show information about the user currently logged in.


13
5.1.2 Alerts
Deep security has default alerts configured on the Alerts section. We recommend that these
alerts remain enabled, as they are vital in monitoring events, attacks or intrusions.
5.1.3 Security Profiles
5.1.3.1 When to make use of Interface Tagging
Interface Types is a very useful feature that is use in conjunction with firewall or DPI rules. We
use Interface Types when we need to assign firewall or DPI rules to specific interface on
machine that has multiple interfaces.
By default when we assign a firewall or DPI rule, the rule is assigned to all interfaces on a
machine. If there are some special rules for instance you want to apply only to the wireless
network interface, and not affect the local area network, this is where Interface Types comes
into play.
We configure Interface Types via Security Profiles Interface Types

We can group interfaces into a maximum of 10 different groups. The ones normally used are
LAN and Wi-Fi. We specify the group name and underneath the group name we specify all
possible interface names that fall under this group, for instance the LAN group we can specify
the following matches:
Local Area Connection
Local Area Connection*

14

When we go to firewall or DPI rules, we can now assign rules to specific interface types. The
rule will be applied only to Interface Names that match what we have defined in the LAN group.

When the Security Profile is assigned to host machine, the host machine where its interface
name is Local Area Connection" will now be mapped to the LAN interface type, instead of
Global. This allows the rules to be applied only to specific interface.

When we are creating a Security Profile, it is a good idea to consider whether Interface Types
can help us in terms of applying rules to specific interfaces we want to protect. Consider
populating the Interface Type based on the different networks available to all potential Deep
Security Agent protected machines.


15
5.1.3.2 Group machines effectively to ease management
Security profiles provide a logical way for replicating security settings to servers and desktops
that share similar security requirements. We recommend that machines with similar settings,
software installed, application, or function be grouped strategically when placing them in
security profiles.

Note that the default profiles built in with Deep Security are meant to be examples and should
not be used without prior configuration.

Using security profiles to assign Deep Security rules generally makes it easier to manage as
compared to directly assigning rules to individual hosts. This way, you can make changes to the
profile settings and testing it first prior to assigining it to the machines. Unlike assigning directly
to hosts, there is no quick way (administrators will have to dig into each individual machine to
check each setting) to remove any setting configured that may cause conflict or some programs
not to run correctly.

Using security profiles will allow you to quickly unassign rules by simply taking out a machine
from the profile or assigning it an entirely new profile. Administrators will also be able to
duplicate profiles and can use these as baseline settings for succeeding profiles to be created.

Below are some recommended machine groupings to effectively take advantage of Security
Profiles:

By Operating System
(ex: Windows 2008 Servers, Windows XP Machines, Linux)

By Server Function
(ex: Mail Servers, Web Servers, User Laptops, Point of Sale Systems)

By Application installed/version
(ex. Officescan Servers, Oracle 10 Database Servers, MS SQL 2005 Servers)

Grouping machines properly is key to manage recommendation scans effectively.
Recommendation scans provide administrators with a list of areas on a host that need
16
protection. It creates a guide for how to harden a host, based on Deep Securitys current ability
to protect.

When a Recommendation scan is performed on an individual member of a profile, the
recommendations for that particular agent (DSA) will be seen on the profile as well. Accepting
(applying) the recommendations at the profile level would apply the rules to all members of the
profile. The advantage to this method is ease of maintenance. The disadvantage, however, is
the possibility of assigning rules to profile members that do not actually need them.

This is the reason why it is recommended that machines are grouped accordingly if users don't
want to see the vulnerability being triggered for machines that should not be affected.

5.1.4 Firewall
Firewall configuration and administration must be performed carefully. There is not one set of
rules that will fit all environments and needs. This guide aims to give users best practice tips and
recommendations that we hope can be used as reference and serve as guidelines when building
your own rules.
5.1.4.1 Use In-Line Mode when possible
It is always recommended that Deep Security be set to run in In-Line Mode. When
operating Inline, the live packet stream passes through the network engine. Stateful tables
are maintained, Firewall Rules are applied and traffic normalization is carried out so that
DPI Rules can be applied to payload content.
Should there be a need to test the configuration and rules before pushing them out to the
production environment, it is suggested that In-line mode with detect settings are used.
This way, the real world process of analyzing the traffic takes place without having to
perform any action such as blocking/denying of packets.
Running Deep Security in Tap Mode is generally not recommended and is not the best practice
to perform tests or evaluate Deep Security. Tap mode does not actually block traffic, so a lot of
traffic that would have otherwise been blocked would continue (e.g., responses to traffic that
would have been dropped), so the traffic patterns in this mode are not representative of how the
network will behave once the administrator switches to Inline mode.

Traffic analysis takes place with both modes. However, Tap mode only performs analysis on a
copy of the incoming packet. Therefore it is not able block traffic. Only Inline mode provides
security functionality.


17

5.1.4.2 General list of firewall best practices
Allow rules explicitly allow traffic that matches it to pass, in addition, it implicitly
denies everything else not defined. Be careful when creating allow rules without
defining related rules correctly as doing so can cause one to block all traffic apart
from what the allow rule is created for.
If one relies on dynamic ARP include an appropriate rule to allow ARP.
When using Ethernet, ARP forms the basis of the TCP/IP stack. ARP facilities
provide translation from IP addresses to Ethernet addresses, which are essential for
sending packets to other systems on the local LAN segment. Without this
conversion, there can be no other form of peer-to-peer IP communication.
It is thus very important that Deep Security Manager does not configure a Deep
Security Agent to drop ARP packets, unless that is actually desired (configuration
uses static ARP tables). To ensure this please follow these guidelines:
1) Enable the Trend Micro-provided ARP force allow rule.
2) Do not prevent broadcast ARP packets.
Stateful Configurations should be used when the Firewall is ON.
If the UDP stateful option is enabled a Force Allow must be used when running
UDP servers (e.g. DHCP).
If there is not a DNS or WINS server configured for the Deep Security Agents, a
Force Allow, Incoming UDP Ports 137 rule may be required for NetBios.
It helps to know the different implications firewall rule actions do when creating your
rules. Below are brief descriptions of what each action does:
Allow this action explicitly allows traffic that matches the rule to pass
Bypass this allows traffic to bypass both firewall and DPI analysis. Use
this setting only for media-intensive protocols. Only the port, direction and
protocol can be set with this action.
Deny this action explicitly blocks traffic that matches the rule
Force allow this forcibly allows traffic that would otherwise be denied by
other rules. This action type must be used for UDP and ICMP traffic.
Log only traffic will be only be logged. No other action will be taken

18

5.1.4.3 Firewall rules for wireless laptops
With many laptops now capable of connecting to both the wired and wireless networks, users
need to be aware of the problems that can result from this scenario.

The common problem is a "network bridge" configured between the wired and wireless
network. You risk forwarding the internal traffic externally and potentially expose internal
hosts to external attacks.

Deep Security allows administrators to configure a set of firewall rules for these types of
users to prevent them from creating a network bridge.

a. Create a security profile for wireless laptops

Start with a fresh new profile and choose not to base the profile on an existing Computers
current configuration. This will allow you to manage the rules and configuration easily without
worrying about any pre-existing rules/configuration in use.

b. Configure Interface Isolation

Interface Isolation allows you to force a Host to use only one interface at any one time. This
feature was designed to enable you prevent attackers from bridging across two interfaces.

To do so, set the Enable Interface Isolation option and enter string patterns that will match
the names of the interfaces on a Computer (in order of priority) and then set the Limit to one
active interface per pattern option.

It is not recommended that this be enabled at the global level, so make sure it is enabled
through the Security Profile that has just been created. Set the global settings to not use
Isolated Interfaces and then override the setting on the Security Profile or the Host.


19
Note: Interface patterns accept wildcards such as (*) as well as regex expressions such as
alternation, or the regex equivalent of or (ex. Wireless*|Local* will match any interface
starting with Wireless OR Local)

c. Create Firewall Rules

Once Interface Isolation is in place, connections via the secondary entry (ie. Wireless
Network Connections) should be dropped by Deep Security. Administrators can proceed with
creating other custom firewall rules for connections coming in through the Local Area
Connection. In addition, one can also configure certain traffic from the restricted interface by
creating additional firewall rules using contexts.

20

A context that uses the Interface Isolation option will apply to interfaces that have been
disabled. This is useful for custom Allow and Force Allow rules to allow certain traffic to pass
through based on needs.

d. Configure DPI, Integrity Monitoring and Log Inspection rules as needed.

Interface Isolation via the Firewall feature of Deep Security should be enough to prevent
network bridging. However, additional security can be further assigned to the profile by
configuring DPI rules, Integrity Monitoring and Log Inspection.

5.1.4.4 Configuring firewall rules to work with Trend Micro products
When Deep Security agents are deployed onto servers that host other Trend Micro products,
firewall rules need to be create to allow traffic in and out ports that the product use. There
are no default firewall rules in place in Deep Security for Trend Micro products. Below is a
guide to Trend Micro product ports and a sample rule to create.
Note: Change the Name and Port field to use the value that that corresponds to the
Trend Micro product youd like to create the rule for.
Creating separate rules per product (instead of creating one general Trend Micro rule)
would help ease management.

21

a. Trend Micro OfficeScan Server
Protocol: TCP
Port: 8082, 4345, 8080, 4343 (Default Officescan Server Ports)
b. Trend Micro OfficeScan Client
Protocol: TCP
Port: xxxxx (where xxxxx is the Officescan Client Port, ex. 54321)
c. Trend Micro Interscan Messaging Security Suite
Protocol: TCP
Port: 25, 110, 15505 (scanner server port), 5432 (PostgreSQL port), 1433 (SQL server
port), 389 / 3268 (LDAP) , 8445 (Console), 8446 (EUQ), 8447 (EUQ)
Protocol: TCP+UDP
Port: 53 (DNS)
d. Trend Micro ScanMail for Exchange
Protocol: TCP
Port: 25, 139, 445, 389 (LDAP) , 636 (LDAP/SSL), 3268 (LDAP/Global Catalog)
22

e. Trend Micro Control Manager
Protocol: TCP
Port: 10319 / 10198 (TMI Based agents), 80 / 8080 (MCP Agents), 443 (MCP SSL)
f. Trend Micro Interscan Web Security Suite
Protocol: TCP
Port: 21, 8080 (Default HTTP service port), 1344 (ICAP), 8081 (Guest Port), 1444
(Master-slave port), 1812 (console port), 8443 (https console port), 1433 (SQL Server
port), 5432 (PostGreSQL port)
5.1.5 Deep Packet Inspection
Deep Packet Inspection (DPI) rules should never be modified at the global level as there is no
way to restore the default settings once changed. Should there be a need to further configure or
modify such rules, its suggested this be done at the profile level. (ie, modify DPI rules needed
within the Security Profile). This way, the default master copy of the rules is kept in the global
level and can be used as a reference should there be a need to revert back changes.

5.1.5.1 General Deep Packet Inspection Rules
If a specific rule is causing false positives, place that rule in Detect Only mode or
unassign it.
Any rule, requiring configuration should be assigned in Detect Only mode until the
rule can be configured for that computer.
For new deployments, we recommend setting DPI rules to Inline Detect mode so it
will be easy to identify any false positives
Set DPI rules to only log dropped packets to avoid using up too much disk space.
Only select the Always Include Packet Data option (on the Filter's property sheet) when
interested in examining the source of attacks. Otherwise leaving packet data logging on
will result in much larger log sizes.
Application Types under DPI rules should be checked prior to use.
Ex. Trend Micro OfficeScan Is allowing incoming ports 8080, 4343 and 46485
OSCE ports can be changed, specially the random 5 digit client port. So make sure
rules such as these are re-configured to match your settings before assigning.

5.1.5.2 Recommendations for Cross Site Scripting and Generic SQL
Injection rules
Two of the most common application-layer attacks are SQL injection and cross-site scripting
(XSS). Cross Site Scripting and SQL Injection rules are configured to catch majority of
attacks by default, the best approach to customizing these rules should be to change the
drop score for specific resources that are causing false positives and not the global drop
score.
Both these rules are smart filters and need custom configuration for web servers.
Customers who have output from Web Application Vulnerability Scanners should
leverage that information when applying protection (ie if username field on login.asp

23
page is vulnerable to SQL Injection, ensure the SQL Injection rule is configured
monitor that parameter with a low threshold to drop on)

5.1.5.3 Recommendations for SSL Configuration
Deep Security Manager supports DPI analysis of SSL traffic and is able to filter SSL
encrypted data streams. If this feature is used, it is recommended to disable the inspection
of HTTP responses to avoid any performance degradation.
All web attacks that we protect against are included in the HTTP request and not the HTTP
response, disabling inspection on responses will improve performance.

To configure this, go to Deep Packet Inspection > DPI Rules > Web Application
Protection.
Right click on Web Server Common application type and choose Application Type
Properties
Go to the Configuration tab and uncheck the option called Monitor Responses from
Web Server
Update the changes to the host/profile.

5.1.5.4 Rules to pass PCI compliance
The Payment Card Industry Security Data Standard, or PCI, protects cardholders and
businesses by establishing standard practices for processing, storing and transmitting credit
card data. Deep Security can help an organization pass this compliancy with the aid of DPI
as well as Firewall, Log Inspection and Integrity Monitoring.
To know more on how one can leverage Deep Security to meet PCI requirements, please
refer to the following link:
http://us.trendmicro.com/imperia/md/content/us/flv/enterprise/endpointsecurity/sp04_pci_09
0811us.pdf

24

5.1.6 Integrity Monitoring
Monitoring the operating system and application files and directories is an excellent way to ensure
the integrity of the data on your server. Unexpected changes to these files can be a good indicator
that something suspicious has occurred and should be investigated.
It is good to note that rules created for Integrity Monitoring should be as specific as possible to
improve performance, avoid conflicts and false positives. (Example: Dont try to create a rule that
monitors the entire hard drive)

5.1.6.1 Using integrity monitoring to protect against malware
Integrity Monitoring can be used to monitor files and registries. Malware normally infects a
system by modifying certain registry keys and various system files. The default Deep Security
rules allow you to monitor the integrity of a machine by monitoring the things most commonly
changed by malware in an infected system. Here are a few example rules that are applicable for
all types of situation in Windows platform:

- Rule 1002773 Microsoft Windows Hosts file modified
- Rule 1002776 Microsoft Windows All Users Startup programs modified
- Rule 1002778 Microsoft Windows System dll or exe file modified
Unless new software or a security patch is installed, there is no clear reason any of these files
should be modified. When such an event is raised, the administrator can check whats
happening on the machine to make sure the machine is not compromised.
It is also possible to create custom rules to monitor specific threats, when a user knows the
behavior of a particular virus he is trying to contain in your environment. He can create a special
monitoring rule that checks for certain registry keys or files created by the virus. This can help
him determine if the spread of the virus is being contained or not.
Integrity Monitoring helps one detect changes made on the system, but it will not remove or
prevent the change from taking place. It is a passive monitoring tool that complements anti-
malware and intrusion prevention software.
5.1.7 Log Inspection
Events from the Windows event log and other application specific logs are a great source of
information about the health of your server and applications. Have an automated solution to inspect
these log files for suspicious events and alert is great functionality to include in your defense in depth
strategy.

5.1.7.1 Log inspection to monitor spam activity on SMTP servers
Log Inspection tracks logs and events in the Operating System Event Log, using an
integrated OSSEC Log Inspection Engine. Based on rules defined within the Log Inspection
Filter, you can track changes detected by Log Inspection, and send alerts if necessary.
This feature is especially useful in having easier access to important events in log files
monitored without having to manually trace through it.
There are a number of available log inspection rules by default that administrators can use
to monitor activity on your mail server, including spam activity.


25

One of these rules are designed to monitor activity on Sendmail servers.

When a recommendation scan is ran against the host with Sendmail, this particular rule
should be listed as one of the recommended rules. Enable the rule, along with the
dependency rule called Default Rules Configuration.
Log inspection rules need to be properly configured to work correctly.The first thing to
change and check is the actual log files to monitor. In this case, thats the Sendmail log, or
the maillog.

After defining the rule location and type, configure the event for detected SPAM messages.
This rule is specifically made to monitor spam activity on the server, so for this scenario, we
are lowering down the severity level for the other events. Detected Spam Messages and
Multiple Spam messages have been set to Critical for this example.

Uneccesary alerts for an allowable number of spam messages are not desired, so make
sure the Frequency and Time Frame fields are also tweaked correctly.
After these have been modified, switch to the Options section to configure DSM to send
alerts when the minimum severity is reached.

26

There are 2 more options that can be configured for Log Inspection and can be found in the
System Settings section.

Send Agent/Appliance events to syslog when they equal or exceed the following severity
level : should normally be changed when a syslog server is used. This setting determines
which Events triggered by those rules get sent to the syslog server (if syslog is enabled.)
Store events at the Agent/Appliance for later retrieval bt DSM when they equal or exceed
the following severity level : This setting determines which Log Inspection Events are kept
in the database and displayed on the Log Inspection Events screen
Custom rules can be made to monitor logs that are not in the built in set of rules. For more
information on making your own rules, refer to section 10, References > Making Custom
Rules.
5.1.8 Components
5.1.8.1 IP Lists
Properly segregating the network allows one to maximize the potential how security rules
can be configured to help protect the network. To make it easier to build firewall rules and
to avoid constantly typing in individual IP Addresses, one can group IP Addresses using IP
Lists. The IP Lists can be re-used on various configuration items in the Deep Security
Manager.
Updating the IP Lists automatically updates security rules using this list. This allows the
administrator to update multiple rules immediately and can help avoid inconsistency among
rules.
5.1.8.2 MAC Lists
Same as with IP Addresses, one can also group MAC Addresses under MAC Lists. This
avoids unnecessary re-typing of MAC Addresses when they need to be added to multiple
rules.
Updating the MAC Lists automatically updates security rules using this list. This allows the
administrator to update multiple rules immediately and can help avoid inconsistency among
rules.
5.1.8.3 Port Lists
The Port Lists by default contains comprehensive information on ports used by different
applications. Before one adds custom ports in here, check first if the application is already
listed and if the port is not there, continue to add the port into the said application.
Otherwise, consider adding a new custom Port List entry with a short and descriptive name.


27
5.1.8.4 Contexts

Context rules allow administrators to create firewall rules that only apply in specific
circumstances. Use context to assign rules depending on the location of the machine in
relation with its Domain Controller. Context can also be created to apply to a restricted
interface by using the apply to restricted interface check box.

5.1.8.5 Schedules

The schedules here do not have anything to do with updates and deployment. The
schedules defined here are used for when certain rules should be enabled only on a limited
basis. (e.g. daily: Weekdays from 8am to 4pm, nightly: Everyday from 10pm to 2am or
weekends: Saturday and Sunday 8am to 4pm)
5.1.9 System
System Setting Recommendations:
Computers > Communication Direction

This option can be set at the global, security profile and host level. We recommend
selecting the default value of Bi-Directional method, which is used in most production
deployments.
Manager Initiated should typically only be used for DMZ hosts that cant reach the
Manager in the Datacenter.
Agent Initiated method is good for environments where the Agent is behind a firewall
such as mobile workstations.
Computers > Automatically Update Computers

We recommend disabling this option and instead, use scheduled tasks to update
computers or to update hosts manually as referred to on section 7.1.10.2)
Scan > Scanning for Recommendations

This setting is disabled by default and should be left off. Setting ongoing scans to
automatically start will mean administrators have no control over when it will occur, best
practice is to schedule Recommendation scans to take place once a week instead.

28

Security Center > Security Updates

This setting should be disabled as rules that are not recommended can be assigned to
hosts that don't really need it. When this option is enabled, Deep Security will only check
for the presence of an application on the system and apply corresponding DPI rules for
that application without going through the recommendation engine.
ie. When a host has IIS 7 installed and new rules for IIS 6 are released, setting this to
enabled would result to the following:
- Security updates would detect that the IIS application is present on the host.
- It would then apply and assign the new rules for IIS 6 on the host even if it is
not needed (remember you have IIS 7)
- This setting is not related to recommendation scan, so it does not check the
host if the available updates actually apply to it. It only checks for the presence
of the application (not the version and other related details which the
recommendation scan does)
Note: By disabling this option, we recommend that the administrator run a
recommendation scan after applying a new security update. This way, you can monitor
the new recommended rules and assign them manually.

5.1.9.1 Recommended Tasks to Set Up

We recommend configuring the following scheduled tasks:

Download New Security Updates (Frequency: Once Daily)
Download New Software (Frequency: Once every Week)
Scan Computers for Recommendation (Frequency: Once every Week)

Note: When scheduling recommendation scans, it is best practice to set the task by
group (ie. per security profile, or for a group of computers, no more than 1,000 hosts per
group) and spread it in different days.

Ex. Database server scans are scheduled every Monday, Mail server scans are
scheduled every Tuesday, and so forth.

Recommendation scans can be CPU intensive on the DSM (Manager) so setting
different schedules per group will help avoid any performance issues.

Schedule recommendation scans more frequently for systems that change often.

Update Computers (Frequency: Once every week, or refer to section 7.1.10.2)
Discover Computers (Frequency: Once Daily)
Backups (Frequency: Once Every Week during off hours)


29
5.1.9.2 Host Update Strategies
Its strongly recommend against deploying program updates automatically. Make sure ample
machines have been tested on new product versions before they are rolled out to the whole
enterprise.
Automatic update for security updates is the default but not recommended in production
environments as the administrator loses control over when updates occur. Manual updates
allow more control for an administrator to follow their existing change control process.
Scheduled Tasks can be used to update hosts during maintenance windows, off hours, etc.

To monitor when hosts were last updated and if an update is required, administrators can
use the information on the Host Properties screen.
5.2 Recommendation Scans
The recommendation engine is a framework that exists within Deep Security Manager, that allows
the system to suggest and automatically assign security configuration. The goal is to make
configuration of hosts easier and only assign security required to protect that host.

5.2.1 General Recommendations
Recommended best practice is to set weekly recommendation scans.
Recommendation Scans can heavily tax the DSM so scanning too frequently can result
in poor DSM performance. Hence, systems that dont change often (servers) can be
scanned less frequently.
Systems that lack control over when changes occur (workstations) should be scanned
more frequently.
Scans should be performed after major changes to the computer to determine any
additional required protection.
5.2.2 Automatic Assignment of DPI rules for Single
Host
By default the automatic assignment of DPI rules is turned off. We do not recommend enabling this
option on the host level except under special circumstances where the host machine is on its own
and cannot be associated with other machines in a group. When this rule is enabled, DPI rules will
automatically be enabled on the host machine when the rule is found to be applicable or a matching
application is found on the machine related to the DPI rule.
5.2.3 Automatic Assignment of DPI rules for
Security Profiles
This option is disabled by default, we recommend to test DPI rules prior to enabling this feature.
After a Scan for Recommendation has been completed, the rules applicable to be assigned will be
30
highlighted by a Green flag besides every rule. You can configure DPI scanning in Detect mode
instead of the default Prevent mode. Any traffic filtered by the DPI rules will be recorded under DPI
events. After you have become comfortable with the DPI detection, you can enable Automatic
Assignment of DPI Rules.
5.3 Assigning Rules and Security Profiles
We do not recommend assigning Firewall or DPI rules directly to individual host. After a series of
changes made to individual machines, it will become impossible to track which configuration machines
have. Not only is this confusing, but it makes it impossible for machines to have a consistent set of rules
and configuration.
Security Profiles should be used as much as possible to assign rules to machines or groups.
It is important to group machines that have common functionalities together. For example, SQL servers
should be under its own group and Web Servers under its own separate group.
For automatic assignment of DPI rules, under Scan for Recommendation Automatic Assignment of
DPI rules, it is recommended that this be disabled to give administrators better control over assigning
and unassigning recommended DPI rules.

Note: Refer to section 5.1.3.2 for more details on grouping machines.
5.4 Database
Deep Security Manager must be able to maintain a database PING time of less than 2 million
nanoseconds. Any figure higher than this can cause unpredictable problems. We recommend tat the
database time skew be kept as close to 0 as possible. Although not 100% necessary,keeping the
database time in sync would help prevent confusion in reading logs and reports, this is also specially
important for multi-node environments.

The DSM System Information screen provides information about connection speed and time skew on
the database.

For this reason, the DSM must be co-located on the same network as its database, ideally with a 1GB
LAN connection. Connections over WAN are discouraged.


31
By default, database communication is not encrypted. However, if DSM uses a remote database, and
the SQL server is protected by a DSA, the contents of DPI rules may cause false alarms when the DSM
saves these rules to its database.

The following workarounds are available to avoid this condition:

Option 1: Create a bypass firewall rule for traffic between the database and DSM servers. In this
scenario, a static IP address for the DSM would be preferred.

Option 2: Enable encryption for the database channel. To accomplish this, add the following line to the
dsm.properties file:

database.SqlServer.ssl=require
5.5 Deep Security Configuration Files
5.5.1 DSM.Properties
This file is located under ..\Deep Security Manager\webclient\webapps\ROOT\WEB-INF. This
file is used by Deep Security Manager to establish communication with its backend database.
The information here once updated, will take effect after the Deep Security Manager service is
restarted.
Parameters Description
database.xxxxx.user The SQL account used to connect to the database
manager.node
Its possible to have multiple Deep Security Manager using
a common database, this is the manager node number.
database.xxxxx.server
This is the SQL server name or IP Address of the
database server
database.name The database name of Deep Security Manager
database.type This can be Oracle, SqlServer, or Embedded Database
database.xxxxx.password
SQL account password in encrypted format, if its not
encrypted, it means Deep Security Manager is not
communicating properly with the database server.
mode.demo
Must have value of false on a production environment
installation.
database.SqlServer.namedPipe
True means its using namedPipe otherwise its using
TCP/IP. For local Microsoft SQL server, it is
recommended to use namedPipe, for remote it is
recommended to use TCP/IP
xxxxx = Oracle (when connected to Oracle database); SqlServer (when connected to a
Microsoft SQL database)
Note: The parameters are case sensitive

In remote database scenarios, encryption is not enabled by default. This means that database
communication is vulnerable to snooping. In these instances, enablement of encryption
32
functionality is recommended.

Oracle and MS SQL require their own procedures. Both are shown below. In both instances, the
DSM service must be stopped and then re-started to take effect.

MS SQL Add the following line to dsm.properties:

database.SqlServer.ssl=require

Oracle Add the following lines to dsm.properties:
database.Oracle.oracle.net.encryption_types_client=(3DES168)
database.Oracle.oracle.net.encryption_client=REQUIRED
database.Oracle.oracle.net.crypto_checksum_types_client=(MD5)
database.Oracle.oracle.net.crypto_checksum_client=REQUIRED

5.5.1.1 hssHostnameIPDisplaynameClientname
By default Deep Security Manager communicates with Deep Security Agents via hostname
information. If hostname resolution is not working 100% on customers environment, it is
possible to configure Deep Security Manager to communicate with agents using IP Address.
The hostname field of the agent property will be displayed using IP Address followed by the
Hostname instead of just the hostname alone. To make this change, you can follow this
procedure in the Deep Security Manager.

1. Stop the "Trend Micro Deep Security Manager" service
2. Edit the dsm.properties file in ..\Deep Security Manager\webclient\webapps\ROOT\WEB-
INF and add the following line:
hssHostnameIPDisplaynameClientname=true
Note: The parameter is case sensitive.
3. Start the "Trend Micro Deep Security Manager" service
5.5.2 Logging.Properties
The file is located under ..\Deep Security Manager\jre\lib folder. This file is mainly used to
enable Deep Security Manager debug and control the debug file size.

Parameters Description
com.thirdbrigade.level = ALL This line is added when enabling Deep
Security Manager debug
java.util.logging.FileHandler.limit
= 10000000
Log file size by default will increase upto
10MB before the next log file is created
java.util.logging.FileHandler.count
= 5
Maximum of 5 log files are created before the
first file is deleted and a new file is generated
in its place.


33
5.5.3 java.security
The Deep Security Manager runs within a Java Virtual Machine (JVM), and the JVM places
certain controls on network behaviour. Java uses a cache to store both successful and
unsuccessful DNS lookups.
By default, successful lookups are cached forever as a guard against DNS spoofing attacks.
However, this caching may prevent the Deep Security Manager from communicating with
computers that use DHCP or whose IP address has changed.
Deep Security Manager uses a value of 60 seconds for this setting.
Alternatively, in environments where DNS spoofing is a risk, the DNS cache can be
configured to an unlimited lifetime. To configure the lifetime of the DNS cache for Deep
Security Manager you need to do the following:
Open the java.security file located in [Manager install directory]\jre\lib\security
Find the line for the networkaddress.cache.ttl and set the value to -1.
networkaddress.cache.ttl=-1
Save the file and restart the Trend Micro Deep Security Manager service.
5.4 Recommendations for Deep Security
Virtual Appliance (DSVA)
The Virtual Appliance uses VMware's VMsafe-NET API to intercept network traffic at the
hypervisor. Because of this, when installing the driver, the ESX server must be put into
maintenance mode (with the running VMs either vMotioned to another ESX server or all turned
off).
Make sure to schedule the deployment of DSVA carefully because of these requirements.
It is best practice to download the filter driver and DSVA installer packages onto Deep
Security Manager prior to deploying DSVA and adding the vCenter server onto DSM.
Ensure that the ESX server is able to connect to the DSM hostname at port 4119. There
will be issues installing the driver and DSVA if ESX cannot do so. Make sure DNS
settings are set properly and that ESX firewall allows outgoing TCP connections to port
4119.
Note: Take precaution when doing changes to the ESX box and consult your ESX
documentation for further information.
To open outgoing TCP port 4119 in ESX, log on to the ESX console and run the
following command:
esxcfg-firewall --openPort 4119,tcp,out,DeepSecurityManager
To query existing firewall configuration in ESX, access the Security Profile setting under
the ESX hosts Configuration page (via vCenter or vSphere client), or for a complete list,
run the following command in the ESX command console:
esxcfg-firewall -q

34

When preparing the ESX box, allow the Deep Security Manager to automatically bring
the server into and out of maintenance mode.

To avoid unnecessary issues, accept the default values for the dvfilter configuration.


35
Default password for the deployed DSVA image is dsva and we recommend users to
change this after the install. To do so, press <F2> and select the option Configure
Password on the console.

36
6 Performance Tuning

Disable stateful logging of UDP packets (especially in a Windows environment)
The network creates a lot of noise because of stateful being enabled which results in the creation
of a lot of events that can be largely ignored from a management perspective. So it is
recommended that the stateful logging of UDP packets is turned off.

Pool Size Configuration
DSM has an unbounded Job Queue and a fixed maximum pool size of current/active jobs. This
is the pool of jobs it maintains to do things like activate and update hosts.
This is controlled via the configuration.schedulerPoolSizePerCPU setting, and it is by default set
to 5. In a dual core system, the active job size can be up to 10. This value can be configured to
extract extra performance from faster machines.
Using a value of 30 typically shows that for 150 hosts, activation takes 70 seconds, updates takes
30 seconds and deactivation takes 20 seconds. These numbers can be extrapolated to indicate
that for 2000 hosts, the activation could take up to 16 minutes. These numbers are greatly
influenced by network lag and host lag, as well as the number of heartbeats the DSM is
processing. For instance, if in an environment with significant network lag, we would want a
greater level of concurrency (i.e. a higher value for the setting) to take advantage of long wait
times. Conversely, if the DSM and agent machines were responding very quickly, a lower value
might have a higher throughput.
To adjust these settings use the dsm_c tool located at ..\Program Files\Trend Micro\Deep Security
Manager with the following parameters:
dsm_c -action changesetting -name "configuration.schedulerPoolSizePerCPU" -value "5"
dsm_c -action changesetting -name "configuration.heartbeatPoolSizePerCPU" -value "20"


37
6.1 Duplicate Logs Handling
Use the following SQL commands to determine the size of each table in the Deep Security Manager
database. The command is created for Microsoft SQL Server.

\\ Start of Script
SET NOCOUNT ON
/*DATABASE TABLE SPY SCRIPT
DESCRIPTION
Returns TABLE Size Information
SORTING USAGE
@Sort bit VALUES
0 = Alphabetically BY TABLE name
1 = Sorted BY total space used by TABLE
*/
DECLARE @cmdstr varchar(100)
DECLARE @Sort bit
SELECT @Sort = 0 /* Edit this value FOR sorting options */
/* DO NOT EDIT ANY CODE BELOW THIS LINE */
--Create Temporary Table
CREATE TABLE #TempTable
( [Table_Name] varchar(50),
Row_Count int,
Table_Size varchar(50),
Data_Space_Used varchar(50),
Index_Space_Used varchar(50),
Unused_Space varchar(50)
)
--Create Stored Procedure String
SELECT @cmdstr = 'sp_msforeachtable ''sp_spaceused "?"'''
--Populate Tempoary Table
INSERT INTO #TempTable EXEC(@cmdstr)
--Determine sorting method
IF @Sort = 0
BEGIN
--Retrieve Table Data and Sort Alphabet
-- ically
SELECT * FROM #TempTable ORDER BY Table_Name
END
38
ELSE
BEGIN
/*Retrieve TABLE Data AND Sort BY the size OF the Table*/
SELECT * FROM #TempTable ORDER BY Table_Size DESC
END
--Delete Temporay Table
DROP TABLE #TempTable
\\ End of Script
The script will return all tables in the database in each row. You will see the byte usage of each of the
table. If one table is too large compared to the others, export the content of that folder by saving the
information of this query to a CSV file.
SELECT * FROM %tablename%
If the table name is AgentEvents, it is safe to purge the content of this folder, but we will lose the System
Event logs stored in the database.
6.2 Log Retention Strategy
There are different types of logs stored in the Deep Security Manager database.

- Firewall logs
- DPI logs
- Integrity Monitoring logs
- Log Inspection logs
- System Events

It is recommended to delete logs older than 7 days, depending on audit purposes sometimes it
maybe necessary to store logs longer than usual. However if the requirement is to keep the logs, it
is recommended not to keep logs older than 30 days. Make sure that log purge is enabled in Deep
Security Manager and log deleted is configured for all types of log (System System Settings
System Tab Prune).
Product logs are stored in the database, it is normal for the database size to grow to 20GB for a log
retention policy of 30 days. If you need to store logs longer than 30 days, please make sure you
allocate enough disk space beyond 20GB to allow ample disk space for the database to grow.
Also note that the bigger the database, SQL related queries can often times slow down in relation
to the size of the database, so we want to purge logs as much as possible and keep only the logs
we need.
6.3 Database Indexing
Indexes are specialized data structures that operate on tables (and sometimes views) in the
database engine used to aid in the searching for and sorting of data. Indexes are vital to the
database engine returning results quickly. As data is modified in the underlying tables that the
indexes operate on, the indexes become fragmented. Fragmentation is when the logical
ordering of an index does not match the physical ordering of the underlying table or view. As
the indexes become more and more fragmented, query times can begin to suffer. The remedy
to this situation is to either reorganize or rebuild the index in SQL.
Its recommended to periodically rebuild the index of the database to improve performance.
Below are some useful links with additional information on how to do this:

39
Rebuilding SQL Server Indexes (Fragmented data can cause SQL Server to perform
unnecessary data reads, slowing down SQL Server's performance)
http://www.sql-server-performance.com/rebuilding_indexes.asp
Index Rebuilding Techniques
http://www.remote-dba.net/t_tuning_index_rebuilding.htm
7. Backup and Disaster Recovery
Deep Security utilizes the database for all of its configurations and settings. It is highly recommended that the
database be backed up periodically. This provides the best chance of successfully recovering a production
environment in the quickest amount of time in case there is a disaster situation. Deep Security is compatible
with both Oracle and Microsoft SQL databases.
7.1 Rule and Configuration Backup
All of Deep Securitys configuration and rules are stored in the database. This is essentially the only data that
needs to be backed up for disaster / recovery purposes. However, there is another file, called
dsm.properties, under ..\Program Files\Trend Micro\Deep Security
Manager\webclient\webapps\ROOT\WEB-INF which we recommend users to save a copy as well.
dsm.properties contains most of the information used by Deep Security to connect to the database. It
includes access information such as the database name and credentials.
Back-up an SQL database using Deep Security Manager:

1. Go to Start > Programs > Trend Micro > Deep Security Manager to launch the console.
2. Log into Deep Security Manager.
3. Choose System > Scheduled Tasks
4. Click on New on top left corner of Right Pane window
5. Under Type choose Backup. Click Next.

6. Choose date, start time and frequency. Click Next.
40

7. Choose the path on the Server for DB backup. Click Next.

8. Confirm and Click Finish.

9. This will create daily backups of SQL server on the specified directory.


41
Back-up an SQL database using the osql.exe tool:
1. Stop the Trend Micro Deep Security Manager service.
2. On the machine where the database is installed, open a commandshell (cmd.exe) and
then type "osql.exe -U sa"
3. Type the sa password.
4. The backup itself is performed using the backup command:
1> backup database dsm to disk='C:\dsm.bak'
2> go
Notes:
- The administrator can specify any other disk file / path as a backup destination.
- Replace dsm to the database name used when Deep Security was installed.
- Length of time to back up depends on the size of the database. The larger the size,
the longer the time to backup.
5. Exit from the osql.exe utility:
1> quit
6. Start the Trend Micro Deep Security Manager service.

Back-up an SQL database using Enterprise Manager:

2. Open Enterprise Manager and connect to the server.
3. Expand the Databases folder, then right-click the database that you want to back up.
(Example: dsm)
4. Select All Tasks, then select Backup Database.
5. Provide a name for the backup in the Name text box. Leave the Database complete
radio button selected and make sure that the correct database to backup is selected in
the Database drop-down menu.
6. Select the Overwrite existing media check box to save a new copy of the database either
to disk or to tape.
7. To select a destination for the backup, click the Add button. Select an existing file or
enter a new file name (eg. C:\Backup\dsm.bak) . Click OK after selecting a file.
8. Click the Options tab and select the Verify backup upon completion check box to verify
the backup upon completion.
9. Once all the necessary options are selected, either click the OK button to start
performing the backup, or check the Schedule check box to schedule this operation for
periodic execution.

42

Restoring an SQL database using the osql.exe tool:
2. Open up a commandshell (cmd.exe) and then type "osql.exe -U sa"
3. Type the sa password.
4. Restore the database from backup, using the restore command:
1> restore database dsm from disk='C:\dsm.bak'
2> go
Specify another file name / location, if it is different from C:\dsm.bak
5. Exit from the osql.exe utility:
1> quit

Restoring an SQL database using Enterprise Manager:
2. Open SQL Server Enterprise Manager and connect to the server where the backup is to
be restored.
3. Right-click the database and select All Tasks, then select Restore database.
4. In the Restore as database: list box, enter the name of the new database that the
backup process will create and restore the backup to or from the list of databases, select
the database for which the backup has to be restored.
5. Select the From device radio button and click the Select Devices... button
6. In the Choose Restore Devices dialog box, select either the Disk or the Tape radio
button.
7. Click the Add button and enter the file name of the backup file that is to be restored. If
the file exists on a network share, provide the UNC share name in the File name text box.
Note: It is recommended that the backup be copied to the server and a local path be used to
restore the database.
8. Click OK and Restore the database.

Back-up and Restore an Oracle database using Recovery Manager
(RMAN):
Recovery Manager (or RMAN) is an Oracle provided utility for backing-up, restoring and recovering
Oracle Databases. There are several methods and strategies available for performing backups in
Oracle. We suggest users choose the method that best fit their needs. For this guide, we shall only
cover basic backup method using RMAN. RMAN ships with the database server and doesn't require
a separate installation. The RMAN executable is located in your ORACLE_HOME/bin directory.
RMAN can be operated from command line:
[oracle@localhost oracle]$ rman
Recovery Manager: Release 10.1.0.2.0 - Production
Copyright (c) 1995, 2004, Oracle. All rights reserved.

RMAN> connect target;

43
connected to target database: ORCL (DBID=1058957020)

RMAN> backup database;
Note: Replace target with target database name.
Whenever a backup is created with RMAN, RMAN records the action in the RMAN repository. One can
also record copies of files you create outside of RMAN (such as copies of datafiles created with host
operating system commands) in the repository. When you attempt to restore the backups using the
RESTORE command, RMAN queries the repository for information about available backups, then
chooses among them to perform the restore efficiently.
Additional references for RMAN and other methods can be found below:
Oracle database Backup and Recovery FAQ
http://www.orafaq.com/wiki/Oracle_database_Backup_and_Recovery_FAQ#Why_and_when_should
_I_backup_my_database.3F
Oracle Database Backup and Recovery Basics
http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/toc.htm
Overview of Database Backup and Recovery Features
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/intro.htm#sthref159
Backup and Recovery
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/backrec.htm#g1023042
Making Backups with Recovery Manager
http://download-west.oracle.com/docs/cd/B12037_01/server.101/b10735/bkup.htm#1005571
7.2 Disaster Recovery
Deep Security in its default form has single point of failure with respect to Database. It is recommended
to implement database clustering to create system If a full backup is available, Deep Security can be fully
restored
There are two options available:
a. Restore on the same Server

Once the database has been restored, simply restart the Trend Micro Deep Security service
and re-connect with the database . All previous data will be available from the Deep Security
Manager.

b. Restore on another Server

1. Install Deep Security Manager using your original license on the new box.
2. At this point, you can use the same hostname as the old server or choose another hostname.
3. If a different hostname is used, make sure that the deployed agents are able to contact and
reach the server.
4. Choose embedded database to complete the installation.
7. Go to [install Directory]\Trend Micro\Deep Security Manager and delete the dsm folder.
8. Open the following file in notepad:
[Install Directory]\webclient\webapps\ROOT\WEB-INF\dsm.properties
44
It will look something like:
database.name=dsm
database.directory=C\:\\Program Files\\Third Brigade\\Deep Security
Manager\\
database.type=Embedded
mode.demo=false

9. Replace the contents of the file with the following values:

Note: Replace <values> with information corresponding to the restored environment (point it to the
restored database). Make sure to use sa username and password.

database.type=SqlServer
database.name=<database_name>
database.SqlServer.server=<hostname>
database.SqlServer.user=<username>
database.SqlServer.password=<password>
database.SqlServer.namedPipe=false
mode.demo=false

10. Restart the Trend Micro Deep Security Manager service.
11. Open the dsm.properties file to confirm that the password is encrypted. If the password is still in
clear text then open server0.log under the dsm directory to see what are the exceptions.
12. If the password is encrypted, it means the connection to sql server was successful.

13. Login to the Deep Security Manager console.
14. You can change the hostname of the DSM at this point, provided that there are no agent initiated
communications and the Manager can contact all the agents.

15. Go to System > System Information > Click on DSM name
16. Update the hostname/ip/fqdn for DSM
17. All the agents will now be updated to report to the new Deep Security Manager.
7.3 Database Migration
Using the embedded Derby database should never be used in production environments. There are
times where default installs using the embedded database needs to be moved over to either SQL or
Oracle. There may be several configurations and rules set up on Deep Security during evaluation
and testing that administrators simply dont want to recreate all over again when moving to
production.
Below is the method that will allow them to easily migrate the database from Derby (embedded
database) over to SQL or Oracle.

The procedure is broken down into three phases:
Export tables from embedded database
Import tables into MS SQL
Modify dsm.properties

1. Export tables from embedded database
This procedure will generate an SQL query file named DSMData.sql in the Deep Security
Manager installation folder. Do the following:
- Open a command prompt (cmd.exe)
- Navigate to the DSM folder. By default this is C:\Program Files\Trend Micro\Deep
Security Manager

45
- Type the following command
dsm_c action createinsertstatements databasetype sqlserver generateDDL
goparameter GO

Optional: To exclude security logs, and thereby make the resulting SQL file more
manageable, include the following after GO above.

excludetables packetlogs,agentinstallers,integrityevents,
loginspectionevents,payloadlogs

2. Import tables into MS SQL
The following procedure is based on OSQL. However SQLCMD will work as well.
- Open a command prompt (cmd.exe)
- Type the following command

SQLCMD U <username> P <password> d <database name> i <full path to DSMData.sql>

3. Modify dsm.properties
When a DSM is set to use an embedded Derby database, the contents of dsm.properties
appears as follows:
database.name=dsm
database.directory=\\Deep Security Manager
database.type=Embedded
mode.demo=false

It must be replaced with entries required for operation with an MS-SQL database. Do the
following:
- Open dsm.properties. This can be found in the following location:
<Install path>\webclient\webapps\ROOT\WEBINF\dsm.properties

- Replace with the contents with the following:
database.name=<database_name>
database.SqlServer.server=<hostname>
database.SqlServer.user=<username>
database.SqlServer.password=<password>
database.SqlServer.namedPipe=true
database.SqlServer.appName=Trend Micro
database.SqlServer.progName=Deep Security Manager
mode.demo=false

46
8. References
8.1 Communication Ports
When troubleshooting communication issues between the Manager and Agents, it is good to know
the actual ports Deep Security uses.
The table below lists ports commonly used by different Deep Security components when
communicating with each other.
Component Port Description
Deep Security Manager
TCP 4119
The default port used by the manager for the
Web Application GUI over HTTPS.
TCP 4120
The default port used by the manager for the
agent to communicate with the manager in
agent-initiated operations over HTTPS.
Deep Security Agent
TCP 4118
The default port used by the agent for
Manager-initiated communications over
HTTPS.
LDAP (Active Directory
Synchronization)
TCP 389 LDAP Clear Text
TCP 636 LDAP SSL
Trend Micro Security
Center (Updates)
TCP 443
SOAP over SSL port, which the Manager uses to
download updates.
Database TCP 1433
TCP 1434
Default Microsoft SQL Server port

8.2 Command Line Parameters
Both the Deep Security Manager and Agent offer administrator command line configuration options that
are helpful when troubleshooting issues or when access to the console is not available.

A partial list of the command line parameters has been included in this section and is grouped according
to function.

Communication:

# dsa_control r

The dsa_control command-line utility can be used to deactivate a running agent and reset its
configuration.
On Windows you would run it from a command prompt as follows:
# "C:\Program Files\Trend Micro\Deep Security Agent\dsa_control.exe" -r

47
On Unix you would use the following:
# /opt/ds_agent/dsa_control -r

Database:

# dsm_c -action resetevents -type [all|fw|dpi|im|li]

This command can be used if the event tables become corrupt or too full. The tables are dropped
and re-created. The -type option can be followed by one or more of:
all - All Event Types
fw - Firewall
dpi - Deep Packet Inspection
im - Integrity Monitoring
li - Log Inspection

Note: For multiple options, comma separate the values.
# dsm_c -action resetcounters
This command can be used if the counter table becomes corrupt or too full. The logs table is dropped
and re-created.
8.3 Security Updates
VSU (Security Updates) are typically released once a week, on Tuesdays, inline with
Microsofts Patch Tuesday.
Automatic download of Security Updates is recommended
Automatic download and apply of Security Updates is not recommended
It is a best practice to perform a Recommendation Scan after applying a new Security
Update
The default setting of Allowing Security Updates to automatically assign new DPI Rules is
not recommended in production environments
You can check the link below for the latest security and product updates for Deep Security. You will
need your customer login information to access the site.
https://labs.thirdbrigade.com

48
Document Revision History
Date Revision Editor
4/23/2010 First draft Jill Maceda and Alwin Yu
5/20/2010 First Draft Revision Andy Lux and Jason
Pappalexis
6/21/2010 Minor revisions and corrections Bob Durie, Mike Gibson
and Christopher McKenzie

Deep Security 7 Best Practice Guide

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Deep Security 7 Best Practice Guide

Uploaded by

Copyright:

Available Formats

Trend Micro Confidential

You might also like