DS8 STS 20feb2012 PDF

Trrend
d Micr
M o™
Deeep
p Se
ecurrity 8.0
0
Sup
pportt Trac
ck
Stu
udent Textb
book
Trend Micro Deep Security Support Track
Information in this document is subject to change without notice. The names of companies, products, people,
characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual,
company, product, or event, unless otherwise noted. Complying with all applicable copyright laws is the
responsibility of the user.
Copyright © 2012 Trend Micro Incorporated. All rights reserved.
No part of this publication may be reproduced, photocopied, stored in a retrieval system, or transmitted without
the express prior written consent of Trend Micro Incorporated.
All other brand and product names are trademarks or registered trademarks of their respective companies or
organizations.
Trainer/Writer: Calvin Mangubat
Released: February 2012 v1.1
2 CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL © 2012 Trend Micro Inc.

Support Track Table of Contents
References
Vording, Mike, and Lee, Wesley; Remove MD5 from DSM specification.doc
Salted hash:
http://www.aspheute.com/english/20040105.asp
http://msdn.microsoft.com/en-us/magazine/cc164107.aspx
Kozierok, Charles M., The TCP/IP Guide, San Francisco, CA: No Starch Press Inc., 2005
Russinovich, Mark E., Solomon, David A., Microsoft Windows Internals, Redmond, WA: Microsoft Press, 2005
RFC 793 – Transmission Control Protocol
RFC 826 – Ethernet Address Resolution Protocol
RFC 3164 – BSD syslog protocol
Third Brigade Deep Security Wikipedia
Port scanning techniques: http://nmap.org/book/man-port-scanning-techniques.html
Xmas scan: http://www.networkuptime.com/nmap/page3-5.shtml
Understanding TCP Reset attacks: http://kerneltrap.org/node/3072
MSI debug: http://support.microsoft.com/kb/223300
OSSEC: http://www.ossec.net/
CERT Advisory CA-1998-01 Smurf IP Denial-Of-Service attacks
PING-of-death: http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci822096,00.html
Spangler, Ryan, Analysis of Remote Active Operating System Fingerprinting Tools, University of Wisconsin, 2003
Browsing and enumeration: http://www.sans.edu/resources/securitylab/attacks_browsing.php
ARP poisoning: http://www.watchguard.com/infocenter/editorial/135324.asp
Session hijacking: http://www.iss.net/security_center/advice/Exploits/TCP/session_hijacking/default.htm
Cross-site scripting: http://www.ibm.com/developerworks/web/library/wa-secxss/
SQL injection: http://technet.microsoft.com/en-us/library/ms161953.aspx
Conficker / Worm_Downad:
Deep Security Server Protection – Conficker Worm Use Case, April 2009
http://threatinfo.trendmicro.com/vinfo/secadvisories/default6.asp?vname=MS08-
067_SERVER_SERVICE_REMOTE_EXECUTION_EXPLOIT
http://blog.trendmicro.com/downad-gearing-up-for-a-botnet/
http://blog.trendmicro.com/where-in-the-world-is-downadconficker/
http://blog.trendmicro.com/downadconficker-turns-1yr/
http://blog.trendmicro.com/new-downad-generates-more-urls/
Acknowledgements
The author wishes to acknowledge the assistance of the following individuals. Without them, this document would
not have been possible.
Mike Gibson
Bob Durie
Bilal Baig
Christopher McKenzie
Eric Rosenquist
Rick Abbott
Sharan Hiremath
Marion Mora
Jesus Escolar
Jill Chua-Maceda
Alwin Yu
Ernesto Jimenez
Dale Sabo
Kevin Boyce
Justin Foster
Bart Trojanowski
Saif Chaudhry
Aphyr Lee
Ron Chittaro
Kevin C Chen
Michael Dysart
The following individuals have offered help with feedback and reviews:
© 2012 Trend Micro Inc. CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL 3

Brent Huffman
Ryan Delaney
Chris Pratico
Mark van Ryck de Groot
John Burroughs
Bob Lewinski
The following individuals from the AMSP team provided information for their component:
Joyce Chang
John H Lee
Sebie Shieh
Travis Lin
Ziv Huang

Support Track
Table of Contents
Chapter 1: Course Overview ....................................................................................... 13
1.1 > Course Objectives ................................................................................. 13
1.2 > Target Audience and Prerequisites ........................................................ 13
1.3 > How to Use This Material ....................................................................... 14
Chapter 2: Product overview ...................................................................................... 15
2.1 > Chapter overview .................................................................................. 16
2.2 > What’s new ........................................................................................... 16
2.2.1 External enhancements ................................................................ 16
2.2.2 Internal enhancements ................................................................. 24
2.3 > Product overview ................................................................................... 26
2.4 > About Deep Security Agent .................................................................... 27
2.4.1 Agent architecture........................................................................ 28
2.4.2 Agent: User mode ........................................................................ 29
2.4.3 Agent: Kernel mode ..................................................................... 30
2.4.4 Protection functionality ................................................................ 31
2.4.5 Agent settings.............................................................................. 34
2.5 > About Deep Security Manager ............................................................... 34
2.5.1 Manager architecture ................................................................... 34
2.5.2 Web client .................................................................................... 35
2.5.3 Manager core ............................................................................... 36
2.5.4 Agent communication .................................................................. 38
2.6 > Management console ............................................................................ 38
2.7 > Database ............................................................................................... 39
2.7.1 Installation options ...................................................................... 39
2.7.2 Database operation ...................................................................... 41
2.7.3 Backup & recovery ........................................................................ 49
2.8 > Review questions .................................................................................. 50
Chapter 3: Installation ................................................................................................... 52
3.2 > System requirements............................................................................. 53
3.2.1 Manager Hardware and Software Requirements ............................ 53
3.2.2 Web Console Requirements .......................................................... 53
3.2.3 Deep Security Agent / Relay Hardware and Software Requirements54
3.2.4 Virtual Appliance Hardware and Software Requirements ............... 54
3.3 > Installing Deep Security Manager ........................................................... 55
3.3.1 Installers ...................................................................................... 55
3.3.2 About the installation log ............................................................. 55
3.3.3 Deployment considerations .......................................................... 56
3.3.4 Changes to host ........................................................................... 60
3.4 > Installing the Deep Security agent ......................................................... 62
3.4.1 Installers ...................................................................................... 62
3.4.2 Changes to host ........................................................................... 63
3.4.3 Agent activation ........................................................................... 63

3.4.4 Agent upgrades ........................................................................... 64

Chapter 4: Detecting hosts ......................................................................................... 68
4.2 > Detection methods ................................................................................ 70
4.3 > Hosts from LDAP/X500 directories ........................................................ 71
4.3.1 How it works ................................................................................ 72
4.3.2 Supported directories ................................................................... 72
4.3.3 Directory-related operations ......................................................... 73
4.4 > Hosts from VMware systems ................................................................. 85
Chapter 5: Applying a security plan ....................................................................... 90
5.2 > About security profiles .......................................................................... 91
5.2.1 Parts of a profile .......................................................................... 91
5.2.2 Settings precedence ..................................................................... 92
5.3 > Assessing traffic patterns ...................................................................... 93
5.4 > Assessing vulnerabilities ....................................................................... 93
5.4.1 About port scanning..................................................................... 94
5.4.2 About Recommendation scan ....................................................... 98
5.5 > About components .............................................................................. 103
5.6 > Contexts ............................................................................................. 106
5.7 > Configuring Anti-Malware functionality ................................................ 107
5.7.1 The relationship between scan types and scan configuration ...... 108
5.7.2 Exclusion lists ............................................................................ 108
5.8 > Review questions ................................................................................ 111
Chapter 6: Protection basics.................................................................................... 112
6.1 > Understanding the threat .................................................................... 113
6.2 > Defending against the attack ............................................................... 113
6.3 > Inline vs. Tap mode ............................................................................. 115
6.4 > Traffic analysis .................................................................................... 116
6.4.1 Phase 1: Fragment analysis ........................................................ 117
6.4.2 Phase 2: Packet analysis ............................................................. 120
6.5 > Host analysis....................................................................................... 124
Chapter 7: About Integrity Monitoring ............................................................... 126
7.1 > Chapter overview ................................................................................ 127
7.2 > Integrity Monitoring basics .................................................................. 128
7.3 > Integrity Monitoring operations ........................................................... 129
7.3.1 About Integrity Monitoring threads............................................. 129
7.3.2 Baseline comparison triggers...................................................... 130
7.3.3 Agent-side storage of events ...................................................... 133
7.3.4 Creating baselines...................................................................... 133
7.3.5 Database size control ................................................................. 134
7.4 > Dissecting an Integrity Monitoring rule ................................................ 134
7.5 > Auto tagging and trusted sources ....................................................... 139

7.5.1 Why bother with automatic tags? ................................................ 139

7.5.2 Tagging basics ........................................................................... 139
7.5.3 About trusted sources ................................................................ 140
Chapter 8: About log inspection............................................................................ 142
8.2 > Log inspection basics .......................................................................... 144
8.3 > Log inspection operation ..................................................................... 145
8.3.1 About database storage ............................................................. 146
8.4 > Dissecting a log inspection rule ........................................................... 147
8.5 > About log decoders ............................................................................. 149
8.6 > Log severity ........................................................................................ 155
Chapter 9: About the firewall.................................................................................. 158
9.2 > Firewall operation ............................................................................... 159
9.2.1 About firewall rules .................................................................... 159
9.2.2 Firewall rule action ..................................................................... 164
9.2.3 About priorities .......................................................................... 167
9.2.4 About database storage ............................................................. 169
9.3 > Reconnaissance scans ......................................................................... 169
9.4 > About stateful configuration................................................................ 170
9.5 > Internet Protocol version 6 (IPv6) ......................................................... 173
9.6 > Known issues ...................................................................................... 173
Chapter 10: About Deep Packet Inspection ..................................................... 176
10.1 > Chapter overview .............................................................................. 177
10.2 > Uses for Deep Packet Inspection ........................................................ 177
10.2.1 Virtual patching ....................................................................... 177
10.2.2 Protocol hygiene ...................................................................... 178
10.2.3 Limited application control ....................................................... 178
10.3 > DPI operations .................................................................................. 178
10.3.1 How rules work ........................................................................ 178
10.3.2 Rule groups ............................................................................. 179
10.3.3 About database storage ........................................................... 182
10.1 > HTTPS payload inspection ................................................................. 182
10.1.1 SSL basics ................................................................................ 183
10.1.2 DSA in an SSL connection ......................................................... 184
10.1.3 Payload inspection ................................................................... 184
10.2 > Protecting web applications............................................................... 185
10.2.1 Dealing with HTTP encoding ..................................................... 189
10.2.2 Web server filters ..................................................................... 190
10.3 > Review questions .............................................................................. 195
Chapter 11: Protecting Virtual Machines .......................................................... 196
11.2 > DSVA basics ...................................................................................... 197

11.2.1 Instant-on protection ................................................................ 197

11.2.2 Network traffic protection ........................................................ 197
11.2.3 Anti-malware protection ........................................................... 199
11.2.4 Agentless File Integrity Monitoring ........................................... 202
11.3 > DSVA internals .................................................................................. 202
11.3.1 File structure ............................................................................ 202
11.3.2 About Master Agents ................................................................ 203
11.3.3 About Virtual Agents ................................................................ 203
11.4 > DSVA operation ................................................................................. 204
11.4.1 Preparation and deployment ..................................................... 205
11.4.2 Traffic analysis ......................................................................... 214
11.4.3 Anti-Malware operation ............................................................ 215
11.5 > DSVA-related communication ............................................................ 216
11.5.1 DSVA communication basics..................................................... 216
11.5.2 DSM and VMware Center Server ................................................ 217
11.5.3 DSM and vShield Manager ........................................................ 221
11.6 > Configuration options ....................................................................... 221
11.6.1 Protecting VMs ......................................................................... 224
11.6.2 Coordinated protection ............................................................ 227
11.7 > Working with vMotion ....................................................................... 231
11.7.1 vMotion basics ......................................................................... 231
11.7.2 Moving DSVA data .................................................................... 232
11.8 > Known issues .................................................................................... 233
Chapter 12: Malware and other threats ............................................................. 235
12.2 > Anti-Malware operation ..................................................................... 236
12.2.1 AM on the DSA ......................................................................... 236
12.2.2 Agentless AM operation ........................................................... 244
12.3 > Anti-malware configuration ............................................................... 245
12.3.1 Scan types ................................................................................ 246
12.3.2 Scan configuration ................................................................... 251
12.3.3 How AM configuration settings work together in DSVA ............. 270
12.3.4 Pattern technology selection..................................................... 272
12.4 > Protection against Web threats .......................................................... 277
12.4.1 WRS basics ............................................................................... 277
12.4.2 About Web security ratings....................................................... 278
12.4.3 Behavior with a page is blocked ................................................ 283
12.4.4 Dealing with false positives ...................................................... 284
12.4.5 WRS operation .......................................................................... 286
Chapter 13: Communication & management .................................................. 290
13.2 > Management console ........................................................................ 291
13.3 > About passwords .............................................................................. 292
13.3.1 Obfuscating the password ........................................................ 292
13.3.2 Password recovery.................................................................... 293

13.4 > Communication................................................................................. 293

13.4.1 About heartbeats ..................................................................... 294
13.4.2 Communication direction ......................................................... 297
13.4.3 Socket timeout ......................................................................... 298
13.4.4 Activation & security ................................................................ 298
13.4.5 Supported commands .............................................................. 301
Chapter 14: About logs, alerts, and reports .................................................... 305
14.2 > Log and event basics ......................................................................... 306
14.3 > Log storage ....................................................................................... 307
14.3.1 Storing logs at the Agent .......................................................... 307
14.3.2 Storing logs at the Manager...................................................... 308
14.4 > Log sending interval .......................................................................... 308
14.5 > Log retention .................................................................................... 308
14.5.1 DSA logs .................................................................................. 309
14.5.2 DSM logs.................................................................................. 311
14.6 > About notifications............................................................................ 312
14.6.1 Selecting events for notification ............................................... 312
14.6.2 SMTP server selection ............................................................... 312
14.6.3 About Alerts ............................................................................. 313
14.7 > Using syslog ..................................................................................... 316
14.7.1 Syslog basics............................................................................ 316
14.7.2 Syslog format ........................................................................... 317
14.8 > About reports ................................................................................... 318
14.8.1 Report templates ...................................................................... 318
14.8.2 Report filters ............................................................................ 319
14.8.3 Report access ........................................................................... 320
14.9 > Best practices .................................................................................... 321
14.10 > Known issues .................................................................................. 321
14.11 > Review questions ............................................................................ 322
Chapter 15: Updating a Deep Security network ............................................ 323
15.2 > How Deep Security components are updated ..................................... 324
15.2.1 DSR basics ............................................................................... 324
15.2.2 The update process .................................................................. 326
15.2.3 About iAU clients and relays ..................................................... 328
15.2.4 Incremental updates ................................................................. 329
15.2.5 iAU basics ................................................................................ 330
15.3 > Updating components ....................................................................... 336
15.4 > Updating DSA / DSVA ........................................................................ 336
15.4.1 Download behavior .................................................................. 337
15.5 > Updating DSM ................................................................................... 339
15.6 > Updating the Deep Security Relay ...................................................... 339
15.6.1 What DSRs offer to their networks ............................................ 340
15.6.2 Download behavior .................................................................. 341
15.6.3 Identifying DSRs with the latest updates ................................... 342

15.7 > iAU folders ........................................................................................ 343

15.7.1 On the DSR .............................................................................. 343
15.7.2 On the DSA .............................................................................. 345
15.7.3 On the DSVA ............................................................................ 346
15.8 > Update sources ................................................................................. 346
15.8.1 Update from an HTTP/HTTPS server ......................................... 347
15.8.2 Update from a resource bundle ................................................ 348
15.9 > Update triggers ................................................................................. 349
15.10 > Updates in a multi-node environment (Only available when DSVA 7.5 is
present) ................................................................................................. 351
Chapter 16: About the diagnostic package ...................................................... 353
16.2 > About the packages .......................................................................... 354
16.2.1 DSM diagnostic package ........................................................... 354
16.2.2 DSA diagnostic package ........................................................... 356
16.2.3 DSVA diagnostic package ......................................................... 360
Appendix A: “Deep dive” information ................................................................. 361
A.1 > Appendix overview.............................................................................. 362
A.2 > Chapter 2: Product overview ............................................................... 362
A.3 > Chapter 3: Installation......................................................................... 369
A.4 > Chapter 4: Detecting hosts.................................................................. 388
A.5 > Chapter 6: Protection basics................................................................ 389
A.6 > Chapter 9: About the firewall .............................................................. 390
A.7 > Chapter 11: Protecting virtual machines .............................................. 392
A.8 > Chapter 12: Communication and management .................................... 415
A.9 > Chapter 13: About logs, alerts, and reports ......................................... 420
A.10 > Chapter 14: Updating a Deep Security network .................................. 422
Appendix B: Key concepts and threat map....................................................... 449
B.1 > Appendix overview .............................................................................. 450
B.2 > Key networking concepts..................................................................... 450
B.3 > Types of attacks .................................................................................. 455
B.4 > Anatomy of an attack .......................................................................... 456
B.5 > Mapping features to threats ................................................................ 466
Appendix C: Product history.................................................................................... 476
C.1 > Appendix overview.............................................................................. 477
C.2 > About Common Criteria ...................................................................... 477
C.3 > Version 7.5 ......................................................................................... 477
16.3.1 External enhancements ............................................................ 478
16.3.2 Internal enhancements ............................................................. 479
C.4 > Version 7.0, Service Pack 1 ................................................................. 480
16.3.3 External enhancements ............................................................ 480
16.3.4 Internal enhancements ............................................................. 481
C.5 > Version 7.0 ......................................................................................... 482
C.6 > Version 6 ............................................................................................ 483
C.7 > Version 5 ............................................................................................ 484

Appendix D: About widgets ..................................................................................... 486

D.1 > Appendix overview ............................................................................. 487
D.2 > Widget options ................................................................................... 487
Appendix E: Database tables ................................................................................... 490
Appendix F: Intelligent ActiveUpdate (iAU) IDs ............................................. 496
F.1 > Class codes ......................................................................................... 497
F.2 > Type codes .......................................................................................... 498
F.3 > Language codes .................................................................................. 507
F.4 > Region codes ....................................................................................... 508
F.5 > Platform codes .................................................................................... 508
F.6 > OEM codes .......................................................................................... 509
Appendix G: Command line interface ................................................................. 510
G.1 > Appendix overview ............................................................................. 511
G.2 > DSM command line interface ............................................................... 511
G.3 > DSA command line interface ............................................................... 512
Appendix H: AMSP reference ................................................................................... 514
H.1 > Appendix overview ............................................................................. 515
H.2 > AmspConfig.ini reference.................................................................... 515
H.3 > AMSP component IDs .......................................................................... 516
Appendix I: Configuration file reference........................................................... 518
I.1 > Appendix overview ............................................................................... 519
I.2 > Naming convention .............................................................................. 519
I.3 > Enabling Deep Security logging ............................................................ 519
I.4 > Circular logging ................................................................................... 520
Appendix J: Answers to review questions ........................................................ 522

Support Track
Cha
apte
er 1: Cou
C rse Over
O rview
w
In this couurse, you will leearn how to use
u Trend Miccro™ Deep Seecurity 8.0. Th his course provvides
information n about the baasic architectuure, deploymeent scenarios, installation,
i co
onfiguration, and
a
administrattion options, and
a troubleshooting details that a networrk administrattor needs to kn now
for successsful implemen ntation and lon ng-term mainttenance.
1.1
1 > Cou
urse Ob
bjective
es
Taking thiss course shoulld enable you to complete these
t knowleddge- and skills--based tasks:
Knowled
dge
● Descriibe the purposse, features, fuunctions, and capabilities off Deep Securitty 8.0
● Descriibe the high-leevel program architecture
a
● Understand system configuration
c and administration optionss and requirem
ments
● Understand the diffe
ferent networkk threats this product
p addresses
● Identiffy areas in whiich troublesho
ooting may bee required
Skills
● Install Deep Securityy manager andd agents
● oot common problems in Deep
Use deebugging toolss to troublesho D Security
1.2
2 > Tarrget Au
udience
e and Prerequisites
This coursee is designed for
f resellers an
nd IT professiionals responssible for proteecting networkks
from virus attacks and other
o security threats.
t Thosee who will typiically benefit the
t most incluude:
● System
m administrato
ors
● Netwo
ork engineers
Before youu take this couurse, Trend Miicro recommeends that you haveh ng knowledge of
a workin
Trend Micrro products an nd services as well as of bassic networkingg concepts and principles. You
Y
should also
o have a workiing knowledgee of the follow wing productss and conceptss:
● TCP/IIP protocol kn
nowledge
● Open System Intercconnection (O
OSI) reference model
● Microssoft Active Diirectory admin
nistration
● VMwaare Center Servver / ESX serrver administrration
© 2012 Trend Miicro Inc. CONFIDEN

NTIAL — Release
e Pursuant to NDA
N — CONFIDE
ENTIAL 13
1.3 > How to Use This Material

This training course combines instructor-led presentation with hands-on lab activities. It includes
two manuals: this student manual, which provides the framework for the course, and a lab
manual, which identifies tasks that you can perform to develop key skills. Prompts to complete
various lab activities appear in relevant locations throughout the textbook.
To help ensure that you learn the skills you need to install, configure, and manage Deep Security,
this course has been created using a learning model that is based on:
Chapters – The student manual is divided into chapters. In addition to defining important
concepts and terms, each chapter outlines the various administration tasks you need to
perform.
Chapter Objectives – Each chapter starts with a list of objectives so that you can see how the
chapter fits into your overall course goal. After reading the chapter, you should be able
to fulfill the chapter objectives.
“Deep dive” information – Information
that are of greater interest to a technical support
audience has been moved to Appendix A.

Support Track
Cha
apte
er 2: Prod
duct overview
w
Chapterr Objective
es
After comp
pleting this ch
hapter, you sho
ould be able to
o:
● Explain the featuress introduced in
n this version
● Understand the Deeep Security maanager architecture.
● Understand the Deeep Security ageent architecturre.

NTIAL — Release
e Pursuant to NDA
N — CONFIDE
ENTIAL 15
2.1 > Chapter overview

This chapter introduces Deep Security and is divided into the following sections:
● What’s new
● Product overview
● About Deep Security Agent
● About Deep Security Manager
● Management console
● Database
2.2 > What’s new

Although this document focuses on version 8.0, there were two major service packs released
since version 7.5 became available that introduced significant changes to the base product. For
this reason, these changes are discussed here in their respective sections.
As with previous versions of this document, the list of new features are divided into the
following categories:
External enhancements – these are changes that are visible on the product console, and
impact the administrator’s experience
Internal enhancements – these are internal-only changes that are not readily apparent.
Both types of enhancements are discussed below.
NOTE For information about features and enhancements introduced in previous

versions, see Appendix B
2.2.1 External enhancements

External enhancements introduced in the various versions released since version 7.5 are
discussed in their respective sections.
Version 8.0
DSM on Linux –64-bit RedHat Linux Enterprise Edition 5 and 6 are now officially
supported.
VMware ESX 5 support – DSVA version 8 is designed to work with VMware ESXi
version 5. It will not work with previous versions of ESXi
Anti-Malware functionality on DSA – Deep Security Agents can now perform Anti-
Malware functionality. This introduces a host of capabilities that were previously
unavailable with agent-less (DSVA-only) protection. This includes:

Support Track Trend Micro Deep Security
● Improved Trojan / memory-resident malware scanning – malware process and

memory-resident components can be stopped and removed, along with related
changes to other system areas (e.g., Registry, etc.)
● Improved Spyware/grayware scanning – DSAs use the Spyware Scanning API
(SSAPI) engine and can scan systems areas beyond the file system, thus improving
Spyware detection and removal.
● New Anti-Malware configuration templates – there are now two types of Anti-
Malware configuration templates
This removes Real-time Scan-specific settings (e.g., IntelliTrap, process image file
list, etc.) from the configuration of scan types that either can’t or shouldn’t use them.
● New Real-time Scan exclusion – a new exclusion list was created for use in Real-time
scan configurations. This only affects DSAs and does not apply to DSVA-initiated
scans.
● Reducing the impact of AM scans – administrators can reduce the impact of manual
or scheduled Anti-Malware scans on available CPU resources, by controlling the rate
at which the DSA cycles through the files it scans. This impact reduction, however,
is at the expense of the total time it takes to complete the scan. This only affects
DSAs and does not apply to DSVA initiated scans

● Granular scan action based on malware-type – administrators now have the option
to specify the scan action taken against malware according to malware type.
● Removal of configurable “second action” – this behavior is dictated by AMSP. If the

first action fails, it will automatically be quarantined.
● Scan size limitation – this feature avoids performance issues associated with
excessively large, non-archival, files. Files that exceed the value specified here are
skipped.
NOTE Worms, Trojans, and the similar malware are typically small files that
do not exceed 5MB. Viruses, which are now less prevalent, can infect larger
files but have been observed to have difficulty infecting large files without
damaging them. For this reason large files are not viewed as much of an issue.
Integrity monitoring on DSVA - the DSVA is now able to detect file-based Integrity
Monitoring events on a Virtual Machine even without a DSA installed.
Smart Protection Network (SPN) integration – DSAs and DSVAs can now send
information to the SPN.
Endpoint notifications – Windows users will now be able to receive notification about
malware and spyware events, and the status of protection through an application that
installs on the Windows system tray.

Support Track T
Trend Micro Deep Security
upport – this version now supports iAU (Intelligent Active

iAU su A Update)) for DSM, DSVA,
an
nd DSA updates. The DSM,, however, willl still support the previous AU-based update
sysstem in enviro
onments that have
h version 7.5
7 DSVAs.
Relay servers – theese are modifieed DSAs that serve as iAU update serverrs for the Deepp
Seecurity network. These faciliitate componeent update sup
pport for largee deploymentss.
Th
hese are also in
nvolved in preeserving Integgrity Monitorin
ng baselines for
fo VMs that
vM
Motioned from m one ESX server to anotheer.
Web reputation
r fun nctionality – DSA/DSVA A can automatiically block malicious or
pootentially maliccious Web sitees. The sensitiivity level for this feature is configurable.
Agentt self-protectiion – administrators can no
ow prevent en
ndpoint users from
f removin
ng
DSSAs
Spywaare exclusionn – this featuree prevents Deep Security from removingg applications that
t
maay be identifieed as spyware
Directt and via-Manager syslog g options – relaying syslog messages

m from
m the agents to o the
DSSM simplifies firewall admin
nistration by eliminating
e the need to perm
mit traffic bettween
thee DSA/DSVA A and a Syslogg/SIEM soluttion.
© 2012 Trend Miccro Inc. CONFIDEN

NTIAL — Releasse Pursuant to NDA — CONFIDE
ENTIAL 19
Version 7.5, Service Pack 2

DEEP SECURITY MANAGER
The LDAP user account synchronization wizard has been enhanced to incorporate a filter that
allows the DSM administrator to choose the types LDAP objects that are imported to the DSM.
The relevant screen is shown below. This feature was added to resolve issues related to having
synchronized with too many LDAP objects.
As shown above, by default the wizard will only show groups. The result of the filter is shown
below.

Administrators can include additional parameters to the filter to further refine the selection
shown on the screen above. For additional information about filter syntax, refer to the following:
http://msdn.microsoft.com/en‐us/library/aa746475(v=vs.85).aspx
DEEP SECURITY AGENT

GUI removal – this service pack removed the graphical user interfaces of the following
agent versions: AIX, HPUX, and Linux
Expanded platform support – the following platforms are now support:
● SUSE 11 SP1.
● Redhat Enterprise Linux 6.
● CentOS 5.

The following external enhancements were introduced in this service pack.
Removal of MD5 support – in support of efforts to obtain Common Criteria EAL +4
certification, MD5 will no longer be used. This affects the following features:
● Password obfuscation – this will affect the password salt implementation, which
used to use MD5 hashes
● Encryption of sensitive database fields – MD5 was used in
● Integrity monitoring baselines
● VSU obfuscation
Enhanced support for multi-tenant deployments – to accommodate requests from XSP
customers that require granularity in what different User Roles are allowed to see on the
DSM console and reports, the following enhancements were introduced:
● New user account controls that hide screen elements from users (see below)
Other rights

User rights
● Filters that prevent users from seeing report data, and events, generated by hosts to
which they cannot view
Removal of weak ciphers – in support of efforts to obtain Common Criteria EAL +4
certification, the list of preferred ciphers for DSM-DSA communication has been
reduced. The following table shows the ciphers that were removed and retained
Retained Removed
TLS_RSA_WITH_AES_256_CBC_SHA SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_AES_128_CBC_SHA SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
Activation and policy assignment via new Event-based tasks – Service Pack 1
introduced the concept of tasks that run when specific events occur. In previous
versions, events ran solely based on schedules.
Event-based tasks, first introduced in version 7.5 SP1, define system responses when a
Virtual Machine is added or moved to a protected ESX server. The following events can
trigger these tasks:
1. Attempt to activate agent on VM
2. Assign a profile based on the VM’s parameters
The relevant screen is shown below.

The profile assignment capability replaces the original system introduced in Deep
Security 7.0 SP1, and resulted in the deletion of the following section of system settings
In its place, event-based tasks allows the administrator to assign profiles according to the
following parameters:
Profile assignments, therefore, will no longer be global as it was previously, but can
actually be tailored for specific environments.
Performance profiles – Administrators now have some measure of control over the
number of threads that are devoted to particular tasks, based on the nature of the Deep
Security Manager installation.

SYN-Flood protection removal – discontinuation of Windows 2000 support has made this
feature redundant. For this reason, this feature has been removed.
2.2.2 Internal enhancements

The following internal enhancements were also introduced to accommodate various requests and
implement fixes:
Version 8.0
AMSP integration – this version includes the Anti-Malware Solution Platform, a Trend
Micro common module that acts as an interface between a product and the core
technologies (e.g., scan engines, etc.) that it uses to implement protection. This module
introduces a number of changes to include the following:
● Aegis support – on Windows-based agents, the Trend Micro Aeigis module is used to
hook into the file system to detect file I/O events, as well as to implement self-
protection
● Referential scanning – AMSP handles cooperation between VSAPI, SSAPI, and a DLL-
based Damage Cleanup Engine
Scan-storm avoidance – this feature controls the number of manual or scheduled AM,
Integrity, and Recommendation scans that take place on an ESX server. This feature
introduced changes the job queuing feature, and affects DSAs that are installed on VMs.
IP6 support – the packet processing pipeline has been modified to support IP6 traffic, to
include IP6 traffic that is encapsulated by IP6 transition mechanisms (i.e., IP6-to-IP4
and Teredo). Selected aspects of the DSM, DSA, and DSVA have been modified to
ensure compatibility with an IP6 environment.

Service Pack 2 introduced resolved a number of issues to include the following:

ESX preparation issues - the following were resolved:
● Resolved and issue where restoring of an ESX host causes loss of network
connectivity in a Distributed Switch environment.
● Resolved an issue where, when preparing the ESX server, the Deep Security
Manager did not prompt the user to enter maintenance mode and would reboot the
ESX without entering maintenance mode
Anti-Malware configuration issues – the following were resolved:
● Resolved an issue where the "-" character in file and directory lists used for Anti-
Malware were being incorrectly encoded.
● Resolved an issue where Scheduled Scan and Manual scan configurations were not
showing hosts on the "Assigned To" tab if the configurations were assigned to the
host directly.
● Resolved an issue where Directory Lists, Files Lists, and File Extension Lists were
showing duplicate entries on the "Assigned To" tab.

Anti-malware report issues – an issue where the URL links in anti-malware and attack
reports were displaying no information was resolved
User interface issue - an issue where some UI items on DSM accept non-ascii characters
was resolved
Japanese language support – improvements designed to support a Japanese version of the
product were introduced
DEEP SECURITY AGENT

Payload inspection issue (Windows version only) - an issue where the Deep Security
Agent process would crash on if an invalid PKCS12 certificate was imported for use
with an SSL configuration was resolved

The following internal enhancements were introduced in this version. Many of these changes
were designed to prepare Deep Security for wider acceptance in the xSP market, address
Common Criteria concerns, and prepare for anticipated changes to supported operating systems.

Improved heartbeat performance – code optimizations resulted in a 10-fold increase in
the rate at which heartbeats can be processed
Enhancements to key operations – code optimizations in the following processes have
resulted in faster processing times:
● Update (configuration deployment)
● Recommendation scanning
● Activation/deactivation
● Check status
Improved scalability of user interface – changes in the way database indices were used,
and how data was fetched from the database have resulted in improvements in the rate
at which console data, counters, and widgets are loaded
DSM as a Platform [DSaap] – these are internal architectural enhancements designed to
turn DSM into a management platform that can be used by other Trend Micro products.
A Trend Micro Control Manager replacement is planned as the first beneficiary of this
enhancement.
Dealing with full DSM databases and similar disk space issues – in support of efforts
to obtain Common Criteria EAL +4 certification, this audit data loss prevention feature
deals with situations when the audit trail on the DSM database is full, or the database
encounters disk space issues.
Web Services API support for Trend Micro Control Manager – this enhancement
allowed Trend Micro Control Manager 5.5 to extract information the Deep Security
database for use in its management console.
DEEP SECURITY VIRTUAL APPLIANCE

Expanded fast-path usage – Firewall and Stateful configuration functionality on the
DSVA have been moved to the fast-path driver on the ESX hypervisor. See Protecting
virtual environments for additional details

Leverage faster slow path communication channel – to improve processing

performance, the DSVA now maximizes a faster (4GB/s) communication channel to
the VA-resident slow path driver. This channel was introduced in VMware ESX 4.1. See
Protecting virtual environments for additional details
Manual scan failure issue – in version 7.5, if a manual scan includes certain large logs, the
scan will either fail or never complete. This issue has been resolved.
DEEP SECURITY AGENT

Enhanced packet processing flow – This change applies to both the Deep Security Agent
and the Deep Security Virtual Appliance. Before version 6.0, Deep Security
implemented a feature that modified potentially malicious packets to render them
harmless. This was a feature that was later found to cause unnecessary latency, so it fell
into disuse. However the code that enabled the feature was retained. In DS 7.5 SP1, this
unused code was removed, thus eliminating the need to re-fragment packets prior to
releasing them to the protocol stack. The result is improved throughput.
Separation of packet decoding logic from layer 2 driver – agents use platform specific
drivers to intercept traffic entering its host’s protocol stack. Windows-based agents use
NDIS drivers, Linux-based agents interface with the Netfilter API, and the driver for
Solaris-based agents interface with netinfo (pfil). In previous versions, responsibility for
decoding packets was given to these platform specific drivers. In DS 7.5 SP1, this
responsibility has been transferred to a new common, platform-agnostic, layer that
resides above the Layer 2 drivers. This was designed to reduce the effort required to add
IP6 support in future versions.
2.3 > Product overview

Trend Micro Deep Security is a centrally-managed host intrusion detection and prevention
system that consists of the following elements:
Port: 80 / 443
(HTTP / HTTPS)
Trend Micro
Update Server
Deep Security
Relay
Port: 80 / 443 Port: 80 / 443
(HTTP / HTTPS) (HTTP / HTTPS)
Optional
Port: 4120
(SSL)
Named pipes
or TCP
Deep Security Deep Security
Database Manager Agent
Port: 4118
(SSL)
Web server
Port: 4119
(HTTPS)
DSM
Management
console

Each component will be discussed in detail in their respective sections. However, they are
described briefly below:
Deep Security Agent (DSA) – this component is responsible all protection functionality on
a host computer. The nature of that protection depends on the rules and security
settings that it receives from the Deep Security Manager.
Deep Security Manager (DSM) – this is the management component of the system and is
responsible for sending rules and security settings to its DSAs. The DSM is also
responsible for generating the DSM management console, and for interfacing with its
database and other network services required for proper operation (e.g., Active
Directory, ESX servers, security center, etc.)
Database – the database contains all persistent information that DSM needs to operate.
This includes configuration details and log information for each individual DSA, and a
multitude of records required for DSM operation.
Management console – this is primary means of administering the DSM network. This
java-based console is generated at the DSM and provides functionality for configuring
security settings and retrieving information about the DSM network.
Trend Micro Update server – this is a security knowledge deployment portal built upon
the content distribution network maintained by Akamai Technologies. Both
ActiveUpdate (AU) and Intelligent ActiveUpdate (iAU) use this facility.
Whenever Trend Micro defines new security rules designed to address emerging threats
or software vulnerabilities, or releases new Anti-Malware components, it makes them
available to its customers via this Website.
Deep Security Relay (DSR) – is a modified DSA that also serves as an update site for the
entire Deep Security network, and is responsible for downloading updates from the
Trend Micro update center. Each Deep Security network needs at least one DSR. While
DSAs can download from an update site if the DSR is absent, the version 8.0 DSM can
only get its updates from the DSR.
NOTE The DSR will not be discussed in detail in this chapter. For additional
information about it, see Chapter 15
2.4 > About Deep Security Agent

The Deep Security Agent (DSA) is responsible for firewall and host intrusion prevention
functionality. This section focuses on DSAs, and is divided into the following sections:
● Agent architecture
● Agent: User mode
● Agent: Kernel mode
● Protection functionality
OPERATING SYSTEM PRIVILEGES

Because of the nature of their operations, DSAs require root or administrator privileges to
their hosts.

2.4.1 Agent architecture

Deep Security Agents can be divided into the
following functionality groups: DSA FILES
The following files make up a DSA
Deep Security installation
Manager
Ds_agent.exe Deep Security
Agent (DSA)
Deep Security
Agent Dsa_control.exe DSA control
utility that
provides a
Agent: User mode command line
interface for
IOCTL IOCTL the agent
Dsc.exe DSA
Agent: Kernel mode configuration
compiler
Ds_agent.crt Contains the

DSA SSL
credentials
Network
Each group will be discussed extensively in their respective sections, but here are their functions
in brief:
User mode – this is responsible for communication with the Deep Security Manager, and
for passing instructions from the manager to Kernel mode via IOCTLs
Kernel mode – this is responsible for implementing manager instructions – or rules – and
turning them into actual security functionality.
As shown in the diagram, both groups communicate by way of I/O controls (IOCTL). It must
be noted that although arrows in the illustration appear to be going in both directions, these only
refer to the flow of information. Responsibility for initiating the exchange is always the User
mode. The kernel does not actively communicate with the User mode.
In Linux-based DSAs, IOCTLs use the following communication channels.
/dev/dsa – for configuration, commands from user mode to the kernel, and logs in return
/dev/dsa_ssl – dedicated channel for SSL master key decryption requests from driver to
user mode
/proc/driver/dsa – used for sending statistical information, module version information,
etc
DSAs start differently on different platforms. On Windows-based machines, the Windows
Service Control module is responsible for loading both components.
Linux-based systems use separate scripts to load components. These are shown below:
/etc/init.d/ds_filter – selects appropriate kernel driver for environment and loads using
insmod

/etc/init.d/ds_agent – checks if driver is already loaded, and then loads the user-mode
component
2.4.2 Agent: User mode

The user-mode group is responsible for Manager-Agent communication. It is composed of the
following sub-modules.
Deep Security Manager
User Mode
Protocol
Incoming Manager Communication Outgoing Manager Communication
Manager Command Responder
Configuration SSL session key Autonomous

Audit storage
builder decryptor operations
Configuration
Audit analysis
compiler
Audit reader
Configuration SSL session key Audit buffer

interface management
DSA: Kernel
Protocol – this works the same way the protocol sub-module on the Deep Security Manager
does. It is responsible for sending and receiving the XML messages that make up
Manager-Agent communication.
Incoming Manager Communication – handles requests received from the Deep Security
Manager
Outgoing Manager Communication – initiates communication with the manager either as
part of a heartbeat or when an Event occurs
Manager Command Responder – Deep Security commands are essentially requests sent
to this agent component. Its acts as a server, providing security services as requested.
Configuration builder – once the protocol module receives a message from the Deep
Security manager, it passes the information in the message to Configuration builder,

which then assembles the information into an XML file that is passed to the
Configuration compiler.
Configuration compiler – this component (dsc.exe) takes the XML message that the
Configuration builder generates and then compiles it into a binary file that the Kernel
Mode component of the Agent uses.
Audit reader – this retrieves event information from the kernel module’s event buffer. This
Audit analysis – this component analyzes information contained in the event
Audit storage – this is responsible for storing the event for later retrieval by the DSM
Autonomous operation – this component monitors the agent host clock for changes,
network interface and firewall status.
SSL Session Key Decryptor – this component is responsible for decrypting SSL traffic in
preparation for analysis by Deep Packet Inspection functionality
2.4.3 Agent: Kernel mode

As this group’s name implies, this part of the agent operates at the operating system kernel level.
It contains the agent’s security functionality and consists of the following modules.
DSA: User mode
Configuration SSL session

Audit reader
builder key decryptor
Kernel
Configuration SSL Session Key

Audit Buffer
interface Management
Network Firewall & DPI functionality Application
NOTE For details about the modules responsible for Firewall and DPI functionality, see
Chapter 4.
Configuration interface – this component is responsible for retrieving configuration

information from the configuration file compiled by the Configuration builder. This file
contains the rules that the firewall & DPI functionality components enforce
SSL Session Key Management – this is the kernel mode interface to the User mode SSL
session key decryptor
Audit Buffer – Security events that kernel modules create are stored here, for later retrieval
by the User mode component of the agent
Firewall and DPI functionality – this component, which is discussed later, is responsible
for network traffic analysis

2.4.4 Protection functionality

Deep Security Agents offer the following security functionality: firewall, deep packet inspection,
integrity, and log inspection. These four functions can be grouped as follows:
Firewall
HIPS functionality
Deep Packet Inspection
Integrity Monitoring
HIDS functionality
Log Inspection
HIPS functionality
For traffic analysis, the DSA intercepts network traffic destined for, and originating from, the
DSA host. The diagram below shows how the interception is accomplished.
Application
Transport layer
Network layer
Data link layer Redirect DSA Driver
Physical layer
(NIC)
Network
The layers in the diagram represent the bottom four layers of the OSI model. The bottom-most
layer, the Physical layer, represents the network interface card, while the top-most layer in the
diagram is the Transport layer, which is where packets are reassembled for use by the application
to which they were sent.
As shown, the agent uses a driver which is bound to the Data Link layer. This permits the agent
to scan network traffic for malicious content – immediately after it arrives at the NIC.
Tip When a computer starts up, drivers in the Data Link layer are loaded before the
rest of the operating system. This ensures timely protection even during a re-start.

The manner, in which traffic is intercepted and then redirected to the driver varies from platform
to platform. The following table presents OS-specific differences for this function.
Operating System Method

Microsoft Windows platforms NDIS driver
Linux platforms NetFilter API
Solaris platforms IP filter (pfil) or Netinfo
On Windows systems, the driver is written according to the Network Driver Interface
Specification (NDIS), and appears in Local Area Connection properties, as shown below.
Drivers for Linux-based DSAs hook into the Linux kernel Netfilter API. This API provides the
following hooks for security applications that need access to network traffic traversing the
kernel.
Layer 1 Pre-routing Routing Forward Post-routing

Layer 3
(Network) hook decision hook hook
The driver intercepts incoming traffic at the pre-routing hook, and outgoing traffic at the post-
routing hook.
NOTE Intercepting traffic at the pre-routing hook, before the routing decision phase
where the kernel decides whether or not the packet was actually meant for the host,
means that the DSA operates promiscuously – analyzing any and all traffic that arrives at
the NIC with no regard for its destination. This is true for all DSAs regardless of platform.
Solaris-based DSAs use IP filter (pfil) or Netinfo interfaces to the Solaris kernel. The latter is
available on the more recent versions of the kernel.

This driver does not exist for DSAs on the HPUX and AIX platforms since these do not have
firewall and Deep Packet Inspection functionality.
HIDS functionality
Host analysis functionality involves monitoring pre-defined system areas for changes, and then
notifying the DSM of these changes for later analysis.
Event
Deep notification Deep
Security Security
Manager Agent
Detect
change System
area
These features can also serve to either confirm the effectiveness of HIPS settings, or alert the
administrator of protection gaps.
Anti-Malware functionality
In version 8.0, the DSA incorporates the Anti-Malware Solution Platform (AMSP), which gives
it access to various scan engines that detect and remove malware.
Deep Security Agent
Anti‐Malware Solution Platform
VSAPI SSAPI DCE
Web reputation functionality

Web reputation functionality blocks access to malicious or potentially malicious Websites, thus
protecting the DSA host against a Web-based attack vector.
Browser DSA Website

X

2.4.5 Agent settings

DSAs store their rules and security settings in a file called config.bin. This is a binary file created
by the Deep Security Agent Configuration Compiler (dsc.exe) using the process shown below.
DSM host DSA host
XML
message
Deep
Deep Security Agent
Security ds_agent.config
(ds_agent.exe)
Manager
Deep Security Agent

Config.3bc Configuration Compiler
(dsc.exe)
Used by
config.bin NDIS driver
Settings arrive from the Deep Security manager in the form of XML messages. After the DSA
receives this message, it generates an encrypted version of the message, called config.3bc, and
stores this on disk. This security measure protects the information contained therein, and makes
the file unique to this particular agent. The latter is made possible because the private key used
for encryption incorporates hardware information (e.g., MAC addresses, etc.).
The configuration compiler converts config.3bc into the binary config.bin file, and then deletes
config.3bc. Each time the DSA starts up, it loads config.bin so that it gets it applies the correct
settings.
2.5 > About Deep Security Manager

The Deep Security Manager allows network administrators to configure their Deep Security
networks from a central location. This section focuses on the Deep Security Manager and is
divided into the following sections:
● Manager architecture
● Web client
● Manager core
● Agent communication
2.5.1 Manager architecture

The following modules work together to provide Deep Security Manager functionality.

Security Center (Internet)
Browser Web client Database

Manager core
Other
(Active Directory,
Email SMTP
VMWare, etc.) notifications server
Agent
communication
Deep Security
Agent
Each module will be discussed in detail in their respective sub-sections, but they are introduced
briefly below:
Web client – these modules are responsible for generating the DSM Web console
Manager core – as the name implies this is responsible for the bulk of DSM functionality,
to include command queuing and deployment, database access, downloading updates
from the security center, to interfacing with various network services (e.g., SMTP, Active
Directory, VMware servers, etc.)
Agent communication – this is responsible for establishing and maintaining the
management relationship with Deep Security Agents.
2.5.2 Web client

This component is responsible for generating the DSM Web console, and for implementing
access control. It consists of the components shown below.

Browser
Web client
Web server (Tomcat)
Static Webservice
images API
Dynamic
images Model-View-
Control
(MVC)
RPC
Manager core
The DSM uses a Web console. Consequently, it needs a Web server to serve the console to its
administrators. For this purpose, DSM uses a built-in, Tomcat-based, Web server. When
accessing unsecured resources, such as static images, the Web server assumes responsibility for
displaying these items on the console. However, for dynamic content and secure resources where
user permissions are a consideration, the Web server passes the relevant information to the
Model-View-Control (MVC) GUI architecture for processing. It then displays the information
that the MVC returns.
For additional information about the MVC architecture, see Appendix A: Deep
dive information > Chapter 2: Product overview > About the Model-Control-View
architecture.
Dynamic images consist of graphs and charts generated by Model components. While the RPC
sub module generates XML documents required by AJAX features used on the browser.
The Webservice API allows third-party applications, written in accordance with API guidelines, to
obtain information from the Deep Security database. The API uses its own access methods, and
is separate from the MVC.
2.5.3 Manager core

The Manager core is responsible for data processing, storage, and security functionality, and
consists of the following sub-modules.

Autonomous
operation
Commands - is responsible for processing all configuration requests, security checks, and
validation logic processing.
Audit - handles storage and management of events (system, agent, DPI, and firewall events.
It works in conjunction with the Web client and Agent communication modules for data
usage and collection.
Alerts - analyzes system data to generate, maintain, and resolve alerts. It works with the
Email notification module for SMTP alerts. Its primary role is to provide administrators
with a list of actionable issues to resolve.
Autonomous operation - responsible for non-user-driven “housekeeping” functions. These
include performance of scheduled tasks, session management, password expiration, and
the like. It is also responsible for the job queue – a to-do list for the outgoing agent
communication sub-module of the agent communication module.
Security center interface - used to access the Trend Micro security center. This module is
responsible for all aspects of security center access from authentication to session
management.
Security - manages authentication, identification, and access control functionality. All user-
initiated actions go through this module for approval, before accessing middleware
functions.
Middleware - provides an interface for all persistent (stored in the database) data on the
Deep Security system. It contains all the operating logic required to maintain data
consistency.
Persistence layer - directly interfaces with the Deep Security database, and is compatible
with a variety of JDBC-compatible databases.

2.5.4 Agent communication

The Agent communication module is directly responsible for Manager-Agent communication. It
consists of the following sub-modules.
Agent communication
Manager core
Manager core
(Audit)
Agent jobs (Active, Update, Upgrade, Heartbeat) (Autonomous
operation)
Incoming agent communication Outgoing agent communication
Protocol
Deep Security Agent
Agent jobs – contains the logic for a variety of agent operations to include: activation,
update, upgrade, and heartbeat. Certain outgoing jobs that it sends out are in response to
requests from the Autonomous operations module of the Manager core.
Outgoing agent communication – processes messages destined for the agent
Incoming agent communication – receives messages from the agent
Protocol – this module encapsulates messages in an XML file and sends them to agents.
2.6 > Management console

The Deep Security Management console is a Web-based console generated by a Tomcat Web
server as shown below.
Tomcat servlet folder
Deep Security
Browser Tomcat
Manager
servlets
The management console is discussed in greater details in Chapter 12.
For additional information about Javascript dependencies, see Appendix A:

Deep dive information > Chapter 2: Product overview > Javascript and the
management console.

2.7 > Database

The Deep Security Manager (DSM) is a database application. It relies on a relational database to
store its various configuration settings, security information (e.g., filters, etc.) and as well as data
that is receives from its Deep Security agents.
This section focuses on the Deep Security database, how it works, and best practices for
administration. It is divided into the following sections:
● Installation options
● Database operation
● Backup & recovery
2.7.1 Installation options

During installation, Administrators are given the option to use the embedded database or an
external database with their DSM servers. Both options are discussed in the following sub-
sections:
● Using the embedded database
● Using external databases
Important: The embedded database is only recommended for testing purposes, and for no
more than 50 agents. In some environments issues are encountered when a DSM has more
than 10 agents. All production environments should use external databases.
Using the embedded database

If the DSM administrator opted not to specify a
database during DSM installation, the installation ABOUT APACHE DERBY
program installs an embedded database based on For additional information about
Apache Derby. Apache Derby, refer to the Apache
Software Foundation Website,
particularly the following URL:
NOTE Deep Security 8.0 uses Derby
http://db.apache.org/derby/papers/
10.5.1.1.
DerbyTut/embedded_intro.html
As described in the reference in the note above, the

embedded Derby database co-exists with DSM within the same Java Virtual Machine. This
architecture is shown below.

JVM
Deep Security
dsm.properties
Manager
JDBC
Derby Database
engine files
As shown in the illustration, the data storage architecture involves the following components in
addition to Deep Security Manager:
dsm.properties – the DSM properties file configures DSM to use the embedded database.
This can be found in the following location:
. . . Deep Security Manager\webclient\webapps\ROOT\WEB‐INF
JDBC – DSM uses Java Database Connectivity (JDBC) to access its database. This is true
for the embedded database as well as the external database.
Derby engine – named derby.jar, this component is responsible for database functionality.
Files related to the Derby engine are stored in the following location:
. . . Deep Security Manager\webclient\webapps\ROOT\WEB‐INF\lib
Database files – these files store the information in DSM database tables. These files are
stored in the following location:
. . . Deep Security Manager\dsm\seg0
For information about how to migrate a DSM from an embedded database to an

MS SQL database, see Appendix A: Deep Dive Information > Chapter 2.
Using the external database

The Deep Security Manager is compatible with the following JDBC compatible third-party
databases:
● Microsoft SQL
● Oracle

USING WINDOWS AUTHENTICATION

By default, the DSM installer uses SQL authentication. To use Windows authentication,
click the Advanced tab, and enter the account domain in the field below.
Note that the domain field might not be visible upon opening the Advanced screen.
Select Named Instance to reveal the field and then enter the domain. If you are need to
use the default instance, simply re-select Default after entering the domain.
The data storage architecture implemented when DSM uses an external database is shown below
JVM
Deep Security
dsm.properties
Manager
Named pipe
or
TCP/IP
JDBC
Database
As shown in the illustration, the data storage architecture involves the following components in
addition to Deep Security Manager:
dsm.properties – the DSM properties file configures DSM to use an external database.
JDBC – DSM uses Java Database Connectivity (JDBC) to access its database. This is true
for the external database as well as the embedded database.
Database – this is the external relational database the DSM uses for data storage
2.7.2 Database operation

This section is divided into the following sections:
● Storing database credentials
● Database selection
● Database communication
● Multi-node operation

● Demo mode
Storing database credentials

Database credentials are stored in the dsm.properties file. When using the embedded database,
this file contains the following parameters:
database.name=dsm
database.directory=C\:\\Program Files\\Third Brigade\\Deep Security Manager\\
database.type=Embedded
These three parameters set DSM to use the embedded database stored in the following folder
structure:
When using the external database, this file contains the following parameters:
database.SqlServer.user=sa
database.name=DSM
database.directory=null\\
database.SqlServer.password=$1$55e98874c689f1dd4cf9b72ca619bf8c09eed5a234513c2dde541e
0d8803060cb305c873951f60f7035ca483d6ab94498dc84989823116dd342a55e8e9513c5659d8d83d9
a47506555a1e5c625be2815c913d52cbea784abdb4923d6e34e63ca4523d88c445d2432955ed8d6c9c9
6bf51dfbfe1ae0b3839ea81dd45e5905947e
database.SqlServer.instance=DSM
. . .
database.SqlServer.namedPipe=true
database.type=SqlServer
database.SqlServer.server=.
NOTE The sample above shows the properties file for a DSM that uses a Microsoft
SQL server. The only difference between the a dsm.properties file of a DSM using an
MS-SQL database and on using an Oracle database is substitution of all instances of
“sqlserver” with “Oracle. For example:
#Fri Aug 28 10:45:16 EDT 2009
database.Oracle.user=dsm_admin
manager.node=1
database.Oracle.server=bh‐oracle10g‐1
database.name=dsm
database.type=Oracle
database.Oracle.password=$1$5bdfd1787ae64e2c34a5927ae07541f887993d5ce4c3903e
d6d951c845a8509c8e1e92da196b59daa81c263da6cdb41228a5510d4d5ee7bf1fbd4ec66845
1200
mode.demo=false

Compared with the properties file for an embedded database, this file contains
additional parameters, namely:
SqlServer.user – this is the user account that DSM uses to access its database. For MS-
SQL databases, the “sa” account is used by default. For Oracle-based databases, this
is the user account used to create the DSM schema.
SqlServer.password – this is the password that DSM uses to access its database.
Tip To change the password, simply enter the new password in this parameter
in plain text. DSM will automatically hash the password when it starts, thereby
protecting the password
SqlServer.instance – identifies the instance of the DSM database on MS-SQL, which

can accommodate multiple instances of databases
SqlServer.namedPipe – determines if DSM connects with its database using either a
named-pipe or using TCP/IP. By default, this value is set to true, meaning it uses
named pipes. Setting this value to “false” sets DSM to use TCP/IP.
Tip Use named pipes only if the database is installed on the DSM server.
Type – this indicates the type of third-party database DSM uses

PASSWORD RECOVERY
Dsm.properties contains the password that DSM uses to access its database. The password
portion for an Oracle database is show below:
#Fri Aug 28 10:45:16 EDT 2009
database.Oracle.user=dsm_admin
manager.node=1
database.Oracle.server=bh‐oracle10g‐1
database.name=dsm
database.type=Oracle
database.Oracle.password=$1$5bdfd1787ae64e2c34a5927ae07541f887993d5ce4c3903ed6d951c
845a8509c8e1e92da196b59daa81c263da6cdb41228a5510d4d5ee7bf1fbd4ec668451200
mode.demo=false
The password is stored in encrypted form.

When the DSM reads this file to retrieve database details, it implements the following logic with
respect to the password:

Fail
No
Read Retrieve Access Access

dsm.properties password database successful?
Yes
Is Yes
the password End
encrypted?
No
Encrypt
password
This design has the following noteworthy implications for troubleshooting:

● If the password for the database changes, Administrators only need to replace the password
field in with the new password in clear text. DSM will automatically encrypt it upon startup.
● If the password is not encrypted, then the database did not accept the password
A troubleshooting flowchart for diagnosing database connectivity problems is

available in Appendix A : Deep Dive Information > Chapter 2.
.
Database communication
DSM supports the use of both local and remote databases. The choice of location affects the
choice of Transport options shown below.

For local databases, administrators can use either TCP or Named Pipes. For remote databases,
only TCP is recommended.
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:
For MS SQL
database.SqlServer.ssl=require
For Oracle
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
MD5 IN ORACLE
Although Trend Micro sought to eliminate use of MD5 in Deep Security, as of writing, this
was reportedly the only algorithm that Oracle supported for encrypted traffic.
M
Multi-node operation
Deep Security allows administrators to link multiple managers into a single multi-node
installation, thus allowing DSAs to failover to alternative DSMs whenever one node. This is

designed to address application-level “high-availability”concerns. This arrangement also allows

DSAs to spread out DSA-to-DSM traffic to different hosts.
In this arrangement, multiple DSM instances share the same database records, thereby appearing
to DSAs as a single manager, but with multiple URLs. This arrangement is shown below.
NOTE Administrators should not go beyond three DSM nodes. Larger numbers have
reportedly resulted in performance penalties.
The following topics will be discussed in this section:

● How the DSA selects its DSM
● Adding nodes to a DSM installation
HOW THE DSA SELECTS ITS DSM

A DSA reconnects with its DSM each time it sends its heartbeat. As will be discussed in Chapter
12, heartbeats can occur anywhere between every 10 minutes to every 24 hours.
During the activation process, and every time it receives a configuration update, the DSA is
furnished with a list of DSMs to which it can connect. Entries on this list can be seen on the
DSA console, as shown below.
NOTE The order in which DSM URLs appear on the list above have no bearing on the
order in which the DSA connects to them.
The sample above shows a DSA with three DSM options. These URLs have been
obfuscated for security purposes.

The DSA randomizes the DSM list with each heartbeat, thereby constantly changing the DSM to
which it connects. This is designed to spread a particular DSA’s communication load across the
different nodes.
Consider the following log trace taken from a DSA in a two-node DSM network. This DSA does
not receive any configuration updates during the course of this test, so all communication is
based entirely on the heartbeat cycle. For security purposes, the hostname and IP address of the
test machines involved have been obfuscated.
00009077 12:02:09 PM [1712] [Beat] Connecting to us‐ca*****12 (10.2xx.xxx.153) on

port 4120
. . .
port 4120
. . .
port 4120
. . .
port 4120
. . .
port 4120
. . .
port 4120
. . .
port 4120
. . .
port 4120
As shown here, the IP address of one DSM ends with the octet “153”, while the other ends with
“150”. The DSM randomization algorithm switches the DSA between DSMs in an irregular
fashion. Connections are generally expected to even out amongst the different node by the 3rd or
4th heartbeat to each node. In this example, connections evened out by the 4 connection to each
node. Here the process took 70 minutes. This interval, however, will vary.
If the chosen DSM is not available at the time of the connection attempt, the DSA will
automatically switch to the next DSM on its list for that attempt. This is illustrated below.

DSM
database

Manager Manager
(#1) (#2)
Connection
failure. Switch
to 2nd DSM
Deep
Security
Agent
In multi-node arrangements of 3 or more DSMs, it is not actually feasible to predict which of the
alternative DSMs the DSA will choose as its secondary DSM. Logs will only show the DSM to
which it successfully connected.
ADDING NODES TO A DSM INSTALLATION

The DSM installation program presents the administrator with the option to setup a multi-node
instance when it detects that DSM related tables are already present on the selected database
server. This selection screen is shown below.
Demo mode
When the Administrator uses the Demo mode option, DSM generates 7-days of fictitious data in
its database which it then keeps current. This mode is not meant to be used on a production
server.
A DSM in demo mode has the following parameter in dsm.properties set as shown

mode.demo=true
2.7.3 Backup & recovery

Administrators are able to create scheduled database backup tasks. However, this can only be
used for the embedded and MSSQL databases. It will not work on Oracle databases.
The backup Derby database will be stored in a folder named after the date and time of the
backup. The SQL server backup consists of backup file with the date and time of the backup as
file name.
As discussed in Using the embedded database on page 39, the Apache Derby-based embedded
database is stored in the following folder:
. . . Deep Security Manager\dsm\seg0
To manually backup the database, copy the contents of the seg0, log, and tmp folders.
NOTE For additional information about Derby database files see:

http://db.apache.org/derby/docs/dev/devguide/cdevdvlp40724.html.

2.8 > Review questions

3. What is a DSM?
a) Dynamic Security Module

b) Deep Security Manager
c) Deep Security Master
4. What is a DSA?
a) Deep Security Agent

b) Dynamic Security Agent
c) Digital Security Assistant
5. Which database is used for the embedded database?
d) Oracle Express
e) MS SQL Express
f) Apache Derby
g) MySQL
6. Which of the following protocols are used for DSM-to-DB communication?
h) RPC
i) Named pipes
j) TCP
k) SOAP
7. Where does the DSM store its database credentials?
a) dsm.properties
b) logging.properties
c) credentials.properties


Chapter 3: Installation
Chapter Objectives
After completing this chapter, you should be able to:
● Understand how to install the Deep Security manager
● Understand how to install the Deep Security agent


This chapter focuses on Deep Security installation and is divided into the following sections:
● System requirements
● Installing Deep Security Manager
● Installing Deep Security Agent
3.2 > System requirements

System requirements for the different Deep Security components are discussed here.
3.2.1 Manager Hardware and Software Requirements

The minimum hardware and software requirements for your Deep Security Manager installation
are shown below.
Component Requirement
Memory 8 GB (Recommended)
Disk Space 1.5 GB free (5 GB recommended)—must be on

an NTFS partition
Operating System Microsoft Windows Server 2008 R2 (64-bit)

Microsoft Windows Server 2008 (32- or 64-bit)
Microsoft Windows 2003 Server SP2 (32- or
64-bit)
Linux:
Red Hat Enterprise Linux 6 (64-bit)
Red Hat Enterprise Linux 5 (64-bit)
Supported Databases Apache Derby database engine (installed by

default)
Oracle 11g
Oracle 10g
Oracle 10g Express Edition
Microsoft SQL Server 2008 SP1
Microsoft SQL Server 2005 SP2 or SP3
Microsoft SQL Server 2005 Express
3.2.2 Web Console Requirements

Deep Security only supports the versions of Firefox and Internet Explorer Web Browsers, as
shown below.
Component Minimum Requirement

Supported Web Browsers Mozilla Firefox 3 or later
Microsoft Internet Explorer 8.0
Microsoft Internet Explorer 7.0

3.2.3 Deep Security Agent / Relay Hardware and Software

Requirements
The minimum hardware and software requirements for your Deep Security Agent computers are
shown below.
Software Minimum Requirement

Memory Agent: 128 MB
Relay: 512 MB
Disk Space 100 MB (200 MB recommended, primarily for

logging)
Operating System Microsoft Windows XP (32- or 64-bit)

Microsoft Windows 2003 (32- or 64-bit)
Microsoft Windows Vista (32- or 64-bit)
Solaris 8, 9, or 10 (64-bit Sparc)
Solaris 10 (64-bit x86)
Red Hat Enterprise 4, 5 (32- or 64-bit)
SuSE Enterprise Server 10, 11 (32- or 64-bit)
AIX 5.3 or 6.1
HP-UX 11i v3
3.2.4 Virtual Appliance Hardware and Software

Requirements
The minimum hardware and software requirements for your Deep Security Virtual Appliance are
shown below.
Software Minimum Requirement

Memory 512 MB
Disk Space 20 GB
Operating System ESXi 5

vCenter Server 5.0.0
For agentless Anti-Malware:
VMWare vShield Manager

vShield Endpoint Security 5.0 (available in
ESXi 5 patch ESXi500-201109001 for vShield
Endpoint driver)
Important: Deep Security uses the VMware VMsafe-Net API to intercept network traffic at the
hypervisor. The VMsafe API is not available in the free version of ESXi.

3.3 > Installing Deep Security Manager

This section focuses on Deep Security Manager installation and is divided into the following
sections:
● Installers
● About the installation log
● Deployment considerations
● Required ports
3.3.1 Installers
There are currently three types of installers for the Deep Security Manager. These are shown
below.
64-bit installers are available for Windows and RedHat Linux distributions. The 32-bit installer is
only available for Windows.
3.3.2 About the installation log

The DSM installation log (install.log) can be found in the following location:
Windows
<Install path>\Deep Security Manager
RedHat Linux (default)
<Install path>/dsm
Unlike other Trend Micro installation logs, the Deep Security installation log is more of an after-
installation report, rather than an action-by-action account what the installer does. For
information about installation logs see Appendix A: Deep dive information > Chapter 3:
Installation.

3.3.3 Deployment considerations

This section presents deployment considerations that DSM deployment plans must incorporate.
It is divided into the following sub-sections:
● GUI requirements
● Database selection
● Database location
● Database communication
GUI requirements
This consideration affects Linux-based DSM installations rather than Windows-based
environments. By default, the DSM installer for Linux looks for the X Windows interface. If
your run the the installer either on a Linux machine with the Graphical User Interface disabled,
or via an SSH client that cannot display the GUI, then the following error will appear
In these environments, you must prepare a properties file that contains the responses to the
installation wizard expects, and use it with the following command:
<installer>.sh ‐q ‐console ‐varfile <PropertiesFile>
For additional information properties file, see Appendix A: Deep dive

information > Chapter 3: Installation > Properties file for unattended
installation.
Smart Protection Network participation

The installation wizard for version 8 includes a new screen to configure participation in the
Smart Protection Network. This screen appears below.

Deep Security Agents that apply Anti-Malware protection can send details about the malware
that they find on their host systems, to Trend Micro to aid in the development of security
solutions and updates.
Administrators can configure participation during installation, and modify their selections
afterwards from within the DSM console.
Database selection
As discussed in Chapter 1, the embedded Derby database was not meant to be used in
production environments and should only be used for evaluation. The Derby database can only
accommodate 50 DSAs or less.
Production environments require either an MS SQL or Oracle database.
Database location
The DSM must be able to maintain a database PING time of less than 2 million nanoseconds.
Any figure higher than this can cause unpredictable problems. The DSM System Information
screen provides information about that connection speed with 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.
Database communication
By default, DSM-to-database communication is not encrypted. When the DSM and its database
are installed on the same host, or when the connection is via a dedicated switch or crossover
cable, this should not be an issue.
However, in other remote database scenarios, this lack of encryption means that database
communication is vulnerable to snooping. In these instances, enablement of encryption
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
Database growth
The following table shows the amount of database space that a DSM typically requires in the
indicated states.
State / description Space required

Fresh install, no computers on Computers list 110MB
Operational DSM with rules, profiles, and, 1GB

updates. No computers on Computers list
Expected database growth per computer 10 – 50 MB
Tip Database space should be pre-allocated to avoid autogrowth. Making 20GB

available is sufficient for most deployments.
Number of DSM nodes

Multi-node installations provide Deep Security networks with failover capability. If one DSM is
busy, or fails, then the rest of the network can fail over to the second. Therefore, whenever
possible, having more than one node is advisable.
For networks with up to 20,000 agents/appliances, having at least two DSM nodes is advisable,
but not required for scalability. Above 20,000, having at least two nodes is recommended. Use
the following rule-of-thumb formula for deciding when it is necessary to add another node.
Number of nodes = Number of devices / 50,000 + 1
Based on actual field experience, administrators should not go beyond three nodes. Going
beyond this recommended limit will result in system instability.
Required ports
When deploying Deep Security in a highly segmented network environment, with multiple
internal gateways and corresponding firewalls, knowledge about the various ports that Deep
Security uses will be useful for preventing unintended functionality disruptions. The relevant
ports, and their directions, are shown below.

HTTPS: 443, HTTP: 80
4118
Deep Security Relay
4122
4120
4119
4118
Browser Deep Security Agent
ActiveUpdate
MSSQL: 1433
Product registration
(olr.trendmicro.com)
80 4122
Oracle: 1521
License information
Trend Micro Database
Virtual
environments 4120
4118
Deep Security Virtual appliance
443
443
443
4119
VMware vCenter Vmware vShield Manager
Network
services 25
UDP: 514
SMTP server Syslog / SIEM
53
Non SSL: 389
DNS server
UDP: 162
SSL: 636
LDAP server SNMP server
The upper part of the diagram shows the interaction between Deep Security components, which
consist of the following:
Deep Security Relay (DSR) – all members of a Deep Security 8.0 network get their
components from Deep Security Relays. This is true for agents/appliances as well as the
DSM. To download updates, DSAs and DSVAs must connect to the relay at port 4122.
The DSM downloads updates over port 4118 using the protocol used for downloading
diagnostic packages. DSRs can either connect to the update server via HTTPS (port
443) or HTTP (port 80).
Trend Micro servers – if the DSM supports legacy version 7.5 DSVAs, then it will
continue to connect to the Trend Micro ActiveUpdate site on port 80. It also uses this
port for license verification

Browser – the management console is accessible via Web browsers connecting to the
manager Web server at port 4119
Deep Security Agent – the manager listens for traffic from the agent at port 4120, while
the latter listens for instructions from the manager at port 4118
Database – the manager can use either a Microsoft SQL or Oracle database. TCP
communication these databases go over ports 1433 or 1521 respectively.
When providing protection for virtualized environments, the following components require the
following ports for the indicated purposes:
Deep Security Virtual Appliance – like physical agents, the DSVA communicates with the
DSM on port 4120, listens for manager traffic on port 4118. and downloads update
components at port 4119. It also sends Anti-Malware functionality status information to
the vShield Manager
VMware vCenter Server – the manager retrieves virtual environment information from the
Center server over port 443, and downloads the filter driver from the DSM at port 4119
VMware vShield Manager – the manager communicates with the vShield Manager to
register itself with the VMware Endpoint Security (EPSec) infrastructure.
The DSM can also interface with the following network services:
SMTP server – this is used to send email notification, and listens for SMTP message at port
25
DNS server – the DSM queries the DNS server for host name lookups at port 53
LDAP server – the manager retrieves LDAP information for user, contact information and
to obtain a list of computers on the network. It can use both non-SSL and SSL-based
communication methods, which use ports 389 and 636 respectively.
Syslog/SIEM – the manager can send event information to Syslog servers and similar
Security Information and Event Management (SIEM) systems. By default it sends these
UDP-based messages over port 514
SNMP server – UDP-based notifications to SNMP servers are sent over port 162
3.3.4 Changes to host

The following table presents the changes that the DSM installer makes on the DSM host.
Operating system Changes
Various Microsoft • By default, DSA files are written to: <install path>\Program
Windows versions Files\Trend Micro\Deep Security Manager
• Register service and driver with Windows Service Control for
service start/stop functionality respectively
• Addition to the Add/Remove programs list
Various Linux • System files:

distributions /opt/dsm – binaries, drivers, and scripts
Note: When performing an attended installation using a

non-root account, the wizard will suggest installing the
dsm directory under usr/local. This, however, is
configurable

• Startup script in /etc/init.d:

Dsm_s

3.4 > Installing the Deep Security agent

One characteristic that makes Deep Security unique in the Trend Micro client-server product line
is the absence of the ability to deploy the DSA from the DSM. Deep Security relies on third-
party software deployment tools for remote installation.
DSA installation options are discussed in the following sub-sections:
● Installers
● Activation
● Upgrades
3.4.1 Installers
Deep Security agents can be installed on a variety of operating system platforms. Each, therefore,
will require their own installation methods. The different installers are discussed in the following
sections:
● Agents for Microsoft Windows
● Agents for Red Hat and SuSE Linux
NOTE Deep Security does not have its own native client deployment mechanism.
Unlike the Intrusion Defense Firewall, which leverage the OfficeScan plug-in architecture,
Deep Security relies on third-party software distribution solutions, e.g., Active Directory,
for large scale deployments. Agent upgrades, however, can be performed from the DSM
console.
Agents for Microsoft Windows

The following MSI-based installers are available for deploying Window agents.
The DSA MSI installation package can be deployed via Active Directory as a GPO.
Tip One method for enabling MSI debug functionality can be found in the following
MSDN article: http://support.microsoft.com/kb/223300
The log that is generated can be found in:
. . .\Documents and Settings\<user folder>\Local Settings\Temp
In addition to the regular DSA installation package, version 8.0 now includes installation
packages for the Deep Security Relay.

Agents for Red Hat and SuSE Linux
All installers utilize the Red Hat Package Manager format, and therefore can be installed using
standard RPM commands.
3.4.2 Changes to host

The following table presents the changes that DSA installers make on the agent host.
Operating system Changes
Various Microsoft • By default, DSA files are written to: <install path>\Program
Windows versions Files\Trend Micro\Deep Security agent
• Register service and driver with Windows Service Control for
service start/stop and load/unload functionality respectively
• Addition to the Add/Remove programs list
Various Linux • System files:

distributions /opt/ds_agent – binaries, drivers, and scripts
/var/opt/ds_agent – data files
• Startup scripts in /etc/init.d:
ds_agent – for user mode component
ds_filter – for loadable kernel module
• Communication channel between user and kernel mode
components:
/dev/dsa
/dev/dsa_ssl
/proc/driver/dsa
3.4.3 Agent activation

To establish a management relationship between a DSM and a DSA, the latter must be activated
from the former. Details of exactly what happens during the activation process are discussed in
detail in Activation basics on page 265. At this point, it is sufficient to know that Activation
registers a DSA with a single, solitary, DSM.
The DSM console control for this is shown below.
Once computers are added to the Computer list, the DSM determines if an agent is installed on
these machines and identifies the ones that have agents, and those that do not.
In addition to activation from the DSM, administrators can also initiate activation from the DSA
host via the agent’s command line interface. The following commands activates the agent

dsa_control /a dsm://<host or IP>:<port>/
or
dsa_control –‐activate dsm://<host or IP>:<port>/
For the command line option to work, the DSM must be set to accept agent-initiated activations.
The control for this functionality is shown below.
Administrators have extensive control over which DSAs are able to initiate their own activations.
Be it based on name or IP address. Self-activated DSAs can even be automatically assigned a pre-
determined Security Profile to ensure at least a minimum level of protection.
To avoid duplication of DSA records on the DSM, the DSM can control Computer list record
creation in the event of duplicate names. In previous versions, the DSM would perform a reverse
DNS lookup for the hostname. Starting in version 6.0, however, the DSM relied on the DSA to
provide its own hostname.
NOTE When the DSA provides it’s own name, it uses its host’s FQDN.
Additional activation considerations can be found in Appendix A: “Deep dive”

information > Chapter 3: Installation > Agent activation.
.
3.4.4 Agent upgrades

While agent deployment requires third-party tools to accomplish en-masse, Agent upgrades can
actually be performed from the DSM management console. The relevant control is shown
below.

Tip The term “update” and “upgrade” are not interchangeable in Deep Security
terminology. An update refers to a configuration change. An upgrade, on the other
hand, refers to the replacement of software with newer version.
Remote upgrades via the console, however, are only supported for DSA versions 5.2, Update 4
or newer. Older versions must be updated manually. The following table presents manual
upgrade procedures for the indicated platforms.
Platform Procedure
Windows Copy the MSI file to the target computer and run it. The MSI will
detect the previous package and upgrade it.
Linux distributions Copy the RPM to the target computer, and run the following
command:
rpm –U <installation file>
The “-U” parameter instructs that installer to perform an upgrade


1. Which of the following package formats are relevant to DSAs?
a) MSI
b) RPM
c) EXE
d) TAR
2. DSAs can be deployed from the DSM
a) True
b) False
3. Can a DSA be activated from the DSA host?
a) Yes
b) No
4. What database should be used in a production environment?
a) MS SQL
b) Oracle
c) Apache Derby


Chapter 4: Detecting hosts

Chapter Objectives
● Explain how Computers are added to the Computer list
● Understand how Deep Security leverages LDAP servers to obtain a list of computers
● Understand how Deep Security obtains its list of virtual machines


Deep Security Manager can only detect vulnerabilities and/or implement security on machines
that are listed in its Hosts tree. A sample tree is shown below.
Populating this tree, and seeing to it that it correctly reflects that composition of the network is a
critical security task. This section focuses on how this functionality works and discusses DSM
features designed to facilitate collection of this information, and is divided into the following
sub-sections
● Detection methods
● Hosts from VMware
● Hosts from LDAP/X.500 directories
● Scheduling discovery and synchronization
NOTE Unlike Trend Micro Intrusion Defense Firewall -- an OfficeScan plug-in based on
Deep Security -- Deep Security Agents cannot be deployed using this tree. In fact, Deep
Security does not have client deployment functionality and requires third-party
deployment tools.

4.2 > Detection methods

Administrators can populate the Hosts tree using the following methods:
Individual host addition –

administrators can add individual
machines to the host list by
specifying them in the New Host
Wizard shown on the right.
Discovery based on IP addresses

– to add multiple machines at
once, administrators specify a
range of IP addresses using the
Discover Hosts feature shown on
the right

Information from LDAP/X500

directory – host information is
imported, and then synchronized
with information on a LDAP server.
Virtual machines in a VMware

system – DSM queries VMware
Center Server for information
about the virtual machines on the
ESX servers that are registered
with it.
Not to be confused with Deep

Security Virtual Appliance (DSVA)
Networks where both physical and virtual machines are listed in Active
Directory will require careful handling. For information see Appendix A: “Deep
dive” information > Chapter 4: Detecting Hosts > Hosts in vCenter and Active
4.3 > Hosts from LDAP/X500 directories

Deep Security Manager can populate its Computers list using computer information from LDAP
servers. This section focuses on how this is accomplished, and is divided into the following
sections:
● How it works
● Supported directories
● Directory-related operations

4.3.1 How it works

To import hosts, the Add Directory Wizard performs an LDAP query to retrieve the necessary
information from the directory and replicate its computer object hierarchy in DSM Hosts, as
shown below.
LDAP query
Add
LDAP
Directory
server
Wizard
Response
Hosts Directory objects
Host Group Root node
Host #1 Computer #1
Host #2 Computer #2
Host #3 Computer #3
After the initial data retrieval, DSM needs to periodically synchronize its host information with
the information in the directory to keep its information up-to-date.
Add
LDAP
Directory
server
Wizard
Clear text connection (port 389)
SSL or TLS (port 636)
Depending on the communication needs of the directory, the wizard can send its query as a clear
text query at port 389, as a secure SSL or TLS connection at port 636.
4.3.2 Supported directories

As of writing, Microsoft Active Directory is the only officially supported directory. For this
reason, many of the default host import settings are optimized for this directory server.
However, it has been tested with the following alternatives:
● Novell eDirectory
● ApacheDS

4.3.3 Directory-related operations

The following Directory-related operations will be discussed in their respective sub-sections:
Import – create hosts based on information found on the directory
Synchronize – add, remove, and update host information based on changes on the
directory
Cleanup – remove or rename hosts are no longer found on the LDAP server (only applies
to directory-types other than Microsoft Active Directory
Remove – remove the directory structure, and remove/modify the affected hosts
Each operation is explained their respective sub-sections.
IMPORT
The import operation copies a list of computers from a pre-selected domain on an LDAP server
– hereinafter referred to as a “directory”. The import operation also collects connection and
LDAP query information, thereby facilitating updates of the list during the synchronization
process, which is discussed separately.
Hosts are imported by way of the Add Directory Wizard. The wizard is found in
directorywizard.jsp and DirectoryWizardBean.java, and is invoked when administrators click the
following button.
The following flowchart shows the phases involved in the initial import of hosts from a
directory.
Verify
Establish
Select administrator’s Import Display
connection with
directory information information summary
directory
schema selection
Each step is explained in their respective sub-sections below.

At the end of this process, the Add Directory Wizard displays a summary like the one shown
below.

The summary includes the following information:

Number of hosts that were imported
List of hosts that were renamed during the import – contains both the original name
listed in the directory, and the new name created during importation. Renamed hosts
will have issues and therefore require corrective action.
List of hosts that could not be imported – contains hostnames, and the reason they could
not be imported are listed here
Important: To correct importation problems, administrators must manually remove the

imported directory, and then try again.
PHASE 1: ESTABLISH CONNECTION WITH LDAP SERVER

The first screen in the wizard is designed to collection information necessary to connect with the
directory. This screen is shown below.

Here the administrator is asked to specify the address of the directory, communication port, and
the access method. Depending on the access method, logon credentials may be required.
Upon clicking Next, the wizard attempts to connect to the directory using the information
provided. If this fails, the wizard does not move to the next step.
If a connection is established, the process of building the directory tree, under Hosts, begins. It
starts with the creation of a HostGroup object like the one shown below.
HostGroup
objects
As shown the name of the directory host group object is Directory – 10.2.34.12. Subsequent steps
in the wizard use this object as the root node for retrieving host information from the directory.
Once retrieved, these hosts will appear on the management console as child objects of this host
group.
PHASE 2: VERIFY ADMINISTRATOR’S INFORMATION SCHEMA SELECTION

The next wizard screen prompts the Administrator to define the information schema of the
directory being accessed. This screen is shown below.
The information supplied here is used to perform an LDAP query, designed retrieve a single
host record using the information supplied above. This is a test to determine if the information
entered is correct. If this fails, then the process ends in an error, and the wizard does not
proceed.
Administrators provide the following information here:

Naming context – this defines the location, or LDAP path of the domain, in the directory
from which hosts are retrieved. A sample is shown below:
dc=test,dc=gtc
This sample above would map to the following Active Directory forest
When information from the root node, obtained in the previous step, contains multiple
contexts, these are presented in a drop-down menu. Alternatively, if there is no context
information in the root node, the drop-down is replaced by a blank field that allows the
administrator to manually enter distinguished name (DN) information.
NOTE In Active Directory, there is only one naming context per forest.
(http://technet.microsoft.com/en-us/library/aa998469(EXCHG.65).aspx)
Directory type – the wizard presents the choice of “Microsoft Active Directory” or
“Other/Unknown”. By default, the wizard checks if the Directory is based on Active
Directory by looking for Microsoft-specific Object IDs (OID) in the supportControl
attribute of the root node. If this attribute, which was retrieved in the previous step,
begins with “1.2.840.113556”, then the wizard assumes that the Directory is an Active
Directory server.
Search filter – the filter restricts the LDAP query to hosts (computers and domain
controllers) and leaves out other objects in the directory (e.g. users, network devices,
etc.). For this filter to work, the object class that corresponds to hosts must be specified.
When connecting to Active Directory, the filter defaults to “objectClass=computer”.
Other directories use different conventions, ApacheDS for example requires the filter
“objectClass=device”. When the directory type is “Other/Unknown”, the filter field
becomes editable, thereby allowing the administrator to define the filter.
HostName attribute – this tells the wizard the three attributes that the wizard needs to
look for to obtain the name of the host. The default syntax, which is optimized for
Active Directory, is as follows:
Windows NT / host name
dNSHostName;name;cn
Fully Qualified Domain Name (FQDN)
Common name
For other directories, the wizard field for this attribute will be editable, and the
administrator must enter the appropriate value. This string indicates the order in which
these attributes are checked, and the first non-null value that the wizard encounters is
used as the host name. However, all attributes specified here must be present. See
below.

Host description attribute – this is an optional field that administrators can use to retrieve
host description information from the directory. It has no default value and the
corresponding wizard field is editable for all directory types.
When the “Next” button on the wizard is clicked the single-host LDAP query is sent to the
directory. The following flowchart shows how the query proceeds.
Begin Last Proceed to

query attribute? bulk import
Use Naming Search for Verify

LDAP query
Context to objectClass hostname Attribute
returns first End wizard
define top of defined by attributes found?
host
search tree search filter (3)
As mentioned earlier Naming context defines the location in the directory that serves as the top
of the search tree, while the Search filter specified the object to retrieve.
For this test, the directory is free to return any object that matches the criteria. The wizard then
cycles through the three hostname attributes and verifies if the host information contains all
three attributes. If any of these attributes are not found, the wizard stops. Otherwise the wizard
proceeds to bulk importation of host data.
PHASE 3: IMPORT INFORMATION

Once the information in the LDAP query search filter is confirmed, the wizard proceeds with
bulk host information importation. The information collected here is used to reproduce the
hierarchy found in the directory. The end result for the sample directory is shown below.
The illustration above maps directory objects with their corresponding objects in DSM, and
presents the following noteworthy points:
● As discussed earlier, the root node of the directory is represented by a Host Group Object
named Directory – 10.2.34.12.
● The Naming Context, dc=test, dc=gtc has been deconstructed, with Host Group objects
assigned to each context component.
● Host objects, namely computers and domain controllers, are imported under the second
naming context group object
The importation process creates records in the following tables of the DSM database.

Both tables contain information about each other’s primary keys, thereby allowing DSM to
determine their hierarchical relationship between directories and the host groups within, when
generating the Hosts tree.
NOTE Host groups that are not associated with directories will have “0” in their
DirectoryID fields.
The actual process of recreating the hierarchy can be broken down into the following four steps:
● Step one: Import LDAP objects
● Step two: Split into component RDNs
● Step three: Reconstruct directory structure in memory
● Step four: Add information to DSM database
NOTE Whenever practical, Wireshark packet sniffer logs will be used to illustrate the
different actions performed in this step.
Step one: Import LDAP objects

The bulk importation process begins with a wholeSubTree LDAP query of the directory, using
the Naming Context define and verified in previous phases. The following Wireshark log entry
records this query.
655 29.310645 10.2.34.113 10.2.34.12 LDAP searchRequest(2)
"DC=test,DC=gtc" wholeSubtree
The sample above clearly shows the Naming Context “DC=test,DC=gtc”. In the sample
directory used to generate the Wireshark logs shown here, this node contained the following
LDAP objects:

Domain controllers
Computers
The following Wireshark log entries show the directory returning all four objects in response to
the query.
663 29.730917 10.2.34.12 10.2.34.113 LDAP searchResEntry(2)
"CN=US‐CALVINMAN10,OU=Domain Controllers,DC=test,DC=gtc"
"CN=US‐CALVINMAN4,CN=Computers,DC=test,DC=gtc"
"CN=us‐calvinman,CN=Computers,DC=test,DC=gtc"
"CN=US‐CALVINMAN11,CN=Computers,DC=test,DC=gtc"
Since the LDAP query returns object information with no regard to their hierarchal relations, it
creates a “flat list” from which DSM needs to re-assemble into its correct structure. This is done
in the next step.
Step two: Split into component RDNs

The process of recreating the directory hierarchy begins the deconstruction of the individual
objects’ Distinguished Names (DN) into their component Relative Distinguished Names (RDN).
The different DSM HostGroup objects are then created based on this information.
Consider the host named us-calvinman4. As shown in the Wireshark log in the previous step, the
DN for this host is:
CN=US‐CALVINMAN4,CN=Computers,DC=test,DC=gtc
The individual RDNs form an ordered list of structured components. With RDNs, from left to
right, defining the hierarchy where the entity itself – identified by the last, left-most, RDN –
resides. This information is mapped to the final directory representation under Hosts as follows:

DC=gtc
DC=test
CN=Computers
CN=US-CALVINMAN4
Once deconstructed, the RDNs for the individual hosts are used to create the hierarchy shown
above. Note that the last RDN is actually the root node of the Naming Context.
Step three: Reconstruct directory structure in memory

In this step, the directory hierarchy is reconstructed using RDN information parsed from the
DNs of the individual hosts. This structure is created in-memory, and then is committed to the
database in the next step.
The relevant DSM function follows the following process.
Create Host
Group Objects
based on last 3
RDNs
No
No
Split DN into Create Host
Do last 3 RDNs
individual Read RDN Object based More RDNs? Next step
already exist?
RDNs on first RDN
Yes Yes
Re-use existing
Host Group
Objects
Step four: Add information to DSM database

Once the directory hierarchy is re-created in memory, DSM then commits this to the DSM
database, particularly the hosts table. The following table fields are populated:
Hostname – the name of the host is the unique/valid name derived from the last RDN in
the DN.
Description - The description is loaded from the first non-null attribute in the
hostDescriptionAttribute list, or an empty string if no attributes were found.
DirectoryDN – The full DN as found in the directory, used for synchronization.
DirectorySyncState – This value records the relationship between the DSM view and the
Directory view of the host. It is initialized to “no change”.
DirectoryUniqueID – Microsoft Active Directory associates a unique id with each node,
and we store this value in DSM to assist in synchronization. For non-AD Directories
this field is blank.

Others – Other Host fields are initialized with reasonable defaults, not specific to the
Directory
SYNCHRONIZE
Administrators have two options for synchronizing DSM host information with corresponding
information on LDAP servers:
Manual – this allows administrators to synchronize directory information on-demand. The
control for this is shown below.
Scheduled task – this sets DSM to synchronize information regularly, without operator
intervention. As shown below, this option is actually presented as an option during the
directory addition process.
Regardless of how the synchronization function is triggered, the underlying process for
accomplishing the task remains the same. This process can be broken down into the following
three phases:
Phase 3:
Phase 1: Phase 2:
Begin
Compare host End
synchronization Create host Access
list with
lists directory
directory
These phases collect information required to detect disparities in the Host information
permitting DSM to correct the inconsistencies.
Phase 1: Create host lists

Synchronization begins with the creation of two lists:
Hosts associated with a particular directory – this is collected to identify the known
directory hosts at the time of the synchronization. It forms the baseline for the
synchronization process.
All DSM hosts – all host names are collected to ensure host name uniqueness when hosts
are added.
Phase 2: Access directory

In this phase, DSM functions access the directory to retrieve an updated list of computers in its
hierarchy. The retrieval process itself identical to the import process used to add the directory to
DSM.
As with the importation process, logon credentials may be required to access the directory
information.
Phase 3: Compare host list with directory

Once the necessary DSM table and directory information have been retrieved, DSM functions
use this information to perform the synchronization process. This phase can be divided into the
following steps:
● Step 1: Identify hosts that need to be updated
● Step 2: Identify deleted hosts
● Step 3: Identify new hosts
● Step 4: HostGroup cleanup
Step 1: Identify hosts that need to be updated

The first step identifies the hosts in the DSM table that are still present in the directory, and
therefore need to be compared and/or updated with the latest directory information. If a
particular host record is present in all three lists assembled in Phases 1 and 2, then that host still
exists in the directory and must be checked for consistency.
The pseudo code for this step is shown below
for each host in DSM
for each host in the Directory
if uniqueIDs match
Hosts match
else if DNs match
Hosts match
else
Hosts do not match
As shown above, DSM host records can be matched with directory records either based on
object GUIDs or with their distinguished names (DN).
NOTE All Active Directory objects have GUIDs. Other LDAP servers, however, do not.
This is why DNs are used as an alternative identifier.
The disadvantage of using DNs is that they change if the host is moved around within
the directory hierarchy, or when they are renamed. For this reason, those two operations
cannot be tracked and will result in new host records and deletion of previous ones.
If a host is found in all three lists the follow fields in the DSA host table (dbo.hosts) are
compared with the information retrieved from the directory.

Step 2: Identify deleted hosts

In this step, hosts that only appear in DSM tables, but are not found in the directory are analyzed
for possible deletion. The following flowchart illustrates the analysis performed in this step.
Delete host
record
Verify agent Is
Begin
state in DSA present or End
analysis
database activated?
Set
Delete
DirectorySynch
DirectoryID
State to “not
information
found”
If the host does not have an activated agent, then it is deleted. However, if the host has an
activated agent, then the host record is retained but its existing directory association information
is removed. Hosts in this state require manual processing discussed in the Cleanup operation.
NOTE Hosts that are matched with their directory counterparts using DN information
instead of object IDs, as would be the case in non-Active Directory LDAP servers, can
experience the non-deletion scenario described above.
Step 3: Identify new hosts

In this step, hosts that are found in the directory but are not found in the DSM table are
imported using the same process used during the directory-addition process. The All-Hosts list
mentioned in step 1 is used here to avoid duplicate host names.
Step 4: HostGroup cleanup

In this step, redundant HostGroups, under the directory HostGroup, that don’t contain hosts
are deleted from the DSM database. HostGroups can become empty if its hosts are deleted or
moved.
CLEANUP
The Cleanup function allows administrators to edit hosts that were orphaned by the dissolution
of the hierarchical relationship with its directory HostGroup object. This can happen with non-
Active Directory LDAP servers where variable DN information is used to map directory objects
with DSM host objects instead of object GUIDs.
If a computer object is renamed or moved on the LDAP server, its DN changes and DSM will
no longer be able to associate this computer with its original host object. As a result, DSM will
create a new record for the renamed computer, and the original record will be given a
DirectorySynchState of “not found” and will require administrator intervention to either: delete
the host, or rename it.

NOTE ”Orphaned”, but activated, DSAs will still retain whatever profiles were assigned
to them to before they were orphaned.
REMOVE
The Remove operation deletes the directory HostGroup from the DSM database. What is done
to the Hosts and HostGroups in the deleted directory HostGroup, however, depend on the
Administrator’s selection in the screen below.
Each option is discussed in detail in their respective sub-sections below.

All three options, however, have the following common results:
● The directory HostGroup object is removed from the database
● Any scheduled task associated with the directory HostGroup object (e.g., a synchronization
task) are removed
● Hosts and HostGroups under the directory are converted to “normal” hosts by removing
the directory reference.
NOTE The synchronization task is automatically deleted from the database because of
a foreignKey relationship between the task and the directory HostGroup object.
Remove directory and all subordinate hosts/groups from DSM

This option removes all objects associated with the directory HostGroup object from the
database. This includes the hosts and HostGroups within.
The pseudo code for this action is shown below:
generate a list of all HostGroup IDs under the top level HostGroup object
generate a list of all Hosts belonging to these groups
for each host in the host list
delete the host
for each group in the group list
delete the group
delete all Directory objects associated with top level HostGroup
Remove directory but retain host data and group hierarchy.

This option preserves the relationship between the HostGroups and hosts contained in the
original directory. The HostGroups then appear directly under Hosts in the Hosts tree.
To accomplish this, records for each Host and HostGroup are updated. The pseudo code for
this action is shown below:
generate a list of all HostGroup IDs under the top level HostGroup object.
generate a list of all Hosts belonging to these groups.
set the DirectoryDN to “”
for each group in the group list
set the DirectoryID to 0
delete all ScheduledTask objects associated with top level HostGroup
Remove directory, retain host data, but flatten hierarchy.

This option deletes all HostGroup information in the original directory HostGroup, preserving
only the Hosts. This would result in all hosts being directly under Hosts in the Hosts tree.
The pseudo code for this action is shown below:
generate a list of all HostGroup IDs under the top level HostGroup object.
generate a list of all Hosts belonging to these groups.
set the DirectoryDN to “”
set the HostGroup to the top‐level group
for each group in the group list (except the top level)
delete the group
set the DirectoryID in the top level group to 0
delete all ScheduledTask objects associated with top level HostGroup
4.4 > Hosts from VMware systems

As a precursor to what eventually became Deep Security Virtual Appliance, developers gave
Deep Security the ability to interface with VMware ESX to import virtual machine information.
This functionality, introduced in version 6, gave the DSM the ability to interact with VMware
Center Server to obtain information about the Virtual Machines that the latter managed.
As with the process for importing hosts from an LDAP server, importing hosts from Center
Server requires the administrator to establish a relationship with the host source. Administrators
accomplish this using the control shown below.

This opens the following screen, which allows administrators to specify the Center Server.
NOTE Starting with version 7, Deep Security will only interact with WMware Center
Server, and not with ESX server directly. This ensures that Deep Security always leverage
Center Server management functionality.



1. Which of the following LDAP servers is officially supported?
a) Novell eDirectory
b) Apache DS
c) Microsoft Active Directory
d) Open LDAP
2. Which of the following is are supported as a means of adding a host to Computers list?
a) Manually add a host

b) Import host list from Active Directory
c) Discover hosts from an IP range
d) Import host list from VMware Center server
e) All of the above
3. If a computer is deleted from Active Directory, it will ALWAYS be deleted from the DSM
Computer list
a) True
b) False


Chapter 5: Applying a
security plan
Chapter Objectives
● Understand the role, and limitations of profiles
● Understand the value of Recommendation scanning
● Understand how to use component lists


The preceding chapters focused on the capabilities of the different security modules. In this
chapter, we will focus on how these features can be combined to implement a host intrusion
prevention plan and how to apply a concept called “virtual patching”. The following topics will
be discussed here:
● About security profiles
● Assessing traffic patterns
● Assessing vulnerabilities
● About components
● About context
● Configuring Anti-Malware functionality
5.2 > About security profiles

Security profiles provide a logical way for replicating security settings to servers and desktops
that share similar security requirements. The following aspects of security profiles are discussed
here:
● Parts of a profile
● Settings precedence
5.2.1 Parts of a profile

View the details of any profile, and you will see something like this:
This tree contains the settings the can be associated with specific profiles. With the exception of
a few minor differences, these are also the same settings that can be assigned to each DSA.
NOTE Anti-malware settings can be specified for all profiles. However in this version,
they only work if the profile is applied to a Deep Security Virtual Appliance.

5.2.2 Settings precedence

The following diagram shows the hierarchy of DSA settings.
Global settings
Profile settings
Host settings
Profiles take precedence over global settings. But host-level settings take precedence over all
others.
A new feature added in version 7.0 allows administrators to view host-level overrides that a
specific DSA may have. The console screen for this is shown below.
At the Computer list screen, DSAs with overrides standout because their profile names are
shown in bold, as shown below.

DSA-specific rules can also be distinguished from profile-assigned rules at the rule list screen.
Profile rules are grayed out, while rules directly assigned to the DSA are clickable.
5.3 > Assessing traffic patterns

Version 7.5 introduced two event logging enhancements that facilitate traffic pattern analysis on
the DSA host. Administrators can use these logs, for example, to decide what ports need to be
opened in the firewall. These enhancements are:
Granular out-of-allow policy logs – logs for implicit denial can now differentiate between
traffic to open or closed ports
New event ID – when “Event ID #142 New connection initiated” is enabled, the DSA will
generate an event each time a connection is added to the DSA state table. TCP
connections, as well as pseudo-connections for UDP and ICMP can generate this event.
NOTE A firewall “allow” will automatically block any traffic that does not satisfy the
allow rule. This is called an “implicit denial”.
5.4 > Assessing vulnerabilities

The following table shows the functionality that administrators can use to assess system
vulnerabilities and formulate their security plans.
Functionality Description Security features that

benefit
Port scanning Detects open ports on Firewall
machines on the network.
This function does not
require a DSA on the target
machine to work
Recommendation scanning Detects applications and/or Deep Packet Inspection

vulnerabilities on machines
on the network. A DSA must Integrity Monitoring
be present and activated on
the machine. Log Inspection
Both scanning functionalities will be discussed in subsequent sub-sections.

5.4.1 About port scanning

Port scanning allows administrators to detect open, and potentially vulnerable, ports on
machines on their company’s network. This functionality can be used for the following purposes:
● Aid in the selection of firewall rules to apply
● Evaluate the effectiveness of existing firewall rules
● When used in combination with malware-specific port lists, detect the ports opened by
malware (e.g.,
The following topics will be discussed in this section:
● Port scanning basics
● Ports to scan
● Scan results
● Scan triggers
Port scanning basics

Deep Security port scans originate from the Deep Security Manager, and works as follows:
Port 1
Port 2
Port 3
Port 4
Port 5
Port 6
Port 7
Deep Security ... Computer
Manager Port X
The DSM checks for open ports by initiating connections with them. If a connection is
established, then the port is identified as open.
Consider the following Wireshark screen capture:

In the example above, the DSM is connecting to a target machine at port 81. Note that unlike
other forms of reconnaissance scanning, it simply uses a TCP packet with the SYN flag enabled.
NOTE The DSM automatically adds its own IP address in the “Ignore reconnaissance” IP
list so that Port scans do not generate reconnaissance scan alerts.
Ports to scan
By default, DSMs scan ports “1” to “1024”. However, as shown below, administrators can use
port lists to scan alternative ports, such as those associated with specific applications or threats.
Consider the following list for ports that are used/exploited by the Back Orifice remote
administration system.

The required ports are well beyond port 1024, and therefore would not be detected in a regular
scan. Port scanning using this port list allows the administrator to diagnose a computer’s
susceptibility to being taken over by this tool.
To prevent the DSM from monopolizing socket resources on its host, it only scans 3 ports at a
time. The resulting sliding-three is shown below.
Port 1
If port “1” is completed
while ports “147” and “2” Port 147 First three ports in job queue
are still in process, Port 2
scanning for port “293”
begins Port 293
Port 148
...
Port X
NOTE Ports in the sliding-three are not sequential.
Scan results
Port scan results are displayed on the target computers details screen, particularly in the Port
Scan section as shown below.
On the DSM database, this information is stored the hostscanports table, as shown below.

Note each time that a machine’s ports are scanned, the scan event is assigned a HostScanID.
Administrators can study the circumstances behind the scan event by looking for the relevant
HostScanID in the hostscans table, which will show all the ports scanned in the event, as shown
below.
Scan triggers
Administrators can initiate port scans in two locations on the DSM console:
● Computers list
● Computer details
COMPUTERS LIST
The screen capture below highlights the Port scan button on the computers list. Initiating the
scan here facilitates analysis of multiple hosts at the same time.

ALTERNATIVES TO DSM PORT SCAN

There are a host of other third-party port scanning tools that administrators can use as an
alternative to native port scanning functionality. NMAP, for example, offers more scanning
functionality and can arguably be deployed with greater ease around the network than the
DSM.
COMPUTER DETAILS
When analyzing or troubleshooting a specific computer, Administrators can choose to initiate
the scan where port scan results are displayed – at Computer details. The specific location is
shown below.
Note that this is found in the Firewall screen of the Computer details screen only. The global and
Profile Firewall screens will not have this option.
5.4.2 About Recommendation scan

Recommendation scans provide administrators with a list of Deep Security rules that need to be
applied to a computer. It creates a guide for how to harden a host using Deep Security features.
This section focuses on this feature and is divided into the following sections:

● Recommendation basics
● Scan triggers
● Assigning DPI rules
Recommendation basics
The objective of a recommendation scan is to provide the administrator with a snapshot of
existing vulnerabilities on a host, and a selection of actions that can be taken to address these
vulnerabilities. This eliminates much of the guesswork involved in configuring security.
The following diagram presents a very high-level overview of what happens during a
recommendation scan.
Deep Deep
Security Security
Manager Agent
Query host information
Collect host
metadata
Return host information
Identify
recommendations
that apply to host
Rule configurations
This sample is based on an on-demand scan, which is triggered with the following management
console control.
Scans can also be triggered by the following events, which are discussed in greater detail in the
Scan trigger section:
Scheduled recommendation scan
The result of the most recent recommendation scan require follow up scans
Important: Steps 1 and 2 of the process can actually occur numerous times in a
recommendation scan. Depending on the result of the scan, the DSM can send “follow-up”

queries to obtain information about system areas whose existence had been confirmed by the
previous recommendation scan.
While the way the scan begins is different, the manners in which they are carried out are mostly
the same.
As shown in the diagram, a recommendation scan can be divided into the following steps:
● Step 1: Query host information
● Step 2: Collect host metadata
● Step 3: Return host information
● Step 4: Identify recommendations that apply to the host
● Step 5: Filter configurations
STEP 1: QUERY HOST INFORMATION

In this step the DSM sends a query to the DSA to initiate the scan. The query includes
instructions as to where on the host the client needs to collect information. These instructions
are based on the detection rules and detection expression that are included in every Security
Update.
STEP 2: COLLECT HOST METADATA

Upon receipt of the query request, the Deep Security Agent collects information about its host
for return to the DSM in the next step. Features within the DSA – called the scanning toolbox –
obtain information from the following sources:
Registry
Running processes
Open ports
FileSystem
Services
This information not only includes information about the host operating system, but also the
applications that are installed upon it. This information is used later in the process to determine
the vulnerabilities that may exist on the host.
STEP 3: RETURN HOST INFORMATION

Once the host metadata is compiled, it is sent to the DSM as an XML-based message. If the
recommendation scan was initiated from the server, the information is returned synchronously
with the query. Otherwise it is sent as part of the regular DSA heartbeat cycle.
STEP 4: IDENTIFY RECOMMENDATIONS THAT APPLY TO THE HOST

Once the DSM receives host metadata from the DSA, it compares this information with the
following security information on its database to identify which rules need to be applied to the
host:
Deep Packet Inspection rules
Integrity monitoring rules
Log inspection rules
Log inspection decoders

For example, if the service information collected from the Windows Service Control Module
indicates that Microsoft IIS was present on the host, then the rules related to this Web server
need to be applied.
The DSM presents the administrator with the option to apply these rules from the following
screen:
As shown above, the console presents the administrator with a variety of filters to manage how
rules are displayed. To facilitate deployment of unapplied rules, administrators can use the Show
Recommended by Not Assigned filter.
The final act of applying these recommendations is not actually part of the Recommendation
scan process. This will be discussed in the next section.
Scan trigger
Recommendation scans are triggered by the following events.
On demand scan
Scheduled or automated recommendation scans
Follow up scans as part of recommendation scanning
As already shown in previous paragraphs, Administrators manually initiate Recommendation
scans by selecting the appropriate DSA from the Computer list and then either clicking the
following button:
Or by right clicking the DSA entry and selecting the appropriate action as shown below.
Recommendation scans can also be set to run as a scheduled task. This can be set as a global
setting, or at the DSA and profile level. The control below shows the scan control for profiles
and DSAs.
Scans that are triggered by other scans can be likened to two workers who are figuring out what
tools are needed for a job. Consider the following:
Worker Worker
A B
What are we working on?
A screw
What type of head does the screw have?
A Philips head
What is the size of the Philips screw?

“We need a #10 Philips
screw driver for this
Size #10
one.
Put the other tools

away.”
Assigning DPI rules

Rules recommended as part of a Recommendation scan can be assigned to DSA in two ways:
● Direct to the DSA
● Via the profile

Both methods have their respective advantages and disadvantages which will be discussed in
their respective sub-sections.
DIRECT TO THE DSA

This can occur when administrators perform individual Recommendation scans and then assign
the rules via Computer > Details.
When the auto assignment feature is enabled, shown below, this also assigns rules directly to the
DSA.
Rules assigned this way override both global and profile-level settings. Maintaining these rules
therefore may become tedious and may eventually require use of the Override function at the
profile.
VIA THE PROFILE

When a Recommendation scan is performed on an individual member of a profile, the
recommendations for the DSA will be reflected on the profile as well. Accepting the
recommendations at the profile level applies the rules to all members of the profile, without
actually assigning them directly to the DSAs.
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. Unless the
network consists of identical machines, assignment-via-profile may be less than ideal.
5.5 > About components

“Components” are lists that contain information that may be re-
used in different rules. These lists obviate the need to manually
enter frequently used data. The different component lists are shown
on the management console as shown on the right.
The following table shows the relationship between these lists and
the different types of rules.
List Anti- Firewall Deep Application SSL Port

Malware rules Packet types configuration scan
Inspection
rules
Directory
File
File
extension
IP list
MAC Lists
Port list
Rule
context
Schedule
NOTE Application types are themselves used as a kind of component list for Deep
Packet Inspection Rules.
The first three lists are used mainly for anti-malware scanning configuration. They can be used to
restrict scanning to specific files or folders, as shown below.
They are also used in scanning exclusions, as shown below.
To illustrate how non-anti-malware related lists are used, test lists named Trend Test List were
created for each type of component list, and then used in a number of test rules. The following
fictitious firewall rule called AA Trend Test Firewall uses lists in the packet source, schedule, and
rule context fields.
As shown above, the IP, MAC, and Port lists can be used to define packet source and
destination. The Schedule and Rule Context lists can be used in the Options tab of a custom
rule.
The Port list, as shown below, can be used to form the basis of Port scanning functionality.
Port lists can also be used as a parameter for Application Types as shown below.
5.6 > Contexts

The Contexts component is responsible for location awareness functionality. It allows the
administrator to specify which firewall and DPI rules apply based on a DSA’s location relative to
the corporate network.
The following contexts are included with the product by default.
Both the Off Domain and Remote Domain VPN contexts use the DSA host’s domain controller
as their reference servers. This behavior is specified using the control shown below.
The Interface Isolation option refers to network interfaces that are affected by the Interface
Isolation feature, shown below.
This feature forces the DSA host to use only one network interface, thereby facilitating
protection. This is particularly useful for laptops that have wireless functionality as well as a
network connection.
A context that uses the Interface Isolation option will apply to interfaces that have been disabled.
This is useful for Allow and Force Allow rules.
5.7 > Configuring Anti-Malware functionality

This section presents information that administrators will need to configure the anti-malware
component of their security profile, and is divided into the following sub-sections:
● The relationship between scan types and scan configuration
● Exclusion lists
5.7.1 The relationship between scan types and scan

configuration
An important point to remember with Deep Security Anti-Malware functionality is the
separation of the following concepts:
Scan types – these refer to how scans are triggered. As will be explained in Scan types on
page 220, there are three types: Real-time, Manual, and Scheduled.
Scan configuration – this defines how the scan is performed (e.g., what is scanned, what
action is taken upon malware, etc.)
Scan
Scan type
configuration
(When to scan?)
(How to scan?)
Anti-Malware
setting
NOTE In other Trend Micro products, scan types and configuration are inseparable.
This design gives administrators the ability to define multiple scan configurations that can be
assigned to the different scan types as warranted.
By default, Deep Security includes the following scan configurations.
Important: Scan types can accept any scan configuration. The names assigned to the default
scan configurations are, therefore, merely suggestions.
5.7.2 Exclusion lists

Malware scanning is a resource intensive process that can cause latency on the protected system.
Administrators, therefore, must strive to achieve a balance between security (e.g., scan everything
and anything that happens on the system), and performance (e.g., scan only likely areas of
attack). This is a decision that only system administrators can take based on their assessment of
the threats to their systems.
Important: Scan exclusions create potential security gaps and must be created with care.
To better enable system administrators to select files and folders for exclusion, this section is
divided into the following sub-sections:
● Guiding principles
● Specific recommendations
Guiding principles
System areas that are prime candidates for exclusion are those folders and/or files that accessed
very frequently during the normal course of operation. Log and database files, for example, are
samples of these system areas.
Files that are already protected by other security products, for example mailbox files of email
systems that are already protected by products like Trend Micro ScanMail, can also be excluded
from scanning.
Scan exclusions need not apply to all types of scanning. Administrators can choose to exclude
files from real-time scanning simply to avoid performance issues, but then configure scheduled
scans that inspect these files, during off-peak hours.
Specific recommendations
The following table presents suggested entries for scanning exclusion lists. Only commonly
excluded files and folders are presented here. Ultimately, administrators must determine what
systems are present in the VMs that Deep Security is protecting, and apply scanning exclusions
based on the principles laid out in the previous section.
Important: The Best Practices Guide for Deep Security, maintained by the technical support
organization, offers a more extensive, constantly updated, list of suggested exclusions. The
list below is merely an example of what areas are excluded.
Description Files or folders

General exclusion For VMs with Windows operating systems, the following files can be
for all Microsoft excluded:
Windows platforms
Pagefile.sys
PST files
<Windows folder>\System32\Spool
<Windows folder>\SofwareDistribution\Datastore
<User profile>\NTUser.pol
<Windows folder>\system32\GroupPolicy\registry.pol
Mapped drives / Real-time scanning in DS 7.5 can scan mapped drives and shared folders
shared folders that are accessed. This may cause additional network traffic during
these events. Consider excluding these shared resources if they already
protected by other anti-malware products (e.g., OfficeScan, etc.)
Microsoft IIS Web server log files change very frequently, and are therefore often
candidates for exclusion. By default, these logs are found in the
following location:
<drive>:\WINNT\system32\LogFiles
<drive>:\WINNT\\system32\IIS Temporary Compressed files
Microsoft On VMs that host MS Exchange servers, exclude the directory, or
Exchange Server partition, where it stores its mailbox. Use anti-malware applications like
Trend Micro ScanMail for Exchange to protect against malware in email.
Installable File System (IFS) drive M must also be excluded to prevent
the corruption of the Exchange Information Store
Key folders per version
MS Exchange 2010 See: http://technet.microsoft.com/en-

us/library/bb332342.aspx
MS Exchange 2007 See: http://technet.microsoft.com/en-
us/library/bb332342(EXCHG.80).aspx
MS Exchange 2003 <drive>:\EXCHSRVR\MDBData
<drive>:\EXCHSRVR\MTAData
<drive>:\EXCHSRVR\Mailroot
<drive>:\EXCHSRVR\SrsData
<drive>:\EXCHSRVR\MdbDataUtility
<drive>:\WINNT\system32\InetSrv
MS Exchange 2000 <drive>:\EXCHSRVR\MDBData

<drive>:\EXCHSRVR\MTAData
<drive>:\EXCHSRVR\Mailroot
<drive>:\EXCHSRVR\SrsData
<drive>:\WINNT\system32\InetSrv
MS Exchange 5.5 <drive>:\EXCHSRVR\IMCData

<drive>:\EXCHSRVR\MDBData

1. Which of the following security features benefit from Recommendation scanning?
a) Firewall
b) Deep Packet Inspection
c) Integrity Monitoring
d) Log Inspection
e) All of the above
2. Can administrators specify the ports that are scanned as part of a port scan?
a) Yes
b) No
3. Which of the following can trigger a recommendation scan?
a) On demand scan
b) Scheduled scan
c) Follow up scan requested as part of the recommendation scan
d) All of the above
4. Which of the following is used as a reference for location awareness functionality?
a) Web server
b) DSM
c) Domain controller
d) A specific IP address
5. Which security features uses all of the component lists?
a) Firewall
c) Application types
d) Port scan
Chapter 6: Protection basics

Chapter Objectives
● Understand how Deep Security features work together to protect their hosts
● Distinguish between HIPS and HIDS functionality
● Understand how packets are intercepted and analyzed
6.1 > Understanding the threat

Computer or corporate network protection is analogous to physical office space security. Assets
within the office, particularly those of interest to criminals and competitors, must be kept out of
reach from these groups, yet remain accessible to authorized individuals (e.g., asset owners,
employees, etc.)
Walls keep unauthorized individuals away from these assets, while secured doors grant
employees access.
Prohibited
Prohibited
Allowed
The unavoidable presence of a door means that there will always be a way for unauthorized
individuals to enter. Therefore if the security features of the door prove insufficient, an inventory
of assets will at least identify whatever is stolen or damaged, thereby facilitating post-mortem,
forensic, and recovery efforts.
That, in a nutshell, is the kind of protection that Deep Security provides to the computers it
protects. It features:
● A firewall to block unauthorized traffic
● Packet inspection to ensure that traffic that is allowed does not contain malicious content
● Log inspection and Integrity Monitoring functionality to detect successful intrusions
6.2 > Defending against the attack

The first section of this chapter introduced the office analogy for computer security. Here we
will dissect the different security elements of that office and map them to Deep Security features.
Consider the following office layout.
Wall
Prevent unauthorized
access to the room
Equipment inventory
Items that should be in
the room
Door
Controls who can enter
the room
Visitor guestbook
Records visitors and
their purpose
The four control elements shown above work together to secure the office. Deep Security
protects computers much the same way.
The four elements shown above can be mapped to four Deep Security features shown in the
table below:
Room feature Function Maps to Deep Security

feature
Wall Keeps people who are not Firewall
involved in the meeting out
Door Selectively lets people, who Deep Packet Inspection

are involved in the meeting,
in and out
Equipment inventory Used to detect changes in the Integrity monitoring

contents of the room
Visitor guestbook Keeps track of what events Log inspection

occurred in the room
Each feature is explained extensively in their respective sections. But here are their functions in
brief:
Firewall – this defines what types of traffic, to and from, the protected machine are allowed
or denied. Rules can be applied based on a combination of protocol, port, direction,
interface, and host identification triggers.
Deep packet inspection – this performs analysis on traffic that is allowed actually allowed,
to prevent or detect attacks that are masquerading as legitimate traffic. This can address
traffic that may be designed to exploit a specific vulnerability on a host.
Integrity monitoring – this feature sets the DS agent to monitor pre-defined system areas
for changes. The DSA, however, does not distinguish between legitimate and malicious
changes.
Log inspection – this sets the DS agent to monitor certain system logs for potential
malware-related events.
Deep security features can take one of three actions: allow, log rule violation, or prevent. The
following table shows the actions that the four features can take.
Feature Actions taken upon traffic

Firewall Allow / prevent / log event
Deep Packet Inspection Allow / prevent / log event
Integrity monitoring Log event only
Log inspection Log event only
Information about how Deep Security protects against an attack process is

available in Appendix B.
6.3 > Inline vs. Tap mode

DSAs can implement two modes for intercepting network traffic at their hosts. These are shown
below.
The packet flow for both modes is shown below.
Inline mode Tap mode
Traffic Traffic
Packet
analysis analysis
From From
network
Packet Application network
Packet Application
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 the inline mode provides
security functionality.
Additional information about Tap mode can be found in Appendix A: “Deep

dive” information > Chapter 6: Protection basics > Tap mode applications.
.
6.4 > Traffic analysis

To be able to detect malicious traffic, the Deep Security Agent must first intercept it. As
discussed in Chapter 2, this task is accomplished via a driver bound to the Data link layer of the
network stack. The redirection process varies between operating systems, but the actual analysis
of the traffic is platform independent, and is the same across all types of DSAs.
Application
DSA driver
Data link layer Fragment Packet

Redirect
analysis analysis
Network Interface
Card
Once traffic is intercepted, the analysis that the driver performs upon it can be divided into the
following phases:
● Phase 1: Fragment analysis
● Phase 2: Packet analysis
Each phase will be discussed in their respective sections.
IP6 support in version 8 resulted in separate analysis tracks for IPv4 an IPv6 traffic. For the
most part, fragment analysis and reassembly work the same way. Differences will be highlighted
in the relevant sections below.
Reassembly
Fragment analysis &
Transition Firewall
(IP4)
(IP4)
DPI, Stateful
Protocol stack
configuration
Reassembly
Fragment analysis &
Transition
(IP6)
(IP6)
There is currently no firewall support for IP6, hence its absence from the IP6 track. DPI and
stateful configuration work the same way for both protocols so they share the same modules.
Because IPv4 and IPv6 networks are expected to co-exist for an extended period, and IPv4
remains the dominant protocol, there will be a need for transition mechanisms that allow IPv6
traffic to go over IPv4 infrastructure. In this version, two mechanisms are supported:
6to4 – this transition mechanism that encapsulates IPv6 packets in IPv4 packets
Teredo – in this transition mechanism IPv6 packets are encapsulated in UDP/IPv4
datagrams
Both methods use encapsulation. To properly analyze traffic, the DSA driver must be able to
access the encapsulated data. For this reason, transition modules were added to the IPv4 and
IPv6 analysis tracks to remove the encapsulation. Additional details are available in the
Transition section below.
6.4.1 Phase 1: Fragment analysis

In this phase, the DSA driver checks individual fragments for pre-defined characteristics that call
for either a block or bypass action – even without full packet reassembly. For example, if the
packet originates from a forbidden IP address, then it is dropped here without further analysis.
NOTE If the routers through which the packet passes do not fragment the packet, then
whole packets will be analyzed here.
This phase applies the following logic:
No
Do packet-level
Intercept Begin
attributes match any block or
packet Phase 2
bypass rules?
Yes
Bypass rule
Which rules does Bypass DSA
the packet match? analysis
Block rule
Drop packet
The modules responsible for implementing the logic shown above are shown below.
Packet
analysis
From packet source Verification Micro filter Blacklist
(Phase 2)
The functions performed in each module are discussed in detail in their respective sections.
Verification
In this step, the driver verifies the validity of the packet. It makes sure that the packet is actually
suitable for analysis. Furthermore, attacks such as the following involve malformed packets that
can be detected by their deviation from protocol requirements, and can therefore be addressed
here:
● Tiny fragment
● Overlapping fragment
● Teardrop
● Ping-of-death (POD)
Tip For additional information about these attacks see Anatomy of an attack >
Performing the attack > Denial of Service on page 460.
Verification is performed on the following aspects of the packet:

● Size
● Header condition
Both aspects have to be in order for fragment reassembly and analysis to proceed. Therefore if
these are malformed, then further analysis is futile and the fragment is dropped.
SIZE
Invalid IP datagram length – Check to confirm that the length of the datagram is not less
than the length specified in the IP header.
First fragment too small – Check to confirm that the first fragment which contains most
of the header information is of a certain minimum size and is not less than the size of
the TCP packet.
Fragment out of bound – Check to confirm that the offset specified in the fragmented
packet is not outside the range of the maximum size of a datagram.
Fragment offset too small – Check to confirm that the offset specified in the datagram
packet sequence is not less than the size of a valid datagram.
HEADER CONDITION
Invalid IP header length - Check to confirm that the TCP header length is valid
No IP header – Check to confirm that the first 20 bytes containing the IP address is not
absent or corrupt.
Unreadable Ethernet header – Check to confirm that there is no Ethernet header which is
not readable.
Invalid TCP header length – Check to confirm that the TCP header length is valid
Unreadable protocol header – Check to confirm that the header is not unreadable.
Unreadable IPv4 header – Check to confirm that the IPV4 header is readable
Unknown IP version – Check to confirm that the packet is either IPv4 or IPv6.
The following non-mandatory checks are disabled by default, and can be enabled from the DSM
management console:
Null IP – Check to confirm that the IP header is not null (i.e., 0.0.0.0).
Deny fragments – Check to deny fragmented packets to come in.

Same src/dst IP – Check to confirm that the Source IP is not the same as the Destination
IP.
The relevant controls are available in System Settings, particularly the Firewall and DPI tab, as
shown below.
Microfilter
Traffic bypass rules are enforced here. Such rules apply to known legitimate traffic that does not
require firewall or Deep Packet Inspection analysis.
Administrators designated analysis-exempt traffic by way of Bypass rules, such as the rule shown
below.
BYPASS VERSUS ALLOW/FORCE ALLOW

Bypass, allow, and force allow rules all let traffic through the firewall. However only
bypass rules exclude traffic from Deep Packet Inspection as well. Once the Microfilter
determines that traffic matches a bypass rule, the remainder of the traffic analysis process
is terminated and the traffic is allowed through to its destination.
Blacklist
At this point, the driver evaluates the traffic to determine if it originates from IP addresses that
have been blacklisted. IP addresses are blacklisted through the Deep Security Reconnaissance scan
feature.
This feature, however, is only available for IPv4 traffic. Blacklisting is not support in IPv6.
Tip For additional information about malicious reconnaissance scans, see Anatomy of
an attack > Performing the attack > Finding a point of entry on page _____.
The DSM management console screen that corresponds to this feature is shown below.
When the Block Traffic option is set to “Yes”, the Blacklist module is responsible for dropping
the packet.
6.4.2 Phase 2: Packet analysis

If a fragment or packet passes all phase 1 checks, the Deep Security Agent proceeds with packet-
level analysis. This phase applies the following logic:
Reassemble No No
DPI / SSL / To
fragments to Firewall rule
Phase 1 Transition Stateful rule Transport
analyze data match?
match? layer
being sent
Yes Yes
No No
Block Block
required? required?
Yes Yes
Drop packet
The sequence for this phase is shown below.
Deep Packet
Fragment
Inspection,
analysis
Reassembly Transition Firewall Stateful Destination
configuration,
(Phase 1)
SSL inspection
The functions performed in each module are discussed in their respective sections.
NOTE Prior to version 7.5 Service Pack 1, packets were re-fragmented to match the
number of fragments that arrived at the Reassembly step, before passing them up the
protocol stack. This was an artifact of a deprecated, pre-version 6.0, ability to
change/delete malicious content in a packet stream. Performance issues led to the
discontinuation of this capability. In version 7.5 Service Pack 1, the associated code was
removed entirely, and the redundant fragmentation step was deleted.
Reassembly
As discussed in the Packet fragmentation thread, fragments are normally assembled at the
Transport layer. However, for traffic analysis to work, Deep Security needs to reassemble the
packets for its own purposes. So if the packet is indeed fragmented (which is not always the
case), this step prepares the fragments for packet analysis later in the phase.
Consider the following illustration based on the analogy used in the Packet fragmentation
section.
#6 #10 #11 #8 #3 #15 #1 #2 #14 #7 #13 #12 #5 #4 #9 #16
m i n t _ a Do B e _ g oSh d
Re-assembly
#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16
Do _ S o m e t h i n g _ B a d
Phase 2: Packet analysis
For firewall and DPI functions in the next phase to recognize the “Do_Something_Bad”
instruction (also called “payload”) in the packet, the unordered packets have to be re-arranged
based on their sequence numbers and then reassembled.
Note that this reassembly happens even before the Transport layer. As a consequence, there is
no danger of applications at the Application layer ever getting the malicious packet before Deep
Security analysis.
Transition
The transition module is responsible for decoding IPv6 transition mechanisms. As discussed
earlier, both 6to4 and Teredo are supported.
There are parallel analysis tracks for IPv6 and IPv4 traffic that converge at a common DPI and
stateful configuration module. Both can independently handle their respective IP versions.
However if the IPv4 track encounters a transition packet, the following happens
Fragment Reassembly Transition Firewall
analysis
(IP4) (IP4)
(IP4)
6to4 or
Teredo
Re-inject into IP6 track DPI, Stateful

configuration
Fragment
Reassembly Transition
analysis
(IP6) (IP6)
(IP6)
The transition module decodes the transition packet and then re-injects it into the IPv6 track for
proper IPv6 processing.
Firewall
With the exception of the Bypass rule, which is applied at the Microfilter, firewall rules are
applied at this point. Firewall rules can filter traffic based on the following characteristics.
Protocol
(TCP, UDP, ICMP, etc.) Direction
(Incoming, outgoing)
Source Destination
(IP address, port, (IP address, port,
MAC address) MAC address)
Packet
TCP header flags

Frame type
(SYN, ACK, FIN, PSH,
(IP, Arp, Revarp, other)
RST, URG)
For additional information about the firewall and firewall rules, see About the firewall on page
158.
Deep Packet Inspection, Stateful configuration, SSL inspection

A single module, the DPI engine, is responsible for the following functions performed in this
step:
● Stateful configuration
● SSL inspection
● Deep Packet Inspection
STATEFUL CONFIGURATION
Stateful configuration functionality monitors connections that traverse the firewall, and ensures
that such connection behave within pre-determined parameters thereby protecting the DSA host
from Denial of Service (DoS) attacks.
There are different Stateful Configuration parameters for different protocols. The following
protocols are supported: TCP, UDP, and ICMP.
SSL INSPECTION
If the packet is part of an SSL connection, the driver will decrypt the traffic to allow Deep
Packet Inspection. This feature, however, requires the administrator to provide the relevant
certificates to permit decryption.
NOTE SSL inspection is not available in IP6. Because of security features built into IP6,
the role of SSL in an IP6 world is currently unclear.
DEEP PACKET INSPECTION

This module inspects the contents of the packet for malicious instructions and other
unauthorized content.
DPI engine Rule match: Drop packet
DPI rule
Shellcode:do_something_bad
Reassembly Fragmentation
Network Packet:do_something_bad Application
process process
For details on how DPI works, see About Deep Packet Inspection on page 176.
6.5 > Host analysis

Host analysis refers to the following Host Intrusion Detection features:
Integrity Monitoring – detects changes to selected system areas (e.g., files, folders, Registry
entries, etc.) for deviations from a baseline
Log Inspection – looks for events that are recorded in selected system and product logs
Both features are designed to detect changes that could indicate an attack on the host that
traffic analysis/HIPS features were not able to block.
Important: Both Integrity Monitoring and Log Inspection cannot distinguish between
legitimate and malicious changes or events.
Both HID features bring these changes and events to the attention of the Deep Security
administrator. The following diagram shows how this is accomplished.
Log
Detect HIDS-
upload via
related log
heartbeat Check for events, or
Deep Deep compare with baseline
Security Security
Manager Agent
Alert
System
Attack
Change detected area
Information about changes and events are stored in SQLLite database files on the DSA, and
then uploaded to the DSM during agent heartbeats. Once the DSM detects logs related to
HIDS functionality, it can generate alerts on the DSM console.

1. Which features constitute HIPS?
a) Firewall
d) Log Inspection
2. Which features constitute HIDS?
a) Firewall
d) Log Inspection
3. One which OSI layer does HIPS functionality operate?
a) Physical Layer
b) Data-link Layer
c) Network Layer
d) Transport Layer
4. Which mode offers no protection?
a) Tap mode
b) Inline mode
5. What firewall rule action is implemented at the Microfilter?
a) Allow
b) Deny
c) Bypass
Chapter 7: About Integrity

Monitoring
Chapter Objectives
● Understand how Integrity Monitoring works
● Know the differences in Integrity Monitoring functionality on different DSA platforms

Integrity Monitoring is a Host Intrusion Detection (HID) feature that detects changes to select
system areas by comparing the current condition of these areas with a hash-based baseline. This
feature allows Deep Security to log events such as those shown below.
Windows event Deep Security Event
The image on the left is the Windows Event log record that was generated when the OfficeScan
Proxy Service was stopped. Since the computer where the event occurred had a suitably
configured DSA, Integrity Monitoring functionality was able to detect the event, thereby
generating the Deep Security Integrity Monitoring Event shown on the right.
This chapter focuses on this feature and is divided into the following sub-topics:
● Integrity Monitoring basics
● Integrity Monitoring operations
● Dissecting an Integrity Monitoring rule
7.2 > Integrity Monitoring basics

Integrity Monitoring works by comparing the current condition of a monitored-object with an
existing baseline.
Deep
Object Security
Agent
Compare
with
baseline
Baseline
This feature can monitor system objects such as, but not limited to, the following
Files
Folders
Registry entries
Processes
Services
Listening ports
NOTE Integrity Monitoring will detect any change that happens to an object. It
currently lacks the ability to distinguish between legitimate and malicious changes.
Baselines are created a number of ways, to include the rule assignment process. The resulting
snapshot is stored in a SQLLite3 DB file on the agent host which is then uploaded to the DSM.
See 7.3.4. Creating baselines for additional information about this DB file.
When a change is detected, the DSM creates a record of the event that is displayed in the
Integrity Monitoring Events screen as shown below.
Each Integrity Rule includes an Alert feature that is enabled using the control shown below.
When an integrity event occurs with a rule that has the alert feature enabled, it will generate an
alert like the one shown below.
7.3 > Integrity Monitoring operations

This section discusses how the following Integrity Monitoring operations work:
● About Integrity Monitoring threads
● Baseline comparison triggers
● Agent-side storage of events
● Creating baselines
7.3.1 About Integrity Monitoring threads

Scanning for Integrity Monitoring changes can be resource intensive operations. File and folder
scans, for example, will result in a significant amount of disk I/O activity. Since the various
Windows flavors cache a lot of the Windows Registry in memory, this has been observed to
result in elevated CPU activity.
To minimize the impact of such scans upon a system, the IM scanning thread is designed to
“give way” to other processes. So for a completely idle machine, a scan could potentially use
100% of system resources. But as soon as another process starts on that machine, then the OS
will free up resources to accommodate the new process. The DSA achieves this through thread-
level scheduling priority.
Different operating systems have different ways of implementing scheduling priorities. For
Windows-based DSA, IM scanning thread is given
THREAD_PRIORITY_BELOW_NORMAL as its base priority. For Unix/Linux based-DSA,
that use POSIX thread APIs (pthreads), the “below normal priority” setting would translate
roughly to the lower 40% mark of the range of possible values – which actually varies with the
specific OS flavor.
NOTE In contrast to Integrity Monitoring threads, threads that read data from the NDIS
driver are assigned “Above normal” priority.
Each object that is monitored (e.g., files, Registry, processes, etc.) is handled by a single thread.
Starting with version 7.5, these threads work sequentially. Previous versions worked in parallel.
Trend Micro implemented this change because of issues with simultaneous access by different
threads.
7.3.2 Baseline comparison triggers

The following events can trigger the comparison between a system object and its baseline:
● Manual trigger
● Real-time OnChange trigger
● Pseudo-real-time OnChange trigger
Manual trigger
Deep Security administrators can initiate an on-demand comparison by clicking the following
control on the DSM console.
Scheduled Integrity scan

Administrators can create scheduled tasks to perform an on-demand scan automatically,
according to a schedule
On-change trigger
This trigger was introduced in version 7.0 and is only available on Windows-based hosts. It uses
the ReadDirectoryChanges( ) function within the Windows API to detect changes.
NOTE For additional information about the ReadDirectoryChanges( ) function, see:

http://msdn.microsoft.com/en-us/library/aa365465%28VS.85%29.aspx
Change
notification
Deep Security
Windows API
Agent
Windows file system
File File
(Original) (Changed)
This functionality is only available for files and folders. All other system objects, with the
exception of the Registry, use pseudo-real-time triggers, which are explained in the next section.
Important: Although the DSA will be able to detect changes as soon as they happen, they will
not be reported to the DSM the next heartbeat.
By default, changes to the DSA’s own database files are ignored regardless of rule settings.
Pseudo-real-time trigger
This feature constantly scans the DSA host for system changes. These scans are performed
anywhere between every 10 seconds or every 10 minutes. The DSA implements an algorithm
that selects the appropriate interval based on how long it takes to scan all system areas. This
design was implemented to avoid frequent, excessively long, scans.
This feature is supported on all Deep Security platforms, and is applicable all system objects with
the exception of the file system – files and folders --, and the Registry on Windows system,
which would take too long to scan to be practical given the 10 to 600 second interval between
each scan.
NOTE DSAs on Windows platforms use the ReadDirectoryChanges( ) function to

monitor files and folders. Non-Windows DSAs do not have an equivalent capability.
This feature has the following noteworthy characteristics:

● It cannot detect changes if they are undone before the scan takes place. On-change
functionality, in contrast, detects changes as they occur
● Changes to the DSA’s own database files are ignored regardless of the rule settings
The algorithm used to determine the appropriate scan interval is shown below. The elapsed time
mentioned here refers to the total length of the scan, which is the aggregate total of scan times of
each thread handling each object.
Elapsed Yes
Complete Interval =
time > thread up
scan 10,000ms
time?
No
Scan time <= 1,000ms ?
Yes
Interval =
15,000ms
No
Interval =
20,000ms
Yes
Interval =
30,000ms
No
Yes
Interval =
60,000ms
No
Yes
Interval =
120,000ms
No
Yes
Interval =
300,000ms
No
Interval =
600,000ms
The minimum interval is 10 seconds. If the scan takes up to 2.5 seconds to complete, the interval
for the next scan goes up to 15 seconds. Alternative intervals are specified for scans that take, 5,
10, 20, 30, and 60 seconds. At 60 seconds, the interval is 5 minutes.
The interval decision is refreshed after each scan. So an abnormally fast or slow scan will only
affect the next immediate pseudo real-time scan.
As shown in the diagram, the algorithm begins with a comparison of the elapsed time with the
thread up time. The DSA refers to time stamps for previous scans in its local SQLLite database.
If the elapsed time is greater than the latter, then the DSA will conclude that the agent had
recently been restarted, and will disregard data about previous scanning times because in all
likelihood the interval does not reflect how long the previous scan actually took. It will default to
10 seconds.
If a pseudo real-time scan is interrupted, the DSA is designed to re-start the scan at the earliest
opportunity. It reads information about what aspects of the scan had already been completed,
from its local SQLLite database, and then takes off from there.
7.3.3 Agent-side storage of events

Integrity monitoring baselines, as well as unreported integrity events, are stored in a SQLite3
database on the DSA host. For Windows-based DSAs, this file can be found in the following
location:
<Install path>\si.db
Integrity events are only stored in the local database until they uploaded to the DSM as part of a
heartbeat operation. Once fetched, the events will be deleted from the DB file – with the
exception of 2000 of the most recent integrity events. These are retained for display on the DSA
console.
7.3.4 Creating baselines

Integrity monitoring baselines consist of a combination of the following attributes:
Created - Timestamp when the file was created.
LastModified - Timestamp when the file was last modified.
LastAccessed - Timestamp when the file was last accessed.
NOTE On Windows this value does not get updated immediately, and recording of the
last accessed timestamp can be disabled as a performance enhancement. The act of
scanning a file requires that the DSA open the file, which will change its last accessed
timestamp.
On Unix, the DSA will use the O_NOATIME flag if it is available when opening the file.
This will prevent the OS from updating the last accessed timestamp and will speed up
scanning.
Permissions - The file's security descriptor. This varies per platform as follows:
Microsoft Windows variants SSDL format
Unix / Linux Posix ACL

“rwxrwxrwx” numeric formats
Owner - User ID of the file owner (commonly referred to as the "UID" on Unix).
Group - Group ID of the file owner (commonly referred to as the "GID" on Unix).
Size - size of the file.
Sha1 - SHA-1 hash when applicable
Sha256 - SHA-256 hash when applicable
Flags - Windows-only. Flags returned by the GetFileAttributes() Win32 API. Windows
Explorer calls these the "Attributes" of the file: Readonly, Archived, Compressed, etc.
SymLinkPath - Unix only. If the file is a symbolic link, the path of the link is stored here.
Windows NTFS supports Unix-like symlinks, but only for directories, not files.
Windows shortcut objects are not true symlinks since they are not handled by the OS;
the Windows Explorer handles shortcut files (*.lnk ) but other applications that open a
*.lnk file will simply see the contents of the lnk file.
InodeNumber - Unix only. This is the inode number of the file.
DeviceNumber - Unix only. This is the device number of the disk on which the inode
associated with the file is stored.
BlocksAllocated - Unix only. The number of blocks allocated to store the file.
As shown in the list above, the hash of the object being monitored is included in the baseline.
The algorithm used to generate this hash is set at the DSM console using the control shown
below.
These baselines, as well as unreported integrity events, are stored in a SQLLite3 database on the
DSA host. For Windows-based DSAs, this file can be found in the following location:
<Install path>\si.db
7.3.5 Database size control

The size of the SQLite database will vary depending on the number of events that occur on the
host. If free disk space drops below 5MB, Integrity Monitoring will be suspended.
7.4 > Dissecting an Integrity Monitoring rule

Integrity Monitoring rules are written in XML. Learning to write custom rules using the IM
syntax is a course by itself. Therefore to simplify matters, this section will focus on a single
Integrity Monitoring rule, and will explain the components of that specific rule.
NOTE Unlike Log Inspection rules, Integrity Monitoring rules are not based on Open
Source Security (OSSEC).
Here we will dissect the rule designed to detect changes to attributes of Windows services, as
shown below.
The details tab for this rule shows the system areas that the rule monitors.
The objects monitored were divided into the following:

● All services
● Services whose “ImagePaths” were monitored
This division of objects created two sections in the XML rule itself, shown below
<!‐‐ Service attributes changed through configuration console ‐‐>
<ServiceSet>

<include key="*" />

<attributes>
. . .
</attributes>
</ServiceSet>

<!‐‐ Registry changes to Service keys ‐‐>
<RegistryValueSet base="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services">
. . .
</RegistryValueSet>
Both sections targeted different system objects and are therefore discussed below separately.
Tip The online help for the Deep Security Manager contains a complete reference for
the Integrity Monitoring rule syntax. Look for the Integrity Monitoring Rules Language
topic.
All services
The <ServiceSet> . . . </ServiceSet>
tags are only used in Windows
platforms, and indicates that this section
of the rule focuses on Windows
services. The <include key= /> define
the system objects to include in the
scope of the rule. Since this example
uses an all-inclusive wildcard (*) then all
Windows services on the host are
monitored.
The <attributes> . . . </attributes> tag
indicate what aspects of the service are
of interest. These refer to the
configuration options that are visible in
service properties, as shown on the
right.
The following table matches the options in the rule configuration tab with the corresponding
tags in the rule’s XML file.
Configuration tab XML file

<ServiceSet>
<include key="*" />
<attributes>
<Permissions/>
<Owner/>
<Group/>
<BinaryPathName/>
<State/>
<StartType/>
<LogOnAs/>
<FirstFailure/>
<SecondFailure/>
<SubsequentFailures/>
<ResetFailCountAfter/>
<RunProgram/>
<DependsOn/>
</attributes>
</ServiceSet>
NOTE Since ProcessId, LoadOrderGroup, and Description were not selected, they are
not included in the XML code.
Each tag between the two attributes tags represents a particular service property. <StartType>
attribute, for example, refers to how the Windows Service Control Module starts the service, as
shown by the highlighted control below.
If any of these attributes change, an Integrity Monitoring event will be triggered.
Services whose “ImagePaths” are monitored

The second part of the rule is focused upon Windows services whose “ImagePaths” are
monitored. The ImagePath is a Registry entry that contains the fully qualified path to a file, and
optional command-line arguments, that Windows runs when it starts a service.
To protect these entries, the rule uses the <RegistryValueSet> . . . </RegistryValueSet> tag,
which sets the DSA to monitor Registry keys. This particular rule involves the following keys:
<!‐‐ Registry changes to Service keys ‐‐>
<RegistryValueSet base="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services">
<include key="DcomLaunch/ImagePath" />
<include key="SSDPSRV/ImagePath" />
<include key="upnphost/ImagePath" />
<include key="Dhcp/ImagePath" />
<include key="Dnscache/ImagePath" />
<include key="NetBT/ImagePath" />
<include key="kdc/ImagePath" />
<include key="Wmi/ImagePath" />
</RegistryValueSet>
The base parameter defines where in the Registry the DSA looks for the protected entries. In this
example, the keys are in HKLM\System CurrentControlSet\Services. By defining the base
parameter, the rule writer no longer needed to specify the full path for each key.
Consider the <include> tag for the key DcomLaunch. This key, and its contents, are shown below.
This is the DCOM Server Process Launcher which provides service launching functionality for
Distributed Component Object Model (DCOM) components. Certain systems require this for
communication functionality.
To load this service, the operating system runs SvcHost.exe with the “–k DcomLaunch
parameter”, as indicated by the ImagePath Registry entry for this service. It is, therefore,
important that any changes to this entry be monitored.
7.5 > Auto tagging and trusted sources

This section discusses auto tagging functionality and its latest evolution: Trusted sources. It is
● Why bother with automatic tags?
● Tagging basics
● About trusted sources
7.5.1 Why bother with automatic tags?

Deep Security version 7.0 introduced Event tagging functionality. While there are a number of
administrative events that benefited from this feature, and tags can be applied to any feature that
has events (e.g., Log Inspection Events, System Events, etc.) the principal use-case for this
capability was for Integrity Monitoring and patch deployment monitoring.
Since Integrity Monitoring functionally cannot distinguish between legitimate or malicious file
changes, security patch deployment can result in superfluous IM events that add to the
administrator’s workload. Prior to version 7.0, the general recommendation was for
administrators to rebuild their baselines after a patch was deployed thus avoiding the events.
Event tagging in version 7.0 sought to turn the previously undesired patch-related IM events into
something beneficial, by using them as a patch compliance data. This was how administrators
were advised to deploy their patches:
● Step one: Apply the patch to a single DSA host
● Step two: Perform an IM scan, and note the IM events that the patch generated, and tag
them with the Event Tagging feature (e.g., “Patch: ACME vulnerability”)
● Step three: Apply patch to the rest of the network
When the same IM events are created on these machines, the Auto-Tag feature would add the
“Patch: ACME vulnerability” tag to these events, so the administrator knows what caused these
changes. Furthermore, if there are machines that do not have these events, then the
administrator knows that these machines have not yet been patched.
Deep Security version 8.0 takes this application of the Event Tags even further with the Trusted
Source feature.
7.5.2 Tagging basics

Tags begin with entries in any of the
various Event screens. Right clicking
an event and selecting Add Tag, starts
the tag wizard.
The tag wizard prompts the
administrator for a number of options
to include the applicability of the tag
(e.g., just this event, or apply to future
events), as well as the name of the tag.
The more importantly, it asks for the data points that will trigger the tag. The following screen
capture shows a selection of data points
If an event shares the same data points defined for a tag, then that event will be tagged.
Increasing the number of data points restricts the events that will be tagged.
7.5.3 About trusted sources

The Trusted Sources feature builds upon automatic tagging functionality, and simplifies the
selection of events to tag. Instead of requiring the administrator to select individual events and
creating tags for each, the trusted sources feature tags can either tag events that occur on a
trusted machine, or generate tags for file changes that match records in a Trend Micro database.
Administrators choose the tag reference when they create a Trusted Source. The screen capture
on the left shows the button on the Auto-Tag Rules screen that starts the Trusted Source wizard.
The image on the right shows the selection options.
The options are:

A Local Trusted Computer can be any machine where Integrity Monitoring functionality is available.
When a patch is applied to this machine, a file-based Integrity Monitoring event is created, and
when similar events occur on other protected machines the events on those machines will be
given the trusted-source tag.
The Certified Safe Software Service is a Trend Micro cloud service that allows the DSM to query a
database of hashes and other identifying data for files that have been verified as safe. When this
functionality is enabled, file-based Integrity Monitoring events will trigger a query to the
aforementioned service.

1. How does Integrity Monitoring detect changes?
a) By comparing select system areas with a baseline

b) By referencing a change log
c) None of the above
2. Which of the following will trigger an Integrity Monitoring scan?
a) An on-demand request
b) Scheduled task
c) Windows API notification
d) All of the above
3. Which platforms benefit from actual real-time Integrity Monitoring?
a) Microsoft Windows (e.g., XP, 2008, etc.)

b) Linux distributions
c) Solaris
d) AIX
e) HP-UX
Chapter 8: About log

inspection
Chapter Objectives
● Understand how Log Inspection works
● Understand where this functionality gets its information

Log inspection is one of two host-analysis features offered by Deep Security Agents. It is, in
essence, log-based Host Intrusion Detection (HID). This feature allows Deep Security to log
events such as those shown below.
Windows Event Log Deep Security Event
The image on the left is the Windows Event log record that was generated when the OfficeScan
Proxy Service was changed from “demand start” to “auto start”. Since the computer where the
event occurred had a suitably configured DSA, Log Inspection functionality was able to obtain a
copy of the event, thereby generating the Deep Security Log Inspection Event shown on the
right.
This chapter focuses on this feature and is divided into the following sub-topics:
● Log inspection basics
● Dissecting a log inspection rule
● Log inspection operation
8.2 > Log inspection basics

The following diagram shows what log inspection does on a protected host.
Server
Client
Event log
00:00:01 01Jan09 EventA Medium

00:00:10 01Jan09 EventB Medium
Rule: Severity level = Critical 00:00:20 01Jan09 EventC Critical
00:00:30 01Jan09 EventD Low
Deep Security Agent 00:00:40 01Jan09 EventE Low
00:00:50 01Jan09 EventF Medium
00:00:60 01Jan09 EventG Low
...
The Deep Security Agent monitors logs defined by log inspection rules. Once an event with the
relevant severity level is detected, the DSA copies the event, and then uploads it to the DSM.
Upon receipt of the log information, the DSM normalizes the information in the log using a
decoder specifically designed for the log format sent, and then performs the following event
handling actions:
1. Store the event in the database and display on the Log Inspection Events screen as shown
below.
NOTE Events will only be captured if their severity values exceed severity clipping
values configured at System Settings > Log Inspection.
2. If the Log Inspection rule was configured to send alerts, as shown immediately below, DSM
will generate an alert for the log.
The alert itself appears as shown below. Alerts highlight specific events on the DSM console to
draw the administrator’s attention to them.
8.3 > Log inspection operation

The DSA performs log inspection by reading the log files of applications that it is instructed to
inspect. For example, rules that monitor various Windows-related logs will cause the DSA to
monitors logs that are normally viewed through the Windows Event Viewer.
The screen capture above highlights the Application event log. If the relevant rule is applied, the
DSA can monitor this file and read events that are being written to it.
NOTE Log inspection can only read new events. This inspection feature cannot be set
retrieve a specific range of logs.
The log parsing process is illustrated below.
Product /
DSA DSM
Log source
Create
alert
Yes
Database
Pre- Rule Database Is an alert
Event Decoding storage
decoding matching storage required?
(Local)
No
End
As shown above, the process is divided into the following steps:

Pre-decoding – in this step, the DSA parses logs that contained pre-defined static data
Decoding – here dynamic content is parsed. This step requires the use of decoders, which
are created for each application. The DSA cycles through its decoders until it finds one
that is appropriate, and then begins the parsing process
Rule matching – once the log is parsed, it is compared to the rules that match the decoder
and is evaluated
Database storage – when a log entry matches one of the rules, a copy of the parsed log is
stored in a SQLLite database on the DSA. This information is uploaded to the DSM as
part of a heartbeat operation. Additional details on this operation are available in the
next sub-section
Alert – this occurs on the DSM. When a Log inspection data is received, the DSM evaluates
it to determine if an alert is required.
8.3.1 About database storage

The database storage process consists of two steps. The first step involves storage of the fully
decoded Log Inspection data on the DSA in a SQLite3 database. For Windows-based DSAs, this
file can be found in the following location:
<Install path>\lca.db
This information is stored in the local database until they uploaded to the DSM as part of a
heartbeat operation. Once fetched, the events will be deleted from the DB file – with the
exception of 2000 of the most recent integrity events. These are retained for display on the DSA
console.
DATABASE SIZE CONTROL

The size of the SQLite database will vary depending on the number of events that occur on
the host. If free disk space drops below 5MB, Log Inspection will be suspended. It will also
be suspended if the DB file reaches 64MB.
8.4 > Dissecting a log inspection rule

Log inspection rules are written as XML files according to the Open Source Security (OSSEC)
syntax. Learning OSSEC rules requires an entire course by itself. Therefore to simplify matters,
this section will focus on a single log inspection rule, and learn its components.
NOTE For additional information about Open Source Security (OSSEC), visit the
following Website: http://www.ossec.net/.
Here we will dissect the rule designed to detect Windows events.
About the rule

The following screen capture shows the Details screen for the DSA used in this test.
Dependency
Note that in addition to the Microsoft Windows Events rule, the Default Rules Configuration
rule had to be applied to DSA as well. All log inspection rules use this rule, which help defines
the log format that the parser should expect from the log.
Like other DSM rules, administrators can view the details of log inspection rules by clicking the
View Rules button on the rule’s Configuration tab
An abbreviated version of the XML output of the Default Rules Configuration rule is shown
below. As shown
<group name="syslog">
<description>Generic template for all syslog rules</description>
. . .
<group name="squid">
<description>Generic template for all web proxy rules</description>
<group name="windows">
<rule id="06" level="0">
<category>windows</category>
<description>Generic template for all windows rules</description>
</rule>
</group>
<group name="ossec">
<description>Generic template for all ossec rules</description>
</group>
To make sense of the information once the

information has been parsed, the DSA
requires information in the Windows
Event rule. Perusal of the XML of this
rule, particularly the Files tab, shows that it
looks for events in the following Windows
logs:
● Application
● System
● Security
The <location> . . . </location> tags
indicate the location of the log file that
must be inspected. The example on the
right shows information for a Windows
rule. Since the location of Windows logs
are already included in the DSA code, only
the name of the folder is required.
For other platforms, more information would be required. For example for the syslog of Linux
box, file location would be written as follows:
<location>/var/log/messages</location>
8.5 > About log decoders

As explained in the Log Inspection Operation section, DSAs need decoders to be able to parse
logs correctly. Here we will inspect the decoders associated with the Microsoft Exchange rule.
NOTE Like other rules, the Microsoft Windows Events rule also uses decoders.
However, unlike the Microsoft Exchange rule, its decoders are not exposed in its XML file.
Configuration options for this rule appear below.
The XML rule that provides the functionality shown above can also be inspected by clicking the
View Rules button. When the rule appears, the pertinent entries are bound by the following tags:
<group name="ms,exchange,">
. . .
</group> <!‐‐ MS,Exchange ‐‐>
Each group of settings in the rule corresponds to a section in the XML file. The tables below will
match these settings with their corresponding sections.
<decoded_as>msexchange</decoded_as>
<description>Grouping of Exchange
rules.</description>
</rule>
The <rule id> tag indicates the OSSEC rule grouping for this particular log. Microsoft Exchange
rules are given IDs ranging from 3800 to 3899.
Tip For other OSSEC rule IDs see:

http://www.ossec.net/wiki/Know_How:RuleIDGrouping.
The level parameter defines the order in which a rule is processed. OSSEC supports level 0 to
15, with the higher value being evaluated before all others – with the exception of “0”, which is
always evaluated first, but no action will actually be taken. By assigning “0” to this rule, the DSM
immediately knows that it needs to use the msexchange decoder before any other analysis is
performed.
NOTE The DSA will cycle through its list of decoders until it finds a match.
The <description> . . . </description> tag simply allows Log inspection functionality to provide a
description for rule on the user interface.
The <decoded_as> . . . </decoded_as> tag defines the Log decoder required to parse MS Exchange
logs. Decoders are accessible via the following portion of the DSM console.
For MS Exchange logs, the corresponding decoder is called msexchange. If we view Default Log
Decoders, as shown above, and then click View Decoder, we will see that the msexchange
decoder appears as follows
<decoder name="msexchange">
<parent>windows‐date‐format</parent>
<use_own_name>true</use_own_name>
<prematch offset="after_parent">^\d+.\d+.\d+.\d+ \S+ SMTPSVC</prematch>
<regex offset="after_parent">^(\d+.\d+.\d+.\d+) \S+ \S+ \S+ \S+ </regex>
<regex>\d+ (\S+) \S+ \S+ (\d+) </regex>
<order>srcip, action, id</order>
</decoder>
Once the appropriate decoder for the log has been identified, the OSSEC component within
DSM applies the following logic when decoding the log:
The decoder begins its work by determining if a log entry matches a pre-match syntax, contained
within the prematch tag. If the log entry matches, then the entry is of interest and is parsed using
the pattern specified in the regex tag.

<if_sid>3800</if_sid>
<action>RCPT</action>
<id>^550</id>
<description>E-mail rcpt is not valid
(invalid account).</description>
<group>spam,</group>
</rule>
NOTE Configuration tabs like the one shown above are only available for rules that are
created by Trend Micro. Custom rules will not have this tab.
The <if_sid> . . . </if_sid> tags indicate that this rule is evaluated after the previous rule
(#3800). Both this rule and the next rule are both actually surbordinates of Rule #3800

<if_sid>3800</if_sid>
<id>^5</id>
<description>E-mail 500 error
code.</description>
<group>spam,</group>
</rule>
The rule below is executed if a match is found with Rule #3801. As explained in the description,
this rule is designed to detect attempts to send emails to an invalid account, indicating a Denial
of Service (DOS) attack.
<rule id="3851" level="9" frequency="10"

timeframe="120" ignore="120">
<if_matched_sid>3801</if_matched_sid>
<same_source_ip />
<description>Multiple e-mail attempts to
an invalid account.</description>
<group>multiple_spam,</group>
</rule>
The rule above is executed if a match is found with Rule #3802. As explained in this rule’s
description, this rule is designed to detect Error 500 events.
<rule id="3852" level="9" frequency="12"

timeframe="120" ignore="240">
<if_matched_sid>3802</if_matched_sid>
<same_source_ip />
<description>Multiple e-mail 500 error
code (spam).</description>
<group>multiple_spam,</group>
</rule>
8.6 > Log severity

The logs that Log Inspection functionality collects depends on the setting selected in the screen
below.
This is a global setting, and since there is not industry standard for logging levels, advanced
information about the logging behavior of the products being protected is advisable.

1. What open-source technology is used for Log Inspection functionality?
a) Microsoft .NET
b) OSSEC
c) GNU
2. Which log formats are supported by default log inspection decoders?
a) Syslog
b) Microsoft Windows
c) Squid
d) All of the above
3. How do administrators select which log entries are captured?
a) Log location
b) Log severity
c) Log name
Chapter 9: About the

firewall
Chapter Objectives
● Understand how the firewall works
● Understand the different firewall actions
● Build upon the protocol basics introduced in Chapter 4

The Deep Security firewall is an NDIS-based, bi-directional, stateful firewall that is responsible
for making sure that packets originating from unauthorized sources do reach the applications on
its host. This chapter focuses on this functionality and is divided into the following sections:
● Firewall operation
● About stateful configuration
● Known issues
9.2 > Firewall operation

The following aspects of firewall operation are discussed in this section:
● About firewall rules
● Firewall rule action
● About priorities
● About database storage
For a comparison between the OfficeScan and Deep Security firewalls, see
Appendix A: Deep dive information > Chapter 9.
9.2.1 About firewall rules

Firewall rules consist of the following parameters:
Protocol
(TCP, UDP, ICMP, etc.) Direction
(Incoming, outgoing)
Source Destination
(IP address, port, (IP address, port,
MAC address) MAC address)
Packet
TCP header flags

Frame type
(SYN, ACK, FIN, PSH,
(IP, Arp, Revarp, other)
RST, URG)
Each parameter is discussed in the following sections:

● Source and destination
● Transport protocols
● Direction
● TCP header flags
● Frame type
Source and destination

The firewall can regulate traffic based on their source and destination using the controls shown
below.
As shown above, packet sources and destinations can be identified using:

● IP address
● MAC address
● Ports
Each identification option has its own sub-options which are described below.
IP ADDRESS
The following table discusses the different ways hosts can be identified using IP addresses
Option Description
No address is specified so
any host can be either a
source or destination
A specific machine is
identified using its IP
address.
This applies the rule to all

machines that share the
same subnet mask
This applies the rule to all

machines that fall within a
specific range of IP
addresses.
Use this when applying a

rule to several machines that
do not have consecutive IP
addresses.
This uses a Component list,

particularly one for IP
addresses, to define hosts.
MAC ADDRESS
The following table discusses the different ways that hosts can be identified by their MAC
addresses
Option Description
No MAC address was
specified, so the rule
applies to all addresses
Rule applies to a specific

MAC address
Rule applies to the MAC

addresses specified here
Rule applies to MAC

addresses in a MAC list
PORTS
The following table discusses the different ways that hosts, with specific applications, can be
identified using ports
Option Description
Rule applies to a single port
Rule applies to multiple

ports written here
Rule applies to a port list
Transport protocols
If the rule is meant for the Internet Protocol (IP) frame type, the protocol field is enabled, and
administrators will be asked to specify the transport protocol that will be analyzed. The protocol
options are shown below.
Selecting “Other” displays a prompt for the protocol number, as shown below.
Direction
The Deep Security firewall is a bi-directional firewall. Therefore it is able to enforce rules on
traffic originating from the network to the Deep Security host, also shown below as incoming, and
traffic from the host to the network, called outgoing.
Firewall rules only apply to a single direction; therefore policies for specific types of traffic often
come in pairs.
TCP header flags

When dealing with TCP traffic, administrators can choose the TCP flags to which rules apply. If
the rule does not apply to all flags, administrators can choose from the following:
The SYN, ACK, and FIN flags, and the threat conditions that involve them, have been explained
in great detail in TCP flags and states on page 452. So only the following flags will be discussed
here:
URG
PSH
RST
There are a number of ways these flags can be used in different attacks. Only a selection will be
used here.
Important: The text below should not be misconstrued as being the only way that
hackers/crackers can use these flags. Refer to a Trend Micro threats course for more detailed
information.
The URG flag indicates that the packet is urgent and must be processed before all others, while
the PSH flag sets the TCP stack to flush its buffers and send all information up to the
application. Both flags can be used in a type port scan called the Xmas scan which is typically a
FIN packet with the URG and PSH flags enabled. This scan gets its name from the alternating
bits turned on and off in the flags byte (00101001), much like the lights of a Christmas tree.
When an unprotected machine receives packets related to a Xmas scan, the following happens:
Condition Response
Closed port Returns an RST packet
Open port No response, betraying existence of the open port
The RST, or RESET, flag abruptly terminates TCP connections. As described above, among its
legitimate uses is to terminate connects to closed ports indicating an impossible or disallowed
connection. However, the RST flag can also be used as part of an RESET attack, designed to
disrupt existing sessions. Consider the following diagram.
Host A Host B Host C
TCP State: TCP State:

Established connection
ESTABLISHED ESTABLISHED
RST message using spoofed Host B identity and packet

sequence #
TCP State:
CLOSED
Message using
terminated connection
????
The diagram above shows a situation where an attack, Host C, was able to calculate the TCP
sequence number that Host A expected from a packet from Host B, thereby spoofing Host A
into believing that Host B had sent it a RST packet. The end result is a denial of service attack.
Frame types
The term “frame” refers to Ethernet frames, and the protocols in the drop-down menu shown
below specify the data that the frame carries.
Internet Protocol (IP), Address Resolution Protocol (ARP), and Reverse Address Resolution
Protocol (RARP) are the most commonly carried protocols on contemporary Ethernet networks.
These, however, are not the only protocols that can leverage Ethernet frames. For this reason,
Administrators are allowed to specify Frame types.
Consider the following firewall Allow rule designed to permit incoming traffic bearing Point-to-
Point Protocol over Ethernet (PPPoE) data.
As shown above, the Frame Type is “Other”, and the Frame number is 8863.
LINUX DSA LIMITATION

Ethernet-related firewall rules for Linux-based DSAs only support IP and ARP frame types.
Other frame types will be allowed through.
9.2.2 Firewall rule action

Firewall rules can take any of the following action options:
Briefly, these actions do the following:

Allow – this action explicitly allows traffic that matches the rule to pass, and then implicitly
denies everything else.
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. For additional information see About bypass on page 165
Deny – this action explicitly blocks traffic that matches the rule
Force allow – this forcibly allows traffic that would otherwise be denied by other rules. The
traffic, however, will still be subject to DPI analysis. See About Force allow on page 166
for an example of how this can be used
Log only – traffic will be only be logged. No other action will be taken
Allow, Force allow and Bypass are explained further below.
About “Allow”
“Allow” rules have a two-fold function:
1. Permit traffic that is explicitly allowed.
2. Implicitly deny all other traffic
If traffic is neither covered by a Deny rule, but is not explicitly allowed by an Allow rule, then it
is dropped and is logged as an Out of allowed policy event in firewall logs.
Commonly applied “Allow” rules – which are part of the default Deep Security rule set --
include, but are not limited to, the following:
ARP – permits incoming Address Resolution Protocol traffic
Allow solicited TCP/UDP replies – this ensures that the host is able to receive replies to
its own TCP and UDP messages. This works in conjunction with TCP and UDP stateful
configuration
Allow solicited ICMP replies - this ensures that the host is able to receive replies to its
own ICMP messages. This works in conjunction with ICMP stateful configuration
Tip Rules can be set in Security Profiles, and then applied to computers with similar
traffic patterns. For information about Security Profiles, see 91.
About “Bypass”
As mentioned in the previous section, the Bypass rule is designed for media-intensive protocols
where filtering, be it by the firewall or DPI, is neither required nor desired.
These rules have the following noteworthy characteristics:
● Bypass skips both firewall and DPI analysis
● Since stateful inspection is skipped for bypassed traffic, bypassing traffic in one direction
does not automatically bypass the response in the other direction. As a result bypass rules are
always in pairs, one for incoming traffic and another for outgoing.
● Bypassed rules will not be logged. This is not a configurable behavior
Tip If DSM uses a remote database that is protected by a DSA, DPI-related false alarms
may occur when the DSM saves DPI rules to the database. The contents of the rules
themselves could be misidentified as an attack. One of two workarounds for this is to create
a Bypass rule for traffic from the DSM to the database host. See Database communication
on page 44 for additional details.
DEFAULT BYPASS RULE FOR DSM TRAFFIC

The Deep Security Manager automatically implements a hidden, priority 4, Bypass rule that
opens incoming TCP traffic at port 4118 on DSA computers. Priority 4 ensures that this rule is
applied before any deny rule, and Bypass guarantees that the traffic is never impaired.
This rule, however, accepts traffic from any IP address and any MAC address. To harden the
DSA at this port, users can create an alternative, more restrictive, bypass rule for this port. The
DSA agent will actually disable the default DSM traffic rule in favor of the new custom rule
provided it has the following characteristics:
Priority: 4 – Highest
Packet direction: Incoming
Frame type: IP
Protocol: TCP
Packet Destination Port: 4118
The custom rule must use the above parameters to replace the default rule. Ideally, the IP
address or MAC address of the actual DSM should be used as the packet source for the rule.
Tip When using multiple DSM machines in a mutli-node arrangement, it may be useful
to define an IP list for these machines and then using this list for the custom DSM traffic
rule.
About “Force allow”

The force allow option excludes a sub-set of traffic that could otherwise have been covered by a
deny action. Its relationship to other actions is illustrated below.
Allow
Deny
Force
allow
Force allow has the same effect as a Bypass rule. However, unlike Bypass, traffic that passes the
firewall because of this action is still subject to Deep Packet Inspection.
The Force allow action is particularly useful for making sure that essential network services are
able to communicate with the DSA computer. Among the default Force allow rules that are
commonly enabled in real-life are:
DHCP client – allows DHCP offer traffic to the DHCP client on the DSA host. This
ensures that the client can obtain its dynamic IP address
Wireless authentication – allows wireless authentication traffic via the Extensible
Authentication Protocol (EAP)
One situation that would require a “force allow” action would be when an administrators wants a
host to accept ICMP and/or UDP traffic, but the Deep Security Agent has stateful configuration
for ICMP and UDP traffic enabled.
Important: The drop action above will happen even if there are no firewall rules that prevent
incoming UDP and ICMP traffic. Stateful configuration will always drop the packet.
Therefore to allow incoming UDP and ICMP traffic, administrators need to configure a force
allow rule like the one shown below.
9.2.3 About priorities

The order in which firewall rules are applied is governed by its priority number. As shown in the
screen capture of the priority dropdown menu, administrators can assign five priority levels.
Traffic is evaluated against firewall rules according to this priority setting, in the following
fashion.
From network
Priority 4:
Log only Bypass Force allow Deny
Highest
Priority 3:
Deny Force allow Bypass
High
Priority 2: Bypass Force allow Deny

Normal
Priority 1: Deny Force allow Bypass

Low
Priority 0:
Bypass Force allow Deny Allow
Lowest
To application
“Log only” rules can only be at priority 4, and are always evaluated first. They will not, however,
interfere with the other rules.
“Allow” rules can only be given priority 0, and are the last rules to be evaluated.
The remaining rules are applied in the following order:
3. Bypass
4. Force Allow
5. Deny
Consider the following rules:
Rule Action Priority Direction Frame Protocol Source

type port
HTTP deny Deny 3 – High Incoming IP TCP 80
HTTP allow Force allow 2 – Normal Incoming IP TCP 80
Both rules apply to TCP traffic at port 80, presumably HTTP traffic. The first rule blocks traffic,
while the second rule forcibly allows it. However, since the Deny rule has a higher priority than
the allow rule, the former will always prevail.
Tip To simplify firewall rule administration, administrators should consider only

assigning one type of action per priority, preferably in the same order they are
evaluated. For example, Priority 3 for Bypass, Priority 2 for Force Allow, and Priority 1
for Deny.

Firewall events are stored on the DSA in a flat text file called dsa_mpnp. On Windows-based
DSAs, this is stored in the following location:
On DSVA, each Virtual Agent will have its own firewall log file stored in the following location:
/var/opt/ds_agent/guests/<virtual agent GUID>/log
Once the events in the logs exceed 4MB, the DSA creates a new dsa_mpnp file and assigns the
numerical file extension to the previous file. By default, these DSA only maintains three event
files.
9.3 > Reconnaissance scans

The diagram below presents what happens during a reconnaissance scan.
Scan packet
Response
Scanner host Scan target
These scans typically involve two types of messages: scanning packets, and responses -- or even
the absence of a response. For example, when the Deep Security Manager performs a port scan,
it sends a SYN packet to the target host, at a particular port. If a connection is established, then
the port is declared open. Other techniques focus on the absence of a reset (RST) response to
detect open ports.
Whereas network administrators use this capability to protect their networks, crackers/hackers
can leverage reconnaissance scanning tools (e.g., NMAP) to look for security gaps.
Reconnaissance scanning can consist of any or a combination of the following activities:
Network mapping/scanning – this refers to the process of collecting a list of computers
on a network that could then be attacked.
Port scanning – this is the process of looking for open ports, betraying the presence of
specific applications and or vulnerabilities. This is the type of scan discussed in the
paragraph above. A successful port scan is essential to a variety of other reconnaissance

scans.
OS fingerprinting – this process discovers the operating system of potential target
machines. Different tools use different ways of creating fingerprints. NMAP, for
example, uses the results of seven different tests and matches the responses to a
database of known responses for each OS. Other tools use their own techniques.
Enumeration – this scan causes the target to list, or enumerate, the resources that are
available on it, or its host network. Such resources include user accounts, services,
network shares, and other information that may be of use to an attacker.
Once general information is collected, the attacker proceeds to Vulnerability scanning to look for
specific exploitable vulnerabilities.
NOTE The firewall must be enabled, and firewall rules assigned, for reconnaissance
scan to work.
9.4 > About stateful configuration

Stateful configuration functionality monitors connections to and from the DSA host and ensures
that such connections behave within pre-determined parameters. Therefore it plays a very
important role in thwarting the attacks such as, but not limited to, the following:
Denial of Service (DoS)
ACK Storm
Traditionally, these attacks leverage the characteristics of the following protocols:
● TCP
● UDP
● ICMP
As a consequence DSA provides functionality that address known attack techniques for each of
these protocols.
NOTE Because of the relationship between ICMP and UDP, both will be discussed in the
same sub-section below.
Stateful configuration for TCP

Of the three protocols that this feature supports, TCP is the only protocol for which the Deep
Security administrator is able to configure. The relevant controls are shown below.
SYN FLOOD PROTECTION

Syn Flood protection was removed in version 8.0. This feature, which was only available on
Windows-based DSA, deemed redundant by improvements to this operating system’s
TCP/IP implementation after Windows 2000.
The following table shows how these settings are used.
Attack Description Setting How the setting

thwarts the attack
ACK Storm Attack injects an out of Enable ACK Storm If stateful configuration
sequence packet into a protection when the detects that the number
session thereby causing number of already of ACK messages for
both hosts to continually acknowledged packets the life of the
send ACK messages to exceeds: XXX. connection exceeds the
each other, thereby tying figure specified, the
up resources connection is
terminated.
The default value is

“300”.
Denial of Attacker either causes Limit the number of Once the number of
Service other machines on a incoming connections connections to and
network to flood the DSA from a single from a computer
host with connections, or computer to: XXX exceeds this setting,
uses the DSA host to DSA prevents additional
launch a similar attack on Limit the number of connections.
other hosts outgoing connections
to a single computer The default value is 100
to: XXX connections
Stateful configuration for UDP and ICMP

Both UDP and ICMP are connectionless protocols, so normal stateful inspection, the kind done
with TCP, is inapplicable for these protocols. Stateful configuration, therefore, uses “pseudo-
state table” that keeps track of related UDP and ICMP messages which are then treated as
“pseudo connections”.
The following diagram shows how this works.
Host A Host B
IP: 1.1.1.1 IP: 2.2.2.2
Src IP Dst IP Time stamp UDP message
1.1.1.1 2.2.2.2 00:00:00
X seconds
Src IP Dst IP Time stamp Response to UDP message
2.2.2.2 1.1.1.1 00:00:01
The diagram shows Host A sending a UDP message to Host B, and then receiving a response.
Host A has a DSA with stateful configuration for UDP traffic enabled. So when Host A sends
the message, it creates a record for this in its pseudo-state table. This record sets the DSA to
expect a UDP response from Host B within 60 seconds. So when it receives a UDP message
from Host B within that timeframe, the agent decides that this UDP message is related to the
first message and lets the message pass to the host.
Both configuration settings affect how hosts deal with unsolicited UDP or ICMP messages.
Consider a situation where Host B sends Host A an unsolicited UDP message, like the one
shown below.
Host A Host B
IP: 1.1.1.1 IP: 2.2.2.2
???? (No corresponding message)
X seconds
Src IP Dst IP Time stamp UDP message
2.2.2.2 1.1.1.1 00:00:01
Since DSA cannot associate the incoming message with an earlier outgoing message, then DSA
will drop this message.
NOTE To permit unsolicited ICMP and/or UDP messages while stateful configuration
for both protocols is enabled, administrators need to apply a Force Allow rule for this
traffic. See About “Force allow” on page 166.
ICMP types 0 and 8, 13 and 14, 15 and 16, and 17 and 18 are supported.
9.5 > Internet Protocol version 6 (IPv6)

In version 8.0, IPv6 support is limited to Deep Packet Inspection. The firewall functionality
cannot be applied to IP6 traffic in this version.
9.6 > Known issues

For a list of known issues, see Appendix A: Deep dive information > Chapter 9. The following
topics are discussed:
● Third party firewalls
● CISCO WAAS

1. Which of the following are valid firewall actions?
a) Allow
b) Deny
c) Bypass
d) Force allow
e) Log only
f) All of the above
2. If a priority 4 Deny rule conflicts with a priority 3 Force allow rule, which rule will prevail?
a) Deny rule
b) Force allow rule
3. Which action implements an “implicit deny” action?
a) Allow
b) Deny
c) Bypass
Chapter 10: About Deep

Packet Inspection
Chapter Objectives
● Understand how DPI works
● Understand the value of DPI
● Understand how malicious content is detected and blocked

This chapter focuses on Deep Packet Inspection (DPI) functionality and is divided into the
following sections:
● Uses for Deep Packet Inspection
● About DPI rules
● About stateful configuration
10.2 > Uses for Deep Packet Inspection

DPI functionality is applied in the following ways:
● Virtual patching
● Protocol hygiene
● Limited application control
10.2.1 Virtual patching

Deep Packet Inspection (DPI) can be used for what is called virtual patching. Consider the
following diagram:
Computer 1 (Attacker) Computer 2 (Victim)
Application
Malicious instruction:
Vulnerability
Do_Something_Bad
Protocol
stack
Protocol
DPI
stack
Computer 2 in the illustration represents a machine with an unpatched vulnerability. The reasons
for this situation can range from dereliction on the part of the IT department to complexities
involved in the application of the patch which prevent timely application. If the Deep Security
Agent is configured correctly during the attack above, meaning the corresponding DPI rule is
enabled, the attack is thwarted at the protocol stack.
Virtual patching mitigates the impact of falling behind on patch application duties. Once the
patch is applied, it is then possible to safely disable the DPI rule that protects against that
particular vulnerability.
10.2.2 Protocol hygiene

DPI gives the administrator the ability to block traffic based on how they conform to protocol
specifications. DPI rules allow DSAs to detect packet fragments, packets without flags, and
similar anomalies.
10.2.3 Limited application control

Communication applications like peer-to-peer chat programs use specific, distinct,
communication protocols. DPI rules could identify packets that use these protocols thereby
detecting the presence, and/or prevent the use, of these applications.
10.3 > DPI operations

DPI rules are comparable to Generic Stream Scanning (GSS) rules that are used in other Trend
Micro products that deal with network viruses (e.g., OfficeScan firewall, Network VirusWall,
etc.). The rules however are created separately from GSS rules and following a completely
different creation process.
Many rules benefit from Trend Micro’s membership in the Microsoft Active Protections
Program (MAPP) which provides advanced access to Microsoft’s monthly security bulletins. This
allows the rule development team to anticipate emerging threats and craft rules that protect
against vulnerability – even before they are officially acknowledged.
10.3.1 How rules work

DPI rules work as shown below.
DPI engine Rule match: Drop packet
DPI rule
Shellcode:do_something_bad
Reassembly Fragmentation
Network Packet:do_something_bad Application
process process
The DSA looks at the content of packet to determine if it contains malicious content. It is able
to determine if content is malicious by referencing instructions within DPI rules. If the content
matches what the rule looks for, then the packet is dropped.
10.3.2 Rule groups

As shown below, there are three groups of DPI rules
IDS/IPS - designed to defend against software vulnerabilities and exploits. These rules
provide virtual patching functionality
Application control – as its name implies, these rules detect the use of particular
applications on the DSA host
Web application protection – these rules are designed to protect Web applications from
malicious attacks
IDS/IPS rules are further sub-divided into the following categories:
● Exploit rules
● Vulnerability rules
● Smart rules
The following diagram illustrates how these rules are inter-related.
Exploit #1 for Vulnerability #1

Vulnerability
#1
For any vulnerability, there can be multiple exploits. For example, the Server Service
vulnerability, discussed very extensively in Gaining access on page 114, can be exploited by
several variants of the Conficker/WORM_DOWNAD malware.
A rule that specifically targets how malware leverages the vulnerability would be an exploit rule.
There will be as many exploit rules as there are methods for using the vulnerability. Depending
on the nature of the exploit, multiple exploits can be addressed by a single exploit rule.
A vulnerability rule, on the other hand, applies a virtual patch on the vulnerability, thereby
rendering all exploits that use that vulnerability harmless. Vulnerability rules, therefore, can
theoretically take the place of several exploit rules.
Smart rules are generic rules that provide virtual patching for one or several vulnerabilities.
Because of the breadth of these rules, some configuration may be required to prevent false
positives.
COMPARISON WITH VSAPI PATTERNS

In VSAPI-based malware detection, malware signatures are classified as:
• 1-to-1
• 1-to-many
The 1-to-1 pattern is designed for a specific malware variant, while the 1-to-many pattern
relies on the characteristics that are common to several variants of the same malware.
Typically detection begins with the 1-to-1 pattern, which relies on a precise match. As
variants emerge, the common denominator found in these variants is used as the basis
for a 1-to-many pattern which can recognize the different variants without the pattern-
size impact of a 1-to-1 pattern. This database space conservation measure permits Trend
Micro to retire the 1-to-1pattern without loss of detection capability.
Mapped to DPI rules, Exploit rules would be very roughly analogous to 1-to-1 pattern
(exploits can actually match with more than one exploit), while Vulnerability and Smart
rules would be analogous to the 1-to-many pattern.
Given the option to create one-size-fits-all Smart rules for multiple vulnerabilities, it would be
natural for any reader of this document to ask: “Why bother with Exploit or Vulnerability rules if
Smart rules can be made?” The short answers are “false-positive avoidance” and “forensics”.
The broader the applicability of the rule, the greater the chances of blocking traffic that really
shouldn’t be blocked. For this reason, Smart rules will probably not be made for every
vulnerability. As of writing there are only a little over 100 Smart rules available, a number that is
expected to grow over time. These were only released after completion of exhaustive testing to
address false-positive concerns.
Rules generate DPI events when they are triggered. Unless packet capture functionality is
enabled, these events typically only contain the name of the rule that was triggered, and the time
and location of the event.
The usefulness of these events for forensic analysis of attacks is directly proportional to the
granularity of the information they contain. Smart rules alone, therefore, are too broad for
forensic analysis because they cover too many attack vectors. Targeted exploit filters, on the
other hand, offer the most targeted DPI logging information.
When all three rules are available for a particular vulnerability are available, they form a kind of
“layered defense” around the vulnerability. This illustrated below.
Exploit #1
for Vulnerability
#1
Exploit #1 rule Exploit #1 rule
Vulnerability rule for Vulnerability rule for

Vulnerability #1 Vulnerability #2
Exploit #2 rule
Exploit #2 rule
Exploit #2
for Vulnerability Smart rules
Vulnerability Vulnerability
#1 for vulnerability
#1 #2
#1 & #2
Exploit #3 rule Exploit #3 rule
Exploit #3
for Vulnerability
#1
Note the different exploits targeted at Vulnerability #1. Each attack vector has a corresponding
Exploit rule. Each vulnerability has a vulnerability rule that can address all of the attack vectors
by itself. Both vulnerabilities can be protected by a single Smart rule that can deal with all the
attack vectors for vulnerability #1 as well as attacks for vulnerability 2.
NOTE The “layering” illustrated here simply shows the coverage of each rule type. They
have no bearing on which rule actually gets triggered first.
Overlapping rules can be applied to a DSA. However, the rule that is actually triggered is the rule
that first matches whatever pattern is found in the traffic. Consider the following hypothetical
rules
Rule Type Action

No.
1 Smart Block entries to password field greater than 100 characters
2 Vulnerability Acme software vulnerability #1. Vulnerable when entering more

than 512 characters to password field
3 Vulnerability Acme software vulnerability #2. Vulnerable when entering more

that 700 character to password field
4 Exploit Exploit 1 for Acme software vulnerability #1. A specific sequence

characters that overflow the 512 character buffer can cause the
software to perform malicious operations
The Smart rule, #1, will drop traffic associated with an attempt to enter more than 100
characters into a password field. This will protect Acme software from vulnerabilities 1 and 2, as
well as Exploit 1.
However since the Smart rule protects any application on the machine with a password field, its
rule event will not provide information about the specific application being attacked. It also will
not provide information about the vulnerability that the attacker was attempting to exploit. For
this reason, Smart rules are typically written with the setdrop action, instead of drop. With setdrop,
the rule will not instruct the DSA to drop the packet until the entire packet is analyzed. This
action gives applicable vulnerability or exploit rules a chance to be triggered, and become
responsible for dropping the packet.
NOTE The rule compilation mechanism is designed so that it gives all relevant rules –
regardless of type -- a chance to be triggered, before the packet is dropped. This is
meant to provide the administrator with as much forensic information as possible.

Firewall events are stored on the DSA in a flat text file called dsa_mpnp. On Windows-based
DSAs, this is stored in the following location:
Once the events in the logs exceed 4MB, the DSA creates a new dsa_mpnp file and assigns the
numerical file extension to the previous file. By default, these DSA only maintains three event
files.
10.1 > HTTPS payload inspection

If the packet is part of an SSL connection, the driver needs to decrypt the traffic to allow Deep
Packet Inspection. To accomplish this, however, the administrator needs to provide the relevant
certificates to permit decryption. The DSM management console screen for importing the
certificate is shown below.
SSL COMPRESSION
The Deep Security agent does not support filtering on SSL connections with SSL
compression enabled. This creates the following conditions with respect to HTTPS
payload inspection:
• When HTTPS payload inspection is enabled, any encrypted traffic that the DSA
cannot decrypt will be dropped. This includes SSL connections with SSL
compression enabled.
• If HTTPS payload inspection is NOT enabled, then SSL connections with SSL
compression enabled will simply be allowed through without analysis.
This section focuses on how HTTPS payload inspection works and is divided into the following
sub-sections:
● SSL basics
● DSA in an SSL connection
● Payload inspection
10.1.1 SSL basics

The following diagram presents a simple review of how an SSL connection is established.
Client Server
Initiate SSL connection
Send certificate
Send challenge based on certificate
Secure connection established
As shown above, the “key” to making the SSL connection possible is the server’s certificate,
which contains one part of the asymmetric key pair that is used in protecting the connection. By
providing the DSA with the server’s certificate, all that it needs to be able to decrypt the SSL
session is the information contained in the challenge.
NOTE HTTPS payload inspection must be able to observe the SSL session
establishment shown above to be able to decrypt SSL traffic. It cannot read an already-
established session. If an established secure session is present when HTTPS Payload
inspection is enabled, the DSA will terminate this connection.
10.1.2 DSA in an SSL connection

A DSA inserts itself into SSL connections as shown below.
Server
Client DSA Application
Decrypt
&
Analyze
Decrypt
&
Analyze
Each time an SSL packet passes through a DSA the traffic is decrypted and analyzed. This
decryption is applied both to incoming traffic and its corresponding response.
10.1.3 Payload inspection

For purposes of this discussion, let us look at a single packet in a single direction. It should be
noted, however, that this process actually takes place in both directions, on both the incoming
HTTPS request, and the corresponding response.
When the DSA receives a packet from the network the DSA defers the packet while its content
is analyzed.
Packet deferred
DSA
Application
Intended
destination
After the firewall module completes its analysis of the packet, it is handed off to DPI and
HTTPS payload inspection for analysis.
Deferred
Firewall
DPI / HTTPS Payload inspection
Decryption Inspection Decision

Copy of
encrypted packet
The decryption engine is not able to re-encrypt the traffic that it decrypts. Therefore to preserve
the original encrypted packet, a copy of the packet is created, and all analysis is done upon this
packet. The copy is decrypted, and then inspected. If the packet contains malicious content, then
it is dropped.
NOTE If the packet cannot be decrypted, then it is also dropped.
On the other hand, if the packet does not trigger any DPI rules then the deferred encrypted
packet is allowed to proceed to its destination.
Packet delivered
DSA
Application
10.2 > Protecting web applications

Readers of this document who have taken part in a formal Sales Engineering demo for Deep
Security ought to have already seen the “Capital Mortage Consolidators” vulnerability
demonstration involving the fictitious Website shown below.
This section consolidates the lessons derived from the lab exercise / demonstration, and is
● The demo site’s vulnerabilities
● How the site was attacked
● How DPI protected the site
The demo site’s vulnerabilities

By design, the fictional website logon system contained vulnerabilities that could be exploited
with the following attacks:
● Cross Site Scripting (XSS)
● SQL injection
How the site was attacked

The demo involved a VMware image that hosted the site, and another image the site was
accessed. For the XSS attack, the following script was entered in the relevant field.
'‐‐<script>alert('XSS Executed')</script>
The site was deliberately designed to with a vulnerability that would be triggered by the script.
How DPI protected the site

Deep Packet Inspection functionality is able to defend against XSS and SQL injection attacks
through the following default rules:
● Generic Cross Site Scripting (XSS) prevention
● Generic SQL injection prevention
Administrators are able to add their own custom Web application rules, and Trend Micro may
add additional rules in the future. However, these are the ones that are available, out of the box,
as of writing.
The configuration options for both rules are very similar, as shown in the table below:
Generic Cross Site Scripting (XSS) Generic SQL Injection
Both have the same parameters that are exposed and configurable. Each parameter is explained
in their respective sub-sections.
PATTERNS
The pattern field contains the characters that DPI looks for in the HTTP message. Consider the
following pattern in the default Generic Cross Site Scripting (XSS) filter.
The individual components of this pattern are explained below:

Character
Character
score
<,%3c,>,%3e:1
Character in
UTF-8 encoding
This pattern prompts the NDIS driver to keep track of instances of “<” and “>”. Each time the
driver encounters these characters in the URL, it increments the URL score by “1”.
Let’s apply this pattern to the XSS attack used on the demo site:
'‐‐<script>alert('XSS Executed')</script>
In addition to the same pattern above, the following XSS patterns also apply to the string used
for the attack.
script,object,iframe,applet,embed:2
. . .
',%27,\x22,%22:1
When all three patterns are applied to the string, the result is shown below.
1 1 2 1 1 1 1 2 1
' -- < script > alert( ' XSS Executed ' ) < / script >
The word “script” is part of the second pattern, and is given a score of “2”. All other matches,
‘
including “ “, are given a score of 1. This gives this script a total score of “11”. In practice,
however, the filter implements a score threshold, which may be breached before the full script is
analyzed.
DROP THRESHOLD
This parameter defines the maximum score that a string can accumulate before it is dropped.
The default value is “4”, so when the score reaches “5” the packet is dropped.
Applied to the attack string, the threshold is breached by the time the “>” after “script” is read.
Total score = 5
(Threshold exceeded)
1 1 2 1 1 1 1 2 1
' -- < script > alert( ' XSS Executed ' ) < / script >
LOG THRESHOLD
This works the same way as the Drop threshold parameter. When the string’s score reaches this
value, the NDIS driver creates a log entry for this event.
MAX DISTANCE BETWEEN MATCHES

This parameter defines how many characters can exist between two pattern matches for both
matches to be part of the same score count.
30 characters (default)
yyyXyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyXyyyyy
If there are no pattern matches beyond this value, then the score is reset to zero. The default
value for this parameter is “30”.
10.2.1 Dealing with HTTP encoding

Uniform Resource Locators (URLs) s are
normally expressed in the standard US
ASCII character set, as defined by RFC
3986 – Uniform Resource Identifier (URI):
Generic Syntax. Some URLs, however,
require special characters that are outside
this set, in which case the characters are
typically percent-encoded. For example a
blank space is encoded as %20, so the
URL for a host named “this is my
site.com” would appear as:
this%20is%20my%20site.com
To allow DPI to analyze the HTTP

message, its URL needs to be decoded
into ASCII. DSA accomplishes this using
to the HTTP Protocol Decoding filter.
The configuration tab for this filter is
shown on the right.
Important: Other Web application and

Web server filters actually look for the
HTTP Protocol Decoding filter when they
are applied and cannot be applied if the
decoding filter is not yet in-effect on the DSA host.
As shown on the right, the filter has the following groups of parameters:
● URI normalization options
● Encoding options
● Raw character options
URI normalization options

URI normalization is another term for the decoding process. The settings in this section focus
on what, and what not, to normalize, as well as logging options. Encoding methods are handled
in the next section. The options under this section are:
Use URI Normalization in body of HTTP POST
Assume POST BODY is URI Form Encoded when Content Type is missing
Pages for which no URI normalization is done for HTTP POST body
Block double URI encoded data
Block invalid hex encoded data
Use full Payload logging on URI normalization errors
Encoding options
By default, DSA assumes that URLs use UTF-8 encoding. The decoding filter, however, can use
either UTF-8 or Latin1 encoding.
Tip If you are seeing “Invalid UTF8 Encoding” events in Deep Security logs for
legitimate traffic, then administrators may need to change encoding methods in this
filter.
10.2.2 Web server filters

Web server-specific rules proactively prevent HTTP traffic with undesirable content from
reaching Web servers. HTTP traffic to and from the server are inspected, and then dropped
when they are in violation of predefined criteria.
Host
Web
server
HTTP traffic NIC DSA
By default, Deep Security includes Web server filters that offer the following functionality.
Administrators can extend this list by creating their own custom filters.
● HTTP method control
● HTTP request control
● Length restrictions
● Resource access control
Each filter-functionality is discussed in their respective sections
HTTP method control

HTTP methods are operations that HTTP clients request HTTP servers to perform. The GET
method, for example, allows the client to retrieve whatever information is specified in the
request.
Filters can restrict the HTTP methods that can be used when accessing a server. The nature of
the restriction can be discerned from the names of the two filters under this category. The
configuration tabs for both filters are shown below.
Disallow HTTP methods Allow HTTP methods
As shown above, the configuration options for both filters are identical, and only differ in the
fact that one explicitly disallows methods, thereby implicitly allowing those that aren’t listed,
while the other is the reverse.
Administrators can allow or disallow standard HTTP 1.1 methods, as well as methods from the
Microsoft HTTP protocol extension WebDAV.
In addition to specifying specific methods, both filters also allow the administrator to specify
pages in a site that are exempted from the filter.
HTTP request control
Length restrictions
Resource access control

In addition to purely protocol hygiene
functionality, DSA can also exercise some
control over the Web content that can be
obtained from the Web server. The Disallowed
Resources filter, shown on the right, can
explicitly allow or deny access to specific
resources.
As shown in the configuration tab for this filter,
administrators identify these resources using
their file extensions. Executables (*.exe) and
dynamic link libraries (*.DLL) are disallowed by
default.

1. Which of the following are valid uses for Deep Packet Inspection
a) Virtual patching
b) Protocol hygiene
c) Application control (limited)
d) All of the above
2. Which of the following describes how DPI works?
a) Traffic from select IP addresses are blocked

b) Packets containing malicious/undesired instructions are blocked
c) Specific protocols are blocked
3. Which Trend Micro pattern contains information that is comparable to DPI rules?
a) VSAPI pattern
b) SSAPI pattern
c) Generic Stream Scanning rules
d) OfficeScan firewall rules
Chapter 11: Protecting

Virtual Machines
Chapter Objectives
● Understand key virtual networking concepts
● Understand how DSVA works
● Understand how VMSafe API is used in DSVA

This chapter focuses on the Deep Security Virtual Appliance (DSVA), and is divided into the
following sections:
● VMware basics
● DSVA basics
● DSVA operation
● Known issues
FOR READERS WHO ARE NEW TO VMWARE TECHNOLOGY AND TERMINOLOGY

To better understand this chapter, readers are who need an introduction to the underlying
infrastructure needed for VM protection to work are advised to refer to Appendix ___ :
Introduction to VMware technology and terminology.
11.2 > DSVA basics

DSVA performs the following functions for the virtual machines that it protects:
● Instant-on protection
● Network traffic protection
● Anti-malware protection
● Agentless file integrity monitoring
Each feature is discussed in their respective sub-sections below.
11.2.1 Instant-on protection

The introduction of Event-based tasks in Deep Security 7.5 Service Pack 2 gave administrators
the ability to automatically assign and activate virtual agents to protect virtual machines that were
added to an ESX server, and then automatically assign security profiles that were matched with
the environment contained within the virtual machine. This replaced the original version 7.0
Service Pack 1 profile assignment mechanism that a single global profile that had to be
appropriate for all operating systems.
11.2.2 Network traffic protection

DSVA works by intercepting network traffic intended for virtual machines, and then analyzing
this traffic for malicious content. A high-level – very simplified -- overview of the components
involved in this operation is shown below.
Deep Security Virtual Appliance
Master
agent Instantiated agents
Virtual
Virtual agent Machine
Actual path
Intended path
Network vmKernel
traffic (with vmSafe)
Important: Details of how DSVA is able to get vmKernel to send packets its way, instead of to
the VM, are discussed in later sections in this chapter. At this point, the key concept to
remember that it can be done.
The components are as follows:

vmKernel – this is the ESX hypervisor, the component that makes virtualization possible.
DSVA installs components on the ESX server that leverages the kernel’s vmSafe API
for performing packet interception and analysis.
Virtual machine (VM) – this is the entity being protected. As with real machines, Deep
Security agents can actually be installed on it for full protection. DSVA, however, is able
to offer limited traffic-analysis-only protection even without an agent installed.
Master agent – this is a full featured Deep Security agent that protects the DSVA itself. It is
also responsible for creating virtual agent instances in response to requests from the
DSM. Once created, the DSM activates the virtual agent and protection for the
corresponding VM begins
Virtual agent – this is responsible for providing DPI and firewall protection to the virtual
machine. VMSafe API functions allow DSVA to intercept packets and redirect them to
this agent for analysis. There is a one-to-one relationship between virtual machines and
virtual agents. The master agent needs to create a virtual agent for each virtual machine
on the ESX server.
Important: The vmSafe API is not present in the free version of VMware ESXi. DSVA in version
8 requires the full featured ESXi version 5. For version 7.5, it requires version ESX or ESXi
version 4.1
DSVA is able to intercept traffic to the protected VM through a Fast-path driver that is installed
on the vmKernel. This is shown below.
DSVA
Virtual
Virtual
agent
Machine
vNIC_d vNIC
vSwitch FastPath
dvFilter driver
Actual path
Intended
path
Network vmKernel vSwitch
After interception, the FastPath driver redirects the packet to the DSVA vNIC, which then
passes it to the Virtual agent created for the VM.
11.2.3 Anti-malware protection

The Anti-Malware protection module was introduced in Deep Security 7.5 and provides anti-
malware functionality for virtual machines – without installing components on the VMs
themselves. Deep Security 8.0 takes advantages to changes to VMware virtual environment that
were introduced in ESXi 5.
A high-level overview of how it works appears below.
ESX
DSVA VM
EPSec API
EPSec API
(Anti-Malware
(VMTools)
daemon)
EPSec Read file

service
Write cleaned file
Hypervisor
To provide Anti-Malware functionality, the DSVA interfaces with the VMware Endpoint
Security (EPSec) system. The system consists of EPSec API components that reside within the
Anti-Malware daemon on DSVA, the EPSec drivers on the protected virtual machines, and a
EPSec service that is installed on the ESX hypervisor.
The EPSec service handles the routing of data between DSVA and EPSec compatible virtual
machines. It is responsible for passing file system data from the virtual machine to the DSVA,
and for retrieving EPSec configuration from the DSVA and applying them to the EPSec drivers.
DSVA - EPSEC SERVICE COMMUNICATION

The EPSec service polls the DSVA every 10 seconds to obtain configuration information.
This information could be anything from a change in the scan exclusions that the EPSec
driver on the VM should implement, or a manual scan request.
Administrators install this component using VMware vShield Manager, using the following
screen control.
Tip In version 7.5, a Loadable Kernel Module (LKM) performed the function of the
EPSec service.
On the virtual machine side of the relationship the EPSec API is contained within a version of
VMTools that was first made available in ESXi 5. Previously this component was only available
as a “thin client” that administrators had to install using a separate MSI installer. Although the
relevant drivers are incorporated in VMTools, they are not actually installed by default.
Administrators must perform a “custom” installation of VMTools and install VMCI and vShield
drivers.
VMTools is responsible for hooking I/O events on the virtual machine, and then passing data to
Anti-Malware daemon on the DSVA, where the VSAPI scan engine analyzes the data. If VSAPI
determines that a file needs to be cleaned, a copy of the file is created in the DSVA for the
VSAPI to work upon, and then the cleaned copy replaces the file on the VM.
As mentioned earlier, the DSVA hosts an Anti-Malware daemon. This interacts with the modules
listed below.
Events
Virtual Scan
request
Common modules
Agent
Scan Scan
configuration engine
Anti-
Malware
Patterns
Scan
Common module update result
Master
Agent Smart scan
Start / Stop interface
File data for

Action
scanning
EPSec
Data from VMTools
module
Each VA is given its own scan settings. So the AM daemon can scan files from each VM and
apply the corresponding scanning configuration. Consequently, all scanning events generated for
a particular VM are sent back to its corresponding VA.
The Master Agent is responsible for starting and stopping the AM daemon, as well as updating
the various common modules.
“Common modules” refer to the following components:
Scan engine – this is the same Virus Scanning API (VSAPI) scan engine that is used in
other Trend Micro products.
Patterns – depending on the scanning mode selected, DSVA can use conventional (lpt$vpn)
or Smart scanning (icrc$) patterns.
Smart scan interface – this refers to the icrchandler that is responsible for querying scan
servers when the DSVA is in Smart scanning mode
ANTI-MALWARE TOPICS
Details about Anti-Malware functionality are available in the next Chapter.
11.2.4 Agentless File Integrity Monitoring

This feature leverages the same EPSec components that are used for Anti-Malware functionality.
It uses the EPSec component’s ability to obtain data about files and a VM, and then compares
this information with baselines on the corresponding VAs to detect changes.
Unlike full Integrity Monitoring capability that is available with DSAs, IM functionality in DSVA
is only limited to monitoring files, and it only works with Virtual Machines with Windows-based
operating systems.
11.3 > DSVA internals

The following aspects of DSVA are discussed here:
● File structure
● About Master Agents
● About Virtual agents
11.3.1 File structure

The DSVA consists of the following files:
Disk 1 is the called the root disk, which contains the source files for DSVA functionality. Disk 2
is a spare disk to which upgrade files are downloaded in preparation for an upgrade of the root
disk. Disk 3 is used to store VM data and for storing quarantine files.
11.3.2 About Master Agents

The file structure of a Master Agent is shown below
True to its role as protector of the DSVA, it consists of many of the same files that would be
found on a DSA. Its files can be found in the following directory within the DSVA:
/var/opt/ds_agent/
Note the sub-directory called guests in the screen capture above. This directory contains the files
associated with Virtual Agents. As explained in the Network traffic protection section, Master
Agents instantiate Virtual Agents (VA) for each protected virtual machine that does not have a
DSA installed.
Details about the instantiation process are available in the DSVA Operation section.
Consider the following environment. This ESX server is protected by a DSVA called GECS-
DSVA), and contains five other VMs, of which three are powered on and activated.
A hierarchical process list for this environment appears below.
The Master Agent corresponds to the ds_agent process. To protect the three active Virtual
Machines, the master agent creates three VAs. Each VA corresponds to a ds_guest_agent process.
11.3.3 About Virtual Agents

A VA is essentially a collection of files that are virtually identical to those on an ordinary DSA.
The instantiation process creates a copy of the virtual agent files in a sub-folder within the
DSVA itself. Files for each VA are stored under the DSVA guests directory, particularly under
sub-folders named after the BIOS UUID of the virtual machine that the VA is protecting.
NOTE Virtual Agents are matched with VMs based on the latter’s UUID.
This corresponds to the following view of a VMware vSphere client that shows the
aforementioned ESX server. The Virtual Machines tab provides details for each VM, to include
their BIOS UUIDs.
You can also view a VM’s UUID by opening its VMX file (configuration file). For example, the
VMX file for the CentOS VM is CentOS.vmx.
This contains the following entries:
uuid.bios = "42 3a d4 fc 9c e2 e5 b7‐90 82 a9 b5 34 cd ce aa"
vc.uuid = "50 3a e8 ff b4 26 d0 ce‐c6 45 28 91 e2 f6 1c 38"
The screen capture below shows the VA directories the guests directory of the GECS-DSVA
appliance.
The directory for the VA that protects CentOS is 420f4235-0bcd-4c18-b8a7-e2c0c0f0227a.
11.4 > DSVA operation

This section provides information about how DSVA works, and is divided into the following
sections:
● Preparation and deployment
● Traffic analysis
● Anti-Malware operation
● DSVA-related communication
● DSVA configuration
● Protecting VMs
● Coordinated protection
11.4.1 Preparation and deployment

“Preparation” is the process of installing the DSVA kernel driver onto the vmKernel of the ESX
machine where DSVA will be installed. “Deployment” is the process of adding the DSVA to the
ESX.
NOTE In version 7.0 ESX preparation was separate and distinct from the DSVA
deployment process. Both wizards were linked in 7.5, so that users had the option to
start the deployment wizard immediately after completing the preparation wizard. This
design has been retained in 8.0
This section discusses each of these processes in the following sub-sections:
● ESX preparation
● DSVA deployment
ESX preparation
The following vCenter events record the preparation process. Note that these entries start from
the bottom and progress upward.
For purposes of discussion, the process listed above is grouped as follows:

● Enter maintenance mode
● vSwitch and port group preparation
● Install driver and exit maintenance mode
ENTER MAINTENANCE MODE

The first step in the process involves entering the ESX server into Maintenance mode. This
mode is required whenever changes are made to the operating environment on the server, such
as installation of DSVA kernel driver.
Important: VMs on an ESX server will lose network connectivity when their host goes into
maintenance mode. For this reason, the DSM, Center Server, and vShield Zones Manager
cannot be installed on VMs that are hosted on the server that is being prepared.
Early in the DSVA activation wizard, administrators are presented with the following option.
Choosing “No” sets the wizard to wait for 10 minutes for the ESX server to go into
maintenance mode, before verifying the status of the attempt. During this interval,
administrators need to enter the ESX server into Maintanance Mode through using a vSphere
Client, as shown below.
VSWITCH AND PORT GROUP PREPARATION

As shown in the events list, the ESX server creates a
port group and a virtual switch as part of the
preparation process. The end result is shown on the
right.
NOTE The two-switch design

shown above is a VMware
mandated topology. By design,
the only way to communicate
with a VM is via a switch.
Therefore, for the DSVA to be
able to intercept traffic and be
able to communicate with its
DSM, must exist on both
As shown above, a properly prepared ESX server will have at least two vSwitches:
External communication vSwitch – the DSVA uses this for communication with the
DSM. It shares this switch with the VMs that it protects that also use this switch to
connect with the outside network. In the screen capture above, this is vSwitch0.
Internal communication vSwitch – the DSVA uses this to communicate with the kernel
driver. In the screen capture above, this is vmservice-vswitch.
To operate on both switches, the DSVA maintains the interfaces shown below:
External Internal Kernel

DSM eth0 DSVA eth1
switch switch driver
For DSM communication on the external switch, it uses eth0, and uses eth1 for the internal
switch from which it receives redirected traffic.
For information, about how to verify the condition of the interfaces, see
Appendix A: Deep dive information > Chapter 11: Protecting virtual appliances
> Connectivity issues
To ensure connectivity between the eth1 the kernel driver, the driver must bind to the IP address
of the vmKernel itself. This IP address is collected during the Center Server addition process,
and the DSVA wizard simply re-uses the information already available.
As shown in the network diagram earlier, the default IP address of the kernel is 169.254.50.1. For
this reason the kernel driver IP address, which is shown in the DSVA deployment wizard – with
strongly worded warnings against modification – must be identical to the default kernel IP
address.
The wizard presents default IP and subnet mask values are should not be changed unless
absolutely necessary. If a change is required, administrators must observe the following rules to
maintain connectivity and protect vMotion functionality.
● DSVAs in the same vCenter must have the same Appliance IP address
● VM Kernel and DSVA must reside within the same subnet to communicate. As a
consequence of the first rule, all appliances must be in the same subnet.
INSTALL DRIVER AND EXIT MAINTENANCE MODE

Once the necessary port groups and switches are created, the kernel driver is installed. During
ESX preparation the DSVA kernel driver is copied from the DSM to the ESX server.
Responsibility for this transfer resides with VMware vCenter, which offers an API specifically
for such purposes.
The DSM leverages the API as follows:
DSM vCenter ESX
Driver location on DSM
Driver location on DSM
Connect to DSM, download driver
1. The DSM passes a temporary URL to vCenter indicating the location of the DSVA kernel
driver on the DSM
2. vCenter passes this URL information to the ESX server
3. ESX server downloads the kernel driver from the DSM and then enters into maintenance
mode and installs the driver upon itself. Throughout this process the ESX server sends
events to vCenter.
The key point to emphasize here is that the ESX server must be able to download the driver
from the DSM. If it is not able to do so, then the preparation process will fail.
This deployment design has the following implications:
● The DSM cannot be installed on the ESX server where the DSVA will be installed. Since the
ESX server must go into maintenance mode during preparation, it will lose connectivity with
the DSM
● Preparation failures are often related to connectivity and name resolution issues
For information about connectivity issues, see Appendix A: Deep dive

information > Chapter 11: Protecting virtual appliances > Connectivity issues
Once installation is complete, the ESX server is brought out of Maintenance mode. The end-
result, as seen from the DSM, should appear as follows.
DSVA deployment
Once the ESX is prepared, the DSVA can be deployed. While it is actually possible to deploy a
DSVA to an unprepared ESX server, the appliance would still require preparation of its host
before it could operate.
Like the preparation process, DSVA deployment is done via vCenter which records the
following events.
As shown above, DSVA deployment leverages the VMware template deployment mechanism.
DSVA activation
DSVA activation works the same way as with DSAs. This action enables DSVA self-protection,
and initiates Virtual Agent instantiation functionality.
ACTIVATION PRE-REQUISITE
If the DSVA is deployed to an unprepared ESX machine, it cannot be activated. Activation
attempts would fail resulting in the following error message.
With the addition of Anti-Malware functionality, the activation process now incorporates EPSec
functionality verification. The following flowchart illustrates the current activation process.
Retrieve Yes No
Network Activate DSVA
Initiate networking Prompt user for vSM details
configuration w/ AM
activation details for vSM details available?
available? functionality
Center server
Yes
No
Fail Connect to
vSM
No
Connection
successful?
Yes
Verify EPSec
components
Activate DSVA No Yes

w/o AM EPSec ready?
functionality
As shown above, DSVA activation can proceed even if vSM details are not given. In such
situations, the following message appears on the wizard.
It should be noted that Anti-Malware functionality will be absent if vSM information is not
available.
PROVIDING VSM CREDENTIALS LATER

Administrators can choose to add vSM credentials at a later point by entering the relevant
information in Center Server properties, as shown below, and re-activating the DSVA.
The wizard uses vSM information logon to the server, and determine if the ESX host upon
which the DSVA is being installed is “EPSec ready”. A host that is “ready” must have the EPSec
service installed and properly registered with vSM.
Virtual Agent activation

Like regular DSAs, Virtual Agents (VA) must be activated before they can provide protection for
their VMs. Administrators can activate them along with the DSVA using the DSVA deployment
wizard. The relevant wizard screen appears below.
They can also be activated manual by right clicking on the VM record on the DSM screen.
The VA activation process, however, goes beyond simply establishing communication with the
DSM. It implements changes in the following areas:
● DSVA files and file structure
● VM configuration
Subsequent sub-sections discuss each of these areas.
DSVA FILES AND FILE STRUCTURE

A Virtual Agent doesn’t actually exist until it is activated. Activation creates the agent’s sub-
directory, under the /var/opt/ds_agent/guests, along with its component files.
The DSVA Master Agent is responsible for these changes which are all part of the VA
instantiation process.
The DSVA syslog records the instantiation process. Relevant sections of the log appear below.
Aug 8 03:50:57 dsva logger: starting guest uuid=423ad4fc‐9ce2‐e5b7‐9082‐a9b534cdceaa ...
Aug 8 03:50:57 dsva ds_guest_agent[433]: Updating database
/var/opt/ds_agent/guests/423ad4fc‐9ce2‐e5b7‐9082‐a9b534cdceaa/ds_guest_agent.db from
schema version 0 to version 3
. . .
Aug 8 03:50:58 dsva logger: started guest uuid=423ad4fc‐9ce2‐e5b7‐9082‐a9b534cdceaa (1)
The VA created above protects the VM with the following BIOS UUID: 423ad4fc-9ce2-e5b7-
9082-a9b534cdceaa. The VA directory name is based on this UUID. Once the files are created,
the Master Agent starts the VA and protection rules can be applied to the VM.
NOTE The DSVA syslog is stored in /var/log. The in-use syslog is named messages.
Where deactivation of a DSA simply causes the deletion of select files, VA deactivation results in
termination of the VA process, and deletion of its directory from the guests folder. The DSVA
syslog records this as follows:
Aug 8 04:51:16 dsva logger: stopping guest uuid=423ad4fc‐9ce2‐e5b7‐9082‐a9b534cdceaa ...
Aug 8 04:51:16 dsva logger: stopped guest uuid=423ad4fc‐9ce2‐e5b7‐9082‐a9b534cdceaa (0.1)
Enabling Anti-Malware protection

From a purely Trend Micro perspective, enablement of Anti-Malware protection is a simple
matter of making sure that the appropriate Activation Code is entered in the DSM license screen,
and then providing vShield Manager information at the vShield Manager tab of the vCenter
Server properties screen.
However, for Anti-Malware functionality to work, administrators must also configure VMware
VMtools on the VM properly. EPSec functionality is not enabled by default. To do so,
administrators must install or VMtools through the following menu
Select an Interactive tools upgrade retain control over the process. This is the only option
available if VMTools is being installed for the first time.
Run setup64.exe to start the installation wizard
Run the wizard, and then select a Custom installation
Expand VMware Device Drivers
Scroll down to VMCI Driver, and then install vShield Drivers
11.4.2 Traffic analysis

Before version 7.5 SP1, the DSVA divided traffic processing between fragment and packet
analysis phases along the same lines as the DSA driver.
Application
DSA driver
Data link layer Fragment Packet

Redirect
analysis analysis
Network Interface
Card
Fragment analysis – this involved inspection characteristics of the individual fragments for
issues and/or problems that could be analyzed without re-assembly of the fragments
Packet analysis – this involved re-assembly of the packet from the individual fragments to
permit more complex analysis of the actual content of the packet
The DSVA used a so-called fast path driver, which was installed on the vmKernel on the ESX
server, to process fragment analysis, while a slow path driver, installed within the individual
Virtual Agents handled packet analysis.
Since version 7.5 Service Pack 1, and continuing into version 8.0, DSVA designers took
advantage of improvements to the vmSafe API, first introduced in ESX 4.1, and re-architected
the process as follows:
Verification
Fragment
Micro filter
analysis
Blacklist
Fast path
driver
Reassembly
Packet Firewall
analysis
Deep Packet Inspection, Slow path

Stateful configuration, SSL inspection driver
NOTE The sequence shown above also holds true for packets that originate at the VM
and is destined for either other VMs or the network.
Most processing now occurs in the vmKernel. The DSVA now only process DPI, stateful
configuration, and SSL inspection, and instead of spreading this out to the individual VAs, all
this is consolidated within the DSVA. The relevant components appear below.
11.4.3 Anti-Malware operation

Deep Security version 8.0 now offers both agentless Anti-Malware, based on DSVA, and in-
guest Anti-Malware protection using an appropriately configured DSA. Both options are
discussed in the next chapter.
11.5 > DSVA-related communication

To deploy and manage DSVA, the DSM must be able to communicate with the DSVA itself,
and the Center server that manages the ESX server upon which DSVA is installed.
DSVA DSM server Center server
This section will focus on the nature of this communication and when they are necessary.
Disruption of either communication is undesirable, but will not actually disrupt protection
functionality once it is already in place. This section provides information about when either
communication is critical and is divided into the following sub-sections:
● DSVA communication basics
● DSM and VMware Center Server
● DSM and vShield Zones
11.5.1 DSVA communication basics

The following table summarizes DSVA-related traffic
Traffic between: DSVA & DSM Center server & DSM ESX & DSM
Description This is virtually The DSM needs this This only applies to
identical to the traffic communication to the state prior to
that would transpire receive VM-related DSVA deployment.
between a DSM and events. This includes:
DSA. This consists of:
• VM creation
• Rule updates • VM start/stop
• Log events events
• Heartbeat • vMotion events
messages
Frequency Either according to The DSM always stays N/A

heartbeat schedule or logged on to Center
upon administrator server.
intervention
If the connection is
lost, the DSM tries to
re-establish
communication every
10 minutes
Effect when disrupted
During N/A Will cause deployment Will cause

deployment to fail deployment to fail
During normal Will prevent rule Will prevent detection N/A

operation updates and event of VM creation and
consolidation at the vMotion events. VM

DSM. Syslogs may status indicators on
still work. the DSM will not be
updated
11.5.2 DSM and VMware Center Server

As discussed in the previous section, DSM communicates with Center Server to obtain
information about the virtual environment it is protecting. This section dwells on this
communication channel and is divided into the following sub-sections:
● Center Server only communication
● Reconfiguring Center Server configuration
● DSM-Center Server synchronization
● VM creation detection
Center Server only communication

When VM support was first introduced in version 6.0, the DSM was able to either interface
directly with ESX servers to collect information about their virtual environments, or with the
VMware Center Server that managed the ESX server. Starting in version 7.0, the DSM is actually
prevented from communicating directly with ESX, and safeguards were put in place to ensure
that the DSM could only communicate with the Center Server. If an administrator were to
attempt to directly add an ESX server to the list, the following error would be generated.
The Center-Server-only design was implemented to ensure that DSM would be able to support
VMware functionality that required information that would only be available from the Center
Server. An example of this would be vMotion information.
Re-configuring Center Server communication

The Add vCenter wizard at the Computer list screen ensures that the DSM has sufficient
credentials to establish a relationship with a particular Center Server instance. The wizard would
fail otherwise.
Should this information change, administrators need update the information by right-clicking the
relevant Center Server on the host tree and selecting Properties.
As shown below, there are three aspects of Center Server communication that can be
reconfigured.
General – this defines basic DSM – Center Server communication. The latter’s host
information, communication port, and logon credentials can be reconfigured here.
vShield Manager – this defines access to the vShield Manager, and is only required when
Anti-Malware functionality is used
Network configuration – this defines the IP address and subnet configuration that DSVA
kernel drivers use when they are deployed to ESX servers. This should not be modified
unless absolutely necessary.
Both the General and vShield Manager tabs feature test buttons for verifying settings. Incorrect
settings will generate the following message within the window.
DSM-Center Server synchronization

The DSM synchronizes its information with Center Server constantly to ensure that it captures
any and all changes that occur within the virtual environment (e.g., VM creation, vMotion events,
etc.). Although this synchronization occurs automatically, administrators still have the option to
synchronize manually.
NOTE Manual synchronization is primarily a troubleshooting tool and rarely required.
This can be done from two locations. One location is from the host tree, as shown below.
The second can be found in the Center Server properties screen.
Synchronization events are recorded in System Events as shown below.
If the DSM is unable to synchronize with Center Server, it won’t generate alerts or send
notifications to the DSM administrator. But it will record these failures in System Events.
NOTE As shown in the sample, the DSM automatically attempts to re-synchronize every
10 minutes and 21 seconds.
VM creation detection
Among the activities that DSM monitors is VM creation. If it is not able to detect these events,
then it will not be able to automatically instantiate the corresponding virtual agent. The following
diagram shows how VMs are detected.
Center Fastpath Master Virtual

DSM vmKernel Slowpath
server filter agent agent
VM created
Bind Fastpath
Bind Fastpath to
vNIC Create filter
instance
Phase 1
Create virtual
agent Create virtual
agent instance
Fork Slowpath
Register
Slowpath
Phase 2
Activate agent
Set config
Set Fastpath
Phase 3 config
As shown in the diagram the process for protecting new virtual machines that do not already
have DSAs installed can be broken down into three phases:
● Phase 1: Bind VM vNIC
● Phase 2: Create virtual agent
● Phase 3: Activate virtual agent
Each time a virtual machine is created, the Center server notifies DSM, thereby prompting the
Master agent in DSVA to instantiate a virtual agent for that VM. Once the virtual agent is
created, administrators can either activate them like they would with a regular DSA, or activate
them automatically using Event based tasks.
Event-based tasks, first introduced in version 7.5 SP1, define system responses when a Virtual
Machine is added or moved to a protected ESX server. The following events can trigger these
tasks:
1. Attempt to activate agent on VM
2. Assign a profile based on the VM’s parameters
The relevant screen appears below.
11.5.3 DSM and vShield Manager

The DSM needs to be able to communicate with the vShield Manager to obtain status
information about EPSec components in the virtual environment. Only after being able to verify
that these components are in place will it show that Anti-Malware functionality is available on a
particular ESX server, DSVA, or Virtual Agent
DSM administrators can manually verify the presence of EPSec components on the ESX by
logging on to the Center Server client, or to the vShield Manager console.
11.6 > Configuration options

In addition to configuration options that are available on the DSM console, the Deep Security
Virtual Appliance has its own console that is accessible from the VMware vCenter Client, as
shown below.
From the vCenter client, the administrator can choose to use one of the following:
● Command line interface
● Graphical interface
Each option is discussed below.
Command line interface

Administrators can open the command line interface by pressing Alt-F2 while at the screen
shown above. This displays the screen shown below.
After entering the appropriate credentials, the appliance offers the administrator a bash shell.
To return to the graphical console, enter Alt-F1.
Graphical interface
To use the graphical interface, press “F2” to open the user authentication dialog box, where
administrators can enter the password to access the console.
Tip The default password for the console is dsva.
This opens a screen with the following options
Each option is discussed briefly below:

System information – provides basic information about the DSVA version and the DSM
with which it is activated
Configure password – this changes the password used to access the console
Configure Management Network – allows the administrator to change the name of the
appliance and its IP address
Virtual Agents – accesses a listing of active Virtual Agents
Reset Appliance – this is the DSVA equivalent to the “dsa_control.exe /r” command,
which deactivates the appliance and all the virtual agents within it.
Options for virtual agents

The DSVA allows administrators to view operational information about each Virtual Agent.
Once a VA is accessed on the screen shown previously, the following options are available
The Show var option show the system variable that in use with the VA.
The Show stats option presents information about the packet analysis activities. This is
comparable to the data that is available via the RATT tool.
11.6.1 Protecting VMs

The following aspects of VM protection are discussed here:
● Maximum number of VMs

● Viewing protected VMs
Maximum number of VMs

With the release of ESX 4.0 Update 1, the default maximum number of powered-on VMs that
DSVA can protect is 25. Up to 100 virtual agents can be instantiated, but only 25 can be running
at any given time.
NOTE Prior to Update 1, ESX 4.0 restricted the number of protected VMs to 15
powered-on VMs.
It is, however, possible to increase the number of protected VMs through tuning. See note
below.
INCREASING THE NUMBER OF SUPPORTED VIRTUAL MACHINES

The following was taken from the following Knowledgebase article:
http://intkb.trendmicro.com/Pages/How-to-tune-memory-on-ESX-for-DSVA-to-support-
more-than-25-virtual-machines.aspx
To permanently increase the maximum size of heap memory in the fast path driver, you
need to log in to the console and issue the “esxcfg-module” command and provide a
maximum heap size in bytes.
The formula is: <number of VMs> * <1048576 Bytes (1 MB)> + 8388608 Bytes (8MB)
So, for example, to increase supported VMs to 32:
32 * 1MB + 8MB = 41943040 Bytes
And the command to set the value is:
% esxcfg-module -s DSAFILTER_HEAP_MAX_SIZE=41943040 dvfilter-dsa
To verify the setting, you can execute:
% esxcfg-module -g dvfilter-dsa
The setting will not take effect until the driver is reloaded. Reloading will either require
a reboot (best option) of ESX or unload/load the driver by executing the commands:
% esxcfg-module -u dvfilter-dsa
% esxcfg-module dvfilter-dsa
Note: The above unload/reload will require all the protected VMs on the ESX(i) and the
DVSA to shutdown.
Viewing protected VMs

Protected VMs, and by extension the virtual agents that provide DPI and Firewall functionality
are displayed in the DSM console as shown below.
The list above shows a solitary protected VM, which would correspond to the following entry in
Computers List
NOTE Disks representing Integrity Monitoring and Log Inspection are greyed out,
indicating their absence.
Administrators can view detailed information about status and security information about the
protected VM from either location.
Additional information about the VM is available from the DSVA console, which is accessible
from vCenter by way of the Virtual Agents menu
Like the sample on the DSM console, there is a solitary virtual agent, which represents the
protected VM. Selecting the VM from the list reveals information about the traffic that the agent
is processing as shown below. Information about the VA’s state table is also visible on this
screen.
11.6.2 Coordinated protection

When a DSA is installed on a Virtual Machine that is already protected by DSVA this creates a
condition called “coordinated protection”
In this mode, responsibility for protecting the VM resides with the DSA, and the DSVA
becomes passive. However, if the DSA becomes dormant for one reason or another, the DSVA
re-assumes responsibility for protecting the VM.
This section explains the benefits and disadvantages of coordinated production, and how this
“hand-over” of responsibility between the DSA and DSVA occurs. It is divided into the
following sections.
● Feature comparison
● How it works
Feature comparison
The following tables compare DSVA-based (Agentless) and DSA-based (In-guest) Anti-Malware
protection.
Feature / Capability / Agentless (DSVA) In-guest (DSA)

Component
Take action upon malware Yes Yes
files
Take action upon malware in No Yes

memory
Registry cleanup No Yes
Stop malware processes No Yes
Leverage VMware Endpoint Yes No
Security
Firewall functionality Yes Yes
Deep Packet Inspection Yes Yes

functionality
Log Inspection functionality No Yes
Integrity Monitoring File-based Integrity Yes

functionality Monitoring only
Recommendation scan No Yes

functionality
DSVA-based protection offers the following key advantages:

No footprint on protected Virtual Machines – this means that there will be no resource-
contention on these VMs as a result of protection
Minimal update-related traffic – the absence of components on the VMs means that the only
update related traffic (e.g., for virus patterns, scan engine, etc.) occurs on the DSVA. VMs are
not affected by component updates
Its disadvantages, on the other hand are:
Lack of in-memory scanning – if a Trojan manages to enter the virtual machine,
subsequent pattern updates may be able to detect the file component of the malware,
but will not be remove its in-memory components
Lack of damage cleanup – the lack of an in-guest component means that the DSVA will
not have Damage Cleanup Service functionality to address changes to the Windows
registry and similar malicious alterations
Limited HIDS capability – the DSVA is only limited to File-based Integrity Monitoring
and will not have Log Inspection functionality
Lack of recommendation scan functionality – the DSVA cannot retrieve metadata from
the VMs it protects, so the DSM will not be able to automatically ascertain the security
requirements. The assignment of DPI and IM rules, therefore, is a manual affair.
All of these shortcomings are addressed by installing a DSA on the VM. However, a DSA will
negate all the resource contention and bandwidth conservation advantages of the DSVA.
Administrators therefore must assess the security needs of their environments and determine the
appropriate mix.
RECOMMENDATION SCANNING FOR AGENTLESS ENVIRONMENTS

Administrators can install a DSA on a VM that is representative of the other VMs on an ESX
server, perform a recommendation scan on that lone DSA, and then apply the
recommendations to the rest of the agentless VMs. To facilitate this, place all agentless
VMs in the same security profile as the VM with coordinated protection.
How it works
The switch between DSVA-based protection and DSA-based protection, and vice versa, is
triggered by DSA status messages using the proprietary Coordinated Approach Status Protocol
(CASP).
NOTE CASP is an IP datagram using IP protocol 99.
The following diagram provides an overview of how this works.

Status Status
message message
DSM
ESX server
FIOCTL CASP
Filter
DSVA driver DSA
(Fast path)
If protected If protected
by DSVA by DSA
VM
Network
traffic
As discussed earlier in this document, when an ESX server is prepared and DSVA is deployed, a
fast path filter driver is installed on the ESX hyperviser to intercept network traffic on behalf of
the DSVA. When a DSA is installed on a protected VM, it will send CASP messages to the filter
driver, which will initiate the following switching process:
Filter
DSVA Driver DSA
(Fast path)
X
DSVA active
Y
CASP message
Z
IOCTL
[
Switch DSVA to
standby mode
1. An active DSVA is present on the ESX server when the DSA is installed on the VM
2. The DSA sends a CASP message to the filter driver on the ESX server
3. The filter driver generates an IOCTL in response to the CASP message
4. The DSVA receives the IOCTL and the DSVA switches to standby mode
The resulting status message appears in the screen capture below.
To retain DSA-based protection, the filter driver must continue to receive CASP messages from
the DSA. If a configurable number of CASP messages are missed, then the filter driver will
automatically switch protection back to the DSVA according to the following process:
Filter
DSVA Driver DSA
(Fast path)
X ???
No CASP message
received (default: 2)
Y
IOCTL
Z
DSVA active
The following system setting controls define how often CASP messages are sent, and how many
times it can be missed before the DSVA regains responsibility for protection.
By default, if two messages are missed, the filter driver issues another IOCTL in response, and
the DSVA becomes active again.
CASP messages can also return VM protection back to the DSA once either communication is
restored or the DSA is restarted. The process for this switch is similar to the first diagram,
however, instead of a single CASP message, the filter driver will require multiple messages before
initiating the process. The number of messages is configured using the control shown below.
By default, the filter driver must receive two CASP messages. This requirement was designed to
ensure that connectivity between the DSA and the filter driver is sufficiently stable before
placing the DSVA on standby. This reduces connection disruptions caused by the DSVA-DSA-
DSVA switch.
11.7 > Working with vMotion

This section focuses on how DSVA works with VMWare vMotion functionality and is divided
into the following sections:
● vMotion basics
● Moving DSVA data
11.7.1 vMotion basics

VMware documentation describes vMotion as follows:
VMware® VMotion™ enables the live migration of running virtual machines from one
physical server to another with zero downtime, continuous service availability, and
complete transaction integrity. VMotion is a key enabling technology for creating the
dynamic, automated, and self-optimizing datacenter.
(From: http://www.vmware.com/files/pdf/VMware-VMotion-DS-EN.pdf)
vMotion is typically used for the following purposes:
Load balancing – VMs can be moved automatically and transparently between ESX servers
in a datacenter to distribute the processing load
Migration for maintenance – VMs can be automatically migrated to other ESX servers
when a particular ESX server is being brought offline for maintenance
DSVAs can protect VMs even if they move between ESX servers – provided that the destination
server has a DSVA installed.
NOTE By design, the DSVA cannot be migrated to another ESX server via vMotion.
11.7.2 Moving DSVA data

As explained at the start of this chapter, each protected VM has a corresponding Virtual Agent
(VA). So when a VM is transferred to another ESX server, its VA must also be replicated at the
DSVA on the receiving ESX server.
The following diagram shows how this works.

vMotion
ESX 1 ESX 2
VM VM
VM
communication
VA within DSVA channel VA within DSVA
VA data VA data
Deep Security Relay
VA data Nginx Web VA data

(IM‐related) server (IM‐related)
During vMotion, the following data, that define a VA’s identity, are compressed into a tar file
and then transferred to the destination ESX server using the default VM communication
channel:
● Certificates used for VA-DSM communication (ds_guest_agent.crt, ds_guest_agent_dsm.crt)
● AM component version information
● System event database (ds_guest_agent.db)
● Miscellaneous vMotion-related data
This communication channel, however, is limited to files that are up to 2KB. This is a concern
for the baseline database (si.db) used for File Integrity Monitoring (FIM), which can become
very large depending upon the IM rules that are applied to the VM.
For this reason IM-related data is transferred through an alternative, proprietary Trend Micro
channel involving a Deep Security Relay (DSR) – a modified version of a regular DSA that
contains an Nginx Web server. In version 8.0, DSRs are responsible for downloading updates on
behalf of its Deep Security network, and then functioning as a local update server. It normally
uses its Web server to distribute component updates.
When migrating a IM-protected VM, the DSVA does the following:
1. Encrypts the IM database on the VA
2. Includes the keys for decrypting the database into the tar file that is transferred using the
default VM channel
3. Uploads the database to the DSR
4. Once the transfer is complete, the VA has 10 minutes to:
4.1. Re-locate the DSR to which it uploaded its IM database
4.2. Download and decrypt the database
If the DSR is not able to download its database within this 10 minute window, or the some other
aspect of the transfer fails, then the VA will rebuild its baseline.
NOTE For details about how the DSVA uploads its database to the Nginx Web Server
on the DSR, see DSR Basics in Chapter 14.
11.8 > Known issues

For a list of known issues, see Appendix A: Deep dive information > Chapter
11: Protecting virtual appliances. The following issues are discussed:
• Required Windows patches

• Virtual host resolution

1. Which of the following is directly responsible for VM protection functionality
a) Deep Security Virtual Appliance

b) Virtual Agent
c) Master Agent
d) vmKernel
2. What is the VMware API that makes DSVA functionality possible?
a) Microsoft .NET
b) VM Safe API
c) Windows API
3. Which features are absent if VM protection is entirely reliant on DSVA?
a) Firewall
d) Log Inspection
4. Which of the following make Anti-Malware functionality possible?
a) VM Safe API
b) EPSec
c) DSA
d) SSAPI
Chapter 12: Malware and

other threats
Chapter objectives:
● Understand how Deep Security detects and deals with malware
● Understand the Anti-Malware Solution Platform (AMSP)
● Understand Web threats and how Deep Security protects against them

This chapter discusses Anti-Malware functionality for both physical and virtual environments,
and is divided into the following topics:
● Anti-Malware operation
● Anti-Malware configuration
● Protection against Web threats
12.2 > Anti-Malware operation

Although Anti-Malware configuration options for the DSVA and DSA are virtually identical,
there are significant architectural differences in their respective Anti-Malware implementations.
This section focuses on these differences and it divided into the following sections:
● AM on the DSA
● Agentless AM operation
12.2.1 AM on the DSA

Anti-Malware functionality on the DSA is based on a Trend Micro common component called
the Anti-Malware Solution Platform (AMSP). This is a plug-in framework that abstracts the
product from specific security technology implementations. This sub-section is further divided in
the following topics:
● AMSP basics
● Technology plug-ins
AMSP basics
The following illustrations show how it fits into a product, and how it compares with previous
Trend Micro Anti-Malware functionality implementation.
Product without AMSP Product with AMSP
Product Product
New
VSAPI SSAPI DCE
technology
Anti‐Malware Solution Platform
New
VSAPI SSAPI DCE
technology
AMSP was designed to facilitate integration of new technologies into a product with –
theoretically – minimal effort.
AMSP turns the product into a user interface generator whose principal function is to capture
Administrator’s security intentions, and then translates these into instructions for AMSP. The
latter is then responsible for leveraging the capabilities of the various technology plug-ins to
convert those intentions into action.
In a DSA installation, the DSA and AMSP actually exist as separate entities under the Trend
Micro folder.
The modules that make up AMSP can be grouped into the following functions:
Product
AMSP
(e.g., Deep Security)
Request
Core framework Action
Client library
(Administration &
(Product interface)
updates)
Technology plug‐ins
(Scan engines, patterns,
system hooks, and
Result
scan flows)
Core framework – this is a collection of files and libraries that are responsible for managing
and using the various technology plug-ins, and obtaining component updates from the
Trend Micro update center so that the plug-ins provide timely and relevant protection.
AMSP is actually separate and distinct service from the DSA, as appears below.
Technology plug-ins – these refer to the various Trend Micro scan engines (e.g., VSAPI,
SSAPI, DCE), their patterns, their corresponding drivers for hooking into the operating
system, and associated libraries that allow the AMSP framework to use them. These are
called “plug-ins” because AMSP is designed to accommodate additional technologies.
Client library - products that use AMSP, such as the Deep Security Agent, use an AMSP
client library to interface with the AMSP Core framework. The product receives the
Administrator’s user input, and then uses the client library to translate this into requests
that the Core framework then uses to configure protection.
AMSP components that make up the Core Framework and Plug-ins are stored in individual
folders in the following location: <install path>\Trend Micro\AMSP\module.
Each component is assigned an ID number, which is also used as the name of its sub-folder
under the module folder. For example, the AMSP module responsible for updating AMSP
components is called the coreUpdateManager.dll. Its ID is “7”, so it is stored in sub-folder “7”:
Within this sub-folder is another folder named after the component’s version. In this example
the coreUpdateManager.dll is version 2.1.1134.
NOTE For a complete list of components and ID numbers, see Appendix Y
About Technology plug-ins

Trend Micro signature-based Anti-Malware technologies typically consist of two basic
components:
● A scan engine
● A database of signatures
If the scan engine needs to detect malware in response to an event, as it would be for real-time
scans that run in response to file Input/Output events, then the scan engine would also have
associated drivers that would be installed on the host machine.
As of writing, the DSA uses AMSP to administer three types of engines:
VSAPI – Virus Scanning API
SSAPI – Spyware Scanning API
DCE – Damage Cleanup Engine
NOTE DSAs also use the Trend Micro URL Filtering Engine (TMUFE) for Web Reputation
Services functionality, but interfaces with this engine directly, outside the AMSP
framework.
These engines work together to provide full protection. VSAPI detects and removes file-based
components of malware, while SSAPI and DCE address malware-related system alterations
outside the file system (e.g., malware processes in memory, Registry entries, Layered Service
Providers in the protocol stack, etc.)
In addition to the engines above, AMSP uses a multi-function assemblage of components called
Eyes. It consists of several User Mode and Kernel Mode sub-components. These are:
Tmevtmgr – Event-hooking component. It registers with the Windows OS Filter Manager
as mini filter driver, thus giving it visibility into Input / Output Request Packets (IRP) to
the file system
Tmactmon – User mode communication component. It receives events from Tmevtmgr
and passess this to Tmsysevt.dll in user mode
Tmsysevt.dll – User mode interface to Eye kernel components. Passes events to the Real
Time Scan Flow controller which it uses to initiate scans
Tmcomm – provides utility functions for other kernel mode drivers and contains the logic
for the Rootkit Common Module (RCM)
Tmcommtapi.lib – library that allows AMSP to use RCM functionality

RCM functionality is used in many enumeration operations (e.g., generating a list of files or
processes for scanning)
Eyes is what gives AMSP the ability to detect Input/Output (I/O) events in real-time. The file
system event hooking component that detects these I/O events, and passes information about
the event to AMSP which then analyzes the file involved in the event. Eyes sub-components
interact with the operating system, and each other, in the following manner.
Eyes
Application
tmcommtapi tmsysevt AMSP
Create / write
User mode
Kernel mode
IRP
Filter
I/O Manager tmcomm
manager
tmevtmgr tmactmon
File system
driver
When applications create, write, or read files, they create I/O Request Packets (IRP) to the File
System driver through a Windows kernel component called the I/O Manager. Since Windows
2003, the I/O manager provided third-party applications (e.g., security, anti-malware) visibility
into the IRP exchange through another component called the Filter Manager. Third-party drivers
– called mini filter drivers -- register themselves with the Filter Manager, which then passes the IRP
to these drivers.
NOTE All mini filter drivers are registered with Microsoft Corp, which assigns “altitude”
numbers that determine their IRP receipt priority. Security software, for example, typically
receive IRPs before other applications.
Responsibility for making sure these engines work together, and are used appropriately rests
upon AMSP, particularly a component called Scan Manager (coreScanManager.dll). This
component is responsible for starting, stopping, and resuming scans.
DCE
components
Scan Flow Scan VSAPI

controller Manager components
SSAPI
components
The relationship between the Scan Manager and the various engines can be likened to a
craftsman and his tools. To use a tool, a craftsman must know what the tool is for, and possess
the requisite skills for it. In the Scan Manager, the engines are its tools, and the tool-usage
knowledge is contained within internal functions called scan handlers.
Scan Manager
Rootkit Common
Driver scan
Module
handler
(Eyes)
Damage
Cleanup DCE
DCE
Scan wrapper
handler
Process
Scan
handler
File Scan
handler
Scan flow VSAPI
VSAPI
controller wrapper
Boot Scan
handler
Memory
Scan
handler
Spyware
SSAPI
Scan SSAPI
wrapper
handler
When a scan request requires, for example, a scan of the file system, the Scan Manager uses its
File Scan handler to call VSAPI to perform the scan. In this version, the Scan Manager
incorporates the following scan handlers:
Scan handler Manual / scheduled scan Real-time scan

Driver scan This handler uses plugUtilRCM.dll to N/A
handler leverage Rootkit Common Module
(RCM) APIs in the Tmcomm
component in Eyes to detect rootkit
(TDL3 and TDL4) infections.
When an infection is detected, the

DSA will generate an alert notifying
the administrator to resort to a
rescue disk.
Damage cleanup The scan manager uses this handler N/A

handler first. It uses the Damage Cleanup
engine to detect malicious
processes, files, and undo
alterations to configuration files and
the Windows registry
Processes scan Enumerate the processes that are N/A

handler running on the system, identify the
files associated with these
processes and then uses VSAPI to
scan them
File scan handler Responsible for calling VSAPI to Receives information from a file
scan files that are not covered by system driver that detects file I/O
file-related exclusions (e.g., file, events and then uses VSAPI to
folder, file extension). analyze the event
Boot scan handler Uses VSAPI to scan the Master Boot N/A
Record (MBR)
Memory scan Scans each running process’ N/A

handler memory space gets their process
IDs and then uses VSAPI to scan
each process
Spyware scan Uses SSAPI to scans the host for the N/A
handler following Spyware-related artifacts:
• Processes
• Services
• Cookies
• Registry entries
• Shortcuts
• Layered Service Providers
• IE plugins
• Add/Remove Programs entries
• Windows policy settings
• Host file changes
In addition to the Scan Engine Wrappers, Scan handlers also interact the following other AMSP
components:
Exclusion Scan Scan Action Report

lists handler engine Manager Manager
Query
Response
Scan request
Action request
Action result
Before a scan handler sends a scan request to scan engine components, it first verifies the
relevant exclusion lists to determine if product settings permit the scan. It only sends the scan
request if it the scan object’s characteristics do not match the exclusion list.
For information the contents of exclusion lists, see Exclusion on page 257.
Once the scan handler receives the result of the scan, it calls Action Manager
(coreActionManager.dll) to take appropriate action upon whatever was scanned. This “action”
can leverage the capabilities of one or a combination of scan engines. Quarantine operations,
however, are handled by the Action Manager itself.
The action result is sent to the Report Manager (coreReportManager.dll), which is responsible
for returning threat detection and scanning status information back to the AMSP.
The scan handlers used for a scan depends on the nature of the scan: Real-time or
Manual/Schedule scan. Each scan type has its corresponding scan controller which contains the
scanning logic required to accomplish a particular type of scan. Scan manager uses the scan flow
information in the scan controllers to determine which engines are used, when they are used, and
in what order.
Real-Time
Scan Flow
Controller
Scan Scan
Manager engines
Manual
Scan Flow
Controller
There are two Scan Flow controllers:

Real-Time Scan Flow (plugRealTimeScanFlow.dll) – this library initiates scans in
response to I/O event data that the AMSP driver detects on the file system.
Manual Scan Flow (plugManualScanFlow.dll) – this library initiates a scan in response
to a request from Deep Security. Both Administrators and Deep Security scheduled
tasks can make this type of request
In the previous page, this section introduced the concept of “exclusion lists”. As stated earlier,
these lists allow administrators to define what files the DSVA/DSA shouldn’t scan, thus
avoiding redundant analysis of trusted files. In addition these administrator-configured lists,
AMSP also maintains scan caches that keep track of files that had already been scanned previous,
were found to be safe, and therefore do not need to be scanned again.
AMSP maintains the following two caches:
Real-Time
Scan cache
Real time scan
Real Time
Scan Scan
Scan Flow
Manager engines
Controller
Real time scan
Common Manual
cache scan
The Common cache includes files that are part of the Good Company List, which is stored in
tmwhlchk.ptn.
12.2.2 Agentless AM operation

In DVSA-only operation, also called Agentless protection, responsibility for detecting malware and
taking appropriate action against them is divided between VMware EPSec and DSVA. This
division can be summed up as follows:
EPSec – retrieve files or detect file I/O events on the VM and pass them on to the DSVA
DSVA – detect malware in the files or I/O events and instruct EPSec to take the
appropriate action upon the file or event
When compared to other Trend Micro endpoint products, the function of EPSec would be
comparable to the kernel-resident hook modules, while DSVA would be comparable to user
mode components.
The diagram below shows how these two components work together. This is based on a Real-
time Scan event, and begins when EPSec detects either a “File Open” or a “File Close” I/O
event with an associated “write” action.
EPSec DSVA
Initial evaluation
2nd evaluation
File event (Cache & simple Send 1st block Start VSAPI
(IntelliScan
detected exclusion lists of file data scan
[optional])
[optional])
Send additional
file information
Determine
appropriate
action
Take action
In addition to detecting events, EPSec is also responsible for maintaining the scanning cache, to
avoid redundant scanning of files that were not actually modified. If non-IntelliScan exclusion
lists are used, these are also implemented by EPSec on the VM side of the process.
If EPSec determines that a file requires a scan, it is responsible for sending the appropriate data
to DSVA. DSVA, where the VSAPI scan engine resides, is then responsible for detecting the
presence of malware. If malware is detected, it determines the appropriate action based on scan
configuration settings, and then instructs EPSec to implement the action.
The diagram below shows a “clean” scan action.
VM DSVA
VSAPI
Read Clean
File Renamed
(Infected) file
Memory
File
(Infected file
overwritten)
Once VSAPI confirms the presence of malware, a copy of the file that was locked earlier is
created in a temp folder on DSVA for cleaning. The copy is given a random name that DSVA
maps to the original file. Once cleaned, EPSec overwrites the original file with the cleaned
version of the file.
As will be explained in Actions on page 232, DSVA can be set to perform a host of actions. If
the scan action is “delete”, then DSVA simply instructs EPSec to delete the file. If the action is
quarantine, then the copy is in Temp is transferred to the quarantine folder, and then EPSec is
instructed to delete the file.
LIMITATIONS
Agentless AM functionality is limited to file-based malware. It can deal with the file
components of Trojans, but cannot undo the damage that they create since Damage
Cleanup Services (DCS) is not resident on the VM. It also cannot deal with non-file
components of Spyware (e.g., shortcuts, Registry changes, LSPs, etc.)
12.3 > Anti-malware configuration

In the previous section, the Anti-Malware operation sub-section provided a high-level overview
of how EPSec and DSVA worked together. This section will present how this feature is
configured, and how it works. It is divided into the following sections:
● Scan types
● Scan settings
● Exclusion
● Scan action
● Quarantine
● Pattern technology selection
● Limitations
12.3.1 Scan types

The profile and host-level Anti-Malware configuration screens show the types of scans that
DSVAs can perform. The profile-level screen is shown below.
These scans are defined as follows:

Real-time Scan – scan files for malware as they are accessed and/or written to
Manual Scan – this is an on demand action that scans all files within a specified scope
Scheduled Scan – this is similar to a manual scan, but is triggered automatically according
to a schedule
Assign an Anti-Malware configuration to each scan type to enable them. All available
configurations are listed in the drop down list under each scan type.
Administrators can also view a list of available configurations on the Anti-Malware > Anti-
Malware Configurations screen.
NOTE Ideally, the names of the configurations describe the scan types that use them.
However there are actually no restrictions as to what configurations a particular scan type
can use.
For as long as a host has at least one configuration, the orb on the Anti-Malware icon will appear
green. Otherwise it will appear blue.
About Real-time scan

Real-Time Scanning (RTS) is designed to detect file infection and/or malware creation attempts
as they happen. This functionality represents the primary reason for using Anti-Malware
products in the first place.
Both the DSA and DSVA possess this functionality, however their implementations are
different.
RTS IN DSA
The Real-Time scan flow controller initiates scans in response to input from the following
components:
Real Time
Scan Scan
Eyes Scan Flow
Manager engines
controller
As discussed in the About technology plug-ins section, Eyes interfaces with the Windows OS
Filter manager to gain visibility into Input/Output (I/O) events. If the I/O event is malicious,
then AMSP will prevent it.
RTS IN DSVA
The following illustration shows how this feature works.
ESX
DSVA VM
Application File
File access
request (I/O
VSAPI event) Intended
destination
of I/O event
Guest OS kernel
Anti-Malware
VM Tools
daemon
As applications, both benign and malicious, attempt to access files within the VM, EPSec-related
system drivers that are included in VMTools detect the Input/Output (I/O) event, and send data
about the file being accessed to DSVA for analysis. If malware is detected, DSVA is able to
leverage VMTools functionality to prevent the malicious change.
About Manual and Scheduled scan

Unlike real-time scans which only apply to individual objects that trigger events, manual and
scheduled scans require the scan engine/s to scan entire system areas to detect malware. The
process of collecting information is called enumeration. If a system area can be enumerated, it can
be scanned.
The DSA and DSVA use different enumeration methods. These are discussed in the following
sub-sections:
● Scanning on DSA
● Scanning on DSVA
SCANNING ON DSA
When the Manual Scan Flow Controller notifies the Scan Manager to perform a scan, its internal
scan handlers call the enumeration utilities for their respective engines. For example, to perform
memory scan it needs the utility that lists all running processes, for file scan, it uses the utility
that lists all the files and folders on the file system, etc.
The Manual Scan Flow controller requests the Scan Manager to use its scan handlers in the
following order:
1. Driver scan handler
2. Damage Cleanup scan handler
3. Process scan handler
4. Memory scan handler
5. Boot scan handler
6. Files scan handler
7. Spyware scan handler
NOTE The AMSP implementation in this version of Deep Security only implements “Full
Scan”, and does not perform “Quick Scan”. Whereas Full Scan enumerate all files on a
disk, Quick scans only enumerate run keys, and do not involve the Boot Scan Handler,
thus resulting in a faster, but less thorough, scan.
SCANNING ON DSVA
The DSVA requests the EPSec components within VMTools to perform enmueration. This
process is shown below.
ESX
DSVA VM
File File File
VSAPI
Request for data to

scan
Anti-Malware daemon VM Tools
Unlike the DSA that can analyze multiple system areas (e.g., registry, etc.), as of writing, EPSec is
limited to the file system.
SCAN TRIGGER
For the most part, both Manual and Scheduled scan work the same way. The principal difference
between the two being in the way they are started.
Important: Scheduled scans will only scan one virtual machine at a time to avoid resource
contention issues. This is not configurable in this version.
As with other recurring tasks within Deep Security, Scheduled Scans are set using the Scheduled
Task wizard.
Administrators can initiate manual scans from three locations. Two options are available at the
Computers list. The scan button on menu shown below is one option.
Alternatively administrators can right-click one of the host records and then click Actions >
Scan for Malware, as shown below.
The final option can be found on the VM’s details screen, under the Anti-Malware section.
USER EXPERIENCE PECULIARITIES

Unlike ServerProtect and OfficeScan, which allow administrators to select a particular
machine to scan, Deep Security requires definition of scan targets in rule-like
configuration settings to identify scan targets.
Aborting scans
Deep Security allows administrators to pre-terminate scans – both manual and scheduled. To be
able to abort a scan, the following conditions must be met:
● Administrator must have update rights to the appliance
● The appliance must not be locked
● Direct communication with the client is possible. This cannot work with appliances with
agent-initiated communication
If all three conditions are satisfied, administrators can abort the scan by selecting the button
shown below
Alternatively, administrators can right click the appliance on the Computer list, and then select
Actions > Abort Malware scan.
12.3.2 Scan configuration

The following options are available for each scan configuration:
● Scan settings
● Exclusion
● Actions
● Options
Like rules used in other Deep Security features, each configuration can be set to generate alerts if
they detect malware. They also provide a list of hosts to which the configuration has been
applied. The three options above are discussed in their respective sub-sections.
Scan settings
These settings define the scope and nature of the scan. The portion of the scan configuration
screen devoted to these settings is shown below. Each group of setting is discussed in their
respective sub-sections below.
FOLDERS TO SCAN
This option allows administrators to define the file system areas that are scanned. A directory list,
like the one shown below, is used to restrict scanning to specific folders.
FILES TO SCAN
The settings in this section define scan coverage. Administrators can manually specify the kinds
of files to scan by selecting Specified file extensions, and using a file list component. Note that
this option relies on file extensions, which may not necessarily indicate the true nature of the file.
Alternatively, administrators can rely on Trend Micro recommendations by choosing “All file
types” or “Intelliscan”. These two options have very subtle differences which are illustrated by
the following diagram.
Skip file
Yes Yes Yes
No No
Safe file High-risk file File size
type? extension? <=70KB
A A
All files
Skip file
No What is
High-risk
Begin scan the scan
file type?
coverage
Yes Intelliscan
B B
No File size No
High-risk file
<=70KB and
extension?
*.COM
Yes Yes
Scan file
NOTE The scan-coverage assessment process is, for the most part, the same for both
IntelliScan and All scannable files. The only difference being the absence of Step 2 for
IntelliScan, and in the decision criteria in Step 4.
The process illustrated above can be divided into the following steps
● Step 1: Determine if the file can be infected
● Step 2: Determine if the file cannot be infected
● Step 3: File extension assessment
● Step 4: File size and/or COM verification
Both steps 1 and 2 use file header information to determine a file’s true file type.
Step 1: Determine if the file can be infected

If DSVA/DSA is set to scan all files or to use
IntelliScan, the first thing it does is determine if the HIGH-RISK FILE TYPES
file type is categorized as having a very high The VSAPI scan engine contains a list
possibility of containing malicious code. of file types that are often associated
with viruses. Pattern files can also
If the file falls in this category, then it is scanned contain supplemental information
and no other coverage-related verification takes that can be used in conjunction with
the default list.
place. Otherwise, the scan coverage determination
process proceeds to step 2
TRUE FILE TYPE RECOGNITION

The VSAPI scan engine uses a number of approaches to detect the type of the content:
2-byte magic - a built-in table is used to interpret the first two bytes of the content
4-byte magic - an extended built-in table is used to interpret the first four bytes of the
content
1k-buffer - a set of internal functions is used to run against the first 1Kb of the content
4k-buffer – this is used only if the content has been identified as TEXT. This is used to
determine if the content that has any scripting statements and must be classified as
script.
Step 2: Determine if the file cannot be infected

This step is only available when the All files option is selected. At this point, the client uses scan
engine functions to determine if the file belongs to a safe file category – one that Trend Micro
antivirus engineers have determined to be either safe from infection or cannot be malware.
NOTE Like in the previous step the scan engine uses built-in and pattern-based file
type information to identify these types of files.
If a file falls in this category, then the file is not scanned. Otherwise, the process proceeds to step
3
Step 3: File extension assessment

In steps 1 and 2, DSVA / DSA analyzed the file using true-file-type information. In this step, the
scan engine compares the file’s extension with a list of at-risk file extensions. As with the file-
type information, the scan engine uses a combination of built-in extension information, as well as
variable data that is held within the virus pattern.
Step 4: COM file verification

Although both IntelliScan and All scannable files settings both have this step, their decision
criteria are different. Consider the following decision table. The condition shown therein will
result in the scan engine NOT scanning the file.
Condition All files IntelliScan
File is less than 70K
Has a file type that does not

have header information (e.g.,
*.COM, script)
A DSVA / DSA that is set to scan All files will not scan any file smaller then, or equal to, 70KB.
If it is set to use IntelliScan, DSVA will only skip scanning files of this size if they files that do not
have header information such as *.COM files as identified by their file extensions.
Tip True-file-type indentification does not work with .COM files because of the lack of
the necessary header information.
Exclusion
Scan exclusions prevent DSVA / DSA from scanning selected files, file types, and/or folders. In
an effort strike a balance between security and performance, administrators can use this
functionality to manage the impact of Anti-Malware scans on their systems.
This section is divided into the following sections
● Exclusion options
● Implementing exclusions
● Recommended exclusions
EXCLUSION OPTIONS
The first exclusion option was already discussed in the Files to scan sub-section: IntelliScan.
IntelliScan uses true file type information, or the absence of this information, to decide which
files would be scanned, and which ones would not.
The remaining options can be found in the Exclusions tab of scan configuration properties
screens, as shown below.
Exclusion functionality leverages the following three components:
Directory lists
These exclude whole

folders/directories from
scanning
File lists
These exclude specific files

from scanning. Both the file
name and file extension must
match the file being
investigated to merit exclusion
File extension list
This excludes files based on

their file extensions. This
method, however, does not
leverage true-file-type
recognition technology
In addition to the exclusion lists, there are two additional types of exclusions:
● IntelliScan-related exclusions
● Shadow copies
IntelliScan exclusions deal with specific file types and sizes, as explained in Files to scan section.
Shadow copies are older versions of shared files or folders that file servers maintain for a pre-
determined amount of time. They are designed to facilitate recovery of shared objects that may
be inadvertently deleted.
Backup processes take longer to finish when real-time scanning scans these files. There are also
instances when real-time scan detects an infected file in these copies but cannot enforce the scan
action because shadow copies are read-only files. These files are excluded by default.
IMPLEMENTING EXCLUSIONS ON DSVA

Both the EPSec Thin Agent and the DSVA implement scanning exclusions. The following table
shows the division of responsibility.
Exclusion EPSec Thin Agent DSVA

Directory list
z
File list
z
File extension list See below See below
Intelliscan-related exclusions
z
Shadow copies
z
Important: This division of responsibility is the primary factor behind the differences between
exclusion behavior in the DSA and the DSVA. See next section.
Scan configurations allow administrators to specify file extensions to include in, or exclude from,
a scan. The EPSec Thin Agent can only implement one of these options. So if a scan
configuration uses a list of file extensions to scan, this list will be sent to the EPSec component,
and file extension exclusions – if any – will be processed on the DSVA.
HOW THE DSA AND DSVA DEAL WITH FILE PATHS IN EXCLUSIONS
The EPSec module currently requires path information for excluded files. This results in the
following differences in DSVA and DSA exclusions.
Exclusion list entry DSA DSVA-only (Agentless)

Full file path given A specific file in a particular A specific file in a particular
location is excluded. The location is excluded. The same
same file in other places is file in other places is not
not excluded excluded
Only file name given, All instances of a file are The exclusion doesn’t work for
no path excluded. Case is not a any instance of the file
consideration
RECOMMENDED EXCLUSIONS
Scan exclusion functionality must be used judiciously. The greater the number of system areas
are excluded from scanning, the number of entry vectors that malware could exploit also
increases.
Exclusion-related recommendations in Trend Micro best practice documents dwell on the
following common exclusion targets:
Quarantine folders – if another Anti-Malware product is present on the protected machine
(e.g., Trend Micro ScanMail for Exchange protecting an MS Exchange server), then
scanning the quarantine folder of that product would be redundant – since any file
found there has already been flagged as malware.
Volume shadow copies - shadow copies are older versions of shared files or folders that
file servers maintain for a pre-determined amount of time. They are designed to facilitate
recovery of shared objects that may be inadvertently deleted. If these are scanned while
backups are in progress, it may take longer for the process to complete.
Files that are subject to constant change – these include log files, transaction files,
mailboxes in email applications, physical database files, etc. Since scanning entails
locking files during scanning, this process can cause latency in applications that use these
files.
Actions
The settings shown below define what the agent/appliance does when it detects malware. The
first option is called ActiveAction. With this option, the administrator relies on Trend Micro action
recommendations that are stored within the VSAPI pattern. Trend Micro antivirus engineers
define these actions based on their analysis of various malware types.
Alternatively, administrators can specify the action to be taken upon malware, as shown below.
The following options are available:

Pass – do nothing to the file and allow full access
Delete – delete the infected file. DSVA can delete files within ZIP/LHA file up to 6 layers
of compression
Quarantine – moves malware to a quarantine folder within the DSVA. For additional
details about this action, see About Quarantine on page 234 .
Clean – remove virus code from the infected file. DSVA can only clean files within
ZIP/LHA files up to one layer of compression.
Deny access – this is only available in Real-time scan configurations, and stops file open /
execute operations.
About possible malware

Possible malware are files that match signatures within the pattern file, but cannot conclusively
be identified as malware. Administrators that encounter these files are advised to contact Trend
Micro for recommendations.
WHEN A “CLEAN” ACTION FAILS

If a clean action fails, AMSP creates a backup of the file in the quarantine folder and
deletes the file.
Options
This section has three sub-sections
● General options
● Real-time scan options
● Alerts
Alerts are the same as with other security features, and define whether or not a malware event
generates an alert on the DSM. The first two options are discussed here in greater detail
General options
These options are shown below.
Enabling Spyware/Grayware scan sets Deep Security to scan for the file components of spyware
using the Spyware Active Monitoring Pattern.
Important: Spyware components in the Windows Registry, network stack, etc. will not be
cleaned in this version.
The Scan compressed files option specifies how Deep Security analyzes compressed files and
archives. When enabled, the following will occur.
Anti-
EPSec VSAPI
Malware
Obtain copy of
compressed file
Place copy of compressed

file in temp folder
Uncompress file
Return result
Scan file
Instruct EPSec to take
action
Real-time scan options

Only Real-time Scan configurations have these options.
Scan files when defines the I/O events Real-time scan traps. Note that files that are opened for
exclusive write only, and are not read, are not scanned.
The Enable IntelliTrap option enables Trend Micro’s solution for “Packed malware”. This is a type
of malware that use compression algorithms to evade detection.
Deep Security implements this feature in a straightforward manner: If it is enabled, all files will
be scanned using this functionality. This is in contrast with other Trend Micro products that only
implement IntelliTrap in specific system folders.
IntelliTrap uses two patterns:
IntelliTrap pattern – this file, named tm_black.<version>, contain heuristic rules that are
used to detect known malware that use real-time compression techniques.
IntelliTrap exclusion list – this pattern, named tm_white.<version>, contains a list of files
that are excluded from action
VSAPI uses these patterns in conjunction with the main antivirus pattern as shown below:
TmWhite > LPT$VPN > TmBlack
Manual / Scheduled scan options

The CPU usage option is only available on Manual Scan Configurations since they are only
relevant for long-duration scans. This feature adjusts the DSA’s CPU utilization in response to
changes in resource requirements of other applications and services on the client’s host.
NOTE This only applies to DSAs. The DSVA will ignore this setting.
This feature works based on the following pricinples:

● If CPU usage is higher than a particular threshold, smart scan pauses scanning
● If CPU usage is equal to, or falls below, the above mentioned threshold for a specified
interval, scanning resumes.
The relevant controls appear below.
The terms “High”, “Medium”, and “Low” are all in reference to the DSA’s priority with regard
to CPU resources. The higher the setting chosen for this feature, the higher the priority that is
given to the DSA, and consequently the greater the impact on other operations taking place on
that machine while a scan is in progress.
Scanning events Other processes

have higher High Medium Low have higher CPU
priority priority
High
About Quarantine
Among the four scan actions listed above, the Quarantine action is most complication option to
execute, because it involves a multitude of modules beyond the scan engine. For this reason, it
discussed in its own section, which is divided into the following:
● Quarantine operations
● Sizing and limitations
QUARANTINE OPERATIONS
Quarantine functionality was designed to give administrators a chance to verify if the file that
was flagged as malware really was a malicious file. For this to work, administrators must receive
notifications when files are quarantined, and must have a means to access the quarantined files.
This section focuses on the mechanisms that allow Deep Security to satisfy both requirements,
and is divided into the following sections.
● Alerts and events
● Quarantine in DSA
● Quarantine in DSVA
● Working with quarantined files
● Restoration
● Limitations
Alerts and events

Quarantine events are recorded in Anti-Malware events like other actions. The Result column
identifies an event as a quarantine action.
Quarantine in DSA
Quarantine functionality on the DSA is based on the AMSP backup mechanism. Whenever
AMSP performs a scan action that results in a change in a file (i.e., clean, delete, quarantine), it
creates a backup in the following location.
The following AMSP_DebugLog.log entries correspond to the creation of the file above.
2012/01/04 16:28:39.437,[01052:01036],[INFO],[Plugin VSAPI], SM handle was not
initialized,[.\vsapi_implementation.cpp(2327)]
2012/01/04 16:28:39.438,[01052:01036],[INFO],[Core Scan Manager], ScanCallBackFunc(): Virus
found!, file path: \\?\C:\Users\Administrator\Documents\eicar\Test ‐ Copy
(9)\eicar.com,[.\AMSP_VsapiProcessFileCallback.cpp(186)]
Name: Eicar_test_file,[.\AMSP_VsapiProcessFileCallback.cpp(187)]
. . .
2012/01/04 16:28:39.447,[01052:01036],[INFO],[Core Action Manager], Backup file path =
C:\Program Files\Trend Micro\AMSP\quarantine\AMTITEF0.10C,[.\ActionHelper.cpp(178)]
. . .
2012/01/04 16:28:39.448,[01052:01036],[INFO],[Core Action Manager], result.pwszBackup:
C:\Program Files\Trend Micro\AMSP\quarantine\AMTITEF0.10C,[.\ActionHelper.cpp(100)]
Note how the backup is stored in the quarantine folder. That means that whenever the DSA
cleans, deletes, or quarantines a file, the action will create a quarantine event.
Consider the following AMSP_DebugLog samples taken from tests involving the Eicar test file.
The column on the left is from a test where the scan action was “Quarantine”, while on the log
on the right, the scan action was clean. To generate these logs, the log level in AmspConfig.ini
was set to “2”.
Scan action: Quarantine Scan action: Clean
2012/01/04 2012/01/04
16:17:51.759,[01052:00752],[INFO],[Core 16:28:39.440,[01052:01036],[INFO],[Core
Action Manager], Value: Action Manager], Value:
0xc,[.\ActionManagerImp.cpp(174)] 0x3,[.\ActionManagerImp.cpp(174)]
... ...
As appears above, the action ID for Quarantine is 0xc, while a clean action has a value of 0x3.
2012/01/04 2012/01/04
Action Manager], Default Action: Action Manager], Default Action:
2012/01/04 2012/01/04
Action Manager], Default Action: Action Manager], Default Action:
... ...
In addition to the user-defined action, the Action Manager also applies a hidden secondary
action in the event the user defined action fails. For quarantine, the secondary is quarantine
again since this actually an option is not expected to fail. For clean, on the other hand,
secondary action is 0x4 – the action ID for delete.
2012/01/04 2012/01/04
Action Manager], result.nPreviousAction: 0, Action Manager], result.nPreviousAction:
result.nPreviousActionResult: 0x3, result.nPreviousActionResult:
0,[.\ActionHelper.cpp(101)] 0xe0ff0022,[.\ActionHelper.cpp(101)]
2012/01/04 2012/01/04
Action Manager], result.nAction: 0xc, Action Manager], result.nAction: 0x4,
result.nActionResult: result.nActionResult:
0xe0ff0001,[.\ActionHelper.cpp(102)] 0xe0ff0001,[.\ActionHelper.cpp(102)]
2012/01/04 2012/01/04
Action Manager], result.nSuggestedAction: Action Manager], result.nSuggestedAction:
0xc,[.\ActionHelper.cpp(103)] 0x4,[.\ActionHelper.cpp(103)]
... ...
In this part of the log above, the result of the desired action appears as well as the action
actually taken. For quarantine, the action is recorded as a success – the file was deleted. On
the otherhand for the clean action, it shows that the clean (0x3) action failed, and the
secondary action of delete (0x4) actually took place.
In both instances a copy of the malware that had been scanned is created in the quarantine
folder, as appears below.
2012/01/04 2012/01/04
16:17:51.766,[01052:00752],[INFO],[Core 16:28:39.447,[01052:01036],[INFO],[Co
Action Manager], Backup file path = re Action Manager], Backup file path =
C:\Program Files\Trend
C:\Program Files\Trend
Micro\AMSP\quarantine\AMSV4U80.0NG,[.\Act
ionHelper.cpp(178)]
Micro\AMSP\quarantine\AMTITEF0.10C,
[.\ActionHelper.cpp(178)]
Quarantine in DSVA
As introduced in the Anti-malware protection section on page 199, a quarantine action proceeds
as shown below.
Anti- Quarantine
EPSec VSAPI
Malware folder
Obtain copy of file
Perform VSAPI scan
Malware detected. Move file

to quarantine folder
Return result
Instruct EPSec to delete file
Each Virtual Agent has its own quarantine folder. A sample with three quarantined files is shown
below.
The sample above offers the following noteworthy points:

● VA-related files can be found under /var/opt/ds_guests within the DSVA
● This VA protects a virtual machine with the UUID 564dc4c4-fb7b-adb3-333d-c5ca22f12bd3
As with other Trend Micro products, quarantine files are renamed. In the case of Deep Security,
it uses a mixed-case naming convention with qtn as its file extension
As discussed in an earlier section, a normal file cleaning operation in an agentless AM
deployment would work as appears below.
VM DSVA
VSAPI
Read Clean
File Renamed
(Infected) file
Memory
File
(Infected file
overwritten)
If the file cannot be cleaned, then the renamed file would be transferred to the Quarantine folder
on the DSVA and the original infected file would be deleted. If the original scan action chosen
were Quarantine, then the cleaning attempt would be skipped altogether.
Working with quarantined files
The Quarantined file list enumerates the files that have been quarantined
To either download or delete the files, administrators can select one or several entries in the
quarantine list, and click either the download or delete option from the menu below.
Both download and delete options start a short two-step wizard that serves to provide status
information on the operation, as well as to give administrators the option to abort the action.
The follow illustration shows what happens in the background.
Console DSM DSVA
Issue download / delete

request
Validate command
Start wizard
Prepare synchronous
requests for each file-host
combination
B Activate progress A Perform

bar on wizard action on
quarantined
items
A Return result to wizard
B Download file to browser Temp folder (for download only)
Details for each step are shown below.

Step 1 – the administrator selects to either download or delete the files on the quarantine list
Step 2 – as discussed in Manager architecture on page 24, the Manager Core, which is
responsible for DSM functionality, maintains a security layer that validates all user
initiated requests
Step 3 – the wizard starts. The example below is for a download request
Step 4 – the wizard thread processes selected files one at a time, for each host-file
combination
Step 5 – the progress bar appears on the DSM console, and the DSVA acts upon the
quarantined file
Step 6 – quarantine functionality leverages the same file download mechanism used in the
diagnostic package. A zip file containing the quarantined files will be downloaded to the
Temp folder of the browser that requested it. The resulting file looks like the one shown
below.
QuarantinedFiles_20100805143353‐3C48[1].zip
NOTE The naming convention used for the quarantine file is as follows:
QuarantineFiles_<server upload time stamp yyyMMddHHmmss>-<4 characters from
GUID>.
Restoration
Once a product is quarantined, there is currently no way to reverse the operation from within
Deep Security. The variety of valid actions that the owner of the quarantined file could take,
independent of the system (e.g., replace it with a valid clean file), that could then be inadvertently
undone by Deep Security were simply too plentiful to consider.
For this, and other, reasons, Deep Security administrators are simply given tools with which they
can manually restore quarantined folders to their original locations. At the final screen of each
wizard, administrators are given a link to a restoration tool.
Clicking the link downloads a self-extracting zip file called QFAdminUtil_win32.exe. This tool is
stored on the DSM at the following location
Extracting this file yields the three other files shown below.
To decrypt the file, extract the contents of the ZIP file downloaded from the quarantine list. The
result should be similar to the following file.
As mentioned earlier in this chapter, this is a benign copy of the malware.

Run QDecrypt.exe, and then select the extracted file.
After clicking Open, the original name of the file should appear in the file name field. Choose a
safe location for saving the file.
Clicking Save completes the decryption process.
LIMITATIONS
Administrators can configure disk space limitations for quarantine functionality at the Anti-
Malware tab on the System Settings screen.
The DSA and DSVA implement this setting in the following manner:
In-guest protection / DSA – this defines the amount of disk space on the DSA allocated
for quarantined files
Agentless protection / DSVA – this defines the amount of space used within the DSVA.
All VAs share this space.
SETTING LIMITS FOR DSA AND DSVA

Per-VM space settings in version 7.5 were removed in 8.0 to unify the quarantine limit for
both agentless and in-guest implementations.
Individual hosts can be given customized limits. Setting larger values for DSAs may be
required because of the way AMSP stores is scanning backups in the quarantine folder.
If a VM is either deactivated or migrated to another ESX server, its quarantined folders in the
DSVA will be deleted.
The following table shows what happens when this limit is reached
Agentless protection / The Quarantine action will fail, and the I/O event that triggered
DSVA the quarantine action will be blocked.
In-guest protection / DSA The oldest quarantined files will be deleted until 20% of
allocated space is freed up.
12.3.3 How AM configuration settings work together in

DSVA
Now that the individual scan settings have been explained, this section will show how they work
together. To facilitate discussion, this section will dwell on a Real-time Scan event.
As shown earlier in Anti-Malware protection on page 206, responsibility for implementing scan
settings is divided between DSVA and the EPSec component on the protected VM. This
division of responsibility is shown here in greater detail.
The first diagram shows the actions for which EPSec is responsible.
EPSec DSVA
File Open /
Close event
detected
Yes
File covered by
folder or extension
exclusions?
No
Is No Send first block

Add latest file
file in RTS Lock file of file data to
details to cache
cache? DSVA
Yes
Send additional
Is part Yes data about the
Invalidate file
of a “write”
cache entry
operation?
No
No Has a Yes
change occurred Take action
since last
scan?
Skip file Unblock file
As a resource conservation measure, EPSec starts the scanning process by determining if the file
is really worth sending to DSVA for scanning. It references two resources to make this
assessment:
● Exclusion lists
● File cache
EPSec is responsible for implementing all exclusion lists short of IntelliScan. If the I/O event
corresponds to a file in either list, then the file is skipped.
The second reference is the file cache. The file cache contains identifying information about files
that had already been scanned before and were not infected. If a file is found in the cache,
remains unchanged, and was not involved in a write operation, then it is not scanned.
However if the file is involved in a write operation, then it is always scanned. Its cache record is
then updated using data from this event.
Once the need for a scan is ascertained, EPSec sends first of what may be several data transfers
to DSVA. The first request involves the first blocks of data from the file. VSAPI on DSVA uses
this first segment of information to determine things like true file type, etc. Depending on the
results of the first batch of data, VSAPI may request additional segments of the file. If malware is
detected, the whole file may be sent to DSVA for processing.
Important: Once the first 8KB of data is sent to DSVA, the file is locked with a FileOpen
command. It will remain locked until VSAPI tells EPSec to take the appropriate action on the
file.
Once VSAPI determines the appropriate action that must be taken upon the infected file, DSVA
sends an action request to EPSec, which then takes responsibility for implementing the
corrective action.
For information about scan actions (e.g., clean, quarantine, etc.), see Actions on page 231.
The diagram below show the actions for which DSVA is responsible.
DSVA
EPSec
Yes
Evaluate Determine scan type Use Covered by
event based on (Real-time/Manual/ corresponding additional Skip file
1st block of file Scheduled) scan settings exclusions?
No
Request additional
Start VSAPI
information about
scan
the file
No
Read file Malware
data detected?
Yes
Take Take
action action
Unblock file
Like EPSec, DSVA also works to avoid redundant scanning. After receipt of file data, it
determines the type of scan that initiated the scan. As discussed in the previous section, each
scan type (Real-time, Manual, and Scheduled scan) has corresponding scan settings, which
includes scanning scope: All files scan or IntelliScan. If the file does not match the scanning
criteria set by either scope, then the file is skipped. Otherwise, the data is passed to VSAPI.
The specifics of how VSAPI detects malware are beyond the scope of this document. However
it is important to note the following:
● The steps “Request additional information about the file” and “Read file data” can occur
several times depending on the query results
● VSAPI can request EPSec to return different parts of the file for its analysis
12.3.4 Pattern technology selection

In addition to traditional pattern-based detection, Deep Security 7.5 offers Smart scan
functionality, a feature of the Trend Micro Smart Protection Network. With Smart scanning,
DSVAs can leverage malware information in-the-cloud, and is no longer limited to locally
available signatures.
An analogy for Smart scanning functionality can be found in Appendix A: Deep

dive information > Chapter 11: Protecting virtual machines > About Smart scan.
This capability is enabled via the setting shown below.
This section is divided into the following sub-sections:

● Why Smart scanning?
● How does it work?
● About scan servers
Why Smart scanning?

The illustration on the right shows the Scan
default protection format, without Smart File data engine
scanning. (VSAPI)
Without Smart Protection, the DSVA uses

a local pattern file called lpt$vpn.<version Pattern
number> which contains all the malware (lpt$vpn)
signatures that the VSAPI scan engine can
use for detection and cleaning. This is
proven technology, and has been in use since Trend Micro’s inception. However it faces the
following problems:
Malware creation is expected to outstrip traditional malware knowledge deployment.
The current Official Pattern Release (OPR) cycle may not be able to keep up with the
rate at which malware is discovered. In 2008, this rate stood at 799 malware per hour.
As patterns grow in power, they grow in size. An inescapable consequence of a rise in
the number of malware is accelerated growth of anti-malware patterns. As things
currently stand, network administrators now have to be careful about when they
schedule their updates, to avoid network disruption.
To address these mutually aggravating conditions, Trend Micro re-thought how it deployed
malware knowledge to its end-point protection products. Instead of pre-deploying all anti-
malware knowledge to the end points, with the resulting deployment delay and bandwidth issues,
this knowledge can now be deployed on-demand from a centralized database that is updated
more frequently than traditional methods. This new paradigm is called: “Smart scan”.
How does it work?

Smart scanning technology works as shown on the illustration on the right. The scan engine can
source malware signatures from two sources:
● A smaller pattern called icrc$oth.<version>

● An external scan server
The scan engine first uses the pattern Scan
information in the Smart scan agent pattern server
(icrc$oth). This pattern contains signatures
for the most active, in-the-wild, malware as
well as malware for which there are no
CRC-based signatures. This signature is
significantly smaller than the original iCRC
lpt$vpn pattern since it has been optimized handler
to contain only the latest and most relevant
signatures.
Scan
File data engine
Information about CRC-
based patterns, how these (VSAPI)
are involved in the Smart
Scan agent pattern can be
found in Appendix A: Deep Pattern
dive information > Chapter (icrc$oth)
11: Protecting virtual
machines > Smart scan
operation
If the file being analyzed does not match any signatures in the Smart scan agent pattern, then the
scan engine queries the smart scan server for additional information. Before it performs the
query, however, the scan engine first checks a local index of the information on the smart scan
server to determine the likelihood that that the server contains relevant signatures. If it finds that
there are absolutely no possible matches for the file on the scan server, then it flags the file as
safe, and no further analysis of the file takes place. The file is not malware.
Otherwise, it downloads signatures from the scan server to continue with the analysis. The scan
engine then takes the appropriate action if the file is flagged as malware.
PATTERNS NOT AFFECTED BY SMART SCANNING

Note that there are a number of locally resident patterns that are used even if Smart Scan
functionality is enabled. These are:
IntelliTrap pattern
IntelliTrap exception pattern
Spyware Active Monitoring pattern
The pattern size implications of either choice are shown below
Smart scanning No smart scanning

(local protection)
Projected memory Icrc$oth 28,724KB 64,560KB
consumption at DSVA (as
of June 14, 2010) BF.ptn 4,097KB
Total 32,821KB
For the most part, Smart scanning works the same way as conventional scanning. The difference
lies in the presence of the iCRC handler, shown below.
VSAPI scan iCRC Scan

File data
engine handler server
NOTE On the DSVA, the iCRC handler library is stored in /opt/ds_agent/lib.
From a purely Deep Security perspective, this is how the scan works:
8. The DSA/DSVA receives data about a file that needs to be scanned, which it then passes to
VSAPI for analysis.
9. Instead of referencing a VSAPI pattern (lpt$vpn.xxx), the scan engine requests malware
identification information from the iCRC handler.
10. The iCRC handler works to retrieve the necessary information. When necessary, it references
the external CRC database that is stored on what is called a Scan Server.
11. After retrieving the information, the handler returns this information to the scan engine,
which then acts upon the file as required
The ICRCHandler is the component that is largely responsible for Smart scan functionality. It is
responsible for the following functions:
● Send queries to the Scan Server and receive the corresponding replies
● Verify Scan Server connectivity
● Provide the OfficeScan client with interfaces with which it can control Smart scan settings
● Load/unload Smart scan-related components
About scan servers

Scan server are available in three forms:
Standalone scan server – this a CentOS-based virtual appliance that is available for
download from the Trend Micro Website
Integrated scan server – this is incorporated in OfficeScan version 10 or later
Trend Micro global scan server – this is a scan server, hosted by Trend Micro, which is
accessible via the Internet.
DSVA/DSA must be able to access at least one of the above-mentioned scan servers if it is to
provide Smart scanning functionality.
Scan server selection is done at the Anti-Malware tab on System Settings. The relevant section is
shown below.
DSVA/DSA cycles through the scan servers in the list in the order they are listed. This list must
be filled with at least one syntactically correct entry, otherwise the following error is generated
and feature enablement will fail.
If for whatever reason the DSVA fails to connect to any Smart scan server, the DSM will
generate an alert as shown below.
12.4 > Protection against Web threats

Trend Micro maintains a large Web site classification database which contains safety ratings for
various sites. These sites were collected from a variety of sources -- to include URLs gleaned
from malware analysis.
Sites on the database are classified and assigned credibility scores that reflect their potential for
either becoming infection vectors or involvement in a malware / spyware’s lifecycle (e.g., sources
of malicious instructions/components, etc). Trend Micro products with Web threat protection
functionality use these credibility scores to control access to these sites.
Deep Security is one such product, and its implementation of this functionality is discussed in
this section, which is divided into the following sub-sections:
● WRS basics
● About Web security ratings
● WRS operation
● Location awareness
● About approved URLs
NOTE Trend Micro PC-cillin and variants of the Trend Micro InterScan product family
also have Web threat protection functionality. Although all these products access the
same classification database that Deep Security uses, the act upon the information
differently. Deep Security implementation is more closely related to OfficeScan.
12.4.1 WRS basics

The DSA/DSVA implement the following logic when they detect that their protected hosts are
accessing a Website:
Block site
Yes
Retrieve No
Host Compare
Website Threshold Grant access
accesses score with
score from exceeded? to site
Website threshold
Trend Micro
Web threat protection functionality permits or prevents access to Web sites based on their
numerical security ratings – hereinafter refered to as credibility scores. Deep Security administrators
determine the types of sites that are blocked by configuring the security levels in the global Web
threat protection policy.
DSA/DSVAs obtain credibility scores from Trend Deep Security Agent / Web reputation

Micro rating servers. Appliance server
Request score
NOTE Rating servers do not
actually store the scores
themselves. They merely act as
the front-end for a system of Trend Micro
databases and score calculators URL Filtering Rating
that are described in the next Engine server
section. (TMUFE)
DSA/DSVA, interfaces with ratings servers using a

component called the URL filtering engine Reply with score
(TMUFE). The illustration on the right shows this

relationship. Deep Security uses the URL filtering engine to send score-requests to the rating
server, and then receiving the replies.
Important: The URL filtering engine is not actually involved in the URL blocking function. It
merely provides the information necessary for the blocking decision.
SAMPLE SITES
Trend Micro maintains sample sites for purposes of testing/demonstrating blocking and
score retrieval functionality. These are the WRS equivalent to the EICAR test file. The
following table lists these sites and their corresponding scores:
Credibility URL Credibility URL
score score
91 wr91.winshipway.com 51 Wr51.winshipway.com
81 Wr81.winshipway.com 41 Wr41.winshipway.com
WHAT HAPPENED TO THE “SIOGNIN.LAND.RU” TEST SITES?

In mid-2007, Trend Micro also used “wrs.XX.siognin.land.ru” URLs for the same testing
purposes. Like the winshipway sites, the “XX” in the URL above also indicated the
credibility score assigned to that URL. Although these remain in the rating server
database, Trend Micro no longer owns these sites.
12.4.2 About Web security ratings

As of writing Deep Security only blocks Websites based solely on their credibility scores that
Trend Micro assigns to different sites. The Trend Micro Web threat database actually also
contains site classification information (e.g., hacking sites, pornographic site, etc.), however it
does not leverage this information.
● About ratings
● Score retrieval
● Score evaluation
About ratings
A Web site’s security ratings determine whether or not agents/appliances permit or prevent
access to that site. This section focuses on these ratings, and is divided into the following sub-
sections:
● About credibility scores
● URL rating process
● Dealing with false positives
ABOUT CREDIBILITY SCORES

The score assignment process is in a constant state
of improvement. As new methodologies are Score Description
developed or acquired, they are added to the score 81 Safe sites
assignment flow .
71 Unrated
The table on the right shows the scores that are 51 Suspicious
assigned to specific types of sites as of writing.
These may change over time. 49 Known malicious
sites
Important: Due to the volume of site-related information that is collected, a portion of the
sites in the database are given an interim category called unrated.
Deep Security will block a site if its score is equal, or less, than the threshold value that a specific
security setting prescribes. As discussed in Score evaluation on page ___, currently the lowest
security setting uses a threshold score of 50. Based on the table above, a DSA/DSVA using this
setting will always block known malicious sites since these sites are assigned a score of 49.
URL RATING PROCESS

The following flowchart presents a high-level view of how Web sites rating process.
Does URL No Score Add score to

Accept URL to
Start download to an assignment rating End
be rated
application? process database
Yes
Antivirus team
analyses the
application
As shown above the rating process can be divided into the following steps:
● Step one: Accept URL to be rated
● Step two: Evaluate if the URL downloads an application
● Step three: Score assignment process
● Step four: Add score to rating database
Step one: Accept URL to be rated

Trend Micro obtains URLs from a variety of sources including, but not limited to, the following:
Malware research – URLs associated with malware are rated as a matter of course
Web-threat-rating queries – URLs submitted to the rating server for evaluation are
collected and added to the rating database.
Step two: Evaluate if the URL downloads an application

In this step, TrendLabs determines if the URL downloads an application. If this is so, then the
URL is sent to the antivirus team for analysis. If the application is malware, then the Website is
tagged as a malicious site, is given the requisite score.
Step three: Score assignment process

After a site is analyzed, it is categorized, and a proprietary application assigns a score to the site /
page based on the categories.
Step four: Add score to rating database

The score received in step 3 is added to the rating database for use by URL filtering engines.
Score retrieval
The diagram below provides additional details about the credibility score retrieval process.
Deep Security
DSA or
DSVA
Agents and appliances can avail of two rating sources:

In-memory cache. If a site has an existing rating in the cache, then it uses this existing
rating. On the DSVA, all Virtual Agents share a single cache on the appliance.
Rating server. If the Web site being visited is new, then the DSVA/DSA queries a the
rating server. Deep Security administrators can use the Trend Micro rating server, or a
local rating server, if it is available.
When the rating server receives the rating request from a client, it queries its rating database, and
returns the corresponding value for the Website.
PROTOCOL FOR QUERYING RATING SERVERS

Trend Micro rating servers can accept queries using either DNS or HTTP-based protocols.
Deep Security 8.0, however, only supports HTTP-based queries.
COMMUNICATING VIA PROXY

If the DSVA or DSA are behind a proxy, it needs access rights to send its rating query through
the proxy. To provide the necessary proxy information, Deep Security administrators can use the
screen below.
NOTE Administrators can specify proxies at the global, profile, or even host level.
Score evaluation
The following flowchart illustrates the URL analysis process.
On Yes
Start URL Do not block
approved End
analysis site
list?
No
Yes
On deny list? Block site
No
Existing Yes
Use existing
rating in
rating
cache?
Evaluate Perform
No
score action
Request WRS
score from
rating server
Tip The DSVA and DSA will lose the contents of their cache when they shutdown.
URL analysis begins with the DSA/DSVA comparing the captured URL being analyzed with an
approved list. If the URL matches an entry on the list, then it is excluded from further analysis.
The approved list can exclude either entire domains or specific directories within these domains.
The same is true for the block list
For additional information about approved lists see page Error! Bookmark not defined..
Regardless of the source of the rating, the following steps in the decision-making process are the
same:
● Evaluate rating
● Perform action
EVALUATE RATING
Ratings consist of a credibility score that the DSA / DSVA compares Do not
with a pre-selected threshold value. If a Web site’s rating is equal to or block
lower than the threshold value, then the agent / appliance blocks this 73
site. 72
Note the illustration on the right. Consider a Website that is given a 71
score of “71”. If the security level has a threshold score of 70 and
below, the unrated site will not be blocked. 70 Threshold
value
69
For a list of credibility scores, and the types of sites that are
given these scores, see About credibility scores on page 279. 68
Block
These threshold values are set on the Deep Security Manager. The following management
console screen capture shows the relevant control.
Specific security level settings, shown above, correspond to specific threshold values. These
values are shown on the table below.
Security level Threshold
High 80
Medium 65
Low 50
PERFORM ACTION
Web threat security can only perform two actions: block or allow.
12.4.3 Behavior with a page is blocked

When a Website is blocked, the following screen appears on the browser on the protected host.
The Deep Security Notifier records all

blocked pages on its Web Reputation
Events tab. The screen capture on the
right shows the record that corresponds to
the browser message above.
As with other security functionality, Web
Reputation events are stored on the Deep
Security Manager. Administrators can view
pages blocked on all DSAs and DSVAs on the Web Reputation Events screen.
12.4.4 Dealing with false positives

In this version, only Deep Security administrators have the ability to address inappropriately
blocked pages. Desktop/endpoint users must notify their administrators if they encounter false
positives.
The following options are available:
● Add site to approved list
● Report site to Trend Micro
Add site to approved list

There are two ways to add a site to the approved list. One way is through the Web Reputation
events screen. This appears below.
Alternatively, the site could be added to the WRS exceptions list.
Report site to Trend Micro

The sitesafety.trendmiro.com site allows administrators to verify the credibility score of sites and
to request re-assessments in the event that the prevailing score is inappropriate. Note, however,
that requests made through this site are not bound to a Service Level Agreement. As of writing,
there are not committed timeframes for when a submission on this site is acted upon. Trend
Micro customers that require site re-assessment are advised to contact Technical Support
directly.
Results of this verification appear below.
The following image shows the feedback screen.
12.4.5 WRS operation

For the most part, WRS-related traffic flow for the DSA and DSVA are similar. Consider the
following diagrams.
WRS in Rating query
DSA Notifier
Browser
WRS
WRS handler TMUFE
rating server
Rating result
WRS events
(db & DSM)
IOCTL IOCTL
User space
Kernel space
DSA driver
WRS in Rating query
DSVA Notifier
WRS
WRS handler TMUFE
rating server
Rating result
WRS events
(db & DSM)
IOCTL IOCTL
DSVA
Hypervisor
Browser dvFilter driver
Both the DSA and DSVA have WRS handlers that use the Trend Micro URL Filtering Engine
(TMUFE) to query the WRS rating server to obtain site scores. The handler is also responsible
for sending events to the DSM and to the Notifier.
The principal difference between the two implementations is in the how they intercept browser
traffic. In the DSA, the DSA driver is used to detect HTTP traffic. The DSVA, on the other
hand, uses the VMSafe API for this. The dvFilter driver, that is installed in Hypervisor for
network traffic re-direction, is also used for WRS.
Browser DSVA WRS server Website
A Connect to Website
Request Website
B score
Intended connection Reply (Dropped) A
Score B
Reply
Instead of blocking the initial connection to the Website, as is done in other WRS
implementations (e.g., Trend Micro OfficeScan), the DSVA / DSA lets the HTTP request
through to the intended Website, but blocks the reply.
DIFFERENCE BETWEEN OFFICESCAN AND DEEP SECURITY

In the OfficeScan design, the initial HTTP query is blocked, and a component called
TMProxy sends keep-alive messages to the application that sent the query.
The Deep Security design puts the onus of maintaining the session upon the Web server
thus leveraging the HTTP protocol’s retry mechanisms.
Once the DSVA receives the a response from the WRS rating server, the DSVA takes the
appropriate action: either it lets the page through to the browser, or it displays the blocked page
warning screen.

1. Which of the following is an advantage of Agent-based protection over Agentless (DSVA
only) protection?
a) Lack of resource contention

b) Absence of update-related network traffic
c) Memory scan
2. If the DSA is unable to perform the configured scan action, what will happen to the
suspected malware?
a) Pass
b) Delete
c) Quarantine
d) Re-scan
3. What is the process of registering a DSA with a DSM called?
a) Registration
b) Activation
c) Melding
d) Binding
Chapter 13: Communication

& management
Chapter Objectives
● Understand the inner workings of the management console
● Understand how DSM-DSA communication works
● Explain the DSA activation process

This chapter focuses on the client-server relationship between the Deep Security Manager
(DSM) and its Deep Security Agents (DSA). It is divided into the following sections:
● Management console
● Password recovery
● Communication
13.2 > Management console

Deep Security Manager is controlled by way of a browser-based management console, shown
below.
The Deep Security Management console is a Web-based console generated by a Tomcat Web
server as shown below.
Tomcat servlet folder
Deep Security
Browser Tomcat
Manager
servlets
There are a number of ways to launch the console:

Run the launcher – double-click dsm_l.exe in the < install path >\Trend Micro\Deep Security
Manager folder on the DSM host.
Start menu – the Deep Security Manager shortcut in the DSM host’s Start menu is linked to
dsm_l.exe, so double-clicking this shortcut runs the launcher
Via browser – this method is used for remote access to the console. The Web server listens
at port 4119, resulting in a console access URL like the one below.
https://dsm_server:4119
The Tomcat servlet folder for Deep Security is shown below.
13.3 > About passwords

This section focuses on how passwords are processed in Deep Security and is divided into the
following sections:
● Obfuscating the password
● Password recovery
13.3.1 Obfuscating the password

The following screen capture of a MS SQL Management Studio screen shows a record from the
Deep Security database table that stores information about DSM administrators. This shows the
default MasterAdmin account and its corresponding password.
Although the contents of the DSM database are not encrypted, user passwords are obfuscated as
shown above.
NOTE This obfuscation behavior discussed here only applies to user passwords.
Deep Security stores passwords as “salted hashes”. It adds a set of random characters,
collectively called “salt”, to the password text and then generates a hash of the combination.
Together they defend against basic dictionary attacks that rely on passwords alone.
PASSWORD AUTHENTICATION BASICS

Hashes are one-way transformations that theoretically result in unique values. It is
mathematically improbable that one could determine the original pre-hashed object based
on its hashed value. Therefore authentication mechanisms that involve hashes simply take
the password entered at the password field, run it through the same hash used in the
stored password, and then compare the output with the object stored. If they match, then
the password is correct.
Prior to Deep Security 7.5 Service Pack 1, passwords were obfuscated using an MD5 hash. These
can be identified by the value “1” in the hash algorithm section. The samples above, for example,
use MD5.
Starting with 7.5 Service Pack 1, in accordance with efforts to satisfy Common Criterial EAL4+
security certification requirements, the algorithm was upgraded to SHA-256. Passwords that are
hashed this way are identified by the number “5” in the hash algorithm section.
13.3.2 Password recovery

The DSM has a command line utility that performs a variety of actions, to include password
recovery. To recover a password, go to the DSM installation directory and enter the following
command:
dsm_c – action unlockout –username USERNAME ‐newpassword NEWPASSWORD
For example
dsm_c –action unlockout –username MasterAdmin –newpassword seCret101
13.4 > Communication

As explained in Chapter 1, Deep Security is a client-server application consisting of the Deep
Security Agent (DSA), which forms the protection tier, where all security actions take place, and
the Deep Security Manager (DSM), which forms the product-level management tier that
provides a single-point interface for configuring all DSAs on the network.
This section focuses on how managers and agents communication with each other, and is
divided into the following sub-sections:
● About heartbeats
● Communication direction
● Activation & security
● Supported commands
13.4.1 About heartbeats

Heartbeats are polling events that define the rate at which information on the DSA is transferred
to the DSM. They are set in the section of the System Setting screen shown below.
This section focuses on the following aspects of heartbeats:

● Purpose of heartbeats
● Anatomy of a heartbeat
● Heartbeat frequency
Purpose of heartbeats
Hearbeats fulfill the following two-part function:
● Deploy the latest system configuration from the DSM to the DSA
● Obtain logs from the DSA to populate DSM statistics counters and events logs
Heartbeats, therefore, play a very important part in creating an overall picture about the state of a
Deep Security network.
DSM modules send instructions opportunistically on top of the heartbeat mechanism. So when
an administrator initiates a Port Scan, or a Recommendation Scan, these instructions will be sent
to the DSA on the next available heartbeat opportunity.
As will be explained in the next section, in certain communication modes, the DSM can pre-
empt the heartbeat, forcing the DSA to send the heartbeat even before it is due, thereby allowing
commands to be sent to the DSA on demand. In such scenarios, commands would not have to
wait for the polling cycle.
Anatomy of a heartbeat
The following log sample shows a DSA trace log, filtered to show only connection (“[Conn]”)
events.
00001831 11:05:53 AM [1464] [Conn] OnRun()

00001849 11:05:53 AM [1464] [Conn] Received command GetAgentStatus
00001852 11:05:53 AM [1464] [Conn] Received command GetAgentEvents
00001870 11:05:53 AM [1464] [Conn] Received command GetLogData
00001919 11:05:54 AM [1464] [Conn] Received command GetDatabases
00001949 11:05:54 AM [1464] [Conn] Received command GetEntitys
00001971 11:05:54 AM [1464] [Conn] Received command GetEvents
00002007 11:05:54 AM [1464] [Conn] OnExit()

00002011 11:05:54 AM [1464] [Conn] ~CConnectionThread
00002760 11:15:45 AM [1464] [Conn] OnRun()
00002778 11:15:45 AM [1464] [Conn] Received command GetAgentStatus
00002781 11:15:45 AM [1464] [Conn] Received command GetAgentEvents

00002848 11:15:46 AM [1464] [Conn] Received command GetDatabases
00002878 11:15:46 AM [1464] [Conn] Received command GetEntitys
00002936 11:15:46 AM [1464] [Conn] OnExit()
These log entries were taken from an activated DSA that did not have any rules assigned to it.
Therefore all DSA-to-DSM communication consisted entirely of heartbeat messages.
These log samples contain the following noteworthy points:
● The “OnRun( )” entries indicate the start of a heartbeat message.
● Between each “OnRun” and “OnExit” pair, the commands listed below were issued. These
represent the default data-set that the DSA regularly sends to the DSM in the absence of
additional instructions from the manager.
GetAgentStatus – this retrieves status information from either the agent or appliance. This
status information includes operating system information, driver status, and connection
details. Information retrieved by this command allows the DSM to set the various
functionality status indicators.
GetAgentEvents – retrieves event information that updates the DSM’s “view” of the
agent’s current state.
GetLogData – this command retrieves firewall and DPI data from the text-based
dsa_mpnp database. This command appears twice in each heartbeat. One each for the
firewall and DPI data
GetDatabases – this command retrieves the GUID of the various SQLLite databases. The
DSM uses the GUID to detect if the DSA created a new set of databases (e.g., if these
were deleted, or if the DSA was reinstalled) from one used in previous logs
GetEntitys – retrieves environment information not included in AgentStatus
GetEvents – this command retrieves Integrity Monitoring, Log Inspection, and Anti-
Malware data from their respective SQLLite databases. In this sample, GetEvents
appears twice, one each for Integrity Monitoring and Log Inspection data.
Heartbeat frequency
By default, DSAs can be set to send out heartbeats out every 10 minutes. These can be delayed
to as much as 24 hours if necessary. If the DSM does not receive heartbeats according to this
schedule for a pre-defined number of times, alerts will be raised.
The actual schedule of the heartbeat that the DSA sends out, however, is actually imprecise.
Consider the following DSA trace logs, collected using DebugView, that show the DSA checking
if a heartbeat is required.
00146654 9:41:52 AM [3468] [Lstn] DoHeartbeatIfNecessary() ‐ starting heartbeat

thread.
. . .

thread.
. . .
thread.
. . .
thread.
. . .
thread.
. . .
thread.
NOTE Certain events, such as “port scan detected”, can pre-empt the heartbeat
process to immediately send information to the DSM, thereby triggering it before it is
due. The DoHeartbeatIfNecessary( ) function checks the agent’s internal heartbeat timer
to see if the heartbeat had already been sent.
The agent used in the test above was set to use the default heartbeat interval of
However, if we tabulate the time stamps of the heartbeat events shown above, the actual
heartbeats are sent a few seconds sooner.
Time stamp Interval

9:41:52 AM -
9:51:01 AM 09:09.0
10:00:17 AM 09:16.0
10:09:18 AM 09:01.0
10:18:36 AM 09:18.0
10:28:28 AM 09:52.0
To prevent the DSAs from inadvertently performing a denial of service attack on its own DSM,
for example if the entire DSA network encounters network connectivity issue, heartbeats are
randomized within a range of 10% of the selected interval. For a heartbeat interval of 10
minutes, for example, the shortest possible heartbeat would be 9 minutes. The first heartbeat
after an agent starts up, however, will be 100% of the prescribed interval.
13.4.2 Communication direction

By default, communication between the DSM and DSA is bi-directional. The DSM can send
instructions to the DSA via TCP/IP at port 4118, and then the agent polls the server at port
4120 to check for configuration changes to as well as to send its status information.
Deep Deep
Security Security
Manager Agent
Port: 4118
Port: 4120
CHANGING THE DSA LISTENING PORT

To modify the DSA listening port, create the DSA configuration file on the DSA host with
the following parameter:
ListenPort=<port>
For Windows-based platforms, this file is called “ds_agent.ini” and must be created in the
Windows system folder. For Solaris/Linux platforms, it is called “ds_agent.conf” and must
be placed in the /etc directory.
Administrator/root privileges will be required to create this file. After creating the file, the
DSA must be restarted.
DSAs, by design, cannot block these ports. Default bypass rules prevent this from happening.
However, if there are other impediments on the network that prevent traffic to these ports, then
administrators need to configure the DSM to work within these restrictions.
Administrators can restrict the direction of communication using the following System setting
control.
If the DSA cannot receive communication from the DSM at port 4118, then the DSM can be set
to avoid sending communication to the DSA altogether by using Agent Initiated communication.
In this situation, the DSA assumes all responsibility for obtaining configuration changes and for
uploading its logs in accordance with the heartbeat schedule. On-demand configuration will be
impossible in this scenario.
When set to use Manager-initiated communication, the DSA will only communicate with the DSM
when specifically instructed to do so. The DSA will not keep track of the heartbeat cycle, and
will only perform the heartbeat operation when notified.
Tip When the DSA is responsible for initiating heartbeats, there is typically a wide
dispersion of heartbeat events since each DSA follows its own 10-minute heartbeat
counter. In a manager-initiated heartbeat, all DSAs are asked to perform a heartbeat
almost at the same time, resulting in a heavy load on the DSM.
13.4.3 Socket timeout

Deep Security communication is affected by the following timeout events. These use the hard
coded default values listed in the table below. See command line configuration options for
details about how to change these values.
Timeout Default value Description

DSM SSL connection 15000 milliseconds Will result in a SSL handshake exception if it
timeout expires, may result in a "Contact by
Unrecognized Client" system event on a
busy system.
Configurable via the

'configuration.defaultSSLHandshakeTimeout'
system setting on DSM.
DSM socket timeout 120000 milliseconds This is the amount of time the DSM will wait
for a response after it sends something to
the agent.

'configuration.defaultSocketChannelTimeout'
system setting on DSM.
Agent socket timeout 120 seconds This is the amount of time the Agent will
wait for a response from the DSM after it
sends something, or is simply waiting for
commands.

'configuration.agentSocketTimeout' system
setting. Note that the agent will ignore any
setting less than 1 minute.
13.4.4 Activation & security

All client-server communication on a Deep Security network is encrypted, and all parties
involved are authenticated with each other. This section focuses on how this security schema is
implemented, and is divided into the following sub-sections:
● Activation basics
● About encryption
WHEN INSTALLED ON AN IMAGE, DO NOT ACTIVATE

When creating a desktop or server image that will be deployed to new machines, be sure
to deactivate the Deep Security Agent on the image source before creating it. Otherwise
the agent will remain in a relationship with its original DSM and will have to be
uninstalled.
Activation basics
The Activation concept was first discussed on page 63. Here we will discuss the internal
mechanics of this action. The following diagram shows what happens during the activation
process.
Deep Deep
Security Security
Manager Agent
Exchange default boot strap

certificates over SSL
Encrypted communication
The process starts when the DSM and DSA exchange bootstrap certificates to identify
themselves to each other. The exchange takes place over SSL and is therefore protected
throughout. All subsequent communication use symmetric-key encryption.
The following command line messages were generated during a manual activation (using
dsa_control.exe). These clearly show the steps taken during activation.
The first two lines show the process illustrated above. The Activation process started with an
SSL handshake, thereby establishing a secure session.
Next, the DSA and DSM negotiated the highest level of encryption that either side would
support. In the example above, it was AES256SHA. Encryption details are discussed in the next
session.
Finally, the DSM leveraged encrypted communication to obtain information about the DSA and
its host, and configure agent settings.
ACTIVATION AND SYSTEM CLOCKS

The DSA and DSM system clocks must be synchronized within 24 hours of each other to
avoid activation failure. If the DSA clock is behind the DSM, then the DSA will not accept
the certificate that the DSM generates will not have yet been valid, and an “Agent activate
failed” event with the following message will be recorded:
“A client error occurred in the Deep Security Manager to Deep Security Agent protocol:
HTTP client error received: certificate is not yet valid”
About encryption
When a connection is established, the DSM sends a list of encryption protocols that it uses to
the DSA. The DSA then responds with the highest level of encryption it supports, and then the
authentication certificates are exchanged.
CLIENT-SERVER IN DSM
The communication architecture in DSM is setup such that the DSA actually acts as a
HTTPS/SSL server, while the DSM functions as a HTTPS/SSL client. The DSM sends its
requests to the DSA, which then performs “services” in response to these requests.
In version 7.5 Service Pack 1, a number of previously used ciphers were removed as part of
efforts to pursue Common Criteria EAL +4 certification. The following table shows the ciphers
that remain, the those that were removed.
Retained Removed
TLS_RSA_WITH_AES_256_CBC_SHA SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_AES_128_CBC_SHA SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
13.4.5 Supported commands

As mentioned in previous sections, the DSM is able to issue commands to its DSAs. Each
command, however, includes additional administrative instructions for efficient management.
The following table lists the different supported commands, as well as the primary and
administrative actions that DSAs perform in response to these commands. These commands are
also divided between user-initiated commands, which administrators request via the management
console, and system-initiated commands, which the DSM performs according to a schedule.
User-initiated commands
Command Description and action
Update This command deploys configuration changes to DSAs and performs
the additional actions:
• Obtain statics for use on DSM console counters
• Determine if the agent requires an update
• Perform outstanding agent-initated requests
Check status This commands collects information required by DSM counters, and
performs the following:
• Determine if the agent requires and update
• Perform outstanding agent-initiated requests
Get logs Prompts the agent to upload its logs
Activate This command initiates the activation process and deploys agent
configuration changes
Upgrade This upgrades DSA agents and collection information used in DSM
counters
System-initiated commands
Command Description and action
Set Security Sets the security configurations on the DSA.
Configuration
Get Interfaces Returns information about network interfaces on the DSA host
Version Collects version information to assess compatibility

Compatibility Check
Status Events & Verifies collects the following information: status, events, counters,
Counters compatibility
Heart Beat This command ensures that the DSA is remains in synch with the DSM,
and performs the following actions:
• Obtain updated configuration file
• Upload statics for use on DSM console counters
• Upload logs

4. Which of the following concepts dictates the rate at which information is transferred from
the DSA to the DSM?
d) Heartbeat
e) Firewall rules
f) Interface changes
g) All of the above
5. Which of the following are valid communication modes?
e) Bi-directional
f) Manager-initiated
g) Agent-initiated
h) All of the above
e) Registration
f) Activation
g) Melding
h) Binding
Chapter 14: About logs,

alerts, and reports
Chapter Objectives
● Understand how events are generated
● Understand how logs are processed and stored
● Understand DSM alerts and notifications
● Understand DSM reports

This chapter focuses on how logs and events are processed, and is divided into the following
sections:
● Log and event basics
● Best practices
14.2 > Log and event basics

The DSM prompts its administrator to perform security actions by way of notifications and
alerts, as shown below.
The DSM generates these alerts based on log information that DSAs upload as part of the
normal heartbeat process, as shown below.
DSM host DSA host
Dsa_mpnp
file
Store
Retrieve (DPI & firewall
events)
Upload
Deep log Deep
Security Security Event
Manager Agent
Alert Store
Retrieve Store Retrieve (Log Inspection & Integrity
Monitoring events)
SQL SQLite3
database database
When events occur on the DSA, they are initially stored in local databases. Firewall and DPI
events are stored in flat text files, while Log Inspection, and Integrity Monitoring use encrypted
SQLLite3 database files. When a heartbeat is due, the DSA reads the logs stored in the files, and
sends them to the DSM.
For events stored in the SQLLite3 database, the DSA deletes most of these logs after they’ve
been sent, save for the 500 most recent entries. These are retained so that the DSA console will
have information to display it its event tabs.
Firewall and DPI events, on the other hand, are not deleted after these are uploaded to the DSM,
and remain in the file.
NOTE DSAs use gzip compression to reduce the size of the logs when they are sent to
the DSM.
Once uploaded, a DSM cycles through the different logs, and then generates alerts and
notifications as required.
14.3 > Log storage

A discussed in the previous section, logs are stored in different locations at different stages in the
log handling process. The following aspects of this process will be discussed here:
● Storing log at the Agent
● Storing logs at the Manager
14.3.1 Storing logs at the Agent

The following databases are used for storing events:
dsa_mpnp – this file contains firewall and DPI data
ds_agent.db – this SQLLite3 database contains miscellaneous system event information
(e.g., abnormal restart detected)
lca.db – this SQLLite3 database contains Log Inspection data
si.db – this SQLLite3 database contains Integrity Monitoring data
With the exception of dsa_mpnp, all DB files are stored in the DSA installation folder.
14.3.2 Storing logs at the Manager

The DSM stores in the following self-descriptive database tables:
packetlogs
integrityevents
loginspectionevents
payloadlogs
Firewall logs are stored in the “packetlogs” table, since the original name for the firewall was the
“packet filter”. DPI logs, on the other hand, are in the “payloadlogs” table for the same reason.
14.4 > Log sending interval

As explained on page 63, the DSA uploads logs to the DSM during a heartbeat event. The
timeliness of the alerts, events, and other notifications, therefore is closely tied to the frequency
of the heartbeats.
NOTE Heartbeat selection becomes less of a concern if DSAs are configured to send
logs to a Security Information and Event Management (SIEM) system such as a Syslog.
The DSA sends event logs in blocks of 1,000 logs during a heartbeat event.
To avoid excessive bandwidth utilization, Trend Micro offers the following rule-of-thumb
heartbeat settings
DSA host Recommended interval Comments

Servers 10 minutes This setting is typical for server deployments,
and reflects the relative importance given to
protecting mission-critical machines
Desktops 60 minutes This setting can be used for machines that end-
user machines
14.5 > Log retention

Deep Security automatically periodically deletes its logs to keep its database within either a
predefined size or date range. There are separate settings for the DSA and the DSM, both of
which are configured from the DSM System Settings screen.
14.5.1 DSA logs

DSA log retention and selection settings can be found in the Firewall & DPI tab on the System
Settings screen shown below.
For the purposes of this document, these settings are grouped as follows:
● Size limitation
● Counter data
● Ignore computer
● Log aggregation
● Data filters
Each group is discussed in their respective sections below.
Size limitation
The following flowchart shows the log file usage logic.
No
Has
Write event
Begin write log reached size End
to log
limit?
Yes
Verify log file

count
No
Has the
Create new
Number of log files
log file
reached limit?
Yes
Delete oldest
log file
The default maximum size for events logs is 4MB. Given that the average size of a single log is
200 bytes, this limit roughly translates to 20,000 log entries. The rate at which the limit is reached
depends on the number of rules in place, as well as network activity on the DSA.
The following parameters fall under this group:
Maximum size of the event log files (on Agent/Appliance)
Number of event log files to retain (on Agent/Appliance)
DSA data
DSAs can send both, or either, of the following information to the DSM:
Event – a 1-to-1 record of events that occur on the DSA host
Counters – an aggregated count of identical events that occur on the DSA host
Event information is used to populate events screens, while counters are used to populate the
various dashboard widgets. The controls in this group allow the administrator to define which of
these two types of information the DSM receives from its DSAs.
For example, an administrator that already collects log information from the DSAs using Syslog
may only want to receive counters. This reduces the traffic and data storage overhead for his
DSM network.
The following parameters fall under this group:
Collect Firewall Events from Agent/Appliance – defines the firewall-related information
is retrieved from the DSA with every heartbeat
Collect DPI Events from Agent/Appliance – defines the DPI-related information that is
retrieved from the DSA with every heartbeat
Ignore computer
This group, which only consists of the Do Not Record Events with Source IP, allows administrators
to refrain from keeping records of events from select “safe” or “trusted” servers.
Log aggregation
The following three settings fine tune Event aggregation functionality. To save disk space, DSAs
will take multiple occurrences of identical events and aggregate them into a single entry and
append a "repeat count", a "first occurrence" timestamp, and a "last occurrence" timestamp. To
aggregate event entries, DSAs need to cache the entries in memory while they are being
aggregated before writing them to disk.
The following parameters below to this group:
Cache Size – defines the number of events to track at any given time. Setting a value of 10
means that 10 events will be tracked (with a repeat count, first occurrence timestamp,
and last occurrence timestamp). When a new type of event occurs, the oldest of the 10
aggregated events will be flushed from the cache and written to disk.
Cache Lifetime - defines how long a record is kept in the cache before flushing to disk. If
this value is 10 minutes and nothing else causes the record to be flushed, any record that
reaches an age of 10 minutes gets flushed to disk.
Cache Staletime - defines how long to keep a record whose repeat-count has not been
incremented. If Cache Lifetime is 10 minutes and Cache Staletime is two minutes, an
event record which has gone two minutes without being incremented will be flushed and
written to disk.
Regardless of the above settings, the cache is flushed whenever Events are sent to the Deep
Security Manager.
Data filters
The following settings provide additional filters for potentially superfluous data:
Generate Firewall Events for packets that are "Out Of Allowed Policy" – the implicit
denial functionality in firewall Allow rules, can generate an excessive number of these
events. This disabling this option allows administrators to ignore these events
Allow DPI Rules to capture data for the first hit of each rule (in period) – this retains
the data from the packet that triggered a log entry. The packet's data can be viewed with
the log entry. Each rule will only capture data once in a five second period to avoid
unnecessarily large log files.
14.5.2 DSM logs

Settings under the Prune group of the System tab of the System Settings screen, allow
administrators to define DSM log-retention behavior. The relevant controls are shown below.
14.6 > About notifications

Deep Security Managers can send notifications, alerts, reports, and the like to its administrators
via email. This section focuses on this functionality, and is divided into the following sub-topics:
● Selecting events for notification
● Notification frequency
● SMTP server selection
● Syslog selection
14.6.1 Selecting events for notification

The following screen allows administrators to specify the events that Deep Security monitors,
and which of these will trigger administrator notifications.
14.6.2 SMTP server selection

Administrators specify the SMTP server that a DSM server uses using the following section of
the System Settings screen.
By default, SMTP servers use port 25. For servers with non-standard ports, enter the mail server
address as shown below:
mail.trendmicro.com:587
The DSM can work with SMTP servers that require authentication. The fields that are relevant
for user credentials are also shown above.
14.6.3 About Alerts

Administrators have two interfaces to the DSM alerts:
● Alert configuration
● Alert view/dismiss
Alert configuration
This screen allows Administrators to select which event results in alerts. This is shown below.
Administrators can access this screen either from the System Settings screen, via the following
button.
Alternatively, administrators can access this from the Alert view/dismiss screen using the control
highlighted below.
Each alert has the following options.
Important: Note that some alerts are not “dismissible”.
Alert view/dismiss
Administrators can view a list of alerts that have been generated thus far by accessing the Alerts
screen. This is shown below
On this screen administrators can view details about the alerts and dismiss them if they are
dismissible.
14.7 > Using syslog

Both the DSA and DSM can send events to a Syslog. This section focuses on this functionality
and is divided into the following sub-sections:
● Syslog basics
● Syslog format
14.7.1 Syslog basics

Both the Deep Security Manager and Deep Security Agent can send messages to a Syslog server.
Agent event
logs (Batched)
Deep Security System event Agent event Deep Security

Manager logs logs (Real-time) Agent
Syslog server
The DSM sends its system events to the Syslog. Administrators configure this functionality from
the following screen.
The Deep Security Agent, on the other hand, sends firewall, DPI, Log Inspection, and Integrity
Monitoring events, as configured in screen sections like the following.
Unlike DSA events that are sent to the DSM, Syslogs are immediately sent to the Syslog server as
they occur. They are not batched in the DSA databases.
14.7.2 Syslog format

Deep Security supports two syslog formats:
Standard format – this format adheres to the 7-bit ASCII format specified in RFC 3164.
Therefore if an event contains characters outside the ASCII set, then these will be
replaced with either underscores or question marks.
Common Event Format – this format uses UTF-8, and is better able to handle events that
use non-ASCII characters. The format is sponsored by Arcsight, and is discussed
extensively on the following Web page: http://www.arcsight.com/solutions/solutions-
cef/.
Administrators choose the format at the System Settings screens shown in the previous section.
NOTE In July 2009, Arcsight issued an updated version of the CEF standard. Deep
Security 7.0 does not support this standard as of writing.
14.8 > About reports

The DSM can package the information derived from the various DSA into PDF, RTF, or
Microsoft Excel reports. These are generated on the following screen.
This section focuses on reports and is divided into the following sub-sections:
● Report templates
● Report filters
● Report access
14.8.1 Report templates

As of writing, there were 16 report templates available. These are listed below.
These templates are stored as jar files in the following folder.
14.8.2 Report filters

When generating reports based on DSA data, administrators can filter the information included
in the reports according to the following parameters:
Tag
Time
Computer
14.8.3 Report access

When generating reports manually, Administrators can choose to encrypt the report to restrict
access. The relevant Report screen section is shown below.
If password access is enabled, Administrators can choose to restrict access only to the user that
generated the report by selecting the Use Current User’s Report Password option. The report
password is defined in the following user properties screen.
For reports meant for wider distribution, administrators can choose to specify a password that is
specific to the report. This option grants access to both DSM and non-DSM users.
If the generated report is a PDF, readers will be prompted for a password when opening the file,
as show below.
PDF-based reports are assigned the following protection
14.9 > Best practices

Here are some tips to help maximize the effectiveness of log collection:
● Disable log collection for hosts that are not of interest. This can be done through Firewall
and DPI > Events on either Computer Properties or Security Profile Properties.
● Consider reducing the logging of firewall activity by disabling the logging options in the
Stateful Configuration (for example, disabling the UDP logging will eliminate the unsolicited
UDP log entries).
● For DPI Filters the best practice is to log only dropped packets.
● For DPI Filters, only select the Always Include Packet Data option (on the Filter's property
sheet) when you are interested in examining the source of attacks. Otherwise leaving packet
data logging on will result in much larger log sizes.
14.10 > Known issues

For a list of known, but highly unlikely issues, see Appendix A: Deep dive
information > Chapter 13. The following issues are discussed:
• Missing rule identification in logs

• Missing MAC address information in logs

1. What database does the DSA use for local Log Inspection and Integrity Monitoring event
storage?
a) Apache Derby
b) MS SQL
c) SQLLite3
d) MySQL
2. Which event monitoring system receives event information in near real-time?
a) Deep Security Manager

b) Syslog
c) Control Manager
d) All of the above
3. Which report format can require a password to read the report?
a) RTF
b) Excel
c) PDF
Chapter 15: Updating a

Deep Security network
Chapter Objectives
● Understand how Deep Security updates are obtained
● Understand what is actually updated

This section focuses on how Deep Security network obtains security updates, and is divided into
the following sections:
● How Deep Security components are updated
● Updating components
● Updating the Deep Security Relay
● Updating DSA / DSVA
● Updating DSM
● iAU folders
● Update sources
● Update triggers
● Updateds in a mutli-node environment (Version 7.5 only)
15.2 > How Deep Security components are updated

In version 8.0, the DSM no longer obtains rule and component updates on behalf of the Deep
Security network. This function is now the responsibility of a modified DSA called a Deep Security
Relay or DSR. This version also transitioned from the previous ActiveUpdate (AU) technology to
the newer Intelligent ActiveUpdate (iAU).
For backward compatibility purposes, the DSM can still obtain and deploy updates to version 7.5
DSVAs -- which would still be required for environments with ESX/ESXi 4.1 environments --
using the legacy AU method. This functionality, however, is hidden in pure version 8.0
environments.
This section is divided into the following sections:
● DSR basics
● The update process
● About iAU clients, relays, and download behavior
● Incremental updates
● iAU basics
15.2.1 DSR basics

Deep Security Relays (DSR) are modified DSAs with Nginx Web servers that allow them to
serve as iAU update sites. They obtain updates from the primary update source, typically the
Trend Micro update site, and then make them available to the Deep Security networks that they
serve.
Alternative
Trend Micro
update server
Update Server
(HTTP or HTTPS)
Deep Security Rule Anti-Malware & AMSP

Update (DSRU) components
Deep Security
Relay
Deep Security
Virtual
Manager Agent
Appliance
By default, all members of a Deep Security network get their updates from Deep Security relays.
The only exceptions are:
● DSMs that manage DSVA version 7.5 and therefore need to function as update servers
using legacy ActiveUpdate technology
● DSVA and DSAs that are allowed to update directly from the primary update server as an
alternative to the DSR
The DSA, DSVA, and DSR all use iAU technology to obtain updates from their update sources.
The DSM, however, leverages the same mechanism used for obtaining diagnostic packages to get
its Deep Security Rule Updates (DSRU) and Deep Security manifest file from the DSR.
NOTE Since the DSM neither uses AU or iAU to obtain its updates it cannot obtain
DSRUs from Trend Micro by itself.
Update events generate the following entries in the System Events screen. These events only
provide the result of an update event, and do not provide granular information about the update.
15.2.2 The update process

Since the Deep Security network updates from DSRs, it is
imperative that DSRs be able to complete their updates
ahead of other members of the network. When an
administrator clicks the Update Components Now button
on the Update screen initiates a network-wide update the
progresses in the following manner:
Trend Micro
DSM DSA / DSVA DSR
update server
Update notification
Begin iAU process
Publish
components
Update notification
Begin iAU process
The following DSM System Event logs record the update process. Note the update sequence.
The DSM initiates DSR updates in the order in which they were added to the network. The
order in which they appear on the DSR list is the same order in which they are updated.
DSA/DSVAs randomize the DSR from which they obtain updates, so they never download
from the same source successively. If they fail to connect to the primary DSR for an update
event, they cycle through the remaining DSRs until they connect successfully.
Consider the following two update attempts using the following environment.
DSR #1 DSR #2 DSR #3

(10.xxx.xxx.150) (10.xxx.xxx.151) (10.xxx.xxx.154)
Deep Security
Agent
In this test, all DSRs were shutdown. So the DSA that generated these logs would never be able
to connect with any of its DSRs.
Attempt one Attempt two

[2011-Dec-06 15:06:54 232|956] [dbg] [2011-Dec-06 15:23:50 1976|1596] [dbg]
iAU::HttpClient::Get iAU::HttpClient::Get
[src\common\src\http_client.cpp(159)] [src\common\src\http_client.cpp(159)]
Getting : Getting :
https://10.xxx.xxx.150:4122/c22t2200v8.0. https://10.xxx.xxx.151:4122/c22t2200v8.0.
0l1p5889r1o1 0l1p5889r1o1
[2011-Dec-06 15:06:54 232|956] [dbg] [2011-Dec-06 15:23:50 1976|1596] [dbg]
Retry times is : 3 Retry times is : 3
... ...
[2011-Dec-06 15:07:54 232|956] [dbg] [2011-Dec-06 15:24:50 1976|1596] [dbg]
Current retry Current retry
times : 3 times : 3
[2011-Dec-06 15:08:14 232|956] [dbg] [2011-Dec-06 15:25:10 1976|1596] [dbg]

Getting : Getting :
0l1p5889r1o1 0l1p5889r1o1
... ...
[2011-Dec-06 15:09:14 232|956] [dbg] [2011-Dec-06 15:26:10 1976|1596] [dbg]
times : 3 times : 3
[2011-Dec-06 15:09:34 232|956] [dbg] [2011-Dec-06 15:26:30 1976|1596] [dbg]

Getting : Getting :
0l1p5889r1o1 0l1p5889r1o1
... ...
[2011-Dec-06 15:10:34 232|956] [dbg] [2011-Dec-06 15:27:30 1976|1596] [dbg]
times : 3 times : 3
Note the following in these sample logs:
● On the first attempt, the DSA attempted to connect to its DSRs in the following order: #1 (.
. . 150), #3 (. . . 154), and then #2 (. . . 151)
● On the second attempt, the DSA followed the following sequence: #2 (. . . 151), #3(. . .
154), and then #1 (. . . 150)
● The DSA tried to download from a DSR three times before moving on to the next DSR.
● After connection with the final DSR failed, the DSA abandons the update attempt.
During the update process, the DSR disables the Nginx Web server to prevent DSAs and DSMs
from downloading updates from it. It disables the Web server by modifying the “location/”
section of the Nginx configuration files (nginx.conf). The relevant sections appear in the table
below.
DSR accepts download requests from DSAs Only the DSR can update from itself
location / { location / {
allow all; allow 127.0.0.1;
} allow ::1;
deny all;
}
During an update, the DSR re-writes the section to appear like the right column. All access is
denied, and only local access is permitted. When a DSA tries to connect to this DSR in this state,
the following entries appear in the Nginx access log.
10.xxx.xxx.15 ‐ ‐ [02/Dec/2011:16:03:05 ‐0800] "GET /c22t2200v8.0.0l1p5889r1o1 HTTP/1.1" 403
564 "‐" "Mozilla/4.0 (compatible;MSIE 5.0; Windows 98)"
As the log sample above shows, the DSA receives an HTTP 403 error.
The corresponding Nginx error log appears below:
2011/12/02 16:03:05 [error] 5552#0: *5 access forbidden by rule, client: 10.xxx.xxx.15,
server: , request: "GET /c22t2200v8.0.0l1p5889r1o1 HTTP/1.1", host: "10.xxx.xxx.151:4122"
The DSR remains in this state for the duration of an update, and returns to normal once the
update is complete.
NOTE If Anti-Malware functionality is set to use Smart scanning, the DSVA/DSA only
downloads the OTH pattern from DSR. It still downloads BF.ptn from the Smart Scan
server.
15.2.3 About iAU clients and relays

Deep Security uses two types of iAU SDKs for update functionality:
iAU client – this is used on DSAs and DSVAs to download the components they need
iAU relay – this is the SDK that makes the DSR possible, and is used to duplicate the
contents of an update server, thus making the full range of relevant patterns, engines,
and program components available to a Deep Security network.
If a DSR provides Anti-Malware functionality, then it will have both client and relay versions of
the iAU SDK.
The iAU client module generates two types of logs:

Iau.log – contains information about the module processes the update
TmuDump.txt – contains information about the connection attempts with the update
server.
An AM-enabled DSR would have all of
components of an AM-enabled DSA, and
consequently the logs mentioned above. It would
also have a third group of components -- the
relay components -- which consist of the
components that it offers to its Deep Security
network. The iAU relay library on the DSR
generates a fifth log: iaurelay.log. The screen
capture on the right shows the iAU (iau.dll) and
iAU relay (iaurelay.dll) libraries on a DSR.
15.2.4 Incremental updates

As with previous Trend Micro update methods, iAU supports incremental updates: the ability to
download partial pattern updates that can be merged with existing patterns, in lieu of
downloading full-sized patterns.
iAU uses two incremental update merge methods: RTPatch and TMPatch. Only the SSAPI
pattern uses the latter. All other patterns use RTPatch, a third-party module from Packet Soft,
Inc.
The following log samples were taken from a DSA update. After downloading the relevant
components, the DSA loaded the appropriate DLL for merging, and writes the following into
TmuDump.txt
Inf 20111128 11:32:23 1216 2072 Load dynamic link library [C:\Program Files\Trend
Micro\AMSP\update\iau_sdk\iaucore\libs\patchw64.dll] succeed
The iAU module then initiates the merge and records the original and updated versions of the
pattern being merged in its iau.log
[2011‐Nov‐28 11:32:23 1216|2072] [app] iAU::MergedPackage::Retrieve
[src\common\src\merged_package.cpp(69)]
start to merge pattern class: 3,type:
536870944,from version 71100 to version 71700
[2011‐Nov‐28 11:32:23 1216|2072] [app] iAU::MergerUtility::MergeFiles
[src\common\src\merger_utility.cpp(199)]
TmIUApply: newDir(C:\Program Files\Trend
Micro\AMSP\update\iau_sdk\iaudata\iaudata5a\temp\merge\a885‐f761‐3683‐9fae)
diffFile(C:\Program Files\Trend Micro\AMSP\update\iau_sdk\iaudata\iaudata5a\temp\f395‐
a5d0‐e295‐a946\w_711.717) baseFile(C:\Program Files\Trend
Micro\AMSP\\.\Module\10000\2.1.1078\9.500.1008\.)
The pattern in this example is not the SSAPI pattern, then iAU uses the RTPatch merge.
Inf 20111128 11:32:23 1216 2072 RTPatchApply32: cmd: ‐NoPathSearch ‐subdirsearch ‐
NOALLOWSPLIT "C:/Program
Files\Trend
Micro\AMSP\update\iau_sdk\iaudata\iaudata5a\temp\merge\a885‐
f761‐3683‐9fae" "C:/Program Files\Trend
Micro\AMSP\update\iau_sdk\iaudata\
iaudata5a\temp\f395‐a5d0‐e295‐a946\w_711.717"
Inf 20111128 11:32:23 1216 2072 Code page before calling RTPatch APIs: ANSI
Each successful merge corresponds to the following entry in iau.log.
[2011‐Nov‐28 11:32:23 1216|2072] [app] iAU::RtpatchMerger::Merge
[src\common\src\rtpatch_merger.cpp(129)]
End Rtpatch Merge, result:
IAU_STATUS_SUCCESS[0(0,0,0)]
15.2.5 iAU basics

Any product that uses Intelligent ActiveUpdate (iAU) to obtains updates needs to perform the
following
• Step 1: Determine the components currently in use
• Step 2: Determine the components available on the update site
• Step 3: Compare the components
• Step 4: Obtain components when necessary
Step 1: Determine the components currently in use

When either a DSA or DSR perform an update, they begin by identifying the components that
are currently on their host. Both use this information in step 3 of this process.
On the Windows-based DSA, there are two iAU instances that retrieve component version
information from separate sources. Information for AMSP components are stored in an
obfuscated file called component_info.cfg, which AMSP maintains in the following location:
. . .\Trend Micro\AMSP
Information for the lone non-AMSP component is stored in an XML file called product.xml in
the following location:
. . .\Deep Security Agent\lib
Deep Security Relays that have been configured to provide full AM functionality, obtain the
relevant components the same way that DSAs do. The principal difference being the name of the
installation folder: Deep Security Relay.
However, in addition to obtaining components that it uses for itself, it also needs to download
components on behalf of its Deep Security network. For this, it creates a copy of the file and
folder structure of its source update server in a process called duplication. Additional details about
this process are available in the Deep Security Relay section, further below in this chapter.
The DSR determines the versions of the components that it serves up to its Deep Security
network by reading a file called a product index. This is the same kind of file that update servers
use to store version information. More details about this file is available in the next section.
Step 2: Determine the components available on the update site

In this step, the DSA/DSR determines the components that are available on the update site. It
does this by downloading XML-formatted product index files that contain version data for the
components on the site, as well as download URLs for these components.
Products obtain these indices by issuing requests like the following:
10.x.x.1 ‐ ‐ [11/Nov/2011:14:19:03 ‐0800] "GET /c22t2202v8.0.0l1p5889r1o1 HTTP/1.1" 200 606
"‐" "Mozilla/4.0 (compatible;MSIE 5.0; Windows 98)"
Observe the following noteworthy points about the log sample above:
● The source of the request (10.x.x.1) has been obscured
● The product downloads the index file using an HTTP GET request
● The index involved in this sample is named c22t2202v8.0.0l5889r1o1. This corresponds to the
index for a version 8.0 Deep Security Relay for the Windows 64-bit platform.
The naming convention for the index file is illustrated below.
OEM = 1
Platform = 5889
Version = 8.0.0
Class = 22
C22t2202v8.0.0l1p5889r1o1
Type = 2202
Language = 1
Region = 1
Class – identifies the product. The value “22” indicates that it is for Deep Security
Type – identifies the sub-component within the product. The value “2202” indicates that
this is for the Deep Security relay. Other valid values for Deep Security software are:
2200 – Deep Security Agent
2201 – Deep Security Virtual Appliance
2203 – Deep Security Manager
Version – indicates the version the version of the product. This is for version 8.0
Language – indicates the language of the product. The value “1” means this is for the
English version
Platform – indicates the operating system of the product. The value “5889” is for Windows
64-bit. Other valid values for Deep Security are:
1 – Windows (32-bit)
257 – Linux (32-bit)
9217 – Linux (64-bit)
Region – indicates geographical limitations for the index. The value “1” means that this is a
global index
OEM – identifies OEM-specific version of the product (e.g., is it for a specific customer,
etc.) to which the index corresponds. The value “1” means that this is the retail version
of the index available to all customers
NOTE Additional information about the these codes are available in Appendix X
MANUALLY VERIFYING THE CONTENT OF UPDATE SERVERS

Administrators can manually download product indices to verify the versions available on
the update site by entering their own index queries in a browser, as appears below:
https://<update server>/iau_server.dll/c22t2202v8.0.0l1p5889r1o1
To obtain the index on a Deep Security Relay, do the following instead:
https://<relay>:4122/iau_server.dll/c22t2202v8.0.0l1p5889r1o1
As mentioned earlier, product indices are XML files. Expanding the file to show its first-level
entities shows the product types for which updates are available, and their corresponding
versions.
<response version="2.0.0">
<update id="c22t2202v8.0.0l1p5889r1o1">
<products>
<product id="c22t2202v8.0.0l1p5889r1o1">
<entity class="22" type="2212" language="‐1" platform="‐1" region="‐1" oem="‐1"
version="8.0.585">...</entity>
version="11.032">...</entity>
<entity class="2" type="574619648" language="‐1" platform="5889" region="‐1" oem="‐1"
</product>
</products>
</update>
</response>
Step 3: Compare the components

At this point, the product already has information about the components that it currently has,
and the components that are available on the update server. So in this step, the product
compares these two information sets to determine which components, if any, need updating.
The product, using the iAU module, arranges the aforementioned data into what it calls trees,
namely the Product local tree and the Product remote tree.
Product Local Product Remote

Tree Tree
Update Tree
The iAU module populates the local tree with information about the components that
DSA/DSR possesses, and records this action in the iAU log. A sample appears below.
[2011‐Nov‐11 14:33:53 3840|3972] [app] iAU::Context::Update [src\core\src\context.cpp(271)]
Product local tree:

‐‐‐+ "Product_Family[c22t2202v8.0.0l1p5889r1o1]"
‐‐‐+ "Product_Group[c22t2202v8.0.0l1p5889r1o1]"
‐‐‐+ "Product[c22t2202v8.0.0l1p5889r1o1]"
‐‐‐‐ "Component[c22t2212v8.0.585l‐1p‐1r‐1o‐1]<‐‐[]"
‐‐‐‐ "Component[c2t574619648v3.5.1047l‐1p5889r‐1o‐1]<‐‐[]"
It then stores the information it obtains from the update server in the remote tree. The following
iAU log entry records this.
[2011‐Nov‐11 14:33:54 3840|3972] [app] iAU::Context::GetRemoteUpdateTree
[src\core\src\context.cpp(153)]
Product remote tree:

‐‐‐+ "Product[c22t2202v8.0.0l1p5889r1o1]"
‐‐‐‐ "Component[]<‐‐[c22t2212v8.0.585l‐1p‐1r‐1o‐1]"
‐‐‐‐ "Component[]<‐‐[c2t574619648v3.5.1047l‐1p5889r‐1o‐1]"
The actual comparison is recorded in yet another tree called the update tree. The relevant iAU
log entry appears below.
Update tree:

‐‐‐+ "Product[c22t2202v8.0.0l1p5889r1o1]"
‐‐‐‐ "Component[c22t2212v0.0.0l‐1p‐1r‐1o‐1]<‐‐[c22t2212v8.0.585l‐1p‐1r‐1o‐1]"
‐‐‐+ "Product[c4t0v6.3.0l1p5889r1o1]"
The update tree sample above contains the following noteworthy points:
● The first three “component” lines show two sets of brackets, with values within, separated
by arrows. These represent components that are newer than what the DSA/DSR currently
possesses.
● In the fourth line, the bracket to the right of the arrow is empty. This means that the local
component is newer, or equivalent to, the component in the server. Inspection of the
corresponding lines in the local and remote trees shows that the component version is
actually the same.
Product local tree Product remote tree
---- "Component[]<-- ---- "Component[]<--

[c2t574619648v3.5.1047l-1p5889r-1o-1]" [c2t574619648v3.5.1047l-1p5889r-1o-1]"
Had there been a version difference, the iAU module would have summarized the result of
comparison in the following manner.
There are 3 component(s) need update
If no updates are required, the iAU module creates a product synch tree like the following, and
writes it to the iAU log before the update tree
Product sync tree:

‐‐‐+ "Product[c22t2200v8.0.0l1p5889r1o1]"
‐‐‐+ "Product[c4t0v6.3.0l1p5889r1o1]"
‐‐‐‐ "Component[c4t112v6.3.1043l1p5889r1o1]<‐‐[]"
Product sync trees are also always followed by the following summary.
It is already update‐to‐date from product
index:c22t2200v8.0.0l1p5889r1o1
Step 4: Obtain components when necessary

When the iAU module determines that the update server contains components that are newer
than those that is currently uses, it downloads the required updates.
In addition to component versions, the product index also contains the URL from which
components can be obtained. Step 2 presented a first-level expansion of the XML-based index.
<products>
</product>
</products>
</update>
</response>
If the administrator were to expand the content of type “574619648”, it would reveal the
following additional information.
version="3.5.1047">
<priority>2</priority>
<share>0</share>
<applyto maxver="3.5.1047" minver="0"/>
<full dig="68d1eacc126f3dd4b0a1c4511cd2e89b" size="388355">
<url>

https://iaus.activeupdate.trendmicro.com/activeupdate/preopr/22_2202_8.0.0_1_5889_1_1/ctlr
po/c2t574619648l‐1r‐1p5889o‐1/3.5.1047_51805141‐4b2c‐4afc‐9c26‐e9e59b4f95d4.7z
</url>
</full>
</entity>
The URL parameter provides the product with update source for the required component. The
iAU module uses this URL to download the update.
15.3 > Updating components

The components that the DSR downloads from the
update server are listed in the Update screen on the
DSM. A sample appears on the right.
Components are grouped into the following groups:
Behavioral monitoring – these are
components used for agent self-protection
using the Aegis module
DPI, Integrity Monitoring and Log
Inspection – this refers to the Deep
Security Rule Update (DSRU) file that
contain the rules for these features
Malware protection – these are used to detect
and malware from host systems (e.g. VSAPI
patterns and engines, etc.), as well as to
query scan servers as part of Smart Scan
functionality
Security Platform – these are update
components for the Anti-Malware Solution
Platform
Smart Feedback – this is the engine that reports information back to the Trend Micro
Smart Protection Network
Web Protection – this is the Trend Micro URL Filtering Engine (TMUFE) that is
responsible for obtaining URL ratings
15.4 > Updating DSA / DSVA

The ultimate goal of the Deep Security update mechanism is timely delivery of security
knowledge to its protection tier: the DSA and the DSVA. This knowledge is contained in their
various patterns, engines, rules and libraries that are part of the various protection features. The
following table shows how this information is stored and transferred to the agents and
appliances.
Feature Knowledge / Description

update source
Firewall Deep Security Manager The DSM downloads Deep Security Rule
Deep Packet Inspection Updates (DSRU) on behalf of its
Log Inspection agents/appliance, stores them in its
Integrity Monitoring database, and then applies them as
required.
Anti-Malware (local Deep Security Relay / These are the locally resident scan
components) Update site engines, pattern files, and program
components (e.g. AMSP) that the different
Anti-Malware features require. If Smart
Scan technology is enabled, the Smart
scan agent pattern falls under this
category.
Anti-Malware (cloud Smart scan server DSAs and DSVAs obtain copies of the
components) BF.ptn file, which acts as an index for the
contents of the Smart Scan filter, from
the smart scan server using the ICRC
protocol. This is a completely different
update channel.
Behavioral monitoring Deep Security Relay / The DSA obtains AEGIS components as it
Update site would normal patterns and engines
Web reputation (engine) Deep Security Relay / The agent and appliance use iAU the
Update site Trend Micro URL Filtering Engine
(TMUFE). As will be discussed in later
sections, they download this component
outside the AMSP framework.
Web reputation (ratings) Rating server DSAs and DSVAs obtain rating
information as required from a rating
server. This information is not persistent
locally.
Some of this knowledge is deployed directly to the DSA/DSVA, while others are sent to the
DSM first before applying them to the agent/appliance. Only Anti-Malware and Behavioral
Monitoring components are deployed directly to the protection tier using iAU technology.
This section focuses on components that are sent directly to the DSA / DSVA using iAU
technology, and is divided into the following sections:
● Download behavior
● Update process
● Smart scan modes
15.4.1 Download behavior

All version 8.0 appliances and agents use the iAU client SDK to download their updates.
However, Microsoft Windows-based DSAs use their iAU modules differently from other agents
because it incorporates the Anti Malware Solution Platform (AMSP) for AM functionality.
AMSP is currently only available for the Windows platform.
This section focuses on the more complicated Windows-based agent. However the principal
difference between the different agents is merely in the number of iAU modules that are
involved (two for Windows, only one for others), and OS-specific peculiarities. Most of the
information here will be applicable to all platforms. Where applicable, alternative
implementations for non-Windows agents and appliances will included in the text.
On a Windows-based DSA with Anti-Malware functionality, there are two groups of
components that it can update
AMSP components – these are components that AMSP needs to provide Anti-Malware
protection. This includes various scan engines (with the exception of the Trend Micro
URL Filtering Engine [TMUFE]), pattern files, and AMSP files and libraries that use
these patterns and engines.
Non-AMSP components – in version 8.0, only the Trend Micro URL Filtering Engine
(TMUFE) falls under this category.
TMUFE AND AMSP

The Trend Micro URL Filtering Engine (TMUFE) provides Web threat protection / Web
reputation functionality by obtaining rating scores for Websites that are accessed from its
host. AMSP supports this functionality and is designed around an implementation that
uses TMUFE with its own TDI driver and proxy service that intercept web traffic for
reputation analysis. Since Deep Security already has its own network engine for
intercepting and decoding traffic, it does not use this sub-set of AMSP capability. For this
reason, it uses TMUFE outside the AMSP framework, and consequently must obtain
updates for this technology on its own.
The DSA downloads each of the abovementioned groups of components independently, using
separate copies of the iAU module: one that downloads AMSP components for AMSP, and
another to download TMUFE.
iAU in AMSP iAU in DSA
NOTE Since Windows-based DSAs use two iAU modules, and each module has its own
set of two logs (iau.log and TmuDump.txt) troubleshooting update issues will require
identifying the logs that correspond to the module that encountered the issue.
iAU iAU Update

(. . . Deep Security (. . . AMSP \ update \
source
Agent \ lib) iau_sdk)
Download TMUFE
Download AMSP components
The diagram above shows the two modules are used. The DSA starts the update process by
downloading TMUFE. If this download is successful, it proceeds to download AMSP related
components.
By design, pattern updates will not interfere with Anti-Malware scanning. This is true for all
DSAs and DSVAs. When a pattern, scan engine, and their associated configuration options, are
loaded into memory, they become part of a memory construct called a Virus Scan Context
(VSC). Agents and appliances maintain two VSCs: one for operational use, and another for
updates. The following diagram illustrates how these VSCs are used.
Anti-Malware
service
During normal operation, DSVA only uses one VSC. When an update occurs, the new
component (e.g., pattern, scan engine) is loaded in the dormant VSC, represented by VSC #2
above. If the update occurs while the DSVA is scanning a file, it will complete the scan on that
file with the old components, and will then switch to the new pattern for the next file. After
switching to the new file, the old component is removed from memory.
15.5 > Updating DSM

The DSM does not use the iAU module to obtain its updates from the DSR. Instead, it uses the
same mechanism used for downloading diagnostic packages.
DSM DSR
Request update package (DSRU,

manifest)
Prepare update
(Diagnostic package
mechanism)
Download package
15.6 > Updating the Deep Security Relay

This section explains how DSRs are updated and is divided into the following sub-sections:
● What DSRs offer to their networks
● DSR update process
● Updating DSRs manually
● Identifying DSRs with the latest updates
15.6.1 What DSRs offer to their networks

The Deep Security Relay obtains updates on behalf of three consumers:
● Deep Security Agents / Appliances
● Deep Security Managers

● Itself
In addition to the components that a normal DSA would download for itself if Anti-Malware
were enabled, the DSR also downloads files that allow it to function as an update server.
The Nginx web server on the DSR publishes
the contents of the following folder:
. . . \relay\iau
The contents on a Windows-based DSR

appear on the right. Note the following
noteworthy points shown in the diagram:
● Product indices for the following are
clearly visible:
○ Deep Security Agent (2200)
○ Deep Security Virtual Appliance
(2201)
○ Deep Security Relay (2202)
● A “xtag” is present, indicating that this
DSR has already completed its first update
● The “packages” folder, where all available components on this DSR are stored, is under iau
folder. A sampling of the contents of this folder appears below.
In addition to preparing the iau folder for use in DSA/DSVA, DSM, and even DSR updates, the
DSR also maintains a DSR manifest file in the following location:
The DSR manifest file, which is stored in the same location as iAU libraries, contains
information about the products on behalf of which it obtains updates. It defines the components
that it downloads. This file’s content, as of writing, appears below:
c22t2200v8.0.0l1p1r1o1
c22t2200v8.0.0l1p5889r1o1
c22t2201v8.0.0l1p9217r1o1
c22t2202v8.0.0l1p1r1o1
c22t2202v8.0.0l1p5889r1o1
c22t2202v8.0.0l1p9217r1o1
DSM COMPONENTS
The DSM (id#2203) does not have its own product index because it does not use iAU to
obtain its rule updates from the DSR. It also does not appear in the DSR manifest because
DSM-related information is already available in the DSR product index.
The DSR periodically checks to see if it has the latest manifest so that it is able to service all the
elements of the Deep Security network that needs it.
15.6.2 Download behavior

Like the DSA, the DSR uses two iAU modules to obtain updates. There are, however, significant
differences in what they download and from where.
iAU iAU Update

(. . . Deep Security (. . . AMSP \ update \
source
Agent \ lib) iau_sdk)
Download DSR manifest
Download DSRU
Download TMUFE
Download DSM product manifest
Duplicate all components that the

DSR will offer to the DS network
Download AMSP
components
The DSR starts the update process with downloading the following components when
warranted. The DSR downloads these components based on etag information. If there is a
difference in between the etag for a component on the DSR, and on the update source, then that
component is downloaded.
DSR manifest – this is a summary of the components that the DSR is supposed to offer to
its Deep Security network.
DSRU – this contains all the rule updates that DSMs require. This contains updated DPI
rules, Log Inspection rules, Integrity Monitoring rules, etc.
TMUFE – this is Trend Micro URL filtering engine that the DSR uses to provide WRS
protection for its host
DSM product manifest – this is the file that the DSM uses to update its list of
components. This information is displayed on the DSM update screen
Once this is complete, it duplicates the patterns, engines, and other components that it needs to
make available to the Deep Security network. This includes full and/or incremental patterns.
If the DSR also provides Anti-Malware protection for its host, the iAU module in AMSP
downloads updates for itself from its own Nginx Web server. This updates its own host
protection capabilities.
Debug log samples that show how the DSR obtains updates are available in
Appendix A: Deep dive information > Chapter 14 > DSR update process.
15.6.3 Identifying DSRs with the latest updates

Each relay and component listed in the Updates section has a column called “Is Latest”. The
DSR-related section appears below.
The key point to remember about this list is that “Latest” is not relative to the components that
are available on the update site. It is actually based on the information taken from the most-up-
to-date DSR.
To database tables are used as a basis for comparison:
dbo.components – this contains information about the most recently obtained components
on the Deep Security network, as reported by the different DSR
dbo.hostcomponents – this table records component versions on all DSAs and DSRs on
the network
Whenever the Updates screen is displayed, the DSM compares these two tables and then
generates the appropriate values for the Is Latest column.
NOTE DSRs are always the basis for what is considered the latest component on the
network. If a DSA downloads a component from an update source directly, and actually
contains components that are newer than what is available on the DSRs, it will not affect
the “Is Latest” status of the DSRs.
15.7 > iAU folders

This section dwells on ActiveUpdate folders on the DSM and the DSVA. Both sets of folders
are discussed in their respective sub-sections.
15.7.1 On the DSR

As mentioned earlier, the DSR maintains three groups of components: AMSP components, non-
AMSP components, and Relay components. Each component group has its own “destination”
folder on the DSR.
Component Destination folder
AMSP
Non-AMSP
Relay
15.7.2 On the DSA

Components on the DSA are stored in two groups of folders: AMSP and non-AMSP.
Component Destination folder
AMSP
Non-AMSP
It should be noted that patterns and engines are renamed with the “cfg” file extension. This was
done to avoid issues related to Windows System Restore functionality. This Microsoft Windows
OS feature can roll back system files, registry keys, installed programs, etc. to a pre-existing state.
Binary files are restored (e.g., *.dll, *cfg, etc.), but other files are not (e.g., *.ptn, *.da6, etc.).
This can create issues in AMSP if its program components are rolled back to older versions that
can’t work with the versions of the pattern or engines that are left alone by system restoration.
Therefore to avoid this situation, all patterns, engines, etc. were given “cfg” extensions.
15.7.3 On the DSVA

The DSVA does not use AMSP, so the components it obtains using iAU are all pattern and
engine related. These are stored in the following directory.
15.8 > Update sources

In this version, Deep Security can only obtain updates from the following:
● An update server via HTTP or HTTPS
● A resource bundle placed on the DSR
Important: Unlike the ActiveUpdate module in version 7.5, this version cannot obtain updates
from a UNC path.
Each option is discussed in their respective sections
15.8.1 Update from an HTTP/HTTPS server

DSRs can obtain updates using either HTTP or HTTPS. However since DSRs use the iAU
module, instead of the previous ActiveUpdate (AU) module, it is only able to download updates
from Web servers. There is currently no option to obtain updates from a file path.
The DSA and DSVA obtain updates from the DSR. However they retain the option to
download directly from the DSR’s source if a DSR is unavailable. This option is particularly
useful for DSAs that are installed on laptops that are often brought outside the network and are
not constantly in communication with the DSR.
NOTE If the DSA/DSVA’s DSR is configured to download directly from Trend Micro,
then the DSA/DSVA will also download from Trend Micro.
This feature is enabled from the following System Settings screen.
The following TmuDump.txt log shows how this transition to the DSR’s update source takes
place.
Inf 20111201 09:44:59 4524 1095911760 Connecting ... 10.xxx.xxx.x50:4122
Inf 20111201 09:44:59 4524 1095911760 Use nonblocking connect with timeout(20 s).
Err 20111201 09:45:02 4524 1095911760 Connect returns, errno(113), errstr(No route to host)
Err 20111201 09:45:02 4524 1095911760 Can't connect to server
Err 20111201 09:45:02 4524 1095911760 HttpsConnection: Socket connect fail
Err 20111201 09:45:02 4524 1095911760 TmDownloader: Connection fail when try to open
resource

. . .
resource

. . .
resource

. . .
resource

Inf 20111201 09:45:12 4524 1095911760 Connecting ... 23.xx.xx.83:443
Inf 20111201 09:45:12 4524 1095911760 Connected!
Inf 20111201 09:45:12 4524 1095911760 Connected to iaus.trendmicro.com:443
After failing to connect to the DSR three times, the DSA switched to the DSR’s update source.
15.8.2 Update from a resource bundle

If a DSR is unable to obtain updates directly from an update server, administrators can manually
update them using an update bundle from a DSR that is able to obtain its updates.
To generate the bundle, run the following command, from the command line, on the source
DSR host.
dsa_control ‐b
Running this command results in the following:
The command creates an update bundle, which consists of a ZIP

archive, in the following location:
< DSR installation path >/relay
The screen capture on the right shows the contents of a bundle.

Bundles contain copies of the contents of the . . . relay/iau folder of
the DSR that created them.
To update a DSR with a bundle, copy it to the base folder of the
DSR. These are:
Windows-based <install path>\Deep Security Relay
Linux-based /opt/ds_agent
15.9 > Update triggers

Updates occur in response to the following triggers:
● On demand update
● Scheduled update
Administrators initiate on-demand updates from the console screen that appears below.
Clicking the link above starts the sequence of updating DSRs followed by DSAs.
The second update trigger is by way of a scheduled update task. The details for the default task
are shown below.
Support Track
15.10
0 > Upd
dates in
n a mu
ulti-node envirronmen
nt (Only
y
av
vailable
e when DSVA 7.5 is presennt)
The followwing node syncchronization behavior
b is on
nly relevant if the
t DSMs maanage version 7.5 7
DSVAs. Th his is no longeer necessary inn a purely 8.0 environment since the DSM M does not acctually
retain updaate componen nts other that rule
r updates, which
w are actuually stored in the database that
all nodes allready share.
Debug log sa
amples that show how the DSR obtains updates
u are available
a in
Appendix A: Deep dive infformation > Chapter
C 14 > Legacy Active
eUpdate
mechanism.
In these typpes of multi-D DSM deploym ments, the firstt DSM that do
ownloads an update
u is
responsiblee for initiatingg updates on other
o nodes. Each
E time a DSSM completess the downloaad of
a particularr component, it notifies othher DSMs. It does
d so in the following maanner:
DSM DSM #1 DSM #2

Download update, first
component Proc
cess
upddate
Notification
Download update
e,
second componeent
Proc
cess
upddate
Notification
Server0.logg entries relateed to updates record

r the folllowing.
Aug 13, 2
2010 3:31:05 P
PM com.thirdbr
rigade.manager
r.core.au.Acti
iveUpdateUtili
ities
duplica
ateComponentsF
FromAU
FINE: AU
Components ha
ave changed, w
will update in
nternals and n
notify other m
managers.
. . .
Aug 13, 2
2010 3:31:05 P
PM com.thirdbr
rigade.manager
r.core.au.Acti
iveUpdateUtili
ities
setAUSe
equenceNumber

FINE: Set
tting AU seque
ence number to
o: 15
. . .
Aug 13, 2
2010 3:31:05 P
PM com.thirdbr
rigade.manager
r.core.au.Acti
iveUpdateUtili
ities
notifyA
AndWaitForOthe
erManagersToUp
pdateFromOurAU
U
FINE: Com
mpleted notify
ying 0 other m
manager nodes
about AU upda
ates.

NTIAL — Release
e Pursuant to NDA
N — CONFIDE
ENTIAL 347
Chapter 16: About the

diagnostic package
Chapter Objectives
● Understand the function of the diagnostic package
● Understand the difference in the content between DSM and DSA packages

Administrators can generate diagnostic packages for either the DSM or individual DSAs.
Understandably, the way the packages are generated, and the contents of these packages are
different. Each package will be discussed in the following sub-sections:
● About the packages
● Generating the packages
● Package generation process
16.2 > About the packages

Administrators can generate the following packages:
● DSM diagnostic package
● DSA diagnostic package
16.2.1 DSM diagnostic package

The DSM diagnostic package facilitates analysis of problems on the DSM. The control below
initiates diagnostic package creation on the DSM.
This starts the diagnostic package wizard which lists the information that the package will collect,
as shown below.
The wizard generates a compressed file that contains the following:
The manager folder

The manager folder contains the following files and sub-folders
The contents of the three sub-folders will be discussed in their respective sub-sections. Only the
following files are discussed at this point:
Configuration.properties – contains information about configuration properties including
listen port and keystore information
Debug.xml – this file contains information about the errors that occurred on the various
hosts, the users on the DSM along with information about their privileges, alerts
generated by DSM and DSA events, rules, etc.
Derby.log – contains information about the embedded Derby database. This will be present
even if the embedded database is not actually used
Dsm.properties – this is a copy of the DSM’s dsm.properties file, which contains its logon
credential settings for the DSM database
Error.log – this contains information about startup and shutdown events before java
logging is initialized, or after it is de-initialized. This log is cleared whenever the DSM is
restarted, so its contents will always refer to the current running state.
Filelist.txt – this is a list of files installed in the DSM folder
Install.log – this is the post installation report for the DSM. See Parts of an installation log
on page 319 for details.
Service.log – contains information on the service code before java.logging is initialized. It is
appended to each start and stop of the service
The .install4j sub-folder

This contains the files listed below.
files.log – this is a list of files installed by install4j, the DSM installer

installation.log – this is the DSM installer log
The jre sub-folder

This folder contains another sub-folder, “lib”, which contains the lone file shown below.
Logging.properties sets the debug log level of the DSM Java framework.
16.2.2 DSA diagnostic package

The DSA diagnostic package facilitates analysis of problems at the DSA. Administrators can
create these packages by accessing the problematic agent’s details, as shown below.
The diagnostic package wizard lists the information that the agent package contains.
The compressed file that the wizard generates contains the following:
At the root path of the resulting ZIP file are the following files:
Builder.log – this is a running account of how the diagnostic package was generated.
System.properties – this is the system.properties file on the DSM at the time the package
was generated. This file shows key Java environment settings that were in use at that
time.
Within the agent package are two folders:
● Agent
● Manager
Their contents are discussed in their respective sub-sections.
The manager folder

The manager folder contains the following files:
Configuration.pdf – this is a report based on the Forensic Computer Audit Report

template. It shows the rules assigned to the DSA, the interfaces detected, and other
system information
Host.xml – like configuration.pdf, this file contains system information. But it also contains
more in-depth agent information, such as agent version, heartbeat settings, synch state,
last IP address used, etc.
Events – the package includes copies of events for the past 24 hours or up to 10,000 events
(for each event type), which ever limit is reached first. These events are written to self-
descriptive CSV files as shown below:
– Dpievents.csv
– Firewallevents.csv
– Hostevents.csv
– Integrityevents.csv
– Loginspectionevents.csv
If the 10,000 event limit is reached, an entry like the following is created in builder.log
[16] WARNING: 10‐06‐04 13:10:29.436
com.thirdbrigade.manager.core.diagnostic.AgentDiagnosticPackageBuilder.addFirewallEv
ents() Unable to include all 34412 firewall events in the past 24 hours. Max events:
10000
Systeminformation.xml – this file provides a snapshot of what the agent was doing at the
time the package was created. In additional environment information, this file includes
information such as number and types of jobs the agent is executing, the time taken to
complete these jobs, status of the different threads, etc.
The agent folder

The agent folder contains the following files:
Config.bin – this is a copy of the configuration settings used by the DSA. The data within is
in binary format and cannot be read without assistance
Config.p7 – this is the DSA configuration in P7 format
Ds_agent.config – this is an encrypted file that contain the DSA configuration in XML
format
dsa_blacklist.txt – a list of known bad IPs
Dsa_conn_states.txt – contains driver connection statistics
Dsa_stats.txt – this contains driver statistics information
Dsa_tcp_conn.txt – contains TCP connection information
Dsa_variables.txt – this contains the advanced driver settings information
Runningprocesses.xml – a list of processes running on the DSA host
Platform-specific folders
DSAs on different platforms will include platform-specific information in their diagnostic
packages. The following are discussed here:
Windows folder
Linux/Solaris folder
WINDOWS FOLDER
This contains the following:
msinfo – this contains Windows-generated system information for the DSA host
setupapi.log – this is a copy of the driver installation log
LINUX/SOLARIS FOLDER
This contains the following:
dsa-state-capture-output.txt – this log contains the following:
○ several files from proc
○ list of loaded modules
○ list of PCI devices
○ list of USB devices
○ network configuration (address, routes)

○ Ethernet info (driver type)
○ Sysctl settings
○ Dmesg lines
○ Kernel config
○ DSVA config files (when applicable)
proc-cpuinfo – contains information about the number and type of CPUs on the DSA host
proc-dsa-configs – contains information about the DSA’s active configuration
proc-dsa-stats – contains driver statistics information
proc-dsa-interfaces - contains network device information
proc-dsa-info – indicates the build version of the DSA
proc-dsa-ignore_device - dsva specific, name of device(s) to ignore packets on
proc-dsa-trace_ctl - dsa specific, control over debug trace
proc-meminfo – contains information about memory usage
proc-pagetypeinfo - contains information about page usage counts
proc-slabinfo – contains information about the memory management mechanism
proc-zoneinfo – contains information about virtual memory allocation
16.2.3 DSVA diagnostic package

The DSVA diagnostic package is very similar to the Linux-based DSA package. One important
difference is in the content for dsa-capture-output.txt
The DSVA adds the following information in this log:
● ActiveUpdate log data (TmuDump.txt)
● Anti-Malware logs
Appendix A: “Deep dive”

information
A.1 > Appendix overview

The principal targets for Support Track documentation are the Trend Micro technical support
organization, newly hired software developers and quality assurance engineers. However, there is
also a secondary audience that requires the level of detail offered by the various basics sections in
the document, but do not require familiarity with the various debug logs, or information about
some of the underlying technology that make the product work.
To facilitate use of this document with different training audiences, certain topics -- for purposes
of this document called “Deep Dive” information – have been moved to this appendix. The
sections in the main document where they would have originally been found are marked with the
following text-box:
Look for the Trend Micro logo.

.
To facilitate mapping of this the deep-dive information in this appendix with their parent
discussions, the following sub-section naming convention will be used.
Heading 1 (Section number) > Deep dive topic title
Let’s take installation logs as an example. Instead of discussing Deep Security Manager
installation logs in the main installation section in Chapter 2, the logs will now be discussed in
the following section in this appendix
A. 2. Chapter 3: Installation
. . .
Installing Deep Security Manager (Section 3.3) > Parts of an installation log
A.2 > Chapter 2: Product overview

The following Deep Dive information for Chapter 2: Product overview
● Java script and the management console (Section 2.6)
● Migrating from an embedded database to MS SQL (Section 2.7.1)
● Database connectivity flowcharts (Section 2.7.2)
● Web client (Section 2.5.2) > About the Model-Control-View architecture
A.2.1 Java script and the management console

The DSM logon screen uses Javascripts. Therefore if the browser used to access the console is
set to block scripts, then the following error message appears.
On Windows Explorer, adding the DSM to the list of trusted sites resolves this issue.
A.2.2 Migrating from an embedded database to MS SQL

(Section 2.7.1)
This procedure is broken down into three phases:
• Export tables from embedded database

• Import tables into MS SQL
• Modify dsm.properties
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:
1. Open a command prompt (cmd.exe)
2. Navigate to the DSM folder. By default this is
C:\Program Files\Trend Micro\Deep Security Manager
3. Type the following command
dsm_c –action createinsertstatements –databasetype sqlserver –generateDDL –goparameter GO
4. 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
Import tables into MS SQL

The following procedure is based on OSQL. However SQLCMD will work as well.
1. Open a command prompt (cmd.exe)
2. Type the following command
SQLCMD –U <username> ‐P <password> ‐d <database name> ‐i “<full path to DSMData.sql>”
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
1. Open dsm.properties. This can be found in the following location:
<Install path>\webclient\webapps\ROOT\WEB‐INF\dsm.properties
2. 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
A.2.3 Database connectivity troubleshooting flowcharts

(Section 2.7.2)
This section is a collection of procedures for identifying the cause of database connectivity
issues. The following procedures are discussed here:
● Beginning the analysis
● Missing database
Beginning the analysis

The following procedure determines if the connectivity issue is caused by simple network
connectivity or protocol support problems or a logon credential issue.
B1 B1.B Consult
Error No Was the No
Unable to connect related flowcharts
encountered during database password
to database or contact Trend
installation? changed?
Micro
Yes Yes
A1 B1.A1
Verify network Update password in

connectivity dsm.properties
A2 B1.A2
Check if selected
communication protocol Restart DSM
is supported
(e.g., is the NamedPipes

protocol enabled)
B1.A3
Was the Yes
A3
database password in
Resolved
Retry database dsm.properties encrypted
selection step after the restart?
No
A3.B B1.A3.B
Consult No Obtain correct database

related flowcharts Was the problem password
or contact Trend resolved?
Micro
Yes
The following table presents additional information about selected steps.
Step Notes
Start This process begins with a database connectivity error. This problem can manifest
itself in the following ways:
• During installation, the installation program refuses to progress beyond

this point:
• The DSM server log, server0.log, records database connectivity errors as

follows:
Apr 2, 2010 12:32:25 PM
com.thirdbrigade.manager.core.db.SystemEventPeer saveEvent
SEVERE: Logging event (999) for target (targetId: null
targetName: null) failed due to a database error.
java.sql.SQLException: Network error IOException: Connection
refused: connect
• If database connectivity is lost prior to a logon attempt, the following

error will appear on the screen.
• If database connectivity is lost while logged on to the DSM console, the

console will appear as follows:
A2 An out-of-the-box installation of MS SQL does not enable the named-pipes protocol

by default. Therefore, if this is the preferred protocol for the installation, the
protocol must be enabled for DSM to communicate with this successfully.
B1.A1 Administrators can enter the password in the password field in dsm.properties
shown below. The password will be in plain text at this point in the process.
database.SqlServer.user=sa
database.name=DSM
database.directory=null\\
database.SqlServer.password=Password here
database.SqlServer.instance=DSM
B1.A3 As discussed in Section 2.7.2, the DSM will automatically encrypt clear-text
passwords if it successfully logs on to the database with that password.
B1.A3.B Remember that the DSM can only logon with the “sa” account. Therefore the “sa”
password must be used in dsm.properties.
Missing database
Unlike other Trend Micro products, Deep Security does not create its own database.
Administrators must create it before pointing the DSM to it.
Unable to
connect to database
(Step A3.B)
Note the database

name chosen
2
B2.A
Determine if the
database exists on the Resolved
database application
A1 B1 B2 Yes
3
Consult
related flowcharts Does the Create database and Was the problem
or contact Trend database exist? retry database selection resolved?
Micro Yes No
B2.B No
Step Notes
Start The chart below begins with Step A3.B of the Beginning analysis flowchart.
2 On MS SQL administrators can perform this step by verifying the existence of the
database node. The following example shows that the default database, dsm, exists
on the database.
A.2.4 Web client (Section 2.5.2) > About the Model-Control-

View architecture
As its name implies, the MVC uses three sub-modules: Model, View, and Controller. The “View”
module determines the information that is displayed, and is responsible for capturing user input
made at the browser. The view module sends user input to the “Controller” module which is
responsible for interpreting the input into the required action. Once identified, the required
action is passed on to the “Model” component, which interfaces with the DSM Manager Core,
and provides the View component with the status information it needs to display on the console.
Each screen on the console has its own Model and View components.
There are numerous Internet references to the MVC. However among the more concise
definitions can be found on Java Website at the following URL:
http://java.sun.com/blueprints/patterns/MVC-detailed.html
State query Model State change

(What is the (Action to be
application doing) ℵ Keeps track of what the performed)
application is doing (state)
ℵ Responds to state queries
ℵ Exposes application functionality
and manages behavior
ℵ Notifies view of changes
Change notification
(e.g., visual cues for what its
doing)
View What should be Controller

ℵ Manages the display of displayed
ℵ Interprets user input into actions
information
that the application must perform
ℵ Requests state updates from the
(e.g., change in state or view)
model
ℵ One controller for each
ℵ Sends user gestures to the
functionality
Controller
User input
(e.g., mouse click)
A.3 > Chapter 3: Installation

The following Deep Dive information for Chapter 3: Installation is discussed here:
● Installing Deep Security Manager (Section 3.3) > Parts of an installation log
● Installing Deep Security Manager (Section 3.3) > Properties file for unattended installation
● Agent activation (Section 3.4.2)
A.3.1 Installing Deep Security Manager (Section 3.3) > Parts

of an installation log
Unlike other Trend Micro installation logs, the Deep Security installation log is actually an after-
installation report, rather than a running account of how the installation is proceeding. For this
reason, the installation process is not described in steps and phases as in other products, but
instead as parts of the log.
The installation log (install.log) can be divided into the following parts:
Part 1: Installation objective
Part 2: Database detection
Part 3: License processing
Part 4: Starting database
Part 5: Legacy ActiveUpdate evaluation
Part 6: Report file preparation

Part 7: Plug-in Directory creation
Part 8: Online help preparation
Part 9: Security configuration
Part 10: Manager port exclusion
Part 11: System settings configuration
Part 12: Linux installation entry
Part 13: Vacuum package
Part 14: Importing performance profiles
Part 15: Non-database environment setup
Part 16: SSL configuration
Part 1: Installation objective

This part of the log identifies the product being installed, where the binaries are being stored,
and the installation mode.
PostInstallAction: ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
PostInstallAction: Installing Trend Micro Deep Security Manager
PostInstallAction: Starting : Thu Sep 01 15:15:37 PDT 2011
PostInstallAction: Installation Directory : /opt/dsm
PostInstallAction: Service Name : dsm_s
[10] INFO: 11‐09‐01 15:15:37.853
com.thirdbrigade.manager.core.install4j.actions.PostInstallAction.doInstall() Logging
intercepted into install.log
PostInstallAction: Mode : FRESH_INSTALL
PostInstallAction: Hostname : 10.xxx.xxx.xx4
PostInstallAction: Manager Port : 4119
PostInstallAction: Heartbeat Port : 4120
PostInstallAction: Pre‐Install Log :
The log sample above shows the following noteworthy points:

● The product being installed is the Deep Security Manager
● The installation program did not detect an existing or older instance of Deep Security on the
target machine, resulting in a FRESH_INSTALL installation mode
The following log sample comes from a DSM installation upon a machine with an existing
version of the product. Note the differences.
PostInstallAction: Starting : Wed Sep 07 13:21:45 PDT 2011
PostInstallAction: Installation Directory : C:\Program Files\Trend Micro\Deep Security
Manager
PostInstallAction: Service Name : Trend Micro Deep Security Manager
[10] INFO: 11‐09‐07 13:21:45.052
PostInstallAction: Mode : UPGRADE
PostInstallAction: Hostname : 10.202.214.150
If the DSM is being added as a new node on an existing DSM installation, then this portion of
the log would appear as follows:
PostInstallAction: Starting : Thu Sep 01 15:31:03 PDT 2011
PostInstallAction: Installation Directory : /opt/dsm
PostInstallAction: Service Name : dsm_s
[10] INFO: 11‐09‐01 15:31:03.235
PostInstallAction: Mode : NEW_NODE
PostInstallAction: Hostname : 10.xxx.xxx.xx6
Part 2: Database detection

As discussed in the Database section of Chapter 1, the Deep Security Manager can use an
external database, or its embedded Derby database. This part of the log records the
administrator’s selection in that regard.
The following log samples will be shown here:
● Fresh installation using embedded database
● Fresh installation using an external MS SQL database
● Upgrade
● Adding a node
● Database from a previous version detected
FRESH INSTALLATION USING EMBEDDED DATABASE

Both “fresh install” and “Embedded” at key words for this scenario.
Running Upgrade Detector (Attempt: 1)
No trace found. Using fresh install mode
Connecting to SQL Server...
Connecting to Embedded...
FRESH INSTALLATION USING AN EXTERNAL MS SQL DATABASE

Like the previous scenario, “fresh install” can be found in this log. The principal difference is the
mention of the “SQL server”, and a test query process.
Test Query Success...
Find Button:Next >
UPGRADE
In this scenario, the Upgrade Detector found an existing dsm.properties file on the indicated
folder. In this example, the upgrade is for different builds of DSM version 8.
Did not find a 32bit version of DSM installed while installing 64 bit version.
Found dsm.properties in: C:\Program Files\Trend Micro\Deep Security
Manager\webclient\webapps\ROOT\WEB‐INF\dsm.properties
Connecting to existing database...
Looking for system versions...
Detecting version...
Detected version (8.0.617) is older than this package version (8.0.765)
Parsed managerUniqueNodeID: 1
Found matching manager node:
Hostname: 10.202.214.150
Manager Port: 4119
Heartbeat Port: 4120
This node is marked as not being the same version as the latest installed. The recorded last
version installed of this node is: 8.0.617
No suitable Relay install packages found
Find Button:Next >
ADDING A NODE
This is a scenario that only works with an external database. If the installer detects that the
database already has an existing database, the installer will present the administrator with the
following option:
This corresponds to the following install.log entry.
Database has data
Schema Same
Find Button:Next >
The sample above shows an instance where the installer recognizes that existing database was
created by the same version of the DSM, and can therefore be installed as a second node. In the
event of a difference in schemas, indicating a different version, only the Overwrite option is
available. See next sections.
DATABASE FROM A PREVIOUS VERSION DETECTED

If the installer detects an existing database on the target database server, it verifies the database
schema to verify version compatibility. If it is found to be different, the installer will refrain from
offer the option to add a new node, and will recommend an overwrite action. Only the overwrite
option will be enabled in the Database Options screen shown previously, and the following
additional dialog box is presented.
The following install log sample corresponds to this scenario
Did not find a 32bit version of DSM installed while installing 64 bit version.
Database has data
Unable to add a node, schema different
Overwrite requested...
Connected...
Overwrite confirmed...
Find Button:Next >
NOTE The sample was taken from a 64-bit DSM installation, hence the additional line
below the Upgrade Detector entry.
Part 3: License processing

This part of the log shows the license that the administrator used during the installation . . . if
any. A sample of this section is shown below.
PostInstallAction: Administrator Username : MasterAdmin
PostInstallAction: Default Locale :en_US
PostInstallAction: Activation Codes : AP‐xxxx‐xxxx‐xxxx‐xxxx‐xxxx‐xxxx
NOTE Deep Security switched to the standard Trend Micro activation code system in
version 7.5.
Part 4: Starting database

This part records the database setup process. The following log samples are used here:
● Fresh install with embedded database
● Fresh install with MS SQL
● Upgrade with MS SQL
● Adding a node
FRESH INSTALL WITH EMBEDDED DATABASE

The log sample below contains the following noteworthy points:
● The database instance used contains the work “EmbeddedInstance”
● Since it is a fresh installation, the Administrator Account is created.
PostInstallAction: Starting Database...
PostInstallAction: Database Instance In Use:
com.thirdbrigade.persistence1.db.EmbeddedInstance
PostInstallAction: Loaded Drivers:
PostInstallAction: sun.jdbc.odbc.JdbcOdbcDriver
PostInstallAction: org.apache.derby.jdbc.AutoloadedDriver
PostInstallAction: org.apache.commons.dbcp.PoolingDriver
PostInstallAction: net.sourceforge.jtds.jdbc.Driver
SchemaManagerTask: Running schema manager...
UpdateDatabaseTask: Updating the database...
AdministratorCreatorTask: Installing Administrator Account...
SettingRecorderTask: Recording Settings...
FRESH INSTALL WITH MS SQL

The principal difference between the logs in this scenario and the one above is the use of the
term “SqlServerInstance” in the description for database instance used. Other entries are the
same.
com.thirdbrigade.persistence1.db.SqlServerInstance
. . .
AdministratorCreatorTask: Installing Administrator Account...
SettingRecorderTask: Recording Settings...
UPGRADE WITH MS SQL

The instance description for this scenario is similar to the fresh installation with an MS SQL
server. The difference lies in the absence of an Administrator account installation event, as well
as a notation about counters not needing to be upgraded.
: Counters do not need to be upgraded.
ADDING A NODE
While a new node is added, other nodes are shutdown
PostInstallAction: Shutting down other nodes...
Part 5: Legacy ActiveUpdate evaluation

To allow version 8.0 DSMs to support version 7.5 DSVAs, they retain legacy ActiveUpdate
functionality. This feature, however, is hidden if these older DSVAs are not present. UI elements
related to this feature are not visible on the management console.
During installation, the installer detects if it is run as part of an upgrade, and if the previous
installation managed a version 7.5 appliance. If such a DSVA is detected, then the relevant UI
elements are enabled. Otherwise, the following entry is created in the installation log.
[10] INFO: 11‐09‐01 15:15:49.929
com.thirdbrigade.manager.core.iau.IAuUtilities.evaludateCanSkipAU() no AU agent is
detected. AU is turn off.
Part 6: Report file preparation

This part of the log records the report-related jar files that are installed onto the DSM host. This
part is identical for fresh installation and upgrade scenarios.
TempDirectoryCreatorTask: Creating Temp Directory...
ReportDirectoryCreatorTask: Creating Reports Directory...
ReportDirectoryCreatorTask: Copying report: report‐antimalwarereport‐1.3.2.jar
ReportDirectoryCreatorTask: Copying report: report‐integrityreport‐1.3.1.jar
ReportDirectoryCreatorTask: Copying report: report‐alertreport‐1.3.1.jar
ReportDirectoryCreatorTask: Copying report: report‐integritybaselinereport‐1.4.2.jar
ReportDirectoryCreatorTask: Copying report: report‐attackreport‐1.3.1.jar
ReportDirectoryCreatorTask: Copying report: report‐webreputationreport‐1.0.0.jar
ReportDirectoryCreatorTask: Copying report: report‐loginspectiondetailedreport‐1.4.0.jar
ReportDirectoryCreatorTask: Copying report: report‐loginspectionreport‐1.3.1.jar
ReportDirectoryCreatorTask: Copying report: report‐suspiciousactivityreport‐1.3.1.jar
ReportDirectoryCreatorTask: Copying report: report‐ipsreport‐1.3.1.jar
ReportDirectoryCreatorTask: Copying report: report‐systemeventreport‐1.3.1.jar
ReportDirectoryCreatorTask: Copying report: report‐forensicauditreport‐1.3.2.jar
ReportDirectoryCreatorTask: Copying report: report‐systemreport‐1.3.1.jar
ReportDirectoryCreatorTask: Copying report: report‐summaryreport‐1.3.1.jar
ReportDirectoryCreatorTask: Copying report: report‐integritydetailedchangereport‐1.4.0.jar
ReportDirectoryCreatorTask: Copying report: report‐administratorreport‐1.3.1.jar
ReportDirectoryCreatorTask: Copying report: report‐firewallreport‐1.3.1.jar
ReportDirectoryCreatorTask: Copying report: report‐recommendationreport‐1.3.3.jar
ReportDirectoryCreatorTask: Copying report: report‐hostreport‐1.3.1.jar
Part 7: Plug-in Directory creation

This portion records the creation of the Plugin Directory, which is used to accommodate
applications that build upon, or extend, DSM functionality. This directory is beyond the scope of
this manual.
PluginsDirectoryCreatorTask: Creating Plugins Directory...
Part 8: Online help preparation

This portion pertains to setup process for the DSM online help.
HelpSystemIndexerTask: Indexing Help System...
ReportFontFinderTask: Finding Unicode Font For PDF Generation...
ReportFontFinderTask: preferredReportFont:
ReportFontFinderTask: No suitable fonts located.
Part 9: Security configuration

This part of the log shows the DSM installation program applying the security update that comes
with the installation package. This ensures that the DSM already contains a minimum set of rules
upon installation. The date of the security update is also shown.
Tip Administrators are advised to download security updates for the DSM shortly after
installation.
SecurityHardeningTask: Hardening Security Settings...
ExampleProfilesTask: Importing Example Security Profiles...
CopyActiveUpdateContent: Copying au content '/opt/dsm/installfiles/au/content' ‐>
'/opt/dsm/au/content/'
PostInstallAction: Using security update included in package...
SecurityUpdateApplierTask: Decrypting Security Update...
SecurityUpdateApplierTask: Applying Security Update...
SecurityUpdateApplierTask: Version: 11‐015
SecurityUpdateApplierTask: Available: Tue May 10 11:17:00 PDT 2011
SecurityUpdateApplierTask: Storing update: 11‐015.dsru
ExampleProfilesToSecurityUpdateMappingTask: Mapping Security Update to Example Security
Profiles...
The log above also shows the Anti-Malware components being prepared for DSVA use. As of
this version, DSVA still obtained updates via the legacy ActiveUpdate mechanism.
Part 10: Manager port and scan exclusion

By default, DSAs are given an exclusion rule that prevents them from blocking the DSM
communication port. This assures that manager-agent communication is never impaired. This
part of the installation log shows this rule being created.
ManagerOverrideCreatorTask: Creating Application Type Override for Manager Port...
ManagerPortListEditorTask: Correcting Manager Port List...
To prevent DSAs from generating reconnaissance scan alerts when the DSM performs port
scanning, the installation program adds the DSM IP address to an IP list called Ignore
Reconnaissance as shown below.
IgnoreReconnaissanceCreatorTask: Creating IP List for Ignore Reconnaissance...
This list is used as the default list for the reconnaissance scan exclusion feature.
Part 11: System settings configuration

This part of the log shows various system settings being prepared.
ScheduledTaskCreatorTask: Creating Scheduled Task for Component Update...
ScheduledTaskCreatorTask: Creating Scheduled Task for Software Check...
ExampleAssetImportanceCreatorTask: Creating Sample Asset Importance Values...
AuditorRoleCreatorTask: Creating the Auditor Role...
ExampleProfileAuditAdjusterTask: Correcting Security Profile Audit...

< Part 10 occurs here>

InstallationRecorderTask: Recording Installation...
PostInstallAction: Automation : false
PostInstallAction: Shutting down the database...
PostInstallAction: Automation : false
Note that the next section, Part 10, is recorded in the midst of this part.
For upgrade scenarios, where the Auditor role is already present, this portion will appear as
follows:
AuditorRoleCreatorTask: Auditor Role already exists...
Part 12 Linux installation entry

This part is only present on Unix/Linux installations and records platform specific adaptations.
UnixTask: Setting the ?nix settings...
Part 13: Vacuum package

Version 7.5 introduced the ability to import agent, DSVA, and dvFilter packages into the DSM
during installation. To accomplish this, the DSM installer must be run with the relevant packages
co-located in the same folder. In the example below, the DSM installer and packages were placed
in a directory called /home/administrator/Documents. The relevant log appears below.
ImportSoftwareTask: dsmInstallerDirectoryString=/home/administrator/Documents/
Administrators can verify the import action by selecting View imported software in the screen
shown below.
The software listed above should appear as follows:
The importation process is shown below.
ImportSoftwareTask: Successfully imported software package. Name:Appliance‐ESX‐8.0.0‐
651.x86_64.zip Version: 8.0.0.651 Platform: ESX_5.0
Fingerprint:D4:02:5D:37:7D:02:D1:E5:88:A5:43:71:6C:55:3A:5A:95:86:96:94
. . .
ImportSoftwareTask: Successfully imported software package. Name:FilterDriver‐ESX_5.0‐8.0.0‐
651.x86_64.zip Version: 8.0.0.651 Platform: ESX_5.0
Fingerprint:99:AC:F2:ED:32:F8:18:16:C5:EB:45:E1:1C:FD:8C:71:18:7C:08:06
. . .
ImportSoftwareTask: Successfully imported software package. Name:Relay‐Windows‐8.0.0‐
636.x86_64.msi Version: 8.0.0.636 Platform: Microsoft Windows x86_64
Fingerprint:C0:0B:EF:29:19:8E:DD:68:F1:E2:FA:5B:68:AB:D7:80:7D:FA:78:CC
“IMPORTING SKIPPED” MESSAGES

Because of the way that vacuum package functionality works, “Importing skipped”
messages will appear in the install log, even if the import is actually successful. The
following files will generate this message:
• Contents of the DSVA package (Appliance-ESX-7.5-xxxx.zip) – the installer will read
the contents of the zip file, and since the zip file itself is being imported, it will
recognize that these individual files are already in the process of importation,
hence this message.
ImportSoftwareTask: zipEntr to import:dsva.ovf
ImportSoftwareTask: The zip entry dsva.ovf is either not compatible for
import or the same package has already been imported, Importing skipped.
ImportSoftwareTask: zipEntr to import:dsva‐disk1.vmdk
ImportSoftwareTask: The zip entry dsva‐disk1.vmdk is either not compatible
for import or the same package has already been imported, Importing
skipped.
skipped.
skipped.
• The DSM installation package
ImportSoftwareTask: The software package "Manager‐Linux‐8.0.617.x64.sh" is
not compatible for import, or the same package has already been imported.
Importing skipped.
These messages can be safely ignored.
Part 14: Importing performance profiles

Performance profiles determine the number of concurrent operations that can take place for
specific types of functionality. Administrators can configure this from the following screen:
The settings associated with these profiles are stored in unencrypted text files that must be
imported during installation. The following installation log entries record this action. It also
shows that the default profile is “1”, meaning “Aggressive”.
ImportPerformanceProfiles: Importing Performance Profiles '/opt/dsm/installfiles'
ImportPerformanceProfiles: Setting the perferred performance profile for all nodes to: 1
Part 15: Non-database environment setup

This part deals with changes to the host computer. Here access to the dsm. properties file, which
contains database access information and the creation of relevant shortcuts is recorded.
PropertiesTask: Storing dsm.properties SSL...
PropertiesTask: dsm.properties exists
PropertiesTask: dsm.properties is writable
ShortcutTask: Creating Shortcut...
Part 16: SSL configuration

The final part of the installation log shows the SSL certification, used for DSM-DSA
communication, being prepared.
SSLTask: Configuring SSL...
SSLTask: Creating a new certificate...
SSLTask: dname: CN=10.202.214.154, OU=Deep Security Manager, O=Trend Micro, L=Ottawa,
S=Ontario, C=CA
SSLTask: Generating certificate on Linux...
Executing: /bin/bash /opt/dsm/installfiles/genkey
STDIN:
STDERR:
SSLTask: Certificate generated
ChkconfigTask: Running chkconfig
Executing: /sbin/chkconfig ‐‐del dsm_s
STDIN:
STDERR:
Executing: /sbin/chkconfig ‐‐add dsm_s
STDIN:
STDERR:
JavaSecurityTask: Altering java.security....
JavaLoggingTask: Using the default logging.properties file
PostInstallAction: Complete : Thu Sep 01 15:22:02 PDT 2011
As shown above, the installation program uses the Sun Microsystems Keytool.exe utility to
generate the certificate. The parameters for certification generation are stored in the genkey.bat
batch file, whose contents are also shown above.
Tip Companies that need to generate their own certificates can modify the contents of
genkey.bat to suit their needs, and run it to generate their own custom keys.
A.3.2 Installing Deep Security Manager (Section 3.3) >

Properties file for unattended installation
Unattended installations require a properties file that provides the responses that users would
normally provide in response to installation wizard prompts. These files are plain text files that
contain the following information:
● Upgrade verification settings
● Database screen settings
● License screen settings
● Address and port screen settings
● Credentials screen settings
● Miscellaneous settings
Among these settings, only the License and Credential settings are the minimum requirement for
the installation to proceed. To avoid installing the embedded database, provide appropriate
information for the database screen settings.
UpgradeVerificationScreen Settings
If an existing installation is detected the user has the option to repair/upgrade (depending on
the version) or overwrite. Overwrite implies a completely new manager installation, discarding
all existing data.
Note that this screen/setting is not used unless an existing installation is detected.
Acceptable values are "True" and "False". The default is "False". Sample:
UpgradeVerificationScreen.Overwrite=True
DatabaseScreen Settings
This section defines the database type and optionally the parameters needed to access certain
database types. Note that the interactive install provides an "Advanced" dialog to define the
instance name and domain of a Microsoft SQL server, but because the unattended install does
not support dialogs these arguments are included in the DatabaseScreen settings below.
Database Type - acceptable values are "Embedded", "Microsoft SQL Server", and
"Oracle". The default is "Embedded". The following sample is for an MS SQL server
DatabaseScreen.DatabaseType=Microsoft SQL Server
Host Name – this is not required if the embedded database is used. Acceptable values are
the name or IP address of the database host. Default is the current host name. Sample:
DatabaseScreen.Hostname=10.203.137.90
Database Name – this is not required if the embedded database is used. Acceptable value is
any string. Default is "dsm". Sample:
DatabaseScreen.DatabaseName=dsm
Transport – this is used for MS SQL servers only. Acceptable values are "Named Pipes"
and "TCP". Default is "Named Pipes". Sample:
DatabaseScreen.Transport=TCP
User Name – this is not required for the embedded database. Default value is blank, which
is discouraged
DatabaseScreen.Username=sa
Password – this is not required for the embedded database. Default value is blank, which is
discouraged
DatabaseScreen.Password=Apple1995!
SQLServer Instance – this is optional and is only required on MS SQL servers are have
multiple instances. Default is blank, which implies default instance. Sample:
DatabaseScreen.SQLServer.Instance=
SQLServer Domain – this is optional and is only required for MS SQL servers.Default is
blank
DatabaseScreen.SQLServer.Domain=
LicenseScreen Settings
This section provides information that would normally be entered on the license screen. The
information here is only valid for version 7.5 and later.
Like the installation wizard, the properties file uses different parameters for different licenses.
For a license that activates all features. Note the “-1” after “license”
LicenseScreen.License.‐1=AP‐xxxx‐xxxxx‐xxxxx‐xxxxx‐xxxxx‐xxxxx
Other licenses require different numerical suffixes. These appear below.

LicenseScreen.License.0=AC for Anti-Malware
LicenseScreen.License.1=AC for Firewall/DPI
LicenseScreen.License.2=AC for Integrity Monitoring
LicenseScreen.License.3=AC for Log Inspection
AddressAndPortsScreen Settings
This screen defines the address and ports for the manager. In the interactive installer this screen
also supports the addition of a new manager to an existing database, but this option is not
supported in the unattended install.
Manager Address - acceptable value is either the name or IP address of the manager host.
Default is the current host name.
AddressAndPortsScreen.ManagerAddress=10.203.137.162
Manager Port – requires a valid port number. Default is 4119
AddressAndPortsScreen.ManagerPort=4119
Heartbeat Port – requires a valid port number. Default is 4120
AddressAndPortsScreen.HeartbeatPort=4120
CredentialsScreen Settings
This screen defines the username and password for the master administrator.
Administrator Username - the default value is blank, which is not acceptable. Sample:
CredentialsScreen.Administrator.Username=MasterAdmin
Administrator Password - the default value is blank, which is not acceptable. Sample:
CredentialsScreen.Administrator.Password=Apple1995!
Use Strong Passwords – acceptable values are "True" or "False". The default is "True".
CredentialsScreen.UseStrongPasswords=True
Other Settings
These are optional settings that broaden installation options
Disable the addition of DSM to Add/Remove - the default is false. Sample:
Disable.AddRemove=true
Disable the addition of DSM to the Start Menu - the default is false. Sample:
Disable.ProgramGroup=true
Override the example security profile XML file included in the installer - this only
applies to fresh installs. The default is to use the normal file. Sample:
Override.SecurityProfilesFilename=C:\SecurityProfiles.xml
Override the latest security update XML file included in the installer – this only
applies to fresh installations, and requires the use of the default the bootstrap license for
encryption. The default is to use the normal file. Sample:
Override.LatestSecurityUpdateFilename=C:\latest.3bsu
Override the Example Security Profile mapping file – this affects Deep Packet
Inspection functionality and only applies to fresh installations. The default is to use the
normal file. Sample:
Override.LatestSecurityUpdateMapFilename=C:\latest_3bsu_map.csv
Override the generated certificate DN values – this only applies to fresh installations,
and is best reserved for situations when a specific CN is required for a particular DNS
(e.g., dsm.myco.com). The default values are:
CN=<AddressAndPortsScreen.ManagerAddress>, OU=Deep Security Manager,
O=Third Brigade, L=Ottawa, S=Ontario, C=CA
Samples for each certificate-related parameter:
Override.Certificate.CN=
Override.Certificate.OU=Deep Security Manager
Override.Certificate.O=Trend Micro
Override.Certificate.L=Ottawa
Override.Certificate.S=Ontario
Override.Certificate.C=CA
Override the Default Locale for the system – this only applies to fresh installations. The
default is English. Sample:
Override.Default.Locale=fr_CA
A.3.3 Agent activation (Section 3.4.2)

Agent activation issues can be divided into the following categories:
Unable to activate
Deep Security Agent
Consult procedure for No Is Yes Consult procedure for

manager-initated this agent-initiated agent-initated
activation activation? activation
Consult
related
flowcharts
Therefore the first step in diagnosing an activation problem is to ascertain if it is an agent-

initiated activation, which is done from the command line, or if it is a manager-initiated
activation, which is done from the DSM console using the following control:
Both activation methods have their respective flowcharts below.
Manager-initiated activation
After determining that the activation failure involved a manager-initiated activation, follow the
following process:
A B B1
No
Unable to activate Verify if the DSA is Is a DSA Install DSA and
Resolved
Deep Security Agent installed on the host installed? activate
Yes
B2
B2.B B2.A1
Consult No Yes
Was the DSA Look for the agent’s
related flowcharts
included in the host *.ini, *.crt, and *.db
or contact Trend
image? files
Micro
B2.A2
B2.A2.B No
Are the files
present?
Yes
B2.A2.A1
Remove / delete these

files and retry activation
B2.A2.A2
B2.A2.A2.B No Yes
Was the problem
resolved?
Step Notes
A The initial step is important since the DSM is not actually able to deploy DSAs, unlike
other Trend Micro client-server products
B2 Agent activation establishes a one-to-one relationship between a DSM and a DSA with
a specific host. This creates challenges for Administrators that want to include DSAs in
server or desktop images that they deploy to new machines via GPO.
If an activated agent is included in the image, it will not work once the image is
deployed. The DSA will recognize that it is no longer on its original host, and it will
not function.
To avoid this issue, administrators must do the following when preparing an a DSA in
an image:
• Deactivate the agent, so that it will not look for a specific DSM
• Delete all instances of following files that tie it to a specific host: *.crt, *.ini,
and *.db
Agent-initiated activation
After determining that the activation failure involved an agent-initiated activation, follow the
following process:
Unable to activate Verify DSM settings for

Deep Security Agent DSA self-activation
B B1.B1 B1.B2
Is No Yes
Configure DSM to Was the issue
DSA allowed to self-
permit self-activation resolved?
activate?
Yes No
B1.A1
Verify command line

parameters
B1.A2 B1.A2.B1 B1.A2.B2
Are switches No Yes

Correct switches and/or Was the issue
and DSM data Resolved
information resolved?
correct?
Yes No
B1.A2.A1
Verify connectivity
between the DSM and
DSA
B1.A2.A2
Consult
Yes Can the DSM No Address
related flowcharts
be accessed from connectivity
or contact Trend
the DSA host? issue
Micro
Step Notes
A Agents cannot activate themselves if the DSM is not configured to allow it. The
relevant control for this is shown below.
Note the granularity that is available to administrators.
B1.A1 Agent activation is accomplished from the command line and requires the following
syntax:
Windows: dsa_control /a dsm://<host or IP>:<port>/
Linux: dsa_control –-activate dsm://<host or IP>:<port>/
The value “port” refers to the DSM heartbeat port, which is “4120” by default
A.4 > Chapter 4: Detecting hosts

The following to topics are discussed here:
Hosts in vCenter and Active Directory
A.4.1 Hosts in vCenter and Active Directory

The following scenario involves computers that are at the intersection of the following sets.
If a DSM imports a list of computers from Active Directory, that are actually virtual machines
that the DSM will also import when it establishes a relationship with Center Server, then these
machines will appear on the DSM Computer list twice. This has been an issue since version 6.0.
This section will offer guidelines for how to deal with this situation, and is divided into the
following sections:
● What to expect
● Working with the problem
● Implications
Working with the problem

If DSAs are installed on these virtual machines, administrators can activate either the Host
records under the vCenter tree, or the records under the Active Directory tree – but not both
records. One will always appear as unmanaged.
The presence of a duplicate record will have no adverse effects on DSA operation. However,
from a management standpoint, it will interfere with groupings in the Computers list since
vCenter information will not reflect AD groupings.
The current work-around for this scenario is described as follows:
● Activate only physical machines in the AD tree
● Activate virtual machines in the vCenter tree, that way it benefits from coordinated
protection via DSVA
● Synchronize both vCenter and Active Directory, and simply ignore the redundant records.
Implications
This design limitation introduces a number of issues in different customer environments. The
full range of issues is beyond the scope of this book. However, specific examples of how
customers have dealt with this scenario will be useful for putting this issue into context.
Scenarios will be added to this section as they become available.
MIGRATING PRE-EXISTING VM NETWORKS

A customer manually deployed Deep Security 3.0 agents to a network consisting of over 1,000
virtual machines. This version of Deep Security did not yet offer vCenter and/or ESX support.
When they tried deploying version 6.0, where ESX/vCenter integration was first introduced, the
the addition of vCenter to DSM resulted all virtual machines being added to the computer list
twice. There was also no easy way to migrate the settings of the manually installed DSAs to the
new records created under the vCenter tree.
In this scenario, the customer opted to retain the original DSA structure and only leverage
vCenter functionality for new VMs that were not part of the original deployment.
A.5 > Chapter 6: Protection basics

The following Deep Dive information for Chapter 6 are discussed here:
● Tap mode applications (Section 6.4)
A.5.1 Tap mode applications (Section 6.4)

A DSA in Tap mode does not actually protect its host. Originally, it was designed to demonstrate
Deep Security detection capability. It was meant to show that the DSA would detect events as
advertised.
It also was not meant to serve as a substitute for “learning mode” functionality found in other
security products. Since it does not actually block traffic in this mode, 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.
One application that a customer has found for Tap mode is for monitoring traffic between
network segments that should not communicate with each other. It is a very unique
implementation that cannot be discussed here in detail. However for our purposes, it is enough
to know that the customer simply leveraged the DSA’s traffic detection capability and reporting
capability.
A.6 > Chapter 9: About the firewall

● Comparison of the OfficeScan and Deep Security firewalls
● Known issues (Section 9.4)
A.6.1 Comparison of the OfficeScan and Deep Security

firewalls (Section 9.1)
The table below presents a comparison of firewall features.
Comparison of stateful inspection capabilities
A.6.2 Known issues (Section 9.4)

The following issues have been known to occur:
● Working with third-party firewalls
● Cisco WAAS
Working with third-party firewalls

Running more than one firewall on a single host can lead to unpredictable behavior. Before
enabling the Deep Security Firewall, any firewalls already running on a host should be
disabled/turned off.
Cisco WAAS
The Cisco Wide Area Application Services is a WAN optimization solution. Additional
information about this technology is available here:
http://www.cisco.com/en/US/products/ps5680/Products_Sub_Category_Home.html
This protocol adds additional information that alter TCP sequence numbers. This interferes with
stateful firewall functionality. On Deep Security, this generates “invalid SEQ” or “invalid ACK”
entries in the firewall log.
To avoid this, administrators can enable the following option:
This causes the DSA driver to ignore WAAS-related oddities when performing analysis. TCP
stateful sequence number checks are still performed for non-WAAS enabled connections.
A.7 > Chapter 11: Protecting virtual machines

● Enabling SSH
● Connectivity issues
● Required Windows patches (Section 11.5)
● Virtual host resolution (Section 11.5)
A.7.1 Enabling SSH

SSH functionality on the base DSVA operating system is disabled by default. To access the
command line interface remotely over this protocol, administrators must perform the following:
1. At the Center Server client, access the DSVA console and then enter Alt F2 to open the
non-graphical interface
2. Enter password. By default this is “dsva”. This opens the command line interface
3. At the prompt enter:
Ssh‐server start
The result should appear as follows:
A.7.2 Connectivity issues (Section 11.5.1)

When faced with communication issues with DSVA, administrators have three system areas to
verify:
● Preparation failure cleanup
● Connectivity with the kernel
● The interfaces
● Connectivity with VMSafe

Each is discussed in their respective sub-sections below.
NOTE Verification of the above-mentioned areas must be done via the command line
interface (CLI).
Preparation failure
cleanup
If the DSM is unable to
prepare an ESX server, it
rolls back its changes to
ensure a clean server for the
next attempt. The following
is a screen capture of the
vCenter events window
showing the rollback
process in action.
The preparation fails at the
“Install” event. Once this
failure is detected, all
changes are removed.
Connectivity with the vmKernel

At the CLI, verify kernel connectivity by pinging the kernel address as shown below
sudo ping <IP address to vSwitch>
Tip Using sudo privileges grants the dsva account root privileges for the ping.
The following is an example of a successful verification
dsva@dsva:~$ sudo ping 192.xxx.2.61
PING 192.168.2.61 (192.xxx.2.61): 56 data bytes
84 bytes from 192.168.2.61: icmp_seq=0 ttl=64 time=1.4 ms
84 bytes from 192.168.2.61: icmp_seq=1 ttl=64 time=0.1 ms
The interfaces
The following diagram shows the two interfaces on DSVA
External Internal Kernel

DSM eth0 DSVA eth1
switch switch driver
Interface eth0 connects the DSVA to the management network and permits communication
with the DSM. eth1 connects to the vSwitch and the protected VMs
At the CLI, verify the interfaces with the following command:
ethtool ‐i <interface number>
The following are samples of successful verifications
eth0 eth1
dsva@dsva:~$ ethtool -i eth0 dsva@dsva:~$ ethtool -i eth1
driver: e1000 driver: vmxnet3
version: 7.3.20-k2-NAPI version: 1.0.0.32-NAPI
firmware-version: N/A firmware-version: N/A
bus-info: 0000:02:00.0 bus-info: 0000:03:00.0
For eth1, the key indicator that the interface is working is that the driver is set to vmxnet3.
Connectivity with VMSafe kernel driver

DSVA connects to its kernel driver via TCP at port 2222. Therefore if these kinds of
connections are present, VMSafe connectivity is available.
At the CLI, run netstat as shown below
netstat ‐n –t
The following is an example of the expected result
As shown in the vCenter network diagram below, the kernel is at 169.254.50.1
A.7.3 About Smart scan

● About CRCs
● About CRC parts: An analogy
● Smart scan operation
Support Track T
Trend Micro Deep Security
About CRCs
C (Section 11.6.5
5)
Smart scann technology iss a new implemmentation of malware identtification via Cyclic
C Redunddancy
Check (CR RC) values. Preevious version
ns of the VSAPI scan engin ne already use this
t method, anda a
significant portion of thee current VSA
API virus patteern is already devoted
d to CR
RC-based
signatures. The followingg diagram shoows how much h of a VSAPI pattern’s sizee consists of CRC
C
information n:
15%
CRC
Non‐CRC
85%
The specifiics of how Treend Micro usees CRCs in itss signature dattabases are understandably
secret. How
wever for purp poses of this document,
d wee can explain that
t CRC info ormation can be
b
divided into two parts:
nitial malware identification
Part 1 – Used for in
Part 2 – Used for malware
m confirrmation
To illustratte how these parts
p work, co
onsider the folllowing diagram that represeents a file thatt has
been infectted by a virus.
Virus parrt 1 Virus part

p 2
File
(Jump coode) (Main po
ortion)
Jump cod
de
When a traaditional virus infects a file, it typically appends a part of

o itself to thee front of the file.
f
This servess two purposees:
- To keeep other instannces of the virrus from re-in
nfecting an alreeady infected file, thereby
ensurin
ng efficient prropagation
- To enssure that the virus
v he file runs firrst, whenever the file is opeened
code in th
This front--appended porrtion often co ontains a “jum
mp” command to the main portion
p of the virus,
which is located elsewheere in the file.
For this kinnd of virus, CRC informatio on part 1 wouuld be used to identify the first
fi part of thee
virus that is added to thee front of the file.
© 2012 Trend Miccro Inc. CONFIDEN

NTIAL — Releasse Pursuant to NDA — CONFIDE
ENTIAL 391
Virus part 1 Virus part 2

CRC part 1 File
(Jump code) (Main portion)
The scan engine uses this information to detect if a file has been infected with a specific virus.
After detecting the first part of the virus using CRC part 1, the scan engine looks for the
corresponding CRC part 2 for information about the remainder of the virus. Part 2 contains
additional identification information about the remaining portion of the virus and is designed to
confirm that the file is indeed a virus.
To locate Part 2, the scan engine requires information about its expected location within the file.
This information is stored in what pattern builders call the CRC table, and the location within the
file is called its offset.
Offset
Virus part 1 Virus part 2

File CRC part 2
Once the virus has been identified, the scan engine requires information to clean/remove the
virus. This information is stored in what antivirus engineers call the virus information table. Once
the scan engine retrieves the cleaning/removal information that corresponds to the identified
virus from the table, it is then able to take action against the virus.
Prior to Smart scan, both CRC parts and the Virus info table were contained within the same
malware signature pattern file. So when the scan engine and pattern file were loaded into
memory as a data structure called a scan context, all the malware-identification information that the
scan engine required accompanied it in memory.
Scan context
Existing pattern
CRC Part 1
Scan
CRC Part 2
engine
Virus info
Non-CRC data
Smart scan addresses the needs enumerated in the previous section by deconstructing the
existing pattern as shown below:
Smart filter generated based on

CRC Part 1 data
New pattern External database

(Smart query filter) Existing pattern (Smart scan pattern)
CRC Part 1 CRC Part 1 CRC Part 1
CRC Part 2 CRC Part 2
Virus info Virus info
Non-CRC data
Non-CRC data
CRC & Virus info for

In-the-wild malware
Non-CRC pattern
(Smart scan agent pattern)
Note the following changes to the existing pattern:

● CRC and Virus info information is still stored locally for malware that are classified as “in-
the-wild”. This means that the only anti-malware information that are available locally are
those that correspond to malware that are actually actively doing harm. This information
resides in the Smart scan agent pattern.
● CRC and virus information for malware that are no longer considered in-the-wild are moved
to an external database called the “Smart scan pattern”. This pattern contains all the CRC
parts 1 and 2 information of the traditional pattern.
Tip In the next section, pay attention to a file called the CRC cache in the next
section. This file serves a local repository for CRC part 2 and Virus info data once these
are queried from the Cloud Virus pattern during the normal course of the CCFR process.
● An abbreviated copy of “Part 1” information, for not-in-the-wild malware, is moved to a

new pattern called the Smart query filter, which DSVA uses to determine when to query the
external database for matching Part 2 information. This serves as a kind of index to the
information in the external database.
● Non-CRC data is stored is also stored in the “Smart scan agent pattern”.
Important: Both the Smart query filter and Smart scan agent pattern reside on the DSVA.
About CRC parts: An analogy

One very rough approximation of the relationship between CRC parts 1 and parts 2 would be
the relationship between a person’s first and last name. Many people can share the same last
Trrend Micro De
eep Security Suppo
ort Track
name, and many people can share the same first nam me. There a combination of
o first and lastt
names is reequired to iden
ntify a specificc individual.
Consider a bus conductoor, shown belo
ow, who has been
b given thee task of keepiing specific
individuals from boardin
ng his bus.
The ticketing office has complete bioggraphical inforrmation about these individduals, to ensurre
accurate identification.
A logical way
w for the con nductor to maatch passengerrs with these records
r wouldd be to have alll
available in
nformation on
n-hand. This so
olution may work
w when deaaling with onlyy a few individduals.
But as the number of peeople to watch
h out for increeases, this metthod will beco
ome cumberso ome.
An alternattive method would

w be to usse a subset of the informatio
on in the main n files as a
preliminaryy identifier. In
n this analogy, the conducto or chooses to write
w a list of last
l names on na
piece of paaper that he thhen carries witth him, and thhen leaves the detailed files at
a the ticketingg
office.
39
94 CONFIDENT
TIAL — Release Pursuant
P to NDA
A — CONFIDENT
TIAL © 2012 Trend
d Micro Inc.
This makes the information more manageable, albeit at the expense of completeness The
conductor, therefore, will have to obtain additional information as required.
The operating schema is shown below.
My name is All details
John Smith for: “Smith”
Smith
The conductor gets the name of every individual who gets on board the bus. If the individual’s
last name does not match names in the list that the conductor keeps, then that person can get on
without further interference.
However, if there is a match, as in the example above where the passenger “Smith” matches one
of the last names on the list, the conductor calls the ticketing office asking for detailed files about
all undesirables named “Smith”.
The ticketing office then responds by sending the required records. Only then will the conductor
have complete records on-hand, and only for a small subset of bad passengers. The conductor
then compares the individual’s full identity with those on the “Smith files”.
Had the person’s full name been “Denzel Smith”, as shown below, then it would not be a full
match for the information on the records. This indicates that he is not on the no-ride list, and is
free to board the bus.
Welcome
My name is aboard!
Denzel Smith
(No match)
Smith
However, if a match is found, then the conductor reports this to the ticketing office and asks for
instructions about how to deal with a known bad passenger.
Confirmed!!!
How do I deal
with him?
Smith
To summarize this analogy:

● The “passengers” are files being scanned, with bad passengers being malware
● The “conductor” is the DSVA
● The “ticketing office” is the external scan server
● The passenger’s “last name” is CRC Part 1 information, and process of asking for it, is the
CRC computation process.
● The “records” that the ticketing office sends to the conductor represent CRC Part 2
information
● The question “How dow I deal with him” represents a call for malware cleaning/removal
information (VInfo).
Smart scan operation (Section 11.6.5 > How does it work?)

This section focuses on how the DSVA uses the external CRC database introduced in the
previous two sections. Note the two main elements in this high-level overview:
DSVA – components on the DSVA are responsible for looking for malware and taking
action upon them when found. However, unlike when Smart scan is turned off, the
knowledge required to identify malware does not completely reside within the appliance
itself. Part of this knowledge is located externally.
CRC database – this contains CRC information that corresponds to known malware and
resides on the scan server. Deep Security administrators can either refer to the Trend
Micro hosted server, or a local Scan Server if it is available
These elements work together as shown below.
Each step in the diagram is described in their respective sub-sections below.
STEP 1: REFERENCE SMART SCAN AGENT

PATTERN (ICRC$OTH.XXX)
Each time the DSVA scans a file, it starts by WHAT INFORMATION IS FOUND
referencing information in the Smart scan agent IN THE SMART SCAN AGENT
pattern. PATTERN?
The information in this pattern
At this point, the client uses the VSAPI scan engine include the following:
to perform the following tasks: • CRC and virus info data for in-the-
wild malware
● In-the-wild verification • CRC part 1 computation algorithm
• Script-based scan patterns
● CRC-pattern applicability
• ScriptTrap
● Compute for CRC part 1 • PETrap
• Exception patterns
Once all these tasks are complete, and the VSAPI • EXE & COM cleaning patterns
scan engine is unable to use information in the • Active Action table
Smart scan agent pattern to remove/clean the • Other pre-CRC patterns
malware, then it proceeds to Step 2, and begins the
first step in Smart scanning.
In-the-wild verification
The Smart scan agent pattern contains complete CRC Parts 1 & 2, and VINFO information for
malware that are considered “in-the-wild”. The DSVA, therefore, is able to use this locally-
available information to clean the malware without querying an external database.
NOTE For details about the in-the-wild list, see http://www.wildlist.org/.
In this step, the client implements the following logic:

Reference CRC Yes
Confirm that file Remove malware
information in
requires CRC- Match found? using Smart scan
Smart scan agent
based patterns agent pattern
pattern
No
Continue with
other Step 1
activities
If the scan engine finds that the file being scanned matches CRC signatures for in-the-wild
malware in the Smart scan agent pattern, then it will act upon the file as it would in a
conventional scan. If a match is not found, then the client continues with other uncompleted
tasks in this step.
CRC-pattern applicability
Step 1 gives the individual anti-malware functions within the scan engine a chance to analyze the
malware. Each individual function evaluates its ability to clean/remove the malware, and at the
end of the step, only the relevant scan engine function acts upon the file.
When the DSVA scans a file, it first identifies its file type to determine the appropriate malware
identification technique. This information is then passed to each scan engine function for
analysis. Each function follows the following logic:
VSAPI scan module

(1 – n)
Yes
Scan module Do Proceed with
(1-n) evaluates CRC-patterns Smart scan in
file type apply? Step 2
Determine
Begin
True File No
scan
Type
Use
Scan for malware
Smart Scan
without CRC
information Agent Pattern
(Icrc$oth.xxx)
Individual scan engine functions evaluate the file’s file-type, and decide whether or not to use
CRC-based patterns.
NOTE VSAPI scan engine is responsible for true-file type identification.
Certain types of malware, for example script-based malware, do not use CRC patterns. These,
therefore, do not benefit from Smart scan and instead use information in the Smart scan agent
pattern (icrc$oth.xxx).
If the file being scanned cannot be analyzed with CRC-based patterns, then the scan engine uses
non-CRC pattern information in Smart scan agent pattern. Smart scanning for this file, therefore,
is no longer required.
CRC part 1 computation

As discussed in the About CRC section, Smart scanning requires CRC part 1 information for
preliminary malware identification – which actually occurs in Step 2. The algorithm for
computing CRC part 1 is contained the Smart scan agent pattern.
The part of the file for which the CRC is computed varies between file types. For example with
certain types of executable files, the CRC is computed for the first 4KB of the file.
STEP 2: FILE REPUTATION ASSESSMENT

In this step, the DSVA determines if the file being analyzed is a known malicious file that isn’t
part of the in-the-wild list. This is where the file’s reputation is assessed.
It implements the following decision logic:
Begin file reputation Is the file Yes Continue

assessment malware? analysis
No
End analysis
When a file is flagged as “malware” in this assessment process, it means that there is a high
probability that it is malware. It is not yet, however, confirmed that it truly malware. This
confirmation occurs later in the process. However when the file is flagged as “not malware”,
then the scan engine ends analysis for that file.
Here, the VSAPI scan engine uses the CRC part 1 information calculated in Step 1 for reputation
assessment. The following are details of how the client implements the logic outlined above:
Yes
Verify Smart Verify CRC
Compute CRC Match found?
query filter cache
No
Not a virus
As shown above, DSVA refers to a file called the Smart query filter (BF.ptn) to determine if the file
is indeed malware. This filter acts like an index to the malware information on the Scan Server.
If the file’s CRC part 1 is not found in the BF.ptn, then it is not malware. This information is
passed to the scan engine which then ends the scanning process for this particular file. However,
if the file is found, then there is a statistical probability that it is indeed malware, and is therefore
subject to further verification.
THE SMART QUERY FILTER AND THE FALSE POSITIVE PERCENTAGE

Each time the Smart query filter is generated on the scan server, the debug log for the scan
server, diagnostic.log, records a false positive percentage for the filter, as shown below.
2009/03/27 13:04:18 Pacific Daylight Time [02520] [DEBUG] [MakeBF.cpp (104)]
false positive probability: 0.3036%
Important: This “false positive” figure should not be confused with false alarms where
legitimate files are misidentified as malware. This false positive occurrence simply results
superfluous scan server queries.
The percentage above refers to the likelihood that analysis of what is actually a safe file will result
in a smart scan query to the scan server. To understand why this happens, let us use an adjusted
version of the bad passenger analogy.
The key point to remember is that the CRC Part 1 information contained within the Smart query
filter pattern is not the full CRC Part 1 information, and is merely an abstraction. Applying this
to the analogy, the piece of paper that the conductor carries would not really contain the full
name “Smith”, but would appear as below:
Last name in full record Last name in paper
Smith Sm
By abbreviating the name, in this example to just two letters, it is possible to fit more names
within the existing piece of paper. This reduction of information, of course, reduces the accuracy
of the match that would result in a call to the ticketing office for additional information. Not
only will a passenger named “Smith, Denzel” result in a call, but so will the following names:
Smythe, John Smithy, Frank Smolinski, Bob
The abstraction introduces the possibility of a false positive. It is not, however, a fatal false
positive since the conductor won’t eject the passenger until the records from the ticketing office
arrive. Since the passenger won’t match any of the bad passenger records, no action will actually
be taken upon this passenger.
All that this causes is superfluous calls. Provided the ratio between valid and superfluous calls
remains reasonable, the situation will remain manageable. Otherwise, it will be necessary for the
conductor to add letters to the names on his list. Changing “Sm” to “Smi”, for example,
immediately eliminates 2/3 of the false positives shown in the sample above.
Smythe, John Smithy, Frank Smolinski, Bob
The effect of this bump in accuracy, however, is a need for a larger piece of paper since it must
contain more information.
As discussed earlier, the piece of paper is a representation of the Smart query filter pattern. The
CRC Part 1 records it contains are much more complicated than five-letter names, but are still
abbreviations of the full CRC Part 1 information in the full pattern, and therefore have margins
for error.
By design, the maximum tolerable false positive rate is 5%. If the query filter generation process
detects that this limit has been exceeded, it automatically compensates by increasing the amount
of CRC Part 1 information the filter contains. This results in an increase in the size of the filter
pattern. This pattern increase behavior is hard-coded and cannot be modified.
STEP 3: LOCAL VERIFICATION

In this step the DSVA looks for locally available information about the suspicious file. This
avoids superfluous queries to the Scan Server.
This process revolves around a file called the CRC cache (cache.dat), which contains information
from previous Scan Server queries. The client checks this cache to see if there is already
sufficient information to act on the file being analyzed.
Important: The information within the cache determines what DSVA does when the Scan
Server is inaccessible.
The following logic is applied here:
CRC Yes Yes

Verify VINFO
Information Take action
CRC cache available?
available?
No No
Proceed to Proceed to
Step 4 Step 6
If all the required information about the file is available in the cache, then the VSAPI scan
engine re-uses this information to deal with the file.
However if the information is not present in the CRC cache, then DSVA queries the scan server.
As shown above, the nature of the query depends upon the information available in the cache.
The purpose of CRC and VINFO information are described in Steps 4 and 6 respectively.
STEP 4: SMART SCAN PATTERN QUERY (CRC)

The About CRC section of this chapter introduced the “Part 1” and “Part 2” concept for
identifying malware based on CRCs. In this step, the Scan Server is queried for “Part 2”
information, which enables the scan engine to confirm that the suspect file is indeed malware.
NOTE This is the first of what will be two queries to the scan server.
As of writing, the CRC database is stored in a file called the Smart scan pattern (icrc$tbl.xxx). The
manner of storage is the object of continual review.
The query process proceeds as shown below:
Client-side
processing
Send CRC query to

End Step 2 Begin Step 5
Scan server
Scan server-side
processing
As shown above, this step can be divided into two sub-steps that run concurrently: client-side
and scan server-side processing.
Client-side processing
By design, the DSVA only waits for a response, from the Scan Server, for a maximum of 500
milliseconds. The following flowchart shows this process.
Required Yes
Wait for response
Send CRC
response Begin Step 5
query
(max time = 500ms) received?
No
Perform error Send error

handling to VSAPI
Important: For this brief period, VSAPI locks the file. This is normal behavior for VSAPI, and is
how it behaves in conventional scanning.
If the iCRC handler is unable to query the Scan Server, then the server-side processing portion
of this step does not occur, and the client attempts to query another scan server if one is
available, or proceeds to what this document refers to as offline protection. See Error! Reference
ource not found. on page Error! Bookmark not defined..
Scan Server-side processing

The specifics of how this query works is restricted information. However for this discussion, we
can say that the “Part 1” information can correspond to multiple “Part 2” records in the CRC
database.
Consider the following representation that is based on the modified analogy introduced in Step
2. The CRC sent to the Scan Server is represented by “Sm”. As shown, the CRC “Sm” actually
corresponds to three malware records.
Part 1 Part 2 #
Smith Denzel 1
Deveci Jen 2
Lim Jack 3
Sm Smith John 4
Costa Jack 5
Smits Bob 6
Chua Alp 7
At the end of the query, the scan server parses the the necessary information, and then returns
only the relevant records to the DSVA, as shown in the representation below.
Part 1 Part 2 #
Smith Denzel 1
Smith John 4
Smits Bob 6
The scan engine on the DSVA then uses this information to identify the specific variant of the
malware that was detected – if it is indeed malware.
When the Scan Server receives the CRC query, it implements the following process:
Not malware
No
Look for matching

Receive CRC CRC information in Match found? Return result
Smart Scan Pattern
Yes
Retrieve
“Part 2”
information
If the CRC information sent in the query matches “Part 1” information in the Smart scan
pattern, then the Scan Server returns all the corresponding “Part 2” records to the DSVA. The
client then uses this information for malware identification. otherwise, it returns no records, and
the scanning process ends for this file.
STEP 5: MALWARE IDENTIFICATION

After completing the search for relevant “Part 2” records, the Scan Server sends this information
back to the DSVA. In this step, the DSVA receives the information, and uses it to confirm if the
file being used is actually malware.
To accomplish malware identification, the DSVA implements the following process:
Pass Yes
End Step 4 Receive result information to Match found? Query Virus ID
VSAPI
No
Add
information Not malware
the cache
When the DSVA receives CRC information from the Scan Server, it does the following:
Pass the information to VSAPI – the scan engine performs the matching operation
described at the start of this step. If no match is found, the file is safe and the scanning
process ends. However if a match is found, the DSVA queries the Scan Server for
records that correspond to the malware’s virus ID . This is described in the next step.
Add the information to the cache - All the records that were returned by the CRC query
in the previous step are entered into the cache – regardless of whether or not they
correspond to the malware that is detected in the system.
NOTE The CRC cache can store a maximum of 6,000 records. If this is exceeded,
entries would be deleted on a Least-Recently-Used basis.
Next, it proceeds with the scan itself. As with other aspects of scanning technology, how this is
actually done is restricted information. However the following representation approximates how
this is done.
The illustration below combines the representation of the records that were returned in the
previous step, with the representation of the infected file from the About CRCs section.
Part 1 Part 2 #
Smith Denzel 1
Smith John 4
Smits Bob 6
Smith File John

Jump code
The scan engine identifies the virus by comparing the “Part 1” and “Part 2” information in the
malware records, with the corresponding parts of the virus. If a match is found, then the
malware has been identified. Otherwise, the file is not malware, and the process ends.
In this example, Part 1 and Part 2 information in record #4 matches the parts of the virus that
infected the file in the illustration. This indicates that the virus is malware #4. Since a match was
found, the process proceeds to step 7 to obtain the information required to remove this specific
malware.
STEP 6: SMART SCAN PATTERN QUERY (VIRUS INFO)

In the previous step, the scan engine found that Parts 1 & 2 for record #4 matched those parts
in the file being analyzed. This not only confirmed that the file was infected, but also identified
the virus that infected it.
What the scan engine needs now is the information for cleaning/removing the virus. In this step,
the DSVA queries the Scan Server for virus information (VINFO) for malware #4. This query
process proceeds as shown below:
Client-side
processing
Send Virus ID query

End Step 5 Begin Step 7
to scan server
Scan server-side
processing
Like step 4, this step can be divided into the following sub-steps: client-side and server-side
processing
Client-side processing
As with Step 4, the DSVA waits for a maximum of 500 milliseconds for the Scan Server to reply.
The following flowchart shows what the client does in this step:
Yes
Wait for response
Send VINFO Response
Begin Step 7
query received?
(max time = 500ms)
No
Perform 2nd
action
If the DSVA does not receive a timely reply, the client will abandon the primary action, in favor
of the secondary action.
If the client were using the settings above, a VINFO query failure would cause the client to
quarantine the malware instead of cleaning it.
Important: At this point, the DSVA has already confirmed that the file is malware. Therefore
action is warranted.
Server-side processing
As explained in the About CRC section, knowledge about how to clean/remove malware is
stored in the virus information table, which is now part of the Smart scan pattern on the Scan
Server. To obtain this knowledge, the DSVA sends a second query to the Scan Server. However,
instead of sending CRC information like in the first query, the client sends the Virus ID (VID) of
the CRC record that matched the malware that was detected. The Scan Server then searches for
the Virus Information (VINFO) that corresponds to this VID.
Consider the following representation of this process:
Part 1 Part 2 # # Virus info
Smith John 4 4 Xxxxxxxxxxxxxxxxxxxx
The representation in the previous step matched malware record #4 with the malware that was
detected.. The VINFO that the DSVA needs to remove the malware, therefore, is the VINFO
that corresponds to “VID = 4”.
The Scan Server implements the following process in this step.
Receive Search for VINFO

Return result
Virus ID based on Virus ID
To obtain VINFO, the DSVA sends the VID of the malware identified in Step 6 to the Scan
Server. Receipt of this VID is recorded on Web server logs on the scan server. A sample of this
is shown below:
2009‐01‐29 20:58:16 W3SVC4 10.2.34.89 GET /tmcss/VSAPIInfo.dll
BF=580456&VID=08000000BCB30800306725B1& 4345 ‐ 10.10.10.10 iCRCHdler+1.0.1081 200 0 0
The Scan Server then uses this VID to search for the appropriate VINFO. Once the VINFO is
retrieved, the Scan Server returns this to the DSVA for use by the scan engine.
STEP 7: REMOVE MALWARE

In this step, the DSVA receives the virus information from the Scan server, and the scan engine
uses this information to remove the virus.
Role of each pattern

The following illustration shows the patterns are involved in Smart scan functionality:
These patterns are discussed in the following sub-sections:

● Smart filter & Smart scan pattern
● CRC cache updates
● Smart scan agent pattern
SMART FILTER & CLOUD VIRUS PATTERN

Both files are at the heart of iCRC functionality. Because of the close relation between these two
files, they are discussed together in the same section.
As explained in the About CRC section, CRC-related malware information can be divided into
two parts. The following information summarizes these parts and relates them to the relevant
components.
CRC Purpose of the Relevant How the Component

part CRC part iCRC component works location
component
Part 1 Identifies if the file Smart query This file serves as an DSVA
either contains filter (BF.ptn) index for Part 1 Scan server
malware, or is information in the
malware Cloud virus pattern
Part 2 Information that Smart scan In addition to Scan server

the scan engine pattern unhashed version of
needs to remove (icrc$tbl.xxx) Part 1 CRC
the corresponding information, this also
malware contains information
about the expected
location of malware
code within the file,
and how to remove
this code
About the Smart scan pattern

The Smart scan pattern is the CRC database to that resides on the Scan server. It contains both
CRC parts 1 and 2 information, as well as the virus information data required to clean and/or
remove malware. For smart scan clients, the information queried from this pattern serves the
purpose of both the VSAPI virus pattern, and the Spyware active monitoring pattern used for
anti-spyware functionality.
Scan servers obtain updates for this pattern via the ActiveUpdate mechanism.
NOTE This pattern supports incremental pattern technology.
About the smart query filter

The Smart query filter functions as a client-resident index to the CRC part 1 information that is
available on the scan server. As explained in About CRC parts: An analogy, this pattern is an
abbreviation of the information available in the primary pattern that resides on the scan server
making it a “lightweight” alternative to the conventional method of having all malware detection
and removal information resident on each DSVA.
Information in the pattern is used to test whether or not a file is present in the Smart scan
pattern or not. The information is designed such that false negatives are impossible – a safe file
will never be misidentified as malware.
False positives, however, are possible. This is expected since the filter does not contain all the
data points required to accurately identify malware. This is why CRC part 2 information is
required prior to any action.
The false positive probability is computed each time the filter is generated on the scan server.
This is recorded on diagnostic.log on the scan server, as shown below.
2009/03/27 13:04:18 Pacific Daylight Time [02520] [DEBUG] [MakeBF.cpp (104)]
false positive probability: 0.3036%
The scan server generates an updated smart query filter each time the Smart scan pattern is
updated. In addition to the filter itself, incremental versions of the pattern are also generated.
FALSE POSITIVE PROBABILITY

The maximum acceptable false positive (FP) probability is 5%. If the Scan server –
particularly a tool called MakeBF.exe -- finds that the filter’s FP is greater than 5%, the
application automatically increases the size of the Smart query filter to improve the FP
rate. This behavior is not configurable.
CRC CACHE UPDATES

As explained in Smart scan process section, the CRC information that a DSVA retrieves from
the scan server is stored in its memory-resident CRC cache. This allows the client to re-use
information retrieved in previous queries, thereby reducing bandwidth consumption.
If the Smart scan pattern on the scan server is updated, there is a probability that the information
in the cache is rendered either obsolete or incomplete. In which case, the information must
either be updated by way of CRC cache updates (CRCDiff), or purged entirely and recreated.
The following CRC cache-related concepts are discussed here:
● What are CRC cache updates?
● Purging the CRC cache
What are CRC cache updates?

CRC cache updates are incremental pattern files that contain the changes to existing CRC
information that result from a Cloud Virus pattern update. The following table illustrates the
kinds of changes that can occur:
Modification Part 1 Part 2 #
ABC 123 1
ABC 789 4 351
ABC 723 6
Deletion Part 1 Part 2 #
ABC 123 1
ABC 789 4
ABC 723 6
Addition Part 1 Part 2 #
ABC 123 1
ABC 789 4
ABC 723 6
ABC 426 9 ABC 426 9
CRC cache updates can implement all of the above changes to the information already in the
DSVA CRC cache.
Purging the CRC cache

DSVAs purge their CRC caches in the following instances:
● The smart filter is completely replaced
● There are no incremental cache updates available (CRCDiff)
As will be explained in the next section, during normal operation, clients update the smart filter
with incremental updates. However if the DSVA has been offline for a extended period, such
that incremental updates are insufficient to make the smart filter current, then the client obtains a
new smart filter and its entire existing cache is discarded.
If the client is still able to update its smart filter incrementally, then only records that correspond
to the updated CRC part 1 record are purged from the cache. This incremental update process is
discussed in the next sub-section.
SMART SCAN AGENT PATTERN

This pattern (icrc$oth.xxx) contains all the non-CRC related information contained in the
original pattern. This includes the following information:
● Full CRC and virus information for in-the-wild malware
● Algorithm information that the scan engine needs to generate CRC information for use in
CRC queries.
● Script-based scan patterns (e.g., VBS, Javascript, etc.)
● ScriptTrap
● PETrap
● Exception patterns
● EXE & COM cleaning patterns
● Active Action table
● Other pre-CRC patterns
Like previous patterns, updates for this pattern are obtained via the normal ActiveUpdate
mechanism.
NOTE This is the only Smart scan pattern that is visible in the pattern summary
screens.
A.7.4 Required Windows patches (Section 11.5)

Virtual machines, already protected by DSVA, can also have DSAs installed in an arrangement
called the coordinated approach. For this to work on 64-bit Windows XP or Windows Server
2003 machines, both must be patched to at least Service Pack 2
A.7.5 Virtual host resolution (Section 11.5)

There may be situations when a DSA, implemented as part of a coordinated approach, fails to
activate. But the virtual agent protecting the virtual machine is activated successfully. This can
result if the virtual machine’s hostname cannot be resolved from the DSM. To correct this,
administrators can do one of the following:
Option 1: Add the virtual machine’s hostname in the hosts file of the DSM host
Option 2: Update DNS entries of the DSM host
A.8 > Chapter 12: Communication and

management
The following Deep Dive information for Chapter 12 is discussed here:
● Consulting Trend Micro
A.8.1 Consulting Trend Micro

If the communication and/or management problem encountered requires consultation with
Trend Micro, collect all the information that the technical support organization would need to
analyze the issue. Perform the following steps:
A
Collect basic product
and environmental
information
Collect product logs

(DSM and DSA)
Consult Trend Micro:

C Consultation
Communication issue
Collect configuration
files
(DSM and DSA)
D
Collect PING, TELNET,
and NSLookup results
(DSM and DSA)
Ste Notes
p
A This involves collection of information about the DSM and DSA hosts involved in the
issue, as well as basic product information. This includes:
• Screen capture of all relevant error messages

• Product version and, when applicable service packs and patches installed
• License and/or Activation Code information
• Third-party products present on the hosts
• Network topology diagram
• System information – this will vary with the operating system. See table below
Microsoft Windows Winmsd.info

variants
Linux variants Run the following commands
For platform information:
uname –a
For driver information:
Cat /proc/driver/dsa/info
For package information:
rpm –qa ds_agent
Solaris Run the following commands
uname ‐a
pkginfo –l ds_agent
HPUX Run the following commands
uname ‐a
swlist ds_agent
AIX Run the following commands
uname ‐a
lslpp –L ds_agent.rte
B Collect product logs
For the DSM
As of writing, only the Windows version of Deep Security was supported, so this
procedure only applies to this platform. Collect the following files:
Diagnostic Create a diagnostic package as described in DSM diagnostic

package (server) package on page 376. For most situations this will be
sufficient for collecting products logs.
Server0.log When collecting the server0.log directly, follow the procedure

discussed in Appendix E for increasing the debug level.
For the DSA
Collect the following information from the DSA. Platform-specific differences are listed
in the sub-tables shown below
Diagnostic The procedure for generating the package from within the
package (agent) DSM console is discussed in DSA diagnostic package on page
306. This is standard for all DSA platforms.
Driver installation When analyzing driver related problems, the following

logs information will be needed:
• Platform information
• Driver information
• DSA package information
The diagnostic package will include this information.

However, administrators can still collect information directly
by using the following operating system-specific procedures:
Microsoft Collect setupapi.log from the following

Windows location:
variants
C:\Windows\setupapi.log
Linux variants Run the following commands
uname –a
For driver information:
Cat /proc/driver/dsa/info
rpm –qa ds_agent
Solaris Run the following commands
uname ‐a
pkginfo –l ds_agent
HPUX Run the following commands
uname ‐a
swlist ds_agent
AIX Run the following commands
uname ‐a
lslpp –L ds_agent.rte
Debug view log Visibility into what the DSA is doing at any given time will
greatly facilitate analysis of problems. To enable this
functionality an agent configuration file -- that is not actually
present by default -- must be created.
The file, and where the log output appears, varies according
to the DSA platform. However, in all instances, administrators
must add the following line to the configuration file:
Trace=Appl Beat Cmd Cfg Conn HTTP Log Lstn Srvc SSL

Alternatively, to generate output for all functionality, add
the following line instead

Trace=*
NOTE For a complete list of valid parameters for

Trace, see ___
Stop the service before adding the entry in the configuration

file, then start it again.
Platform specific differences are outline below.
The configuration file to be added:
Microsoft <System root>\ds_agent.ini

Windows
variants
Linux variants /etc/ds_agent.conf
Solaris /etc/ds_agent.conf
HPUX /etc/ds_agent.conf
AIX /etc/ds_agent.conf
On Windows platforms, the agent debug log will be created in

the DSA folder, and is best viewed using the DebugView
utility from SystemInternals.
On non-Windows platforms, however, the output must be

directed to a Syslog. Platform specific procedures for
configuring Syslog to accept logs from the DSA are shown
below.
Linux Add the following line to syslog.conf:

variants
local0.info /var/log/messages
The output goes to syslog using ""local0"", so

where it ends up depends on your
/etc/syslog.conf settings.
Solaris Modify syslog.conf and add *.info to the line

pointing to /var/adm/messages:
*.err;kern.debug;daimon.notice;mail.crit;*.info
/var/adm/messages
Restart the syslog service:
svcadm restart /system/system‐log:default
The output goes to syslog using

/var/adm/messages
HPUX Modify syslog.conf and add *.info:
*.info /var/adm/syslog/syslog.log
Restart the syslog service:
/sbin/init.d/syslogd stop
/sbin/init.d/syslogd start

/var/adm/syslog/syslog.log
AIX Modify syslog.conf and add the line (This will

output everything to syslog):
local0.info /var/log/syslog
Restart syslog using:
refresh ‐s syslogd

/var/log/syslog"
C Collect configuration files
For the DSM
Collect a file called dsm.properties. This file contains information that the DSM uses to
connect to its database. This can be found in the following location:
C:\Program Files\Trend Micro\Deep Security Manager\webclient\ROOT\WEB‐INF

NOTE The diagnostic package also collects this file.
For the DSA
For this procedure, all the administrator needs to do is view the client configuration on
the DSA user interface. This is provides a quick way to determine if the agent is
applying the expected rules.
D Perform PING, TELNET, and NSlookup tests on both DSM and DSA hosts
From the DS Manager, open command prompt and run the following commands then
copy the results:
• Ping <DS Agent hostname exactly as it appears in DS Manager console>

• Nslookup <DS Agent hostname exactly as it appears in DS Manager console>
• Telnet <DS Agent hostname exactly as it appears in DS Manager console>
4118 (once complete you may need to ctrl-] to break the input)
• Copy the results to a text file
A.9 > Chapter 13: About logs, alerts, and reports

● Known issues (Section 13.9)
A.9.1 Known issues (Section 13.9)

The following highly unlikely issues have been known to occur:
● Missing rule identification in logs

● Missing MAC address information
Missing rule identification in logs

Under certain circumstances, DPI and firewall logs on either the DSM or DSA will display
numbers instead of the object names for firewall rules, traffic stream, and DPI filters/rules. This
occurs when the log viewer is not able to access information about the objects referred to by the
log entry.
This problem can occur in the following scenarios:
● The DSA no longer applies a rule that had been triggered in the past. When viewing logs, the
entries that correspond to the old rule will remain, but the DSA no longer possesses
information about the rule itself. The DSA only knows the rules that it is currently
enforcing; it does not keep track of past rules.
● A new set of rules has been assigned to the DSA, but the refresh button had not yet been
clicked on the Agent Configuration tab to refresh the display of logs on the DSA console.
● A DSA with logs that have not yet been uploaded to its DSM, was transferred to a new
DSM. When the DSA uploads the logs, the DSM might not have the rules referenced in the
logs.
Missing MAC address information

This is only a problem in Linux-based DSAs, and is due to the NDIS driver’s location in the
protocol stack. If a DSA takes action on a packet before the OS completes ARP resolution,
MAC address data will not be written to the event log.
A.10 > Chapter 14: Updating a Deep Security

network
The following Deep Dive information for Chapter 14 is discussed here:
● Update technology
● OPR and CPR
● Understanding update logs
● Updating the DSM
A.10.1 Update technology

The following aspects of Trend Micro update technology are discussed here:
● About incremental updates
● About site duplication
● About smart duplication
About incremental updates

Incremental update technology Pattern
limits the impact of updates on #1
Incremental pattern #8
network bandwidth and system

resources. This was originally only
Pattern #2 Incremental pattern #7
available for virus pattern updates,
but is now also available for other
patterns. It still, however, does not
apply to scan engine updates.
For each new pattern on the Trend
Micro update server, several
incremental patterns are also
available. Each incremental pattern
contains the difference between the
malware signatures in the most
recent pattern version, and the Pattern #6
Incremental
pattern to which the increment pattern #2
corresponds.
Inc. ptn
Pattern #7
Consider the illustration on the #1
right. If a product is currently using

“Pattern #5”, then all that the Pattern #8
product would need to update its
pattern to the most current pattern
would be to download Incremental Number of virus signatures
pattern #3, which contains all the
new virus signatures that were added in versions 6 to 8. The ActiveUpdate module downloads
this incremental pattern, and then merges it with Pattern #5, thereby updating it to Pattern #8.
NOTE For merge functionality, AU leverages the RT Patch library from Packet Soft, Inc.
Incremental updates obviate the need to download complete patterns, thereby reducing the
bandwidth consumed during pattern updates.
Consider the table on the right, which
shows the file sizes for virus pattern Virus pattern xxx
____ and the associated incremental Pattern Size
virus patterns. When comparing the Full pattern (compressed for
size of the full pattern with those of the download)
incremental patterns, the benefits for Increment 14
bandwidth are obvious.
Increment 13
Increment 12
NOTE Gaps between versions
exist because these missing Increment 11
versions are allocated for Incremental patterns 4 to 10 skipped
Controlled Pattern Releases.
Increment 3
Incremental patterns are available for Increment 2
14 of the most recent Official Pattern Increment 1
Releases. If a product uses a pattern
that is more than 14 versions older than
the current pattern, then the product will download the latest full pattern.
Duplication methods
The Deep Security Manager acts as a local update server for its agents. This means that is must
be able to offer both full and incremental updates to its endpoints. The ActiveUpdate module
offers two methods for providing this functionality:
● Site duplication
● Smart duplication
The end result for both methods is essentially the same: agents are given a choice of 14
incremental patterns to choose from. The difference lies in how these 14 incremental patterns
are obtained.
ABOUT SITE DUPLICATION

This is initially how all Trend Micro products Trend Micro Deep Security
update site Relay
that acted as AU sites for other product
components created local AU sites. In this Full pattern
method, the ActiveUpdate module made a
direct copy of all relevant files that existed on
the Trend Micro update site on the product Incremental pattern #1 to #14
server.
The following diagram on the right shows
what happens during site duplication. As
shown, site duplication is a very bandwidth
intensive process. For each pattern type, 15
files need to be downloaded: the full pattern
and the 14 corresponding incremental
patterns. For the virus pattern alone
(lpt$vpn), this was already 44.3 MB as of
writing.
As a bandwidth conservation measure, an alternative duplication method was first introduced in
AU 2.8: Smart duplication. This is discussed in the next section
ABOUT SMART DUPLICATION

Smart duplication is a reduced bandwidth AU site replication method, and can be described as
incremental update for local AU sites. This technology is not used in Deep Security.
A.10.2 OPR and CPR

As discussed in previous sections, version numbers for Trend Micro patterns are determined by
two types of patterns: Official Pattern Release (OPR), and Controlled Pattern Release (CPR).
The CPR has a notable effect on smart duplication, and therefore merits closer scrutiny. Since
discussion of CPRs is disjoint without an explanation of what OPRs are, both patterns are
explained in their respective sub-sections below.
NOTE Other pattern types, such as “bandage” patterns are beyond the scope of this
section.
About OPR
The regular updates that Trend Micro customers receive are released as part of an OPR. Upon
release, these patterns are posted on the ActiveUpdate system, where products can download
them from their default update sources.
OPR patterns are easy to differentiate from CPR patterns by their version numbers. The former
always use odd-numbered file extensions. For example
icrc$oth.373
CPRs are given even numbered version. This numbering convention is readily seen on the
download page of the Trend Micro Website
About CPR
The formal definition of a CPR is shown below
A Controlled Pattern File Release (CPR) is a manually loadable, pre-release version of a Trend Micro virus
protection database, designed to provide users with additional antivirus protection in between official pattern file
releases.
These patterns are made available via the Trend Micro Website, and not through the standard
Trend Micro update server. As a consequence, these have to be applied to the products
manually.
CPR patterns are full patterns, and no incremental patterns are generated for them. So if a
product uses a CPR, then the next update will download a full OPR pattern, since incremental
updates to update the CPR version to OPR are not available.
A.10.3 DSR update process

The DSR update process can be divided into the following phases:
● Phase 1: Trend-to-DSR update
● Phase 2: Self update
● Phase 3: Trend-to-DSR duplicate
● Phase 4: DSR-to-AMSP update
The DSR update proceeds differently between a freshly installed DSR, which lacks the product
indices and the latest DSR manifest, and a DSR that has already been updated at least once.
These first-use steps will be identified below.
Phase 1: First-use updates

This phase consists of the following steps, most of which are only done in first-use situations:
● Step 1: Fresh installation detection
● Step 2: Download DSR product index
● Step 3: Download components in product profile
● Step 4: Generate product indices
● Step 5: Cleanup and feedback
STEP 1: FRESH INSTALLATION DETECTION

Trend Micro collects update statistics through a feedback mechanism that sends update results,
at the end of the update process, back to the update server. To match the feedback with the
product that obtained the download, the iAU module assigns a GUID to the product using
simple text file called an x-tag on its host.
In this step, the DSR verifies if the x-tag is present. If this file is missing, the DSR generates one.
The following DSR iaurelay.log entry records the feedback mechanism verifying the existence of
the x-tag:
[2011‐Nov‐11 14:18:08 3840|3972] [app] iAU::DirectoryManager::DirectoryManager
[src\common\src\directory_manager.cpp(28)]
Auto control the path : C:\Program Files\Trend Micro\Deep Security
Relay\relay\iau\feedback
Max size is : 1048576
Force size is : 1048576
[2011‐Nov‐11 14:18:08 3840|3972] [app] iAU::FeedbackClientID::Load
[src\common\src\feedback_client_id.cpp(67)]
If the x-tag is not found, it proceeds to generate the file. The following log sample shows this
process. This action is skipped if a valid x-tag is detected.
Unable to get xtag from local: "C:\Program Files\Trend Micro\Deep Security
Relay\relay\iau\xtag", this is fresh install.
Generating the uuid because of no xtag: 3ec37aea‐e1ae‐4656‐85ee‐3b2f6ebfe5c9
Also at this point, the DSR verifies the existence of product indices and the
common_components file.
[2011‐Nov‐11 14:18:08 3840|3972] [err] iAU::Source::GetUpdateTree
[src\common\src\source.cpp(57)]
Product index is empty.
[2011‐Nov‐11 14:18:08 3840|3972] [err] iAU::LocalSource::GetUpdateTree
[src\common\src\local_source.cpp(101)]
Failed loading C:\Program Files\Trend Micro\Deep
Security Relay\relay\iau\common_components
The sample above corresponds to a freshly installed DSR, so the product indices are empty. On
an already-in-use DSR, this step is not recorded.
STEP 2: DOWNLOAD DSR PRODUCT INDEX

At this point, the DSR attempts to compare the versions of the components it currently has with
the components on the update server. The following iaurelay.log entry corresponds to this step.
[2011‐Nov‐11 14:18:08 3840|3972] [app] iAU::Context::GetRemoteTree
[src\relay\src\context.cpp(528)]
Duplicating for product: IAURELAY_Product {
id: c22t2202v8.0.0l1p5889r1o1
components: 0000000000000000
componentCount: 0
}
[2011‐Nov‐11 14:18:08 3840|3972] [err] iAU::Source::GetUpdateTree
[src\common\src\source.cpp(57)]
Product index is empty.
[2011‐Nov‐11 14:18:08 3840|3972] [err] iAU::LocalSource::GetUpdateTree
Failed loading C:\Program Files\Trend Micro\Deep
Security Relay\relay\iau\c22t2202v8.0.0l1p5889r1o1
A freshly installed DSR, however, does not actually include any components. The product index
is empty and therefore cannot be loaded.
The following iaurelay.log entries record the relay downloading the DSR product index. In this
example, the index is for a Windows 64-bit relay.
[2011‐Nov‐11 14:18:08 3840|3972] [app] iAU::Context::GetUpdateTree
Building remote source for duplicate.
[2011‐Nov‐11 14:18:08 3840|3972] [app] iAU::UriQuery::QueryIndex
[src\common\src\uri_query.cpp(125)]
Query index for protocol :
c22t2202v8.0.0l1p5889r1o1
Temp query index for protocol :
c22t2202v8.0.0l1p5889r1o1
Query URI : https://iaus‐
preopr.trendmicro.com/iau_server.dll/c22t2202v8.0.0l1p5889r1o1
The DSR records the attempt to connect to the update server in a TmuDump.txt log. The entry
that corresponds to the download attempt above appears below.
Inf 20111111 14:18:08 3840 3972 Connecting ... 96.7.153.83:443
Inf 20111111 14:18:08 3840 3972 Connected!
Inf 20111111 14:18:08 3840 3972 Connected to iaus‐preopr.trendmicro.com:443
. . .
Inf 20111111 14:18:09 3840 3972 GET /iau_server.dll/c22t2202v8.0.0l1p5889r1o1 HTTP/1.1
Host: iaus‐preopr.trendmicro.com:443
User‐Agent: Mozilla/4.0 (compatible;MSIE 5.0; Windows 98)
Accept: */*
Pragma: No‐Cache
Cache‐Control: no‐store, no‐cache
Connection: Keep‐Alive
X‐Trend‐ActiveUpdate: 6.3.1043
Proxy‐Connection: Keep‐Alive
pragma: akamai‐x‐cache‐on
Accept‐Encoding: gzip

Inf 20111111 14:18:09 3840 3972 HTTP request headers send OK
Inf 20111111 14:18:10 3840 3972 HTTP/1.1 200 OK
Server: TMUpdateServer 2.0.0.1024
Content‐Encoding: x‐gzip
Content‐MD5: YjRiNmZjNjM2ZTVjMWJlZjQxZWY0MDQyZDYxMzFkNWY=
ETag: "c22t2202v8.0.0l1p5889r1o1:b4b6fc636e5c1bef41ef4042d6131d5f"
Last‐Modified: Fri, 11 Nov 2011 21:46:55 GMT
Content‐Type: application/xml
Content‐Length: 602
Expires: Fri, 11 Nov 2011 22:18:13 GMT
Date: Fri, 11 Nov 2011 22:18:13 GMT
X‐Cache: TCP_MISS from a204‐2‐136‐180 (AkamaiGHost/6.6.0‐8695903) (‐)
Connection: close

Inf 20111111 14:18:10 3840 3972 response OK, content followed
Inf 20111111 14:18:10 3840 3972 HttpsConnection: Successful: HTTP 200 OK
Inf 20111111 14:18:10 3840 3972 Start to get the file...
Inf 20111111 14:18:10 3840 3972 TmDownloader: Succeeded getting the file
The DSR product index contains specifies four components.
<products>
version="8.0.585"> . . .</entity>
</product>
</products>
</update>
</response>
2212 – DSR manifest

2213 – Deep Security Rule Update. This is contains the latest DPI, Log Inspection, and
Integrity Monitoring rules and is meant for the DSM
574619648 – Trend Micro URL Filtering Engine. Additional information about why this
component is obtained separately from the other Anti-Malware components will be
explained in the DSA update section
2211 – Deep Security Manifest. The DSM uses this to display component versions on the
DSM console
STEP 3: DOWNLOAD COMPONENTS IN PRODUCT PROFILE

At this point, the DSR determines if an update is required. Information in the product index
obtained from the update site is compared with those of available components. The following
iaurelay.log entries shows the relay reading the contents of the update server product index.
[2011‐Nov‐11 14:18:10 3840|3972] [app] iAU::Context::GetRemoteTree

‐‐‐+ "Product[c22t2202v8.0.0l1p5889r1o1]"
Incremental updates, when possible occur in this step. If incremental updates are not available,
iAU relay writes the following to its log
[2011‐Nov‐11 14:18:10 3840|3972] [app] iAU::MergeOptimize::Optimize
[src\common\src\merge_optimize.cpp(106)]
Read extern for mutil‐merge
IAU_STATUS_UNCLASSIFIED_ERROR[‐1073741824(3,0,0)]
NOTE For an example of a successful merge, see the Incremental update section in
this chapter.
Since an incremental update is not possible in this example, iAU downloads full packages. This is
recorded in the iaurelay.log below
[2011‐Nov‐11 14:18:10 3840|3972] [app] iAU::Context::Duplicate
0 full package(s) will be generated via merge
instead of download.
The DSR begins by downloading the DSR manifest. The following iaurelay.log entries record
this action.
[2011‐Nov‐11 14:18:10 3840|3972] [app] iAU::UriDownloader::GetFile
[src\common\src\uri_downloader.cpp(92)]
Parsing URI :
po/c22t2212l‐1r‐1p‐1o‐1/8.0.585_c01b58b9‐2d70‐4360‐9241‐36fa7370e36e.7z
This corresponds to the following TmuDump.txt entry
Inf 20111111 14:18:10 3840 3972 Connecting ... 96.7.144.158:443
Inf 20111111 14:18:10 3840 3972 Connected!
Inf 20111111 14:18:10 3840 3972 Connected to iaus.activeupdate.trendmicro.com:443
. . .
Inf 20111111 14:18:10 3840 3972 Establish SSL connection OK with peer
Inf 20111111 14:18:10 3840 3972 GET
/activeupdate/preopr/22_2202_8.0.0_1_5889_1_1/ctlrpo/c22t2212l‐1r‐1p‐1o‐
1/8.0.585_c01b58b9‐2d70‐4360‐9241‐36fa7370e36e.7z HTTP/1.1
. . .
Inf 20111111 14:18:10 3840 3972 HttpsConnection: Successful: HTTP 200 OK
Inf 20111111 14:18:10 3840 3972 Successfully wrote [475]B to disk.
Inf 20111111 14:18:10 3840 3972 Successfully wrote cache [475]B, currently cached [475]B.
After successfully downloading a component, the DSR writes the following entry in iaurelay.log
Succeed downloading, remove cache file.
Finish downloading, result:
The DSR downloads the rest of the items in the product index in a similar matter. The following
iaurelay.log entries correspond to the indicated components.
Deep Security Rule Update
Parsing URI :
po/c22t2213l‐1r‐1p‐1o‐1/11.031_aab90948‐ab7d‐4a08‐a0a6‐3e3c462f21f9.7z
TMUFE
Parsing URI :
po/c2t574619648l‐1r‐1p5889o‐1/3.5.1047_51805141‐4b2c‐4afc‐9c26‐e9e59b4f95d4.7z
DS product manifest
Parsing URI :
po/c22t2211l‐1r‐1p‐1o‐1/8.0.0_b2c5a7d7‐2876‐42e2‐8cf9‐777fe8ee17f7.7z
After downloading all relevant components, the DSR moved them to their destination folders.
The following iaurelay.log entries record this action.
[2011‐Nov‐11 14:19:00 3840|3972] [app] iAU::Context::GetPackages
Succeed to get update packages, start to install.
Getting pakcages result:
IAURELAY_STATUS_SUCCESS(1)
STEP 4: GENERATE PRODUCT INDICES
Generating product index and component external
index...
[2011‐Nov‐11 14:19:00 3840|3972] [app] iAU::IndexVisitor::GenerateIndexFile
[src\common\src\visitor.cpp(604)]
save product index to: C:\Program Files\Trend
Micro\Deep Security Relay\relay\iau\c22t2202v8.0.0l1p5889r1o1
Generating common components...
Micro\Deep Security Relay\relay\iau\common_components
[2011‐Nov‐11 14:19:00 3840|3972] [app] iAU::Context::Update [src\relay\src\context.cpp(778)]
Start loading local components information to
memory
[2011‐Nov‐11 14:19:00 3840|3972] [app] iAU::LocalSource::ScanRepository
Initilizing and checking local repository:
C:\Program Files\Trend Micro\Deep Security Relay\relay\iau
Micro\Deep Security Relay\relay\iau\all_components
[2011‐Nov‐11 14:19:00 3840|3972] [app] iAU::Context::Update [src\relay\src\context.cpp(813)]
Local components information loaded
STEP 5: CLEANUP AND FEEDBACK
[2011‐Nov‐11 14:19:00 3840|3972] [app] iAU::Cleaner::CleanPackages
[src\common\src\cleaner.cpp(59)]
Start cleaning packages: C:\Program Files\Trend
Micro\Deep Security Relay\relay\iau\packages
[2011‐Nov‐11 14:19:00 3840|3972] [app] iAU::Cleaner::CleanPackages
End clean packages.
[2011‐Nov‐11 14:19:00 3840|3972] [app] iAU::Cleaner::CleanCache
Start cleaning cache files: C:\Program Files\Trend
Micro\Deep Security Relay\relay\iau\cache
[2011‐Nov‐11 14:19:00 3840|3972] [app] iAU::Cleaner::CleanCache
End clean cach files.
[2011‐Nov‐11 14:19:00 3840|3972] [app] iAU::DataManager::GetInformation
[src\relay\src\data_manager.cpp(29)]
Get the memory space: 00000000057794C0
Duplicate result: IAURELAY_STATUS_SUCCESS(1)
At this point, the iAU relay module submits a result to the Trend Micro update site via an ISAPI
filter on the update server called iau_visibility.dll. It starts the process in with the following entry
in iaurelay.log
[2011‐Nov‐11 14:19:00 3840|3972] [app] iAU::FeedbackProtocolbuffer::UploadReport
[src\common\src\feedback_protocolbuffer.cpp(98)]
Post the feedback report return true
[2011‐Nov‐11 14:19:00 3840|3972] [app] iAU::Sdk::GetStatusMessage
[src\relay\src\sdk.cpp(149)]
The connection attempt with the update server appears in TmuDump.txt as follows:
Inf 20111111 14:19:00 3840 3972 Connecting ... 150.70.74.55:80
Inf 20111111 14:19:00 3840 3972 Connected!
Inf 20111111 14:19:00 3840 3972 POST /iau_visibility.dll HTTP/1.1
Host: iaufdbk.trendmicro.com
Accept: */*
X‐Trend‐ActiveUpdate: 6.3.1043
pragma: akamai‐x‐cache‐on
XEtag: 3ec37aea‐e1ae‐4656‐85ee‐3b2f6ebfe5c9
Connection: Keep‐Alive
Content‐Length: 435
Inf 20111111 14:19:00 3840 3972 HTTP request headers send OK
Inf 20111111 14:19:00 3840 3972 [173]B of [213]B is parsed as response header
Inf 20111111 14:19:00 3840 3972 HTTP/1.1 200 OK
Date: Fri, 11 Nov 2011 22:19:03 GMT
Server: Apache/2.2.17 (Unix)
Connection: close
Transfer‐Encoding: chunked
Content‐Type: text/html; charset=UTF‐8
Inf 20111111 14:19:00 3840 3972 HttpConnection: Connect to source success
Phase 2: Self update

At this point, the DSR downloads components, for its own use, from its own Web server. This
phase can be broken down into the following steps:
• Step 1: Determine the components currently in use
• Step 2: Determine the components available on the update site
• Step 3: Compare the components
• Step 4: Obtain components when necessary
• Step 5: Move components to destination folder
• Step 6: Cleanup and feedback
STEP 1: DETERMINE THE COMPONENTS CURRENTLY IN USE

This phase begins with the DSR reading its Product.xml file to acertain the versions of
components on the host. This appears on the DSR iau.log as follows:
[2011‐Nov‐11 14:19:00 3840|3972] [app] iAU::Core::IAU_Update [src\core\src\sdk.cpp(739)]
updating with input products information:
<product_information version="1.0"><products id="c22t2202v8.0.0l1p5889r1o1"><product
id="c22t2202v8.0.0l1p5889r1o1"><path>C:\Program Files\Trend Micro\Deep Security
Relay\lib</path><install>C:\Program Files\Trend Micro\Deep Security
Relay\lib</install><components><component version="0" oem="‐1" region="‐1" platform="‐1"
type="2212" class="22" language="‐1"><install>C:\Program Files\Trend Micro\Deep Security
Relay\lib/resource/c%(class)t%(type)/%(version)</install></component><component
version="0" oem="‐1" region="‐1" platform="‐1" type="2211" class="22" language="‐
1"><install>C:\Program Files\Trend Micro\Deep Security
version="0" oem="‐1" region="‐1" platform="‐1" type="2213" class="22" language="‐
1"><install>C:\Program Files\Trend Micro\Deep Security
version="3.5.1047" oem="‐1" region="‐1" platform="5889" type="574619648" class="2"
language="‐1"><install>C:\Program Files\Trend Micro\Deep Security
Relay\lib/resource/c%(class)t%(type)/%(version)</install></component></components></produc
t></products></product_information>
Begin to update...
Note that Product.xml also contains information about where components are stored on the
DSR. This information will be used in step 5.
Next, the iAU module creates various temporary folders for its cache and download folders.
Actions related to this are labeled “Auto control the path”. An example appears below.
[2011‐Nov‐11 14:19:00 3840|3972] [app] iAU::DirectoryManager::DirectoryManager
Auto control the path : C:\Program Files\Trend
Micro\Deep Security Relay\lib\iaudata\iau_5AA21871‐EE90‐4937‐B591‐6F5253D070D9\download
Max size is : 157286400
Force size is : 1073741824
As with the first step of phase 1, the iAU module also assigns an x-tag to this instance of the iAU
module. If this tag is missing, it generates this file. The following log records this action.
Unable to get xtag from local: "C:\Program
Files\Trend Micro\Deep Security Relay\lib\iauclient.xtag", this is fresh install.
Generating the uuid because of no xtag: c87d2878‐
b60b‐4306‐8c13‐bb8a8ede421b
Using the product information parsed from Product.xml, the product generates the product local
tree in this step. This summarizes with iAU “knows” about the components that its host product
is using.
Product local tree:

‐‐‐+ "Product[c22t2202v8.0.0l1p5889r1o1]"
STEP 2: DETERMINE THE COMPONENTS AVAILABLE ON THE UPDATE SITE

As in the previous phase, the iAU module downloads a product index. This is recorded in iau.log
below. This time, however, it downloads the product index from the DSR update folder.
Try to get index from product
index:c22t2202v8.0.0l1p5889r1o1
c22t2202v8.0.0l1p5889r1o1
c22t2202v8.0.0l1p5889r1o1
Query URI :
https://localhost:4122/c22t2202v8.0.0l1p5889r1o1
The product index that it downloads from itself is similar to the index from the update site. The
principal difference is that the URL to component points to the DSR’s package folder. A sample
entry from this index appears below.
<entity class="22" language="‐1" oem="‐1" platform="‐1" region="‐1" type="2212"
version="8.0.585">
<priority>2</priority>
<applyto maxver="8.0.585" minver="0"></applyto>
<full dig="3aaac579b7bcecab75406299085a7300" size="475">
<url>packages\8.0.585_c01b58b9‐2d70‐4360‐9241‐36fa7370e36e.7z</url>
<last_modify_time>20111111T221810</last_modify_time>
</full>
</entity>
STEP 3: COMPARE THE COMPONENTS

DSR compares local data with product index, and determines that three updates are required.
The following iau.log entries record this action.

‐‐‐+ "Product[c22t2202v8.0.0l1p5889r1o1]"
There are 3 component(s) need update
STEP 4: OBTAIN COMPONENTS WHEN NECESSARY

The previous step identified three components for update. The iAU module cycles through the
components, creating entries like the following in the iAU log for each component.
Parsing URI :
https://localhost:4122/packages/8.0.585_c01b58b9‐2d70‐4360‐9241‐36fa7370e36e.7z

Downloading from a remote URL.
STEP 5: MOVE COMPONENTS TO DESTINATION FOLDERS

In this step, the various updates are moved to their destination folders where the DSR will use
them. This is recorded in the DSR iau.log as appears below.
[2011‐Nov‐11 14:19:06 3840|3972] [app] iAU::Context::GetPackages
Succeed to get update packages, start to install.
The following log sample is an update summary, written further down in the DSR iau.log, that
shows how the DSR knows where destination folders are:
<components>
<component class="22" type="2212" version="0"
language="‐1" platform="‐1" region="‐1" oem="‐1"
update_class="22" update_type="2212"
update_version="8.0.585"
update_language="‐1" update_platform="‐1"
update_region="‐1" update_oem="‐1">
<status>0</status>
<install>C:\Program Files\Trend Micro\Deep Security
Relay\lib/resource/c22t2212/8.0.585</install>
</component>
This is information was parsed from Product.xml, and shows that the
destination folders named after the component’s product code, and are all
under the . . ./lib/resource folder on the DSR.
STEP 6: CLEANUP AND FEEDBACK

In this step, the iAU module sends the update result to the DSR, and then cleans up temporary
files. This step starts with the following DSR iau.log entry
Update finished with result :
[2011‐Nov‐11 14:19:07 3840|3972] [app] iAU::FeedbackProtocolbuffer::~FeedbackProtocolbuffer
[src\common\src\feedback_protocolbuffer.cpp(57)]
Feedback returned without information saved
because of feeback disabled.
Next, the DSR deletes files that were generated during the update, but are not longer used. The
following iau.log entries record this action.
[2011‐Nov‐11 14:19:07 3840|3972] [app] iAU::DirectoryManager::Cleanup
Start to cleanup the directory : C:\Program
Files\Trend Micro\Deep Security Relay\lib\iaudata\iau_5AA21871‐EE90‐4937‐B591‐
6F5253D070D9\index
End clean up the directory.
6F5253D070D9\feedback
6F5253D070D9\temp
FileOperations(RemoveFile)Directory size is larger
than 0 , remove this folder.
6F5253D070D9\download
This phase ends with the iau module preparing a summary of the update that it sends to DSR.
[2011‐Nov‐11 14:19:07 3840|3972] [app] iAU::Core::IAU_SetWideString
[src\core\src\sdk.cpp(194)]
succeed to set data into data handle : "
Phase 3: Trend-to-DSR duplicate

In this phase, the DSR downloads the components that it makes available to the Deep Security
network.
Download DSA product index, contains data for AMSP, DSRU, TMUFE
[2011‐Nov‐11 14:19:07 3840|2064] [app] iAU::Sdk::GetInformation [src\relay\src\sdk.cpp(583)]
Download DSA Windows 64-bit product index, AMSP, DSRU, TMUFE
c22t2200v8.0.0l1p5889r1o1
c22t2200v8.0.0l1p5889r1o1
Download DSVA product index
c22t2201v8.0.0l1p9217r1o1
c22t2201v8.0.0l1p9217r1o1
Download DSR product index
Query index for protocol : c22t2202v8.0.0l1p1r1o1
c22t2202v8.0.0l1p1r1o1
. . .
Index server return : 16
Etag is not modified, use the etag file in local
cache.
Use the index file in local cache.
Query successfully
Linux DSR product file
c22t2202v8.0.0l1p9217r1o1
c22t2202v8.0.0l1p9217r1o1
Analyze product indices
0 full package(s) will be generated via merge
instead of download.
Download files
Duplicate result: IAURELAY_STATUS_SUCCESS(1)
Phase 4: DSR-to-AMSP update

The steps in this phase a identical to an iAU client update that occurs on a DSA. For additional
details on what happens in this step, see the Updating DSA section.
A.10.4 Legacy ActiveUpdate mechanism

DSM version 8.0 retains the update legacy ActiveUpdate mechanism to permit backward
compatibility with DSVA version 7.5. These appliances still need to obtain their updates from
the DSM. This section focuses on troubleshooting information for this technology and is divided
into the following topics:
● Updating the DSM
If version 7.5 DSVAs are not registered with a DSM, then these logs and procedures will not be
present.
Understanding update logs

The ActiveUpdate module records all its action in a log file “TmuDump”. That makes this file a
very important source of troubleshooting information. Depending on how the AU module is
configured, this log can be written as a text file (TmuDump.txt) or as an HTML file.
The log is an excellent source of information about what files the AU module attempted to
download, and the result of those attempts. The log doesn’t actually identify the components by
name, and instead uses hexadecimal numbers as component identifiers.
Take for example the virus pattern file (lpt$vpn). The code for this pattern would be
“item[3][4][0][0]”. The following table explains what these numbers mean.
Code Code location Description
Download class ActiveUpdate recognizes three component classes

Item[3][4][0][0]
Code Class
1 Products, patch agents, and patch files
2 Scan engines (e.g., VSAPI, DCE, etc.)
3 Pattern files (e.g., virus patterns, etc.)
This value sets the context for the other parts of

the code.
Component type This represents the specific component being

Item[3][4][0][0]
downloaded. Its actual meaning depends on the
download class. In this example, since the
download class is for the pattern, “4” refers to the
virus pattern
Language type This is the language version of the component.

Item[3][4][0][0]
This is only relevant for the product download
class.
Platform type This identifies the platform, or operating system,

Item[3][4][0][0]
of the component. This is only relevant for the
product download class.
Updating the DSM

The DSM update process can be divided into two parts:
● Part one: Obtain information for update wizard
● Part two: Update components
This section will present debug log entries that are relevant to these parts of the update process.
Entries are taken from the following logs:
Server0.log – Java-based debug log for the DSM. In the samples listed below, these are
entries that use a Month Day, Year format and a 12-hour time stamp
TmuDump.txt – debug log for the ActiveUpdate module. These use a YYYYMMDD date
format, and a 24-hour time stamp
NOTE Although the logs are presented in their correct sequence, the specific samples
may be taken from separate update events.
PART ONE: OBTAIN INFORMATION FOR UPDATE WIZARD

The ActiveUpdate wizard uses TmuUpdate ( ) to download the server definition file (server.ini)
to determine the components available on the update site.
Inf 20101029 13:51:02 2412 4620 Start TmuUpdateEx()
Inf 20101029 13:51:02 2412 4620 Downloader: retry = 3, timeout = 120:120:1, cache path is:
[C:\Program Files\Trend Micro\Deep Security Manager\au\bin\win64\AU_Data\AU_Cache]
Inf 20101029 13:51:02 2412 4620 CacheCleaner: CacheTTL = 7 Day,MaxCacheSize = 50 MB.
Inf 20101029 13:51:02 2412 4620 Dump parameters:
SourceInfo[http://tmds75‐
p.activeupdate.trendmicro.com/activeupdate]
. . .
Inf 20101029 13:51:02 2412 4620 Downloading [http://tmds75‐
p.activeupdate.trendmicro.com/activeupdate/
ini_xml.zip] to [C:\Program Files\Trend Micro\Deep Security
Manager\au\bin\win64\AU_Data\AU_Temp\2412_4620\ini_xml.zip]...
. . .
Inf 20101029 13:51:02 2412 4620 End TmuUpdateEx()
However, the actual decision logic is contained within DSM, and the AU module is simply used
as a means to download server.ini. In this part of the process the DSM compares the file
information in the definition file with the component information in its database and makes a
determination if an update is required.
PART TWO: UPDATE COMPONENTS

Once the need for an update is ascertained, the update wizard begins the second part of the
update process which is illustrated below.
The update wizard downloads each component using distinct TmuDuplicate( ) calls. The
following log excerpt, for example, show the portion related to the download of the Smart Scan
agent pattern (icrc$oth / 0x48020000).
Inf 20100810 18:33:52 1636 10712 Start TmuDuplicateEx()
Inf 20100810 18:33:53 1636 10712 Downloader: retry = 3, timeout = 120:120:1, cache path is:
[C:\Program Files\Trend Micro\Deep Security Manager\au\bin\win32\AU_Data\AU_Cache]
Inf 20100810 18:33:54 1636 10712 CacheCleaner: CacheTTL = 7 Day,MaxCacheSize = 50 MB.
Inf 20100810 18:33:55 1636 10712 Dump parameters:

SourceInfo[http://beta.external.trendmicro.com/activeupdate/tmds75]
useProxy[FALSE] nOption[0x0]
Item[0]:
class[3](Pattern) type[0x48020000] language[L1] platform[P0] action[0x40]
destination[C:\Program Files\Trend Micro\Deep Security Manager\au\content\]
original version[0] result version[0]

< ‐‐‐ Download related log entries here ‐‐‐ >

Inf 20100810 18:41:29 1636 10712 before UpdateManager end, version info in items:
items[0] ([3][0x48020000][L0][P1]): 737100 ‐> 737300
Inf 20100810 18:41:30 1636 10712 Release dynamic link library[C:\Program Files\Trend
Micro\Deep Security Manager\au\bin\win32\patchw32.dll]
Inf 20100810 18:41:31 1636 10712 End TmuDuplicateEx()
Note that this TmuDuplicate( ) call is specific to the Smart Scan agent pattern. Each component
that the update wizard downloads will have its own section shown above.
Each phase in the flowchart above is discussed in its own section below. To facilitate discussion,
the log samples here will be restricted to the Smart Scan agent pattern.
Phase 1: Load module and create context

In this phase, the DSM loads the ActiveUpdate module in preparation for the update operation.
It begins with the following entry in the DSM log:
Aug 13, 2010 3:00:14 PM com.thirdbrigade.manager.core.au.ActiveUpdateUtilities
getLatestComponentInfo
FINE: Init the TmuLoader with: C:\Program Files\Trend Micro\Deep Security
Manager\au\bin\win32\
This corresponds to the following log entry in the AU log:
Inf 20100813 15:00:15 13140 13228 Load 32 bit AU 2.82.0.1099 from: [C:\Program Files\Trend
Micro\Deep Security Manager\au\bin\win32\]
Note the following noteworthy details in both logs:

● The ActiveUpdate module is stored in the DSM folder, particularly under . . .\au\bin\win32
● The version of the AU module currently in-use is version 2.82, build 1099
Once loaded into memory, the DSM proceeds to create a data structure called a “context” where
the version comparisons are made.
Context creation is recorded on the DSM log as follows
getLatestComponentInfo
FINE: Create a context...
This corresponds to the following AU log.
Inf 20100813 15:00:15 13140 13228 Start TmuCreateContext()
Inf 20100813 15:00:15 13140 13228 new context for thread: 13228
Inf 20100813 15:00:15 13140 13228 End TmuCreateContext()
In preparation for the download itself, the ActiveUpdate module creates a temporary directory as
shown below.
Inf 20100810 18:33:56 1636 10712 Creating Temp dir [C:\Program Files\Trend Micro\Deep
Security Manager\au\bin\win32\AU_Data\AU_Temp\1636_10712]
NOTE Among the four phases in this part of the update process, Phase one is the only
one that is not repeated for each component.
Phase 2: Determine required components

Although the DSM already confirmed the need for the component that is being downloaded in
Part one, the ActiveUpdate module itself needs to know that the component is actually
necessary, so the server definition file (server.ini) is downloaded again for version verification.
This phase consists of the following steps:
● Step one: Download server definition file
● Step two: Identify required updates
Step one: Download server definition file

Each TmuDuplicate( ) call begins with the ActiveUpdate module downloading a server
definition file. As mentioned earlier, this is standard part of the AU process.
The actual file that it downloads is named ini_xml.zip, as shown below.
Inf 20100810 18:33:56 1636 10712 Downloading
[http://beta.external.trendmicro.com/activeupdate/tmds75/
ini_xml.zip] to [C:\Program Files\Trend Micro\Deep Security
Manager\au\bin\win32\AU_Data\AU_Temp\1636_10712\ini_xml.zip]...
. . .
Inf 20100810 18:34:06 1636 10712 Successfully wrote [1677]B to disk.
Inf 20100810 18:34:08 1636 10712 Unzipping... [C:\Program Files\Trend Micro\Deep Security
Manager\au\bin\
win32\AU_Data\AU_Temp\1636_10712\ini_xml.zip] to
[C:\Program Files\Trend Micro\Deep Security
Manager\au\bin\win32\AU_Data\AU_Temp\1636_10712]
Inf 20100810 18:34:09 1636 10712 Unzip return [0]
Step two: Identify required updates

Once the definition file is extracted from the zip file, it is analyzed to obtain version information,
and to ascertain the availability of incremental components. This is recorded in the following log
entries
Inf 20100810 18:34:09 1636 10712 [UPAU]Serverini Analyzer Init: C:\Program Files\Trend
Micro\Deep Security Manager\au\bin\win32\AU_Data\AU_Temp\1636_10712\server.ini
Inf 20100810 18:34:09 1636 10712 [UPAU]Expand Item:[3][0x48020000][L1][P0]
Inf 20100810 18:34:10 1636 10712 [UPAU]Add item:[3][0x48020000][L0][P0]
Inf 20100810 18:34:10 1636 10712 [UPAU]Expand item successfully!
Inf 20100810 18:34:10 1636 10712 [UPAU]Expand item success input item class=3
type=0x48020000 language=1 platform=0. Expand to 1 item(s)
Inf 20100810 18:34:10 1636 10712 [UPAU]find item[3][0x48020000][L0][P0] info (for
dup)version: 737300 version is 737300(description is not available)
Inf 20100810 18:34:10 1636 10712 ready to copy C:\Program Files\Trend Micro\Deep Security
Manager\au\content\
server.ini ‐> C:\Program Files\Trend Micro\Deep Security
Manager\au\bin\win32\AU_Data\AU_Temp\1636_10712\server.ini.tmp
Inf 20100810 18:34:10 1636 10712 Retry Counter: 1
Inf 20100810 18:34:10 1636 10712 [LOLD]Serverini Analyzer Init: C:\Program Files\Trend
Micro\Deep Security Manager\au\content\server.ini
Inf 20100810 18:34:10 1636 10712 [LNEW]Serverini Analyzer Init: C:\Program Files\Trend
Micro\Deep Security Manager\au\bin\win32\AU_Data\AU_Temp\1636_10712\server.ini.tmp
Since the need for the update had already been ascertained in Part One of the update process,
the result of version of analysis will always show that an update is required. Analysis results are
written to the log as shown below.
Inf 20100810 18:34:10 1636 10712 Duplicate Processing: item[3][0x48020000][L0][P0]
Inf 20100810 18:34:11 1636 10712 [LOLD]find item[3][0x48020000][L0][P0] info (for
dup)version: 737100 version is 737100(description is not available)
Inf 20100810 18:34:11 1636 10712 local version is lower than server. Dup it.
Phase 3: Download component

This phase in the update process begins with the following entry in the TmuDump.txt file.
Inf 20101029 13:51:12 2412 2236 ActiveUpdate start download patch files...
It can be divided into the following steps:
● Step one: Download DSM-update component

● Step two: Download additional incremental components
● Step three: File verification
● Step four: Update preparation
● Step five: Delete out-of-date files
● Step six: Copy to destination folder
Each step will be explained further in the sections below.
Note that the debug logs in this example were taken from a fresh DSM installation, so the full
and incremental patterns were downloaded, the former being the “latest pattern”.
Step one: Download DSM-update component

The “DSM-update component” refers to the update that the DSM needs to ensure that it has the
latest full pattern. This is an important distinction since the DSM also downloads components
that it simply makes available to its DSVAs without further processing.
For fresh installations, the incremental updates that are on the update site will, in most instances,
no longer be sufficient to update the full pattern that is included with the DSM installation
package. So the first update will usually involve a full pattern, like the following:
p.activeupdate.trendmicro.com/activeupdate/
pattern/icrc/ioth757900.zip] to [C:\Program Files\Trend Micro\Deep Security
Manager\au\bin\win64\AU_Data\AU_Temp\2412_2236\AU_Down\pattern\icrc\
ioth757900.zip]...
Inf 20101029 13:51:12 2412 2236 Connecting ... 10.x.xx.35:8080
Inf 20101029 13:51:12 2412 2236 Connected!
Inf 20101029 13:51:12 2412 2236 GET http://tmds75‐
p.activeupdate.trendmicro.com:80/activeupdate/pattern/
icrc/ioth757900.zip HTTP/1.1
Host: tmds75‐p.activeupdate.trendmicro.com:80
Accept: */*
Pragma: No‐Cache
Cache‐Control: no‐store, no‐cache
Connection: Close
X‐Trend‐ActiveUpdate: 2.82.0.1099
The sample above contains the following noteworthy points:

● The full pattern being downloaded is the Smart Scan agent pattern, version 579. This is
being downloaded in zip format
● The DSM is connecting via an Internet proxy at address 10.x.x.35 at port 8080
● The update source is: tmds75-p.activeupdate.trendmicro.com
If the DSM is able to get regular updates, then it would only need an incremental pattern to
update itself, and this section would look more like this
Inf 20100810 18:34:26 1636 10712 Downloading
[http://beta.external.trendmicro.com/activeupdate/tmds75/
pattern/ioth_737100.737300] to [C:\Program Files\Trend Micro\Deep Security
Manager\au\bin\win32\AU_Data\AU_Temp\1636_10712\AU_Down\pattern\ioth_737100.
737300]...
In the log extract above, the DSM is downloading an incremental pattern that can update Smart
Scan pattern version 371 to version 373.
Step two: Download additional incremental components

After the DSM-update component is downloaded, the DSM proceeds to obtain incremental
update patterns. By design, the DSM is always able to offer incremental updates for up to 14
older versions of a particular pattern file.
This step is written as follows in the ActiveUpdate log
. . .
p.activeupdate.trendmicro.com/activeupdate/pattern/icrc/ioth_757700.757900] to [C:\Program
Files\Trend Micro\Deep Security
Manager\au\bin\win64\AU_Data\AU_Temp\2412_2236\AU_Down\pattern\icrc\ioth_757700.757900]...
. . .
. . .
p.activeupdate.trendmicro.com/activeupdate/pattern/icrc/ioth_755100.757900] to [C:\Program
Manager\au\bin\win64\AU_Data\AU_Temp\2412_2236\AU_Down\pattern\icrc\ioth_755100.757900]...
As in the previous steps, this ActiveUpdate log extract comes from a fresh DSM installation. It
shows the DSM downloading 14 incremental updates, that update versions 551 to 577 to version
579.
Step three: File verification

After downloading all relevant files the ActiveUpdate module verifies each file. This process is
recorded in ActiveUpdate logs as shown below.
Inf 20101029 13:53:41 2412 2236 Download all patch files success, checking ...
Inf 20101029 13:53:41 2412 2236 Check [C:\Program Files\Trend Micro\Deep Security
Manager\au\bin\win64\AU_Data\AU_Temp\2412_2236\AU_Down\pattern\icrc\ioth757900.zip], size
[15048223] B
. . .
Inf 20101029 13:53:41 2412 2236 Check [C:\Program Files\Trend Micro\Deep Security
Manager\au\bin\win64\AU_Data\AU_Temp\2412_2236\AU_Down\pattern\icrc\ioth_755100.757900],
size [84948] B
Inf 20101029 13:53:41 2412 2236 Check over, All files are OK.
Step four: Update preparation

This step only takes place if the patterns on the DSM can still be updated using the incremental
updates available on the update site. This is recorded in the ActiveUpdate logs as shown below.
Inf 20100810 18:40:16 1636 10712 RTPatchApply32: cmd: ‐NoPathSearch ‐NOALLOWSPLIT
"C:\Program Files\Trend Micro\Deep Security
Manager\au\bin\win32\AU_Data\AU_Temp\1636_10712\DupMerge\3\1208090624" "C:\Program
Manager\au\bin\win32\AU_Data\AU_Temp\1636_10712\AU_Down\pattern\ioth_737100.737300"
Inf 20100810 18:40:16 1636 10712 Code page before calling RTPatch APIs: ANSI
Inf 20100810 18:40:49 1636 10712 RTPatchApply32: ret: 0
Inf 20100810 18:40:49 1636 10712 Compress [C:\Program Files\Trend Micro\Deep Security
Manager\au\bin\win32\AU_Data\AU_Temp\1636_10712\DupMerge\3\1208090624] to [C:\Program
Manager\au\bin\win32\AU_Data\AU_Temp\1636_10712\AU_Down\pattern\ioth737300.zip]...
Inf 20100810 18:40:59 1636 10712 Compression finished!
In the sample above, the incremental update was used to update Smart scan agent pattern
version 371 was updated to version 373. The merged pattern is initially stored in a sub-folder
under AU_Temp.
Step five: Move files to their destination folders

This step involves the copying of the updates from AU_Temp to their final destinations under
the DSM \au\content folders. The following ActiveUpdate log entries record copy-stage of this
step
Inf 20101029 13:53:41 2412 2236 ready to copy C:\Program Files\Trend Micro\Deep Security
Manager\au\bin\win64\AU_Data\AU_Temp\2412_2236\server.ini.tmp ‐> C:\Program Files\Trend
Micro\Deep Security Manager\au\content\server.ini
Inf 20101029 13:53:41 2412 2236 deleting out of date files...
Inf 20101029 13:53:41 2412 2236 copying [C:\Program Files\Trend Micro\Deep Security
Manager\au\bin\win64\AU_Data\AU_Temp\2412_2236\AU_Down\pattern\icrc\ioth757900.zip] ‐>
[C:\ Program Files\Trend Micro\Deep Security
Manager\au\content\pattern\icrc\ioth757900.zip]
Inf 20101029 13:53:42 2412 2236 there is no dsc file[C:\Program Files\Trend Micro\Deep
Security
Manager\au\bin\win64\AU_Data\AU_Temp\2412_2236\AU_Down\pattern\icrc\ioth757900.dsc],
ignore it.
Inf 20101029 13:53:42 2412 2236 copying [C:\Program Files\Trend Micro\Deep Security
Manager\au\bin\win64\AU_Data\AU_Temp\2412_2236\AU_Down\pattern\icrc\ioth_757700.757900] ‐>
[C:\ Program Files\Trend Micro\Deep Security
Manager\au\content\pattern\icrc\ioth_757700.757900]
. . .
The excerpt above contains the following noteworthy points:
● The server.ini that DSM downloads from the update site is used as a replacement for its
existing definition file that DSVAs access when performing their own updates
● The full Smart scan pattern version 579 is transferred to the pattern\icrc folder. Regardless
of whether or not the full pattern is the product of an incremental update, or is downloaded
as a full pattern from the update site, its initial storage location will always be AU_Temp. So
the file-copy action shown above will occur in both situations.
● Incremental updates, in this case the update for Smart scan pattern version 577 to 579, is
copied to the \pattern\icrc folder
Step 6: Delete AU_Cache entries

Once the files have been moved to their destination folders, the ActiveUpdate module deletes
the contents of AU_Cache to complete the update process. The following ActiveUpdate log
entries record this step.
Inf 20101029 13:53:42 2412 2236 Flag "keep_cache_file_on_success" in configuration file is
off.
Inf 20101029 13:53:42 2412 2236 Cache Cleaner Action: Remove cached files.
Inf 20101029 13:53:42 2412 2236 Remove cached file[ioth757900.zip] in folder [tmds75‐
p.activeupdate.trendmicro.com\]
Inf 20101029 13:53:42 2412 2236 Remove etag file[ioth757900.zip.etag] in folder [tmds75‐
Inf 20101029 13:53:42 2412 2236 Remove cached file[ioth_757700.757900] in folder [tmds75‐
Inf 20101029 13:53:42 2412 2236 Remove etag file[ioth_757700.757900.etag] in folder [tmds75‐
. . .
Inf 20101029 13:53:42 2412 2236 Remove cached file[ioth_755100.757900] in folder [tmds75‐
Inf 20101029 13:53:42 2412 2236 Remove etag file[ioth_755100.757900.etag] in folder [tmds75‐
Inf 20101029 13:53:42 2412 2236 Cache Cleaner Action: Remove cached files end.
Inf 20101029 13:53:42 2412 2236 Cleanning Temp dir [C:\Program Files\Trend Micro\Deep
Security Manager\au\bin\win64\AU_Data\AU_Temp\2412_2236]
Phase 4: Notify other DSM nodes

DSMs in a multi-node arrangement will download their updates from the DSM that obtained
their updates from the update site. The DSM that performs the initial update sends notifications
to other nodes after downloading each component.
The DSM debug log records this event as shown below.
duplicateComponentsFromAU
FINE: AU Components have changed, will update internals and notify other managers.
. . .
setAUSequenceNumber
FINE: Setting AU sequence number to: 15
. . .
Appendix B: Key concepts and

threat map
B.1 > Appendix overview

The following appendix discusses the following topics that readers must have already learned
from pre-requisite courses.
● Key networking concepts
● Types of attacks
● Anatomy of the an attack
● Mapping features to threats
B.2 > Key networking concepts

To fully appreciate the capabilities of the various Deep Security features, readers must be
thoroughly familiar with the following networking concepts.
● Packet fragmentation
● TCP flags
Although these have already been introduced in the Protocol review section of Chapter 1 of the
Administrator Track document, these are re-explained here to introduce samples and analogies
that will be used throughout this chapter.
B.2.1 Packet fragmentation

Packet fragmentation is important concept to understand when discussing Deep Security. For
this reason, this section will offer a high-level review of the concept, and will present a standard
analogy that will be used throughout the traffic-analysis discussion.
INTRODUCTION TO OSI LAYERS AND NETWORKING BASICS

An introduction to the OSI layers and networking basics is provided in the Deep Security
and Intrusion Defense Firewall Administrator Track manuals. In both documents, this
information can be found in Chapter 1, Section 1.1 Protocol review.
Readers of this document are expected to be already familiar with these concepts. This
packet fragmentation discussion is merely a refresher.
Fragmentation is a normal consequence of data traversing the Network and Data Link OSI
layers of the network stack. The protocols at these two layers have prescribed sizes for the
protocol data units/datagrams/packets that they handle. So if the data unit from the higher-level
layer is larger than what the lower layer supports, which is typically the case, then fragmentation
is the inevitable result.
Consider the following representation of a packet that contains a malicious instruction designed
to exploit a particular vulnerability in an application:
Do_Something_Bad
NOTE In real-life, this could take the form of malicious shellcode or scripts designed to
exploit a buffer overflow or cross-site scripting vulnerability.
The instruction issued from an “attack” machine, to a “victim” machine as shown below. Once
the packet reaches Computer 2, normal protocol stack processes will direct the message it
contains, to the vulnerable application which then executes the harmful instruction.
Computer 1 (Attacker) Computer 2 (Victim)
Application
Malicious instruction:
Vulnerability
Do_Something_Bad
Protocol Protocol
stack stack
For purposes of this analogy, we shall assume that the Transport and Network layers of the
protocol stack use a fictitious protocol that behaves somewhat like TCP/IP, and another
fictitious protocol that works at the Data Link layer.
Protocols in a protocol stack “know” the requirements of the protocols of the layers below
them. In this fictitious stack, the Data Link layer protocol prescribes that its protocol data unit
will only accept one letter at a time. As a consequence, the Network layer protocol fragments the
packet, and assigns sequence numbers to each letter of the message, as shown below.
#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16
Do _ S o m e t h i n g _ B a d
Where once there was a single TCP-like protocol packet, now there are sixteen individual
fragments, each of which will be encapsulated in the Data Link layer protocol’s protocol data
unit (PDU), and then sent individually to Computer 2.
Since the PDUs are sent individually, transient network conditions can result in each PDU
arriving at Computer 2 in a completely different order from when they were sent. For this
analogy, let’s assume they arrive in the following order:
#6 #10 #11 #8 #3 #15 #1 #2 #14 #7 #13 #12 #5 #4 #9 #16
m i n t _ a Do B e _ g oSh d
Protocols at the Data Link layer normally treat the packets as individual entities -- with no regard
to their sequence or relationships. However at the Transport layer, the fragments are collected,
re-arranged according to their sequence number, and then the original packet is reassembled.
Once a malicious packet is re-assembled, the application is then able to read the malicious
instruction.
NOTE Although this analogy focuses on a vulnerability exploit, there are a multitude of
other threats that Deep Security can address.
B.2.2 TCP flags and states

TCP flags and connection states are important concepts to remember when discussing Deep
Security firewall, DPI, and stateful configuration features.
B.2.3 Connection establishment and the SYN and ACK flags

If a host seeks to establish a TCP connection with another host, it performs the 3-way
handshake shown below.
Client state
Client Server Server state
CLOSED CLOSED
Passive open
LISTEN
Establish connection Wait for client
SYN SENT Send SYN (Seq# N)

Acknowledge receipt
Wait for of SYN message and
acknowledgement SYN-RECEIVED
establish connection
with client
Send SYN (Seq# Y)+ACK (Seq# N+1)
Receive Wait for

acknowledgement and acknowledgement
send acknowledgement
ESTABLISHED Send ACK (Seq# Y+1)
Receive
acknowledgement
ESTABLISHED
The diagram above shows how two important message flags are used:
SYN – hosts exchange this type of message to initiate a connection with each other.
ACK – after receiving each other’s SYN messages, they each respond with an ACK message
as an acknowledgement. Upon receipt of the ACK message, the host switches to an
“Establish” state, indicating that it is open for messages from the other host.
“SYN” is short for “synchronize”. This initial message results in the exchange of information
required for the TCP connection to work reliably. Included in this information exchange are
sequence numbers that both hosts expect the other host to use in their messages. For example,
the first SYN message has a sequence number N. The client host, therefore, would expect that
its ACK message to have the sequence number “N+1”.
B.2.4 Terminating connections and the FIN flag

When a fully functional TCP connection between two hosts exists, both hosts are in an
“Established” state and are both waiting for, sending, or receiving packets from one another.
Host 1 state
Host 1 Host 2 Host 2 state
Awaiting message Awaiting message
To completely terminate a connection, the TCP protocol requires both hosts transition to a
“Closed” state, and to notify the other host about this transition by exchanging FIN messages.
The transition process, and the different TCP states the connection goes through, is shown
below.
NOTE The Deep Security Agent is able to monitor how long a TCP connection stays in
a particular TCP state during termination. To fully appreciate this capability, these states
are discussed here.
Host 1 state
Host 1 Host 2 Host 2 state
Initiate termination
FIN
Receive FIN
Wait for
FIN-WAIT-1
acknowledgement CLOSE WAIT
Close application
using connection
ACK
FIN-WAIT-2 Receive ACK

Wait for
application to
close
LAST ACK
Wait for FIN from Application ready
Host 2 to close, send FIN
FIN
Wait for ACK to

TIME WAIT Receive FIN, send FIN
ACK
ACK
Wait for Double Receive ACK CLOSED

Maximum
Segment Life
(MSL) Time
CLOSED
Neither side of the communication considers the communication completely closed until it
receives an ACK message that acknowledges receipt of the FIN message.
B.3 > Types of attacks

Cyber attacks can be loosely divided into the following broad classifications:
● Passive attack
● Active attack
Both can result in similar types of damage, and differ mainly in victim selection. The first attack
is opportunistic, whereas the second is targeted. However information gleaned from a victim in
passive attacks can result in subsequent active attacks on the same victim.
B.3.1 Passive attack

Passive attacks are essentially equal-opportunity attacks that are crafted without a specific victim
in mind. Often, but not in all cases, these rely on social engineering to trick the victim into
initiating the self-inflicted attack.
These types of attacks are beyond the scope of Deep Security, and the principal defensive tools
against them are:
● End-user training and threat awareness initiatives (e.g. do not click on an email attachment
with “exe” and “com” extensions)
● Web-threat protection products
● URL filtering products
● Messaging security products
Tip For information about the product-based solutions above, refer to Support Track
documentation for Trend Micro OfficeScan 8.x or later, the ScanMail and IM Security
family or products, and the InterScan family of products.
B.3.2 Active attack

Active attacks are targeted attacks that begin with the attacker deliberately probing for gaps in
the intended victim’s protection. These are the types of attacks for which Deep Security was
designed.
The next section discusses how such attacks take place. Details about how Deep Security
addresses the different steps in an active attack are discussed in Defending against the attack on
page 111.
B.4 > Anatomy of an attack

While the hacking process is an art form, the basic
steps that a hacker/cracker typically performs on the
target machine can be broken down into the Step 1: Finding a point of entry
following steps:
Step 2: Gaining access
● Step 1: Finding a point of entry
Step 3: Performing
● Step 2: Gaining access the attack
● Step 3: Performing the attack
NOTE This section should not be

misconstrued as a how-to-hack-a-network
section. These steps are merely representative
of the tasks that a hacker must accomplish to
perform the attack. Exactly how they are
accomplished will vary according to the
preferences of the hacker, and the nature of
the target network.
The nature of each step will be explained in the following sub-sections. The security features that
are available to a Deep Security administrator will be discussed in the next section.
B.4.1 Step 1: Finding a point of entry

Information is the key to any successful attack. An attacker, therefore, must be able to answer
the following key questions about their targets in advance of the attack:
● What is the target (Is there, in fact, a target)?
● What is the target’s environment?
● What vulnerabilities are associated with that environment?
Once these preliminary questions are answered, the attacker is then able to choose the
appropriate attack mechanism.
VULNERABILITIES THAT CAN’T BE PATCHED

The standard solution to operating system vulnerabilities that can be used to gain access
to a system is to apply that appropriate security patch to resolve the issue. However,
patches are only available to operating systems that are still supported by their developer.
Microsoft, for example, no longer support Windows 2000, and therefore has stopped
issuing security patches for them.
The full spectrum of techniques for determining points of entry is beyond the scope of this
document. These techniques can range from social engineering methods for collecting
information, to using search engines to look for vulnerable sites with specific un-patched
versions of blog software.
Among these techniques are a set of activities collectively called Reconnaissance scans. For purposes
of this document, this is the technique upon which we will focus.
Important: Reconnaissance scans actually have legitimate uses. Network administrators do

this to help them harden their networks. Deep Security, for example, performs a form of
reconnaissance scanning on computers on its network to detect open ports that may need to
be protected.
Scans typically work as shown below:

Scan packet
Response
Scanner host Scan target
These scans typically involve two messages: the scanning packet, and the response -- or even the
absence of a response. When the Deep Security Manager performs a port scan, it sends a SYN
packet to the target host, at a particular port. If a connection is established, then the port is
declared open. Other techniques focus on the absence of a reset (RST) response to detect open
ports.
Whereas network administrators use this capability to protect their networks, crackers/hackers
can leverage the same reconnaissance scanning tools (e.g., NMAP) to look for security gaps.
Reconnaissance scanning can consist of any or a combination of the following activities:
Network mapping/scanning – this refers to the process of collecting a list of computers
on a network that could then be attacked.
Port scanning – this is the process of looking for open ports, betraying the presence of
specific applications and or vulnerabilities. This is the type of scan discussed in the
paragraph above. A successful port scan is essential to a variety of other reconnaissance
scans.
OS fingerprinting – this process discovers the operating system of potential target
machines. Different tools use different ways of creating fingerprints. NMAP, for
example, uses the results of seven different tests and matches the responses to a
database of known responses for each OS. Other tools use their own techniques.
Enumeration – this scan causes the target to list, or enumerate, the resources that are
available on it, or its host network. Such resources include user accounts, services,
network shares, and other information that may be of use to an attacker.
Once general information is collected, the attacker proceeds to Vulnerability scanning to look for
specific exploitable vulnerabilities.
NOTE Depending on the tool used, reconnaissance and vulnerability scanning can be
performed together. These are not necessarily separate steps.
The vulnerabilities detected – as well as the objectives of the attacker -- define the attack options
open to the attacker. The options are very broad, however, they can still be divided into the
following considerations.
Yes
Gain access
to target
Does the
Evaluate
Vulnerability attack option require
attack
scan access to the
options
target?
Perform
attack
No
If the nature of the attack requires gaining access to the target, then the process described here
proceeds to the next section. Otherwise, it proceeds directly to the attack itself.
B.4.2 Step 2: Gaining access

As mentioned in the previous step, access to the target is not necessary for all attacks. Network-
based threats, for example, misuse protocol behaviors to cause damage. Attacks only require
access if they involve the insertion of malware on the target, or if they require modification of
certain system areas to work.
The access methods that hackers use to compromise systems range from social engineering
techniques, to technological approaches. The sheer number of options precludes discussion of
all, but a few, methods in this document.
To rationalize the discussion, let us focus on how various variants of the malware
Conficker/WORM_DOWNAD gain access to their systems. As of writing, this malware used
the following propagation methods:
● Vulnerability exploit
● Brute force attack on network shares
● Named-pipes
● Malicious HTTP servers
● Autorun.inf
Once the worm gains access to the target system, it marks its transition to the attack step by
dropping files believed to form part of a botnet, and then using the victim’s machine as a
platform for infecting other machines.
Important: The caveat “as of writing” is important because this malware has been known to
obtain upgrades that expand its capabilities.
Vulnerability exploit
Most variants of the malware Conficker/WORM_DOWNAD gain access to affected systems
through the following end-user reported vulnerability: Server Service Vulnerability (MS08-067). This
issue affected Windows operating systems from version 2000 to 2008/Vista, and involves the
Server Service, which is responsible for the following functionalities that are essential to network
operations:
● RPC support
● File & print sharing support

● Named pipe sharing
Attackers leverage this vulnerability by sending malicious RPC requests to the service, which
then fails to validate its content. The request causes a stack overflow and code execution that
grants the attacker the following abilities on the victim:
● Install programs
● View/Change/Delete files
● Create new accounts with full user rights
Brute force attack on network shares

Some Conficker/WORM_DOWNAD variants can launch brute-force/dictionary attacks against
password protected network shares. If the worm successfully “guesses” the password of the
share, it drops a copy of itself in the shared folder.
Named-pipes
Later versions of the worm gained the ability to use named pipe connections to receive
components from remote systems.
Malicious HTTP servers

This action can be considered part of both Malicious
the attack, as well as the process of gaining HTTP
server
access. It reflects the sophistication of
present-day malware. Download worm
components / updates
Once part of the worm gains access to
victim’s machine, it connects to a malicious
HTTP server and downloads additional Un-secured
Worm
infection vector
components. These components can
consist of the worm’s payload, or updates Target
to the worm’s code. computer
The HTTP server can be another compromised computer where the worm creates an HTTP
server with a random port, or a Website that is accessible via the Internet.
NOTE An example of update to the worm is one that increased the number of Internet
domains from which it could download updates and payload, from 250 to 50,000
domains. This update changed the worm from WORM_DOWNAD.A to WORM_DOWNAD.KK.
Autorun.inf
This a passive access method that requires the victim to connect to an infected network or
removable drive with a malicious autorun.inf file.
Autorun functionality was originally intended to automate the device “mounting” process,
thereby facilitating the use of external data storage devices. A popup window like the one shown
below typically appears when a USB device is connected.
At this point, Windows automatically looks for a file called autorun.inf. This file contains
instructions that the OS executes to facilitate use of the device. If the USB drive contains
malware, such as Conficker/WORM_DOWNAD, a maliciously modified autorun.inf could be
used to initiate an attack on the desktop from the USB drive.
B.4.3 Step 3: Performing the attack

Discussion of the possibilities open to an attacker once a machine is compromised is so broad, it
actually merits its own course of instruction. However for purposes of document, we will limit
the discussion to the following types of attacks:
● Denial of Service
● Man-in-the-middle attack
● Web application attack
● Botnets
● Attacks on virtual environments
Each attack is discussed in detail below.
Denial of Service
A Denial of Service (DoS) is a type of attack that renders a particular service unavailable to its
intended users. For example, visitors to a Website that is subject to a DoS would receive
messages like “Host not found” because the site would no longer be able to respond to the
visitor’s browser request.
Request
DoS
Host not found attacker
Request timed out
NOTE DoS attacks can be directed a computer’s IP address or its domain name.
A DoS can also be used to facilitate other types of attacks. For example, an attacker seeking to
hijack a TCP session as part of a Man-in-the-Middle attack can initiate the attack by launching a
DoS on one of the machines in the session to temporarily disrupt communication, thereby
allowing the attacker to insert himself into future communication.
There are a wide variety of DoS attacks, only a selection of which is discussed below:
● ACK Storm
● Smurf
● PING-of-death
● Teardrop
● Botnets
ACK STORM
The ACK storm is the uncontrolled exchange of ACK messages between two hosts that
eventually results in network congestion. This is typically the result of vulnerability in an
operating system’s implementation of TCP because this attack requires the attacker to know the
TCP sequence number that a particular host expects to elicit an ACK message from that host.
Consider the following diagram.
Host 1 Host 2
Message using spoofed
Host 2 identity and a
sequence# N that Host 1
accepts
Acknowledge receipt of
message from Host 2
ACK (Seq# N+1)
Wait for Incorrect sequence

acknowledgement number. Expected
number: Y
ACK (Seq# Y)
Incorrect sequence Wait for

number. Expected acknowledgement
number: N+2
Send ACK (Seq# N+1)
Incorrect sequence
number. Expected
number: Y+1
Repeat ACK exchange
The initial attack causes Host 1 to send an ACK message to Host 2. The sequence number used
in this message comes from the attacker’s message, and will not be expected by Host 2. This will
prompt Host 2 to send an ACK message to Host 1 with the sequence number that it expects to
resynchronize the communication. Since Host 1 will receive an ACK message whose sequence
number is also not what it expects, it too will try to resynchronize the communication by sending
its own ACK message.
SMURF
A Smurf attack leverages the broadcast address of incorrectly configured routers to flood the
network with ICMP messages. By design, each router maintains a broadcast address that
automatically sends messages to all computers on the network.
In a Smurf attack, the attacker sends a PING message to the broadcast address of a router, or
similar intermediary, causing device to forward the PING to all machines on the network.
PING
255.255.255.255
When these machines make their ICMP Echo replies, they will send them back to the broadcast
address, thereby triggering additional broadcasts. This creates a kind of broadcast storm, and results
in network congestion.
PING-OF-DEATH
A PING-of-Death (POD) involves a PING message that exceeds protocol specifications, thus
causing buffer overflow problems in certain TCP/IP implementations.
Buffer
Transport Re-assembled packet
overflow
Data link #1 #4 #3 #5 #2
TEARDROP
A teardrop attack uses a malformed IP fragment with overlapping, oversized, payloads that can
cause errors at the Transport layer of a computer’s protocol stack when it tries to reassemble the
fragments.
Fragmentation attacks
Attackers can use packet fragments to infiltrate networks and cause Denial of Service. Since DoS
has already been discussed in the previous section, including the POD and Teardrop
fragmentation attacks, this section focuses attacks designed for infiltration, namely:
● Tiny fragment attack

● Overlapping fragment attack
TINY FRAGMENT ATTACK

The SAN glossary of security terms defines this attack as follows:
http://www.sans.org/security-resources/glossary-of-terms/t
With many IP implementations it is possible to impose an unusually small fragment size on outgoing packets. If
the fragment size is made small enough to force some of a TCP packet's TCP header fields into the second
fragment, filter rules that specify patterns for those fields will not match. If the filtering implementation does not
enforce a minimum fragment size, a disallowed packet might be passed because it didn't hit a match in the filter.
The fragmentation, therefore, is used as a means to circumvent HIPS solutions.
OVERLAPPING FRAGMENT ATTACK

This attack is similar to a Teardrop attack, but instead of causing a denial of service, it is used as
a means of circumventing HIPS solutions. The following document presents an example of how
this attack could be performed
http://www.ouah.org/fragma.html
This attack can be used to overwrite part of the TCP header information of the first fragment, which contained
data that was allowed to pass through the firewall, with malicious data in subsequent fragments. A common
example of this is to overwrite the destination port number to change the type of service i.e. change from port 80
(HTTP) to port 23 (Telnet) which would not be allowed to pass the router in normal circumstances.
Man-in-the-middle attack
A man-in-the-middle (MITM) attack allows the attacker to divert the victim’s outgoing traffic
from its intended destination to a malicious alternative. This can be used to insert the attacker in
communication between two ends of a session. For example, if an attacker uses ARP poisoning
to trick the network router into believing the attacker machine is the victim’s machine, then
tricks the victim’s machine into believing the attacker’s machine is the router, and then the
attacker uses IP forwarding to send traffic to the appropriate destinations, then the all traffic to
and from the victim will always go through the attacker’s machine – without the victim knowing
about it.
Server
IP forwarding
Attacker
There are a number of techniques available for accomplishing this attack. These include DNS
poisoning, where domain name information is maliciously associated with the attacker’s preferred
alternative. This information can be entered at the network DNS server itself, or in the hosts file
on computers on the network.
Web application attack

Web applications are inherently difficult to protect. Because they have to be exposed to the
outside world to perform their function, they cannot benefit from the security-through-isolation
schema that defines traditional network security.
Important: This is an example of an attack where the attacker does not even need to gain
access to the target machine before launching the attack. So for this attack, the attacker
would proceed from Step 1 to Step 3 in this attack process discussed here.
These applications typically reside in what is called the “DMZ”, a section of the network that is
accessible to both the “Trusted” network, and the “Untrusted” outside world (e.g., the Internet,
public WiFi access, etc.).
Untrusted zone DMZ Trusted zone
Console
Web
Management application
console Database
In the diagram above, anyone should be able to access the Web application in the DMZ, but
should not be able to directly access the backend resources in the trusted zone. In this example,
that resource is a database server. Only the Web application should be able to access this
database.
To preserve the integrity of the zones, the Web application must be able to resist attempts to
misuse it to gain access to the trusted zone. Not all Web applications, however, achieve this goal.
Among the methods attackers use to attack Web applications are the following:
Cross-Site Scripting (XSS) – the attacker introduces malicious script to a dynamic form
(e.g., an input field on a Web application) that does not perform sufficient validation.
SQL injection – the attacker includes malicious instruction into strings that are eventually
passed on to the database associated with a Web application. The malicious code can be
designed to be executed as soon as they are accepted, or to be stored in the database and
then executed when they are retrieved.
Botnets
A “bot” is an application that is installed on a machine, either surreptitiously via a Trojan or by
social engineering, that grants an attacker remote access to that machine’s system resources for
use in acts of malfeasance. For example, that machine could be used to establish malicious
connections to a web application as part of a Distributed Denial of Service (DDoS) attack.
Once a bot is installed on a machine, that machine is thereinafter referred to as a “zombie”, and
becomes part of a network work of zombie machines collectively called a “botnet”.
Attacks on virtual environments

In many ways, virtual machines are no different from physical machines. They are subject to the
same threats that traditional physical platforms face. However, the ease with which VMs can be
created, cloned, brought online, etc. do create unique administrative challenges that create their
corresponding threats.
Among these threats is the issue of instant-on gaps. The “gap” refers to the interval between when
a VM is powered on, to when vulnerabilities present on these machines are patched. This is
illustrated below.
VM VM VM
OFF ON ON
Vulnerability Vulnerability Patched
X seconds Y seconds
T:0 T:+X seconds T:+X+Y seconds
Window of vulnerability
This gap can last anywhere from minutes to even days, depending on the skill and availability of
personnel to administer the virtual infrastructure. The vulnerabilities mentioned here can include:
● Operating system vulnerabilities
● Application vulnerabilities
● Un-updated security software on the VMs
If an attacker initiates the attack process during this window, then they elevate their chances for
success.
B.5 > Mapping features to threats

To understand how Deep Security protects against the attack process, the following tables
present the different Deep Security features that are designed to address these specific attack
steps:
● Finding a point of entry
● Gaining access
● Performing the attack
Finding a point of entry

The Deep Security Reconnaissance scan feature
offers protection against this step in the attack
Step 1: Finding a point of entry
process. Administrators can choose to automatically
block sources of Reconnaissance scans, or simply log
their occurrrence.
Relevant features are listed below: Step 3: Performing
the attack
Network or port scan – the DSA detects scans
based on analysis of port connection
attempts over time, derived from state table
information. It uses a Time-based Access
Pattern Sequential (TAPS) hypothesis testing
algorithm.
Computer OS fingerprint probe – some probes involve, but not limited to, packets with
SYN, FIN, URG, PSH flags enabled. Others use packets with no flags enabled, but have
the DF (don’t fragment) option set.
TCP Null scan – this is a TCP packet with no flags set and does not use the DF option.
This can be used to detect open ports without triggering TCP 3-way handshake.
TCP SYN FIN scan – this is a port scan method that utilizes a TCP packet with both SYN
and FIN flags enabled – in violation of TCP protocol specifications
TCP Xmas scan – these scans use packets with the PSH, FIN, and URG flags set and are
used to detect open ports.
Controls for these features appear Reconnaissance tab on the System Settings screen on the
DSM management console.
Once a reconnaissance scan is detected, the DSM generates an alert like the one below
Information about the reconnaissance scan also appears on the target machines details screen
and preview. The latter appears below.
Gaining access Step 1: Finding a point of entry

In the section that introduced this step of the attack
process, the following propagation methods that Step 2: Gaining access
Conficker/WORM_DOWNAD utilized were
discussed: Step 3: Performing
the attack
● Vulnerability exploit
● Brute force attack on network shares
● Named pipes
● Malicious HTTP servers
● Autorun.inf
This section will discuss what Deep Security can, and cannot, do to address these attack vectors.
NOTE Conficker/WORM_DOWNAD is an example of a threat that requires a mix of

solutions for effective defense. Deep Security can prevent infection via the network by
blocking network access points that the worm leverages. However other Trend Micro
solutions such as ______ are necessary for other attack vectors, such as USB drives, etc.
Attack vector Deep Security solution

Vulnerability exploit Feature: Deep Packet Inspection > DPI Rules
Action: Prevent
The following DPI rules address the Server Service vulnerability

that Conficker/WORM_DOWNAD uses for propagation
Brute force attack on Feature: Deep Packet Inspection > DPI rules
network shares
Action: Prevent
This filter identifies a brute force attempt to determine the

Windows password by inspecting the number of failed logons
within an interval. By default, this rule is triggered when 50
attempts fail in 180 seconds. This value is configurable. This
defends against malware that use letter combinations or
dictionaries to "guess" passwords.
Named pipes Feature: Deep Packet Inspection > DPI rules
Action: Prevent
Malicious HTTP servers Feature: Deep Packet Inspection > Application control
Action: Prevent
This is a heuristics filter that detects HTTP traffic that does not
occur on ports 80, 8080, or some other administrator-authorized
port.
Leveraging other Trend Micro products
The following threats discussed in the Anatomy of the attack section are beyond the current
scope of Deep Security’s protection capabilities
Attack vector Description of limitation Alternative Trend Micro product
Autorun.inf As of writing, Deep Security does End-point protection solutions that

not offer file access prevention prevent autorun.inf from being run
capability can offer protection against this
attack vector.
Relevant product:
OfficeScan 10.x or later
Performing the attack

The section that discussed how attacks are
performed, focused upon the following attacks:
Step 1: Finding a point of entry
Denial of service
Fragment attack
Man in the middle Step 3: Performing
the attack
Web application attack
Botnets
Attacks against VMs
The tables below provide a high-level view of the
protection that Deep Security offers against these
attacks.
DENIAL OF SERVICE
Attack description Deep Security solution
ACK Storm Feature: Stateful configuration > TCP Packet Inspection
Attack injects an out of sequence Action: Prevent / Detect only

packet into a session thereby
causing both hosts to continually
send ACK messages to each other,
thereby tying up resources
If stateful configuration detects that the number of ACK

messages for the life of the connection exceeds the
figure specified, the connection is terminated.
The default value is “300”.
Generic, non-distributed Denial Feature: Stateful configuration > TCP Packet Inspection
of Service
Action: Prevent
Attacker either causes other
machines on a network to flood the
DSA host with connections, or uses
the DSA host to launch a similar
attack on other hosts
Once the number of connections to and from a

computer exceeds this setting, DSA prevents additional
connections.
The default value is 100 connections
Smurf Feature: Stateful configuration > UDP/ICMP Packet

Inspection
The attacker sends a PING message
to the broadcast address of a Action: Prevent
router, or similar intermediary,
causing device to forward the PING
to all machines on the network.
When these machines make their
ICMP Echo replies, they will send
them back to the broadcast
address, thereby triggering

additional broadcasts. This creates
in a kind of broadcast storm, and
results in network congestion.
The protocol upon which this attack takes place is an

unsolicited PING, which is based on UDP and ICMP
protocols.
Stateful configuration for UDP and ICMP cause the DSA

to reject unsolicited PINGs, thereby thwarting the attack
entirely
PING of death Feature: Firewall
A PING-of-Death (POD) involves an Action: Prevent

PING message that exceeds
protocol specification, which Protection against this attack is built into fragment-level
causes buffer overflow problems in analysis and is an integral part of protocol hygiene
certain TCP/IP implementations. functionality. Packets with headers that do not conform
to protocol specifications, such as those used in this
kind of attack, are dropped.
See the Traffic analysis > Fragment analysis >

Verification section on page 123 for more details.
Teardrop Feature: Firewall
A teardrop attack uses a Action: Prevent

malformed IP fragment with
overlapping, oversized, payloads Protection against this attack is built into the
that can cause errors at the fragmentation-analysis process and is an integral part
Transport layer of a computer’s of protocol hygiene functionality. Packets with headers
protocol stack when it tries to that do not conform to protocol specifications, such as
reassemble the fragments. those used in this kind of attack, are dropped.
See the Traffic analysis > Fragment analysis >

Verification section on page 123 for more details.
FRAGMENTATION ATTACK
Tiny fragment attack Feature: Firewall
The first fragment of a packet is Action: Prevent

deliberately made small to force
TCP header fields into subsequent
fragments, hence circumventing
HIPS solutions that only look for

header information in the first
fragment.
Fragment-level analysis can drop fragments that fall

below a pre-defined size.
Overlapping fragment attack Feature: Firewall
Like the Tiny fragment attack, first Action: Prevent

fragment of a packet is malformed
to small to force TCP header fields Fragment-level analysis can drop fragments that fall
into subsequent fragments, hence below a pre-defined size.
circumventing HIPS solutions that
only look for header information in
the first fragment.
MAN IN THE MIDDLE

DNS poisoning Feature: Integrity Monitoring
If a malicious entry is inserted in a Action: Detect only

machine’s hosts file, the victim
could be tricked into connecting to
the wrong server/service provider.
Note: There are other forms of DNS

poisoning that require other
solutions
Integrity Monitoring can detect these sorts of malicious
changes, if the attack could not be thwarted in the first

two phases of the attack process
WEB APPLICATION ATTACK

Cross-Site Scripting Feature: Deep Packet Inspection > Web application
protection
Action: Prevent
Generic XSS rule drops traffic with malicious

content
SQL injection Feature: Deep Packet Inspection > Web application
protection
Action: Prevent
Generic SQL injection rule drops traffic with

malicious content
BOTNETS
As illustrated in the threat section, botnets generally have the following common elements:
● A zombie with a bot
● A command center that controls the bots
● Communication between the bots and the command center
The third element is one of the principal ways that botnets are discovered, and eventually
eliminated.
The Trend Micro product that is specifically targeted at addressing botnets is the Trend Micro
Threat Management Service. This is a virtual appliance/hardware-based solution that deploys
sensors at strategic points in the network to detect the tell-tale traffic between bots and their
command center and then correlate this information to facilitate remediation.
Deep Security, on the otherhand, offers botnet traffic detection capability for a limited selection
of botnets through its Deep Packet Inspection functionality. As of writing, for example, a DPI
rule for detecting command center traffic associated with the Night Dragon network is currently
available.
Note that this rule will only detect and log the traffic emanating from the Deep Security host, but
will not actually block it.
ATTACKS AGAINST VMS

Attacks in common with Feature:
physical machines
These refer to all the attacks

mentioned in previous sub-
sections that physical machines
experience
Action: Prevent/Detect
Anti-Malware, Firewall, and DPI functionality do

not require installation of a DSA on the VM. Log
Inspection and Integrity Monitoring, however, do.
NOTE In this version, Anti-Malware functionality
is only available to VMs, and is only available via
DSVA.
Exploit instant-on gaps Feature: Deep Security Virtual Appliance
There is a window of Action: Prevent

vulnerability between when a
The Deep Security Virtual Appliance interfaces with the
VM is powered on, and its ESX kernel so that all relevant network traffic and I/O
vulnerabilities are patched, events are routed to it, even without installing a DSA on
and/or its security software is the VM.
updated
This feature, however, is only available if the

administrator sets the DSM to automatically activate
virtual agents and assign a pre-defined profile. This is
done from the System Settings screen, under vCenter
Options.
Inter VM attacks Feature: Deep Security Virtual Appliance
Attackers could theoretically Action: Prevent

use poorly secured VMs on an
Malicious file transfers and other I/O activity can be
ESX box to launch attacks on detected and prevented, even without installing a DSA
other VMs on the same box on the VM.
Appendix C: Product history
C.1 > Appendix overview

This appendix provides a historical overview of the features introduced in different Deep
Security versions. The following versions are discussed here:
● About Common Criteria
● Version 7.5
● Version 7.0, Service Pack 1
● Version 7.0
● Version 6
● Version 5
C.2 > About Common DEEP SECURITY COMPLIANCE
Criteria
The following Deep Security versions
have been granted Common Criteria
certification.
Select security-conscious organizations, especially
Version Certification status
government entities, require that the security
software that they use be certified for “Common 7.0 Not certified
Criteria” compliance.
6.0 Not certified
The Common Criteria Website 5.0 Certified 08 April 2008
(http://www.commoncriteriaportal.org/) provides
the following definition for this certification:
● Products can be evaluated by competent and independent licensed laboratories so as to
determine the fulfilment of particular security properties, to a certain extent or assurance;
● Supporting documents, are used within the Common Criteria certification process to define
how the criteria and evaluation methods are applied when certifying specific technologies;
● The certification of the security properties of an evaluated product can be issued by a
number of Certificate Authorizing Schemes, with this certification being based on the result
of their evaluation;
● These certificates are recognized by all the signatories of the CCRA
C.3 > Version 7.5

The features that were introduced in version 7.5 can be divided into the following categories:
NOTE For information about features and enhancements introduced in previous

versions, see Appendix B

Anti-Malware functionality – the Deep Security Virtual Appliance (DSVA) is now able to
detect and remove malware on virtual machines, without requiring installation of a Deep
Security Agent on these machines. This DSVA version can:
• Perform manual, scheduled, and real-time scanning
• Support different scanning configurations for each scan type
• Use conventional or Smart scanning

Anti-malware reports – new report templates have been added in support of Anti-Malware
functionality
ActiveUpdate support – the DSM now downloads all its updates from the Akamai-based
Trend Micro ActiveUpdate infrastructure. DSVA also downloads its anti-Malware
components using this technology.
Product registration – this version now uses the standard Trend Micro Product
Registration mechanism based on Activation Codes
Enhanced DSVA deployment wizard – the new wizard unifies the ESX preparation and
DSVA deployment process.
vShield Manager support – when adding vCenter Servers to the Computers list,
administrators can now specify a VMware vShield Manager with which to interface as
part of Anti-Malware functionality. This step is only required when malware protection
is required
Host-state reverification – in previous versions, if a computer was added to the DSM
computer list as having no agent installed, and then an agent were installed after the fact,
its status on the Computers list would still appear as it did prior to installation even if a
host discovery command was re-issued. This behavior has been rectified to allow host
discovery to synch the status of existing hosts with their actual status at the time of the
scan.
Expanded Oracle support – this version now supports Oracle 11g
DSVA enhancements – the following improvements to DSVA were introduced in this
version:
DSVA provisioning options – the DSVA deployment wizard now provides the
administrator the option to use thin provisioning for the DSVA. This reduces the
disk space that the appliance occupies.
Automatic start/stop behavior – the DSVA will stop itself automatically when the
ESX goes into maintenance mode, and starts when maintenance mode ends. See
DSVA chapter for details.
Detect-only DPI rules – administrators are now better able to identify rules that Trend
Micro specifically designed for detect-only mode. In these filters, the detect-only button
would always be enabled, and cannot be changed

implement fixes:
Vacuum packages – to facilitate importation of Deep Security packages, such as the DSVA
and dvFilter packages, copy these packages to the location of the DSM installer, and
then run the installer. The installation program will detect the packages and import –
vacuum – them into the resulting DSM installation.
Recommendation scanning changes – since DSVA is a hardened Linux system, and any
DSVA issues will be dealt with product updates, recommendation scanning on DSVA
have been judged redundant, and therefore disabled.
Excel report omission option – the option to generate Excel-based reports has been
disabled by default due to report access/download issues. Administrators retain the
option to re-enable it from the command line using a dsm_c command.
Traffic pattern identification logs – this version introduced two new logs designed to help
administrators fine tune their firewall settings to avoid blocking essential traffic. These
logs are:
– Granular out-of-allow policy logs – logs for implicit denial can now differentiate
between traffic to open or closed ports
– New event ID – when “Event ID #142 New connection initiated” is enabled, the
DSA will generate an event each time a connection is added to the DSA state table.
TCP connections, as well as pseudo-connections for UDP and ICMP can generate
this event.
Generate DSA diagnostic package from command line – troubleshooters can now use
the dsa_control /d or –diag to generate a diagnostic package from the command line.
The resulting diagnostic package will not have DSM log files, and will be found under
the diags folder.
Integrity Monitoring enhancement – the ability to generate alerts based on whether a file
either grew or shrunk in size has been added to IM functionality. These attribute are
different from the original size attribute, which generate an alert based purely on a
change in size, with no regard for the nature of the change. This is particularly useful for
monitoring log files whose growth is of little concern, but whose sudden reduction of
size could indicate malicious tampering of the data within.
C.4 > Version 7.0, Service Pack 1

The features that were introduced in version 7.0 Service Pack 1 can be divided into the following
categories:

Virtual machine protection – administrators can now choose the Security Profiles that are
automatically assigned to Virtual Agents upon instantiation to protect Virtual Machines.
Previously, profiles always had to be manually assigned. This is set in the System Settings
tab using the control shown below, and is a global setting.
Installation – the ability to use an IP address, instead of a hostname, for DSM identification
has been highlighted. The current IP address is now clearly visible on the installation
screen for ease of reference. This is particularly useful when the DNS is not available
during installation.
Management console enhancements – the following changes were introduced to this
feature:
• Misidentification of Windows 7 machines – some Microsoft Windows 7 clients were
misidentified as “servers”
• Advanced search feature – optional fields on the User account details screen were
not included in searches
Syslog enhancements – the following changes were introduced to this feature:
• UTF-8 formatting for CEF – previously, CEF syslogs did not properly support
UTF-8 characters
• CEF formatting – a problem resulting in excess characters in Syslogs, when using

the CEF 1.0 format, was resolved.
• Packet data – base64 encoded packet information can be included in the syslog in
the TrendMicroDsPacketData column
Report template for Integrity Monitoring – a report for Integrity Monitoring baselines
has been added. The report includes the fingerprint date of the baseline, as well as the
relevant type and key
Default maximum memory usage for DSM – the default maximum amount of RAM
available to a 64-bit Deep Security Manager service has been increased from 1GB to
4GB. This, however, is configurable. The default maximum memory usage for a 32-bit
DSM service remains at 1GB.
UTF-8 support in SMTP notification – notification emails can now be sent to recipients
whose names require UTF-8 encoding.
Expanded character support – this resolved a number issues related to non-English
character sets. This included:
● Graphical user interface issues
● Log inspection would fail when it encountered Japanese characters

implement fixes:
Real-time Integrity Monitoring enchancement – resolved an issue where certain events
were appearing on the DSA console, but were incorrectly reported to the DSM. This
occurred when files or folders were created and then deleted very quickly, caused
“Could not create Superseded Entity” error messages on the DSM.
Windows 7 Action Center compatibility – resolved an issue where the DSA may not
correctly report the status of the firewall to the action center immediately after a reboot.
This was caused by the DSA reporting its status to the action center while the center was
still being started, and the DSA did not re-send its status. A retry mechanism has been
incorporated.
Windows XP embedded systems – resolved an issue where the DSA would not start
successfully on Windows XP embedded OSes. There were instances where the DSA
would start before certain network-related services, resulting in a startup failure. The fix
made DSA startup dependent upon these services.
Recommendation scanning enhancements – the following changes were introduced to
this feature:
• Latin-1 character support – previously agents could not retrieve select computer
information using this encoding. This resulted in scan failures
• Memory management – large numbers of recommendations used to cause “java

OutOfMemoryError” in the DSM alert module. This issued occurred in
environments with more than 2,000 computers running Recommendations scans.
● Registry query enhancement – fixed a problem involving improper queries to
Registry keys on 64-bit Windows platforms. This resulted in excessive memory
usage
Resolved errors involving false “duplicate unique identifiers” warnings for VMs. This could
occur when ESX servers were added to the Computer list.
Some customized DPI rules would not function correctly. This was caused by incorrect handling
of the rule’s metadata
C.5 > Version 7.0

The features that were introduced in version 7.0 can be divided into the following categories:
C.5.1 External enhancements

Virtual appliance / VMSafe-Net integration – the Deep Security Virtual Appliance
(DSVA) offers protection for virtual machines on ESX4 and ESXi4 machines, without
requiring the installation of a DSA on the VMs
Integrity Monitoring enhancements – the following changes were introduced to this
feature:
• On-change support – changes to files and Registry entries on Microsoft-based
operating systems can now be detected in real-time
• Baseline viewer – administrators can view a list of system areas for which Integrity
Monitoring has baselines. This is accessible via the DSA’s details.
Event tagging – administrators can now create custom tags to frequently occurring events
to facilitate tracking
Location awareness – DPI and Firewall rules can now based on a DSA’s location relative
to the network
Agent hardening – desktop users are not longer able to deactivate their DSAs from the
DSA console
C.5.2 Internal enhancements

implement fixes:
Recommendation enhancements
Reporting enhancements
Support for 64-bit JVM
Miscellaneous Integrity Monitoring enhancements
Miscellaneous Log Inspection enhancements
C.6 > Version 6

This version became generally available in July 2009. A variant of this version, particularly
version 6.1, became the basis for Intrusion Defense Firewall version 1.2.
C.7 > Version 5

This version became the basis for two Intrusion
Defense Firewall (IDF) versions, as shown on the IDF VERSION MAPPING
text box on the right. Deep Intrusion
Security Defense Firewall
It was the first Deep Security version that obtained version version
Common Criteria compliance certification.
5.0 1.0
5.2 1.1
Appendix D: About widgets
D.1 > Appendix overview

Attendees of Deep Security 7.0 Support Track classes conducted in the first half of 2010, by the
Global Education & Certification Services (GECS) department, were asked to take part in a
number of group workshops where they were asked to discuss among themselves, and then
present to the class, how they would use select Deep Security features.
Among the features discussed in these classes were the Deep Security dashboard widgets.
Presentations by participants of the following classes have compiled and categorized for use in
this appendix:
● Technical University (Mexico City, Mexico) dated March 22-26, 2010
● Deep Security Support Track training (Arlington, USA) dated April 12-14, 2010
● Deep Security Support Track training (Manila, Philippines) dated April 27-29, 2010
D.2 > Widget options

Attendees were asked to decide which widgets they would use if they were Deep Security
administrators. The rationale for their choices can be divided into the following categories:
● Role-based
● Graph-centric
The default arrangement, which some attendees also felt was sufficient for most needs, is shown
below.
D.2.1 Use everything

Some groups were hard-pressed to leave out widgets, and instead choose all. One group,
however, took this option one step further and grouped their widgets according to perceived
importance.
On a typical, wide-side-horizontal monitor, some widgets would only be visible by scrolling. So

this group divided the console into scrolling zones, arranged in roughly the following descending
order:
● Alerts and computer status
● Firewall and DPI events
● Log Inspection and Integrity Monitoring events
● Historical graphs and attacks prevented
● All other widgets
D.2.2 Role-based
Most groups presented one variation or another of a role-based widget selection that was
coupled with specific account types.
D.2.3 Graph-centric
In this design, only graphical historical information would be shown on the dashboard, as shown
below.
This was envisioned for the following use-cases:

● For view only user accounts for decision makers primarily interested in evaluating the
product’s ROI
● Users who preferred to obtain summaries via Deep Security reports instead of console
inspection
Appendix E: Database tables
Deep Security Manager tables are listed below, and grouped according to functionality.
Dashboard
saveddashboards
Alerts
alert2administrators
alert2hosts
alert2s
alerttypes
emails
Reports
reporttemplatemetadatas
Counters
counter3s
counter3ips
counter3ports
counterintegritys
counterintegritykeys
counterloginspection
counterloginspectiondescriptions
countermatch2s
counterwatch2s
Host/Agent/Appliance Management
activehosterrors
agentevents
directories
hosts
hostassetimportance
hostbridges
hostconnectiontypes
hostconnectiontypeportoverrides
hostgroups
hostintegrityrules
hostinterfaces
hostinterfaceconnectiontypes
hostinterfaceips
hostinterfaceippacketfilters
hostinterfacepacketfilters
hostinterfacepayloadfilter2s
hostinterfacestatefulfilters
hostloginspectionrules
hostmetadatas
hostmetadataattributes
hostmetadatagroups
hostpacketfilters
hostpayloadfilter2s
hostrecommendations
hostscans
hostscanports
hostsystemsettings
virtuals
virtualesx
virtualvm
sslcredentials
sslhostconfigurations
sslhostconfigurationhostinterfaces
Security Profiles
interfacetypes
securityprofiles
securityprofileconnectiontypes
securityprofileconnectiontypeinterfacetypes
securityprofileconnectiontypeportoverrides
securityprofileintegrityrules
securityprofileloginspectionrules
securityprofilepacketfilters
securityprofilepacketfilterinterfacetypes
securityprofilepayloadfilter2s
securityprofilepayloadfilter2interfacetypes
securityprofilestatefulfilters
securityprofilesystemsettings
Firewall
packeterrors
packetfilters
packetfilteroverrides
packetlogs
packetlogdatas
packetloghistory
statefulfilters
Deep Packet Inspection

connectiontypes
connectiontypeoverrides
connectiontypemetadatas
connectiontypemetadataoverrides
payloadfilter2s
payloadfilter2overrides
payloadfilter2metadatas
payloadfilter2metadataoverrides
payloadlogs
payloadloghistory
payloadlogdatas
Integrity Monitoring
attributes
entitys
integrityevents
integrityeventhistory
integrityrules
integrityrulemetadatas
integrityrulemetadataoverrides
integrityruleoverrides
supersededentitys
Log Inspection
loginspectiondecoders
loginspectiondecodermetadatas
loginspectionevents
loginspectioneventhistory
loginspectionrules
loginspectionrulemetadatas
loginspectionrulemetadataoverrides
loginspectionruleoverrides
portlists
Components
iplists
maclists
rulecontexts
schedules
Other (System)
autodiagnostic
availablesystemversions
checkedoutobjects
detectionexpressions
detectionrules
dsmcredentials
managernodes
pluginsettings
rulegroups
systemevents
systemeventhistory
systemsettings
systemversions
sslcertificates
Role-Based Access Control and User Settings

administrators
administratorroles
administratorrolehosts
administratorrolehostgroups
administratorrolerights
administratorrolesecurityprofiles
administratorsettings
administratorsettingvalues
clientsessions
contacts
rights
rightgroups
ssogroups
Tagging/Syslog/SNMP
autotagrules
comments
postprocessor
recentcomments
tags
tagsets
tagsettags
Software
agentinstallers
agentinstallersegments
Job Framework
discoveryjobs
donotdiscoverips
locks
managerjobs
managerhistorys
managermessages
Scheduled Tasks
scheduledtasks
scheduledtaskadministrators
scheduledtaskcontactss
Help System
helparticles
Vulnerability Database
vulnerabilities
vulnerabilitylinks
vulnerabilitypayloadfilter2s
vulnerabilityshieldupdates
vulnerabilitysoftwares
softwares
Appendix F: Intelligent
ActiveUpdate (iAU) IDs
OEM = 1
Platform = 5889
Version = 8.0.0
Class = 22
C22t2202v8.0.0l1p5889r1o1
Type = 2202
Language = 1
Region = 1
F.1 > Class codes

Binary Hex Description
0 0x00000000 IAU_CLASS_TEST
1 0x00000001 IAU_CLASS_TIS
2 0x00000002 IAU_CLASS_ENGINE
3 0x00000003 IAU_CLASS_PATTERN
4 0x00000004 IAU_CLASS_IAUCLIENT
5 0x00000005 IAU_CLASS_RESOURCE
6 0x00000006 IAU_CLASS_ENFORCE
7 0x00000007 IAU_CLASS_FUNCTION
8 0x00000008 IAU_CLASS_MISC
9 0x00000009 IAU_CLASS_AMSP
10 0x0000000A IAU_CLASS_AMSP_3RD_PARTY
11 0x0000000B IAU_CLASS_UNICLIENT
12 0x0000000C IAU_CLASS_VIZOR_PRODUCT
13 0x0000000D IAU_CLASS_PROGRAM
14 0x0000000E IAU_CLASS_PATCH
15 0x0000000F IAU_CLASS_SECURITY_PATCH
16 0x00000010 IAU_CLASS_WOFIE_PRODUCT
17 0x00000011 IAU_CLASS_TITANIUM_PRODUCT
18 0x00000012 IAU_CLASS_PARENTAL_MONITORING_PRODUCT
19 0x00000013 IAU_CLASS_ROOTKITBUSTER_PRODUCT
21 0x00000015 IAU_CLASS_IDENTITYSAFE_PRODUCT
22 0x00000016 IAU_CLASS_DEEPSECURITY_PRODUCT
99 0x00000063 IAU_CLASS_PATCH_AGENT
F.2 > Type codes

AMSP related type codes
901 0x00000385 IAU_TYPE_AMSP_AMSP_X86_CORE_CONFIG_REPOSITORY

902 0x00000386 IAU_TYPE_AMSP_AMSP_X86_CORE_UPDATE_MANAGER
903 0x00000387 IAU_TYPE_AMSP_AMSP_X86_CORE_FRAMEWORK
904 0x00000388 IAU_TYPE_AMSP_AMSP_X86_CORE_OTHERS
905 0x00000389 IAU_TYPE_AMSP_AMSP_X86_PLUG_ENGINE_WRAPPER_VSAPI
906 0x0000038A IAU_TYPE_AMSP_AMSP_X86_PLUG_ENGINE_WRAPPER_SSAPI
907 0x0000038B IAU_TYPE_AMSP_AMSP_X86_PLUG_ENGINE_WRAPPER_DCE
908 0x0000038C IAU_TYPE_AMSP_AMSP_X86_PLUG_ENGINE_WRAPPER_AEGIS
909 0x0000038D IAU_TYPE_AMSP_AMSP_X86_PLUG_ENGINE_WRAPPER_TMUFE
910 0x0000038E IAU_TYPE_AMSP_AMSP_X86_PLUG_ENGINE_WRAPPER_TMASE
911 0x0000038F IAU_TYPE_AMSP_AMSP_X86_PLUG_ENGINE_WRAPPER_TMFBE
912 0x00000390 IAU_TYPE_AMSP_AMSP_X86_PLUG_ENGINE_WRAPPER_ICRC
913 0x00000391 IAU_TYPE_AMSP_AMSP_X86_PLUG_ADAPTER_SYSTEM
914 0x00000392 IAU_TYPE_AMSP_AMSP_X86_PLUG_ADAPTER_FIREWALL
915 0x00000393 IAU_TYPE_AMSP_AMSP_X86_PLUG_ADAPTER_PROXY
916 0x00000394 IAU_TYPE_AMSP_AMSP_X86_PLUG_SFC_REALTIME
917 0x00000395 IAU_TYPE_AMSP_AMSP_X86_PLUG_SFC_MANUAL
918 0x00000396 IAU_TYPE_AMSP_AMSP_X86_PLUG_SFC_ROOTKIT
919 0x00000397 IAU_TYPE_AMSP_AMSP_X86_PLUG_SCAN_CACHE_ROOTKIT
920 0x00000398 IAU_TYPE_AMSP_AMSP_X86_PLUG_UTIL_RCM
921 0x00000399 IAU_TYPE_AMSP_AMSP_X86_PLUG_UTIL_ENUM
922 0x0000039A IAU_TYPE_AMSP_AMSP_X64_CORE_CONFIG_REPOSITORY
923 0x0000039B IAU_TYPE_AMSP_AMSP_X64_CORE_UPDATE_MANAGER
924 0x0000039C IAU_TYPE_AMSP_AMSP_X64_CORE_FRAMEWORK
925 0x0000039D IAU_TYPE_AMSP_AMSP_X64_CORE_OTHERS
926 0x0000039E IAU_TYPE_AMSP_AMSP_X64_PLUG_ENGINE_WRAPPER_VSAPI
927 0x0000039F IAU_TYPE_AMSP_AMSP_X64_PLUG_ENGINE_WRAPPER_SSAPI
928 0x000003A0 IAU_TYPE_AMSP_AMSP_X64_PLUG_ENGINE_WRAPPER_DCE
929 0x000003A1 IAU_TYPE_AMSP_AMSP_X64_PLUG_ENGINE_WRAPPER_AEGIS
930 0x000003A2 IAU_TYPE_AMSP_AMSP_X64_PLUG_ENGINE_WRAPPER_TMUFE
931 0x000003A3 IAU_TYPE_AMSP_AMSP_X64_PLUG_ENGINE_WRAPPER_TMASE
932 0x000003A4 IAU_TYPE_AMSP_AMSP_X64_PLUG_ENGINE_WRAPPER_TMFBE
933 0x000003A5 IAU_TYPE_AMSP_AMSP_X64_PLUG_ENGINE_WRAPPER_ICRC
934 0x000003A6 IAU_TYPE_AMSP_AMSP_X64_PLUG_ADAPTER_SYSTEM
935 0x000003A7 IAU_TYPE_AMSP_AMSP_X64_PLUG_ADAPTER_FIREWALL
936 0x000003A8 IAU_TYPE_AMSP_AMSP_X64_PLUG_ADAPTER_PROXY
937 0x000003A9 IAU_TYPE_AMSP_AMSP_X64_PLUG_SFC_REALTIME
938 0x000003AA IAU_TYPE_AMSP_AMSP_X64_PLUG_SFC_MANUAL
939 0x000003AB IAU_TYPE_AMSP_AMSP_X64_PLUG_SFC_ROOTKIT
940 0x000003AC IAU_TYPE_AMSP_AMSP_X64_PLUG_SCAN_CACHE_ROOTKIT
941 0x000003AD IAU_TYPE_AMSP_AMSP_X64_PLUG_UTIL_RCM
942 0x000003AE IAU_TYPE_AMSP_AMSP_X64_PLUG_UTIL_ENUM
943 0x000003AF IAU_TYPE_AMSP_AMSP_X86_PLUG_ADAPTER_PRODUCT
944 0x000003B0 IAU_TYPE_AMSP_AMSP_X64_PLUG_ADAPTER_PRODUCT
945 0x000003B1 IAU_TYPE_AMSP_AMSP_x86_PLUG_ADAPTER_BROWSER_PLUGIN
946 0x000003B2 IAU_TYPE_AMSP_AMSP_x64_PLUG_ADAPTER_BROWSER_PLUGIN
947 0x000003B3 IAU_TYPE_AMSP_AMSP_LCE_X86_Engine
948 0x000003B4 IAU_TYPE_AMSP_AMSP_LCE_X64_Engine
949 0x000003B5 IAU_TYPE_AMSP_AMSP_LES_X86_Engine
950 0x000003B6 IAU_TYPE_AMSP_AMSP_LES_X64_Engine
951 0x000003B7 IAU_TYPE_AMSP_AMSP_X86_PLUG_UTIL_SYSINFO

952 0x000003B8 IAU_TYPE_AMSP_AMSP_X64_PLUG_UTIL_SYSINFO
953 0x000003B8 IAU_TYPE_AMSP_AMSP_X86_PLUG_LOCAL_CORRELATION_FLOW
954 0x000003BA IAU_TYPE_AMSP_AMSP_X64_PLUG_LOCAL_CORRELATION_FLOW
955 0x000003BB IAU_TYPE_AMSP_AMSP_X86_PLUG_ENGINE_WRAPPER_TMSA
956 0x000003BC IAU_TYPE_AMSP_AMSP_X64_PLUG_ENGINE_WRAPPER_TMSA
957 0x000003BD IAU_TYPE_AMSP_AMSP_x86_PLUG_UTIL_Exception
958 0x000003BE IAU_TYPE_AMSP_AMSP_X86_PLUG_SCAN_CACHE_COMMON
959 0x000003BF IAU_TYPE_AMSP_AMSP_X64_PLUG_SCAN_CACHE_COMMON
960 0x000003C0 IAU_TYPE_AMSP_AMSP_x64_PLUG_UTIL_Exception
961 0x000003C1 IAU_TYPE_AMSP_AMSP_x64_PLUG_UTIL_DRE
962 0x000003C2 IAU_TYPE_AMSP_AMSP_x86_PLUG_UTIL_DRE
963 0x000003C3 IAU_TYPE_AMSP_AMSP_X64_PLUG_ADAPTER_NCIE
964 0x000003C4 IAU_TYPE_AMSP_AMSP_X86_PLUG_ADAPTER_NCIE
965 0x000003C5 IAU_TYPE_AMSP_AMSP_X86_PLUG_ADAPTER_EAGLEEYE
966 0x000003C6 IAU_TYPE_AMSP_AMSP_X64_PLUG_ADAPTER_EAGLEEYE
967 0x000003C7 IAU_TYPE_AMSP_AMSP_X86_PLUG_ENGINE_WRAPPER_WHITELIST
968 0x000003C8 IAU_TYPE_AMSP_AMSP_X64_PLUG_ENGINE_WRAPPER_WHITELIST
969 0x000003C9 IAU_TYPE_AMSP_AMSP_X86_PLUG_ENGINE_WRAPPER_PEDIF
970 0x000003CA IAU_TYPE_AMSP_AMSP_X64_PLUG_ENGINE_WRAPPER_PEDIF
971 0x000003CB IAU_TYPE_AMSP_AMSP_X86_PLUG_ENGINE_WRAPPER_CDE
972 0x000003CC IAU_TYPE_AMSP_AMSP_X64_PLUG_ENGINE_WRAPPER_CDE
973 0x000003CD IAU_TYPE_AMSP_AMSP_X86_PLUG_ENGINE_CDE, Core engine for x86
974 0x000003CE IAU_TYPE_AMSP_AMSP_X64_PLUG_ENGINE_CDE, Core engine for x64
975 0x000003CF IAU_TYPE_AMSP_AMSP_PATTERN_CDP, CDE pattern
976 0x000003D0 IAU_TYPE_AMSP_AMSP_X86_PLUG_UTIL_LOW_CONFIDENCE_DB, AMSP
plug-in for low confidence DB utility for x86
977 0x000003D1 IAU_TYPE_AMSP_AMSP_X64_PLUG_UTIL_LOW_CONFIDENCE_DB, AMSP
plug-in for low confidence DB utility for x64
978 0x000003D2 IAU_TYPE_AMSP_AMSP_X86_PLUG_CENSUS, Census binary files in
AMSP2
979 0x000003D3 IAU_TYPE_AMSP_AMSP_X64_PLUG_CENSUS, Census binary files in
AMSP2
980 0x000003D4 IAU_TYPE_AMSP_AMSP_X32_PLUG_ENGINE_WRAPPER_SMV, Softmice V
engine wrapper for 32 bits
981 0x000003D5 IAU_TYPE_AMSP_AMSP_X64_PLUG_ENGINE_WRAPPER_SMV, Softmice V
engine wrapper for 64 bits
982 0x000003D6 IAU_TYPE_AMSP_AMSP_X86_PLUG_PROFILE_MANAGER, SPN 2.0
Endpoint Sensor module for handling profile updates (x86)
983 0x000003D7 IAU_TYPE_AMSP_AMSP_X64_PLUG_PROFILE_MANAGER, SPN 2.0
Endpoint Sensor module for handling profile updates (x64)
984 0x000003D8 IAU_TYPE_AMSP_AMSP_X86_PLUG_ENGINE_MANAGER, SPN 2.0
Endpoint Sensor module for interacting with core engines (x86)
985 0x000003D9 IAU_TYPE_AMSP_AMSP_X64_PLUG_ENGINE_MANAGER, SPN 2.0
Endpoint Sensor module for interacting with core engines (x64)
986 0x000003DA IAU_TYPE_AMSP_AMSP_X86_PLUG_SENSOR_FLOW, SPN 2.0 Endpoint
Sensor module for managing events and controlling data flows (x86)
987 0x000003DB IAU_TYPE_AMSP_AMSP_X64_PLUG_SENSOR_FLOW, SPN 2.0 Endpoint
Sensor module for managing events and controlling data flows (x64)
988 0x000003DC IAU_TYPE_AMSP_AMSP_X86_PLUG_THREAT_INTELLIGENCE, SPN 2.0
Endpoint Sensor module for aggregating event violation reports (x86)
989 0x000003DD IAU_TYPE_AMSP_AMSP_X64_PLUG_THREAT_INTELLIGENCE, SPN 2.0
Endpoint Sensor module for aggregating event violation reports (x64)
990 0x000003DE IAU_TYPE_AMSP_AMSP_X86_PLUG_PERFORMANCE_MANAGER, SPN 2.0
Endpoint Sensor module for monitoring and adjusting performance
(x86)
991 0x000003DF IAU_TYPE_AMSP_AMSP_X64_PLUG_PERFORMANCE_MANAGER, SPN
2.0 Endpoint Sensor module for monitoring and adjusting
performance (x64)
992 0x000003E0 IAU_TYPE_AMSP_AMSP_X86_PLUG_ADAPTER_TMESD, End-Point Sensor

Plug-in for TMESD x86
993 0x000003E1 IAU_TYPE_AMSP_AMSP_X64_PLUG_ADAPTER_TMESD, End-Point Sensor
Plug-in for TMESD x64
994 0x000003E2 IAU_TYPE_AMSP_AMSP_X86_PLUG_UTIL_RCM_ESE, End-Point Sensor
Plug-in for RCM utility x86
995 0x000003E3 IAU_TYPE_AMSP_AMSP_X64_PLUG_UTIL_RCM_ESE, End-Point Sensor
Plug-in for RCM utility x64
996 0x000003E4 IAU_TYPE_AMSP_AMSP_X86_PLUG_ADAPTER_EVENT_LOG, SPN 2.0
Endpoint Sensor module for reporting violations found in event logs
x86
997 0x000003E5 IAU_TYPE_AMSP_AMSP_X64_PLUG_ADAPTER_EVENT_LOG, SPN 2.0
Endpoint Sensor module for reporting violations found in event logs
x64
2701 0x00000A8D IAU_TYPE_AMSP_AMSP_X86_WRAPPER_BEP_SPN2, BEP AMSP Wrapper
for SPN2 windows x86
2702 0x00000A8E IAU_TYPE_AMSP_AMSP_X64_WRAPPER_BEP_SPN2 =, /*BEP AMSP
Wrapper for SPN2 windows x64
2703 0x00000A8F IAU_TYPE_AMSP_AMSP_X86_WRAPPER_SAL_SPN2, SAL engine for SPN2
windows x86
2704 0x00000A90 IAU_TYPE_AMSP_AMSP_X64_WRAPPER_SAL_SPN2, SAL engine for SPN2
windows x64
AMSP special type
999 0x000003E7 IAU_TYPE_AMSP_AMSP_FEATURE_META
AMSP 3rd party type
1000 0x000003E8 IAU_TYPE_AMSP_3RD_PARTY_3RD_PARTY_X86_VC2005SP1_REDISTRIB

UTABLE_PACKAGE
1001 0x000003E9 IAU_TYPE_AMSP_3RD_PARTY_3RD_PARTY_X64_VC2005SP1_REDISTRIB
UTABLE_PACKAGE
Enforce type
209 0x000000D1 IAU_TYPE_ENFORCE_169, Pro Features Navigator

Interface:TM_AU_PRODUCT_Common_Platform
Engine type
1 0x00000001 IAU_TYPE_ENGINE_VSAPI_ENGINE
2 0x00000002 IAU_TYPE_ENGINE_DCT_ENGINE
4 0x00000004 IAU_TYPE_ENGINE_VSAPI_ENGINE_X86
16 0x00000010 IAU_TYPE_ENGINE_VSAPI_DRIVER_X86
947 0x000003B3 IAU_TYPE_ENGINE_ENGINE_AMSP_LCS_x32
948 0x000003B4 IAU_TYPE_ENGINE_ENGINE_AMSP_LCS_x64
949 0x000003B5 IAU_TYPE_ENGINE_ENGINE_AMSP_LES_x32
950 0x000003B6 IAU_TYPE_ENGINE_ENGINE_AMSP_LES_x64
4096 0x00001000 IAU_TYPE_ENGINE_VSAPI_DRIVER_X64
33554432 0x02000000 IAU_TYPE_ENGINE_ENGINE_TMASE_ENGINE_32BIT_WIN,
Engine:TMASE Engine 32Bit Win:TM_AU_ENGINE_PIRANA
335544320 0x14000000 IAU_TYPE_ENGINE_ENGINE_TMUFE_X86, Engine:TMUFE
x86:TM_AU_ENGINE_TMUFE_WIN32
536871168 0x20000100 IAU_TYPE_ENGINE_VSAPI_ENGINE_X64
536871936 0x20000400 IAU_TYPE_ENGINE_VSAPI_X64_LINUX
553648132 0x21000004 IAU_TYPE_ENGINE_ENGINE_TMASE_ENGINE_64BIT_WIN, Engine:TMASE
Engine 64Bit Win:TM_AU_ENGINE_TMASE_WIN64
553650176 0x21000800 IAU_TYPE_ENGINE_VST_ENGINE_X86, VST engine x86
553652224 0x21001000 IAU_TYPE_ENGINE_VST_ENGINE_X64, VST engine x86

554172416 0x21080000 IAU_TYPE_ENGINE_DCE_ENGINE_X86, DCE engine x86
554696704 0x21100000 IAU_TYPE_ENGINE_DCE_ENGINE_X64, DCE engine x64
570425360 0x22000010 IAU_TYPE_ENGINE_SSAPI_ENGINE_V6_X86, SSAPI engine v6 x86
570425376 0x22000020 IAU_TYPE_ENGINE_SSAPI_ENGINE_V6_X64, SSAPI engine v6 x64
570425408 0x22000040 IAU_TYPE_ENGINE_ENGINE_AEGIS_DRIVER_X86, Engine:AEGIS driver
x86:TM_AU_ENGINE_BM_CORE_DRV_32
570425472 0x22000080 IAU_TYPE_ENGINE_ENGINE_AEGIS_SERVICE_X86, Engine:AEGIS service
x86:TM_AU_ENGINE_BM_CORE_SRV_32
570425856 0x22000200 IAU_TYPE_ENGINE_ENGINE_AEGIS_SERVICE_X64, Engine:AEGIS service
x64:TM_AU_ENGINE_BM_CORE_SRV_64
570429440 0x22001000 IAU_TYPE_ENGINE_ENGINE_NSC5_CFW_DRIVER_X86, Engine:NSC5
CFW driver x86:TM_AU_ENGINE_NSC5_x86_IM_DRIVER
570441728 0x22004000 IAU_TYPE_ENGINE_ENGINE_NSC5_VISTA_FIREWALL_DRIVER_X86,
Engine:NSC5 Vista firewall driver
x86:TM_AU_ENGINE_NSC5_x86_WFP_DRIVER
570458112 0x22008000 IAU_TYPE_ENGINE_ENGINE_NSC5_VISTA_FIREWALL_DRIVER_X64,
Engine:NSC5 Vista firewall driver
570490880 0x22010000 IAU_TYPE_ENGINE_ENGINE_NSC5_TDI_DRIVER_X86, Engine:NSC5 TDI
driver x86:TM_AU_ENGINE_NSC5_x86_TDI_DRIVER
570556416 0x22020000 IAU_TYPE_ENGINE_ENGINE_NSC5_TDI_DRIVER_X64, Engine:TDI driver
x64:TM_AU_ENGINE_NSC5_x64_TDI_DRIVER
574619648 0x22400000 IAU_TYPE_ENGINE_ENGINE_TMUFE_X64, Engine:TMUFE
x64:TM_AU_ENGINE_TMUFE_64
604504064 0x24080000 IAU_TYPE_ENGINE_ENGINE_NSC5_5_CFW_DRIVER_X86, Engine:NSC5.5
605028352 0x24100000 IAU_TYPE_ENGINE_ENGINE_NSC5_5_CFW_DRIVER_X64, Engine:NSC5.5
606076928 0x24200000 IAU_TYPE_ENGINE_ENGINE_NSC5_5_VISTA_FIREWALL_DRIVER_X86,
Engine:NSC5.5 Vista firewall driver
608174080 0x24400000 IAU_TYPE_ENGINE_ENGINE_NSC5_5_VISTA_FIREWALL_DRIVER_X64,
Engine:NSC5.5 Vista firewall driver
612368384 0x24800000 IAU_TYPE_ENGINE_ENGINE_NSC5_5_TDI_DRIVER_X86, Engine:NSC5.5
TDI driver x86:TM_AU_ENGINE_NSC55_x86_TDI_DRIVER
671088640 0x28000000 IAU_TYPE_ENGINE_ENGINE_NSC5_5_TDI_DRIVER_X64, Engine:NSC5.5
TDI driver x64:TM_AU_ENGINE_NSC55_x64_TDI_DRIVER
671088656 0x28000010 IAU_TYPE_ENGINE_ENGINE_NSC5_5_PFW_SERVICE_X86, Engine:NSC5.5
PFW service x86:TM_AU_ENGINE_NSC55_x86_PFW_SRV
671612960 0x28080020 IAU_TYPE_ENGINE_ENGINE_NSC5_5_PFW_SERVICE_X64, Engine:NSC5.5
PFW service x64:TM_AU_ENGINE_NSC55_x64_PFW_SRV
671612992 0x28080040 IAU_TYPE_ENGINE_ENGINE_NSC5_5_TMPROXY_SERVICE_X86,
Engine:NSC5.5 TMPROXY service
x86:TM_AU_ENGINE_NSC55_x86_TMPROXY_SRV
671613056 0x28080080 IAU_TYPE_ENGINE_ENGINE_NSC5_5_TMPROXY_SERVICE_X64,
Engine:NSC5.5 TMPROXY service
x64:TM_AU_ENGINE_NSC55_x64_TMPROXY_SRV
671613184 0x28080100 IAU_TYPE_ENGINE_ENGINE_TMUFE_LINUX_64,
ENGINE_TMUFE_LINUX_64
672137216 0x28100000 IAU_TYPE_ENGINE_ENGINE_AEGIS_2_5_PEM_PLUG_IN_DLL_X32,
Engine:AEGIS 2.5 PEM plug in DLL x32:TM_AU_ENGINE_BM_PEM_32
675282944 0x28400000 IAU_TYPE_ENGINE_ENGINE_AEGIS_2_5_PEM_PLUG_IN_DLL_X64,
Engine:AEGIS 2.5 PEM plug in DLL x64:TM_AU_ENGINE_BM_PEM_64
679477252 0x28800004 IAU_TYPE_ENGINE_ENGINE_TMFBE_2_5_ENGINE_WIN32, TMFBE 2.5
Engine Win32.
679477256 0x28800008 IAU_TYPE_ENGINE_ENGINE_TMFBE_2_5_ENGINE_WIN64, TMFBE 2.5
Engine Win64.
679477264 0x28800010 IAU_TYPE_ENGINE_ENGINE_TMFBE25_SOLARIS, TMFBE 2.5 Engine

Solaris
679477280 0x28800020 IAU_TYPE_ENGINE_ENGINE_TMFBE25_LINUX_RHEL_32, TMFBE Engine
64-bit
679477312 0x28800040 IAU_TYPE_ENGINE_ENGINE_TMFBE25_LINUX_RHEL_64, TMFBE Engine
Linux 64bit
679477376 0x28800080 IAU_TYPE_ENGINE_ENGINE_AIX_64, TMASE AIX 64-bit platform engine
679477504 0x28800100 IAU_TYPE_ENGINE_ENGINE_VSAPI_64_AIX, VSAPI AIX 64-bit platform
engine
679477760 0x28800200 IAU_TYPE_ENGINE_ENGINE_NSC60_x86_IM_DRIVER, NSC6.0 CFW IM
driver x86
679478272 0x28800400 IAU_TYPE_ENGINE_ENGINE_NSC60_x64_IM_DRIVER, NSC6.0 CFW IM
driver x64
679479296 0x28800800 IAU_TYPE_ENGINE_ENGINE_NSC60_x86_WFP_DRIVER, NSC6.0 WFP
driver x86
679481344 0x28801000 IAU_TYPE_ENGINE_ENGINE_NSC60_x64_WFP_DRIVER, NSC6.0 WFP
driver x64
679485440 0x28802000 IAU_TYPE_ENGINE_ENGINE_NSC60_x86_TDI_DRIVER, NSC6.0 TDI
driver x86
679493632 0x28804000 IAU_TYPE_ENGINE_ENGINE_NSC60_x64_TDI_DRIVER, NSC6.0 TDI
driver x64
679510016 0x28808000 IAU_TYPE_ENGINE_ENGINE_NSC60_x86_PFW_SRV, NSC6.0 PFW service
x86
679542784 0x28810000 IAU_TYPE_ENGINE_ENGINE_NSC60_x64_PFW_SRV, NSC6.0 PFW service
x64
679608320 0x28820000 IAU_TYPE_ENGINE_ENGINE_NSC60_x86_TMPROXY_SRV, NSC6.0
TMPROXY service x86
679739392 0x28840000 IAU_TYPE_ENGINE_ENGINE_NSC60_x64_TMPROXY_SRV, NSC6.0
TMPROXY service x64
680001536 0x28880000 IAU_TYPE_ENGINE_ENGINE_BM_CORE_32, AEGIS3.0 Core Component
x32
1073741824 0x40000000 IAU_TYPE_ENGINE_ENGINE_BM_SYSTEM_EVENT_32, AEGIS3.0 System
Event Component x32
1073741826 0x40000002 IAU_TYPE_ENGINE_ENGINE_BM_USER_EVENT_32, AEGIS3.0 User Mode
Component x32
1073741828 0x40000004 IAU_TYPE_ENGINE_ENGINE_BM_ROOTKIT_SCAN_32, AEGIS3.0 Rootkit
Scan Component x32
1073741832 0x40000008 IAU_TYPE_ENGINE_ENGINE_BM_WHITE_LISTING_32, AEGIS3.0 White
Listing Component x32
1073741840 0x40000010 IAU_TYPE_ENGINE_ENGINE_TMMSG30_x86_DLL, TMMSG 3.0 x86 DLL
1073741856 0x40000020 IAU_TYPE_ENGINE_ENGINE_TMMSG30_x64_DLL, TMMSG 3.0 x64 DLL
1073741888 0x40000040 IAU_TYPE_ENGINE_ENGINE_ICRC_HLDR, ICRC Handler
1073741952 0x40000080 IAU_TYPE_ENGINE_ENGINE_ICRC_SF, ICRC Smart Filter
1073742080 0x40000100 IAU_TYPE_ENGINE_ENGINE_ICRC_HLDR64, ICRC Handler 64bit
1073742336 0x40000200 IAU_TYPE_ENGINE_ENGINE_HC_CORE_DLL, for Housecall 7
1073742848 0x40000400 IAU_TYPE_ENGINE_ENGINE_HC_CORE_DLL_CLI, for Housecall 7
1073743872 0x40000800 IAU_TYPE_ENGINE_ENGINE_HC_CORE_DLL_X64, for Housecall 7
1073745920 0x40001000 IAU_TYPE_ENGINE_ENGINE_HC_CORE_DLL_CLI_X64, for Housecall 7
1073750016 0x40002000 IAU_TYPE_ENGINE_ENGINE_NVE_VSAPI2, network scanning engine for
Network VirusWall Enforcer
1073758208 0x40004000 IAU_TYPE_ENGINE_ENGINE_NSC60_x86_TMPROXY_URLFILTER_ONLY_S
RV, NSC6.0 TMPROXY URL Filtering-Only service x86
1073774592 0x40008000 IAU_TYPE_ENGINE_ENGINE_NSC60_x64_TMPROXY_URLFILTER_ONLY_S
RV, NSC6.0 TMPROXY URL Filtering-Only service x64
1073807360 0x40010000 IAU_TYPE_ENGINE_ENGINE_AMSP_DCE_X86, tscdll32.dll
1073872896 0x40020000 IAU_TYPE_ENGINE_ENGINE_AMSP_DCE_X64, tscdll64.dll
1074003968 0x40040000 IAU_TYPE_ENGINE_ENGINE_AMSP_SSAPI_X86, tscdll32.dll
1074266112 0x40080000 IAU_TYPE_ENGINE_ENGINE_AMSP_SSAPI_X64, tscdll32.dll
1074790400 0x40100000 IAU_TYPE_ENGINE_ENGINE_BM_CORE_64, AEGIS3.0 Core Component
x64
1075838976 0x40200000 IAU_TYPE_ENGINE_ENGINE_BM_SYSTEM_EVENT_64, AEGIS3.0 System
Event Component x64
1077936128 0x40400000 IAU_TYPE_ENGINE_ENGINE_BM_USER_EVENT_64, AEGIS3.0 User Mode
Component x64
1082130432 0x40800000 IAU_TYPE_ENGINE_ENGINE_BM_ROOTKIT_SCAN_64, AEGIS3.0 Rootkit
Scan Component x64
1090519040 0x41000000 IAU_TYPE_ENGINE_ENGINE_BM_WHITE_LISTING_64, AEGIS3.0 White
Listing Component x64
1107296256 0x42000000 IAU_TYPE_ENGINE_ENGINE_VSAPI32_LINUX_GCC423, VSAPI 9.0 new
platforms
1140850688 0x44000000 IAU_TYPE_ENGINE_ENGINE_X64_MACOS_X, VSAPI 9.0 new platforms
1207959553 0x48000001 IAU_TYPE_ENGINE_ENGINE_NSC65_x86_BROWSER_PLUGIN_IE
1207959554 0x48000002 IAU_TYPE_ENGINE_ENGINE_NSC65_x64_BROWSER_PLUGIN_IE
1207959556 0x48000004 IAU_TYPE_ENGINE_ENGINE_TMSA_X86, Script Analyzer Lineup engine
for 32 bit
1207959560 0x48000008 IAU_TYPE_ENGINE_ENGINE_TMSA_X64, Script Analyzer Lineup engine
for 64 bit
1207959569 0x48000011 IAU_TYPE_ENGINE_ENGINE_NSC65_x86_FFExt, NSC 65
0x48000012 IAU_TYPE_ENGINE_ENGINE_DRE_X86, Damage Recovery Engine for
x86
0x48000014 IAU_TYPE_ENGINE_ENGINE_DRE_X64, Damage Recovery Engine for
x64
1207959577 0x48000019 IAU_TYPE_ENGINE_CLEANBOOT_ENGINE_X86, CleanBoot program
which loads VSAPI to do the virus clean and file restore in Linux
1207959585 0x48000021 IAU_TYPE_ENGINE_NCIE_x64_DRIVER
1207959586 0x48000022 IAU_TYPE_ENGINE_NCIE_x86_COORDINATOR, Network Content
Inspection Engine Coordinator
1207959587 0x48000023 IAU_TYPE_ENGINE_NCIE_x86_DRIVER, Network Content Inspection
Engine Scanner
1207959588 0x48000024 IAU_TYPE_ENGINE_ENGINE_EAGLEEYE_CONTROLLER_VISTA_X86,
EagleEye Controller on Vista (x86)
1207959592 0x48000028 IAU_TYPE_ENGINE_ENGINE_EAGLEEYE_CONTROLLER_VISTA_X64,
EagleEye Controller on Vista (x64)
1207959616 0x48000040 IAU_TYPE_ENGINE_ENGINE_EAGLEEYE_CONTROLLER_XP_X86,
EagleEye Controller on XP (x86)
1207959617 0x48000041 IAU_TYPE_ENGINE_ENGINE_EAGLEEYE_CONTROLLER_XP_X64, EagleEye
Controller on XP (x64)
1207959618 0x48000042 IAU_TYPE_ENGINE_ENGINE_EAGLEEYE_HOOK_DRIVER_WFP_X86,
EagleEye Vista WFP Hook Driver (x86)
1207959620 0x48000044 IAU_TYPE_ENGINE_ENGINE_EAGLEEYE_HOOK_DRIVER_WFP_X64,
EagleEye Vista WFP Hook Driver (x64)
1207959624 0x48000048 IAU_TYPE_ENGINE_ENGINE_EAGLEEYE_HOOK_DRIVER_TDI_X86,
EagleEye XP TDI Hook Driver (x86)
1207959680 0x48000080 IAU_TYPE_ENGINE_ENGINE_EAGLEEYE_HOOK_DRIVER_TDI_X64,
EagleEye XP TDI Hook Driver (x64)
1207959681 0x48000081 IAU_TYPE_ENGINE_NCIE_x64_COORDINATOR, Network Content
Inspection Engine Coordinator x64
1207959682 0x48000082 IAU_TYPE_ENGINE_PEDIF_ENGINE_X86, PeDif engine for 32 bits
1207959683 0x48000083 IAU_TYPE_ENGINE_PEDIF_ENGINE_X64, PeDif engine for 32 bits
1207959685 0x48000085 IAU_TYPE_ENGINE_CLEANBOOT_VSAPI_LINUX_ENGINE_X86, Cleanboot
Vsapi Linux Engine
1207959686 0x48000086 IAU_TYPE_ENGINE_SOFTMICE_V_X86, SoftMice V Engine for Windows
x86
1207959687 0x48000087 IAU_TYPE_ENGINE_SOFTMICE_V_X64, SoftMice V Engine for Windows
x64
1207959688 0x48000088 IAU_TYPE_ENGINE_CLEANBOOT_MBRTOOL_ENGINE_X86, MBR Tool
Engine for Windows x86
1207959689 0x48000089 IAU_TYPE_ENGINE_ENGINE_VSAPI_LINUX_RH6_X86, VSAPI 32-bit
Linux build for RH6

1207959696 0x48000090 IAU_TYPE_ENGINE_ENGINE_TMESD_KERNEL_X86, End-Point Sensor
Kernel Mode Component x86
1207959697 0x48000091 IAU_TYPE_ENGINE_ENGINE_TMESD_KERNEL_X64, End-Point Sensor
Kernel Mode Component x64
1207959698 0x48000092 IAU_TYPE_ENGINE_ENGINE_TMESD_USER_X86, End-Point Sensor User
Mode Component x86
1207959699 0x48000093 IAU_TYPE_ENGINE_ENGINE_TMESD_USER_X64, End-Point Sensor User
Mode Component x64
1207959700 0x48000094 IAU_TYPE_ENGINE_ENGINE_ICRC_HLDR_LINUX86, ICRC Handler for
Linux x86
1207959701 0x48000095 IAU_TYPE_ENGINE_ENGINE_ICRC_HLDR_LINUX64, ICRC Handler for
Linux x64
1207959702 0x48000096 IAU_TYPE_ENGINE_MINI_SIC_ENGINE_X86, Mini Sic engine for
Windows x86
1207959703 0x48000097 IAU_TYPE_ENGINE_MINI_SIC_ENGINE_X64, Mini Sic engine for
Windows x64
1207959704 0x48000098 IAU_TYPE_ENGINE_ENGINE_BEP_SPN2_X86, BEP engine for SPN2
windows x86
1207959705 0x48000099 IAU_TYPE_ENGINE_ENGINE_BEP_SPN2_X64, BEP engine for SPN2
windows x64
1207959706 0x4800009A, IAU_TYPE_ENGINE_ENGINE_SAL_SPN2_X86, SAL engine for SPN2
windows x86
1207959707 0x4800009B IAU_TYPE_ENGINE_ENGINE_SAL_SPN2_X64, SAL engine for SPN2
windows x64
Function type
169 0x000000A9 IAU_TYPE_FUNCTION_FUNCTION_PRO_FEATURES_NAVIGATOR_INTERF
ACE
209 0x000000D1 IAU_TYPE_FUNCTION_FUNCTION_VSAPI_WRAPPER
210 0x000000D2 IAU_TYPE_FUNCTION_FUNCTION_SSAPI_WRAPPER
211 0x000000D3 IAU_TYPE_FUNCTION_FUNCTION_DCE_WRAPPER
212 0x000000D4 IAU_TYPE_FUNCTION_FUNCTION_TMPFW
213 0x000000D5 IAU_TYPE_FUNCTION_FUNCTION_TMPROXY
214 0x000000D6 IAU_TYPE_FUNCTION_FUNCTION_UPDATE
215 0x000000D7 IAU_TYPE_FUNCTION_FUNCTION_IAUUPDATE
216 0x000000D8 IAU_TYPE_FUNCTION_FUNCTION_IM_SCAN
217 0x000000D9 IAU_TYPE_FUNCTION_FUNCTION_LOADHTTP
218 0x000000DA IAU_TYPE_FUNCTION_FUNCTION_SERVER_AGENT
219 0x000000DB IAU_TYPE_FUNCTION_FUNCTION_HOMENETWORK
220 0x000000DC IAU_TYPE_FUNCTION_FUNCTION_HISTORYCLEAN
iAU client type
0 0x00000000 IAU_TYPE_IAUCLIENT_IAU_SDK
18 0x00000012 IAU_TYPE_IAUCLIENT_DETECTOR_PLUGINS, test for selfupdate
112 0x00000070 IAU_TYPE_IAUCLIENT_IAUCORE, iAU 2.0 self-update core component
113 0x00000071 IAU_TYPE_iAURELAY_PRODUCT_iAURELAY
114 0x00000072 IAU_TYPE_iAURELAY_RELAYCORE
Patterns
4 0x00000004 IAU_TYPE_PATTERN_VSAPI
5 0x00000005 IAU_TYPE_PATTERN_SPYWARE_DCT, tmadce.zip
6 0x00000006 IAU_TYPE_PATTERN_DCT, tscptn.zip
8 0x00000008 IAU_TYPE_PATTERN_ENT_LEGACY, lvsapi.zip
512 0x00000200 IAU_TYPE_PATTERN_GSS
2048 0x00000800 IAU_TYPE_PATTERN_TSC
65537 0x00010001 IAU_TYPE_PATTERN_PATTERN_TMAS_NO_HASH_PATTERN
524288 0x00080000 IAU_TYPE_PATTERN_VA_X86
1048576 0x00100000 IAU_TYPE_PATTERN_VA_DATABASE
48040023 0x02DD0857 IAU_TYPE_PATTERN_AEGIS_2_6_APEM_PATTERN_FOR_EN_US, AEGIS

2.6 APEM Pattern for en-US
67108865 0x04000001 IAU_TYPE_PATTERN_PATTERN_TMAS_WITH_HASH_PATTERN
536870913 0x20000001 IAU_TYPE_PATTERN_NSC
536870944 0x20000020 IAU_TYPE_PATTERN_INTELLITRAP
536870976 0x20000040 IAU_TYPE_PATTERN_INTELLITRAP_EXCEPTION
536871936 0x20000400 IAU_TYPE_PATTERN_VSAPI_SPYWARE
536903680 0x20008000 IAU_TYPE_PATTERN_VA_X64
1073741840 0x40000010 IAU_TYPE_PATTERN_SSAPI_DA6
1073741856 0x40000020 IAU_TYPE_PATTERN_AEGIS_POLICY_EN_US
1073741888 0x40000040 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_EN_GB, Pattern:AEGIS
policy
1073741952 0x40000080 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_TW
1073742080 0x40000100 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_CN
1073742336 0x40000200 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_JP
1073742848 0x40000400 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_FR
1073743872 0x40000800 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_DE
1073745920 0x40001000 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_ES
1073750016 0x40002000 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_IT
1073758208 0x40004000 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_NL
1073774592 0x40008000 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_SV
1073807360 0x40010000 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_DA
1073872896 0x40020000 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_NO
1074003968 0x40040000 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_PT, Pattern:AEGIS policy
PT
1074266112 0x40080000 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_RU
1082130432 0x40800000 IAU_TYPE_PATTERN_AEGIS_WHITE_LISTING
1090519040 0x41000000 IAU_TYPE_PATTERN_AEGIS_CONFIG
1207959552 0x48000000 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_ZH_HK
1207959553 0x48000001 IAU_TYPE_PATTERN_PATTERN_AEGIS_POLICY_FR_CA
1207959808 0x48000100 IAU_TYPE_PATTERN_TMUFE_CODE_EXAM_PATTERN
1207961600 0x48000800 IAU_TYPE_PATTERN_PATTERN_AEGIS_2_5_BM_WHITE_LISTING_OEM_A
U_PATTERN
1207963648 0x48001000 IAU_TYPE_PATTERN_PATTERN_AEGIS_BM_CONFIGURATION_OEM_AU_
PATTERN
1208090624 Smart Scan Agent pattern
1208221696 0x48040000 IAU_TYPE_PATTERN_PATTERN_PRE_SCAN
1208221698 0x48040002 IAU_TYPE_PATTERN_PATTERN_AEGIS_2_6_APEM_PATTERN_FOR_ZH_T
W
1208221699 0x48040003 IAU_TYPE_PATTERN_PATTERN_AEGIS_2_6_APEM_PATTERN_FOR_ZH_C
N
1208221731 0x48040023 IAU_TYPE_PATTERN_PATTERN_AEGIS_2_6_APEM_PATTERN_FOR_EN_U
S
1208221734 0x48040026 IAU_TYPE_PATTERN_MAC
1208221735 0x48040027 IAU_TYPE_PATTERN_TB_IPS_SERVERS
1208221736 0x48040028 IAU_TYPE_PATTERN_APEC_TMBLACK
1208221737 0x48040029 IAU_TYPE_PATTERN_BM_POLICY_PT_PT
1208221744 0x48040030 IAU_TYPE_PATTERN_HC_BEHAVIOR_RULE
1208221745 0x48040031 IAU_TYPE_PATTERN_HC_VSAPI_BETA
0x48040033 IAU_TYPE_PATTERN_TMUFE_FULL_SPN
0x48040034 IAU_TYPE_PATTERN_TMUFE_PATCH_SPN
1208221749 0x48040035 IAU_TYPE_PATTERN_LCE_PTN
0x48040038 IAU_TYPE_PATTERN_TMSA, Script Analyzer Lineup Pattern
1208221762 0x48040042 IAU_TYPE_PATTERN_AMSP_EXCP_GLBTM
1208221763 0x48040043 IAU_TYPE_PATTERN_AMSP_EXCP_GLBOEM
1208221764 0x48040044 IAU_TYPE_PATTERN_AMSP_EXCP_LocOEM
0x48040045 IAU_TYPE_PATTERN_BM_POLICY_EL, AEGIS2.0 POLICY Pattern for
language Greek
0x48040046 IAU_TYPE_PATTERN_BM_POLICY_HE, AEGIS2.0 POLICY Pattern for

language Hebrew (HE)
0x48040047 IAU_TYPE_PATTERN_BM_POLICY_AR, AEGIS2.0 POLICY Pattern for
language Arabic (AR)
0x48040048 IAU_TYPE_PATTERN_BM_POLICY_TH, AEGIS2.0 POLICY Pattern for
language Thai (TH)
0x48040049 IAU_TYPE_PATTERN_BM_APEM_EL, AEGIS2.0 APEM Pattern for
language Greek (EL)
0x48040050 IAU_TYPE_PATTERN_BM_APEM_HE, AEGIS2.0 APEM Pattern for
language Hebrew (HE)
0x48040051 IAU_TYPE_PATTERN_BM_APEM_AR, AEGIS2.0 APEM Pattern for
language Arabic (AR)
0x48040052 IAU_TYPE_PATTERN_BM_APEM_TH, AEGIS2.0 APEM Pattern for
language Thai (TH)
0x48040053 IAU_TYPE_PATTERN_DRE, Damage Recovery Engine Pattern
1208221780 0x48040054 IAU_TYPE_PATTERN_AMSP_LES
1208221784 0x48040058 IAU_TYPE_PATTERN_NCIE_NVP, Network Virus and Vulnerability
Pattern
1208221785 0x48040059 IAU_TYPE_PATTERN_NCIE_RR, Relevant Rule Pattern
1208221792 0x48040060 IAU_TYPE_PATTERN_PEDIF_EXCP_GLBTM, PeDif global exception
pattern
1208221793 0x48040061 IAU_TYPE_PATTERN_PEDIF_EXCP_GLBOEM, PeDif OEM exception
pattern
1208221794 0x48040062 IAU_TYPE_PATTERN_PEDIF_EXCP_LOCOEM, PeDif local exception
pattern
1208221795 0x48040063 IAU_TYPE_PATTERN_PEDIF_CFG_GLBTM, PeDif global configuration
pattern
1208221796 0x48040064 IAU_TYPE_PATTERN_PEDIF_CFG_GLBOEM, PeDif OEM configuration
pattern
1208221797 0x48040065 IAU_TYPE_PATTERN_PEDIF_CFG_LOCOEM, PeDif local configuration
pattern
1208221798 0x48040066 IAU_TYPE_PATTERN_SOFTMICE, SoftMice pattern - smvptn.XXX
1208221799 0x48040067 IAU_TYPE_PATTERN_IDENTITYSAFE_DOMAIN, IDENTITYSAFE domain
pattern update
1208221800 0x48040068 IAU_TYPE_PATTERN_MEMORY_SCAN_TRIGGER, Pattern for memory
scan trigger-Tmmst.ptn
1208221801 0x48040069 IAU_TYPE_PATTERN_THREAT_TRACE, Pattern for Pattern for threat
trace- Tmtt.ptn/Tmtt64
1208221808 0x48040070 IAU_TYPE_PATTERN_BEP, Browser Exploit Prevention
1208221809 0x48040071 IAU_TYPE_PATTERN_CENSUS, Census binary files
1208221810 0x48040072 IAU_TYPE_PATTERN_ANDROID_V2, Android pattern file v2
1208221811 0x48040073 IAU_TYPE_PATTERN_ENDPOINT_SENSOR_PROFILE_METADATA, SPN
2.0 Endpoint Sensor profile metadata
1208221812 0x48040074 IAU_TYPE_PATTERN_PATTERN_IDENTITYSAFE_AUTOFORMFILL, Used
for IDENTITYSAFE AUTOFORMFILL pattern update
1208221813 0x48040075 IAU_TYPE_PATTERN_PATTERN_AEGIS_THREAT_BEHAVIOR_SENSOR,
Threat-Behavior-Sensor pattern of AEGIS for SPN 2.0
1208221814 0x48040076 IAU_TYPE_PATTERN_PATTERN_THREAT_CORRELATION, Pattern for
Trend Micro Threat Correlation Rules
1208221815 0x48040077 IAU_TYPE_PATTERN_PATTERN_THREAT_KNOWLEDGEBASE_EN, Threat
knowledge base for Threat correlation rules EN
1208221816 0x48040078 IAU_TYPE_PATTERN_PATTERN_THREAT_KNOWLEDGEBASE_ZH_CN,
Threat knowledge base for Threat correlation rules ZH_CN
1208221817 0x48040079 IAU_TYPE_PATTERN_PATTERN_THREAT_KNOWLEDGEBASE_ZH_TW,
Threat knowledge base for Threat correlation rules ZH_TW
1208221824 0x48040080 IAU_TYPE_PATTERN_PATTERN_THREAT_KNOWLEDGEBASE_KO, Threat
knowledge base for Threat correlation rules KO
1208221825 0x48040081 IAU_TYPE_PATTERN_PATTERN_THREAT_KNOWLEDGEBASE_JP, Threat
knowledge base for Threat correlation rules JP
1208221826 0x48040082 IAU_TYPE_PATTERN_PATTERN_THREAT_DETECTION_X64, Threat-

Detection pattern of AEGIS for 64 bit platform
1208221827 0x48040083 IAU_TYPE_PATTERN_PATTERN_NCIE_APPID, Network Content
Inspection 2.0 for Application ID
1208221828 0x48040084 IAU_TYPE_PATTERN_PATTERN_MOBILE_GATEWAY, Pattern For Mobile
Gateway Product 32/64 bit
1208221829 0x48040085 IAU_TYPE_PATTERN_PATTERN_BEP_SPN2, BEP pattern for SPN2
1208221830 0x48040086 IAU_TYPE_PATTERN_PATTERN_SAL_SPN2, SAL pattern for SPN2
Test type
1 0x00000001 IAU_TYPE_TEST_PRODUCT001
2 0x00000002 IAU_TYPE_TEST_TEST_COMPONENT
Program types
1301 0x00000515 IAU_TYPE_PROGRAM_AMSP_PROGRAM_X86
1302 0x00000516 IAU_TYPE_PROGRAM_AMSP_PROGRAM_X64
1303 0x00000517 IAU_TYPE_PROGRAM_CLEANBOOT_MODULE_X86, Startup module
which launches the CleanBoot program in Linux
1304 0x00000518 IAU_TYPE_PROGRAM_CLEANBOOT_OS_X86, Linux OS which contains
the boot files, libaries, and tools
1306 0x00000520 IAU_TYPE_PROGRAM_CPM10_SPN, Product AUID for SPN backend to
identify the SPN feedback
Patch types
1401 0x00000579 IAU_TYPE_PATCH_AMSP_PATCH_X86
1402 0x0000057A IAU_TYPE_PATCH_AMSP_PATCH_X64
Security Patch types
1501 0x000005DD IAU_TYPE_SECURITY_PATCH_AMSP_SECURITY_PATCH_X86
1502 0x000005DE IAU_TYPE_SECURITY_PATCH_AMSP_SECURITY_PATCH_X64
Rootkitbuster product type
1900 0x0000076C IAU_TYPE_ROOTKITBUSTER_PRODUCT_ROOTKITBUSTER_PRODUCT
Identity product type
2100 0x00000834 IAU_TYPE_IDENTITYSAFE_PRODUCT_IDENTITYSAFE_PROUDUCT
2101 0x00000835 IAU_TYPE_IDENTITYSAFE_RESOURCE
2102 0x00000836 IAU_TYPE_IDENTITYSAFE_PATCHTOOL, Used for IDENTITYSAFE UI
program update
2103 0x00000837 IAU_TYPE_IDENTITYSAFE_PROGRAM_PACKAGE, Used for
IDENTITYSAFE product program update
Deep Security
2200 0x00000898 IAU_TYPE_DEEPSECURITY_PRODUCT_DEEPSECURITY_AGENT */
2201 0x00000899 IAU_TYPE_DEEPSECURITY_PRODUCT_DEEPSECURITY_VIRTUAL_APPLIA
NCE
2202 0x0000089A IAU_TYPE_DEEPSECURITY_PRODUCT_DEEPSECURITY_RELAY
2203 0x0000089B IAU_TYPE_DEEPSECURITY_PRODUCT_DEEPSECURITY_MANAGER
2211 0x000008A3 IAU_TYPE_DEEPSECURITY_PRODUCT_MANIFEST
2212 0x000008A4 IAU_TYPE_DEEPSECURITY_RELAY_MANIFEST
2213 0x000008A5 IAU_TYPE_DEEPSECURITY_PRODUCT_DEEPSECURITY_RULE_UPDATES,
DEEPSECURITY Rule Updates
Endpoint sensor client type
2600 0x00000A28 IAU_TYPE_PRODUCT_ENDPOINT_SENSOR_CLIENT, for SPN2
F.3 > Language codes

-1 -0x00000001 IAU_LANGUAGE_IGNORE
1 0x00000001 IAU_LANGUAGE_ENU
2 0x00000002 IAU_LANGUAGE_CHT, Traditional Chinese (Taiwan)
4 0x00000004 IAU_LANGUAGE_JPN, Japanese

8 0x00000008 IAU_LANGUAGE_CHS, Simplified Chinese (PRC)
16 0x00000010 IAU_LANGUAGE_KR, Korean
32 0x00000020 IAU_LANGUAGE_DEU, Germany
64 0x00000040 IAU_LANGUAGE_FRA, French
128 0x00000080 IAU_LANGUAGE_ESP, Spain
256 0x00000100 IAU_LANGUAGE_PT, Portuguese
512 0x00000200 IAU_LANGUAGE_ITA, Italy
8192 0x00002000 IAU_LANGUAGE_RUS, Russian
16384 0x00004000 IAU_LANGUAGE_NL, Netherlands/Dutch
65536 0x00010000 IAU_LANGUAGE_EN_GB, Great Britain
131072 0x00020000 IAU_LANGUAGE_SV, Swedish
262144 0x00040000 IAU_LANGUAGE_NO, Norwegian
524288 0x00080000 IAU_LANGUAGE_DA, Danish
1048576 0x00100000 IAU_LANGUAGE_FR_CA, for FR_CA
2097152 0x00200000 IAU_LANGUAGE_HK, HK_Chinese
4194304 0x00400000 IAU_LANGUAGE_EN_APAC, APAC English
8388608 0x00800000 IAU_LANGUAGE_PT_PT, APAC English
16777216 0x01000000 IAU_LANGUAGE_TR
4096 0x00001000 IAU_LANGUAGE_POL, Polish
33554432 0x02000000 IAU_LANGUAGE_FIN, Finnish
67108864 0x04000000 IAU_LANGUAGE_EL, Greek
134217728 0x08000000 IAU_LANGUAGE_CS, Czech
369098752 0x16000000 IAU_LANGUAGE_HE, Hebrew
838860800 0x32000000 IAU_LANGUAGE_AR, Arabic Saudi Arabia
1677721600 0x64000000 IAU_LANGUAGE_TH, Thai
1677721601 0x64000001 IAU_LANGUAGE_VN, Vietnamese
1677721602 0x64000002 IAU_LANGUAGE_ID, Indonesia
F.4 > Region codes

-1 -0x00000001 IAU_REGION_IGNORE
1 0x00000001 IAU_REGION_GLOBAL
2 0x00000002 IAU_REGION_US
3 0x00000003 IAU_REGION_JAPAN
4 0x00000004 IAU_REGION_EMEA
5 0x00000005 IAU_REGION_APAC
F.5 > Platform codes

-1 -0x00000001 IAU_PLATFORM_ALL
1 0x00000001 IAU_PLATFORM_WIN32
5889 0x00001701 IAU_PLATFORM_WIN64
7389 0x00001CDD IAU_PLATFORM_CentOS_5_64, CentOS 5.x & RHEL5 (64bit)
257 0x00000101 IAU_PLATFORM_LINUX86, Linux (32bit)
9217 0x00002401 IAU_PLATFORM_LINUX64, Linux (64bit)
F.6 > OEM codes

-1 -0x00000001 IAU_OEM_IGNORE
0 0x00000000 IAU_OEM_IAU_CIENT_OEM
1 0x00000001 IAU_OEM_RETAIL
2 0x00000002 IAU_OEM_TMOS
3 0x00000003 IAU_OEM_NEC
4 0x00000004 IAU_OEM_SHARP
5 0x00000005 IAU_OEM_TOSHIBA, Toshiba OEM
6 0x00000006 IAU_OEM_FUJITSU, Fujitsu OEM
7 0x00000007 IAU_OEM_NTT_EAST, NTT East JP
8 0x00000008 IAU_OEM_NTT_WEST, NTT West JP
9 0x00000009 IAU_OEM_NTT_EAST_NGN, NTT East NGN JP
10 0x0000000A IAU_OEM_NTT_WEST_NGN, NTT West NGN JP
11 0x0000000B IAU_OEM_DELL, Dell OEM
12 0x0000000C IAU_OEM_BEST_BUY, Best Buy
13 0x0000000D IAU_OEM_ASUS, OEM
14 0x0000000E IAU_OEM_NTT_East_SOHO, NTT East SOHO
15 0x0000000F IAU_OEM_NTT_West_SOHO, NTT West SOHO
16 0x00000010 IAU_OEM_SONY, SONY OEM
1000 0x000003E8 IAU_OEM_CHINA_PATTERN, For China Pattern
1001 0x000003E9 IAU_OEM_NOCAT, VSAPI Driver (E.10) without CAT
1002 0x000003EA IAU_OEM_TIS_STD_17_1, TIS_STD_17.1
1003 0x000003EB IAU_OEM_TAV_17_1, TAV_17.1
1004 0x000003EC IAU_OEM_TIS_PRO_17_1, TIS_PRO_17.1
1005 0x000003ED IAU_OEM_TIS_17_2, TIS_17.2
1006 0x000003EE IAU_OEM_TIS_PRO_17_2, TIS_PRO_17.2
1007 0x000003EF IAU_OEM_TAV_17_2, TAV_17.2
1008 0x000003F0 IAU_OEM_NTT_EAST_STD_NGN, NTT East (Std & NGN)
1009 0x000003F1 IAU_OEM_NTT_WEST_STD_NGN, NTT West (Std & NGN)
1010 0x000003F2 IAU_OEM_SPN_CN, SPN China Pattern
1011 0x000003F3 IAU_OEM_PHILIPS, Philips
1012 0x000003F4 IAU_OEM_SPECIAL_VENDOR
1013 0x000003F5 IAU_OEM_TAV_17_5, TAV_17.5
1014 0x000003F6 IAU_OEM_TIS_17_5, TIS_17.5
1015 0x000003F7 IAU_OEM_TISPRO_17_5, TISPRO_17.5
1016 0x000003F8 IAU_OEM_PCOEM, OEM for Fujitsu.Nec,Sharp,Toshiba
17 0x00000011 IAU_OEM_WHITE_BOX, OEM for White Box
18 0x00000012 IAU_OEM_VBSE, OEM for VBSE
19 0x00000013 IAU_OEM_HINET, OEM for HINET
1019 0x000003FB IAU_OEM_NEC_17_5, OEM for White Box
1020 0x000003FC IAU_OEM_SHARP_17_5, OEM for VBSE
1021 0x000003FD IAU_OEM_TOSHIBA_17_5, OEM for HINET
1022 0x000003FE IAU_OEM_FUJITSU_17_5, OEM for HINET
1023 0x000003FF IAU_OEM_Best_Buy_TAV_17_50, OEM for TAV BESTBUY 17_50
1024 0x00000400 IAU_OEM_Best_Buy_TIS_17_50, OEM for TIS BESTBUY 17_50
1025 0x00000401 IAU_OEM_RADIAL_POINT, OEM for RADIAL POINT
Appendix G: Command line

interface
G.1 > Appendix overview

Both the DSM and DSA offer administrator command line configuration options. Some options
are duplicates of what is already available on the management console, whereas other are
command-line only functionality.
This appendix is a summary of what can be done through this interface and is divided into the
following sections:
● DSM command line interface
● DSA command line interface
G.2 > DSM command line interface

To access the DSM command line interface, run the following application
<install path>\Trend Micro\Deep Security Manager\dsm_c.exe.
The syntax for this tool is as follows:
dsm_c –action <action name>
The following table presents what administrators can do with this tool
Objective Syntax
Change setting dsm_c -action changesetting -name NAME -value VALUE
For example, to change the agent socket timeout,

administrators can enter the following:
dsm_c -action changesetting -name

configuration.agentSocketTimeoutOverride -value 500
Reset the events tables dsm_c -action resetevents -type [all|fw|dpi|im|li]
(Reset back to an empty

state)
Rest counter tables dsm_c -action resetcounters
Rest back to an empty state)
Create insert statements dsm_c -action createinsertstatements [-file FILEPATH] [-

generateDDL] [-databaseType sqlserver|oracle] [-
For export to a different maxresultfromdb count]
database)
Set manager port(s) dsm_c -action setports [-managerPort port] [-heartbeatPort

port]
Create a diagnostic package dsm_c -action diagnostic

for the system
Trust the certificate of a dsm_c -action trustdirectorycert -directoryaddress

directory DIRECTORYADDRESS -directoryport DIRECTORYPORT [-
username USERNAME] [-password PASSWORD]
Reindex help system dsm_c -action reindexhelp
If the DSM online-help system becomes inaccessible after

an update, this command can be used to restore access.
This is rarely used.
G.3 > DSA command line interface

To access the DSA command line interface, run the following application
<install path>\Trend Micro\Deep Security Agent\dsa_control.exe
The syntax for this tool is as follows:
dsa_control /<parameter> <string>
The following table presents what administrators can do with this tool
Objective Syntax
Activate agent with a specific Windows: dsa_control /a dsm://<host or IP>:<port>/
DSM
Linux: dsa_control –-activate=dsm://<host or IP>:<port>/
The value “port” refers to the DSM heartbeat port, which is

“4120” by default
Set the Agent URL Windows: dsa_control /g <URL>
Linux: dsa_control –-agent <URL>
Default URL is “https://127.0.0.1:4118”
This is used if the DSA uses a non-standard communication

port, which is 4118 by default. Dsa_control needs this
information to be able to communicate with DSA during
activation/deactivation.
This parameter is used in conjuction with “/a” and “/r”.
Certificate file Windows: dsa_control /c <str>
Linux: dsa_control -–cert=<str>
This is used if the DSA is installed a non-standard location,

and the DSA control utility cannot locate its credential file
(ds_agent.crt) which it used for the initial SSL connection.
Will not be necessary in Windows machines since
dsa_control will reference the Windows Registry to
determine the installation path.
This parameter is used in conjuction with “/a” and “/r”.
Reset agent configuration Windows: dsa_control /r
Linux: /opt/ds_agent/dsa_control –r
/opt/ds_agent/dsa_control --reset
This returns the DSA to an “out-of-the-box” state, with no

configuration, and no DSM. It is similar to the deactivate
command issued from the DSM console. The “Deactivate”
command used to be called “Reset agent configuration”,
hence the use of “r” in this parameter
The DSM will not be notified of the deactivation.

Administrators will only know of this event when the DSM
reports communication errors.
This feature is useful for manually transferring the DSA

from one DSM to another.
Generate diagnostic package dsa_control /d or --diag
Generates a diagnostic package for the DSA. The resulting

package will not include log files, and will be generated in
the diags folder.
Generate a update resource dsa_control -b

bundle
Generates a zip file that can be used to update DSRs
without access to an update server. Copy this file to main
directory of a DSR, and then command the DSR to perform
an update. If the relay cannot connect to an update site, it
will check its local folder for this bundle.
Activate / deactivate Agent To enable: dsa_control -–harden=1 -–passwd=passwordhere

Self Protection
To disable: dsa_control -–harden=0 --passwd=passwordhere
Appendix H: AMSP reference
H.1 > Appendix overview

This appendix contains the following information about AMSP
● AmspConfig.ini reference
● AMSP component IDs
H.2 > AmspConfig.ini reference

Parameters with AmspConfig.ini define how AMSP writes information into its debug log. The
following table explains these parameters
Parameter Description
DebugLevel Valid values are:

0 – disable log
1 – Performance log
2 – Detailed information
3 – Warning messages (default)
4 – Unused
7 – all output options
DebugFlag 1 – file
2 – console
4 – debug string
7 – all output options
DebugLogFilePath Absolute path for the debug log folder. By default, this is:
C:\Program Files\Trend Micro\AMSP\debug
DebugLogFilePrefix Prefix used in the AMSP debug log name. By default this is
“Amsp”, so debug logs are named Amsp_*.log
DebugLogFileMaxSize Default value is 52,428,800. Valid values are from 1 to 100MB
DebugLogFileMaxCount Maximum number of files that can be generated for each AMSP
module log. Acceptable values are from 1 to 10
DebugLogAMSPServiceStart 0 – Do not start AMSP_LogServer.exe with the AMSP service

1 – Start AMSP_LogServer.exe with the AMSP service
Plugin <plugin name> Defines debug levels for individual AMSP plug-ins
DebugLevel
A sample log entry appears below:
found!, file path: \\?\c:\Users\Administrator\My
Documents\target\eicar\eicar.com,[.\AMSP_VsapiProcessFileCallback.cpp(186)]
Logs use the following structure
YYYY/MM/DD HH:MM:SS, [Process ID: Thread ID], [Severity], [Module name], Debug message,
[Source file name (Line number)]
Administrators can enable debugging for all or individual modules. To enable individual logging,
each module must have their own section in Amsp_Config.ini like the one below:
[Plugin VSAPI]
DebugMode=1
DebugLevel=2
DebugFlag=1
DebugLogFilePath=.\debug\
DebugLogFilePrefix=PluginVSAPI
The following table presents valid names for these sections
Module Plugin Name Module Plugin Name
Action Manager Core Action Manager Real-Time Scan Flow Plugin Realtime Scan
Controller Flow
Command Manager Core Command
Manager Report Manager Core Report Manager
DCE Wrapper Plugin DCE Wrapper Scan Manager Core Scan Manager
Event Manager Core Event Manager Service Shell Core Service Shell
Framework Host Core Framework Host SSAPI Wrapper Plugin SSAPI
ICRC Handler Plugin ICRC TMFBE Wrapper Plugin TMFBE

Wrapper
Update Manager Core Update Manager
Manual Scan Flow Plugin Manual Scan
Controller Flow VAPI Wrapper Plugin VSAPI
H.3 > AMSP component IDs

AMSP components are stored in the following location: <install path>\Trend
Micro\AMSP\module.
Each component is assigned an ID number, which is also used as the name of its sub-folder
under the module folder. For example, the AMSP module responsible for updating AMSP
components is called the coreUpdateManager.dll. Its ID is “7”, so it is stored in sub-folder “7”:
The following table provides the ID numbers for other components.
ID File
1 coreFrameworkBuilder.dll
2 coreCommandManager.dll
3 coreEventManager.dll
4 coreTaskManager.dll
5 coreConfigRepository.dll
6 coreReportManager.dll
7 coreUpdateManager.dll
10 coreActionManager.dll
11 coreScanManager.dll
10000 plugEngineVSAPI.dll
10001 plugEngineSSAPI.dll
10002 plugEngineDCE.dll
10007 plugEngineTMFBE.dll
10008 plugEngineICRC.dll
10015 plugEngineWL.dll
10016 plugEngineSMV.dll
20001 plugAdapterSystem.dll
30000 plugRealtimeScanFlow.dll
30001 plugManualScanFlow.dll
30004 plugRealTimeScanCache.dll
30006 plugCommonScanCache.dll
40000 plugUtilRCM.dll
40001 plugUtilEnum.dll
40002 plugUtilSysInfo.dll
40003 plugUtilException.dll
Appendix I: Configuration file

reference
I.1 > Appendix overview

This document relies on debug logs to illustrate key operating concepts in Deep Security. To
better understand how these debug logs are generated, and to make the most of the information
contained therein, this chapter focuses on Deep Security debugging functionality. It is divided
into the following sections:
● Naming convention
● Enabling Deep Security logging
● Circular logging
I.2 > Naming convention

The debug log is named as follows:
<debug log name><sequence number>.log
The default log name is “server”, and is defined by the following entry in the logging.properties
file:
# default file output is in user's home directory.
java.util.logging.FileHandler.pattern = DSMROOTPATH/server%g.log
java.util.logging.FileHandler.limit = 10000000
java.util.logging.FileHandler.count = 5
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter
java.util.logging.FileHandler.append = true
Administrators can rename the debug log by replacing “server” with the desired name.
I.3 > Enabling Deep Security logging

1. Locate the logging.properties file. This is typically found in the following location:
<Install path>/Deep Security Manager/jre/lib
2. Add the following line:
com.thirdbrigade.level = ALL
3. OPTIONAL: Modify the name of the debug log as follows:
C:/Program Files/Trend Micro/Deep Security Manager/<alternative name>%g
I.4 > Circular logging

The following illustration shows a sample of server0.log that had been renamed to
“recommend”, to facilitate Recommendation scanning research.
By default, the Java framework only writes to the log file until it reaches 9,766KB as shown
above. Once a log reaches this limit, the framework changes the sequence number of file and
creates a new sequence-zero file. The sample above shows four renaming events.
Appendix J: Answers to
review questions
Chapter 2 answers
1. What is a DSM?
a) Dynamic Security Module
b) Deep Security Manager
c) Deep Security Master
2. What is a DSA?
a) Deep Security Agent
b) Dynamic Security Agent
c) Digital Security Assistant
3. Which database is used for the embedded database?

a) Oracle express
b) MS SQL Express
c) Apache Derby
d) MySQL
4. Which of the following protocols are used for DSM-to-DB communication?

a) RPC
b) Named pipes
c) TCP
d) SOAP
5. Where does the DSM store its database credentials?

a) dsm.properties
b) logging.properties
c) credentials.properties
d) dsm.ini
Chapter 3 answers
1. Which of the following package formats are relevant to DSAs?
a) MSI
b) RPM
c) EXE
d) TAR
2. DSAs can be deployed from the DSM

a) True
b) False
3. Can a DSA be activated from the DSA host?

a) Yes
c) No
4. What database should be used in a production environment?

a) MS SQL
b) Oracle
c) Apache Derby
Chapter 4 answers
1. Which of the following LDAP servers is officially support?
a) Novell eDirectory
b) Apache DS
c) Microsoft Active Directory
d) Open LDAP
2. Which of the following is are supported as a means of adding a host to Computers list?
a) Manually add a host
b) Import host list from Active Directory
c) Discover hosts from an IP range
d) Import host list from WMware Center server
e) All of the above
3. If a computer is deleted from Active Directory, it will ALWAYS be deleted from the DSM Computer list
a) True
b) False
Chapter 5 answers
1. Which of the following security features benefit from Recommendation scanning?
a) Firewall
d) Log Inspection
e) All of the above
2. Can administrators specify the ports that are scanned as part of a port scan?
a) Yes
b) No
3. Which of the following can trigger a recommendation scan?

a) On demand scan
b) Scheduled scan
c) Follow up scan requested as part of the recommendation scan

d) All of the above
4. Which of the following is used as a reference for location awareness functionality?

a) Web server
b) DSM
c) Domain controller
d) A specific IP address
5. Which security features uses all of the component lists?

a) Firewall
c) Application types
d) Port scan
Chapter 6 answers
1. Which features constitute HIPS?
a) Firewall
d) Log Inspection
2. Which features constitute HIDS?

a) Firewall
d) Log Inspection
3. One which OSI layer does HIPS functionality operate?

a) Physical Layer
b) Data-link Layer
c) Network Layer
d) Transport Layer
4. Which mode offers no protection?

a) Tap mode
b) Inline mode
5. What firewall rule action is implemented at the Microfilter?

a) Allow
b) Deny
c) Bypass
Chapter 7 answers
1. How does Integrity Monitoring detect changes?
a) By comparing select system areas with a baseline
b) By referencing a change log
2. Which of the following will trigger an Integrity Monitoring scan?

a) An on-demand request
b) Scheduled task
c) Windows API notification
d) All of the above
3. Which platforms benefit from actual real-time Integrity Monitoring?

a) Microsoft Windows (e.g., XP, 2008, etc.)
b) Linux distributions
c) Solaris
d) AIX
e) HP-UX
Chapter 8 answers
1. What open-source technology is used for Log Inspection functionality?
a) Microsoft .NET
b) OSSEC
c) GNU
2. Which log formats are supported by default log inspection decoders?

a) Syslog
b) Microsoft Windows
c) Squid
d) All of the above
3. How do administrators select which log entries are captured?

a) Log location
b) Log severity
c) Log name
Chapter 9 answers
1. Which of the following are valid firewall actions?
a) Allow
b) Deny
c) Bypass
d) Force allow
e) Log only
f) All of the above
2. If a priority 4 Deny rule conflicts with a priority 3 Force allow rule, which rule will prevail?
a) Deny rule
b) Force allow rule
3. Which action implements an “implicity deny” action?
a) Allow
b) Deny
c) Bypass
Chapter 10 answers
1. Which of the following are valid uses for Deep Packet Inspection
a) Virtual patching
b) Protocol hygiene
c) Application control (limited)
d) All of the above
2. Which of the following describes how DPI works?

a) Traffic from select IP addresses are blocked
b) Packets containing malicious/undesired instructions are blocked
c) Specific protocols are blocked
3. Which Trend Micro pattern contains information that is comparable to DPI rules?
a) VSAPI pattern
b) SSAPI pattern
c) Generic Stream Scanning rules
d) OfficeScan firewall rules
Chapter 11 answers
1. Which of the following is directly responsible for VM protection functionality
a) Deep Security Virtual Appliance
b) Virtual Agent
c) Master Agent
d) vmKernel
2. What is the WMware API that makes DSVA functionality possible?

a) Microsoft .NET
b) VM Safe API
c) Windows API
3. Which features are absent if VM protection is entirely reliant in DSVA?

a) Firewall
d) Log Inspection
Chapter 12 answers
Which of the following is an advantage of Agent-based protection over Agentless (DSVA-only) protection?
a) Lack of resource contention
b) Absence of update-related network traffic
c) Memory scan
If the DSA is unable to perform the configured scan action, what will happen to the suspected malware?
a) Pass
b) Delete
c) Quarantine
d) Re-scan
Chapter 13 answers
1. Which of the following concepts dictates the rate at which information is transferred from the DSA to the DSM?
a) Heartbeat
b) Firewall rules
c) Interface changes
d) All of the above
2. Which of the following are valid communication modes?

a) Bi-directional
b) Manager-initiated
c) Agent-initiated
d) All of the above

a) Registration
b) Activation
c) Melding
d) Binding
Chapter 14 answers
1. What database does the DSA use for local Log Inspection and Integrity Monitoring event storage?
a) Apache Derby
b) MS SQL
c) SQLLite3
d) MySQL
2. Which event monitoring system receives event information in near real-time?

a) Deep Security Manager
b) Syslog
c) Control Manager
d) All of the above
3. Which report format can require a password to read the report?

a) RTF
b) Excel
c) PDF
Index
6to4 ............................................................. 116 Integrity Monitoring, agentless .................... 230

ACK ............................................................ 448 port............................................................ 58, 431
ACK Storm .................................................. 456 updating ........................................................... 336
activation usage ................................................................ 322
agent initiated..................................................507 DSVA .......................................................... 196
basics ................................................................296 coordinated approach ................................... 411
AIX .......................................................... 33, 53 operation ......................................................... 203
AMSP .......................................................... 234 protected VMs................................................ 223
Anti-Malware Solution Platform ...... See AMSP service pack, Microsoft Windows ............... 411
Apache
FIN .............................................................. 448
Derby ................................................................. 39 firewall
attribute bypass .................................................. See bypass
Integrity ...........................................................132 Firewall
baseline about ................................................................ 113
Integrity ...........................................................132 fragmentation .............................................. 446
BF.ptn ............................... See smart query filter hash
bypass SHA-1 .............................................................. 132
about ................................................................164 SHA-256.......................................................... 132
database ............................................................. 45 heartbeat
Common Criteria......................................... 472 definition ......................................................... 290
CRC ............................................................ 391 frequency ......................................................... 292
analogy .............................................................393 interval, default ............................................... 292
cache........................................................ 402, 405 randomization ................................................ 293
Part 1 ....................................................... 391, 399 HIDS
Part 2 ................................................................391 Integrity Monitoring ...................................... 126
credibility scores Log inspection ................................................ 142
about ................................................................274 high-availability ............................................. 45
rating servers ...................................................275 Host Intrusion Detection System ...... See HIDS
Cross Site Scripting .................................... 186 HP-UX..................................................... 33, 53
Cyclic Redundancy Check.................... See CRC HTTP encoding ........................................... 188
database iAU .............................................................. 320
high-availability ................................................. 45 basics ................................................................ 326
dbo.components ......................................... 339 client................................................................. 324
dbo.hostcomponents .................................. 339 log ..................................................................... 325
DCE .................................................... 236, 237 relay .................................................................. 324
Deep packet inspection
SDK ................................................................. 324
about ................................................................113
icrc$oth .................. See smart scan agent pattern
Deep Packet Inspection...................... See DPI
Integrity monitoring
Deep Security Relay .......................... See DSR
Deep Security Virtual Appliance ...... See DSVA about ................................................................ 113
Derby ..................................See Apache Derby attributes.......................................................... 132
DPI .............................................................. 176 baseline ............................................................ 132
SSL, compression...........................................181 rule ................................................................... 133
ds_agent.conf ............................................. 294 Intelligent ActiveUpdate ....................... See iAU
ds_agent.ini ........................................ 294, 413 in-the-wild ................................................... 393
dsa_mpnp ........................................... 168, 181 verification ...................................................... 398
dsm.properties .............................................. 40 Intrusion Defense Firewall .................. 478, 479
DSR IPv6
basics ................................................................320 6to4 .................................................................. 116
iAU SDK .........................................................324 firewall ............................................................. 172
Teredo..............................................................116 Rootkit Common Module .................. See RCM

Java Database Connectivity ......................... 40 RST............................................. 162, 168, 452
JDBC ............See Java Database Connectivity rule
Known issues exploit .............................................................. 178
firewalls ............................................................387 HTTP encoding ............................................. 188
logs, alerts, reports .........................................416 Integrity monitoring ...................................... 133
LDAP ............................................................ 70 smart ....................................................... 178, 179
Linux vulnerability .................................................... 178
/dev .................................................................... 28 web server ....................................................... 189
/etc/init.d.......................................................... 29 scan handlers ............................................. 239
/proc .................................................................. 28 Scan Manager ............................................ 238
DSVA...............................................................474 script ...................................... See Linux, script
script, start/stop ............................................... 28 SHA-1 ......................................................... 132
Log inspection SHA-256 ..................................................... 132
about ................................................................113 smart query filter ......................................... 400
logging.properties ....................................... 514 false positive percentage ............................... 400
Logging.properties ...................................... 352 Smart scan
Microsoft Windows operation ......................................................... 397
agent ................................................................... 61 pattern.............................................................. 407
service pack .....................................................411 smart scan agent pattern ............................ 398
system requirements ........................................ 52 SMTP .......................................................... 308
Netfilter API................................................... 32 Solaris ..................................................... 32, 53
NMAP ................................................. 168, 452 SQL injection .............................................. 186
OfficeScan SQLLite ....................................... 131, 133, 145
stateful inspection ..........................................387 SSAPI ................................................. 236, 237
Open Source Security .................. See OSSEC SSL
OSSEC ....................................................... 146 compression, limitation ................................ 181
packed malware.......................................... 258 configuration .................................................. 377
packet stateful configuration .................................. 169
fragmentation .................................................446 stateful inspection
password OfficeScan, comparison ............................... 387
console, recovery............................................290 SuSE
report, access ..................................................316 agent ................................................................... 62
pattern SYN ............................................................ 448
smart scan........................................................407 TAPS ............ See Time-based Access Pattern
port Sequential hypothesis testing
4118 ..................................................................293 TCP
4119 ..................................................................288 ACK ................................................................. 448
4120 ..................................................................293 flag ........................................................... 161, 448
4122 .................................................................... 58 state .................................................................. 448
DSA.................................................................... 26 SYN ................................................................. 448
DSM ................................................................... 26 Teardrop ..................................................... 116
template
list .....................................................................103
report ............................................................... 314
management console ....................................... 26
Teredo ........................................................ 116
open........................................................... 93, 452 thread
scanning ............................................................. 94 priority ............................................................. 128
POSIX ......................................................... 128 Time-based Access Pattern Sequential
ratings servers hypothesis testing ................................... 461
about ................................................................275 URL filtering engine .................................... 275
RCM ............................................................ 237 vacuum package ........................................ 474
reconnaissance scan .................................. 119 virtual agent ................................................ 223
reconnaissance scanning ........................... 452 Virtual agent .............................................. 197
Red Hat Virtual patching ........................................... 176
agent ................................................................... 62
virus info ..................................................... 405 What's new

vMotion ....................................................... 229 Service Pack 1........................................ 472, 475
VMware version 5 .......................................................... 479
adding machines ............................................... 84 version 6 .......................................................... 478
VSAPI ................................................. 236, 237 version 7 .......................................................... 477
web threats XSS............................ See Cross Site Scripting
protection against ...........................................274
Webservice API ............................................ 36

DS8 STS 20feb2012 PDF

Uploaded by

Document Information

Original Title

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

DS8 STS 20feb2012 PDF

Uploaded by

Copyright:

Available Formats

Trrend

Copyright © 2012 Trend Micro Incorporated. All rights reserved.

Trainer/Writer: Calvin Mangubat

Released: February 2012 v1.1

2 CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL © 2012 Trend Micro Inc.

© 2012 Trend Micro Inc. CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL 3

4 CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL © 2012 Trend Micro Inc.

© 2012 Trend Micro Inc. CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL 5

3.4.4 Agent upgrades ........................................................................... 64

6 CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL © 2012 Trend Micro Inc.

7.5.1 Why bother with automatic tags? ................................................ 139

© 2012 Trend Micro Inc. CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL 7

11.2.1 Instant-on protection ................................................................ 197

8 CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL © 2012 Trend Micro Inc.

13.4 > Communication................................................................................. 293

© 2012 Trend Micro Inc. CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL 9

15.7 > iAU folders ........................................................................................ 343

10 CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL © 2012 Trend Micro Inc.

Appendix D: About widgets ..................................................................................... 486

© 2012 Trend Micro Inc. CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL 11

© 2012 Trend Miicro Inc. CONFIDEN

1.3 > How to Use This Material

14 CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL © 2012 Trend Micro Inc.

© 2012 Trend Miicro Inc. CONFIDEN

2.1 > Chapter overview

2.2 > What’s new

NOTE For information about features and enhancements introduced in previous

2.2.1 External enhancements

16 CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL © 2012 Trend Micro Inc.

● Improved Trojan / memory-resident malware scanning – malware process and

© 2012 Trend Micro Inc. CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL 17

● Removal of configurable “second action” – this behavior is dictated by AMSP. If the

18 CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL © 2012 Trend Micro Inc.

upport – this version now supports iAU (Intelligent Active

Directt and via-Manager syslog g options – relaying syslog messages

© 2012 Trend Miccro Inc. CONFIDEN

Version 7.5, Service Pack 2

20 CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL © 2012 Trend Micro Inc.

DEEP SECURITY AGENT

Version 7.5, Service Pack 1

© 2012 Trend Micro Inc. CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL 21

22 CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL © 2012 Trend Micro Inc.

© 2012 Trend Micro Inc. CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL 23

2.2.2 Internal enhancements

Version 7.5, Service Pack 2

DEEP SECURITY MANAGER

24 CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL © 2012 Trend Micro Inc.

DEEP SECURITY AGENT

Version 7.5, Service Pack 1

DEEP SECURITY MANAGER

DEEP SECURITY VIRTUAL APPLIANCE

© 2012 Trend Micro Inc. CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL 25

Leverage faster slow path communication channel – to improve processing

DEEP SECURITY AGENT

2.3 > Product overview

26 CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL © 2012 Trend Micro Inc.

2.4 > About Deep Security Agent

OPERATING SYSTEM PRIVILEGES

© 2012 Trend Micro Inc. CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL 27

2.4.1 Agent architecture

Ds_agent.crt Contains the

28 CONFIDENTIAL — Release Pursuant to NDA — CONFIDENTIAL © 2012 Trend Micro Inc.

2.4.2 Agent: User mode